Reason for removing sname check?
Simo Sorce
simo at redhat.com
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:
> >
> > http://k5wiki.kerberos.org/wiki/Projects/Aliases#Server_principals
>
> 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.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Kerberos
mailing list