Subject: Re: Using "Cookies"?

From: [email-masked]
Date: Wed, 25 Apr 2001 05:44:08 -0500

From ftp://ftp.isi.edu/in-notes/rfc2964.txt:

...
2.2.2 Use as an Authentication Mechanism

It is generally inappropriate to use the HTTP State Management protocol as
an authentication mechanism.  HTTP State Management is not designed with
such use in mind, and safeguards for protection of authentication
credentials are lacking in both the protocol specification and in widely
deployed HTTP clients and servers.  Most HTTP sessions are not encrypted
and "cookies" may therefore be exposed to passive eavesdroppers.
Furthermore, HTTP clients and
servers typically store "cookies" in cleartext with little or no protection
against exposure.  HTTP State Management therefore SHOULD NOT be used as an
authentication mechanism to protect information from being exposed to
unauthorized parties, even if the HTTP sessions
are encrypted.
...

The net of this is that it's a VERY BAD IDEA to use cookies for any
authentication credentials, including Kerberos.

"Jung, Edward (Edward)" <[email-masked]>@achilles.ctd.anl.gov on
04/24/2001 06:48:26 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Using "Cookies"?

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: "Booker C. Bense" <[email-masked]>
Date: Wed, 25 Apr 2001 09:30:06 -0700 (PDT)

On Wed, 25 Apr 2001, Mike Fisk wrote:

> Nonetheless, many people do use cookies for plaintext, reusable
> credentials.  When a cookie is issued without an expiration date, clients
> are to store it in memory only.  This tends to have at least as much overt
> access control as a credentials cache in /tmp.  A few years ago, I
> proposed to one site a Kerberos-based cookie/form-data mechanism as a
> replacement for their existing cookie-based authentication system.
>
> The main advantage of using something like Kerberos is that you can have
> single sign-on between application servers, yet not reveal to any of those
> application servers a secret that is usuable at other servers.
>
> My proposal required no browser modifications and relied on a single
> trusted web server to perform ticket requests on behalf of the user.  The
> browser stores a TGT cookie for just that server.  The trusted proxy can
> use the presented TGT cookie to get a service ticket and redirect the
> browser there with the service ticket passed as form data.
>

- There is a system very much like this in production at Stanford
University. We call it webauth, in our system the browser stores
a service ticket for the web site you wish to contact. You can find
out more about webauth by searching on the www.stanford.edu page.

- Booker C. Bense

---

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

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

---

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

What are the  known issues between Kerberos and NAT?

For example:

a. What attacks are prevented by placing IP addresses within tickets and
checking them? 

b. What vulnerabilities would be exposed by not doing this? Are there
alternate ways of addressing them?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Apr 2001 15:12:03 -0400

> a. What attacks are prevented by placing IP addresses within tickets and

This limits what IP addresses can be used as the source addresses of IP
UDP packets/TCP sessions containing Kerberos AP_REQs.

Thus, if you have address-limited Kerberos credentials (TGTs) and you
wish to use them on a host other than the one(s) identified in the
ticket address list, then you must: a) obtain FORWARDED credentials, b)
forward those credentials to the host in question. But (a) can be done
only from the host(s) whose addresses are listed in the credentials you
do have, and the FORWARDABLE flag MUST be set in the credentials and the
TGS(s) have to agree to the forwarded credentials request.

Else you're stuck on the host(s) whose addresses are listed in the
credentials you have.

> alternate ways of addressing them? 

Credentials can be used on any host, and no tracks of the forwarding of
such forwardings will be left on the KDCs' logs. This may be a
convenience to users, and even more so to any attacker who manages to
steal live credentials.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Apr 2001 15:20:35 -0400

One more thing. This all assumes that the source IP address of IP
packets are not easy to spoof. This is not always (usually? :) true, but
even if you have shared media and untrusted routers in your network, TCP
can be made reasonably hard to spoof. Which is why I think it's worth
keeping and even expanding on this feature of Kerberos.

