My understanding from previous postings is that a modern Kerberos app should
just try decrypting the ticket with every key in its keytab until it finds
one which works.
On the openldap-technical mailing list, Russ Allbery has just posted a
one-line patch he uses for Cyrus-SASL:
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -693,7 +693,7 @@ gssapi_server_mech_step(void *conn_context,
GSS_LOCK_MUTEX(params->utils);
maj_stat = gss_acquire_cred(&min_stat,
- text->server_name,
+ GSS_C_NO_NAME,
GSS_C_INDEFINITE,
GSS_C_NO_OID_SET,
GSS_C_ACCEPT,
I'd like to propose this upstream, but first would like some feedback as to
whether this is likely to be a safe change to make, remembering that some
people may be using older versions of MIT, or different Kerberos libraries,
underneath GSSAPI.
Greg said recently at
http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html
"Actually, as of MIT krb5 1.7, we usually ignore the principal sent by
the client, because it might be an alias. If the server application
doesn't specify a principal, we just try every entry in the keytab until
we find one which can decrypt the ticket."
Would GSS_C_NO_NAME work for older versions of MIT krb5 too?
I found another post at
http://mailman.mit.edu/pipermail/krbdev/2006-February/004150.html
which also suggests to me that it would work with MIT Kerberos, but is
possibly "non-standard" usage.
I tried scanning RFC 2743, which allows this usage for GSS_Acquire_cred
(2.1.1)
"A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name,
which will be interpreted as a request for a credential handle that
will invoke default behavior ..."
I couldn't find anything relevant in RFC 1964 apart from
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No principal in keytab matches desired name" */
Are there any other considerations?
Regards,
Brian.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
