Re: Secure legacy authentication for IKEv2

[Uri Blumenthal <uri@xxxxxxxxxxxxx>]

On the first glance - it looks very reasonable. I'm for it
(pending some more thinking).

Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:
> 
> I see a number of problems with the SLA proposal posted as an I-D,
> and have a counterproposal.
> 
> The SLA proposal says that message 1 is unmodified and Message 2 contains
> the responder's AUTH payload, moved from message 4. There are a number
> of problems with this. Message 3 contains the list of roots trusted by
> the initiator as well as the desired responder identity (the Me Tarzan,
> You Jane variation). The responder uses those values to decide what
> identity to respond with. We would either have to disallow that flexibility
> when SLA was used or move those values to message 1. If we move them
> to message 1, we lose the protection from passive eavesdroppers.
> 
> Further, a responder must know whether it is going to use legacy
> authentication or regular authentication after receiving message 1, which
> has few clues and therefore a responder could not accept either type.
> This could be fixed by putting a capability indicator in message 1.
> 
> In this protocol, the initiator decides what form of legacy authentication
> it wants to do and the responder can accept or reject that choice. This
> is the reverse of what happens with EAP, where the responder decides
> what form of authentication it expects sometimes based on the claimed
> user identity. This means that if some users of a particular piece of
> software use challenge/response tokens and some use username/password,
> it would be up to the user to communicate to the client software what
> sort of capability he has rather than waiting for the responder to prompt
> for something.
> 
> All of these problems can be worked around (but we would have to decide
> how before we would have a spec), and the limitations may be
> acceptable, but I believe they are unnecessary. I believe a smaller
> modification to the protocol avoids these problems.
> 
> The changes I would propose (derived closely from Stephane Beaulieu's proposal)
> are to leave the first two messages alone, replace AUTH and CERT in message
> 3 with an EAP exchange in messages 4 & 5 (and if more needed, 6 & 7, etc),
> and deferring the completion of the child SA establishment from message 4
> to the last message. Or more precisely:
> 
> No change to message 1.
> No change to message 2.
> Message 3: AUTH and CERT payloads are removed - perhaps an optional
> indication of legacy auth methods supported.
> Message 4: SAr2, TSi, TSr removed; EAP payload added
> Message 5: EAP payload
> Message 6: SAr2, TSi, TSr
> 
> (where extra pairs of messages can be inserted between 5 and 6 if more
> than one EAP round trip is required).
> 
> If a legacy auth method that produces a shared key is used, the next
> to last message should have an AUTH payload generated using that key.
> The purpose is to protect against man-in-the-middle attacks. Defense
> is only possible of the legacy auth method generates keying material,
> and using that key for creating an AUTH payload is simpler than other
> proposals that mix that keying material into the keys for the SAs.
> 
> Note that a (perhaps controversial) aspect of this proposal is that
> the initiator identity remains in message 2. This has the advantages
> that it minimizes changes to the protocol and may avoid a round trip
> in the EAP protocol because the responder doesn't have to separately
> prompt for username. It has the disadvantage that it presumes that
> with all legacy authentication methods there is some expression of
> the user's identity that can be prompted for in a uniform way. I
> can't think of any case where that wouldn't be true.
> 
> What do people think?
> 
>       --Charlie
> 
> Typical protocol run for the legacy auth case where we're just
> prompting for a username and password would be:
> 
>        HDR, SAi1, KEi, Ni   -->
>                             <--    HDR, SAr1, KEr, Nr
>        HDR*, IDi, [IDr,]
>             SAi2, TSi, TSr} -->
>                             <--    HDR*, IDr, [CERT,] AUTH, EAP(pwd)
>        HDR*, EAP(pwd)       -->
>                             <--    HDR*, SAr2, TSi, TSr}