Nico

On Wed, Apr 25, 2001 at 03:12:02PM -0400, Nicolas Williams wrote:
> .
--

---

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

> a. What attacks are prevented by placing IP addresses within tickets and

It could potentially make reuse of a stolen Kerberos ticket cache
more difficult.  Some uses with some applications may only accept
authentications from the IP-Addresses that are in the ticket.
Note that this is limited to native Kerberos applications
and to those few GSS-API based applications that do use
channel bindings.

When GSS-API based applications don't use channel bindings,
the addresses in the tickets will be ignored.  
Microsoft W2K Kerberos doesn't even offer/implement the gssapi channel
bindings facility, so their apps and services might be ignoring
IP-Addresses in tickets as well ...
 
> alternate ways of addressing them? 

Not using addresses in ticket does *not* add vulnerabilities.

-Martin

---

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

> convenience to users, and even more so to any attacker who manages to

But wouldn't the attacker also need to obtain the session key so as to be
able to compose a valid Authenticator? If a client can provide both a
valid ticket and Authenticator, what additional protection does an IP
address check provide?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Apr 2001 16:37:01 -0400

> valid ticket and Authenticator, what additional protection does an IP

I said "... to any attacker who manages to STEAL LIVE credentials."

To me that means that the attacker has the decrypted credentials. In MIT
krb5 terms: the attacker stole a user's ccache which contained at least
one live ticket, possibly a TGT.

As for the additional protection provided by the IP address check: the
attacker is pinned to the given host and must talk to the TGS to forward
stolen creds, thus leaving tracking information on the KDC. This is not
additional protection.

The addresses in tickets provide a way to control credentials forwarding
at the KDC.

Ticket proxying is too fine grained to be useful and ticket forwarding
is too coarse to be useful in limiting the damage that can be caused by
forwarding credentials to a trojaned service.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 25 Apr 2001 15:16:27 -0700 (PDT)

While I really don't have much to contribute here,
I'll point out that it's not just evil NAT's that
are at issue. Multihoming, mobility and
renumbering might cause hidden assumptions about
IP address stability to cause trouble.

	   Mike

---

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

> valid ticket and Authenticator, what additional protection does an IP

It means I can't take your credentials cache and use it from my machine.
Perhaps my machine is monitored less or may be allowed to do things
that your's isn't.  Perhaps not.

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Apr 2001 12:25:29 +0200 (MET DST)

On Wed, 25 Apr 2001, Mike Fisk wrote:
> access control as a credentials cache in /tmp.

I *strongly* disagree!

Cookies are a mechanism for automatic and aggressive re-distribution
(=replay) of a constant piece of information.  The means to
control Cookie distribution are *NOT* access control mechanisms at all,
they work only moderately well and there are plenty of known bugs and
features to get around these distribution control mechanisms for those
who like to get their hands on it. 

A credential cache in the filesystem on a serious operating system
is protected by a *real* access control mechanism, and there is
no inherent urge in a filesystem to distribute this information
to the world.

A credential cache is also not mixed into arbitrary application
data, and therefore application are significantly less likely
to accidentally leak its contents.

>                                                 A few years ago, I

You proposed a single break-in solution.  Take over the webserver
and you can collect Kerberos credentials of everyone and just walk
into every other machine as well.

> browser there with the service ticket passed as form data.

No matter what you do, the resulting authentication scheme will
*NOT* be Kerberos at all.

As I explained before, HTTP-Cookies are a pure replay mechanism
and the Kerberos protocol has replay-protection as one of it's
key features, so they simply don't go together.

I could think of two scenarios that involve Kerberos, but that
do not use Kerberos authentication (in the Cookie):

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".

> out more about webauth by searching on the www.stanford.edu page.

From a quick glance, this looks like option (1).
I think this is an EXTREMELY dangerous approach, and their Warning:

