Re: Authentication methods in IKEv2

["Valery Smyslov" <svan@trustworks.com>]

----- Original Message -----
From: <Charlie_Kaufman@notesdev.ibm.com>
To: "Valery Smyslov" <svan@trustworks.com>
Cc: <ipsec@lists.tislabs.com>; <owner-ipsec@lists.tislabs.com>
Sent: Friday, November 15, 2002 6:29 AM
Subject: Re: Authentication methods in IKEv2


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

I agree with you that SA payload is not a good place for such information
unless we want authentication method to become negotiable again.

Actually I was thinking about new dedicated payload or CERTREQ
payload. Putting this information into CERTREQ payload seem to be
a bit more convinient, it allows to bind authentication method to particular
issuer
(for example, it allows to say: I will accept RSA certificates issued by CA1
or
DSS certificates issued by CA2), but the overall semantics of CERTREQ
payload seem to become very complex (especially for CRLs and
different certificate formats).

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

OK.

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

Actually, responder may attempt to perform new SA establishment
in reverse direction (as initiator), but this behaviour has so many
drawbacks, that I even don't propose it...

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

I think it is worthwhile to have such an option. Currently the situation
with multiple authentication mechanisms is uncommon, but things
might change in the future. Imagine new auth mechanism appear and
become popular (or RSA is suddenly compromised) and IKE needs to migrate to
it.
During migration period this situation will be very common.

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

Regards,
Valery Smyslov.