Subject: RE: Using "Cookies"?

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Fri, 27 Apr 2001 11:17:24 -0400

Mike,

Am I correct in understanding that this appears to address only the
authorization portion of the Kerberos functionality? Doesn't Kerberos use
the tickets more like a certificate, associated with a secret key, than as
the entire credential? In Kerberos, an attacker needs to get both the ticket
and the secret key, while for cookies the attacker only needs to get the
cookie? Or to put it another way, the loss of control of the cookie would be
catastrophic while the loss of control of a Kerberos ticket wouldn't matter
much at all?

If that's the best we can do with browsers today, than that's best we can
do. I'm just trying to understand the remaining vulnerabilities.

Thanks,

Paul

> -----Original Message-----
> From: Mike Fisk [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 9:53 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Using "Cookies"?
> 
> 
> Let me explain this without using the work "ticket" or 
> "credential" since
> people seem to keep reading extra Kerberos semantics into them:
> 
> The idea is to have a cookie-granting-cookie issued by the 
> cookie-granting
> system.  When someone wishes to go to a web service, they get 
> redirected
> back to the cookie-granting system to get a service cookie.  The proxy
> issues a service-cookie and redirects the browser back to the 
> service.  
> The service can verify that the service-cookie authorizes its holder
> to access the service.  The cookies seen by a rogue or 
> compromised server
> will not be usable to access other network services.  Thus 
> the individual
> servers need not be trusted, however the cookie-granting server is
> trusted.  It's your typical trusted third-party model.  
> 
> In your e-mail quoted at the end of this message, you seem to 
> be talking a
> bout a two-party system.  If you've come full circle and are 
> talking about
> something similar to what's described above (which is what we've been
> talking about all along), then great!  Otherwise, please 
> explain how you
> plan to handle single sign-on while handling the rogue server case
> securely.
> 
> [out of order]
> > What can be done with the information in the cookie in case 
> > the cookie is leaked to an attacker?
> 
> For a cookie-granting-cookie:  access any service for the 
> lifetime of that
> cookie.  If cookies are renewable, you can change the passwd 
> with them,
> etc. then game over.
> 
> For a service-cookie:  only access that particular service for some
> smaller period of time.
> 
> On Fri, 27 Apr 2001, Martin Rex wrote:
> 
> > 
> > Mike Fisk wrote:
> > > 
> > > On Thu, 26 Apr 2001, Martin Rex wrote:
> > > 
> > > > I could think of two scenarios that involve Kerberos, but that
> > > > do not use Kerberos authentication (in the Cookie):
> > > 
> > > Neither of your scenarios seem to address single sign-on.
> > > That tends to be a system requirement.
> >  
> > Of course, it does -- use your imagination!
> > 
> > By selecting/creating a token with adequate characteristics, the
> > Web-Server can easily achieve that.
> 
> > 
> > In both scenarios, the token from the Webserver for (b) can 
> be one or more of:
> >  - a simple increasing 16-bit number
> >  - a cryptographically strong random number with >= 128 bits
> >  - a user name
> >  - a user name and password
> >  - a Kerberos TGT
> >  - a Kerberos service ticket
> >  - a Kerberos TGT plus the matching session key
> >  - a Kerberos service ticket plus the matching session key
> >  - anything of the previous encrypted
> >  - anything of the previous protected by a keyed hash
> >  - anything of the previous protected by a public key signature
> >  - anything of the previous with a validity timestamp
> > 
> > Personally, I consider it very dangerous to store anything 
> in the cookie
> > for (re-)authentication purposes that is *not* limited to a short
> > lifetime (a few hours).  Storing true credentials in a cookie (like
> > some of the above list) would be a pretty bad idea.
> > 
> > Keep in mind that there is a cookie size restriction ... 
> (4KByte, I think).
> > 
> > Depending on how the web server creates his token, other web servers
> > will be able to recognize/assert a previous authentication of the
> > user and permit the user in.  IMHO that is the *only* kind 
> of cookie-based
> > Single Sign-On approach that is possible.
> > 
> > 
> > If any, the cookie should probably contain:
> >   - a user name
> >   - a validity timestamp
> >   - the purpose of the cookie (limiting its capabilities)
> >   - the name of the system who issued this cookie
> >   - an integrity protection of this information either by a
> >     keyed hash or preferably a public key signature
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -Martin
> > 
> > 
> > Quoting my original scenarios:
> > > 
> > > > 1) (a) There is a login-page (form) through which users 
> can type in
> > > >    and submit their Kerberos password.  On the Web-Server, this
> > > >    password is verified against the Kerberos KDC as the
> > > >    password database (e.g. by requesting a TGT).
> > > >    (b) When this succeeds, the Web-Server creates and 
> sets a Cookie
> > > >    containing a token that he will recognize in future requests.
> > > > 
> > > >    (a) is simple, disclosing password-based authentication
> > > > 
> > > >    (b) is a disclosing (re-)authentication of a token selected
> > > >        or generated by the Web-Server.  It does *NOT* 
> matter what
> > > >        the content of that token is, everyone who is able to
> > > >        copy that token is able to impersonate.
> > > > 
> > > >    It is extremely dangerous to have all one's users disclose
> > > >    their longterm Kerberos secrets to a single Web-Server,
> > > >    because it makes this Web-Server an *extremely* attractive
> > > >    target for attack -- about as attractive as the KDC itself,
> > > >    just that all Web-Servers that I know are significantly less
> > > >    robust and secure as most KDCs ...
> > > > 
> > > > 
> > > > 2) (a) there is a login-page (form) through which users can
> > > >    submit a service-ticket with an accompanying fresh
> > > >    authenticator to the Web Server.  The Web-Server performs
> > > >    a Kerberos authentication by verifying the authenticator
> > > >    against the service ticket.
> > > >    (b) When this succeeds, the Web-Server creates and 
> sets a Cookie
> > > >    containing a token that he will recognize in future requests.
> > > > 
> > > >    (a) is a true Kerberos authentication.  It's non-disclosing,
> > > >        non-replayable and secure.  It's good.
> > > > 
> > > >    (b) is a disclosing (re-)authentication of a token selected
> > > >        or generated by the Web-Server.  It does *NOT* 
> matter what
> > > >        the content of that token is, everyone who is able to
> > > >        copy that token is able to impersonate.
> > > > 
> > > >    This system is much better, just that the Cookie-based
> > > >    (re-)authentication has nothing at all to do with Kerberos
> > > >    (not even when the token contains a Kerberos ticket) and
> > > >    it is vulnerable to cookie-theft just as any other
> > > >    Cookie-based authentication.
> > > > 
> > > >    However: (a) will require either a browser modification,
> > > >    an awkward user interface or enabling of active content in
> > > >    the browser, so you have to choose between
> > > >    "non-standard", "awkward" and "dangerous+platform-specific".
> > > 
> > 
> 
> -- 
> Mike Fisk, RADIANT Team, Network Engineering Group, Los 
> Alamos National Lab
> See http://home.lanl.gov/mfisk/ for contact information
>

