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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Jul 2011 21:27:39 +0100

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:[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
>
>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 :-).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Jul 2011 14:24:45 -0700

I'll jump in wearing my shepherd hat.

On Jul 4, 2011, at 1:27 PM, Alexey Melnikov wrote:
> How are you planning to achieve interoperability if one endpoint can use a mechanism which the other end is not required to support?

The draft assures interoperability between peers that are both at a minimum level (minLOS) of security of 128 bits. It also assures interoperability between peers that are at a minLOS of 192 bits. It has a SHOULD-level wording that would assure interoperability for systems that have different minLOSs.

There are policy reasons why a system might only handle one security level; however, for systems that don't have such policy restrictions, the draft says that they SHOULD handle the other level.

This is a conscious decision on the part of the authors, one that has been discussed within the authors' organizations. In my mind, it is better that they are being honest about it instead of having requirements that we know will silently ignored by some policies.

>> 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.
>> 
> Why is this a SHOULD and not a MUST, i.e. what are the possible reasons for not selecting the first offered mechanism?

A system at minLOS_128 might also be able to support 192-bit security and have a policy of preferring it; the initiator might offer them in the reverse order for some reason. This SHOULD allows the responder to achieve the higher security even if the initiator didn't prefer it.

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

RFC 4308, "Cryptographic Suites for IPsec", is unusual, and is an exception to that "rarely". A small but significant number of IPsec VPN vendors have followed it.

--Paul Hoffman

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Jul 2011 21:37:04 +0100

Hi Kelley,

>why it's a SHOULD and not a MUST.
  [...]

>Suite-B-GMAC-256." To the beginning of the following paragraph.
After seeing Paul's reply and thinking a bit more about this issue I 
think your additional text is fine. As there are MUST-support 
requirements, that is sufficient for interoperability.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Jul 2011 19:43:26 +0100

Hi Paul,

>This is a conscious decision on the part of the authors, one that has been discussed within the authors' organizations. In my mind, it is better that they are being honest about it instead of having…
Ok, I withdraw my original comment on this text.

>A system at minLOS_128 might also be able to support 192-bit security and have a policy of preferring it; the initiator might offer them in the reverse order for some reason. This SHOULD allows the…
After thinking a bit more about that: we had a similar debate in the 
SASL WG and decided that the responder has no reason to trust the order 
suggested by the initiator. Why is this SHOULD important at all? I would 
feel more comfortable if the whole sentence is deleted or restated not 
to use RFC 2119 keywords.

Ok.