Subject: RE: Using "Cookies"?

From: Mike Fisk <[email-masked]>
Date: Wed, 25 Apr 2001 12:17:34 -0700 (PDT)

If you've stolen the TGT, you can create new service tickets and
don't need to replay old ones.

On Wed, 25 Apr 2001, Friedrichs, Paul LCDR wrote:

> Hi Mike,
> 
> It appears to me that this means it doesn't matter whether things are sent
> in the clear. Another web site steals the cookie (exploiting vulnerabilities
> mentioned earlier) and uses the cookie to pretend to be the first person.
> 
> Am I missing something, anyone?
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: Mike Fisk [mailto:[email-masked]]
> > Sent: Wednesday, April 25, 2001 1:56 PM
> > To: Derek Atkins
> > Cc: Bernard Aboba; [email-masked]; Jung Edward; [email-masked]
> > Subject: Re: Using "Cookies"?
> > 
> > 
> > On 25 Apr 2001, Derek Atkins wrote:
> > 
> > > It prevents replay attacks.
> > 
> > Gee, thanks.  In what context?  What value does it add if 
> > tickets aren't
> > transmitted in the clear?
> > 
> > > Mike Fisk <[email-masked]> writes:
> > > 
> > > > Authenticators prevent replay by an eavesdropper when a ticket is
> > > > transmitted in the clear, but an HTTP mechanism can use 
> > SSL to protect
> > > > tickets from eavesdroppers.  
> > > > 
> > > > As far as checking that the ticket was recently 
> > generated, can someone
> > > > clue me in on what vulnerability this prevents? 
> > > > 
> > > > On Wed, 25 Apr 2001, Bernard Aboba wrote:
> > > > 
> > > > > > > Q: Can we implement Kerberos using "cookies" for a 
> > single sign-on function
> > > > > > > that can be used in the HTTP Web Applications environment?
> > > > > 
> > > > > The big issue with cookies isn't that they're transmitted in the
> > > > > clear, or that they are reusable (both are characteristics of
> > > > > Kerberos tickets). It is that there is no equivalent of 
> > the Authenticator
> > > > > to prove "liveness". So even if a ticket could be represented in
> > > > > the form of a cookie, it would not provide the required 
> > security. 
> > 
> > -- 
> > Mike Fisk, RADIANT Team, Network Engineering Group, Los 
> > Alamos National Lab
> > See http://home.lanl.gov/mfisk/ for contact information
> > 
> 

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

---

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Wed, 25 Apr 2001 15:12:53 -0400

Hi Mike,

Paul

---

From: Derek Atkins <[email-masked]>
Date: 25 Apr 2001 16:18:56 -0400

That's the whole point of the livliness check, to prove that
you have the secret key contained in the TGT (or service ticket).
The timestamp provides you a replay-window.  So, mere posession of
a kerberos ticket is not sufficient to use it; you need a ticket
and authenticator.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Mike Fisk <[email-masked]>
Date: Wed, 25 Apr 2001 15:55:14 -0700 (PDT)

> a kerberos ticket is not sufficient to use it; you need a ticket

You're assuming a solution (the k5 protocol).

Let me try again.  Assume that tickets cannot be stolen in transit (this
is not k5).  Then to capture a TGT, you would have to compromise one of
the end-points.  If you compromise the KDC, then it's all over, so let's
not worry about the details of that case.  If you compromise the client,
then what you get is a credentials cache.  If you have a credentials
cache, then you can get new service tickets.

---

From: Derek Atkins <[email-masked]>
Date: 25 Apr 2001 21:52:51 -0400

> You're assuming a solution (the k5 protocol).

Perhaps, but kerberos has a lot of research and study to back up
it's design decisions (ASN.1 aside ;)

> cache, then you can get new service tickets.

How do you know that you're talking to the right endpoint?  You can't
have it both ways, you know.  If you're using SSL, then how do you
know that the SSL endpoint is really the same as the kerberos
endpoint?  Without some mapping and verification then you may be
subject to a man in the middle attack (which is already possible with
SSL today!).

