Re: Remaining open issues for RFC-2401bis

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >How about using the ID_KEY_ID to send the uid of the unix machine
> >(i.e. the numeric user id, as 16/32 bit number (2/4 octects)).
> 
> If the goal is to match account names precisely, 
> then 822 addresses are not an ideal choice. I 
> also would not suggest the Unix UID, since that 
> is clearly an OS-specific approach. The goal in 

The unix UID was one example of IDs implementators might want to use
for the ID_KEY_ID. 

> access control systems is to provide admins with 
> name forms that mimic the ones that they are 
> otherwise accustomed to dealing with. That's why 
> a user login ID or account name is preferable in 
> many cases.

For example the unix kernel only knows about user IDs, it does not
know about user logi IDs or account names, and there is no way to map
user ID to user name (there might be multiple user names with same
user ID). Because of that if IPsec is used between two unix machines
belonging to the same NIS domain etc (== same UIDs) it would make
perfect sense to use the UID as a ID inside the IKE (when creating per
UID SAs between two hosts).

Again this was simply an example how the ID_KEY_ID can be used. In
some other environment it might be used completely differently.

> >If my account name is Törvelä, I will encode it in the same way
> >in my client and in my server, as they are most likely adminstrated by
> >the same persons. If the adminstrator cannot enter my account name, he
> >will propably say, that your new account name for the VPN use will be
> >"Torvela".
> 
> The client and server may be produced by 
> different vendors, and if only one provides a 
> management interface for UTF-8 ID input, then 
> there is a possibility that it will not be easy 
> to get the two to match.

Yes, but if both ends provides way to enter binary data, it is always
possible to make them match. You simply take the UTF-8 formatted ID
from the server, and configure that in to the client as binary octect
string. No problems with different ways to encode the umlauts etc in
the login name. 

> my experience with 801.11 passwords says 
> otherwise, i.e., it was not possible to configure 
> the access point and my computers to interoperate 
> because of the management interface discrepancies.

And the reason is, that somebody assumed that the password is plain
ASCII, or any text. If they only way to configure it in is the
hex-string or similar, then there would not be problems...

That is exactly the reason I do not like the idea of UTF-8 there. It
requires the implementators to actually do something for that. Quite
often they say, ok, I create this dialog box, which supports any
characters, so it simply matter of the input device if you can enter
the name or not. And if you do not happen to have Japanese input
support installed, there is no way, you can enter the Japanese name.

If we mandate that there must be way to insert ID_KEY_ID as binary
octect string (either in hex or something similar, including NULs),
then we can always enter those names to the system. It might not be
easy, as it might require converting the name to the ISO10646 and then
UTF-8 and then to hex, but it is possible.

Vendors are of course allowed to provide other means to input the
item, like dialog box asking it as string. 

> Agreed. But, then we should not expect this ID 
> type to be used to login/account IDs, since there 
> is a chance that it will be infeasible for many 
> folks to configure such ID types using only a 
> binary representation.

You again assume that vendors will only support exactly one way to
enter the data in. Most of the implementations out there already have
way to specify the shared-secret either in text or in hex, so the
implementators do know how to do it... :-)
-- 
kivinen@safenet-inc.com