| Subject: | gss_accept_sec_context() SPNEGO-wrapped src_name interacts badly with gss_localname() |
After successfully establishing a SPNEGO context,
gss_accept_sec_context() returns GSS_S_COMPLETE to the caller with
*mech_type set to the underlying mech OID (not SPNEGO) and *src_name
set to a union name containing a SPNEGO MN. (SPNEGO just stores a
union name as its internal name, so the mech_name field inside the
mechglue's union name is another union name containing an MN for the
underlying mech.)
For the most part this inconsistency is invisible to the caller.
gss_display_name(), gss_inquire_name(), gss_export_name(), and
gss_get_name_attribute() will all be passed through by SPNEGO. Even
the mech_MN reported by gss_inquire_name() will be the underlying
mech.
gss_localname() (based on the Solaris gssd_pname_to_uid()) accepts a
mech parameter--presumably the intent is to allow the caller to ask
for the local name of a non-MN. If the caller provides the mech
returned by gss_accept_sec_context(), the mechglue will notice the
mismatch and will attempt to re-canonicalize the name for the
underlying mech; the conversion process might lose some information
about the name. (As an example, while the mechglue tries to preserve
name attributes across the conversion, the mech may not accept the
gss_set_name_attribute() calls. This was observed with the EAP
mechanism in
https://github.com/modauthgssapi/mod_auth_gssapi/pull/195 .)
Also, SPNEGO doesn't currently implement a passthrough for
gss_localname(), so even if the caller doesn't pass a mech OID,
SPNEGO will force the mechglue to fall back to attributes for getting
the local name.
The mechglue gss_accept_sec_context() has a special case for
*delegated_cred_handle: if the mech returns a different actual_mech
than the mech's own OID, gss_accept_context() will assume that the
delegated cred handle is a union cred and won't wrap it. We could do
the same for *src_name.
Nico suggests adding explicit unwrapping functions to the SPI (here
is a name/context/cred; give me the underlying union
name/context/cred or fail if it's not a simple wrapping). If we did
that then we wouldn't be making as many assumptions about mech
implementations which return actual_mech values different from their
own OIDs, at the expense of more code.
gss_accept_sec_context() returns GSS_S_COMPLETE to the caller with
*mech_type set to the underlying mech OID (not SPNEGO) and *src_name
set to a union name containing a SPNEGO MN. (SPNEGO just stores a
union name as its internal name, so the mech_name field inside the
mechglue's union name is another union name containing an MN for the
underlying mech.)
For the most part this inconsistency is invisible to the caller.
gss_display_name(), gss_inquire_name(), gss_export_name(), and
gss_get_name_attribute() will all be passed through by SPNEGO. Even
the mech_MN reported by gss_inquire_name() will be the underlying
mech.
gss_localname() (based on the Solaris gssd_pname_to_uid()) accepts a
mech parameter--presumably the intent is to allow the caller to ask
for the local name of a non-MN. If the caller provides the mech
returned by gss_accept_sec_context(), the mechglue will notice the
mismatch and will attempt to re-canonicalize the name for the
underlying mech; the conversion process might lose some information
about the name. (As an example, while the mechglue tries to preserve
name attributes across the conversion, the mech may not accept the
gss_set_name_attribute() calls. This was observed with the EAP
mechanism in
https://github.com/modauthgssapi/mod_auth_gssapi/pull/195 .)
Also, SPNEGO doesn't currently implement a passthrough for
gss_localname(), so even if the caller doesn't pass a mech OID,
SPNEGO will force the mechglue to fall back to attributes for getting
the local name.
The mechglue gss_accept_sec_context() has a special case for
*delegated_cred_handle: if the mech returns a different actual_mech
than the mech's own OID, gss_accept_context() will assume that the
delegated cred handle is a union cred and won't wrap it. We could do
the same for *src_name.
Nico suggests adding explicit unwrapping functions to the SPI (here
is a name/context/cred; give me the underlying union
name/context/cred or fail if it's not a simple wrapping). If we did
that then we wouldn't be making as many assumptions about mech
implementations which return actual_mech values different from their
own OIDs, at the expense of more code.