Re: Remaining open issues for RFC-2401bis

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 9:35 PM -0500 3/22/04, Stephen Kent wrote:
>Since all ID's sent via IKE are used for access control, it seems 
>reasonable to assume that, in general, people have interacted with a 
>management interface to enter these IDs.

Fully agree.

>  So, unless there is a need to transmit an arbitrary octet string 
>for ID purposes, it would be more appropriate to constrain this to 
>something that a user has a good chance of getting right.

Also fully agree.

>The IKE v2 specs says (page 55)
>
>	    "An opaque octet stream which may be used to pass an account
>             name or to pass vendor-specific information necessary to do
>             certain proprietary types of identification."
>
>This hardly sounds like an arbitrary byte string.

Fully disagree. "opaque octet stream" sounds exactly like "arbitrary 
byte string" to me.

>IKE is very sloppy re choice of IDs, and this has not been fixed in IKEv2.

Fully agree.

>  for example, in addition to explicit support for e-mail addresses, 
>IP addresses, and distinguished names, IOKEv2 calls for support of 
>the general name construct. But, this construct already encompasses 
>all of the preceding name types, plus others that seem very unlikely 
>to ever be of interest in our context, e.g., EDI Party names!

I tried to get this fixed a while back, and was shot down.

>  So, my suggestion is that we be a bit more restrictive with the 
>supported name types. In that spirit, if we need to keep this as an 
>arbitrary byte string, we ought to provide some rationale for that 
>decision.

Also fully agree. I'm happy if we change this field in IKEV to "UTF-8 
text string" (changing it to ASCII is not a reasonable option). 
However, I'm not happy with leaving IKEv2 alone and having that 
requirement (or, even worse, that assumption) come in 2401bis. If 
IKEv2 is left as it is, 2401bit should not change the interpretation 
of the field. Otherwise, boxes that follow 2401bis might fall over 
when handed a non-UTF-8 octet stream.

--Paul Hoffman, Director
--VPN Consortium