[Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00

[Alexey Melnikov <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-burgin-ipsec-suiteb-profile-00
Reviewer: Alexey Melnikov
Review Date: 17-June-2011
IETF LC End Date: 13-July-2011
IESG Telechat

Summary: not ready, but issues are not difficult to address

Major issues:

4.3.  Suite B IKEv2 Authentication

    If configured at a minimum level of security of 128 bits, a system
    MUST use either ECDSA-256 or ECDSA-384 for IKE authentication.  It
    is allowable for one party to authenticate with ECDSA-256 and the
    other party to authenticate with ECDSA-384.  This flexibility will
    allow interoperability between an initiator and a responder that
    have different sizes of ECDSA authentication keys.

    Initiators and responders in a system configured at a minimum level
    of security of 128 bits MUST be able to verify ECDSA-256 signatures
    and SHOULD be able to verify ECDSA-384 signatures.

The last SHOULD seems to mean that at the minimum level of security of 
128 bits
it is possible to have a situation when a responder might be unable
to verify ECDSA-384 signatures used by an initiator.

Is this truly desirable?


5.  Suite B Security Associations (SAs) for IKEv2 and IPsec

    An initiator in a system configured at a minimum level of security
    of 128 bits MUST offer one or more of the four suites:
    Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
    Suite-B-GMAC-256 [RFC4869bis].  Suite-B-GCM-128 and
    Suite-B-GMAC-128, if offered, must appear in the IKEv2 and IPsec SA
    payloads before any offerings of Suite-B-GCM-256 and
    Suite-B-GMAC-256.

Does this mean that the responder needs to support all 4?
I think it does (or otherwise there is a chance of non interoperability),
but it would be better to state that explicitly.

    A responder configured in a system at a minimum level of security
    of 128 bits SHOULD accept the first Suite B UI suite offered by the

Is this a new requirement in this document, or is this repeating a 
general requirement stated in another document? If the latter, a 
reference is needed here, ideally accompanied by some text stating that 
the requirement comes from another document.

Similar text later in the same section.

    initiator that it can accommodate.  If none of the four suites are
    offered, the responder MUST return a Notify payload with the error
    "NO_PROPOSAL_CHOSEN".

8.  Additional Requirements

    Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use
    IKEv1.  However, to accommodate backward compatibility, a Suite B
    IPsec compliant system can be configured to use IKEv1 so long as only
    IKEv2 is used between a Suite B compliant initiator and responder.

You lost me here. Can you please explain what is the meaning of
the second sentence?

    The administrative user interface, (UI), for a system that conforms
    to this profile MUST allow the operator to specify a single suite.
    If only one suite is specified in the administrative UI, the IKEv2
    implementation MUST only offer algorithms for that one suite.

This requirement is unusual, because IETF documents rarely have 
requirements on UIs. Can you please elaborate what is this trying to 
achieve?


Minor issues:

3.  Suite B Requirements

       Curve        NIST name       SECG name   IANA assigned DH group #
       -----------------------------------------------------------------
       P-256       nistp256        secp256r1               19
       P-384       nistp384        secp384r1               20

This doesn't tell where to look for the IANA assigned DH group.
An Informative reference would be nice.

10.  IANA Considerations

    TBD.

I think this needs to be replaced with a statement saying that this 
document doesn't require any new actions from IANA, because all 
algorithm are already registered in RFCs referenced by this document.


idnits 2.12.12 reports:

   Miscellaneous warnings:
 
----------------------------------------------------------------------------

   -- The document has a disclaimer for pre-RFC5378 work, but was first
      submitted on or after 10 November 2008.  Does it really need the
      disclaimer?

Please double check that that is intentional.


Nits/editorial comments:

7.  Generating Keying Material for the IKE SA

    IKEv2, [RFC5996], allows for the reuse of Diffie-Hellman ephemeral
    keys. Section 5.6.4.3 of NIST SP800-56A states that an ephemeral
    private key MUST be used in exactly one key establishment
    transaction and MUST be zeroized after its use.

Is "zeroized" a correct verb?