- From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
- Date: Wed, 2 Aug 2000 21:26:08 +0200
- To: JGSmith@tamu.edu
- Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
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