Re: ticket based authentication

Peter W <peterw@usa.net> wrote:
>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.

Good point.  We need some way for the client to know that the 
user should be aware of the authentication request so it isn't 
silently taking place.  The user should have a way to refuse 
authentication as with Basic and Digest.  Of course, refusal with 
those two is by virtue of the user having to usually enter some 
information.

One important difference between cookies and the credentials in
this scheme are that cookies can persist across client invocations.
We are explicitly disallowing / discouraging such behavior in
the draft.

>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?

I was not thinking so much of authorization but of authentication.  
The credential would say this person is who they say they are, 
and no more unless agreed to by the site requiring the credentials 
and the site providing the credentials prior to the request.

Perhaps be able to form a request such as:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Third-Party realm="testrealm@host.com", 
             url="https://tehuti.nowhere.org/authenticate/",
             ou=acme, c=us

The other end might then require that the ou and c fields match
in the ldap entry for the person authenticating.  Of course,
this is not the best example for this situation, but it does
illustrate what is possible in the draft.

>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.

Having implemented something along these lines before with cookies 
and redirects, I would expect the site issuing the credentials to 
encode the expiration time in the credentials.  The expiration 
given to the client would be purely advisory on their part.

This could be placed in a section for recommended practices in
creating credentials.

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

-nod-

>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.

Good point.  We need a good way for the two sites involved to authenticate
themselves to each other.  The credentials can authenticate the issuer
to the requester, but there isn't a good method for the other way around
yet that is scalable.

One way is to send a signed identifier as part of the request (the
WWW-Authenticate header).  This requires communication between
the issuer and the requesting site `behind the scenes'.  If this
could be made sufficient, it could be placed in the `recommended
practices' section.  This could also address the next issue (#6).

>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?

We do need to be able to specify the scope of the credentials.  With
Basic and Digest, it's trivial.  They are only good on the site which
requested them and for the realm.  Perhaps a combination of `url' and
`realm' could be used.  But then we have the issue of sites requesting
them when they shouldn't have them...

Allowing some scoping rules that cookies have would help here.  We
can create a system that is no worse than cookies :P  That's not
all that comforting, but we do have a worst case scenario.

When I worked on something similar to this, but with cookies, the
credentials would have been passed to any machine in the .tamu.edu
domain since that allowed us to have a central server able to
issue to any other machine in the TAMU network, it kept machines
from outside TAMU from using it, and it would allow people to
authenticate once and hop from site to site.
-- 
James Smith <JGSmith@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Received on Thursday, 10 August 2000 08:17:11 UTC