Subject: Using "Cookies"?

From: "Jung, Edward (Edward)" <[email-masked]>
Date: Tue, 24 Apr 2001 18:48:26 -0500

Hi all,

Sorry for asking this implementation Q that is potentially non-sense.....

Q: Can we implement Kerberos using "cookies" for a single sign-on function
that can be used in the HTTP Web Applications environment?

Regards
E.J.

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Apr 2001 12:41:00 +0200 (METDST)

> Sorry for asking this implementation Q that is potentially non-sense.....

Well, it's pretty close to it.  ;-)

> that can be used in the HTTP Web Applications environment?

Short answer: No.

HTTP Basic Authentication or a Cookie-based authentication is
going to be a disclosing authentication scheme, because the only
characteristic these functions provide is being able to automatically
replay a piece of constant information with every successive HTTP-request.
The information is transfered buried within the application protocol
data and very few web-applications apply extra care for such
sensitive information within the header fields of a client request.

The huge drawback of disclosing authentication is that everyone who gets
hold of this information somehow can reuse and successfully impersonate
the original client, maybe even for access to additional resources
and other machines/systems and maybe for a quite long or indefinite
time.

To put it mildly: combining a disclosing authentication with a technology
for massive automatic duplication, replay & spread is extremely dangerous.
To mix any sensitive disclosing authentication information in
such a careless fashion arbitrarily into application protocol
data so that applications are quite likely to disclose it by accident
make it even more dangerous.

Leakage of the information can be easily be caused by invalid or inappropriate
attempts of an application to configure the distribution of a cookie.
There are millions of Web-Browers out there with all kinds of bugs
that will leak cookies and/or Basic authentication in various situations
all by their own.  Millions others can be coerced into revealing via
HTTP those cookies and basic authentication information that was
originally established over HTTPS.

Persistent cookie (storage), application log files on the Web
Server(s) containing the header fields of client requests,
JavaScript plus Cross-Domain-Scripting, ActiveX and overzealous
safe-for-scripting controls and plenty of other bugs offer an
extremely high probability of coerced leakage of such information
i.e. >95% of the Web-browsers are vulerable to at least one
well-known and well-documented coerced leakage even with
the highest security settings, probably >80% of the installed
base has the security settings so low that coerced leakage
is possible just by using the available "features" even without
exploiting a single bug...

Kerberos (and every other serious authentication scheme), performs
a non-disclosing authentication, i.e. the transferred authentication
information is valid for at most one authentication and can therefore
not be reused for successive authentications, i.e. the Kerberos
protocol protects against replayed authenticatin attempts.

-Martin

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Apr 2001 08:08:53 -0700 (PDT)

> replay a piece of constant information with every successive HTTP-request.

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.

---

From: Mike Fisk <[email-masked]>
Date: Wed, 25 Apr 2001 09:28:48 -0700 (PDT)

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? 

-- 
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: 25 Apr 2001 13:11:13 -0400

It prevents replay attacks.

-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 10:55:46 -0700 (PDT)

> It prevents replay attacks.

Gee, thanks.  In what context?  What value does it add if tickets aren't
transmitted in the clear?