Expired Krb5 TGT prevents GSSAPI from calling SPNEGO plugins

[Adam Bernstein]

_*BACKGROUND*_*:*
VMware vcenter product initial configuration uses a GSSAPI plugin
implementing the Secure Remote Password (SRP) protocol. This is a
"bootstrap" authentication protocol, used to store initial
authentication identities in our LDAP directory, and other operations
requiring security. During configuration, DCE/RPC secured by GSSAPI/SRP
is used. Once configured, DCE/RPC secured by GSSAPI/KRB5 is used. We are
using MIT Kerberos version 1.14.


_*ISSUE:*_
During development, we discovered an expired Kerberos credentials cache
causes GSSAPI krb5_gss_inquire_cred() to fail with the error
GSS_S_CREDENTIALS_EXPIRED. This prevents SPNEGO from attempting
authentication with plugin mechanisms configured in /etc/gss/mech.

To reproduce this problem, the current user must have a Kerberos
credentials cache containing an expired krbtgt. For example, see the
below expired credentials cache:

# /opt/likewise/bin/klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: sles11-***@VSPHERE.LOCAL

Valid starting Expires Service principal
02/24/2016 16:28:36 02/24/2016 16:34:34 krbtgt/***@VSPHERE.LOCAL

GSSAPI authentication with SRP is not possible for the user
"sles11-***@VSPHERE.LOCAL" when this expired ticket
exists. After deleting this expired cache, SPNEGO authentication
proceeds to SRP.


_*PROPOSED SOLUTION:*_
Attached is a patch for gssapi/mechglue/g_inq_cred.c : gss_inq_cred()
which fixes this issue.

The strategy used in this patch is rather than returning the error
GSS_S_CREDENTIALS_EXPIRED, skip adding the Kerberos mech OID to the
"mechs" OID set.

When krb5_gss_inquire_cred() returns GSS_S_CREDENTIALS_EXPIRED,
mech_offset is set to 1. The assumption made here is the Kerberos mech
OID always exists and is always first in the union_cred->mechs array.
When GSS_S_CREDENTIALS_EXPIRED is returned, the Kerberos OID is not
added to the mechs OID set.

Should "mechanisms" be NULL, the original behavior of returning an empty
OID set is preserved, unless krb5_gss_inquire_cred() failed with
GSS_S_CREDENTIALS_EXPIRED, then that error is returned.

Note: The patch does properly preserve tab/space indentation. Depending
on your email reader, this may not appear to be true.

Please consider accepting the following patch for inclusion in the next
release of MIT Kerberos.

Thanks,
Adam
====
Adam Bernstein
Staff Engineer, VMware
***@vmware.com
500 108th Ave NE, Bellevue WA, 98004

[Greg Hudson]

Hi, Adam. I submitted https://github.com/krb5/krb5/pull/418 yesterday
to address this issue in a simpler way. Can you see if that change
works for you?

Thanks again for reporting this.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Adam Bernstein]

Hi Greg,

The change you checked in fixes expired Kerberos credentials preventing
plugin mechs from being executed.

During my testing, I believed I encountered a case where leaving the
Krb5 mech OID in the mechs_array broke plugin mechanisms, which is why I
coded my patch to leave out the Krb5 mech OID.

However, I've re-tried testing without either of our fixes, and manually
set "status = 0" in the debugger after the failed call to "status =
mech->gss_inquire_cred()". Manually forcing a successful return after
krb5_gss_inquire_cred() returns allows the SRP plugin mech to work.
Removing the Krb5 mech OID from the mechs_array is not required to
resolve this problem.

As your fix is checked in and works for the issue I reported, we will
use your change, as it is an officially supported GSSAPI change.

Thanks for looking into this issue,
Adam

Hi, Adam. I submitted https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_krb5_krb5_pull_418&d=BQIC-g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=o4kJa_KVmM09QFQ8yc4DVnti6YAUAUKF973znNCXFXg&m=J9aMMzaSHp2czb39RSaSBeGUzt-wm7fxJVFYHiKiu1g&s=gocWbEgyTA4rdQPdsWMVqy6035bsFPzSMQDtOK_w3Ok&e= yesterday
to address this issue in a simpler way. Can you see if that change
works for you?
Thanks again for reporting this.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev