[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remaining open issues for RFC-2401bis
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.
> 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)).
> 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.
> 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.
> >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.
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".
> 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.
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.
> 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.
--
kivinen@safenet-inc.com