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

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 03 Dec 2002 14:54:05 -0600

Sam, 
Can you outline the DH with key approach again? This sounds like
it addreses the 99% of the cases, and kepts down the need for
other protocols. 

You said the MITH is detactable. It looks like only the client
can detect the MITM, and the MITM has what he needs to start cracking.
Is this correct?  If so, could the MITM not send the final message
to the client, thus making ot look like a DOS rather then a MITM to 
the client?

Nico Williams wrote:

> 
> I think the DH w/ key combination approach that Sam suggested is another
> possibility.  That approach has a detectable MITM attack, which, being
> detectable, is tolerable.
> 
> Cheers,
> 
> Nico
> --

-- 

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

---

From: Marcus Watts <[email-masked]>
Date: Tue, 03 Dec 2002 16:46:21 -0500

> to the client, thus making ot look like a DOS rather then a MITM to 

I'm not Sam, but I did implement an experimental version of DH in
kerberos 5 using elliptic curve encryption a while back.

What I did:

KRB5_PADATA_ECEKE	= preauth type

Upon the initial auth attempt, server responds with
	KRB5KDC_ERR_PREAUTH_REQUIRED
and returns a KRB5_PADATA_ECEKE that contains the server's public key.

When the client receives a KRB5KDC_ERR_PREAUTH_REQUIRED with a
KRB5_PADATA_ECEKE, it generates a public/private key, and sends back a
KRB5_PADATA_ECEKE that contains the client's public key and the hash of
the user's password derived key & the DH key that results from hashing
the two keys.

When the server gets a KRB5_PADATA_ECEKE, it generates the hash of the
user's password from its database and the key that result from DH, and
checks to see if they match.  If they don't, then the server has
positive proof the client didn't know the password.  It can log this,
and either return a bogus "success" (to avoid password guessing games)
or return an error.  I implemented the bogus "success" after deciding
the error was unpalatable.  The final successful result returns a
random key encrypted using a variation of the exchanged hash,
and the actual ticket is encrypted under the random key.

I had each server generate its own public key on each restart.  That
means it's important all responses go to the same server.  This also
removes one otherwise useful check: is this the real KDC or an
impostor?  This could be fixed if you're willing to store public keys
in krb5.conf, but that creates its own problems.

What this does do is remove the ability to passively crack keys using
just information acquired through network sniffing.  It does leave the
ability for an active MITM to subsitute for the KDC and return bogus
information - the client will still detect this since the bogus packet
can't be decrypted successfully.

There's also a more complicated key exchange that requires both a
permament and ephemeral key pair for both the server and client,
or 4 key pairs in total.  This would be good if key information is
put in krb5.conf, and may have other advantages.  It's also more
complicated and slower.

I don't know how this relates to lucent technology's encrypted key
exchange patent discussed here
	http://www.networkcomputing.com/1305/1305colmoskowitz.html
since I haven't read the patent and don't know what it claims.
Apparently nobody knows just how broadly the patent could be
interpreted or just what it covers.  If it covers SRP as some have
speculated, it might cover any use that cryptographically associates
passwords to key exchange using assymetric encryption.

				-Marcus Watts

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 3 Dec 2002 16:27:29 -0600

> to the client, thus making ot look like a DOS rather then a MITM to 

I'm not Sam :-), but I posted a DH with key approach in another forum.
``Reprinting'' below.  Basically, the client sends the KDC a HMAC over
the negotiated DH key, using the usual password-derived key, e.g.

     p = client password-derived long-term key
     X = client ephemeral public key 
     Y = KDC ephemeral public key
     k = resultant DH key
     MAC = HMAC-SHA1[p](X, Y, k)

If the MITM passes that one, the KDC detects him.  If the MITM drops
it, the client can be pretty sure of foul play.  Yes, this could be
mistaken for a DoS or other outage.

----- begin reprint -----
>From: "Jacques A. Vidrine" <[email-masked]>
>To: Jeffrey Altman <[email-masked]>
>Cc: [email-masked]
>Subject: Re: Kerberos Password Sniffing
>Message-ID: <[email-masked]>
[...]

