Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

[Tero Kivinen <[e-mail]>]

Dan Harkins writes:
> >>   - there is another IKEv1 feature not available in IKEv2: a deniable
> >>     authentication method. IKEv1 had a very cool deniable exchange
> >>     involving encrypted nonces. IKEv2 decided to not support that for
> >>     whatever reason. Lack of support for a cool and usefu authentication
> >>     method doesn't really make the case to send IKEv1 to historic
> >
> > Can you clarify this a bit further for me? Is this deniable
> > authentication method part of all IKEv1 auth methods? Or is this a
> > specific feature that needed to be specifically enabled?
> 
>    It was one of the authentication methods: PSK, certs, encrypted
> nonces. The encrypted nonce method was completely deniable. Honest
> participants would get strong authentication but they could prove
> to a court-of-law that the whole exchange could be fabricated by a
> third party and deny ever taking part in it.

The draft-ietf-ipsec-ikev2-00.txt draft only included digital
signatures, -01 version added shared secret authentication, but
encrypted rsa was never even considered for IKEv2, i.e., it was never
explcitly removed, it was simply never taken in to the IKEv2.

If I remember correctly (this discussion happened around year 2002 or
so) the reason was that there were no requirement for it. While there
were IKEv1 implementations which supported authentication with public
key encryption mode, not all implementations had it. Also support for
the revised method of authentication with public key encryption was
even less common. Also VPN and remote access people did not consider
benefits from the authentication with public key encryption mode
useful for them.

Having two different keys, one for signing and one for encryption, for
authentication was considered complicated, and reusing same key for
both signing and for encryption was considered bad idea.

And also I think shared key authentication also offeres exactly same
benefits than authentication with public key encryption for the
deniability point of view (i.e., either end can calculate everything
as long as they know the shared secret).

> > That said, if the WG deemed this feature no longer required when
> > specifying IKEv2, then I do not think we need to mention this here when
> > we are talking about motivations for people to move from IKEv1 to IKEv2.
> >
> > If there is a good reason and people are prevented from upgrading to
> > IKEv2 because of this, I would be expecting an IKEv2 draft to be
> > developed to address this shortcoming. But it seems to me (I wasn't here
> > when these decisions were made) that the WG did not think this issue was
> > a concern ?
> 
>    I walked away from the WG after I produced -02 of the draft that became
> IKEv2 so I have no idea what the was thinking after April of 2002 (nearly
> two decades! Yikes). There were a number of decisions that the WG made that
> looking back were odd. This is just one of them. Deniability is a valuable
> property and I don't know why it was ditched.

It was not ditched, it was never included. I.e. the public key
encryption was not in the -00 version. Shared secret (which provide
deniability) was added in version -01.
-- 
[e-mail]