Subject: Re: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sniffer and cracker for Windows 2000/XP]

From: Jeffrey Altman <[email-masked]>
Date: Mon, 2 Dec 2002 11:20:16 EST

> On Mon, Dec 02, 2002 at 09:29:11AM -0500, Jeffrey Altman wrote:
> > > > > If we still do not want Microsoft to begin using TLS to protect TGT
> > > > > requests we need to come to an agreement quickly.  Probably within
> > > > > days.
> > > > 
> > > > Okay, how about smb's suggestion to use anonymous Diffie-Hellman?
> > > 
> > > How about the suggestion to use DCE RFC 26.0?
> > > 
> > > 
> > 
> > DCE RFC 26.0
> > <http://www.opengroup.org/tech/rfc/mirror-rfc/rfc26.0.txt> is not
> > sufficient in that it assumes that the client machine is managed.
> > This is not the case for the vast majority of client machines.
> > Therefore, there would be no shared key to use to request the data.
> 
> It is the case for most Solaris (SEAM) and Windows 2000/XP deployments
> that clients are "managed" and that is one of the main cases we must
> cater to.  It is easy enough to provide this solution.  I see no reason
> why we shouldn't.  As for key-less kiosks, I agree that we need a
> solution that works for them, but I disagree that we need one solution
> that works for both.
> 
> That said, I very much like the EKE/SRP approaches.
> 
> > The DCE approach also has limitations in a managed environment.  When
> > a host key is available it is only good for a specific KDC.  That
> > means that if I am logged into a machine in REALM BAR1.COM and need a
> > TGT for REALM BAR2.COM and there is no cross realm, my TGT request
> > would again be vulnerable.
> 
> I don't see this. A) the client can use its key to get x-realm TGTs for
> the purpose of doubly-encrypting pa-enc-timestamp and B) we need only
> protect the AS exchanges (principals with password-based longterm keys
> should not be allowed to act as services without user-to-user
> authentication).
> 
> > The ADH approach allows us to provide protection against passive
> > attacks although it does leave open a MITM attack.
> 
> Using a host's keys (its TGTs' serssion keys, rather) to protect
> vulnerable password-based pre-auth data is not open to a MITM attack.
> 
> Cheers,
> 
> Nico
> -- 
> 

Nico:

The cases I am describing above involve situations where there is no
"host key" shared between the client's machine and the KDC.  If the
clients machine belongs to CC.COLUMBIA.EDU and there is no cross realm
with ATHENA.MIT.EDU; and I need a TGT for ATHENA.MIT.EDU I cannot use
the host key assigned to my machine in the request to the
ATHENA.MIT.EDU realm.

Nor in the case of the vast majority of machines at University
campuses can I assume that there are host keys assigned to the vast
majority of the computers used by end users.  Most computers are
managed by local end users (students, faculty, staff) and not by the
central computing authority.

- Jeff

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 08:33:21 -0800

> the host key assigned to my machine in the request to the

I understand.  The case of public, key-less kiosks cannot be addressed
with DCE RFC26 or any variation of it.  My point is that this should not
stop us from specifying a solution based on the DCE RFC26 concept.

> central computing authority.

Clients managed by end users, but which are not public kiosks, could be
given host keys (it's akin to giving a user a very long, random password
for them to use along with their normal password and which the user
stores in a smartcard or in her computer's hard disk and which they
never have to actually type in).

Obviously, public kiosks cannot be considered secure, and therefore
cannot be given host keys, without lots of work to ensure the security
of those host keys (e.g., net booting off of read-only media + very good
kiosk physical security).  Not that it is impossible to have secure,
keyed, public kiosks, just a bit of a headache.

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 02 Dec 2002 11:57:10 -0500

Also note that any DCE-RFC26 solution requires that any
AS_REQ-producing client be setuid-root in order to read the system
key.  This means that kinit, kpasswd, and who knows what other
applications _necessaily_ need to be setuid.

This adds a metric buttload of additional (potential) security
vulnerabilities.

I, personally, do not want to require kinit to be setuid....

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 09:27:52 -0800

Setuid is not the only way to implement this.

However, DCE RFC 26 -style pre-auth does make available to unpriviledged
users an AP-REQ for the client to the KDC.  By itself this does not open
any major vulnerabilities, but it's worth keeping in mind.

Cheers,

Nico
--