Kerberos Password Sniffing

[Jacques A. Vidrine]

On Sun, Dec 01, 2002 at 11:16:16AM +0000, Jeffrey Altman wrote:
> There are a large number of factors:
> 
>  . do not want to require the use of PKINIT solutions since the whole
>    point of Kerberos is that Kerberos is the trust third party and
>    we do not want to need to worry about all of the problems surrounding
>    PK management
> 
>  . do not want to require the use of TLS over which the Kerberos
>    exchange could take place; both because of the added crypto 
>    overhead and because most Kerberos implementations do not yet
>    support non-UDP exchanges
> 
>  . do not want to require the use of Zero Knowledge Inference solutions
>    such as EKE, SPEKE, and SRP because of all the intellectual property
>    issues surrounding the various patent claims.

In fact, there already exists a first draft of an SRP-based
preauthentication proposal, but it has no chance in the IETF due
to the patent issues.  Likewise, IMHO, it has little chance in the
commercial environment.

> Once you go through that list what are we left with?

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.

If you can have a pre-configured client, there is the possibility
of eliminating even the passive attack by e.g. using DSS to sign
the KDC's Y, or using ElGamal to encrypt the client's X.  But this
complicates things substantially, so I've not pursued it.  (If you
can pre-configure the client, there are other ways of protecting the
exchange that might be cleaner.)

> The working group has been talking about a variety of solutions that could
> be standardized.  Perhaps SRP for open source deployments and SPEKE for 
> commerical ones.  Some people might want the TLS solution.  In any case,
> the IETF has had a hard enough time just coming to consensus on the 
> Kerberos 5 Clarifications document let alone addressing all of the many 
> other needs which may be dependent on Kerberos 5 Revisions.

And such proposals can (and IMHO should) be handled by extensions,
anyway.

> Kerberos 5 Clarifications plus the Crypto updates and AES support
> should go the IESG within the next month.  Then we will start to work
> on PKINIT, PKCROSS, Set/Change Password, and the Revisions document.
> Rapid progress should be acheivable from this point forward.

Cheers,
-- 
Jacques A. Vidrine <nectar at celabo.org>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
jvidrine at verio.net     .  nectar at FreeBSD.org  .          nectar at kth.se