Subject: Re: sketch of a simple authentication protocol

From: Story Henry <[email-masked]>
Date: Wed, 2 Apr 2008 16:52:48 +0200

Hi Toby,

I thought it would be fun to represent your answer [1] with a Sequence  
Diagram to make sure I have really understood what you are saying. It  
is even simpler that the previous sketch.

So let me rephrase your steps:

1. Romeo's User Agent GETs Juliette's public foaf file at <http://juliette.org/ 
 >, that file contains the relation:

    <> rdfs:seeAlso <https://juliette.org/protected/juliette> .

2. Romeo's UserAgent does a GET on the HTTPS URL
    with the extra identification header:

    Agent-Id: http://romeo.name/#romeo

    All the https handshake stuff goes on as usual. From this  
Juliette's server extracts the hex id of the SSL key used by Romeo's  
User Agent.

3. Juliette's Server notices the extra header
    and GETs the resource at http://romeo.net/

    this contains the statements

    :romeo is wot:identity
              of [ a wot:X509Key;
                   wot:hex_id "ABC123AB";
                   wot:pubkeyAddress <http://key.com/romeos.key>;
                 ] .

4. Juliette's Server queries the triples returned in the the  
representations
    with the SPARQL query

    PREFIX wot: <http://xmlns.com/wot/0.1/>
    SELECT ?hexid
    WHERE {
              [] wot:identity <http://romeo.name/#romeo>;
                 wot:hex_id ?hexid .
    }

5. Since Juliette's user agent trusts the URL "http://romeo.name/ 
#romeo" - for whatever reason, perhaps her best friend had it in her  
foaf file - and the SSL session was signed by the client with the  
public key identified by hex_id "ABC123AB", she knows that the  
UserAgent has a strong enough trust relation with the person  
identified by <http://romeo.name/#romeo>, and so she returns the  
protected information over SSL.

Could it really be this simple?

	Henry

[1] http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0207.html