Caution: Do not enter your SUNet ID and password on any other Web page

will save them.  Once a user gets accustomed to typing
his Kerberos password into a Web Browser (or in other situations
during work) he will casually leak it in all the wrong places!

For the average user the Kerberos password should only be requested
and typed during machine logon and *NOWHERE* else (with the exception
of the screen-lock maybe).  Anything else is calling for trouble.

-Martin

---

From: "Booker C. Bense" <[email-masked]>
Date: Thu, 26 Apr 2001 07:40:02 -0700 (PDT)

> during work) he will casually leak it in all the wrong places!

- Well, we don't think it's a great idea either. The web page login is
a fallback for those users that don't have our kerberos sident
responder installed on their workstations. If you install our kerberos
clients you never see that web page, however for our version of real
world deployments something like this is required. We assume that you
have an ssl-capable web browser and nothing else as a least common
denominator.

> of the screen-lock maybe).  Anything else is calling for trouble.

- If you take this approach you will never be able to use the web to
provide kerberos authorized services. The webauth system at stanford
has been extremely successful in deploying applications and getting
people to buy into the idea of a single sign-on. It's not ideal, but
it's better than the alternative of every department on campus
maintianing it's own set of usernames and passwords. Perhaps we've
compromised too far on the scale of usablity vs. security, but to
date the system has proven to be extremely useful.

- Kerberos doesn't create security and trust it can only extend it.
It's way to take two things you believe to be secure [1] and extend
that security to other systems. In the case of cookies, the security
of one of the bits[2] is questionable, but at least preferable to the
alternatives.

- Booker C. Bense

[1]- The machine that runs the KDC and the local filesystem or cache
store.

[2]- the credentials cache.

---

From: "E. Larry Lidz" <[email-masked]>
Date: Thu, 26 Apr 2001 10:26:55 -0500

>date the system has proven to be extremely useful.

The lack of any good way of doing Kerberized web authentications
(barring lots of locally developed applications like sident) is one of
Kerberos's major failings at this point. 

So far, we've stuck with the hardline "No kerberos passwords over the
web." However, the number of places that require web-based
authentication are great. We're having to support more passwords than
we'd like and there is a fairly strong demand to stop using Kerberos
entirely. 

We'll probably end up compromising and running something like Stanford's
Webauth. We'll end up treating that machine much more like a KDC in
terms of our security mechanisms than a standard web server, but it's
all we can do until there's a better mechanism for Kerberized web
authentication.

-Larry

---
E. Larry Lidz                                        Phone: (773)702-2208
Sr. Network Security Officer                         Fax:   (773)702-0559
Network Security Center, The University of Chicago
PGP: http://security.uchicago.edu/centerinfo/pgpkeys.shtml

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 26 Apr 2001 11:36:48 -0400

>Kerberos's major failings at this point. 

Is this a failing of Kerberos, or more a failing of one particular vendor
(Netscape), who as far as I can tell is not providing the right plugin
for no good reason?  At least (from things that I hear) the Microsoft
folks are doing some form of Kerberized web authentication, but Netscape
isn't doing anything.  The very fact that things like sident/sidecar even
exist should be in my mind proof that people out there want Kerberos
authenticated web pages, but somehow the folks at Netscape don't see
it that way.  Sigh.

--Ken

---

From: "Booker C. Bense" <[email-masked]>
Date: Thu, 26 Apr 2001 09:22:42 -0700 (PDT)

On Thu, 26 Apr 2001, Ken Hornstein wrote:

> for no good reason?

- I wouldn't call it "no good reason", until very recently the API
situation on both PC's and Macs has been very fractured.

>  At least (from things that I hear) the Microsoft
> isn't doing anything.

- That isn't the story I heard from MS when I was there last summer.
"maybe someday" is what they were telling the edu crowd.

> The very fact that things like sident/sidecar even