---

From: Mike Fisk <[email-masked]>
Date: Fri, 27 Apr 2001 08:43:13 -0700 (PDT)

On Fri, 27 Apr 2001, Friedrichs, Paul LCDR wrote:

> authorization portion of the Kerberos functionality? 

I wouldn't say so.

> Doesn't Kerberos use
> cookie? 

The Kerberos ticket is not protected in transit, but the key is.  Your
analogy to a cert is well-founded in that the opaque ticket is not
particularly confidential and it vouches for the identity (and
authorization) of the holder of the session key.  (But unlike a PKI cert,
the full contents of the ticket are not publicly readable.)

> Or to put it another way, the loss of control of the cookie would be

The opaque ticket is disclosed by definition.  The disclosure of the
cookie is more similar to disclosing the session key (although the cookie
might contain both a session key and non-secret information like a
ticket).  Disclosing the session key to the service doesn't hurt since the
service already knows it.  But disclosing it to anyone else may let them
access that service as you.

A true Kerberos client proves to the service that it holds the key by
making a well-formed authenticator.  With a cookie-based protocol, you
have to send the key to the server and depend on SSL to protect its
confidentiality.

So this protocol is only acceptible if one has some level of trust in the
brower's ability to keep the cookie secret.

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

---

From: Mike Fisk <[email-masked]>
Date: Fri, 27 Apr 2001 09:51:52 -0700 (PDT)

On 27 Apr 2001, Derek Atkins wrote:

