Re: IKE V2 Open Issues

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

Derek, 

the questions you raise below were discussed in this thread.
Take a look at past messages on it. They should , hopefully, ,clear some
misunderstandings. Here are some brief answers to your questions.

First let me make a clarification that is important to keep in mind
(and relates to an objection that you raised in another message in this
thread). The proposal to protect IDi from active attacks applies ONLY
to the EAP extension of ikev2. All other runs of the protocol (in
particular peer-to-peer runs) will have the same protection that the WG
decided long ago (that is, IDr has full protection while IDi has only
protection against active attacks).

Also, important to keep in mind is that in the current EAP solution 
BOTH initiator and responder's identities are vulnerable to active
attacks. What I was proposing for the EAP exchange does not make it worse
for the responder in the EAP context (that is, it still has protection
against passive attacks) while it improves substantially the privacy
guarantee for the initiator.

See more below:

On 10 Apr 2003, Derek Atkins wrote:

> Hugo Krawczyk <hugo@ee.technion.ac.il> writes:
> 
> > > 
> > > 1) Hugo's proposal to change legacy authentication to protect the
> > > initiator's identity against active attacks.  After looking at the
> > > discussion, Barbara and I have concluded that the impacts of moving
> > > around various protocol elements introduces numerous additional
> > > complexities which will be hard to address at this late date.  Russ
> > > with his AD hat on set as the bar, "if the changes are the least bit
> > > onerous, then this should not be done".  We believe these changes meet
> > > that test.
> > 
> > objection! the above presentation of the complexity incurred by
> > the changes needed to suport  user's identity privacy (against
> > active attackers)  is inaccurate and misleading. The required changes are
> > purely local to the EAP extension of ikev2 and do not touch global
> > elements in the protocol nor they impact performance or any
> > other aspect of an application/implementation not running the
> > EAP extension (for example, if all we do is to move IDi to 5th message).
> 
> Note that the responder cannot start the EAP authentication system
> until it has an identity from the initiator (or it needs to send an
> "EAP Identity Request" which adds yet another round trip).  This is
> because the server needs to use the identity to determine what kind of
> EAP session to initiate.  This is usually accomplished via an
> encapsulation within RADIUS to some AAA server in order to
> authenticate the supplicant (using EAP terminology).
> 
> Basically, this means that moving IDi to message 5 implies you cannot
> start send the EAP Challenge until message 6, which means you're not
> done with IKE until at least message 8 (assuming a one-round-trip EAP
> protocol).  Are you SURE you want an 8-message protocol?  I'm not sure
> this is what we want.
> 

This additional RT is the price for one of the solutions (moving IDi to
5th message). The other solution (moving R's authentication to msg 2 as
SLA proposed) does not have this problem though it has some complexity by
itself (again these trade-offs were discussed already in this thread).

As for the question "Are you SURE you want an 8-message protocol?" I have
to say that its formulation is a bit unfair. It makes it sound as a
horrible thing. And may be it is. The question, however, is "Are you
willing to pay an increase from 6-mesages to 8 messages for user's id
privacy?". I am. But apparently most people are not.
And again, there are solutions that do not require the extra RT

> Also, what happens when you turn the protocol around?  I see you're
> initiating IKE with server X, so I initiate IKE with you to determine
> your identity -- how do you protect your identity there?
> 

I am assuming that the user's machine (or policy) will be configured such
that it will never respond to IKE-EAP initiations, but will only act as
initiator of EAP methods. That's how the user's id is  protected from
probe attacks.

BTW, note that anyone that requires protection of its own identity from
probing attacks has to make sure that it does not act as responder in a
EAP exchange. If a machine is configured to allow for such responses then
the protection promised by IKEv2 is gone.
(I ACTUALLY THINK THAT THIS NEEDS TO BE SPELLED EXPLICITLY IN THE DRAFT)

> Or are you saying that you're putting the identity in different places
> based on whether EAP is being used?  Well, how do you know if EAP is
> being used if you don't know who your peer is?  I can certainly posit
> a server that is configured to use EAP with some subset of peers and
> RSA authenticatation with some other subset of peers.  How does the
> server (acting as IKE responder) know which sub-protocol to use?

the server knows that the iniitiator requests EAP by the lack of signature
in message 3. All machines should be configured to reject such requests
except for those specific machines that will work as EAP-supporting
gateways.

In any case, this discussion is over. The decision on the EAP protocol for
IKEv2 has been made.

(And I will be travelling for a while now so do not expect a response 
from here)

Hugo

> 
> -derek
> 
> -- 
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com
>