On 1 Apr 2008, at 12:40, Toby A Inkster wrote:
>
> Story Henry wrote:
>
>> My feeling is that what is needed is to see how this could be made to
>> work better with SSL.
>
> I've already posted a message suggesting an HTTPS-based solution.
>
>  Message-ID: <[email-masked]>
>  Subject: Re: [foaf-dev] Re: privacy and open data
>  Date: Thu, 27 Mar 2008 12:59:37 -0000 (UTC)
>
> Summary:
>
> 1. Client requests public FOAF
> 2. FOAF contains rdf:seeAlso with URI for HTTPS private FOAF
> 3. Client requests private FOAF using a client-side SSL cert
> 4. Client includes URI of their public FOAF in HTTP "From" header
> 5. HTTPS server requests client's public FOAF file and queries it
>    to find client's certificate serial number
> 6. Server checks that FOAF serial number matches the request
>    cert serial number, thus requesting client really does own
>    the FOAF file in HTTP From header
> 7. Server makes decision on what information client should be
>    shown, based on client's FOAF, and on client's FOAF URI
> 8. Server sends client this information as RDF
>
> -- 
> Toby A Inkster BSc (Hons) ARCS
> [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
> [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 21:52.]
>
>                           Cognition 0.1 Alpha 6
>         http://tobyinkster.co.uk/blog/2008/03/29/cognition-alpha6/
>

---

From: "Chris Richard" <[email-masked]>
Date: Wed, 2 Apr 2008 13:21:05 -0400

I really like this.

Is it too soon to bring up the case of multiple "semantically-enabled" web
servers whereby a server can make a request to a server on behalf of another
user? Suppose a user GETs a web page or a SPARQL protocol query from a
semantically-enabled server. In order to service that request, the server
makes secure requests to several other semantic servers for protected
resources necessary to build the requested view. The server-to-server
requests can use same authentication process described (steps 2-4 above,
note that many servers already have SSL certificates which is an added
bonus).

However, access to a resource should only be allowed if both the user and
the requesting server are trusted by the owner of the resource. You can
imagine this can be extended to a chain of "on-behalf-of" requests. Would
supporting this be as simple as using a stack of agent-id values? Servers
making a new on-behalf-of request would simply prepend their id to the list
from the incoming request and servers would be required to confirm that all
identities in the list are trusted or granted appropriate permissions (as
you noted previously, this part is external to the protocol).

While each server would *authorise all parties indicated in the agent-id
list*, for a chain of on-behalf-of requests this would require the server
that actually serves a particular protected resource to *authenticate only
the requesting party*. It would implicitly trust that each previous server
in the chain had taken proper steps to authenticate their requesting party.

What do you think?

Chris Richard

On Wed, Apr 2, 2008 at 10:52 AM, Story Henry <[email-masked]>
wrote:

> Diagram to make sure I have really understood what you are saying. It is
> even simpler that the previous sketch.
>
>
>
>
>
> 1. Romeo's User Agent GETs Juliette's public foaf file at <
> http://juliette.org/>, that file contains the relation:
>
>   All the https handshake stuff goes on as usual. From this Juliette's
> server extracts the hex id of the SSL key used by Romeo's User Agent.
>
> 5. Since Juliette's user agent trusts the URL "http://romeo.name/#romeo" -
> for whatever reason, perhaps her best friend had it in her foaf file - and
> the SSL session was signed by the client with the public key identified by
> hex_id "ABC123AB", she knows that the UserAgent has a strong enough trust
> relation with the person identified by <http://romeo.name/#romeo>, and so
> she returns the protected information over SSL.
>
>

---

From: Pipian <[email-masked]>
Date: Wed, 2 Apr 2008 13:54:41 -0400

On Apr 2, 2008, at 1:21 PM, Chris Richard wrote:

> I really like this.
>
> Is it too soon to bring up the case of multiple "semantically- 
> enabled" web servers whereby a server can make a request to a server  
> on behalf of another user? Suppose a user GETs a web page or a  
> SPARQL protocol query from a semantically-enabled server. In order  
> to service that request, the server makes secure requests to several  
> other semantic servers for protected resources necessary to build  
> the requested view. The server-to-server requests can use same  
> authentication process described (steps 2-4 above, note that many  
> servers already have SSL certificates which is an added bonus).
>
> However, access to a resource should only be allowed if both the  
> user and the requesting server are trusted by the owner of the  
> resource. You can imagine this can be extended to a chain of "on- 
> behalf-of" requests. Would supporting this be as simple as using a  
> stack of agent-id values? Servers making a new on-behalf-of request  
> would simply prepend their id to the list from the incoming request  
> and servers would be required to confirm that all identities in the  
> list are trusted or granted appropriate permissions (as you noted  
> previously, this part is external to the protocol).
>
> While each server would authorise all parties indicated in the agent- 
> id list, for a chain of on-behalf-of requests this would require the  
> server that actually serves a particular protected resource to  
> authenticate only the requesting party. It would implicitly trust  
> that each previous server in the chain had taken proper steps to  
> authenticate their requesting party.
>
> What do you think?

Absolutely.  This is more or less the key element of the access  
control proposal Jim Hendler and I have made in the TAMI project[1].   
The project focuses a bit more on the accountability/access aspect,  
the idea that a server may wish to authenticate against another server  
(e.g. a server may require proof that you are a fireman to access  
building blueprints, and in order to do so, your identity is checked  
against those approved by the local fire department, etc.)

I've attached a couple of the architecture images we've been working  
with that elucidate the 'webby' nature of this authentication scheme  
(not too dissimilar to those put forth already, though a couple are  
outdated).  I've actually got a mockup of our proposal up already  
protecting the page http://www.pipian.com/rdf/tami/t42_contacts.html,  
but it's using our originally proposed OpenID authentication method,  
which I can elaborate on if you'd like.

Ian Jacobi

---

From: Toby A Inkster <[email-masked]>
Date: Thu, 3 Apr 2008 09:55:38 +0100

On 2 Apr 2008, at 15:52, Story Henry wrote:

> I thought it would be fun to represent your answer [1] with a  
> Sequence Diagram to make sure I have really understood what you are  
> saying. It is even simpler that the previous sketch.

Yep, that's pretty much it.

An additional detail which is missing in your diagramme is: what  
happens if Romeo's client doesn't send an Agent-Id header (I used  
HTTP "From" header originally, but it doesn't really matter what the  
header is called) or Juliette decides she doesn't trust Romeo. I  
originally specified that a simple copy of the public profile should  
be returned, but instead I think perhaps a 302 redirect back to the  
public profile is more appropriate.

Also, I'd like to make a bid to explicitly allow XHTML+RDFa to be  
used for the public profiles (and if implementations are going to  
need to support it for public profiles, we might as well also allow  
it for private profiles!). With that in place, a person can decide to  
use the same URI for:

	* their (human-readable) homepage;
	* their FOAF profile for use in this protocol; and
	* their OpenID identifier.

If we insisted that their profile URI be RDF/XML, then that couldn't  
happen (except perhaps with some sort of content negotiation going on  
— I've not thought out the details).

-- 
Toby A Inkster
<mailto:[email-masked]>
<http://tobyinkster.co.uk>

---

From: Story Henry <[email-masked]>
Date: Thu, 3 Apr 2008 11:15:26 +0200

> Yep, that's pretty much it.

great. I am now checking to see how difficult it is to get this X501  
information with Java libraries. It would be fun to get a demo going.

> public profile is more appropriate.

makes sense. I'll add a note in the commentaries if I can get this to  
work.

> it for private profiles!). With that in place, a person can decide  
> to use the same URI for:
>

Of course. In the initial sketch I had made that explicit. Any RDF  
representation, including GRDDLEable Xml should be ok.

> happen (except perhaps with some sort of content negotiation going  
> on — I've not thought out the details).

Well the beautify of semantics is that we can abstract on the  
representation.
:-)

Henry

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 06 Apr 2008 00:36:44 +0200

tor 2008-04-03 klockan 09:55 +0100 skrev Toby A Inkster:

> header is called)

