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:29:08 -0400

I'm not really clear on whether this working group thinks that being
able to do preauth involving a Diffie-Hellman exchange and having some
way to use a public key to authenticate the kdc in that exchange is
valuable.  However, I'm going to assume for the rest of this message
that that's an interesting problem.

So one question is whether it would be better to use the KDC's part of
the Diffie-Hellman exchange as the KDC's relatively-long-term public
key, or whether it makes sense to generate a new Diffie-Hellman public
key frequently.

One potential advantage to using the Diffie-Hellman key as the long
term key is that you can probably save a round trip.  Another
potential advantage is that you don't have to bother to add RSA or DSS
to a Kerberos implementation in order to get a Diffie-Hellman exchange
that authenticates the KDC to the client, and we don't have to argue
over how we specify public key signature algorithms.  And a third
potential advantage is that there may be less state on the KDC
consuming memory when you have lots of outstanding preauth requests,
perhaps from someone attempting a denial of service.

The advantage of doing a Diffie-Hellman exchange with the client and
KDC each generating a public key for each session is that once the
tickets expire, the KDC can destroy all of the encryption keys,
keeping only a long-term signing key around; thus if the KDC becomes
compromised in the future, you don't do nearly as much to compromise
the contents of old sessions if they had been recorded by a sniffer.

(It would still be worth doing Diffie-Hellman in the AP-REQ to prevent
a KDC from sniffing and decrypting sessions without doing a MitM
attack, and to narrow the window of opportunity to the time the
tickets are issued, instead of the time until they expire.)

(Tangentially, my understanding is that there historically has been a
belief that the KDC should be trusted to generate quality random
numbers, but clients shouldn't be trusted in that fashion.  It looks
to me like if you use Diffie-Hellman to negotiate your keys, and you
don't have good random numbers on both sides, you lose.)

---

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

> that that's an interesting problem.

It is an interesting problem.

WG members have been working on two solutions to the current weak
password pre-auth problem, one based on using an additional [host]
principal's TGT to protect the weak pw pre-auth, the other based on
using an anonymous DH exchange to protect the weak pw pre-auth.  Both
are patent free and both defeat passive attackers, but only the former
defeats active attackers (MITMs).

The problem is that to defeat MITMs you need either a patent encumbered
protocol, or you need to distribute additional keys (whether public keys
or shared secrets).  Apparently, enough WG members want to avoid patent
issues that we're left with the two proposals I mentioned, and now
yours.

What's unique to your proposal is that it automates the public key
distribution; of course, it defaults to being MITM-susceptible in the
initial case.

> key, or whether it makes sense to generate a new Diffie-Hellman public

Holding one public DH parameter constant across multiple exchanges makes
the exchanges' security depend on the other peers' DH private number
selection; also, I figure larger groups are needed too.

> perhaps from someone attempting a denial of service.

Not only does one save a round-trip with this approach, one saves an
exponentiation, although the benefit of this may be lost to using larger
groups.

> the contents of old sessions if they had been recorded by a sniffer.

No, this is true even if the KDC's (the REALM's) public DH key is
constant, as long as the clients generate decent, random DH exponents.

> tickets are issued, instead of the time until they expire.)

Extensions...  Will you be at the interim WG meeting?  Perhaps we can
discuss this there in the hallway.

> don't have good random numbers on both sides, you lose.)

Yep.  Nowadays clients may have better sources of random, or
pseudo-random numbers than they used to, but the _KDC can't tell_.

Cheers,

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 19 Aug 2003 10:38:07 -0500

Nicolas Williams wrote:
>  Apparently, enough WG members want to avoid patent

If there is some vendor who would be willing to take on the possible 
patent fight, I believe the WG would get behind them on this. But so 
far no one as stepped up so and the WG has other work to do.

Would you company be willing? 

-- 

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

---

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

> Would you company be willing? 

I wouldn't know, but I'll inquire.

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 19 Aug 2003 14:11:30 -0400

