[kerberos-discuss] thoughts/issues making MIT krb code fit for drop-in to Solaris

Nicolas Williams Nicolas.Williams at sun.com
Fri Sep 19 12:05:02 EDT 2008

On Fri, Sep 19, 2008 at 10:10:16AM -0500, Nicolas Williams wrote:
> On Fri, Sep 19, 2008 at 12:53:13AM -0400, Ken Raeburn wrote:
> > On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> > > - No reverse DNS lookup in krb5_sname_to_principal()
> > 
> > *sigh*
> > 
> > This will be a behavioral change.  We should also not be doing the DNS  
> > lookup to canonicalize the name in the first place, but fixing that  
> > requires other support (having the KDC recognize aliases, etc); that  
> > will also be a behavioral change.  I think we've been maintaining the  
> > status quo until we can inflict just one massive change on the end  
> > sites instead of two.
> I've a plan.  We should discuss this.

I've not read Love's blog entry yet (funny, I've had one of my own saved
but not posted for a while...  perhaps you could say that means I'm part
of the problem :( ), but here's my plan:

I'll take a look.

I haven't yet, but here's my plan:

 - let krb5_sname_to_principal() do no canonicalization (except, if a
   global switch is on, to add the default domain to non-FQDN hostnames)

 - provide an option to do princ name canonicalization during TGS
   exchanges (referrals! but not only)

 - provide a GSS-API req_flag/ret_flag for requesting/indicating

 - canonicalization, when requested, should be as follows:

    - try the given name first (if referral results -> follow it)

    - for each domainname in the resolver's search list

       - try the given name qualified with that domainname (if referral
         results -> follow it)

 - apps that request canonicalization should prompt the user if the
   resulting name was different than the one given by the user

    - with varying levels of strictness[*] (don't prompt if the
      domainname added was the first one on the search list[**]) and
      with a known_hosts-type file this can be no big deal

[*]  Think OpenSSH's StrictHostKeyChecking option.

[**] Whether this happened should be indicated by the library itself,
     which means one more ret_flag.  The app still gets to decide
     whether to prompt.


More information about the krbdev mailing list