Re: Secure legacy authentication for IKEv2

[Charlie_Kaufman@xxxxxxxxxxxxxxxx]

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

I checked my hat collection and none say EAP. I agree it would be nice to
get feedback. Anyone???

>  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 would propose that the client sends an AUTH payload whenever he has
enough information to have generated the shared key. I believe that would
always be before the EAP(success) message, though it would depend on the
details of the protocol. Are any key-generating algorithms defined for EAP?

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

Yes... that's what I think we should do.

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

I would say the client MUST must an AUTH payload *if* the legacy
authentication
method establisheds a shared key with the server, and it MUST be in the
first message from client->server after the client has enough information
to generate it. For a given authentication method, that should always be in
the same message. I wouldn't repeat it in subsequent messages.

I think we're getting close... are others being silent because they agree
or because they are behind on email?

          --Charlie

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