Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ikev2-null-auth-06: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Stephen,

thank you for your comments.

> Stephen Farrell has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-null-auth-06: Yes
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - 2.1: just wanted to check as I didn't have time to go
> through it all myself - are we confident that using
> SK_pi/SK_pr in this way has no cryptographic downsides? The
> reference to the EAP methods convinces me this is no worse
> than an existing thing, but not (by itself) that it is
> cryptographically sound, so I just wanted to check as I
> think prf(SK_pr,IDr') has until now been calculated but not
> transmitted, so there's a tiny change here maybe, but as I
> said I didn't have time to fully check. If someone just
> tells me that yes, the authors/wg did consider this, that'll
> be fine, no need to fully explain to me why using SK_pr like
> this is safe (though if you want to, that'd be fine too).

In IKEv2 the AUTH payload plays dual role - it first authenticates
peer identity and it also cryptographically binds the first
messages of IKE_SA_INIT exchange to the protocol run.
Unlike the other IKEv2 messages the messages of IKE_SA_INIT
have no cryptographic protection and are sent in clear, so they
need to be included into the AUTH payload calculation.
The calculation of the AUTH payload depends on the authentication
method the host selected, but in general it is digital signature
(in case of certificates or raw public keys) or prf (in case
of preshared key) over the blob of data containing
the IKE_SA_INIT message, peer's nonce and own
MAC'ed identity.

With the NULL authentication the first role of the AUTH
payload is obviously lost (by definition there is no credential
in case of the NULL authentication, and thus no way to authenticate 
identity,
and often no identity itself). But the second role - binding the first 
messages,
is still very important. That's why the AUTH payload cannot be omited.
As the host has no credentials, the only way to calculate
AUTH payload is to use some key derived from SKEYSEED
for that calculation. The SK_pi/SK_pr are the natural choice.
And the situation with the NULL Authentication in this regard is the same,
as with the EAP authentication in case the EAP method doesn't
produce the shared secret. In this case the RFC7296
instructs to use SK_pi/SK_pr as shared secrets when
calculating AUTH payload. Note, that in this case IKE identity
becomes not authenticated (only the identities that were exchanged
inside EAP method are authenticated), so we get the same situation
as with NULL authentication.

The SK_pi/SK_pr are also used in the calculations of MAC'ed
identities (e.g. prf(SK_pr,IDr')), but it is not where SK_pi/SK_pr
are used as keys for calculating AUTH payload. To be precise,
in case of the NULL authentication (and EAP with non-key-generating
methods) the SK_pi/SK_pr are used twice in the calculation of the
AUTH payload - first as preshared key and second in the calculation
of MAC'ed identity, that then included in a data blob,
"signed" with the preshared key (the same SK_pi/SK_pr).

We (the authors) don't believe that the draft somehow changes
the authentication fundamentals, that IKEv2 is based on.
The construction of AUTH payload in case of NULL authentication
is exactly the same, as with EAP methods that don't generate shared
secret. It was in the draft from the very begining
and I drew WG's attention to this fact, but no
comments were received, that would criticize it from
cryptographic point of view.

Hope this long explanation helps.


> - 2.5: "hand out" is an odd phrase here - would be better
> to expand on that I think and say more precisely what
> should never be done.

I think Paul Wouters, my co-author, will address this
and will expand the text.

Regards,
Valery Smyslov.