Proposed Behavior change: don't fail when krb5_sname_to_principal cannot canonicalize input

[Nico Williams]

On Fri, Oct 14, 2011 at 1:21 PM, Tom Yu <tlyu at mit.edu> wrote:
> Greg Hudson <ghudson at MIT.EDU> writes:
>> I'm not really opposed to this, although one could argue that
>> host/foo.searchdomain is a better guess than host/foo in the absence of
>> DNS (when foo contains no dots).  But that assumes we can find out the
>> search domain (which might be easier than we used to think, but we don't
>> have a facility for it at the moment) and begs the question of what
>> happens when there are multiple search domains.

Windows has an interface that allows you to find out what the
resolver's search list is.  On Unix I assume that the BIND resolver
-or, in the worst case, reading resolv.conf directly- will always be
there.

> Is there any way to securely deal with multiple search domains?

First off we all use DNS now, so we're already not secure.  There's
two ways in which an attacker can hurt the client today: a) by
spoofing NXDOMAIN to make the client walk down its search list, b) by
spoofing a reply with a CNAME RR, of which (b) is by far the worse
attack.

Second, we could and should add a secure KRB-ERROR facility.  Love
proposes FAST for TGS exchanges, but since there are or might be AP
exchange KRB-ERRORs that one might want to secure as well, and for the
sake of simplicity, I prefer using an e-data extension to secure the
KRB-ERROR.  Note that the client can only really learn about realm/KDC
support of secure KRB-ERROR via AS exchanges and successful TGS
exchanges (e.g., renew/validate ticket), or else via configuration.

Nico
--