Obtaining credentials in GSSAPI/GS2 (was: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt)

[Simon Josefsson <jas@xxxxxxxxxxx>]

Simon Josefsson <jas@xxxxxxxxxxx> writes:

>>   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>>   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>>   GSS-API mechanism for which this SASL mechanism is registered
>> (*). Servers MAY use
>>   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>>   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>>   for the server's principal name(s) (**) and the
>>   GSS-API mechanism for which this SASL mechanism is registered.
>>
>>   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>>   GSS-API mechanism as an input parameter.  The OID set can be created
>>   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>>   be freed by calling the GSS_Release_oid_set.
>>
>>   (**) - Use of server's principal names having
>>   GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
>>   where "service" is the service name specified in the protocol's
>>   profile, is RECOMMENDED.
>>
>>   Upon successful establishment of the security context (i.e.
>>   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>>   verify that the negotiated GSS-API mechanism is indeed the registered
>>   one.  This is done by examining the value of the mech_type
>>   parameter returned from the GSS_Accept_sec_context call.  If the
>>   value differ SASL authentication MUST be aborted.
>>
>> (I've edited the text not to reference Kerberos)
>
> Thanks, this seems good for GS2, but I wonder about the value of this
> in GSSAPI.  It seems to make my RFC 2222 conforming implementation
> violate the first SHOULD.  I'll bring this up separately...

After re-reading RFC 2222, it seems that the old document was
under-specified in this area -- it doesn't discuss how servers should
obtain the credentials at all.  However, it may be reasonable to
assume that the RFC 2222 server side should be similar to the RFC 2222
client side, which implies using GSS_Import_name, and thus breaking
the SHOULD above about using GSS_C_NO_NAME.  Both Cyrus SASL and GNU
SASL work that way, and thus break the SHOULD above.

I wonder whether any existing implementations of "GSSAPI" will be
updated to follow the above SHOULD.  Given the deployed working base,
and no incentive to update GSSAPI beyond RFC 2222, I kind of doubt it.

/Simon