Re: Authentication methods in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

You're describing a different problem than the one addressed by the
proposed solution.

The proposal was for the negotiation of authentication methods (e.g.
X.509 cert or SecurID # or Password). That was the case I claimed was
unusual. You're trying to handle the case of negotiation of which of
several keys is used with a single authentication method. While I agree
this would be a nice feature, it's not supported today with or without
authentication method negotiation.

If we wanted to support such a capability, I think the appropriate syntax
would be to have something like a CERTREQ payload that instead of
stating what certifiers I trust states what key(s) I would like you to use in
creating the AUTH payload.

Do people think such a capability should be added?

      --Charlie

> >>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:
>     Charlie> At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
>     >> I have some doubts about using of authentication methods in IKEv2.
>     >> In IKEv2 negotiation of authentication methods was completely
>     >> removed - each side simply uses his/her favourite method.
>     >> I think this may lead to the lack of interoperability and extensibility
>     >> in case one of the endpoints supports more than one method of
>     >> authentication.
>
>     Charlie> A problem only occurs when one or both sides have
> multiple different keys
>     Charlie> (or different ways of using the keys) with which they
> could authenticate. I
>     Charlie> would expect this case to be unusual, but it certainly
> could happen. If it
>
>   The situation is not unusual.
>
>   Any system that generates new public keys regularly will have multiple keys
> that it could use. Combined with the fact that many directory systems are not
> instantaeous, and you have a wave effect, that reminds me of how light/sound
> propogates.