[17309] in Kerberos_V5_Development
Re: Proposed Behavior change: don't fail when krb5_sname_to_principal
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Oct 14 15:31:01 2011
MIME-Version: 1.0
In-Reply-To: <ldvr52fsacg.fsf@cathode-dark-space.mit.edu>
Date: Fri, 14 Oct 2011 13:59:48 -0500
Message-ID: <CAK3OfOgxWpHeEkCjzjTBmG6HOuE=ChwK+zXLS3vuwdPEB30FqA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tom Yu <tlyu@mit.edu>
Cc: Sam Hartman <hartmans@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Oct 14, 2011 at 1:21 PM, Tom Yu <tlyu@mit.edu> wrote:> Greg Hudson <ghudson@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 theresolver's search list is. On Unix I assume that the BIND resolver-or, in the worst case, reading resolv.conf directly- will always bethere.
> 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'stwo ways in which an attacker can hurt the client today: a) byspoofing NXDOMAIN to make the client walk down its search list, b) byspoofing a reply with a CNAME RR, of which (b) is by far the worseattack.
Second, we could and should add a secure KRB-ERROR facility. Loveproposes FAST for TGS exchanges, but since there are or might be APexchange KRB-ERRORs that one might want to secure as well, and for thesake of simplicity, I prefer using an e-data extension to secure theKRB-ERROR. Note that the client can only really learn about realm/KDCsupport of secure KRB-ERROR via AS exchanges and successful TGSexchanges (e.g., renew/validate ticket), or else via configuration.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
