Subject: Methods for protecting PA-ENC-TIMESTAMP with a third-party principal

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 09:23:25 -0800

Proposal #1 (no new ASN.1 types defined):

 - client host obtains a TGT with its host key for the realm of the user
   (an x-realm TGT if need be)

 - client encrypts timestamp with the user's password derive key and
   then encrypts again with the session key (or a sub-session key) from
   the client's TGT and makes a PA-ENC-TIMESTAMP

   (alternatively we could specify one encryption with a combined key)

 - client includes a PA-TGS-REQ (using the client's TGT) and a
   PA-ENC-TIMESTAMP (as above), in that order, in the AS-REQ for the
   user's initial ticket

 - if a KDC receives an AS-REQ with a a PA-TGS-REQ pre-authentication
   element before any others then the KDC should use the session key (or
   sub-session key, if available) from the embedded AP-REQ to validate
   the subsequent PA-ENC-TIMESTAMP (the semantics for other PA types
   should be specified separately) in the same way that the client used
   to construct the PA-ENC-TIMESTAMP

 - the AS-REP's encrypted part should be encrypted using the combined
   key (if we specify key combination) or the session/sub-session key
   from the PA-TGS-REQ in the AS-REQ

 - perhaps a special KDC options flag should be defined for use with
   this approach (but I don't think that it is strictly necessary)

Proposal #2 (new pre-auth type defined):

 - define a new PA type, similar to the PADATA-ENC-THIRD-PARTY of DCE's
   RFC26. like so:

   PA-ENC-TIMESTAMP-THIRD-PARTY ::= SEQUENCE {
	    ap-req	[0] AP-REQ,
	    timestamp	[1] PA-ENC-TIMESTAMP
   }

 - for the rest this is just like proposal #1, with this new pre-auth
   type used instead of PA-TGS-REQ+PA-ENC-TIMESTAMP

Double encryption (with two keys) presents a small complication: the
client's TGT's session and sub-session key enctype must be the same as
the enctype used for the user's encrypted timestamp.  Key combination
would slow down the specification of this pre-auth mechanism.

I prefer proposal #1.  Existing KDCs should either ignore the PA-TGS-REQ
in the AS-REQ, which would be evident to the client from the response,
or they would respond with an error - either way proposal #1 is
backwards compatible.

Cheers,

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 10:14:24 -0800 (PST)

One thing that occurs to me is that whatever
solution to this problem is adopted, we should
also solve the orthogonal problem of DoS
attacks. After talking to Matt, Brian and Sasha we
all agreed that it really should be orthogonal to
PKINIT, and I'd assume this as well, but I don't
think it can get ignored if expensive public
operations are going to become more prevalent. A
KDC is a sitting duck.

       Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 10:23:15 -0800

Kerberos V is generally vulnerable to DoS attacks - says so in
clarifications.  I don't think we can address that right now.

In any case, the method I propose in this thread is based on symmetric
crypto (though the client can use PKINIT to get its TGTs).

Cheers,

Nico

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 10:54:08 -0800 (PST)

> crypto (though the client can use PKINIT to get its TGTs).

   Frankly, anything which posits a local secret
   to shore up crappy user passwords doesn't seem
   particularly appealing when you can do a DH
   exchange and have a much higher level of
   confidence. Double encryption is certainly
   cheaper, but part of Kerberos' appeal IMO is
   the fact that through tickets it makes public
   encryption a much more scalable proposition,
   CPU-wise. I don't think we should try to
   *avoid* it all costs; it's useful where it's
   useful, and this looks like one of those places.

	   Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 11:11:55 -0800

DH by itself does not protect against MITM attacks.

Simply trading off vulnerability to sniffer passive dictionary attacks
for vulnerability to MITM + dictionary attacks is not very appealing
either.

Nico

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 11:25:57 -0800 (PST)

> for vulnerability to MITM + dictionary attacks is not very appealing

   There is a *substantial* amount of extra work that
   one has to go through to mount an active MITM attack.
   Passive offline sniff 'n crack is a lot more plausible.
   Frankly, if you're that concerned about MITM attacks
   you probably shouldn't be using symmetric key Kerberos
   at all. Let's not lose sight of what the base of the
   problem is here.

	   Mike

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2002 14:33:23 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> One thing that occurs to me is that whatever solution to
    Michael> this problem is adopted, we should also solve the
    Michael> orthogonal problem of DoS attacks. After talking to Matt,
    Michael> Brian and Sasha we all agreed that it really should be
    Michael> orthogonal to PKINIT, and I'd assume this as well, but I
    Michael> don't think it can get ignored if expensive public
    Michael> operations are going to become more prevalent. A KDC is a
    Michael> sitting duck.

This WG reached a consensus that we are not addressing the
authenticated cleartext problem for clarifications.  This consensus
was reached at the first interim meeting, reported at the next IETF
and validated by a lack of objections to the minutes on the list.

The issue of wether to solve that problem for extensions is still
open.

It would be useful if you would try and build a consensus to solve
that problem in extensions.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2002 14:43:22 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> This WG reached a consensus that we are not addressing the
    Sam> authenticated cleartext problem for clarifications.  

While true, this is only a partial answer to your comment.  The DOS
issue of clients pounding the KDC with requests they never plan to
look at the answers to is not an authenticated cleartext issue.

Where did that discussion get left last time we had it?

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Dec 2002 14:10:39 -0600

>    Passive offline sniff 'n crack is a lot more plausible.

Once the extra work is implemented in readily available badguy kits,
it doesn't matter how hard or easy it was -- it's done.

And MITM against SSL and SSH with unchecked server certificates is done.

---

From: Derek Atkins <[email-masked]>
Date: 02 Dec 2002 15:19:42 -0500

> DH by itself does not protect against MITM attacks.

Unauthenticated DH, yes.  ADH == Authenticated DH, which is not
subject to MITM attacks (or at least has MITM detection capabilities).

> for vulnerability to MITM + dictionary attacks is not very appealing

I think trading off passive attacks for active attacks is a major win.
It's not perfect, but it is a step in the right direction.  The other
benefit is that ADH is usably by any client at any time, regardless of
client configuration.

> Nico

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 12:22:03 -0800

> subject to MITM attacks (or at least has MITM detection capabilities).

Ooops, sorry.  I'd taken ADH to mean anonymous Diffie Hellman (a phrase
which was used by someone else earlier in the thread).

My apologies.

> benefit is that ADH is usably by any client at any time, regardless of

Again, I don't think that the MITM attacks are so implausible.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 12:21:53 -0800 (PST)

> And MITM against SSL and SSH with unchecked server certificates is done.

   So I might be totally naive, but it also requires
   that all of the traffic to be made to flow through
   you too, right?. For your average script
   kiddie, that doesn't sound very easy. It's a
   lot more plausible if you have access to the
   network infrastructure, but, well, there's all
   kinds of attacks you could mount if you're a
   bad guy there and sniff 'n crack of Kerberos
   as-reqs doesn't sound like it would be very
   high on the tasty bits list, IMO.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 12:28:21 -0800 (PST)

> benefit is that ADH is usably by any client at any time, regardless of

   Right, and ADH is simply a matter of the KDC and client
   remembering the DH random bits long term. Indeed, a lousy
   password based symmetric key used to bootstrap a better
   long term diffie hellman key might be quite interesting...

   One question: is it possible to massage PKINIT to provide
   the ability to have an unauthenticated DH exchange which
   protects the symmetric key authenticators? Or is that a
   "let's not go there" kind of thing?

	  Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 12:27:13 -0800

> Proposal #1 (no new ASN.1 types defined):
...
> Proposal #2 (new pre-auth type defined):
...

Alternatively, GSS pre-auth, where we would defined a pa-data type for
GSS token exchange and an optional pa-data type similar to
PA-ENC-TIMESTAMP, but which consists of a GSS_Wrap()ed enc-timestamp
(optional because it would be needed only where the GSS initiator
principal does not correspond to the AS-REQ client principal or where
the GSS exchange does not meet policy requirements for initial pre-
authentication.

Combined with the use of the GSS_C_PROT_READY_FLAG option for
GSS_Init_Sec_Context() GSS pre-auth with rfc1964 as the mechanism would
reduce to the exact moral equivalent of DCE RFC26 style pre-
authentication.

(Thanks to Sam for bringing up GSS pre-auth)

Cheers,

Nico
--

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Dec 2002 15:10:54 -0600

>    kiddie, that doesn't sound very easy.

dsniff-2.3 will do that for you as well: suck in traffic across the
local switch with forged ARPs, then play MITM.

But we digress.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 13:25:18 -0800 (PST)

> local switch with forged ARPs, then play MITM.

   I really don't want to belabor this either, but this
   is a localized attack which can be mitigated in other
   ways and to the general good. So I think we're back
   where we started: would an unauthenticated DH exchange
   used to cover a potentially weak password derived key
   be a Good Thing? I think so, all things considered 
   because the alternatives all seem to require
   shared pieces of entropy with all of the issues
   which that brings in tow.

	 Mike

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Dec 2002 15:17:45 -0600

> which was used by someone else earlier in the thread).

Same here.  In fact, google gives me about 8x as many hits for

	adh anonymous-diffie-hellman
as for
	adh authenticated-diffie-hellman