- From: James G Smith <JGSmith@tamu.edu>
- Date: Wed, 02 Aug 2000 14:43:31 -0500
- To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
- cc: JGSmith@tamu.edu, "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
"Joris Dobbelsteen" <joris.dobbelsteen@mail.com> wrote: >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...... 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 <JGSmith@TAMU.Edu>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Received on Wednesday, 2 August 2000 12:42:37 UTC