Reason for removing sname check?

Will Fiveash will.fiveash at
Wed Oct 10 14:31:34 EDT 2012

On Wed, Oct 10, 2012 at 12:40:12PM -0400, Greg Hudson wrote:
> On 10/10/2012 11:27 AM, Tomas Kuthan wrote:
> > in MIT krb there used to be a check making sure, that the principal name
> > of a keytab entry used to decode enc-part of a ticket equals sname from
> > that ticket. But this check went away [...]
> We removed this check in 1.7 and changed the way rd_req_dec works in
> order to support server principal aliases.  You can read a bit about
> this at:

In that project description I see:

"Server principals need to be handled differently. The problem is that
 the KDC cannot generally change the name of the server principal. So,
 instead, we must return the principal name exactly as the client asked
 for it. However we need to come up with a solution so that the server
 doesn't need to know the comparison function the KDC is using.
 We do this by ignoring the server name in the ticket (except in the KDB
 keytab) and finding a key in the keytab that can decrypt the ticket. If
 the application passes in constraints about what principal names are
 used, we use these constraints. If not, we accept any key in the keytab.
 We update the context claiming that the client authenticated to whatever
 principal is we found in the keytab. "

How does the server application pass in the service principal
constraints?  Does this mean that if a server calls gss_acquire_cred()
like so:

    maj = gss_acquire_cred(&min, GSS_C_NO_NAME, 0, indicated,
                                 ^^^^^^^^^^^^^ desired name
        GSS_C_ACCEPT, &creds, &acquired, NULL);

the krb code will use any service princ keys found in the keytab, as
long as the hostname component matches, for accepting the AP_REQ?

Will Fiveash
Oracle Solaris Software Engineer
Sent using mutt, a sweet, text based e-mail app <>

More information about the Kerberos mailing list