Subject: Re: Secure legacy authentication for IKEv2

From: [email-masked]
Date: Wed, 22 Jan 2003 21:56:46 -0500

Derrell Piper <[email-masked]> wrote on 01/19/2003 01:09:32 PM:

> To summarize the differences, some of which are admittedly trivial:
>
>
> 6) Is this a separate exchange type or not?

(CKnote: I reordered your differences, for clarity of responses).
I had misread the SLA proposal. The fact that it specifies a separate
exchange type removes some of my objections.

>
> 5) AUTH payload in message 2 or message 4?  --> implication for client
> identity protection

I believe this is the most important difference. Moving AUTH from message 4
up to message 2 makes the protocol quite different from the non-SLA case,
and (I believe) this makes a lot of other changes necessary. It also
complicates the analysis and changes the "what can an eavesdropper figure
out" properties. The main advantage is (possibly) saving a round trip,
which I would argue is not very important in a protocol that is interacting
with people.

> 1) Do we need to allow for the EAP identity exchange?  If so, where
> does it occur?

If it's going to happen, I think it should happen in messages 4 & 5. This
would extend the protocol one round trip in the case of legacy
authentication, with the benefit of protecting the client identity from
someone pretending to be the server.

As to whether it has to happen, I don't think so. If there were some future
EAP exchange that did not start with an identity request, then the ID
payload couldn't substitute. But that seems unlikely.

From a technical perspective, it's a trade off between one more round trip
and protecting the initiator's claimed identity from something
impersonating the server. I don't believe either of these issues is worth
fighting over. I'd happily go the other way but anticipated howling over 8
messages for username/password authentication.

>
> 2) Do we want to require or allow IKE ID payloads in addition to the
> EAP identity?

I don't think so. I think we want one or the other. I was proposing IKE ID
payload as a replacement for EAP identity exchange.

>
> 3) Addition of optional CERT payload returned by the gateway along with
> its AUTH payload.

I think this is necessary. You can't necessarily verify a signature without
the certs. I also believe the CERTREQ should precede the CERT so the client
can specify trusted roots and IDr should precede the CERT so the client can
name the server it wants to connect to in the case of a shared IP address.
These combined make it possible that message 1 will require fragmentation,
which in turn complicate the cookie/DOS stuff.

>
> 4) What is the order of the EAP payloads relative to other payloads?

I don't think we disagree on this one, though the SLA proposal saves a
round trip by not using the EAP syntax. I believe that's a false economy.

There is another important difference you didn't mention. My proposal has
an optional AUTH payload in the final message from client to server in the
event that the legacy authentication method establishes a key between the
two parties. The SLA spec doesn't say how such a key would be used, though
some possibilities have been proposed on the list.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Derrell Piper <[email-masked]>
Date: Thu, 23 Jan 2003 11:34:39 -0800

> exchange type removes some of my objections.

I'd still propose that we use a separate exchange type for the legacy 
authentication exchange.

Derrell

---

From: Derrell Piper <[email-masked]>
Date: Thu, 23 Jan 2003 11:27:41 -0800

> which I would argue is not very important in a protocol that is 

I was hoping for more discussion from others.  I can go either way 
myself.  Since we're running out of time and there's been no other 
input, I'll defer to your preference.

> messages for username/password authentication.

This question is really directed at folks who have implementation 
experience with EAP.  Is it the case that existing EAP implementations 
generally do not require the optional identity exchange when they have 
an identity available from some other out-of-band source?  I was hoping 
some EAP folks would speak up here...  Or do you sometimes masquerade 
in an EAP hat?  :-)

It's certainly cleaner for IKE if that's the case and if we can rely 
solely on our own ID's.  But I'd hate to see us say that that's how 
it's going to work and then find out that in the real world, BCP for 
EAP just doesn't work that way...  I think it behooves us to make sure 
that the way we're proposing to use EAP is realistic.  Are any EAP 
people following this discussion?  William?

Having gotten that off my chest, let's assume this is the case...  :-)

> payload as a replacement for EAP identity exchange.

I'd prefer this too, again as long as this is copasetic with EAP folk.

> which in turn complicate the cookie/DOS stuff.

Yeah, fine.  SLA made some aggressive assumptions about its client's 
configuration and constraints.

> some possibilities have been proposed on the list.

Good point, sorry I missed that.  That's a great idea, though there is 
a nuance to saying that.  Does the client aggressively send an AUTH 
payload whenever *he* thinks the authentication is done, or does he 
send it only after receiving a positive EAP(success) from the gateway?  
I.e., does it end:

        HDR*, EAP(n), AUTH   -->
                             <--    HDR*, EAP(success), SAr2, TSi, TSr

...or...

        HDR*, EAP(n)         -->
                             <--    HDR*, EAP(success), SAr2, TSi, TSr
        HDR*, AUTH           -->

The issue with the former is that the client might not necessarily know 
which is his last response.  I'm thinking about SecurID Next Code mode, 
thought that's obviously a bad example for a shared key.  The issue 
with the latter is that it makes the exchange an odd number of 
messages, which is bad for our retransmission policy.
So we should probably chose the former.  So in the case of an extra 
round-trip it ends like this:

        HDR*, EAP(n), AUTH   -->
                             <--    HDR*, EAP(n)
        HDR*, EAP(n), AUTH   -->
                             <--    HDR*, EAP(success), SAr2, TSi, TSr

--------

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 ]

Additional round-trips may occur after after Messages 4 & 5, depending 
on the EAP exchange type.  Additionally, if an EAP identity exchange is 
required, it begins with Message 4 (and necessitates additional 
Messages 7 & 8).

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.

The final message from the server completes the CREATE_CHILD_SA setup 
begun in message 3 and returns SAr2, TSi, TSr only when the EAP 
authentication was successful.

For the case where one additional EAP round-trip is required (e.g., 
SecurID Next Code mode):

        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(n)
        HDR*, [AUTH,] EAP(n)         -->
                                     <--    HDR*, EAP(status) [, SAr2, 
TSi, TSr ]

When EAP processing requires additional round-trips, Message 6 contains 
only an EAP payload.

Derrell

---

From: [email-masked]
Date: Thu, 23 Jan 2003 21:52:36 -0500

> some EAP folks would speak up here...  Or do you sometimes masquerade

I checked my hat collection and none say EAP. I agree it would be nice to
get feedback. Anyone???

>  Does the client aggressively send an AUTH

I would propose that the client sends an AUTH payload whenever he has
enough information to have generated the shared key. I believe that would
always be before the EAP(success) message, though it would depend on the
details of the protocol. Are any key-generating algorithms defined for EAP?

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

> 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

---

From: Derrell Piper <[email-masked]>
Date: Fri, 24 Jan 2003 11:11:06 -0800

On Thursday, January 23, 2003, at 06:52  PM, 
[email-masked] wrote:

> the same message.

> I wouldn't repeat it in subsequent messages.

But it might be that the subsequent EAP exchange generates a new key.  
For generality, I think it should be shown as optional on subsequent 
messages...  Basically, send it when it's first known and if/when it's 
changed.

Derrell

---

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 25 Jan 2003 00:54:29 +0200 (IST)

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 [email-masked] wrote:

> [....]