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

[Tom Yu <[e-mail]>]

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"