[33597] in Kerberos

home help back first fref pref prev next nref lref last post

Re: when would you not want +requires_preauth?

daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Jul 19 15:09:52 2011

MIME-Version: 1.0
In-Reply-To: <CAD3FbMUd4Vazq6Lbtt0s69bC=23sBZM5nhA3QeuifNu4UYuY4Q@mail.gmail.com>
Date: Tue, 19 Jul 2011 14:09:47 -0500
Message-ID: <CAK3OfOi2SJKxAPw4yYE5Td6sMH3Zpx7qJafETwM=8UfByykT_g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Ken Dreyer <ktdreyer@ktdreyer.com>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On Tue, Jul 19, 2011 at 2:01 PM, Ken Dreyer <ktdreyer@ktdreyer.com> wrote:
> On Tue, Jul 19, 2011 at 12:39 PM, Greg Hudson <ghudson@mit.edu> wrote:
>> The best practice is to set +requires-preauth (and probably
>> -allow_tgs_req) on principals with password-derived keys and leave it
>> unset on principals with random keys.
>
> I thought the "best practice" would be to set requires-preauth on
> every principal? I don't want to give someone the ability to offline
> attack any of my principals...

Assuming a strong enough RNG you can't mount an off-line dictionary
attack against pre-auth-less AS-REPs for client principals with
randomized keys.  (The same goes for tickets, which is why you don't
want to allow tickets to be issued for service principals whose keys
are really derived from weak passwords.)

Nico
--
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post