Kerberos canonicalization problem

[Lorenzo Costanzia]

On 2009-02-13 19:41:41 +0100, Ken Raeburn <raeburn at MIT.EDU> said:

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

You're right. I stated above that the "dotted form" is the correct 
behavior, but in the RFC doesn't explicitly say so. But as far as I 
understood, Apples implementation (which is the main proponent of 
Bonjour) _does_ return the dotted form, so their applications like 
Safari, iChat and especially the AFP client built into the Finder use 
also this form. There is not much I can do about it.

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

I personally think this would be the right way, as the dot explicitly 
states: this is a FQDN, there's no need to canonicalize the hostname 
further, simply remove the trailing dot and use it. And I guess there 
are not many way this root label (the dot) would get appended if it 
_were not_ a FQDN, so it should work out in most situations.
But your mileage may vary, and of course when introducing a new 
arbitrary (albeit somewhat understandable) rule one should always 
balance benefits and drawbacks (in this case potential confusion)...

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

No, it's proprietary software, and I'm using Mac OS X. As said above, I 
guess that this behavior is intentional, see 
http://developer.apple.com/documentation/Cocoa/Conceptual/NetServices/Articles/domainnames.html#//apple_ref/doc/uid/TP40002460 
where they explain specifically the meaning of the trailing dot.

>> 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).

I agree.

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

Thanks for the offer, however, I'm not a programmer...
> 
> Ken

Thank you for your long and informative answer.

Take care,
Lorenzo Costanzia