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 13:30:52 EST

> On Mon, Dec 02, 2002 at 11:50:06AM -0500, Jeffrey Altman wrote:
> > There is consensus that a DEC RFC26.0 solution is one of the MUST
> > implements.
> 
> I don't think there is.  I think many here recognize that the DCE
> RFC26.0 approach is fatally flawed.
> 
> The `only' advantage DCE RFC26.0 seems to have going for it is that it
> is already specified.

A DCE RFC26.0 style solution works for those environments such as DCE
or Windows Domains where machines are centrally managed.  For these
environments there is no reason not to implement it.  However, it is
not a general solution.

> On the other hand, ANY solution involving public key cryptography and
> (a certified public key for the KDC) will gain you everything you
> might get with DCE RFC26.0, and it will not have these flaws.

The problem with public key is that you must distribute the keys.  I
really don't want to open up the whole DNS KEY debate again.

> > The ADH solution therefore seems to me to be a MUST implement.
> 
> Given that we cannot at this time mandate EKE-like schemes nor SRP, I
> agree.  [MUST in some future document, not in Kerberos clarifications.
> I think it is too late )-: ]

All of the discussions we are having right now are for the Kerberos
Extensions document OR to be issued as separate Internet-Drafts.  They
cannot affect the Kerberos Clarifications draft.  

 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: "Douglas E. Engert" <[email-masked]>
Date: Mon, 02 Dec 2002 14:21:29 -0600

Might I suggest another approach: increase the keying material
used for generating the user key. 

If I might summarize the problem: User don't pick very good passwords,
thus any key derived from just the password could possibly be cracked.

Solution so far are to protect the preauth using some other method, 
which may or may not be subject to MITM. These other methods
include TLS, DCE RFC26.0, EKE-like or DH.  

The simplest is longer passwords, but since we are having this
discussion, we will assume it is not as well accepted. 

Another approach might be to have individual salt values. In effect 
the password is divided into two parts, the secret password and the
individual salt. Neither is sent over the network. 
 
The individual salt can be stored by the user on the user's workstation.
The memory jogger for the user is stored in the KDC. When the user changes 
the password, the individual salt and memory jogger are also changed. 

The individual salt can be stored on the user's workstation, so the
user normally only enters the password. But if the individual salt is not
available on the client or is wrong, the user is prompted using the 
memory jogger.

The memory jogger needs to be stored by the KDC, and returned as a PA-PW-SALT
or a new PA data type similar to PA-PW-SALT.

Advantages:

   Basically no protocol changes, just a new PA-data type. 
 
   User still has short passwords. 

   Increased keying martial not susceptible to sniffing or MITH. 

   Individual salt is something the user can easily remember.  

Disadvantages:

   User has to define individual salt and memory jogger when changing password.

   Individual salt is stored on user's computer, which means it must
   be protected from other users on that computer. (It might be stored
   in memory, and not over a restart.)

   Preauth may require additional prompt to user to enter in individual salt. 

   Change PW needs to be modified to collect the individual salt,
   and to send memory jogger to KDC. 

   Individual salts need to be selected so as not guessable by sniffer or MITH.
   i.e. your name is not a good choice.   

For example, my memory jogger is "dog's name and b-day"
and my individual salt is "Fido Oct 1,1999"

 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444