> Mike,
> 
> The disconnect here is that with Kerberos (or, indeed, any real
> authentication system), you generally "prove" authentication by
> showing "something you have" (SYH) and also showing "something you
> know" (SYK).  

> With a certificate system, the SYH is your Public Certificate.  The
> SYK is your secret key.  You prove authentication by sending your
> public certificate and then encrypting some data (signing it) with
> your secret key.

No. 

First, Most two-factor authentication systems with SYH and SYN assume that
neither of those factors is public knowledge or publicly accesible.  If
it's public is it doesn't count as a factor.  So counting a public cert as
SYH is useless.  Second, you're the first person I've talk to ever refer
to "having" knowledge.  In common usage, "having" refers to something
physical like a list of one-time passwords, a hardware device, or a body
part.

What you're stuck on is this notion that any "real" authentication system
proves knowledge of a secret without disclosing the secret.  "real" is a
subjective and biased term.  Yes, I prefer systems that don't disclose
secrets.  I'd love it if the browser could build an authenticator or, say,
hash the secret with a challenge issued by the server and return that.  
But that doesn't seem likely with a dumb browser.

> The problem with your proposal is that if I, as a rogue server, could
> convince you that really I'm server X, I can cause you to obtain a
> 'service cookie' for server X and then hand it to me ("protected" by
> SSL :).  Then I can go use your cookie with server X and be
> authenticated as you, as far as server X is concerned.  There is no
> proof of SYK in this system, so there is no way to prevent a party
> from re-using the SYH data.

I completely agree and that's something that it appears you have to accept
with a cookie scheme that uses a passive browser that doesn't know
anything.

> Mike Fisk <[email-masked]> writes:
>

---

From: Derek Atkins <[email-masked]>
Date: 27 Apr 2001 13:19:59 -0400

> neither of those factors is public knowledge or publicly accesible.  If

I've certainly never read any literature that makes this claim, but
there are a number of papers in Advances in Cryptology that look at
applications of authentication in open networks.

> physical like a list of one-time passwords, a hardware device, or a body

No, you can have a pile of bits, too.  A Kerberos Ticket is certainly
something that you can consider "having", whereas the shared secret is
something that you can consider "knowing".  The analogy fits
perfectly, and indeed Kerberos was originally based on this two-factor
model.

> But that doesn't seem likely with a dumb browser.

Any authentication system where the secret is both disclosed and
reusable is just plain broken.  You can have a "real" authentication
system with disclosed secrets.  Just look at any One-Time Password
schemes like S/Key or SecurID.

The problem is that any re-usable cookie system is no more secure than
a username/password scheme.  The best you can get is a "distributed"
username/password scheme, but the system is still not secure.  The
best you can do is centralize the username/password "authority", but
you're not improving security, you're only centralizing your database.

The two concepts are not equivalent.

-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: Nicolas Williams <[email-masked]>
Date: Fri, 27 Apr 2001 14:37:16 -0400

You're right, there's nothing that can be done with the web and Kerberos
in a standard way that will bring Kerberos authentication to a web.

What you're trying to do is validate user passwords against Kerberos and
then follow up with cookie magic to implement single-sign-on across a
set of web servers. There's a number of products, commercial and
otherwise which allow you to do this [without storing ccaches in
cookies].

I think this all argues for a standard way to do SASL and/or GSS and or
raw Kerberos V *network* authentication and session key exchange in
HTTP.

For God's sake, how come it hasn't been done yet!

And what would it take to do it?? For raw Kerberos auth it would be
trivial, almost: base-64 encode an AP_REQ and pass it to the web server
in the HTTP header, indicate (with another header) wether you want to
encrypt, if encrypting then base-64 encode the encrypted remain headers
and the HTTP request body -- similarly with the HTTP response; if
encrypting then use the same session key for the rest of the HTTP [1.1]
session.

For SASL/GSS it gets a bit more complicated, but it's instructive to see
how OpenVision, and later Sun retrofitted GSS into ONC RPC. To follow
that example I would use a header to indicate that SASL or GSS auth is
being requested and then use multiple requests with that header and with
the body being base-64 encoded tokens until the session is established
at which point the original request is continued (possibly encrypted).
If the server doesn't know how to do SASL or GSS then its response would
lack the appropriate header and will be an error because the body of the
request will have been useless (except for GET requests).

