Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Why the dislike of X.509?



Richard,

Richard Pieri <richard.pieri at gmail.com> writes:

> On 8/28/2014 1:40 PM, Derek Atkins wrote:
>> Passwords?  We don't need no stinking passwords!  You don't need to know
>> your user's passwords, you have access to their keys!  If I could dump a
>> copy of your KDC database then I could then impersonate any user (or
>> server!) on your network and read all their traffic.  I don't need to
>> know their passwords to do that.
>
> I don't have their keys. I have one-way hashes of their keys. And your
> hypothetical dump will have the same one-way hashes. No, that wouldn't
> keep you from exploiting the compromise but it would slow you down.

I'm sorry, but you're just 100% wrong here.  You absolutely, positively
have the user (and service) keys on the KDC.  The keys are a hash (well,
technically KDF, a one way function) of the user's passwords.  So you
are somewhat correct in that yes, you have the hash of user's password.
But no, you do actually have the user's *keys* on the KDC.  Otherwise
the Kerberos protocol wouldn't work at all.

Yes, the KDC stores those keys encrypted in a "master key", but for all
KDCs I've met that master key is stashed in a file on the file system.
So let me rephrase, because you're right a "dump" of the kdc database is
still encrypted in the master key.  But if I can get a clone of the KDC
disk then I've got *everything*, not just able to impersonate but as I
stated before also able to read most communications that have already
occurred.

(The exception, of course, are protocols that use Kerberos only for
authentication of a DH session key -- but very few protocols do that).

But if someone does get that copy, the only thing you can do is
effectively force everyone to reset their password.  You basically have
to rekey everyone (users and servers).  It's still a PITA, but I guess
you're right that there *is* a way to do it.  Not that I think *anyone* has.

>> A bad actor can do *everything* with a compromised KDC.  Yes, there are
>> steps to prevent compromise, just like there are steps to prevent
>> compromise of an X.509 CA.  The main difference here is that if I
>
> Except there aren't. X.509 lacks mechanisms to prevent and detect root
> certificate compromises. It was intentionally designed this way. It was
> designed this way so that, for example, government oversight and the NSA
> can decrypt all messages within the agencies under their authority. This
> all happens silently, undetectable by affected users, by design.

Sure it does, it's called a "CRL"..  And OCSP..  But yes, it's
definitely more work to remove bad actors from the trusted root CA list.

> Attempts have been made to address this design "feature". None to date
> have proven consistently reliable.

I agree with this statement.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org