Subject: RE: Using "Cookies"?

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Thu, 26 Apr 2001 09:21:08 -0400

Hi All,

Yes, this was my thought earlier. (But be warned I am not a Kerberos expert
and could be way out to lunch!) The SSL/TLS seems to me to be a read
herring. At the application level, as I understand it, it's the session key
that *authenticates* the user, not the TGT. This cookie notion seems to
ignore that. As I understand it, there is no physical security required for
the TGT. It is passed within the protocol as an operational convenience.
Within the encrypted TGT is the secret the user will use to authenticate.
Since the TGT is encrypted, an attacker might have the TGT, but not the
associated secret needed to benefit from it.

As I understand it, if the actual authentication credential were asymmetric,
rather than shared secret, the tokens would only have to be signed.

Do I not understand?

If the above is correct, perhaps the way to kluge Kerberos rigor into
web-based systems would involve something like having the (well) encrypted
cookie contain the SSL/TLS session key that would be used by the user and
application.

Thanks,

Paul

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 11:20 PM
> To: Derek Atkins
> Cc: Mike Fisk; Friedrichs, Paul LCDR; Bernard Aboba; [email-masked];
> Jung Edward; [email-masked]
> Subject: Re: Using "Cookies"?
> 
> 
> On 25 Apr 2001, Derek Atkins wrote:
> 
> > 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.
> 
> 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
>

---

From: Mike Fisk <[email-masked]>
Date: Thu, 26 Apr 2001 12:38:21 -0700 (PDT)

> cookie contain the SSL/TLS session key that would be used by the user and

That would seem to require a modified browser.  Try having the ticket and
plaintext session key in the cookie and protecting it with SSL.

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

---

From: Derek Atkins <[email-masked]>
Date: 26 Apr 2001 16:46:06 -0400

> plaintext session key in the cookie and protecting it with SSL.

Putting the raw session key in the cookie does absolutely no good.
Indeed, this is even worse than before.  Remember, all that static
data (read: cookies) gives you is linkability, not authentication.  It
doesn't matter what you put in the cookie; all it gives you is the
ability to believe that this user has been there before.  Nothing you
can do will actually let you use a cookie _BY ITSELF_ for
authentication.

If someone can steal the cookie, by any means, they can also present
that cookie and claim to be you.  The difference here is that the
cookie is static and non-changing for a LONG period of time, which
gives an attacker both a long time to try to gain access to your
cookie as well as a long time to USE that cookie onece they get it.

I also think, based on your messages to date, that you have absolutely
no clue how Kerberos works or why.  I suggest you go to a tutorial on
Kerberos 101 and then return to the discussion.

-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: Thu, 26 Apr 2001 14:42:18 -0700 (PDT)

We're talking right past each other.  As far as I can tell, you haven't
understood a single statement of mine.  Go back and understand what I'm
saying before deriding me.  Other people on the list have understood the
scenario and have commented that they already do something similar or plan
on doing it in the future.  I've explained it as well as I can.  Try the
following documentation:
	http://www.stanford.edu/~torg/WWW-security.doc.html

Your assertion that "nothing you can do will ... let you use a cookie by
itself for authentication" is flat-out wrong.  Everybody and their brother
does it.  But most of them do it pretty poorly and some of us would like
to see it done better.  If your answer requires the use of a modified
browser or plugin, then you're not addressing the problem at hand.

As far as I can tell, you're unwilling to accept any compromises.  From a
security point of view that's a fine stance, but it does little for most
engineering problems.  You ridicule any less-than-perfect solution, but
all parties seem to agree that there is no perfect solution here.  I'll
take an imperfect solution over either what we have today or a
non-existent perfect solution.

On 26 Apr 2001, Derek Atkins wrote:

> data (read: cookies) gives you is linkability, not authentication.  

Authentication by symmetric encryption, hashing, passwords, etc. is all
done by "linkability".

> that cookie and claim to be you.

Such is the nature of stolen credentials.  The same happens if you steal
my Kerberos credentials cache.

> The difference here is that the cookie is static and non-changing for
> a LONG period of time, which gives an attacker both a long time to try
> to gain access to your cookie as well as a long time to USE that
> cookie onece they get it.