Re: uw-imapd gssapi support and heimdal

[Assar Westerlund <assar@sics.se>]

Aidan Cully <aidan@kublai.com> writes:
> As someone else mentioned, gss_nt_service_name seems to be undefined
> to heimdal, but looks functionally equivalent to
> GSS_C_NT_HOSTBASED_SERVICE.  I think these OIDs are transmitted over
> the network, so it's possible that an arbitrary krb5 client won't work
> with your (arguably more correct) krb5 imap server, if all you do is
> replace gss_nt_service_name with GSS_C_NT_HOSTBASED_SERVICE, since
> gss_nt_service_name is not encoded in the same way as
> GSS_C_NT_HOSTBASED_SERVICE.  The MIT encoding is:
>  {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
>               "\x01\x02\x01\x04"},
> corresponding to the following definition:
>  * service_name:
>  *      iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2)
>  *      generic(1) service_name(4) = 1.2.840.113554.1.2.1.4

It's rather complicated.

Once upon a time, in RFC1964, it was said that the oid should be:

{iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) service_name(4)}

also known as GSS_C_NT_HOSTBASED_SERVICE

In rfc2078 (gss-api v2) it got changed to:

   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
   2(gss-host-based-services)}

aka GSS_C_NT_HOSTBASED_SERVICE

And in rfc2743 (gss-api v2 update 1) it was changed back to the old
value (with the same symbolic name).

We will update the gssapi library in Heimdal to use the new^H^H^Hold
OID.

/assar