[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving forward with IKE V2: A proposal for final edits toikev2-04
Ted,
I have to agree with Paul's observation that he provided a
well-reasoned rationale for each choice for MUST vs. SHOULD for the
cipher suites and these did receive some scrutiny & discussion prior
to his posting to the overall list. Thus any suggested changes to his
list really ought to be accompanied by a similar level of rationale.
Overall, I am comfortable with Paul's list of MUSTs and SHOULDs. I
could be persuaded to add some more MUSTs with regard to things like
AES-CTR for ESP, but I think it is incumbent on you to provide more
rationale rather than "just pick[ing] something."
I also would like to proposed some different text that addresses
Paul's comments re support of private suites, specifically for IKE:
It is likely that IANA will add additional Suite-IDs in the future, and
some users may want to use private suites, especially for IKE where
implementations should be capable of supporting different parameters,
up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD [I'd prefer MUST, but Paul has argued
eloquently for very restrictive criteria for MUST re suites.] include
a management facility that allows specification (by a user or system
administrator) of Diffie-Hellman parameters (the generator, modulus,
and exponent lengths and values) for new IKE Suites. Implementations
SHOULD provide a management interface via which these parameters and
the associated Suite-IDs may be entered (by a user or system
administrator), to enable negotiating such Suites.
All implementations of IKE v2 MUST include a management facility that
enables a user or system administratror to specify the Suite IDs that
are acceptable for use with IKE. Upon receipt of a payload with a
suite ID, the implementation must compare the transmitted suite ID
against those locally configured via the management controls, to
verify that the proposed suite is acceptable based on local policy.
The implementation MUST reject key exchange payloads that are not
authorized by these IKE suite controls.
Also, I would suggest a slight edit to the Appendix B.1 text that
Paul provided:
Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Future
IANA-registered and private use Suite-IDs MAY use Diffie-Hellman groups
that have modulus values and generators that are different than those in
this document or in [ADDGROUP].
I have not reviewed the Identity payload discussion sufficiently to
comment on that part of the discussion at this time. I'll comment on
that next week.
Steve