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

Re: Remaining open issues for RFC-2401bis



At 8:22 PM +0200 3/23/04, Tero Kivinen wrote:
>Stephen Kent writes:
>>  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
>
>There is no text in the IKEv1 defining it to be account name. IKEv1
>defined it to be "an opaque byte stream which may be used to pass
>vendor-specific information necessary to identify which pre- shared
>key should be used to authenticate Aggressive mode negotiations."
>
>This account name thing was added in the IKEv2, and I do not know why
>it was added.

neither do I. I did not go back to IKEv1 to see 
how the ID type was defined there, since the 
focus of 2401bis is IKEv2, but your point is well 
taken. If the WG is comfortable changing the 
dscriptipn back to what it was in IKEv1, then I 
agree that this is an arbitrary, potentially 
binary value, and my suggestion re human 
readable, character string encoding would not be 
relevant.

>  > 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.
>
>Do we really need account name? Why cannot be use rfc822 address?
>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 
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.

>  > As for using a random number as an ID, note that this may not play
>>  well with the PAD description that we published.
>
>Why not, after the new ID has been exchanged, both the server and
>client, will simply reconfigure the PAD to include the new ID.

We had no plans to describe the PAD as a database 
that was dynamically reconfigured, but we also 
did not plan to say anything that would prohibit 
this.

>  > 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.
>
>We already have rfc822 address for user account name, why would we
>need separate account name id? The ID_KEY_ID is also defined to be
>something that is NOT matched against anything in the certificates
>etc, it is only matched against the built in policy (i.e. mostly
>usefull in shared-key authentication). In those case the
>bit-comparison is much better.

As noted above, 822 addresses may be OK, but they 
are not ideal as a way to mimic a login ID.

>  > >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.
>
>Why should there interface to allow UTF-8 account names, if the only
>thing the adminstrator is going to use it, is to account names in the
>policy specified format.

I can't parse the above sentence.


>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.  For example, in 802.11 
nets, I have had problems getting the passwords 
that are used as keys to match on routers/access 
points and my Apple computers, precisely because 
the management interfaces were not built to any 
standard.

>  > 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.
>
>If I undertand correctly, the general name is there, because it can be
>matched against the certificate, and in some cases people might have
>setup where they allow you to login if you just happen to have valid
>certificate from that certain CA, and you can use any ID that can be
>found from the certificate as your ID. The pki4ipsec wg is working on
>that issue.

The pki4ipsec WG document that deals with this 
also excludes GN, just as 2401bis has in its 
current draft. Requiring support for GN 
duplicates what we already mandate when we 
require support for DNs, 822 addresses, and IP 
addresses, plus it adds a requirement to support 
names forms like EDI party name and X.400 
addresses. Unless we believe it is appropriate to 
support these additional name forms, not to 
mention to "free form" name types that are part 
of GN, it is a bad idea to call for GN support.

>This issue does not cover ID_KEY_ID, as it will not be in the
>certificates. If we say that ID_KEY_ID is octect string, and
>adminstrators must allow support for any binary string there, then we
>can put configure the system to use ISO 10646 UTF-8 account names,
>uid, Latin-1 account or plain ASCII account names. If the
>implementator is stupid and does not include easy way to enter the ISO
>10646 UTF-8 account names, it does not still affect the
>interoperability, it just makes the configuration harder.

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.

>
>>  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.
>
>If we say it is opaque octect string, and implementationtions MUST
>support any binary data up to 32 bytes in it, it defines exactly an
>interoperable use for the ID_KEY_ID.

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.

Steve