Hi Paul,
Paul Hoffman wrote:
I'll jump in wearing my shepherd hat.
On Jul 4, 2011, at 1:27 PM, Alexey Melnikov wrote:
How are you planning to achieve interoperability if one endpoint can use a
mechanism which the other end is not required to support?
The draft assures interoperability between peers that are both at a minimum
level (minLOS) of security of 128 bits. It also assures interoperability
between peers that are at a minLOS of 192 bits. It has a SHOULD-level wording
that would assure interoperability for systems that have different minLOSs.
There are policy reasons why a system might only handle one security level;
however, for systems that don't have such policy restrictions, the draft says
that they SHOULD handle the other level.
This is a conscious decision on the part of the authors, one that has been
discussed within the authors' organizations. In my mind, it is better that they
are being honest about it instead of having requirements that we know will
silently ignored by some policies.
Ok, I withdraw my original comment on this text.
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?
A system at minLOS_128 might also be able to support 192-bit security and have
a policy of preferring it; the initiator might offer them in the reverse order
for some reason. This SHOULD allows the responder to achieve the higher
security even if the initiator didn't prefer it.
After thinking a bit more about that: we had a similar debate in the
SASL WG and decided that the responder has no reason to trust the order
suggested by the initiator. Why is this SHOULD important at all? I would
feel more comfortable if the whole sentence is deleted or restated not
to use RFC 2119 keywords.
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?
RFC 4308, "Cryptographic Suites for IPsec", is unusual, and is an exception to that
"rarely". A small but significant number of IPsec VPN vendors have followed it.
Ok.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