If you plan to use Kerberos to secure SSL, then you've got a chicken
and egg problem.  How do you secure the keying?

What the IP checks give you is just an added bar that an attacker
needs to jump through while the authenticator is still valid.  The
more things an attacker has to do, then _hopefully_ the more difficult
it is for them to do it.  Is it perfect?  No.  Does it add some
security?  Maybe.  Does removing it definitely lower the security?
Yes, because it makes it easier for someone to reuse the tickets from
anywhere.

-derek

---

From: Mike Fisk <[email-masked]>
Date: Wed, 25 Apr 2001 19:05:30 -0700 (PDT)

> it's design decisions (ASN.1 aside ;)

Agreed.  And that's why it's beneficial to apply some of that experience
to the masses of people using very poorly designed cookie-based
authentication schemes.

> subject to a man in the middle attack (which is already possible with

I probably should have explicitly stated it earlier, but in this model SSL
is used for host (server) authentication and Kerberos ala cookies is used
for user authentication.

So, rightly or wrongly, a browser trusts any host that Verisign, et al
certify.  Naively ignoring human-factors issues about users ignoring
browser warning messages, the user will only submit their password to a
"trusted" host.  If that password successfully gets and decrypts a TGT,
then the web authentication server, will issue that TGT as a cookie to the
same host that provided the password.  It's not perfect, but it's what you
get with SSL.

> Yes, because it makes it easier for someone to reuse the tickets from

Agreed.  But the question was about the timestamp, not IP addresses.  
(The other thread was about IP addresses.  8^)

---

From: Derek Atkins <[email-masked]>
Date: 25 Apr 2001 22:14:13 -0400

What a timestamp gives you is replay protection and liveness.  You
_KNOW_ when the client created the authenticator.  What this gives
you is that either:

	1) the request is "current" (within the "validity window" of
           the authenticator) and valid, or

	2) an attacker was able to obtain the ticket and replay it all
           within the validity window

What this buys you is that someone can't just obtain the 10-hour
ticket off the wire and use it for the whole 10 hours; they have to
also have either the session key (which implies they've obtained the
client credential cache) or they have to replay within the (much
shorter) authenticator validity window.

-derek

PS: Considering the currently outstanding Microsoft level-3
certificates that Verisign mistakenly created, do YOU still trust them
to protect you from man-in-the-middle attacks?  I certainly don't!

---

From: Mike Fisk <[email-masked]>
Date: Wed, 25 Apr 2001 19:49:18 -0700 (PDT)

>            within the validity window

Yes, but what I was looking for was an example of an attack that uses a
replayed ticket, but that can't do so within the validity window.  I'm
struggling for a canonical example.

And the answer to my earlier question, "What value does it add if tickets
aren't transmitted in the clear?" seems to be a confirmed "none" IF you
trust the confidentiality of your transport layer.

> to protect you from man-in-the-middle attacks?  I certainly don't!

I never did.  I'm kind of glad someone was able to do something high
profile to point out this flaw in the trust relationship.  I've purchased
legit certs before (after a failed attempt at getting users to use an
in-house, "untrusted" CA) and anyone else who could spoof letterhead and
make-up signatures could have gotten certs as us too.

But keep in mind kerberos ala cookies (call it bastardized kerberos if you
like) would be a big step up from many current cookie-based schemes.

If you could do it right, then yes you'd use k5 as an SSL authentication
method, but those of us who are "prisoners to our software" (as RMS would
say) are stuck without k5-enabled browsers.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 Apr 2001 23:20:19 -0400 (EDT)

> shorter) authenticator validity window.

Replays, in turn, can be defended against by having the application keep a
replay cache.  What the timestamp in the authenticator gives you is a
bound on the time period which must be covered by the replay cache.

In any event, the original question was whether a web-based application
could do authentication by storing Kerberos tickets in cookies.  The
answer is no -- an application which does this gains nothing over storing
a cookie in some other format.  Anyone can get a Kerberos ticket for a
service; the thing that authenticates the client's identity is that he
knows the session key, which he proves by using it.  An unmodified browser
cannot do this.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA