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

Re: Remaining open issues for RFC-2401bis



Mohan,

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

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

Steve