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

[Paul Hoffman <[e-mail]>]

At 1:23 AM -0400 5/4/10, Tom Yu wrote:
>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.

Correct.

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

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

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

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

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.

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

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
>reasonable to me.

Thanks.

>Editorial:
>
>"elliptical curve" -> "elliptic curve"

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

--Paul Hoffman, Director
--VPN Consortium