Re: Remaining open issues for RFC-2401bis

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Tue, Mar 23, 2004 at 08:10:09AM -0800, Paul Hoffman / VPNC wrote:
> At 9:35 PM -0500 3/22/04, Stephen Kent wrote:
> >Since all ID's sent via IKE are used for access control, it seems 
> >reasonable to assume that, in general, people have interacted with a 
> >management interface to enter these IDs.
> 
> Fully agree.
> 
> > So, unless there is a need to transmit an arbitrary octet string 
> >for ID purposes, it would be more appropriate to constrain this to 
> >something that a user has a good chance of getting right.
> 
> Also fully agree.

Note that SSH users manage to used public keys for authorization even
though the bits in those keys are almost meaningless to them.

My point is that users can handle items that look like gibberish.  Oh, I
know, it ain't pretty, and we'd all rather use names when interacting
with access control management interfaces, but that does not mean that
access control with opaque IDs can't be done.

> >The IKE v2 specs says (page 55)
> >
> >	    "An opaque octet stream which may be used to pass an account
> >            name or to pass vendor-specific information necessary to do
> >            certain proprietary types of identification."
> >
> >This hardly sounds like an arbitrary byte string.
> 
> Fully disagree. "opaque octet stream" sounds exactly like "arbitrary 
> byte string" to me.

Yes.  Of course, presumably initiators can figure out what to use as
ID_KEY_ID values, and presumbaly they can told what to use much the same
way that access control by ID_KEY_ID can be managed.

But it would be nice if there was a simple default content type for
ID_KEY_ID, such as, say, the public key of the cert.  This would bring
the "power" (forgive me) of secure shell hostkeys/pubkey userauth to
IPsec.

[...]
> > So, my suggestion is that we be a bit more restrictive with the 
> >supported name types. In that spirit, if we need to keep this as an 
> >arbitrary byte string, we ought to provide some rationale for that 
> >decision.
> 
> Also fully agree. I'm happy if we change this field in IKEV to "UTF-8 
> text string" (changing it to ASCII is not a reasonable option). 
> However, I'm not happy with leaving IKEv2 alone and having that 
> requirement (or, even worse, that assumption) come in 2401bis. If 
> IKEv2 is left as it is, 2401bit should not change the interpretation 
> of the field. Otherwise, boxes that follow 2401bis might fall over 
> when handed a non-UTF-8 octet stream.

Agreed, except that I think ID_KEY_ID should stay an octet string.

Nico
--