Re: Remaining open issues for RFC-2401bis

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> 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 was the main reason why i raised the issue i.e ID_KEY_ID is used
to select pre-shared key and it was defined to be a opaque octet stream
in IKEv1. This in conjunction with a road warrior case where the addresses
are not known a priori, you need to use the information in ID_KEY_ID as
selector. Please see draft-ietf-pana-ipsec-02.txt as an example of how
this ID_KEY_ID is used to carry a session-ID - which is an opaque
octet stream or possibly an UTF8 string carried in an opaque way.

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

Yes, i don't see why this is in conflict with the PAD description in 2401bis.

-mohan

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