Subject: Tom Ken and my discussions so far

From: [email-masked] (Sam Hartman)
Date: Thu, 5 Dec 2002 13:38:10 -0500 (EST)

This is just my summary of discussions that Tom Yu, Ken Raeburn and I
have been having; I haven't run it by the other two participants so it
is my impressions of the discussions, not a group summary.

PFS does not seem to be that  important, especially because  we will
end up encrypting the session key in a long-term service key.

More specifically, secrecy in the event of a server key compromise
doesn't seem to be important, but secrecy of session keys in case of a
client key compromise seems desirable.

For the most part we cannot seem to find a significant difference
between LEAF and DH.

The one exception might be detection of man-in-the-middle attacks.  It
might be easier to construct a system using DH in which MITM attacks
become fairly obvious.

Consider the following possible clarification  to Jacques's protocol:

c->k g^x
k->c g^y, cookie

The client caches the cookie and resulting g^xy, associating them with
the particular user who is trying to log in. This key will be used
until either a successful authentication happens or the client gives
up and concludes the client has been attacked.

c->k hmac[k_c](x,y, g^xy), cookie
k->c as-rep

Note that the MITM still gets text needed to mount a dictionary
attack, and in fact if the MITM can succeed in real time, then the
MITM can go undetected.  However, if the MITM does not succeed then
the client will never successfully authenticate until it decides
something is wrong because it will be looking for a response that uses
g^xy as part of the key and the long term key as the other part of the
key.  The KDC does not know the correct g^xy and the MITM does not yet
know the correct long-term key.  Thus unless the KDC and MITM
cooperate no such request can be generated.  The client implementation
to actually detect attacks is somewhat complex and fragile, but if you
don't care about attack detection, the implementation is simple.

Notes about this scheme:

* Ken is concerned that if the client reuses g^xy, you may have
  vulnerabilities if an attacker walks up to the client and types in a
  weak but incorrect password and then later the user types in a real
  password.  You may be able to solve these problems by encrypting
  something in combine(g^xy, k_c) rather than using a MAC.

* You probably want to cache g^y on the client in some cases for
  faster authentications and again to make it likely that a MITM will
  be a DOS.

* you need to think about how to handle the KDC wanting to create a
  new g^y or expire outstanding cookies; not actually difficult but
  details you'd have to work through to implement.

* Someone might want to provide a mechanism to associate g^y with a
  cert chain as an optional authentication mechanism.

Finally, for our own benefit, we explored some of the related patent
issues.  I'm not going to summarize that here; really everyone needs
to take appropriate steps to deal with IPR on their own.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Dec 2002 15:20:07 -0500

It was pointed out to me that I proposed that the client include y in
a MAC it sends to the KDC.

What I probably should have suggested is hmac[k_c](g^x, g^y, g^xy).

---

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

> end up encrypting the session key in a long-term service key.

Moreover, if the preauth is `broken' by an attacker, the stakes are
not very high: the attacker then gets only the opportunity of running
a dictionary attack.  Also for this reason, I think that it OK to
allow relatively short (DH or other public) key lengths (such as 512
bits), especially where performance is a concern.

> For the most part we cannot seem to find a significant difference

Then my preference would be Diffie-Hellman: it is simple and widely
understood.

Was there not a difference in computation, though?  It seems that with
the number of public key operations required are:  LEAF requires 1
each at the client and server, while DH requires 2 each at the client
and server.  Is that correct?

That's not much of a concern to me, but I wonder what others think.

> don't care about attack detection, the implementation is simple.

I don't recall if I mentioned it before, and I didn't see it mentioned
here: the cookie is optional and possibly not needed.  In the
following cases, I could see it not being needed:
   (1) There is only one KDC
   (2) All KDCs somehow have shared memory
   (3) The whole exchange has some other state, such as being done in
       a single TCP connection.

>   password.  

I don't understand the risk.

> You may be able to solve these problems by encrypting

This last one could be implemented as simply as providing the client
(at configuration time along with domain->realm mappings and other
sensitive but public information) a fingerprint of g^y ... or a full
blown cert chain as you suggest.  I think that can be left up to the
implementation.

> What I probably should have suggested is hmac[k_c](g^x, g^y, g^xy).

You are correct, that's what my previous proposal included (big X and
big Y).

Thanks for the summary!

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Dec 2002 18:20:56 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    >> vulnerabilities if an attacker walks up to the client and types
    >> in a weak but incorrect password and then later the user types
    >> in a real password.

    Jacques> I don't understand the risk.

I walk up to the computer and try to log in as raeburn with a password
of foo.

The client and KDC select a g^xy and the client sends a MAC  of  data
containing g^xy in foo.  A passive attacker sees this MAC and may gain
information  about  g^xy because the key of the MAC is known.

With real-world hashes I doubt the attack is useful; but I don't think
it is a correct use of a keyed MAC as a primitive.

    >> * Someone might want to provide a mechanism to associate g^y
    >> with a cert chain as an optional authentication mechanism.

    Jacques> This last one could be implemented as simply as providing
    Jacques> the client (at configuration time along with
    Jacques> domain->realm mappings and other sensitive but public
    Jacques> information) a fingerprint of g^y ... or a full blown
    Jacques> cert chain as you suggest.  I think that can be left up
    Jacques> to the implementation.

I disagree for two reasons.  First, we want to reduce configuration
information not increase it.  Second, the public key on the KDC will
change from time to time, where the other information will tend not to
change.  As such, I think the protocol may eventually want to be
extended to allow transport of this information.