[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure legacy authentication for IKEv2
Derrell Piper <ddp@xxxxxxxxxxxxxxxxx> 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
> 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.
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).