Re: ticket based authentication

At 4:47pm Aug 9, 2000, James G Smith wrote:

> I have put my thoughts together in the form of a draft

James,

I'm glad to see this taking shape. I have a longer note I haven't yet
sent, but here are some comments:

1) Privacy concerns. This looks like a "nice" alternative to third-party
banner-ad and web-bug cookies. Even "better", because 3rd party cookies
are only visible to the ad/web-bug server, where this could be used to
share the same identifier with the content provider and the
"authentication" provider.

2) Multiple credentials? E.G., if my content site needs to verufy both
that the user is an employee of Acme Products and a US citizen, would my
content site simply request one credential, and then the next iff the
first was acceptable?

3) Section 3.2. The expiration time provided by the authentication server
could be ignored by a (deliberately noncompliant) client. If you want to
be safe, you want a signed credential that includes an expiration time.

4) Nit pick. I'd suggest using example.(org|com|net) domains as examples.

5) Privacy #2: identity discovery. Send an HTML page that references a 1x1
pixel image. The URL for that image sends the client an authentication
challenge:
 WWW-Authenticate: Third-Party realm="CIA" url="https://login.cia.gov/"
and uses that to see if the user is able/willing to prove their
relationship with the US Central Intelligence Agency.

6) Auth server needs more info. The client should give the authentication
server some reason to go to the trouble of authenticating the client.
Authentication can be expensive, so the authentication provider might not
want to go to the trouble for unknown sites. This would also allow the
auth server to do nice tricks like encrypting the response for that
specific content site. It could even send garbage data in case of failure
to protect against identity tests.

7) Caching credentials/realm. If two different sites want me to
authenticate for WallyWorld on tehuti.nowhere.org, how does my client know
that it's OK to send the credential obtained for the first site to the
second site? I expect (maybe this should be clarified, or maybe I'm
dense) that the credential would be resent to any URL on the content site
that issues the same realm challenge. But should the client also only
provide the credential if the authentication "url" is the same? Should
there be a cookie-like path restriction?

-Peter

-- 
http://www.bastille-linux.org/ : working towards more secure Linux systems

Received on Wednesday, 9 August 2000 17:16:57 UTC