- You can go the plugin route, but that has it's own pitfalls. Umich
developed one for earlier versions of netscape, I don't know if they
ever deployed it in production though. I don't think
there's anything stopping you from writing a k5 plugin with the
current Netscape, but the problem with this approach is that it
requires a lot of support and really limits what web clients you can
use.

- If we were in the position to tell everybody what web client
( and hardware ) to use then there are much better solutions than
ours.

- Booker C. Bense

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 26 Apr 2001 09:21:46 -0700 (PDT)

> browser there with the service ticket passed as form data.

Schemes more or less along this line have been invented and reinvented
countless times in the last few years, by universities, corporate IT, and
commercial vendors (among universities:  UIUC, NCSU, Stanford, Washington,
Brown, Michigan, and Minnesota are just a few of the many).  New ones are
being invented daily, it seems.  Some are more Kerberos-dependent than
others, some more cookie-dependent than others, but the basic idea of a
"weblogin" server that creates ticket-like things that are consumed by
target web servers has been extremely popular.

There is, in fact, an effort (at least one) to standardize this kind of
thing, motivated by the products of many vendors in this space bumping
into each other in real-world deployments, and not having any
interoperability since they're all proprietary.  See:

   http://www.oasis-open.org/committees/security/

for info on the initiative.  I'll note that among the vendor participants
are quite a few who are very knowledgable about Kerberos, and quite a few
PKI folks too.  And just to be clear, the scope is not just weblogin but
more general application security exchange.

 - RL "Bob" Morgan
   University of Washington

---

From: "E. Larry Lidz" <[email-masked]>
Date: Thu, 26 Apr 2001 11:26:29 -0500

>authenticated web pages, but somehow the folks at Netscape don't see

I agree, it's a failing of Netscape, but it's Kerberos's future that is
damaged by it, not Netscape's... 

-Larry

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Apr 2001 12:33:08 -0400 (EDT)

> Kerberos's major failings at this point. 

To be fair, this is not a failing of Kerberos.  It is no harder to use
Kerberos to authenticate HTTP than for any other protocol.  An HTTP
Kerberos auth mechanism was defined many years ago; the problem was that
only Mosaic ever implemented it.  There is a standards-track Kerberos
ciphersuite for SSL, but apparently no one implements that either.

Needless to say, life would be much easier if the browser and web server
vendors would implement these things, instead of insisting that all
problems can be solved using public-key crypto with a poorly-designed
excuse for a PKI.

> all we can do until there's a better mechanism for Kerberized web

I strongly suggest looking into the Minotaur project here at CMU.  It's
basically a mechanism for providing Kerberos authentication to web
services by using a browser plugin.  The kweb plugin is available for
Netscape and IE on most major platforms, and there is a java applet for
users who don't have a supported browser.  Server-side support exists for
both Netscape and Apache (even though the page below claims apache support
isn't done yet; that hasn't been true for a long time).

Take a look at http://andrew2.andrew.cmu.edu/minotaur/

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

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 26 Apr 2001 09:38:38 -0700 (PDT)

On Thu, 26 Apr 2001, Ken Hornstein wrote:

> At least (from things that I hear) the Microsoft folks are doing some
> form of Kerberized web authentication, but Netscape isn't doing
> anything.

It is my understanding (though I could easily be mistaken) that between
Win2000 clients and servers (or more precisely, clients and servers with
some appropriate level of SSPI support) that IE and IIS can authenticate
via an exchange that more or less puts GSSAPI tokens into HTTP
authentication headers.  The negotiation includes SPNEGO and hence can use
any supported GSS mechanism, including Kerberos and NTLMv2.  I think this
is acknowledged to require TLS to protect the connection from precisely
the kinds of attacks we've been discussing.

I've heard a rumor that a better version is being prepared and written up
for possible standardization.  I've also heard a rumor that the method is
being reverse engineered for inclusion in Apache and perhaps Mozilla.

 - RL "Bob"

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 26 Apr 2001 12:55:08 -0400

