[19098] in Kerberos_V5_Development
Re: Proposal for using NAPTR/URI records
daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Feb 24 13:53:36 2015
MIME-Version: 1.0
In-Reply-To: <1424801990.2583.46.camel@redhat.com>
Date: Tue, 24 Feb 2015 12:53:23 -0600
Message-ID: <CAK3OfOgwPaeHYQBynKTEVqP64GJyDV=Wp1Z+aobZwgj2B1JfRw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Feb 24, 2015 at 12:19 PM, Nathaniel McCallum
<npmccallum@redhat.com> wrote:
> MITM attack isn't a property limited only to MS-KKDCP. It is possible
> at pretty much every level. Any attack possible over MS-KKDCP is
> possible pretty much everywhere. In fact, I consider MS-KKDCP *more*
> secure given that it goes over TLS and the TLS connection is validated.
Yes, but we're working towards closing many MITM-on-the-wire cases.
DNSSEC takes care of one set of cases. FAST takes care of the rest
(to some degree). (IPsec is out; let's not mention it.) Admittedly,
that's part of the answer to the problem here: use DNSSEC where zones
don't opt-out.
> Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
> But now I'm really stirring the pot. :)
But I agree with this. If we use FAST for AS *and* TGS exchanges,
then what do we get from TLS that we're not already getting from FAST?
This is important from an implementation complexity point of view.
It's a given that we'll all need DNSSEC, fine, and Kerberos, since
Kerberos is the point here, but why add a dependency on TLS? That
brings in a whole bunch of things that a Kerberos implementor might
not want to have to deal with.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
