Re: ticket based authentication

"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