Subject: ticket based authentication

From: James G Smith <[email-masked]>
Date: Wed, 02 Aug 2000 09:34:07 -0500

I think I recall some mention that security related issues were 
not being dealt with by this group, but then I saw the RFC for 
Basic and Digest Access Authentication among this groups RFCs...

If this has been answered already, then a gentle reminder of 
where I need to look will be sufficient :P

+---
|
| I would like to propose an extension to the HTTP standard to 
  include yet another authentication scheme.  This would allow for 
  clients to use a third-party URL (third party being not the 
  client and not the site requiring authentication) to generate the 
  authentication credentials.

  This would allow for one site to know who someone is without 
  having access to the information which would prove their 
  identity.  This requires that the site requiring authentication 
  trust the site issuing the credentials.

  This allows for a central authority to issue credentials without 
  untrusted sites having sufficient information to reproduce those 
  credentials.  This can be important when the identity of the 
  untrusted sites may be unknown, or when the information used to 
  authenticate to the central authority may be legally protected.

  This scheme also solves the problem with POST requests and other
  requests with a body when trying to implement this scheme with
  the current standards (cookies and redirects) and with finite
  credential lifetimes.  With the client unaware of the overall 
  process, the user experience is severly affected.

  I believe this can be done within the present framework outlined 
  in RFC 2617.  

  The auth-scheme would be "ticket" or "third-party" or some other 
  sensical tag.  The auth-param would be `realm' as presently 
  defined.  Any parameters required by the site issuing the 
  credentials would be included in the URL for that site (see next
  paragraph).

  In addition to the challange, a location header would need to be 
  sent so the client knows where to go to obtain the credentials.  
  The client would need to not retry the request requiring the 
  credentials until it has obtained those credentials from 
  following the actions at that location.

  Any request for credentials with this scheme should preempt any 
  other request for credentials with this same scheme.  This allows 
  a client to only track one such request at a time, without 
  requiring an unbounded stack of nested requests, or even 
  unrelated requests.  This also allows for the third-party site to 
  use any other authentication scheme it might find necessary 
  before issuing the credentials.

  The third-party may issue the credentials in the response header 
  with the `Authorization' header line.  The client should be able 
  to use the contents of this header line verbatim in retrying the 
| original request.
|
+--

This is a bit rough in the description, but if there are any questions,
let me know.  If this is something worthwhile, I'll put together a more
formal description.
--
James Smith <[email-masked]>, 409-862-3725
Texas A&M CIS Operating Systems Group, Unix

---

From: "Life is hard, and then you die" <[email-masked]>
Date: Wed, 2 Aug 2000 08:46:05 -0700

>   authentication credentials.
[snip]

Isn't the algorithm=MD5-sess in Digest auth sufficient? The A1 is
basically your ticket. Or maybe I'm missing something.

  Cheers,

  Ronald

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 2 Aug 2000 14:13:10 -0400

> From: [email-masked]

> basically your ticket. Or maybe I'm missing something.

No, Digest as currently defined allows the http server to consult a
third party authentication server in order to obtain the secret (but
does not specify how that should be done).  It does not, however, meet
the need described here - that the http server be able to instruct the
client to first obtain credentials through the third party server.

--
Scott Lawrence

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 2 Aug 2000 21:26:08 +0200

You might look at Kerberos. Maybe this already provides what you want to
have in the authentication. However there needs to come a standard
describing how to use Kerberos authentication with HTTP.

At least I assumed Kerberos also used tickets e.d. Maybe that it needs to be
a bit modified (e.g. HTTP-Kerberos), because something with certificates (I
don't know how it all works).....

Only a suggestion......

- Joris Dobbelsteen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> James G Smith
> Sent: woensdag 2 augustus 2000 16:34
> To: [email-masked]
> Cc: [email-masked]
> Subject: ticket based authentication
>
>

---

From: James G Smith <[email-masked]>
Date: Wed, 02 Aug 2000 14:43:31 -0500

>don't know how it all works).....

This is what I was thinking.  However, I was not wanting to put the actual 
contents of the ticket, or credential, in the standard, becuase that depends 
on what the credential server and the website (which is requiring the 
credential) would need to agree on.  It could be kerberos, but it could also 
be a signed certificate issued by the credential server.

Basically, I'm looking for a standard that can give a fairly reliable user 
experience while allowing for transport of credentials issued to a client by 
one site to be used at another site, but without cookies and the other messy 
kludges required.

For example, if the site requiring the authentication requires 
reauthentication in response to a POST (e.g., the credentials have expired), 
that site must buffer the data until the request is retried with possibly a 
GET of some kind and the new credentials.  This can lead to DOS attacks on a 
site.  By requiring the client to buffer the POST and retry again, we avoid 
that situation and make for a more reliable user experience.

By avoiding nested authentication attempts of this type, we avoid the same 
buffer problem on the client side.
-- 
James Smith <[email-masked]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

---

From: "David W. Morris" <[email-masked]>
Date: Wed, 2 Aug 2000 19:02:07 -0400 (EDT)

While not commenting directly on the proposal, I would note in my
application deployment role ... firewall and application service provider
issues make the missing function Scott mentions an important capability.

Thanks,
  Dave Morris