Subject: [secdir] review of draft-ietf-ipsecme-ikev2bis-10

From: Tom Yu <[email-masked]>
Date: Tue, 04 May 2010 01:23:32 -0400

draft-ietf-ipsecme-ikev2bis-10 document intends to replace RFC 4306,
the previous specification of IKEv2.  My comments focus on the
Security Considerations section, which mostly the same as in RFC 4306.
None of these comments represents a major issue.

Compared to RFC 4306, the Security Considerations section of this
document contains additional comments about implementation robustness
against attacks (including exhaustion of computational resources) by
unauthenticated peers.

The following sentence from RFC 4306, referring to Diffie-Hellman
exponents, is not present in this document:

   In particular, these exponents MUST NOT be derived
   from long-lived secrets like the seed to a pseudo-random generator
   that is not erased after use.

I understand that this sentence was removed because it is impractical
for many implementations to comply.  For reasonable interpretations of
the randomness requirements which are listed a few paragraphs later, I
believe it is possible to securely implement this specification
without satisfying the RFC 4306 condition on erasing certain
pseudo-random number generator seeds after use.  The paragraph on the
randomness requirements would therefore subsume the above RFC 4306
condition that was deleted.  Do the authors agree?

The lengthy paragraph warning about non-key-generating EAP methods is
mostly unchanged from RFC 4306.  I do wonder if channel bindings would
help with non-key-generating EAP methods tunneled in protected
channels, but am not sufficiently familiar with EAP to know whether
this is feasible.  (non-key-generating EAP methods might not have any
way to perform the additional necessary authentication to achieve
channel binding)

The SHOULD in RFC 4306 in the sentence beginning "Implementers SHOULD
describe the vulnerabilities of non-key-generating EAP methods..." was
demoted to a non-capitalized form.  Is this intentional?  If so, what
is the rationale?

This document adds a paragraph about "admission control", a term for
which I am unable to find a contextually meaningful definition.  I
agree with the importance of choosing a more carefully evaluated set
of trust anchors for IKE authentication than for identification of
public web servers, but I am uncertain how that statement relates to
(network?) admission control in that paragraph.

The added section (5.1) on traffic selector authorization seems
reasonable to me.

Editorial:

"elliptical curve" -> "elliptic curve"

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 May 2010 07:59:11 -0700

At 1:23 AM -0400 5/4/10, Tom Yu wrote:
>for many implementations to comply.

Correct.

> For reasonable interpretations of

Yes. In particular, the sentence preceding the one that was removed is sufficient: "Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys."

>way to perform the additional necessary authentication to achieve

Channel bindings might or might not help here, depending on the current precise definition of "channel bindings". Trying to wind this into a bis document didn't seem prudent, given the loose state of the definition.

>demoted to a non-capitalized form.  Is this intentional?  If so, what

There is no interoperability effect of implementers describing something, and the security aspects are not clear. This seemed like an over-shooting of RFC 2119 language.

>(network?) admission control in that paragraph.

I think it was meant to indicate that gateways that talk to roaming clients might have different trust requirements than those that only talk to fixed gateways within an organization.

>The added section (5.1) on traffic selector authorization seems

Thanks.

>"elliptical curve" -> "elliptic curve"

<sigh> Good catch. Fixed in the next version.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Yu <[email-masked]>
Date: Wed, 05 May 2010 23:16:29 -0400

> Channel bindings might or might not help here, depending on the current precise definition of "channel bindings". Trying to wind this into a bis document didn't seem prudent, given the loose state…

I just checked, and RFC 5056 ("On the Use of Channel Bindings to
Secure Channels") deliberately chose to exclude EAP channel bindings
from its recommendations due to the difficulty of meaningfully
identifying the lower-level channel over which EAP runs.

> There is no interoperability effect of implementers describing
> something, and the security aspects are not clear. This seemed like
> an over-shooting of RFC 2119 language.

One change that would bring it back into a RFC 2119 scope is making a
recommendation such as "Implementations SHOULD default to disabling
the use of non-key-generating EAP methods", as that recommendation
would then have a useful security impact.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 May 2010 14:51:14 -0400

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> Paul Hoffman <[email-masked]> writes:
    >>> The lengthy paragraph warning about non-key-generating EAP
    >>> methods is mostly unchanged from RFC 4306.  I do wonder if
    >>> channel bindings would help with non-key-generating EAP methods
    >>> tunneled in protected channels, but am not sufficiently familiar
    >>> with EAP to know whether this is feasible.  (non-key-generating
    >>> EAP methods might not have any way to perform the additional
    >>> necessary authentication to achieve channel binding)
    >> 
    >> Channel bindings might or might not help here, depending on the
    >> current precise definition of "channel bindings". Trying to wind
    >> this into a bis document didn't seem prudent, given the loose
    >> state of the definition.

    Tom> I just checked, and RFC 5056 ("On the Use of Channel Bindings
    Tom> to Secure Channels") deliberately chose to exclude EAP channel
    Tom> bindings from its recommendations due to the difficulty of
    Tom> meaningfully identifying the lower-level channel over which EAP
    Tom> runs.

OK, so remember that there are two different definitions of channel
bindings: EAP channel bindings and RFC 5056 channel bindings.  If you
don't know the difference, giving up now for this discussion would
probably be reasonable:-) 

EAP channel binding could be used to provide RFC 5056 channel binding
for the IKE session, assuming that you could define an RFC 5056 channel
binding data appropriate to a under-negotiation IKE session.  However,
i'm unaware of any EAP methods that do or could easily be made to
support EAP channel binding that do not produce a key.

It would be possible to use RFC 5056 channel binding (or something like
it) to bind an EAP method that did not produce a key to the IKE session
if that method produced something similar to channel binding data.
No EAP methods today do this: why not make them produce a key instead if
you were going to manage to make such a change.

In conclusion, I don't think that RFC 5056 or EAP channel binding have
much to add to EAP methods that produce no key.