[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Secure legacy authentication for IKEv2


On Wednesday, January 22, 2003, at 06:56 PM, Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:

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.

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.

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.

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

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.

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

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.

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

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.

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