>There is a standards-track Kerberos

It's actually implemented in the source code of OpenSSL available from
anonCVS.

>I strongly suggest looking into the Minotaur project here at CMU.

I looked at Minotaur, but it seemed like it was intended never to escape
CMU (e.g, I could never find the source code to the plugins).

--Ken

---

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

You could always provide a "service" that uses kerberos to
authenticate a transaction to supply Web Certificates (where
you have your own CA) and then you can use that Web Cert
to authenticate via SSL to your web servers.

-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: Ken Hornstein <[email-masked]>
Date: Thu, 26 Apr 2001 12:50:09 -0400

>situation on both PC's and Macs has been very fractured.

They don't have to write to any APIs; they could provide plugin support
at the appropriate points, but they don't even do that.  We've had meetings
with Netscape; they said "We're sticking with PKI", and they said that
they didn't understand us, they already support Kerberos ... on their
servers, of course, and they really only meant they support V4 Kerberos
password verification .... arrrrggghhhh.

>"maybe someday" is what they were telling the edu crowd.

AFAIK, this already exists today (of course, it's between IE and IIS, but
see Bob Morgan's email).

>requires a lot of support and really limits what web clients you can

My problem is the plugin route really isn't feasible today; you're not given
a point where you can do Kerberos in a reasonable way.  If you look
at all the schemes out there (and believe, me, I have) they all pretty
much suck one way or another.

>( and hardware ) to use then there are much better solutions than

I don't have a problem telling people to use a particlar web client;
I mean, let's face it ... we already are doing that to a limited extent
today (we're not providing any OS/2 or VMS Kerberos support, for example).

--Ken

---

From: "E. Larry Lidz" <[email-masked]>
Date: Thu, 26 Apr 2001 12:09:52 -0500

>ciphersuite for SSL, but apparently no one implements that either.

There's modkssl, which is available at: 

  <http://sourceforge.net/projects/kssl>. 

There's also Minotaur (as you mention), UMich's kx509, and a bunch of
other projects. 

I've yet to find a single one, though, which supports Kerberos V and
works with Netscape, IE, Apache, and IIS without significant additional
programming. 

From a practical standpoint (and this might not be the proper venue
for this discussion, and I appologize for that), it's a fairly serious
problem for organizations which are attempting to use Kerberos on a
wide scale.

-Larry

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Apr 2001 13:09:12 -0400

> situation on both PC's and Macs has been very fractured.

Does Netscape provide a directory client? One that supports SASL? On
which platforms?

If yes, yes and Mac, *nix and Windows, then why not develop SASL auth
for HTTP?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Apr 2001 13:39:24 -0400

On Thu, Apr 26, 2001 at 09:38:38AM -0700, RL 'Bob' Morgan wrote:
> any supported GSS mechanism, including Kerberos and NTLMv2.

>                                                              I think this

Why? There's no need to protect AP_REQs/AP_REPs nor is there a need to
protect GSS w/SPNEGO.

> being reverse engineered for inclusion in Apache and perhaps Mozilla.

The second would be good, the first would be better. In any case, a
standard is needed.

>  - RL "Bob"

Cheers,

Nico
--

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 26 Apr 2001 11:55:42 -0700 (PDT)

> Why? There's no need to protect AP_REQs/AP_REPs nor is there a need to

(Again, this is based on unconfirmed discussion ...)

It's not the authentication exchange itself that needs extra protection,
it's the application session post-authentication, since there is not any
use of the GSS/Kerb-negotiated session key to protect the data stream (ie,
no gss_wrap).  Sorry I didn't make that clear.  Of course, the possible
disconnect between the TLS-provided identity of the server and the
Kerberos-provided identity of the server is also a problem; presumably a
next-generation version would fix both of these.

 - RL "Bob"

---

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

> into every other machine as well.

Yes, but there is only one such server in this model.  This replaces other
single sign-on cookie schemes in which ANY participating server can be
used to harvest credentials that can be used at any other service.

KDC's are a "single break-in solution" as well.

> of the screen-lock maybe).  Anything else is calling for trouble.

In many environments, you cannot control the configuration of the
environment enough to set things up this way. 

The Stanford scheme seems to be as good as anyone has gotton with
cookie-based authentication.  And cookies is what a big chunk of the world
is stuck with.

---

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

> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Apr 2001 15:32:22 -0400

> next-generation version would fix both of these.

Ah. Got it. Well, a standard that addresses all this is needed. Or
perhaps SSL w/ Kerberos will do. ??

Nico
--

---

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

> to authenticate via SSL to your web servers.

Doug Engert has such a service.  It was designed to issue x509 certs for
the Globus project.  But if you can't depend on client software on the
browser machine, then it's probably easier to use a web server to issue
the cert.

---

From: Mike Fisk <[email-masked]>
Date: Thu, 26 Apr 2001 14:01:07 -0700 (PDT)

On 26 Apr 2001, Derek Atkins wrote:

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

> If you can't depend on the client software
> then ALL is lost -- you can't depend on it not to email all your
> keystrokes to the NSA (or your mother :) 
>
> That's just not a reasonable assumption to be making here.

You completely misinterpreted my comment.  I was talking about the ability
to require that the client system have special software.  You may not be
able to depend on having anything more than a basic browser.  So you can
issue certs via HTTP, but probably not via k5get509cert over port 1234
using GSSAPI.

> We have to assume some level of trust of the client machine, otherwise
> you shouldn't be typing your password at the keyboard.  What I'm
> worried about is: how do I know I can trust the SERVER?
> 
> 1) I don't want my password to cross the network.  Period.  I don't
> care if it's encrypted or not.  It should be used locally.  This
> implies using the full kerberos protocol to obtain credentials.
> Unfortunately this wont work with current browsers as-is (although
> I have some ideas to workaround this).

