In message <20041107132746.6E9A81C063@coconut.itojun.org>,
Jun-ichiro itojun Hagino writes:


I too have implemented an Microsoft Windows-2000-compatible GSSAPI
extension to IKE, which may be why Jason asked me to comment.  For
now, just a quick response:



[.. Jason Thorpe writes.. ]

>> - While the GSS-API-for-IKE draft specifies "Unicode" (for Windows 
>> compatibility), this was unfortunately a little too vague.  Currently, 

I cannot agree with Jason. In context, and at the time of writing of
the draft, it seemed abundantly clear that the document intends UCS-2.
(The only possible ambiguity in "Unicode" would be to include UCS-4).

It will come as no suprise to any well-informed reader that UCS-2
little-endian is absoutely required for Microsoft compatibility.
Since MS interoperability was the intent of the document, a UCS-2le
encoding should be ``taken as read'' for ``Unicode''.

That said: my understanding is that a UCS-2 encoding is flatly
incompatible with the DER rules for the OIDs used for Kerberos
principals; the ANS.1 encoding of KRB5 principals is such that a UTF-8
encoding is the only permissible ``on-the-wire'' extension of
ASCII/ISO 646.  (Somewhat heated statements by the usual MIT-Kerberos
suspects to that effect can be found via a search engine. Or at least,
they could a couple of years ago.)

Therefore, if the I-D was to be rescusitated and progress down the
IETF standards track (and the "private use" handshake and payload
values be replaced with public IANA-assigned values), it should
specify a UTF-8 encoding of principal names --- with a revised
parameter, and with a note requiring backwards-compatibility with the
extant Microsoft UCS2 encoding.


If (dim) memory serves, I discussed the issue with Brian Swander,
suggested the above approach, and Brian agreed to my suggestion.  It
should probably be done afresh, if anyone cares to write an I-D
specifying GSSAPI authentication for IKEv2.


>	will you comment on it to authors of the offending internet draft?
>	from the current situation, using UTF16-LE (just like MS) might be an
>	mistake.  

That's an downright *stupid* idea. The expired I-D under discussion
existed in large part to document how to interoperate with Microsoft
implementations.  That's why the expired I-D documented the "private
use" values chosen by the Microsoft implementation.


>the document is vague so we don't know what is the right
>	thing to do.

Oh, bollocks. Anyone with half a brain can see that the only ``right
thing to do'' for interoperability with Microsoft's ``private use''
values in conjunction with Microsoft's private Vendor-ID, is to in
fact be interoperable with the Microsoft implemetation. In this case,
that means using UCS-2LE.  See also the comments in the expired I-D
about the IETF allocating new, public IDs, should the I-D be promoted
to the standards track. (That, imho, would be the correct point to
switch to a UTF-8 encoding of principal names).

Itojun, you really should read draft-ietf-ipsec-isakmp-gss-auth-07.txt.