> issues that we're left with the two proposals I mentioned, and now

It may be worth pointing out that I do want to see extra-tgt
implemented, as well as whatever my draft ends up evolving into.
Extra key distribution is hard, and I'd like to see it be possible for
the end user to use whichever of a public key or a shared secret
happens to be more convenient.  (And extra-tgt also supports some two
factor authentication cases that I would like to see be supported.)

> distribution; of course, it defaults to being MITM-susceptible in the

But it's an improvement over truely anonymous D-H, and we seem to have
people who've decided that their threat model doesn't have any threats
that can't be thwarted by a single weak shared secret being the only
thing exchanged out of band.

There are probably also some bits of complexity we could add that
might partially help to make attacks in the initial case more likely
to be detected.

I think you could have the client keep both the current key and the
previous key, and always include a signature of the hash of the
previous key when sending a request to the KDC, and a MitM who didn't
have knowlege of the KDC's private key ought to reliably be noticed if
it tries to roll a bogus key over to the KDC's real key, as long as
the KDC has a list of all the public keys it has ever had.  I think
this even works regardless of whether the MitM ultimately manages to
crack the user's password.

> selection;

If what you say is true, then I think you just found an error in
Ferguson + Schneier's Practical Cryptography that isn't listed in the
errata.  Can you cite a source?

> also, I figure larger groups are needed too.

That *might* be true if you're using variable groups.  (I need to read
some more literature and understand all the fixed group vs variable
group issues.  Though really, it appears that reading Pratical
Cryptography implies that there are several things that are wrong with
my draft, but I need to understand what's in the book a bit better
before I'm going to try to fix the draft.)

> constant, as long as the clients generate decent, random DH exponents.

I'm pretty sure that if you have all of the traffic that's gone over
the network, and either side's private number, you have enough
information to recover the session key.  After all, each side manages
to derive the session key from the exchange to be able to communicate
with the other.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 12:46:11 -0700

> errata.  Can you cite a source?

Er, what I meant to say is that entropy matters, and if you hold one
side constant then the relative importance to the security of the
exchange of the other side's entropy increases.  But that is intuition.
I may well be wrong on this.

> to derive the session key from the exchange to be able to communicate

Ah, yes, you're right.  But the point is somewhat moot anyways, since
this is true today: snoop all the kerberos traffic, break into the KDC
later and you can decrypt much of that traffic except where the keys of
the KDC exchange target principals involved have changed.  IIUC, in the
case of your draft a similar formulation holds.

Cheers,

Nico
--

---

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

So, the way my draft is written right now, it's pretty specific to the
problem of password authentication; if someone wants to use a single
use authentication method with it, there will be more stuff that will
need to be defined, and if someone wants to use a single use
authentication method in conjunction with extra-tgt, that will require
yet more specification.

I talked to Sam yesterday, and he indicated interest in having my
draft interact with the problem pkinit solves somehow, saying that it
seems to try to solve several problems and that we might want to try
to refactor things.

Anyway, I am starting to think that perhaps the correct model to look
at is the way ssh handles authentication.  What I am thinking of
proposing to do with Kerberos is this:

1) The first step is an anonymous Diffie-Hellman exchange between the
client and the KDC, which you always do if you have a
post-PA-ENC-TIMESTAMP era client and KDC.  I think I would be inclined
to differ from ssh by immediately setting up an encrypted and
intergrity protected channel using the output of the Diffie-Hellman
exchange, and using that for the rest of the authentication session.

2) If the client cares to authenticate the server, it does so.

a) If you want the functionality of extra-tgt, the client would send
the name of a principal it has a service key for, and the KDC would
make a cksum of the session key using that principal's key.

b) If you want public key functionality, you send the KDC what you
think its current public key is, and what you thought it was before
that (or omit one or both of those if you simply don't have them).
The KDC will send back a signature with its current key.  If your idea
of the KDC's current key differs from its idea, it will send you its
current public key.  If the client's idea of the KDC's current key had
been something that the KDC used to have as its key, the KDC will
include some sort of signature authenticating that the new key really
belongs to the KDC.

c) If you really want anonymous Diffie-Hellman, the client could just
skip this step.

