Re: Remaining open issues for RFC-2401bis

[Stephen Kent <kent@bbn.com>]

At 2:00 PM +0200 3/23/04, Tero Kivinen wrote:
>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).

so, the problem we have is that the same ID type 
is defined to have two different uses: an account 
name, for which an IA5 or UTF-8 string would be 
appropriate, or an arbitrary byte sting, for 
which no further encoding is appropriate. I would 
be happy if we choose ONE of these two, but 
having both listed is a recipe for 
non-interoperability.

As for using a random number as an ID, note that 
this may not play well with the PAD description 
that we published.

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

I agree that IF the intent is to send an 
arbitrary byte string for a vendor-specific 
purpose, then UTF-8 encoding is inappropriate. 
However, if the intent is to send a user account 
name, then such encoding is appropriate. That's 
why I suggest that we disentangle these two 
different uses for the field.

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

I disagree. There is no reason to believe that 
there will be an appropriate management interface 
to allow for easy entry of a UTF-8 account name 
by a user or admin if the only requirement is to 
support binary values for this field.

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

same argument as above, For interoperability we 
want to ensure that any ID form that either end 
may use will be easy to enter and manage by 
everyone. Unless we have some good reason to 
believe that EDI Part names, and X.400 addresses 
are appropriate ID forms for IPsec, then  we 
ought not provide a means to carry them, since 
such carriage should be matched by a requirement 
for a management interface for them in every 
IPsec implementation.

Flexibility is not free if we want 
interoperability at the same time. If we make 
provision for carriage of arbitrary strings as 
IDs in IKEv2 mandatory, then we have a 
responsibility to ensure that IPsec 
implementations have a means to make use of them 
when the arrive. Otherwise we create 
opportunities for non-interopeability.

Steve