[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The remaining IKEv2 issues



On Tue, Aug 19, 2003 at 11:18:33AM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@sun.com> writes:
>     Nicolas> For challenge/response token EAPs one could define a challenge
>     Nicolas> based on some derivative of the key exchange.  Thus the client
>     Nicolas> could verify that the challenge corresponds to the KE and the
>     Nicolas> server could verify that the response corresponds to the
>     Nicolas> challenge and if both check out then the KE is authenticated.
> 
>   There is a key thing that you should realize: in general, the responder
> (aka "gateway") won't be able to derive the appropriate response itself.
> 
>      i.e. we can't do something like CHAP.
> 
>   The reason is that the gateway will likely have to provide the literal
> reply via EAP/Radius to another machine for checking.
> 
>   I'm not certain what systems your proposal would work for.
>   Not SecureID, not X9.9, not passwords-over-radius.

The challenge function would have to be modified in those systems - it's
not applicable only at the responder.  This means that the responder
would have to be able to pass the "session ID" to the token system that
generates the challenge, so not only would existing systems have to
change, existing interfaces would have to change.  And initators would
have to be able to verify that the challenge is derived from or bound to
the "session ID."  Large changes indeed.

That's why I said "[some]" in one post - I couldn't say that this
applies easily to any one challenge/response token system, not with any
useful degree of certainty.

(I did have a challenge/response system like SafeWord's in mind though.)

The situation could change in the future though (that is, implementors
could follow the spec in this case, rather than the spec follow the
implementors).

I did also own up to my ulterior motive for offering this :)

Cheers,

Nico
--