Kerberos canonicalization problem

[Ken Raeburn]

On Feb 13, 2009, at 06:23, Lorenzo Costanzia wrote:

> Hi everybody,
>
> I'm trying to set up a AFP server with (MIT) Kerberos authentication
> and DNS service discovery (aka Bonjour, see http://www.dns-sd.org/) in
> my home network (which uses a private .lan top level domain). The AFP
> server works beautifully when connecting "directly" to it.
>
> But when I try to connect to the AFP after discovery via dns-sd, the
> client tries to fetch a
> "afpserver/afp.lan. at MYREALM.LAN" ticket (note the trailing dot in the
> SPN), which doesn't exist, so authentication fails. (This is btw the
> correct behavior of dns-sd, which always gives back the more verbose
> "form" of the hostname with trailing dot.)

I'm not familiar with dns-sd, but my first thought would be that the  
correct behavior for the resolver APIs for producing fully-qualified  
DNS names is to omit the dot.  (There is the argument that the  
trailing dot indicates it's anchored at the root instead of possibly a  
relative name, but in some cases where a name is unambiguously known  
to be fully-qualified, including some standard APIs, the trailing dot  
is omitted.)  I've looked at a few pages on the dns-sd.org web pages,  
and it just sounds to me like they're just being aggressive about  
making the names explicitly fully-qualified when the option is  
available.  But they're talking about GUIs like web browsers, and I'm  
interested in programming APIs.

The standard DNS-host-based principal representation in Kerberos is  
for the second component to be the fully-qualified domain name,  
without the trailing dot.

At some point, the hostname gets translated into a principal name.  It  
might be the right answer for the trailing dot to be omitted at that  
point -- but then, without knowing why or how dns-sd is special in one  
case, I have no idea whether it should be treated specially in the  
other case.

Actually, it looks like we *have* code in one of the code paths (in  
the library function krb5_sname_to_principal) for removing a trailing  
dot, because the Windows APIs (in at least one beta version) behaved  
differently from everyone else.  So I don't think they're using that  
function to generate principal names.  Which leads to the question of  
how the AFP client *is* generating principal names; perhaps it's a bug  
in that code?  Do you have access to the AFP client code, to see what  
it's doing?

> Now I can't simply add "afpserver/afp.lan." principal, as the AFP
> server accepts only one principal,

That's arguably a bug, as even with ordinary DNS a host could have  
multiple names mapping to its IP address(es).

> and I want to be able to connect
> both "directly" and via dns-sd.


> However, when the client connects to the KDC asking for that
> nonexistent service principal, the "canonicalization" flag is set, but
> the KDC doesn't care and reports KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
>
> Now is there a way to activate kdc-side canonicalization and/or  
> setup a
> static alias between "afpserver/afp.lan." and "afpserver/afp.lan"?

Not currently, no.  In the 1.7 alpha release we recently put out,  
there are hooks for the database back end (which may be turning into  
"the interface to the rest of all your infrastructure including  
Kerberos principal data and other things") to do alias processing, but  
we don't have any alias processing currently defined in the database  
back ends we ship, nor any general heuristics applied in the main KDC  
code.

If you feel like writing KDC code, I could probably tell you where to  
look to drop it in...

Ken