Re: Remaining open issues for RFC-2401bis

[Stephen Kent <kent@bbn.com>]

Paul,

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

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.

IKE is very sloppy re choice of IDs, and this has not been fixed in 
IKEv2. 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! 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.

Steve