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 protected]]
Sent: Friday, June 17, 2011 6:21 PM
To: [email protected]
Cc: [email protected]; [email protected]
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 :-).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
