ticket based authentication

James G Smith (JGSmith@tamu.edu)
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 <JGSmith@TAMU.Edu>, 409-862-3725
Texas A&M CIS Operating Systems Group, Unix