IKE Phase1 3 message pair

There are three variants of main-mode: pre-shared secret, signature, public key. Is your question about all of them or just one of them? If you meant all three then consider the case of pre-shared secret or signatures and how you'd implement identity protection with only four messages while also avoiding performing expensive keying operations from forged addresses[1]. If you don't want identity protection or care about performing unnecessary work then you can use less messages which is exactly what aggressive-mode does.

You'd need to lay out your idea in more detail for anyone to be able to analyze it and say whether it was viable. However, since IKE isn't open to change and IKEv2 already exists (RFC 4306) then I'm not sure you'll get a lot of takers.

--------------

[1] IKEv2 takes the approach of supporting a 4 message negotiation that provides identity protection (and can perform the first "phase2" negotiation) and a 6 message negotiation that avoids doing unnecessary keying or even storing any state for forged requests.

Hi, Thanks for the reply. My argument is how can you be sure of the identity just because the peer includes its identity in the 5th message if the peer is initiator. Is it not possible for someone else to just enter that ID and construct the 5th message of Phase1?? My question was with the case of pre-shared key. I have read in some documents that the various keys SKEYID_D, SKEYID_A and SKEYID_E (apologies if the notations dont match rfc) are computed before the 3rd pair of messages and used in later stages. Also, its given that source authentication is done via HMAC. And given the fact that a hash (probably using HMAC) is attached in phase2 messages which is computed using one of the above derived keys, I dont see the need for the 3rd pair of messages in Phase1. How do you justify its purpose? Is it significant only for the presence of the Identification payload??

Thanks and Regards, Prashant

If the case of a pre-shared key then the phase1 identity is superfluous in the situation where only the initiator and responder know the pre-shared key since the ability to correctly encrypt the 5th message and construct a valud HASH_I indicates that the initiator is whomever the responder gave the pre-shared key to (and vice versa). Of course if the responder shares the same pre-shared key with multiple initiators then the responder has no way of knowing which initiator it actually is. That's why it isn't a good idea to share the pre-shared key with more than one peer :-) There are cases where sharing the same pre-shared key is used, but then it is typically augmented with another authentication phase e.g. Modecfg.

Without the 5th and 6th messages then neither side can be sure who they are talking to. As you note, determining this could be deferred until the first phase2 but to what end?

If the goal is to understand why it was done the way it was in IKE(v1) then I recommend reading the IPsec mailing list archives and the early drafts which cover goals the ISAKMP vs IKE split and the split betwen phase1 and phase2[1]. You might not agree with the goals or the chosen solution but it might help understand why IKE is the way it is and hence why your approach is not used in IKE. I also suggest looking at IKEv2 which improves on IKE in that the common case of generating an IPsec SA between two peers using a pre-shared key now only requires

4[2] messages rather than 9 in IKE.

-------------------------- [1] Consider what changes would also need to be made to GDOI (RFC 3547) if it could not rely on the phase1 authenticating the user and instead had to defer that to its phase2. Note I don't mean to imply it could not be done only that GDOI is simpler because it can rely on the authentication already having been done by phase1. Whether this tradeoff is a good one is partially philosophical in that one camp would argue that the separate phases simplify the construction of phase2 protocols like GDOI while the other camp would argue that more efficient protocols can be constructed by considering them as a whole.

[2] 6 messages if you want to be sure you aren't being spoofed into performing a DH calculation for a non-existent peer but as an implementor you get to make the choice i.e. if the responder is lightly loaded you can perhaps afford to do the DH calculation even if the initiator was being spoofed and only switch to a 6 message variant if your load increases beyond some limit.

Hi, Thanks once again for a wonderful reply. I will try to look into the archives and understand why its designed the way it is. But I have one question.

Why can't the responder look at the IP header?? Also, there are cookies to differentiate the messages.

Regards, Prashant

The responder can look at the cookies and/or IP address to to determine that two different packets belong to different phase1/phase2 but neither the IP address or cookies *authenticate* the initiator. That is, the responder can tell it has two connections , but not who those connections are from except to know that the connections are from one or more people that have access to the pre-shared key. Sometimes that's enough (e.g. you are just providing access to some service that all users can use) and sometimes it is not (e.g. different users are allowed access to different services).

Hi, I guess we have the hash to authenticate. What else is required?? And about the problem of different users being allowed to access different services, I think the phase 2 proxy ID takes care of that. Am I right??

Thanks and Regards, Prashant

I don't know what else you want to do and so what is required.

The phase 2 proxy ID does take care of that, though it obviously only works if you've already authenticated a user so that only the proxy IDs that you've configured to be allowed for that user can actually be negotiated. If the user is not authenticated first then all the proxy IDs in the world aren't going to help.

Hi,

What I meant was that when we have the hash computed using HMAC which can be (is) used to authenticate the peers, why do you need an explicit pair of messages with the IP Address of peers in it, as in the 3rd pair of messages. I am still going through the archives , i will get back in case I dont find any convincing mail there.

Thanks and Regards, Prashant

In the case it is an IP address it isn't much use. The best that can be done is to optionally check it matches the IP address on the IKE packet but even that fails in the presence of NAT.

However, the IDii does not have to be an IP address. It could be a FQDN or an opaque key. Either of these can be used to pass down a value that is known only to the initiator and responder. Obviously using a FQDN name like " snipped-for-privacy@dino.dnsalias.com" would be easy to guess but if instead it was a string like "stephen/*WQ732HG" where "stephen" is the user-name and "*WQ732HG" is another shared secret then this can be used to provide identity protection (stephen) and provide a way to use main-mode with a (group) pre-shared key but still providing per-user authentication.