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

[Alexey Melnikov <[e-mail]>]

Hi Kelley,
Thanks for the answers. Some followup questions/comments below.

Burgin, Kelley W. wrote:

>Thank you for the review. Comments inline below, noted with [kwb].
>
>Kelley
>
>-----Original Message-----
>From: Alexey Melnikov [mailto:[e-mail]] 
>Sent: Friday, June 17, 2011 6:21 PM
>To: [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: [Gen-art] Gen-Art Last Call Review:
>draft-burgin-ipsec-suiteb-profile-00
>
>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?
>
>[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.
>
How are you planning to achieve interoperability if one endpoint can use 
a mechanism which the other end is not required to support?

>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.
>
>[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.
>  
>
This is going to have the same interop issue as above.

>    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".
>
>[kwb] These are new, so no reference is given.  
>
Why is this a SHOULD and not a MUST, i.e. what are the possible reasons 
for not selecting the first offered mechanism?

>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?
>
>[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.
>
I suggest you rephrase the 2 sentences to say exactly that. I found the 
current text to be unclear.

>    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?
>
>[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."
>
Ok.

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

>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.
>
>[kwb] Will replace "TBD" with "None."
>
>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.
>
>[kwb] This is intentional since this draft uses text from documents
>published before 10 November 2008.
>  
>
Thanks for checking.

>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?
>
>[kwb] The terms zeroize, zeroized, zeroizing are used in security
>standards (e.g., RFCs 1319-1321, 4949).
>
Ok then :-).