In HTTP this usually results in a 401 Unauthorized, asking the requestor
to identify himself..

> or Juliette decides she doesn't trust Romeo.

Thats usually a 401 (identity not trusted, please supply another) or 403
(I know you but do not want to speak to you).

In the response entity or headers you MAY provide additional
information, such as the location of the public profile, just as you MAY
on any response.

I think it in this case can be assumed the requestor already knows the
public profile, no need to redirect back there, and such redirections
only risk resulting in some implementations entering a loop..

Regards
Henrik

---

From: Story Henry <[email-masked]>
Date: Wed, 9 Apr 2008 11:16:51 +0200

I have been enquiring a little about the feasibility of the protocol  
sketched by Toby and illustrated  below for easy reference. It does  
seem to be technically possible, even if it requires some hacking  
around. More news later as the implementation proceeds.

Proposal compared to X.509
--------------------------

As I am learning more about SSL I had a few thoughts on how this  
proposal compliments and distinguished itself from X.509 on which SSL  
is built.

  It is clear that we are augmenting the X509 Distinguished Name [2]  
with a URI, in particular a http URL, and in some respects augmenting  
the Public Key Infrastructure (PKI) [3] with Linked Data. Let me  
consider each in turn:

   1. Distinguished Name enhancement

     I don't know that much about X500, so I can't tell what the  
advantages or problems with this protocol/naming system are by  
experience, though I did find a detailed, interesting and severe  
critique [5]. The Semantic Web seems to generalize above this, as it  
deals with all unique identifiers under the topic of URIs, and it has  
a system that works - better even: it works with the web.

    The case that we are enhancing X.509 can be made by realizing that  
it should be possible to add to the SSL certificate an additional URI  
id [4]. Essentially we could then make the statement:

   <distinguishedNameURI> owl:sameAs <foafid> .

By doing this the foaf id would be itself part of the certificate I  
suppose and so be vouched by the Certification Authority. Perhaps this  
reveals a problem with CAs: would CA.s be happy to vouch for a foaf  
id, even if they don't control the contents? If they did then it could  
slightly reduce the need for the foaf resource to return information  
about the key id identifying the user, or enhance the trust of that  
foaf id. Something to think about.

  2. PKI enhancement

    The URI for the user identity is also the place where the  
attributes can be found. So there is no need to pass the attributes in  
the certificate [5]. They can be fetched in a global distributed  
system known as the web, with no central point of control, no  
authorization bottleneck, when and if they are needed. As RDF is  
extremely flexible and well defined, extending it in a clear and well  
documented manner is no problem: every relation can be clicked on to  
find its meaning [6]. Another advantage of this PKI is that it should  
be easy to revoke a certificate. No need for revocation lists. If the  
foaf id of the agent no longer points to the certificate signature,  
the certificate can be deemed to be invalid. All the user would need  
to do to change his certificate is to create a new one, and publish  
its signature to his foaf file. In a semantic address book such as  
Beatnik [7], that could be done with the click of a button.

