[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure legacy authentication for IKEv2
Hugo,
I think I was the main opponent to using EAP, but I'm willing to
concede this point if it helps get us to consensus. I see now that
using EAP is cryptographically no worse than what we proposed with SLA
(see other thread) and you make some good arguments here for its
adoption (as do others).
Note that SLA proposed a strict client-directed authentication
exchange. For each client request, the server's response either
completed the exchange or contained an additional challenge. The SLA
protocol did not allow for negotiation of the LAM type (without
restarting the exchange). This was chosen primarily so that the client
could aggressively send his credentials in message three. RFC2284
(EAP) instead implements a request/response protocol run by the
responder ("authenticator" in RFC2284) and allows for flexibility in
authentication type negotiation (the client can "nak" the requested
type and request something else).
So here's a fairly straightforward substitution of EAP for CHRE in SLA:
We'll need to define an EAP payload:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Packet ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Critical Bit MUST be set in all EAP payloads. The EAP Packet and
its contents are defined in RFC2284.
The first two messages remain almost the same as for SLA. The response
from the gateway now also includes the EAP identity request and begins
the EAP protocol. Note that this is only a request; identity
protection for the client is not compromised if the server
authentication fails.
Initiator (client) Responder (gateway)
------------------ -------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr,
EAP(Request/Identity), AUTH
The responder's AUTH payload is computed over all of message one
concatenated with all of message two. Because the contents of the AUTH
payload cannot be known when creating the concatenation, a dummy AUTH
payload is constructed which consists of the payload header that would
have been used (including a correct length field), but with each octet
of the contents set to 0x0.
The client MUST both verify the signature as being valid for the
gateway's public key as well as verify that the signed exchange matches
the actual data sent by the client in the first message.
Message 3 contains the EAP identity response:
HDR*, SAi2, TSi, TSr,
EAP(Reply/Identity) -->
Message 4 through message N-1 have the following format and essentially
define a challenge/response exchange between the gateway (acting as an
RFC2284 "authenticator") and the client (an RFC2284 "peer"):
HDR*, EAP(n)
Message N is the last message, and MUST come from the responder. If
the responder successfully authenticates the initiator, message N is:
<-- HDR*, EAP(SUCCESS),
SAr2, TSi, TSr
If the responder does not successfully authenticate the initiator,
message N is:
<-- HDR*, EAP(FAILURE)
Best case we complete the exchange in six messages vs. four for CHRE in
SLA. (NB: this is still a whole lot better than the nine or ten
required for IKEv1 when using a standard MM/QM exchange). Note also
that the even number of messages defined here plays well with IKEv2's
retransmission policy (c.f. IKEv2 (03) Section 4.1).
Derrell
On Friday, December 20, 2002, at 05:30 PM, Hugo Krawczyk wrote:
> It is up to the "legacy authentication" community to come up with
> solutions to
> these problems (which arise from the essentially-insecure use of
> credentials
> in mixed protected/unprotected environments). Moreover, if you support
> EAP
> exchanges and the EAP community comes up with measures to alleviate
> these
> attacks in the context of EAP then you get the benefits of this
> solution
> automatically. If you do CHRE then you don't.
>
> That's a good reason to support EAP in SLA.
>
> And it is not the only benefit:
> There is a lot of deployment of EAP and the definition of
> authentication
> mechanisms over EAP can be (and is) done independently of IKE. In my
> view, it is better to leave these definitions in the hands of people
> (such as the EAP WG) that specifically care about transport of client
> authentication. If you rely on EAP then all you have to care about is
> to
> build a sound tunneling mechanism for EAP in the context of IKEv2
> (rather than building profiles that depend on the specifics of
> secure-id,
> radius, etc.) And, as said, the EAP guys are better suited to take
> care of
> problems in the "legacy authentication" world such as the above "man
> in the
> middle attacks" against tunneled authentication that have been a
> concern
> lately in this community.
>
> And adopting EAP into SLA is easy, just copy PIC.