[19094] in Kerberos_V5_Development
Re: Proposal for using NAPTR/URI records
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Tue Feb 24 13:20:08 2015
Message-ID: <1424801990.2583.46.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Tue, 24 Feb 2015 13:19:50 -0500
In-Reply-To: <CAK3OfOjxU5naun6BQE2AjwVdGNusEotgiZzanb+HNroMf4ui=g@mail.gmail.com>
Mime-Version: 1.0
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, 2015-02-24 at 11:15 -0600, Nico Williams wrote:
> I should add that I'm assuming that an MITM wouldn't be able to get
> away with modifying important bits of the protocol because we
> authenticate all contents (or all that matters). So the main
> problem would be information leaks and other problems with getting
> redirected, such as (stretching here) changing the trust anchors
> that the AS' PKINIT cert is to get validated to.
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.
Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
But now I'm really stirring the pot. :)
The point is that Kerberos should always presume that transport is
insecure. Given this, adding additional hoops for a transport that
provides authenticated encryption for at least part of the journey
seems wrong.
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
