How IKE authentication happens? what's the role of HASH_I & HASH_R, and how it gets verified by each parties? and where SKEYID_a gets engaged?

Question

Dears,

In RFC 2409 "The Internet Key Exchange (IKE)", its mentioned there are four available authentication methods for IKE, there are different calculations for SKEYID for each method and hence we get HASH_I & HASH_R which seems it has one calculation way but the SKEYID gets engaged on its calculation.

Referring to the RFC 2409:

SKEYID is a string derived DH exchanged

SKEYID_e (encryption key, for the phase 1 messages)

SKEYID_a (for authenticating phase 1messages)

SKEYID_d (to protect "encryption & authentication" phase 2 messages)

The value SKEYID is computed separately for each authentication method.

For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) ===> let's focus on pre-shared key

PRF or HMAC (if no prf negotiated)

The result is the three groups of keying material:

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

HASH_I and HASH_R are generated by each party in order to authentication each others:

HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

Question #1: I don't see SKEYID_a got engaged in the calculation of HASH_I, where it should get engaged in the authentication process? Question #2: when the responder receives the packet with the HASH_I? what does it do to verify the authenticity of the initiator?

Answer 1

First of all, you are discussing the older version known as IKEv1 (which is really only of historic interest); the current version (known as IKEv2, which is what everyone should be using instead) does this entirely differently.

Anyways, to answer your questions:

I don't see SKEYID_a got engaged in the calculation of HASH_I, where it should get engaged in the authentication process?

It's not what SKEYID_a is there for. When we send an IKE packet, we add an authentication tag (the "hash payload") which the receiver can use to verify that the IKE packet was not modified (except some fields are not included in the authentication computation - don't ask me why). This authentication tag is computed via an HMAC - the SKEYID_a value is the key used to compute this HMAC.

That's the only thing it is used for - it is not used in the process of verifying the other side's identity.

when the responder receives the packet with the HASH_I? what does it do to verify the authenticity of the initiator?

That depends on the authentication used.

For certificate authentication, the HASH values are not explicitly transmitted (instead, the signatures of those values are).

For preshared key authentication, the actual authentication comes from the computation of SKEYID (which has the preshared key stirred in). The HASH values are exchanged and verified - they depend on the SKEYID value (and also have some additional dependencies on the initial exchange, to help verify that it wasn't modified in transit. Although, in practice, if the other side doesn't know the preshared key (say, on a preshared key mismatch), you won't be able to decrypt the packet (because your SKEYID_e is wrong), and so you fail before you get to that point...