Re: IKEv2: SA attribute processing rules

[Charlie_Kaufman@notesdev.ibm.com]

I'm confused by a number of your suggestions... specific responses below:

> 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."

What version of the spec are you reading? I don't think transform
attributes are there anymore. The document does say that
unrecognized payload types MUST be ignored (unless marked
critical). I thought it was clear that unrecognized suite IDs MUST
be ignored, but I added text saying it again.

> 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.

This was just a typo; I fixed it.

> 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...:

You're right; the current text is too restrictive. vendor ID should be
allowed to disambiguate private use numbers.

> 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.

A am mystified as to what you're talking about. It is a goal of the IKEv2
spec that it have no normative references to IKEv1, ISAKMP, or the DOI.
Could you give an example of ambiguity?

> 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.

This has been extensively debated, with no clear resolution. What I think
I heard was that there should be multiple required suites with sizes
ranging from 1024 to 2048. The reason to require more than one is that
if there is a single required suite everyone will tend to use it. If it's
1024, IKEv2 will be criticized as insecure. If it's 2048, IKEv2 will be
criticized for being slow. I'm concerned that if there are multiple
required suites that it will be criticized for being complex. I'm not sure
what to put in the next draft, but I don't expect people to be happy whatever
it is.

> 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.

This means reject/ignore the proposal. The negotiation may still
succeed if there is another acceptable proposal. I have added
text to that effect.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).