Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.507 (Entity 5.507)
Subject: gss_accept_sec_context() SPNEGO-wrapped src_name interacts badly
 with gss_localname()
X-RT-Original-Encoding: iso-8859-1
Content-Length: 2248

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.