Another possibility might be to standardize SASL/GSS/Kerberos in SSL and
be done.

That might be a way to start a discussion of a standard.

Who wouldn't want such a standard resolved??

Nico

On Fri, Apr 27, 2001 at 10:56:40AM -0700, Mike Fisk wrote:
> > reusable is just plain broken. 
> 
> "Broken" is subjective and I think we'll have to agree to disagree about
> the tradeoff between pragmatism and security.  I'd rather have something
> "less broken" that what people use now.
> 
> Wrong:
> 1. Passwords that people can remember and type tend to be very easy to
> guess.  A secret generated by a good PRNG can be much harder to
> brute-force.
> 
> 2. Keys can be re-negotiated much more frequently than passwords
> 
> 3. People can't remember enough passwords for each service to have a
> unique password.  Thus a rogue service can harvest passwords that are
> valid on many other services.
> 
> 4. Centralizing your database does improve security by giving a single
> point at which an account can be disabled.
> 
> Finally, you say that the system is "not secure" as if there was an
> alternative that was.  You're naive if you thing security is a binary
> attribute. 
> 
> At this point we're just going around in circles and probably annoying the
> rest of the list members.  It doesn't seem as though you and I will ever
> connect, and if we do, it should probably be done off the list.
> 
--

---

From: Derek Atkins <[email-masked]>
Date: 27 Apr 2001 12:29:14 -0400

Mike,

The disconnect here is that with Kerberos (or, indeed, any real
authentication system), you generally "prove" authentication by
showing "something you have" (SYH) and also showing "something you
know" (SYK).  In the Kerberos model, the SYH is your kerberos ticket.
The SYK is the session key.  You prove the SYH by just sending the
ticket, you probe the SYK by being able to encrypt data using the
session key (which happens to also be encrypted inside the ticket for
the server).

The problem with cookie systems is that you only have the SYH data,
the cookie.  There is no way to introduce a SYK.  How you transmit the
SYH and SYK proofs are completely irrelevant to the discussion.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Apr 2001 12:15:52 -0700 (PDT)

Just as a note, SIP is in the same predicament
with an even more complex set of issues. Jonathan,
Henning and I have been trying to figure out what
to do here, but a general mechanism for MIME based
proxy routed things like smtp, http, and sip could
be very interesting. We've been thinking along the
lines of providing a general framework that can 
accommodate many different authentication methods
so as not to get into the inevivitable pissing 
match about Kerberos, AAA, straight CA/PKCS, but
target a couple up front. Ie, here's how you use
Kerberos.

Yes, this sounds like something that people have
thought a lot about before (ala GSS), but the
sorry fact of the matter is that other
non-security related WG's find this work well
beyond their skill set and end up with some pretty
bizarre/inadequate authentication tools for their
protocols. While not like SIP, DIAMETER seems
headed down the path of "what's Kerberos?"
too. This is even more problematic because AAA and
Kerberos are heading for a big time collision
course but nobody seems to realize it (well,
maybe Bernard does :-)

Sigh.

	Mike

---

From: Mike Fisk <[email-masked]>
Date: Fri, 27 Apr 2001 10:56:40 -0700 (PDT)

Wrong:

---

From: Derek Atkins <[email-masked]>
Date: 27 Apr 2001 16:53:04 -0400

Along these lines I've been thinking of trying to define
a MIME multipart/security binding for Kerberos because of
some requirements from IMPP.

-derek

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 27 Apr 2001 15:03:40 -0700 (PDT)

> I think this all argues for a standard way to do SASL and/or GSS and
> or raw Kerberos V *network* authentication and session key exchange in
> HTTP.
>

There are two current internet-drafts proposing methods of doing SASL with
HTTP:

  draft-burdis-http-sasl-00.txt
  draft-nystrom-http-sasl-00.txt

There was some discussion of them at the last IETF, I think at the SAAG
session.  The first uses the HTTP Upgrade mechanism, ala the upgrade to
TLS in RFC 2817.  The second (I believe) makes SASL another HTTP
authentication method, ala HTTP-Digest.  I think the general sense is that
the Upgrade approach solves the problem more generally, but needs more
work to be complete.  I'm not sure if these are being discussed on some
list or not.

 - RL "Bob"