Then why do you let the KDC have your secret key?  Maybe you should use a
PKI.

> 2) a server should not be able to obtain and (re-)use my long-term
> credentials.  This means a rogue server shouldn't be able to spoof me
> and then obtain my credentials and be able to re-use them in the long
> term.  I'm probably willing to live with the 5-minute authenticator
> window, but I'd even prefer to limit that.
> 
> 3) cookies, as specified today, just cannot solve this problem.

Then don't use the web as it stands today.
I'm worried about a weaker, but more saliant problem.

---

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

> browser machine, then it's probably easier to use a web server to issue

I've got such a service.  Jeff Schiller has such a service.  Honestly
they're not hard to build.  If you can't depend on the client software
then ALL is lost -- you can't depend on it not to email all your
keystrokes to the NSA (or your mother :) 

-derek

---

From: Kevin Coffman <[email-masked]>
Date: Thu, 26 Apr 2001 17:09:07 -0400

> works with Netscape, IE, Apache, and IIS without significant additional

kx509 now supports Kerberos V.  The updated source, etc., should be
available RSN.

---

From: Matthew Hur <[email-masked]>
Date: Thu, 26 Apr 2001 18:42:38 -0700

> > >ciphersuite for SSL, but apparently no one implements that either.

- I've been communicating with some guys who are looking to add the latest 
draft (which will obsolete the RFC) to mozilla.
- I've been told that a fellow is/has implemented fro OpenSSL.
- Microsoft has expressed interest in implementing the latest draft in some 
future release.

I guess we'll see...

--Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Apr 2001 12:43:31 +0200 (METDST)

> 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

What exactly do you want to store in your tickets?
Do you want to integrity/confidentiality protect some/all of the
information in your cookies?  Which, how and for what purpose?

What can be done with the information in the cookie in case 
the cookie is leaked to an attacker?

