[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remaining open issues for RFC-2401bis



At 3:36 PM +0200 3/25/04, Tero Kivinen wrote:
>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.

as an example it is fine.

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

I think I'm not communicating well here. As a 
user and for most admin functions, login names 
will be used for access control, nit the internal 
UIDs that the kernel sees. My concern is that if 
we intend to represent character string IDs in an 
ID type, then it behooves us to use a suitably 
restrictive syntax for that purpose. the 
reasoning is that a vendor will offer a 
management interface appropriate for a given 
syntax and we want the management interface to be 
easy for users and admins, not only because it 
makes life easier, but because it helps avoid 
management-induced vulnerabilities.

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

no problme encoding at a low level, but a big problem entering the data.

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

but the point was that vendors acted in what they 
believed was a reasonable way give a lack of 
syntactic direction. hex would be workable, but 
is often harder for a user.when Apple user ASCII, 
I could use a pass phrase as the key. when I had 
to use hex to enter the data, life became much 
harder, and it took several tries to get the same 
data into the access point and each machine. does 
anyone think that's a feature?

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

yes, this makes it harder for implementors, and 
easier for users. offering a GUI for management 
is also harder for implementors and easier for 
users. I think we have to accept the possibility 
that additional effort for implementors is 
sometimes appropriate, if it yields a better user 
interface.

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

yes, possible, but maybe not easy.

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

allowed, yes, required, no. As a user I would 
like to try to make my life easier whenever 
possible.

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

I can't comment on what most vendors do in the 
shared secret case for IPsec implementations. I 
just cited my bad experience in a different but 
equivalent context, and it was not good.

Steve