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.
> 
> Let me note, again, that 2401bis assumes IKEv2, in lots of places, so 

But where possible, it should still work with IKEv1.

> I don't think the use of this ID type in IKEv1 is central to this 
> discussion. There have been lots of good arguments why one might 
> choose to view this ID type a just a byte string, and why we might 
> want to add another ID type for conveying login IDs, but references 
> to IKEv1 are not among those good arguments :-)
> 
ID_KEY_ID was used in IKEv1 in a particular way as Tero mentioned
in the other email. One would like that to still work with IKEv2. Please
see the other draft that i mentioned. It is useful to have opaque identifiers
that are established by other means and use it as an ID to select  the
pre-shared key.

> >  > 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.
> 
> I said this MAY be in conflict because there is not mention of PAD 
> entries being dynamically changed as a side effect of an initial IKE 
> exchange.  And, as you may guess, I had not envisioned a context 
> where that would be required. In 2401 we needed to consider dynamic 
> SPD entries to accommodate road warriors. That is no longer the case, 
> because of the SPD cache in the model, and because of the 
> introduction of the PAD. I'm not claiming that there are no reasons 
> to have dynamic PAD entries, but none occurred to us in writing 
> 2401bis.
> 
Ok. So, to accomodate the dynamic creation of PAD entries i.e not through
an user interface, can we still include the ID_KEY_ID as specified in IKEv1 
as a selector and define a new type for login names etc. which would
also be another selector?

thanks
mohan

> Steve