-Martin

---

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

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]
> 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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 27 Apr 2001 13:48:49 -0400 (EDT)

> trusted.  It's your typical trusted third-party model.  

This is about as good as you're going to get today with an unmodified
browser.  It's not great, and there are several potential vulnerabilities,
but it's still the best you can do _with cookies_.

Now, why are people intent on using a Kerberos ticket, or even a complete
set of credentials (with unencrypted session key!) as a service cookie? 
You can use anything signed by the cookie-granting service in some way
that allows the services to verify it -- there's nothing to be gained by
making it a Kerberos ticket.

A better approach would be to use as a cookie a block of data identifying
the user which is signed using a public key pair belonging to the
cookie-granting service.  All of the web services could know the CGS's
public key, and thus be able to verify identity based on the same cookie.
You could even include a chain of signatures in the cookie, such that
foreign users could be authenticated by including a copy of their CGS's
key signed by the local CGS.

Even better, one could use an approach where clients _do_ have to prove
knowledge of a secret key.  This approach would require no new code in the
browsers or web servers, because they already support it, in the form of
SSL client certs.  If you care about tying into an existing Kerberos
infrastructure, you can do that too -- more than one organization has
services which grant certificates based on Kerberos authentication.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Apr 2001 19:56:04 +0200 (METDST)

> For a service-cookie:  only access that particular service for some
 
OK, I see much clearer now what you're thinking of.

There are two things I'd like to mention:

Although your scheme "involves" Kerberos credentials
(i.e. a Kerberos ticket accompanied by its session key),
it is clearly not a _Kerberos_authentication_.
It's a disclosing password-based authentication where
the username is (encoded in) the ticket and the password is
the session key for that ticket.  I hope that the lifetime limit of
the service ticket is being used in this scheme.

The issue with the rogue Web-Server was not that it will be able
to see and leak the service cookie.  With the browsers and browser
settings in use today, there is a 95% probability for a rogue Web-Server
to retrieve a cookie with a predetermined distribution-limitation
from any browser that connects to it.

If you go as far as using a TGT with its secret key into that
cookie-granting-cookie, then this will put *all* Kerberos-protected
resources in that realm at a great risk -- you should at least
set up an isolated Kerberos realm for only that particular purpose.

-Martin

---

From: Mike Fisk <[email-masked]>
Date: Fri, 27 Apr 2001 11:03:30 -0700 (PDT)

> it is clearly not a _Kerberos_authentication_.

If you recall, my original message talked about a "Kerberos-based
cookie/form-data mechanism as a replacement for their existing
cookie-based authentication system" and talked about the "advantage of
using something like Kerberos".

I never claimed that it was Kerberos.  I used words like tickets because
it describes the semantics that you get it from a TGS and use it for a
specific service.  Unfortunately, many people assumed that I meant an
actual Kerberos authentication exchange.

> set up an isolated Kerberos realm for only that particular purpose.

Yes, that's an option that I had considered.  I'm not sure how places like
Stanford do it.

---

From: Theodore Tso <[email-masked]>
Date: Fri, 27 Apr 2001 15:46:05 -0400

> actual Kerberos authentication exchange.

I think you would do a lot better if you simply didn't call it
Kerberos, or use Kerberos terminology.

Here's a concrete design of what I think you're trying to do.  

(1)  The user enters their username and password into a server's web page.

(2)  The server validates the password and then creates the following cookie:
	{ username, exp. date, MD5 (username, exp. date, server secret) }

(3) The client can the present that cookie to the server to
authenticate future web pages.

See?  It has absolutely nothing to do with Kerberos!  (At which point
we can ask the question why we're discussing this on the IETF Kerberos
wg mailing list.)

You had talked about wanting to do single sign-on, but that's not
really possible if we assume the constraint of not modifying the
browser.  One could posit a Kerberos-authenticated service which used
Kerberos for authentication and which shared a secret with the web
server.  Such a service could generate cookie defined in step (2), but
there's no portable way to get that cookie into the browser.

						- Ted

