Subject: Re: I-D ACTION:draft-weber-krb-wg-kerberos-pfs-00.txt

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 19 Aug 2003 02:06:50 -0400

Would the following be acceptable for public key caching:

You initially either prime the cache with the kdc's public key in some
out of band fashion, or else you use an unauthenticated preauth method
to fetch the kdc's current public key.

When the key changes, and the client indicates it intends to use a key
which is not the newest key, the KDC sends the new key in a KRB-ERROR,
integrity-protected by the old, and the client updates its key cache
database and resends the request.

(One problem that doesn't solve is an attacker doing a MitM the first
time the client connects, and then the attacker rolls the client over
to the real KDC's key silently without any warning.)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 07:26:17 -0700

> to the real KDC's key silently without any warning.)

This is fine with me, and you can replace the DH public parameter with
an RSA or DSA public key too.

It'd be a small variation on something Jacques Vidrine, IIRC, was
supposed to be working on (a weak password pre-auth protected by an
anonymous DH key).

In the limit your proposal is no stronger than weak password pre-auth
protected by an anon DH key, but depending on the situation it can be
significantly stronger (i.e., not susceptible to MITM attacks).

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Aug 2003 19:55:09 -0400

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:

    Joel> Would the following be acceptable for public key caching:
    Joel> You initially either prime the cache with the kdc's public
    Joel> key in some out of band fashion, or else you use an
    Joel> unauthenticated preauth method to fetch the kdc's current
    Joel> public key.

I don't want the anonymous DH preauth type to cause clients to break
if a KDC is forced to discard a key without knowing its old key and
without being able to sign things in that key.

I think if you want signed DH parameters you should use the facilities
provided in pkinit.

Note that is not quite possible right now.

I at least am very concerned about any public key caching in your
draft.  I do believe that there should be a way to enable support for
retaining a KDC public key long-term in conjunction with your schemee.
I'm not really convinced that your draft should specify it nor that it
should be specified now.

I do think that MITM detection should be a part of your proposal,
however.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 19 Aug 2003 20:18:02 -0400

> without being able to sign things in that key.

If the user gets a warning and is asked whether or not to continue,
does that solve this problem sufficiently, or do you think that the
amount of user interaction caused by that warning is unreasonable?

> Note that is not quite possible right now.

OK.

> I do think that MITM detection should be a part of your proposal,

For the anonymous DH case, do you have any objection to keeping track
of previously used KDC public keys only for the purpose of detecting
man in the middle attacks?  I am thinking that if the user hasn't
explicitly and manually configured a key, the things to use the cached
key for are letting the KDC realize that the client may have talked to
a man in the middle, and if there is no signature validating a
rollover, to present a warning to the user.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Aug 2003 08:52:44 -0400

>> I don't want the anonymous DH preauth type to cause clients to
    >> break if a KDC is forced to discard a key without knowing its
    >> old key and without being able to sign things in that key.

    Joel> If the user gets a warning and is asked whether or not to
    Joel> continue, does that solve this problem sufficiently, or do
    Joel> you think that the amount of user interaction caused by that
    Joel> warning is unreasonable?

User interaction is not the problem; deployability is the problem.
Some people, including Ken and myself will not deploy such a system.

I really don't have time to get dragged into a discussion of this
before the September meeting, but hope to consider this issue in great
detail between September and the IETF meeting.