Limitations of the proposal
----------------------------

In the mean time, while searching for solutions I chatted on irc with  
Perry Nguyen [1] who did point out a few limitations of the proposal.  
Of course every proposal will be a tradeoff between different  
constraints, and so will have limitations. OpenId's limitations for  
example stem from trying to work around the limitations of browsers,  
which is also its big advantage. Still it is useful to list some of  
these, if only because some of these may easily be fixed with a little  
thought, others may have some good workarounds, and others may make us  
more modest. :-)

   1. Man in the middle in step 1

    Yes, that is a problem with any web site. All the unencrypted  
pages could be hijacked by a man in the middle and think links to the  
protected file could be redirected to some other service. This will  
only work if the other service can serve its https pages with a key  
that could be deemed to belong to Juliette. So the question outlined  
here is how does Romeo get to know Juliette's public key?

	The Web of Trust could be made to work here. If people use the  
wot:identity relation between a key and a foaf:Agent to identify the  
agent, in the way the foaf:openid, foaf:mbox, foaf:homePage and other  
relations do, then Romeo could have some confirming evidence as to the  
validity of the public key from his social network. Of course these  
will be out of date in the social network if Juliette changes her  
public key, but that should be relatively rare. When that happens it  
is reasonable to expect people to be on their guard.

   2. Man in the middle in step 2

    That is a rejoins point 1 above. It helps to have Juliette's  
public key, if Romeo wants to be sure that he is communicating with  
her server. Currently Juliette can pay for a public key from a CA, but  
it costs, and if someone steals it, it may take long before the  
expiration time on the key times out [5]. I don't think browsers do  
much checking of certification revocation lists. So the web of trust  
may again work much better.

   3. Man in the middle in step 3

   In the diagram this is not protected. The foaf file contains the  
signature of Romeo's key. If this were changed this would leave the  
door wide open to abuse. Does this mean that foaf files should be  
behind https, even for the non protected files? Notice that we would  
be more secure than OpenId, which does not require the openid URL to  
be protected. I think I heard that https could be used just to sign a  
file without encrypting the communication. When this happens is it  
proxy friendly? I mean can, and do, proxies cache the representation  
in order to reduce load on the server? What would be gained if romeo  
used his private key to sign the representation?

   So these are a few thoughts I gathered on my search to implement  
Toby's solution. Feedback welcome of course.

	Henry Story

Home Page: http://bblfish.net/

[1] http://www.hanhuy.com/pages/resume
[2] http://en.wikipedia.org/wiki/Distinguished_name
[3] http://en.wikipedia.org/wiki/Public_key_infrastructure
[3] http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html#certificates
[4] My guess is that this would be possible theoretically, though not  
easy when dealing with the Java API.
     I am not sure how one would go about it.
     http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/X509Certificate.html
[5] I did find a very critical document of X.509 on wikipedia  
"Everything you Never Wanted to Know about PKI but were Forced to Find  
Out"
     http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
[6] http://blogs.sun.com/bblfish/entry/get_my_meaning
[7] for more info on Beatnik, see the slightly hidden link on https://sommer.dev.java.net/

---

From: Story Henry <[email-masked]>
Date: Wed, 9 Apr 2008 11:37:22 +0200

> around. More news later as the implementation proceeds.

I just noticed that I linked to a lot of resources in this answer, but  
forgot to link to the original post which describes the stages. You  
can find it here:

http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0017.html

Henry

---

From: "Per-Olav Gramstad" <[email-masked]>
Date: Wed, 9 Apr 2008 12:28:24 +0200

Henry,
Thanks for going that extra mile for all us newcomers and eavesdroppers!

Looking forward to endulge in SAUTHNP ;-)

/Per-Olav  

-----Oprindelig meddelelse-----
Fra: Story Henry [mailto:[email-masked]] 
Sendt: 9. april 2008 11:37
Til: Inkster Toby
Cc: Semantic Web; foaf-dev Friend of a; HTTP Working Group; Harbulot Bruno;
Nguyen Perry
Emne: Re: sketch of a simple authentication protocol

> around. More news later as the implementation proceeds.

I just noticed that I linked to a lot of resources in this answer, but forgot
to link to the original post which describes the stages. You can find it
here:

Henry