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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 27 May 2015 00:43:32 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-ikev2-null-auth-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/

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

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

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 27 May 2015 11:49:49 +0300

Hi Stephen,

thank you for your comments.

> draft-ietf-ipsecme-ikev2-null-auth-06: Yes

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.

> to expand on that I think and say more precisely what

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

Regards,
Valery Smyslov.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 31 May 2015 11:57:43 -0400 (EDT)

> to expand on that I think and say more precisely what

How about:

OLD:

    A rogue IKE peer could use malicious Traffic Selectors to obtain
    access to traffic that the host never intended to hand out.

NEW:

    A rogue IKE peer could use malicious Traffic Selectors to trick
    a remote host into giving it IP traffc that the remote host never
    intended to be send to remote IKE peers. For example, if the remote
    host uses 192.0.2.1 as DNS server, a rogue IKE peer could set its
    Traffic Selector to 192.0.2.1 in an attempt to receive the remote
    peer's DNS traffic.

Paul

---

From: [email-masked]
Date: Sun, 31 May 2015 16:24:37 +0000

> > to expand on that I think and say more precisely what

Yep that's better.
Ta
S