Reason for removing sname check?

[Greg Hudson]

On 10/10/2012 02:31 PM, Will Fiveash wrote:
>  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?

If it's a libkrb5 app, it passes a server principal.  If it's a GSSAPI
app, it imports a name and acquires a cred.

>     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?

If no name is given to gss_acquire_cred (or if no acceptor cred is given
to gss_accept_sec_context), krb5 1.7 or later will use any service
principal in the keytab, without respect to hostname.

If a host-based acceptor name is given, krb5 1.9 will translate that
into a single principal and will restrict the client to using that
principal.  krb5 1.10 will allow any service princ key found in the
keytab which matches the criteria in the acceptor name (for instance, if
you give the host-based name "HTTP" without a specific hostname,
rd_req_dec will use any principal of the form HTTP/*@*).

http://k5wiki.kerberos.org/wiki/Projects/Acceptor_Names discusses this
in gory detail, including the pre-1.10 behavior.