Re: Secure legacy authentication for IKEv2

[Derrell Piper <ddp@xxxxxxxxxxxxxxxxx>]

On Friday, January 17, 2003, at 08:04 PM, 
Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:

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

Is this a valid optimization, i.e., is it that most EAP implementations 
will be able to avoid an EAP protocol exchange to prompt for user 
identity if the user identity is available out-of-band (w.r.t. EAP)?  
RFC2284 says that that exchange is optional, but it doesn't say what's 
BCP (and I have no idea).  It might be worth pointing out that IKEv2 
implementations will likely be calling out to existing EAP 
implementations and therefore need to adhere to whatever existing EAP 
API's currently allow.  More below...

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

[You have some extra "}"'s here which I assume are transcription 
errors...]

vs. SLA comments:

In SLA, the client didn't have to reveal his identity until after the 
gateway proved its identity.  Here, the client sends his identity in 
message 3 before the gateway proves its identity in message 4.  This 
proposal allows any active attacker to observe client identities by 
simply replying with message 2.

EAP integration comments:

Note: I'm convinced that using EAP is a good idea.  My comments aren't 
intended to argue against it...

1) Are existing EAP implementations prepared to associate an externally 
derived user identity with an EAP exchange?  If so, the assumption that 
the EAP(Request/Identity) and EAP(Reply/Identity) round can be 
optimized out is valid.  If not, it probably ought to begin in message 
2.   Which bring us to the second point...

2) How does a gateway know its doing SLA?  SLA proposed a separate 
exchange type for this.  Since this does not resemble "normal" IKEv2, I 
think a separate exchange type is justified.  It's also good for the 
responder, since he can tag the larval exchange as being SLA.  And it 
also makes the question about the EAP identity prompt round moot, since 
the gateway could respond with an EAP(request/identity) payload in 
message 2.

3) You're missing the final EAP(Success) or EAP(Failure) payload, which 
needs to be returned by the gateway in its final response (to complete 
the EAP protocol).  That would be message 6, as you've drawn it.

All in all, there's not that much difference from what I wrote on 12/21.

	HDR, SAi1, KEi, Ni			-->
							<--  HDR, SAr1, KEr, Nr,
								  EAP(Request/Identity), AUTH
	HDR*, SAi2, TSi, TSr,
		EAP(Reply/Identity)	-->
							<-- HDR* EAP(n)
	HDR*, EAP(n)				-->
                                 <--	HDR*, EAP(SUCCESS),
									  SAr2, TSi, TSr

					...or...

							<-- HDR*, EAP(FAILURE)

To summarize the differences, some of which are admittedly trivial:

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

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

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

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

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

6) Is this a separate exchange type or not?

I still think there's value to having the gateway prove itself *before* 
the client has to reveal his identity, but that's just my opinion.  
Note that the change that Hugo proposed to move the identity binding 
MAC into the signature definition is necessary if the AUTH payload 
happens in message 2, but not if it happens in message 4 with explicit 
IKE ID payloads.

Derrell