|
Posted by Stephen J. Bevan on March 27, 2006, 12:53 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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.
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map