---

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

> Kerberos, or use Kerberos terminology.

Yes, staying away from overloaded terms seems to have helped in the last
few messages.  In previous discussions elsewhere, the abstract concepts
implied by kerberos terms aided the discussion.  In this context, people
are more engrossed in the details rather than the abstractions.  Believe
it or not, several people at different institutions found that Kerberos
was a starting point for developing this type of system.

> we can ask the question why we're discussing this on the IETF Kerberos

Ted, 

Sorry, but you too have missed the idea.  There is more to it and that
additional part is what makes it similar to Kerberos (at least to some of
us).  You're model only has one "server" rather than a cookie-granting
service and multiple other (cookie-consuming) services.

> browser. 

Perhaps this is yet another mis-understanding.  I was just referring to
single sign-on between web servers not with other kerberized
applications (which obviously isn't possible with non-kerberized
clients).

---

From: Theodore Tso <[email-masked]>
Date: Fri, 27 Apr 2001 17:41:40 -0400

> service and multiple other (cookie-consuming) services.

So now you're assuming that users will be willing to configure
their clients to allow cross-server cookies.  (Umm, not.)

Actually, if you're using the model of asking the user to do a
password authentication at a central location, and then reuse that
authentication at other sites, then why not simply use x.509 client
certificates and be done with it?

At MIT, you can use your Kerberos password to get an X.509 client
certificate where the E-Mail name portion of the subject name in the
x.509 client cert is the Kerberos username.  That client certificate
can then be used to access a wide variety of web services at MIT.  The
client certificate can be treated as disposable, since it's so easy to
get another one.  So you can simply request a certificate with a
one-day validity if you're surfing the web from the kiosk, and simply
delete the certificate from the browser's certificate store when you
leave the kiosk machine.

It also means that the problem of what to do if the user forgets their
passphrase protecting their x.509 private key is trivial; they can
just throw it away and get another one.  And if they forget their
Kerberos password, that's a previously solved problem; they just have
to go to User Accounts and have their password reset.

That basically does what you're looking for, without needing to make
any browser changes.

						- Ted

---

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

> their clients to allow cross-server cookies.  (Umm, not.)

You can also have the cookie sent as form data in a HTTP POST.  That's my
preference (since I don't like cookies) for systems that I've done, but
most people speak in terms of cookies.

> certificates and be done with it?

This is getting off-topic, but we couldn't even get our users to download
and accept an in-house CA cert (and they only have to do that _once_).  I
think making them get user certificates would be a nightmare.

---

From: Derek Atkins <[email-masked]>
Date: 27 Apr 2001 18:31:01 -0400

> most people speak in terms of cookies.

The problem with POST data is that it requires extra code in every CGI
application to parse the cookie out of the form, and it implies that
you're actually performing POSTs instead of GETs.  Neither of these
are, IMHO, a reasonable assumption for web developers.  I've written
web apps that work both ways, and generally I like to use a
combination of GET and POST.  Indeed, when I really want web
authentication my method of choice is still SSL with user certs.

> think making them get user certificates would be a nightmare.  

Wow.  Are your users complete idiots?  Seriously, have you actually
done any studies to figure out _why_ they can't download and accept an
in-house CA cert?  Downloading a new CA cert is REALLY EASY -- the only
potential problem is that the user may be scared by the warnings
and decide not to actually install the new certificate.

Technically, you just need to setup a link to the CA cert and have the
user click on it (and then accept it into their browser).  Granted,
this latter portion might be the major issue, but this is an education
problem, not a technical one.  If an MIT freshman can do this, I'm
sure that employees of one of this country's most prestigious Lab's
would be able to do it...  Unless, of course, there are other
technical issues keeping it from working.

Anyways, this is way off topic now.

Good Luck,

-derek