3) The client sends its principal name to the server over the
encrypted channel.  (Notice how this largely addresses one of the
things mentioned in security considerations of clarifications.)

4) The client interacts with the server to authenticate itself.

a) If the client has a password or a keytab, it uses that to make a
cksum of the session key, and that cksum sent encrypted in the
authentication session key.  The PA-ETYPE-INFO2 can be protected by
the authentication session key as well.

b) If the client has a private key, it could make a public key
signature of the session key.

c) If you're using a single use authentication method, all of the
messages for that would be protected by the authentication session
key.  For some methods, you'd probably want to feed the data through
the string to key function and make a cksum; for others, you'd want to
send the text entered by the user to the KDC.

d) If you don't trust your users to have strong enough passwords to
want any host on the Internet to be able to try to authenticate as
them, you could have a cksum of the session key made using a keytab,
and use a different key usage value for this secondary authentication
than you would be using if you were requesting tickets as the
principal of that keytab.

5) Once the KDC is satisfied that the client has authenticated itself,
the KDC uses a key derived from the diffie-hellman exchange's output
to encrypt the ticket, and sends it to the client.

Notice that I also seem to be proposing to kill extra-tgt as it
stands.

I think in the initial draft of this I would propose to make
everything that isn't just a use of a password or keytab a MAY
implement.

Key usage values are important, especially in the case of kiniting
with a keytab; the server will send a cksum using the keytab's key,
and then it will send the ticket encrypted in the diffie-hellman
authentication session key, so it is crucial that recieving that cksum
authenticating the KDC doesn't provide information that's useful for
the client convincing the KDC that it knows the key of that keytab.

Comments?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Aug 2003 12:28:40 -0400

Nico, as we discussed on list, MITM detection is possible with
anonymous DH.  Have the client insist on the same DH key for the
entire exchange even if an apparently wrong password is entered.
Either the attacker must brute-force the key in real time or force the
login to fail or interrupt the process.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 09:36:30 -0700

> login to fail or interrupt the process.

I'd forgotten about this.  Which is why Jacques' I-D ought to do.

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 20 Aug 2003 15:13:30 -0400

>login to fail or interrupt the process.

Just so I understand this completely ... if you had a MITM, he could
get access to something encrypted with the key, but you'd be able to
detect it, right?

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 12:41:51 -0700

> get access to something encrypted with the key, but you'd be able to

Sort of.

You can design the system so that by the time the MITM gets data it can
attack off-line there must have been a round-trip between the client and
the MITM.  If the MITM can't figure out the password in real-time it
will have to "disconnect" (i.e., fake a network failure) or lead the
client to think that the password is wrong (or that the client principal
doesn't exist)

So MITM detection here is conflated with several other errors.

The client may still be able to tell the difference though.  If after
several attempts to pre-auth with the same password one succeeds where
the previous had failed, then the client knows there was an MITM
earlier.  And network failures immediately following the initial
round-trip could be treated as MITM attacks in all cases.

(Adding a realm public key that can be cached, as in Joel's I-D, would
 defeat the MITM attack in subsequent AS exchanges where the client can
 cache the public key.)

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 20 Aug 2003 18:52:41 -0400

If you want to reuse the same D-H parameters for the entire exchange,
how does that interact with PA-SAM-REDIRECT, and how does it interact
with the MIT implementation's habit of retrying with the master KDC
when a failure occurs?

(The answer *might* be that you only accept PA-SAM-REDIRECT if you get
it before you start sending client authentication information to the
KDC, and I'm not sure if always retrying with the master is considered
important functionality that people are committed to keeping.  But I
think this may suggest that authenticating each request with a signing
key that you can change infrequently enough to keep constant across
all your KDCs easily is going to be less painful.)