Subject: Re: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt

From: "Peck, Michael A" <[email-masked]>
Date: Thu, 26 May 2011 16:01:39 -0400

Dan,

Thanks for your comments.  My responses are below.

Mike Peck

>-----Original Message-----
>From: Dan Harkins [mailto:[email-masked]]
>Sent: Friday, February 11, 2011 3:17 AM
>To: Peck, Michael A
>Cc: [email-masked]
>Subject: Re: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt
>
>
>  Hello,
>
>  I have a couple of comments after a quick read.
>
>  - instead of mentioning vague things like the "Diffie-Hellman common
>    value" and the "x value", I think it would improve the draft to note
>    that the shared result of a successful ECDH exchange will be a point
>    (x,y) on the elliptic curve with x- and y-coordinates that satisfy
>    the equation of the curve.
>
>    Then I think it would be better to say that the the secret used
>    in computation of SKEYSEED is the x-coordinate, treated as an
>    unsigned integer, and represented as an octet string per section 6.2
>    of RFC 6090.

For consistency with RFC 5903, we have decided to keep the text of this document as it currently stands.

>
>  - section 6 of this draft mentions additional requirements. This draft
>    may be necessary but it certainly is not sufficient for an IPsec
>    implementation to claim "Suite B compliance". There are other
>    requirements set out by various US government agencies that dictate
>    whether a particular implementation can be so blessed or not. In
>    other words, this draft is not a complete and authoritative statement
>    on what it means to be "Suite B compliant".

Looks like you mean section 8 of the draft.  This proposed informational RFC when published will be a statement of the requirements for Suite B IPsec implementations.  We acknowledge that procurements can add additional requirements, but they will not contradict the IPsec RFCs, Suite B Certificate and CRL Profile (RFC 5759), or this document.  We don't believe any additional text is required.

>
>    That being the case, the following statement does not seem technical
>    and, while it may be true when considering the other requirements
>    for "Suite B compliance" (that come out of US government agencies),
>    seems out-of-place and unnecessary here in an IETF document: "Suite
>    B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1."
>
>    The various US government agencies that deem "Suite B compliance"
>    may forbid IKEv1 but it does not seem to be reason for an IETF
>    document to forbid an IKEv1 implementation from deciding to use
>    P-256 (P-384) with ECDH and ECDSA, and SHA256 (SHA384) and, in all
>    other respects, be compliant with this draft. I feel the language in
>    the draft is too restrictive and suggest it be removed (from section
>    6 and similar wording in section 1). "IKE" is referred to in other
>    places in the draft. Just leave it at that and leave the statements
>    of what it means to have "Suite B compliance" to the agency(-ies)
>    that actually do that.

We have nothing against nor are we preventing IPsec implementations from supporting IKEv1 and using Suite B algorithms.  However, that would not be Suite B compliant.  
The second sentence of this paragraph from section 8 may address your concern:

   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.

We don't believe any additional text is required here.

>
>  regards,
>
>  Dan.
>
>On Thu, February 10, 2011 11:21 am, Peck, Michael A wrote:
>> We've submitted draft-burgin-ipsec-suiteb-profile-00.txt, Suite B Profile
>> for IPsec, and would appreciate any comments.
>>
>> The draft should be read in conjunction with draft-law-rfc4869bis-01.txt
>> (Suite B Cryptographic Suites for IPsec), which has been submitted and
>> should be available shortly.
>>
>> The new RFC4869bis -01 draft removes the authentication requirements
>that
>> were previously in its IPsec cryptographic suite definitions.  Instead,
>> revised authentication requirements have been incorporated into the Suite
>> B Profile for IPsec draft.
>>
>> Thanks,
>> Mike Peck
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
>> Sean Turner
>> Sent: Thursday, February 10, 2011 12:42 PM
>> To: [email-masked]
>> Subject: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt
>>
>> This might be of interest to some on this list.
>>
>> spt
>>
>> -------- Original Message --------
>> Subject: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt
>> Date: Thu, 10 Feb 2011 09:00:01 -0800
>> From: [email-masked]
>> Reply-To: [email-masked]
>> To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : Suite B Profile for Internet Protocol Security (IPsec)
>> 	Author(s)       : K. Burgin, M. Peck
>> 	Filename        : draft-burgin-ipsec-suiteb-profile-00.txt
>> 	Pages           : 10
>> 	Date            : 2011-02-10
>>
>> The United States Government has published guidelines for "NSA
>> Suite B Cryptography" dated July, 2005, which defines cryptographic
>> algorithm policy for national security applications.  This document
>> specifies the conventions for using Suite B cryptography in IP
>> Security (IPsec).
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-burgin-ipsec-suiteb-profile-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>