Reason for removing sname check?

Simo Sorce simo at
Wed Oct 10 15:51:38 EDT 2012

On Wed, 2012-10-10 at 13:31 -0500, Will Fiveash wrote:
> 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?

That's exactly it.


Simo Sorce * Red Hat, Inc * New York

More information about the Kerberos mailing list