[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