VPN - IKE Phase1 3 message pair

Author

IKE Phase1 3 message pair

pvsnmp@yahoo.com

2006-03-25, 9:54 am

Hi,
What is the purpose of the 3rd message pair in IKE Main mode Phase1
(messages 5 and 6)?
Its written its for authenticating the peers. Is it not possible to
combine this wth Phase2 messages which anyway contains Hash which can
be used to authenticate while using HMAC??
Is it not possible to spoof the address and authenticate anyway with
the 3rd pair of messages?

Regards,
Prashant

Stephen J. Bevan

2006-03-27, 7:53 am

pvsnmp@yahoo.com writes:
> What is the purpose of the 3rd message pair in IKE Main mode Phase1
> (messages 5 and 6)?

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.

> Its written its for authenticating the peers. Is it not possible to
> combine this wth Phase2 messages which anyway contains Hash which can
> be used to authenticate while using HMAC??
> Is it not possible to spoof the address and authenticate anyway with
> the 3rd pair of messages?

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.

pvsnmp@yahoo.com

2006-03-27, 7:53 am

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

Stephen J. Bevan

2006-03-27, 7:53 am

pvsnmp@yahoo.com writes:
> 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.

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.

> 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??

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.

pvsnmp@yahoo.com

2006-03-27, 7:53 am

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.
>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 :-)

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

Regards,
Prashant

Stephen J. Bevan

2006-03-31, 12:11 am

pvsnmp@yahoo.com writes:
>
> Why can't the responder look at the IP header?? Also, there are cookies
> to differentiate the messages.

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).

pvsnmp@yahoo.com

2006-03-31, 12:11 am

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

Stephen J. Bevan

2006-04-01, 12:29 pm

pvsnmp@yahoo.com writes:
> I guess we have the hash to authenticate. What else is required??

I don't know what else you want to do and so what 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??

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.

pvsnmp@yahoo.com

2006-04-09, 7:00 pm

Hi,
>I don't know what else you want to do and so what is required.
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

Stephen J. Bevan

2006-04-09, 7:00 pm

pvsnmp@yahoo.com writes:
> 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.

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 "stephen@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.