Strange klist output, missing realm in service principal name

[Andreas Ntaflos]

Hi all,

I am wondering what (if anything) is wrong with the following output
from klist. This is after authenticating against a kerberized Apache
server with Firefox and negotiation enabled:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: da...@EXAMPLE.COM

Valid starting Expires Service principal
12/17/10 05:47:13 12/17/10 15:47:13 krbtgt/EXAMP...@EXAMPLE.COM
renew until 12/18/10 05:50:05
12/17/10 05:47:45 12/17/10 15:47:13 HTTP/dev.example.com@
renew until 12/18/10 05:50:05
12/17/10 05:47:45 12/17/10 15:47:13 HTTP/dev.exa...@EXAMPLE.COM
renew until 12/18/10 05:50:05

Notice the first HTTP entry, the realm part after the "@" is missing. I
don't know for sure but this looks wrong to me. No example output of
klist I have ever seen when reading docs or googleing looked like this.
However, everything seems to be working fine, i.e. logging into the
website works without extra password prompts from the browser, as
expected.

Any ideas what, if anything, is the problem here?

Thanks,

Andreas

[Greg Hudson]

On Fri, 2010-12-17 at 00:01 -0500, Andreas Ntaflos wrote:
> Notice the first HTTP entry, the realm part after the "@" is missing. I
> don't know for sure but this looks wrong to me.

This is an artifact of the way host referrals were introduced in krb5
1.6.

Inside the Kerberos library is a function named krb5_sname_to_principal,
affectionately known as sn2princ. When you make your HTTP connection,
this routine is called with the hostname "dev.example.com" and the
service name "HTTP". sn2princ needs to guess the realm to which
dev.example.com belongs. Prior to krb5 1.6, it would try the following
sources of information in order:

1. The krb5.conf domain_realms section
2. A TXT lookup in DNS (if configured to allow these)
3. The uppercased parent domain (EXAMPLE.COM)
4. The client's default realm (for single-component hostnames)

As of krb5 1.6, sn2princ stops after step 1 and just returns a principal
with an empty realm, known as "the referral realm." This is a signal to
krb5_get_credentials to try a request to the client's default realm, and
perhaps get back a referral to the actual realm. If that fails,
krb5_get_credentials invokes a new function
krb5_get_fallback_host_realm() to try steps 2-4 (plus a new step or
two).

Two cache entries are created, one with the empty realm and one with the
realm we actually got credentials in. This is so we don't have to
perform a referral request a second time.

[Andreas Ntaflos]

On Friday 17 December 2010 06:36:45 Greg Hudson wrote:
> On Fri, 2010-12-17 at 00:01 -0500, Andreas Ntaflos wrote:
> > Notice the first HTTP entry, the realm part after the "@" is
> > missing. I don't know for sure but this looks wrong to me.
>
> This is an artifact of the way host referrals were introduced in krb5
> 1.6.

[...]

> Two cache entries are created, one with the empty realm and one with
> the realm we actually got credentials in. This is so we don't have
> to perform a referral request a second time.

Thank you very much for this excellent explanation!

Andreas