Subject: ticket based authentication

From: James G Smith <[email-masked]>
Date: Wed, 09 Aug 2000 16:47:09 -0500

From the response, it would seem some form of third-party 
authentication may be desired and useful, but no clear concensus 
on how best to go about it.  I don't have an answer to that, but 
I have put my thoughts together in the form of a draft, which 
should appear sometime as 

     draft-smith-http-third-party-authentication-00.txt 

Until it is posted on the IETF site, it is available from my
own workstation at 

  http://hex.tamu.edu/drafts/draft-smith-http-third-party-authentication-00.txt 

I already have a correction for it -- the expiration time should 
be in GMT (section 2.2).

An issue that is not addressed is how to indicate that the client
should abandon the authentication process and discard the pending
request awaiting credentials.  The authentication process MUST
indicate one and only one of success or abandonment.  When in doubt,
the client may abandon the process?  This could be the case if
the client becomes confused as to what is going on.
--
James Smith <[email-masked]>, 409-862-3725
Texas A&M CIS Operating Systems Group, Unix

---

From: Peter W <[email-masked]>
Date: Wed, 9 Aug 2000 20:11:33 -0400 (EDT)

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

---

From: James G Smith <[email-masked]>
Date: Thu, 10 Aug 2000 10:14:19 -0500

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

>content site simply request one credential, and then the next iff the

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="[email-masked]", 
             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.

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

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

>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 <[email-masked]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix