Re: Authentication methods in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

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.

A problem only occurs when one or both sides have multiple different keys
(or different ways of using the keys) with which they could authenticate. I
would expect this case to be unusual, but it certainly could happen. If it
did, I think it would be more natural to encode "what kind of
authentication information I will accept" not in the SA negotiation but
rather in the CERTREQ payload (which would have to be extended) or another
payload like it. I don't think it belongs in the SA negotiation because the
two sides don't have to agree on it. But as with telling you my list of
trusted roots, I might want to tell you what mechanisms I can accept. Also
a natural for this space would be information like the names of Kerberos
realms from which I can accept tickets (for some hypothetical future
extended version of the protocol).

> Another thing that makes me feeling uncomfortable is that even
> type of key an enpoint uses for her own signature is not always
explicitely
> indicated in the protocol. It can easily be learned if certificate
> is present in exchange, but certificate payload is optional...

This is an oversight dating back to when there was only certificate based
authentication. Unless someone objects, I'll add a specifier of the
authentication data type, of which we currently have 3: RSA signature, DSA
signature, and shared key HMAC.

Paul Hoffman writes:
> The worst-case scenario is that the responder tells the initiator "I
> don't trust you", and the initiator tries again with a different
> authentication mechanism.
>
I don't buy this.
This works if it's the initiator who has multiple mechanisms. It
doesn't help the responder with multiple mechanisms.

> For the rare case where the two endpoints don't really know each
> other *and* are going to trust each other *and* have multiple
> authentication mechanisms, we have eliminated a confusing option from
> IKEv1. That's exactly what IKEv2 was designed to do.
>
I might buy this. It is an uncommon circumstance. It will add
complexity to IKEv2 to handle it. If we decide to allow this, I
believe we could best do it with an optional payload - perhaps
CERTREQ, in which case we could add it later without backwards
compatibility problems. I could go either way... what do others
think?

If we are going to let the endpoints indicate their capabilities,
I would think we would allow them to specify RSA and/or DSA key
sizes (which brings back the 1023 vs 1024 bit issues) as well as
shared key HMAC.

Jan Vilhuber wrote:
> So, in theory anyway, authentication methods need to be negotiated via
> cipher-suites within the SA payload, and thus the AUTH payload is
> well-defined by nature of the cipher-suite both agreed to (rather than
> adding another 2 bytes of 'type' to the AUTH payload).
>
> he cipher-suites not contain the authentication type?

No, the cipher-suites do not currently contain the authentication type.

> If we want to support legacy authentication in IKEv2, we definitely
> need to be able to tell the 'client' that she's supposed to do legacy
> authentication (at least in my idea of how legacy authentication needs
> to work). So authentication-parameters for phase 1 need to be part of
> the SA payload in some way (as part of the cipher suite or as an extra
> value somewhere or whatever).

Yes, one of the issues with legacy authentication is how to negotiate
it in the case where it's one of several possible forms of authentication
an endpoint has "keys" for (again a fringe case). If we've going to
negotiate it, my preference would be to see it in an optional payload.

          --Charlie Kaufman

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