IIRC, during my presentation at IETF 53, Steve Bellovin suggested
using a Diffie-Hellman exchange.  This defeats the passive attacker
but not the active attacker.  I have a half-baked implementation of
this just waiting for a week's vacation to finish. :-)  The message
exchange is basically

   AS-REQ            --->

                     <---   KRB-ERROR
                            Need PA: PA-ENC-TIMESTAMP, or
                              PA-ANON-DH (parameters)

   AS-REQ            --->
   PA-ANON-DH: (parameters, X)

                     <---   KRB-ERROR
                            Need PA: PA-ANON-DH (parameters, Y, cookie)

   AS-REQ            --->
   PA-ANON-DH: (parameters, cookie, MAC[p](X, Y, k)

                     <---   AS-REP
                            E[h(p,k)]i(TGT)

X and Y are the DH public keys; k is the resulting secret key; p is
the key based on the client's password.  The cookie is optional: it
holds state for the KDC.  The cookie idea is from Ken Raeburn, who I
think got it from Tom Wu.

This adds an additional message exchange (could perhaps be avoided by
an opportunistic client), but works fine with UDP as well as TCP.

My half-baked implementation doesn't yet handle salt and uses an
ad-hoc encoding of the DH parameters and integers.

----- end reprint -----

This protocol can also be used to eliminate the MITM attack
altogether:

   (1) Instead of an ephemeral key, the KDC uses a long-lived 
       private/public key pair.  (It might do this anyway for
       performance reasons.)

   (2) The client can be configured with a hash of the KDC's
       long-lived public key, and detect MITM attempts early.

The messages remain the same.

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 14:31:10 -0800

> mistaken for a DoS or other outage.

This is EKE by another name.  Don't get me wrong - EKE would be really
cool to use - the question is whether this is covered by an existing
patent.

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 3 Dec 2002 16:37:32 -0600

> cool to use - the question is whether this is covered by an existing

This is not EKE.  EKE is using a shared secret to hide the
public exponents.  It was designed specifically to protect
against password-guessing attacks.  This does not protect against
password-guessing attacks.  This is simply computing a MAC over
previously seen messages.  The MAC is itself vulnerable to
password-guessing attacks (by the MITM).

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Dec 2002 18:13:07 -0500

I'm currently in the middle of discussions with Ken Raeburn.

We're trying to understand some tradeoffs like:

* PFS vs MITM prevension and round trips

* DH vs LEAF

I hope to summarize something shortly.

---

From: Marcus Watts <[email-masked]>
Date: Tue, 03 Dec 2002 19:32:13 -0500

> passwords to key exchange using assymetric encryption.

I hate software patents.

Here are some patents I found which might be relevant:
	
5,241,599
	AT&T/Lucent.  19950808
	EKE.
	I think this describes a particular method using a combination
	of symmetric and assymetric encryption.
5,440,635
	AT&T/Lucent.  19930823
	EKE.
	I think this describes a more general method using a
	combination of symmetric and assymetric encryption.
6,226,383
	Jablon.  20010501
	SPEKE.
	This uses assymetric encryption and one way hashs,
	in a number of different permutations.

There might be more; patent lawyers have a real neat gig going here.

I believe what I implemented does not actually conflict with Lucent's
EKE.  It may conflict with Jablon's SPEKE.  I have to read through his
patent to see what he actually claims; his paper describes several
possibilities.  I think this is the patent that is going to be
hardest to work around within the framework of kerberos.

I didn't look up SRP, because that's more quirky.  I believe it's
wrapped up with how RSA works much more tightly, and would require deeper
changes to how kerberos works (to use it right, the current password
hash database would have to be replaced with information derived from
the password which is by a neat math trick insufficient by itself for
authentication.)  I don't think lucent can make any real claim against
SRP but I'd have to look more carefully at SRP to be sure.  Probably
Lucent has the richest lawyers, so this may not mean much.

I found several other groups trying to come up with an unencumbered
secure password authenticated key exchange, including p1363, fips, and
iscsi.  I suppose that kinda guarantees that if there is a decent
solution, it's non-obvious and therefore in itself patentable.

I hate software patents.

				-Marcus Watts
				UM ITCS Umich Systems Group

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Dec 2002 20:42:51 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Dec 03, 2002 at 04:27:29PM -0600, Jacques
    Nicolas> A. Vidrine wrote:
    >> I'm not Sam :-), but I posted a DH with key approach in another
    >> forum.  ``Reprinting'' below.  Basically, the client sends the
    >> KDC a HMAC over the negotiated DH key, using the usual
    >> password-derived key, e.g.
    >> 
    >> p = client password-derived long-term key X = client ephemeral
    >> public key Y = KDC ephemeral public key k = resultant DH key
    >> If the MITM passes that one, the KDC detects him.  If the MITM
    >> drops it, the client can be pretty sure of foul play.  Yes,
    >> this could be mistaken for a DoS or other outage.

    Nicolas> This is EKE by another name.  Don't get me wrong - EKE
    Nicolas> would be really cool to use - the question is whether

I do not believe this is EKE; you still have a man-in-the-middle
attack.

No DH keys or parameters are encrypted in the long-term key.

---

From: Clifford Neuman <[email-masked]>
Date: Tue, 3 Dec 2002 17:51:55 -0800

I expect I will have all the revisions done by 10:30.

Cliff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Dec 2002 07:21:51 -0800

> No DH keys or parameters are encrypted in the long-term key.

Right.  My bad.

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Thu, 5 Dec 2002 17:06:11 -0600

> I expect I will have all the revisions done by 10:30.

Has a new version been posted for review?
I didn't see one at <URL:http://www.isi.edu/people/bcn/krb-revisions/>.

Cheers,