Re: Obtaining credentials in GSSAPI/GS2

[Simon Josefsson <jas@xxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Tue, Oct 03, 2006 at 11:27:50AM +0200, Simon Josefsson wrote:
>> 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.
>
> Thus the new text in GS1.  Please copy it.

I have, with some modifications (see other posts).

>>                                 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.
>
> It may seem reasonable, but it isn't useful.

Why not?  Popular implementations still do things this way.  If there
is anything wrong with that behaviour, I think it should be brought up
in the "Changes since RFC 2222" section.

>  See the archives.

Pointers would be appreciated...  Is this related to non-hostbased
names?

>> 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.
>
> SHOULD is not MUST.

Understood, but violating a SHOULD typically require a good argument.
I don't see one here.

It seems to me that this change could potentially cause interop
problems with RFC 2222 "GSSAPI" implementations and gssapi-08 draft
"GSSAPI" implementations.  For example, it is not clear that
GSS_C_NO_NAME will lead to using the same server name as using
GSS_Acquire_cred with a server name derived by GSS_Import_name from
"service@hostname".

/Simon