RE: ticket based authentication

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: jgsmith@hex.tamu.edu [mailto:jgsmith@hex.tamu.edu]On Behalf Of
> James G Smith
> Sent: woensdag 2 augustus 2000 16:34
> To: http-wg@cuckoo.hpl.hp.com
> Cc: JGSmith@TAMU.Edu
> Subject: ticket based authentication
>
>
> 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
>
>

Received on Wednesday, 2 August 2000 12:29:25 UTC