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?
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
