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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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.

>                                 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.  See the archives.

> 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.

Nico
--