OpenSolaris

Printable Version Enter a New Search
Bug ID 6817447
Synopsis libgss and various mechs are hiding both the real minor_status and the error token
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kerberosv5_bundled:other
Keywords
Responsible Engineer Glenn Barry
Reported Against
Duplicate Of
Introduced In solaris_8
Commit to Fix snv_125
Fixed In snv_125
Release Fixed solaris_nevada(snv_125)
Related Bugs 6283931 , 6791210 , 6808598 , 6867208 , 6888759
Submit Date 14-March-2009
Last Update Date 7-October-2009
Description
If the underlying security mechanism (e.g. mech_krb5) fails during context acceptance, its minor status is not bubbled up to the GSS-API layer given that the input token to the (k)gss_accept_sec_context() is a SPNEGO context token.

The minor status is somehow set to (uint32_t) -1.  The following unreadable message string is returned by (k)gss_display_status:

Unspecified GSS failure.  Minor code may provide more information\273\335\272\376\312\335\272\376\312\335\272\376\312\335\272\316\372\355\376\274?
I observed that the gss_accept_sec_context() doesn't return an output token if the initiator's time (i.e. a Windows client) is not sync'd with the acceptor's time.

To be compatible with Windows servers, I expect to see something like the following where the krb_blob is set to an error token:
  Security Blob: A1819B308198A0030A0101A10B06092A864882F712010202...
            GSS-API Generic Security Service Application Program Interface
                SPNEGO
                    negTokenTarg
                        negResult: accept-incomplete (1)
                        supportedMech: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                        responseToken: 607E06092A864886F71201020203007E6F306DA003020105...
                        krb5_blob: 607E06092A864886F71201020203007E6F306DA003020105...           <-- expecting an ERROR Token
                            KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            krb5_tok_id: KRB5_ERROR (0x0003)
                            Kerberos KRB-ERROR                                 Pvno: 5
                                MSG Type: KRB-ERROR (30)
                                stime: 2009-04-01 19:16:28 (UTC)
                                susec: 194914
                                error_code: KRB5KRB_AP_ERR_SKEW (37)
                                Realm: W2K3R2.COM
                                Server Name (Service and Host): host/win2003-rc2.w2k3r2.com
                                    Name-type: Service and Host (3)
                                    Name: host
                                    Name: win2003-rc2.w2k3r2.com
                                e-data 

While scanning through the mech_krb5 code (i.e. accept_sec_context.c), mech_krb5 does constructs a krb5 error token in krb5_gss_accept_sec_context (see the call to krb5_mk_error() on line 1145 and line 1160).

The truss output can be found here:
/net/thurso.west/ws2/builds/nl160780/tmpdir/gss_accept_sec_context_wo_errortoken/truss.out

krb5_mk_error() succeeds (on line 4747 and 10068 of the truss.out).  Yet, the gss_accept_sec_context doesn't return an output token of type error.
Work Around
N/A
Comments
N/A