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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Jun 2011 23:20:59 +0100

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?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Jun 2011 16:00:51 +0100

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

This was a bit harsh/unclear. I meant:

    This draft is on the right track but has open issues, described in the review.

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Tue, 28 Jun 2011 11:05:02 -0400

Thank you for the review. Comments inline below, noted with [kwb].

Kelley

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Friday, June 17, 2011 6:21 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Gen-art] Gen-Art Last Call Review:
draft-burgin-ipsec-suiteb-profile-00

Major issues:

Is this truly desirable?

[kwb] Would we like minLOS_128 devices to be able to also support the
192 bit sure, but there might be cases where they simply can't. That's
why it's a SHOULD and not a MUST.

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.

[kwb] I will add "A responder configured in a system at a minimum level
of security of 128 bits MUST support Suite-B-GCM-128 and
Suite-B-GMAC-128 and SHOULD support Suite-B-GCM-256 and
Suite-B-GMAC-256." To the beginning of the following paragraph.

[kwb] These are new, so no reference is given.

    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.

[kwb] This means that the box can talk both IKEv1 and IKEv2 but when
they're talking in "Suite B mode" they can't use IKEv1.

[kwb] It is unusual, but the accompanying draft
(draft-law-rfc4869bis-01) defines Suite B User Interface suites (the
term UI is from RFC 4308) that this draft refers to so this seems like
the appropriate term. From RFC 4308: "These suites may be presented in
the administrative interface of the IPsec system."

Minor issues:

3.  Suite B Requirements

[kwb] Will add "IANA has already registered these DH groups in
[IKEV2IANA]." after the table, and add to Informative References:
[IKEV2IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.

10.  IANA Considerations

    TBD.

[kwb] Will replace "TBD" with "None."

idnits 2.12.12 reports:

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

[kwb] This is intentional since this draft uses text from documents
published before 10 November 2008.

Nits/editorial comments:

[kwb] The terms zeroize, zeroized, zeroizing are used in security
standards (e.g., RFCs 1319-1321, 4949).