In message <200206080011.g580BPT09554@Gregorio.Stanford.EDU>
Jonathan Stone wrotes:

>In message <20020607154511.G11012@dr-evil.shagadelic.org>,
>Jason R Thorpe writes:
>
>>On Fri, Jun 07, 2002 at 05:55:18PM -0400, Ken Hornstein wrote:
>>
>> > One thing that comes to mind is that win2k GSSAPI generally uses SPNEGO,
>> > and I believe Heimdal at that time didn't support it.
>>
>>No, it was definitely using Kerberos ... there was a vendor name
>>string we weren't getting right at the time, as well (but I think
>>I fixed that in racoon -- I can't remember right now :-)

I found a cached copy of draft-ietf-ipsec-isakmp-gss-auth-07.  (No
change from -06; re-issued to keep draft current. An -08 draft expired
in May, but it's been overwritten everywhere by the "draft expired" notice.)


The -06/-07 draft specifies several GSS-based options using the using
"private" namespace:

3.3.1 Authentication Method (IKE)

  GSS-API using Kerberos                65001
  Generic GSS-API                       65002
  GSS-API with SPNEGO                   65003
  GSS-API using SPKM                    65004
 

what I see is 65001.  But here's the rub: the -06 draft clearly states:

   3.2
      GSS-API requires that a client identify the target GSS-API endpoint
      by name.  If the initiator does not already know the GSS-API endpoint
      name of the ISAKMP target, a new Phase 1 attribute can be used to
      exchange endpoint names during the first Main Mode round trip
      (Section 3.2).  Note that these name string are bound to the exchange
      but otherwise unauthenticated.  The GSS-API endpoint names are also
      assumed to be opaque.
   
      For Windows 2000 compatibility, these opaque blobs are encoded as
      unicode strings.  For instance, for machine 'briansw' in domain
      'IPSEC.MICROSOFT.COM', the identity is 'briansw@IPSEC.MICROSOFT.COM'
      (in unicode).  This identity is just a particular example, and it
      should not be assumed that the GSS-API identity is necessarily the
      machine name + domain name.

The "GSS-API identity" is, if not otherwise known, the GIi or GIr.
And, according to the draft, the GIi/GIr must be present for win2k
interoperation.

And it says it again in the Changelog:

   4.2 Changes from -05
   
        o  Specify unicode encoding for opaque endpoint ID's in Section 3
           for Windows 2000 compatibility.
        o  Make endpoint ID exchange in Section 3.2 mandatory for Windows
           2000 compatibility.
        o  Added extra reserved byte proceeding token payload format for
           Windows 2000 compatibility.
        o  Added Vendor ID usage guidelines for Windows 2000 compatibility.
   


Bloody silly, really, since the draft says in sec. 3.2.2 that the
format of these identity name strings is ``private to the underlying
GSS-API mechanism''. What, then, if that `underlying mechanism'
doesn't do UTF-8 encoded Unicode?

Anyway, now I think I can see what fvdl's README.gssapi, and Jason's
messages of a year or so back, were getting at.

But the fvdl/Zembu implementation just doesn't do the Unicode encoding
*at all*, so it's not actually in compliance with the draft.
Equally clearly, it's not going to work with win2k as it stands :-(.


What I'm trying to figure out (haven't had enough morning coffee) is:
If racoon used unicode for on-the-wire GIi/GIr names, but converted them
to ASCII before attempting a gss_import on the names; but (as
required) computed the hash on the Unicode form of the GIr/GIi ---
would it ``just work''?  Isn't that the ``cut-and-paste attack''
that including GII/GIR in the hash is designed to defeat?

Has anyone contacted the I-D authors and asked how the heck this is
supposed to interwork with an Distinguished Encoding Rules-compliant
(see draft-ietf-krb-wg-info-ascii-gen-string-00.txt) GSSAPI using Kerberos?