Re: Remaining open issues for RFC-2401bis

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> 	    "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."

Vendor-specific sounds to me like anything I simply like to put there,
including binary. Some uses for this has been proposed to support
total identity protection including active attacks, i.e. where you use
random ID_KEY_ID as your identity, and after you have connection ready
and authenticated from both ends, you run some protocol that will give
you new ID_KEY_ID to be used for the next time (this was mostly
suggested for IKEv1 aggressive mode, where ID's are in clear
otherwise).

For that kind of usage, I see no point why it should restricted to the
ASCII string. 

> This hardly sounds like an arbitrary byte string.

I think arbitrary octect string easier for multiple reasons. If we say
it is text we need to and the encoding to it (ISO 10646 UTF-8?). Doing
that causes unnecessary code on some clients and servers, which might
have the user database in latin-1 format or similar, and now they need
to convert it UTF-8 and back when sending it over the wire. Using
UTF-8 there does not help anything, as those implementations propably
do not know how to convert the strings to normal format (i.e. they do
not know how to convert a + umlauts to ä).

On the other hand the client and server will have common security
domain, which also defines the usernames, and the encoding used for
them, thus it does not cause any problems to encode the Latin-1
username string as binary latin-1 octect stream when sent inside the
IKE ID_KEY_ID. 

> 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 

If the client and server agrees that they will use the EDI Party names
(whatever that is) when identifying the each other, I do not see
problem with that. I do not think every implementation should
implement EDI Party name support though (it is not MUST)...

> 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.
-- 
kivinen@safenet-inc.com