Subject: RE: Using "Cookies"?

From: "Shishir Nagaraja" <[email-masked]>
Date: Fri, 04 May 2001 06:47:11 -0600

Paul,     
In kerberos the SYH, can be had by anybody else as well. You just need to sniff it off the wire. Its only the SYK, the session key in the service ticket that counts.

Shishir.

>>> "Friedrichs, Paul LCDR" <[email-masked]> 04/28/01 12:25AM >>>

I can see that Kerberos may have been designed to provide a two-factor
authentication service over the network. But is it truly significant that a
ticket be a secret? I get the impression this weakens the argument for
Kerberos. I'm very impressed with the possible strength of the encryption
over the ticket and the possible strength of the crypto module that's
protecting the client's session key. But if confidentially of the already
encrypted ticket is argued to be necessary or significant, then I think I
would be much less impressed with Kerberos.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]] 
> Sent: Friday, April 27, 2001 12:29 PM
> To: Mike Fisk
> Cc: Friedrichs, Paul LCDR; [email-masked]; [email-masked] 
> Subject: Re: Using "Cookies"?
> 
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -derek
> 
> Mike Fisk <[email-masked]> writes:
> 
> > On Fri, 27 Apr 2001, Friedrichs, Paul LCDR wrote:
> > 
> > > Mike,
> > > 
> > > Am I correct in understanding that this appears to 
> address only the
> > > authorization portion of the Kerberos functionality? 
> > 
> > I wouldn't say so.
> > 
> > > 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? 
> > 
> > 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
> > > catastrophic while the loss of control of a Kerberos 
> ticket wouldn't matter
> > > much at all?
> > 
> > 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.
> > 
> > > 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
> > > > 
> > > 
> > 
> > -- 
> > Mike Fisk, RADIANT Team, Network Engineering Group, Los 
> Alamos National Lab
> > See http://home.lanl.gov/mfisk/ for contact information
> > 
> 
> -- 
>        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
>