GSS_C_NO_NAME for desired_name?

[Brian Candler]

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.