RE: Remaining open issues for RFC-2401bis

["Charlie Kaufman" <charliek@microsoft.com>]

---On Wednesday, March 24, 2004 6:53 AM, Steve Kent Wrote:
>
>>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.
>
>neither do I. I did not go back to IKEv1 to see how the ID type was
defined >there, since the focus of 2401bis is IKEv2, but your point is
well taken. >If the WG is comfortable changing the dscriptipn back to
what it was in >IKEv1, then I agree that this is an arbitrary,
potentially binary value, >and my suggestion re human readable,
character string encoding would not be >relevant.

I can answer the 'why' question, though I don't know whether this will
help in the debate.

When copying the text from IKEv1 describing this field, I was confused
and asked 'what would people do with this field really'. The answer I
got was that they would likely put an account name or some such there,
so I added that text by way of a hint to the reader. It was not my
intent to change the definition of the field.

In my opinion, leaving it an opaque octet stream is the right thing to
do. We could make the spec more clear by making it explicit that account
name is only an example. We could make the spec more precise but less
clear by going back to the IKEv1 wording. I didn't think anyone could be
confused by the current wording, but I clearly underestimated the
creativity of the audience.

We could add yet another ID Type option for UTF-8 string, but does
anyone actually have a use for it?

Currently, the spec says that implementations MUST accept ID_KEY_ID
types, but does not say what values MUST be configurable. One could
interpret that as requiring an administrative interface that allows
entry of arbitrary binary values. If so, and if people don't like that,
I would propose removing the requirement that implementations MUST
accept the type rather than trying to restrict how the field could be
used.

	--Charlie