Subject: Re: racoon, gss-api auth, and win2k IPSec IKE ...
To: Jason R Thorpe <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/08/2002 16:11:08
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
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:
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
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
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?