IKEv2: SA attribute processing rules

["William Dixon" <wdixon@windows.microsoft.com>]

I was researching the exact way to handle additional MODP groups in
IKEv1 and realized that IKEv1 was unclear on how to handle additional
transform attribute types in the SA payload that you didn't recognize,
including the private use range values.  IKEv2 does not yet clarify this
in section 5.3.  And then I found a number of other issues with IKEv2's
current treatment of SA attribute processing.  Maybe some of these have
been discussed on the list already.  If so, I've missed that discussion.
I just didn't want to lose these thoughts while they were present.

The following topics are addressed in this mail for IKEv2:

A.) How to handle unrecognized attribute types
B.) Gap in private use range
C.) Regarding how we indicate "mutually consenting parties" - vendor ID
can't be used.
D.) No real clarification on SA attribute handling
E.) Implied requirement for 1536, should be 2048 or 3072. 
F.) Be clear what fails the negotiation and what doesn't.

My impression is that the current IKEv2 draft is missing it's goal of
making IKE easier to analyze and implement by not clearly describing how
to negotiate (what it means to include, omit, and accept) each SA
attribute and the selection/ordering of these attributes in terms of
having a predictable outcome when processing two lists of preferences.
To implement IKEv2 SA attribute processing correctly, you must now
analyze text in 4 documents: IKEv2, IKEv1, ISAKMP, and the DOI, and
still guess whether the peer is going to fail the negotiation, and guess
at what the outcome will be.

--------------------

A.) How to handle unrecognized attribute types, I suggest text:
"An unrecognized transform attribute type MUST be ignored.  If no SA
attributes are recognized, then the negotiation MUST fail."

B.) Gap in private use range.  Some questions come up from this text:
"values 2-65000 are reserved to IANA. Values 65501-65533 are for private
use among mutually consenting parties."
- did the authors purposely skip the range 65001 through 65500 ?  If so,
I assume this was done to allow implementers of IKEv1 to continue to use
their private identifiers that may have been chosen in the omitted
range.  But it leaves implementers in a weird spot if they do what to
use 65001, which is neither allocated for private use nor assigned to
IANA.

C.) Regarding how we indicate "mutually consenting parties".  Common
practice is to use the vendor-ID, and so we should be clear and say that
this is the method used when administrative configuration permits the
advertisement of such consent.  Section 5.12 Vendor ID discussion talks
about this, but note that it prohibits making assumptions on what the
peer may accept, and mandates that the initiator always know what the
peer is willing to accept before sending it private use ranges.
However, this prohibits the use of private use ranges in the SA
attributes...:

IKEv2 draft-03 current text:
"The Vendor ID payload is not an announcement from the sender that it
   will send private payload types but rather an announcement of the
   sort of private payloads it is willing to accept. The implementation
   sending the Vendor ID MUST not make any assumptions about private
   payloads that it may send unless a Vendor ID of like stature is
   received as well. "

D.) No real clarification on SA attribute handling.  I'm surprised that
we are not taking the opportunity in IKEv2 to clean up the confusion
about the IKEv1 SA attributes having different definitions for Phase I
and Phase 2.  Phase 1 is defined in the IKEv1 appendix A.  Phase 2 is
defined in the DOI with different SA attribute type numbers.  For
example, the DH Group Description is defined to be 4 in Phase I, but 3
in Phase 2 in the DOI (unless you realize that you're using quick mode
PFS and the group is really the same as in Phase 1...)  I don't see a
reason why the IKEv2 can't fix this to have one list of attribute types.
I haven't studied this enough to see if IKEv2 solved the problem of
being able to negotiate PFS, but it should.

My impression is that the current IKEv2 draft is missing it's goal of
making IKE easier to analyze and implement by not clearly describing how
to negotiate (what it means to include, omit, and accept) each SA
attribute and the ordering of these attributes in terms of having a
predictable outcome when processing two lists of preferences.  To
implement IKEv2 SA attribute processing correctly, you must now analyze
text in 4 documents: IKEv2, IKEv1, ISAKMP, and the DOI, and still guess
whether the peer is going to fail the negotiation, and guess at what the
outcome will be.

E.) Implied requirement for 1536, should be 2048 or 3072.  The example
suite given suggests that DH1536 would be a "default".  It doesn't say
whether it's a MUST support.  I think we need something greater than
DH1024, but why does IKEv2 need to specify it ?  Given the strength
calculation in Tero's MODP draft, DH1536 supports by one calculation
only 90bits entropy, which is still much less than 3DES ~112bits entropy
(from Schneier's Applied Cryptography) which is included in that suite,
and insuffient for keying 128bit AES.  So DH2048 or DH3072 should be the
choice to ensure IKE DH is not the weakest point, and thus force the
attack to the 3DES keys, which of course is being rekeyed far more often
than the DH is generated in most cases.

F.) Be clear what fails the negotiation and what doesn't.  When that
same section talks about Reserved-MBZ: "a proposal containing a non-zero
value MUST NOT be accepted.", it's not clear whether this means fail the
negotiation if it isn't, or ignore the value. 

>From earlier research, and practical experience, we need to be clear
about what specific conditions fail the negotiation, and absent those
specific conditions, any other violation of MUST does not fail the
negotiation.  Yes, the implementer's rule of "be liberal in what we
accept" is true, but at the cost of accepting an RFC MUST violation ?

Thx,
Wm