Re: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt

[Brian Korver <briank@briank.com>]

Theodore Ts'o wrote:
> 
> Charlie Kaufman has released the next version of IKEv2
> (draft-ietf-ipsec-ikev2-05.txt) and we are slowly but surely getting
> closer to completion.  Many thanks to Charlie and those who
> contributed text, ideas, and bug fixes to this new version of the
> ikev2 I-D.
> 
> At the time when Charlie began his revisions to produce the 05 I-D,
> there were still a few open issues.  In the meantime, some additional
> issues have opened up, including the discussion between Tero, Francis,
> and Radia regarding address management and whether IKE v2 adequately
> handles NAT traversal (particularly in transport mode).  Furthermore,
> ikev2-05 has changed significantly and has much new material to
> address various concerns addressed by those on the list, including the
> addition of the agreed-upon handling of legacy authentication, more
> explicit specifications about when the CERT and CERTREQ packets much
> be sent and how they should be handled, the addition of crypto suites,
> and so on.
[snip]

Ted,

I have a couple of problems with the latest CERT and CERTREQ sections.

Sections 1.2 and 3.6:  "If multiple certificates are sent, the first
certificate MUST contain the public key used to sign the AUTH payload."
I've heard people ask for this from time to time, but as an implementor
I prefer the unordered "bucket of certificates" that we usually have.
What motivates this change from IKEv1?  Also, I worry that this new
rule means that it won't be possible to send 2 EE certificates, for
instance to handle expiration rollover.  

Section 3.7:  Why has the contents of the CERTREQ payload been changed
from sending the DN to the SHA-1 hash of public keys?  This wasn't broken
in IKEv1, so what motivates this change?  Yes, DNs are variable size, but
they're a lot more useful for debugging/diagnostics than SHA-1 hashes are.
I don't have any problem with adding an additional "hash" type, but let's
not remove our ability to requests certs by CA DN.

Section 3.7 (again):  We need to be able to request more than just
signature certificates, CRLs being the most obvious example.  This 
absolutely needs to be fixed.

-brian
briank@briank.com