Re: Secure legacy authentication for IKEv2

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

Some comments on the latest proposal (appended)

This approach is certainly more compatible with the key exchange method of
IKEv2 than the original SLA.  This, I guess, is an advantage in terms of
specification and implementation.  On the other hand it costs one extra
round (bringing to 3 rounds the minimal possible exchange, and at least 4
rounds if the anti-DoS round is used). If people feel comfortable with
this trade-off then let's go with it.

The one thing that I definitely dislike in the appended proposal is that
it opens IDi (sent in message 3) to active attacks.  If there is one
application where identity protection really makes sense is in hiding
identities and locations of mobile users, which will be among the main
users of SLA. I suggest to make IDi optional in message 3, and make it
clear that implementations should NOT assume that this IDi value is
available, certainly not in a way that compromises the user's identity.

Now regarding the AUTH field in the client's side, which is to be computed
with a key exchanged by the underlying legacy authentication method
(assuming, of course, that such a key exists and it is made available to
SLA).  I have no practical (or other) experience with such key-providing
legacy authentication methods. However, since these are LEGACY methods
then I assume that if they generate a shared key then this key may be
intended for other uses. Can we be sure that this key (call it LK for
"legacy key"), if used by SLA, will be used ONLY by SLA?  Otherwise we may
end having one key LK which is used in two different settings.  In
particular, one may end using one key LK for two different cryptographic
algorithms. Are you sure that this is NOT possible?

One other question raised in the appended note is when should the AUTH
field be sent. Seems to me that the simplest specification is to send it
in the last client's message in SLA.  Even if this key (LK) is available
earlier, it does not buy you much to compute AUTH earlier (and you can
always keep the key for authentication at the end).  An early
authentication using LK can only help against a DoS attack mounted by a
MitM attacker; however I doubt that anyone will choose this costly (for
the attacker) way to to mount a DoS attack.

Finally, if we are already assuming this key LK and use it to calculate
AUTH from client to server, why not use it also in the other direction?
Namely, to compute an AUTH payload from server to client sent, say,
in the last protocol message. (This would be in addition to the AUTH
payload that R sends in message 4 using its signature key).  One advantage
of having this field is that it helps to authenticate the server in the
case that the client fails to properly authenticate the server using
certificates (this is a natural concern especially in view of certiifcate
use in SSL).  Also, I have not seen definite enough studies of this MitM
issue to be convinced that the authentication by the client using LK is
enough to prevent ALL forms of MitM against the tunneled run. Server
authentication using this key (which has no real complexity or
disadvantages since we are already using LK in SLA) can prevent unseen
attacks.  (Has anyone done a full analysis to confidently discard the
advantage of a server to client authentication using LK?)

Hugo

On Thu, 23 Jan 2003 Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:

> [....]

> > So let's see if we agree on the generic protocol for the simple case
> > (username/password):
> >
> >  HDR, SAi1, KEi, Ni           -->
> >                               <--    HDR, SAr1, KEr, Nr
> >  HDR*, IDi, [CERTREQ], [IDr,]
> >       SAi2, TSi, TSr          -->
> >                               <--    HDR*, IDr, [CERT,] AUTH, EAP(n)
> >  HDR*, [AUTH,] EAP(n)         -->
> >                               <--    HDR*, EAP(status) [, SAr2, TSi, TSr
> ]
> 
> Yes... that's what I think we should do.
> 
> > The final message from the client MAY include an AUTH payload if the
> > legacy authentication method establishes a shared key with the server.
> > If EAP processing requires an additional round-trip, the AUTH payload
> > from the client is repeated in Message 7 and on.
> 
> I would say the client MUST must an AUTH payload *if* the legacy
> authentication
> method establisheds a shared key with the server, and it MUST be in the
> first message from client->server after the client has enough information
> to generate it. For a given authentication method, that should always be in
> the same message. I wouldn't repeat it in subsequent messages.
> 
> I think we're getting close... are others being silent because they agree
> or because they are behind on email?
> 
>           --Charlie
>