Re: RDFAuth: an initial sketch

Hi Renato,

thanks for your detailed feedback. This is helping a lot.

On 27 Mar 2008, at 14:59, Renato Golin wrote:
>
>
> Hi Henry,
>
>
> Story Henry wrote:
>> 2. the server responds with either:
>>   - some minimal information and a yet to be invented return code  
>> of 207 PARTIAL INFORMATION
>
> You can use the already existent 206 "Partial Content" for that, I  
> guess.

I was hoping I could, but the spec states

[[
The server has fulfilled the partial GET request for the resource. The  
request MUST have included a Range header field (section 14.35)  
indicating the desired range, and MAY have included an If-Range header  
field (section 14.27) to make the request conditional.
]] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.7

It is the MUST there which is problematic. That is why I was thinking  
it may be nice to have a 207 - partial content, more when  
authenticated, response.

>
>>   - a 403 Forbidden
>
> 401 "Authentication required" will trigger some form of  
> authentication on normal browsers (such as htaccess).

Oops. Quite right. That's what I meant. I'll update my diagram.

>>   In either case a header returning some information regarding the  
>> type of authentication required is sent back
>
> via WWW-Authenticate header...


Ok, so avoiding reading the whole of RFC 2617 I jumped to http://en.wikipedia.org/wiki/Basic_access_authentication
which gives a good idea of how this works.

The server in 2 would return

HTTP/1.0 401 UNAUTHORIZED
Server: Knowee/0.4
Date: Sat, 1 Apr 2008 10:18:15 GMT
WWW-Authenticate: RdfAuth realm="http://juliette.org/*"  
nonce="ILoveYouToo"

questions:
  - not sure what to put as the realm there really. Here I thought  
some form of regexp perhaps. Perhaps a link to a POWDER doc.
  - it would be really nice again if a basic representation could be  
returned,
    if this is not possible then perhaps the basic foaf file should be  
available to all and contain a statement such as
    <> rdfs:seeAlso </protected/juliette> .
    </protected/juliette> would then be the resource requiring  
authentication.

And the client in 3 would respond with

GET /protected/juliette HTTP/1.0
Host: juliette.org
Authorization: RdfAuth id="http://romeo.name/#romeo"  
key="THE_REALM_AND_NONCE_ENCRYPTED"
Content-Type: application/rdf+xml, text/rdf+n3


>
>> 3. the client sends a GET back with some header information:
>>   - the URL of Romeo <http://romeo.name/#romeo>
>>   - an encrypted string (perhaps a string sent in the previous  
>> response)
>
> A three-way challenge response would be nice here...
>
> 1. Romeo gets random text + hash from romeo [ you mean juliette  
> right?]
> 2. Romeo encrypts text with private key and send to juliette's with  
> hash
> 3. Juliette's sends hash to romeo's and gets text + public key
> 4. Juliette's decrypts text and compare with romeo's text
>
> The key could be in a public key server though.

Hmm this would be to test that the connection was really with  
Juliette's server right?
I was thinking this could be solved with ssl the way other things are,  
but I am not sure how.
I suppose you are right, this could be extended so that the server  
also returns a link to the server's foaf file - which would also  
contain a link to a PGP file, perhaps located on a trusted server  
somewhere. The Public key (be it PGP or some other algorithm) should  
be pointed to via a URL .

This is getting more complex though. I wonder if one can make a simple  
spec that would easily be extensible to your suggestion.
And it would also be nice if one could have one that could work with  
ssl as stated.

>> 4. The server controlling Juliette's foaf doc sends a GET request  
>> to the foaf file
>> 5. The server controlling Romeo's foaf doc returns his foaf file,  
>> in any number of formats, or perhaps even a GRDDLable document the  
>> server can understand,  containing a link to one of his public pgp  
>> keys
>
> You're not taking into account that Romeo might not want Juliette to  
> access his foaf file too... I he doesn't you got caught in a deadlock.

Well I did. My thought is that pragmatically, a foaf file always has a  
public version with minimal content, of which clearly a reference to a  
public key would make a lot of things easier. A public foaf file could  
just contain:

:me a foaf:Person;
     foaf:firstName "Romeo";
     rdfs:seeAlso <protected>;
     is wot:identity of ....

In fact if such a protocol took off, this would create a big incentive  
for having a minimal public foaf file such as the above.

>
> The auth scheme should never rely on foaf files, it must be  
> completely independent of them because it's a step before actually  
> getting foaf files in the first place.

Not in the situation described above, I think.


>
>> 7. Juliette uses the answer in 6 to GET the PGP key.
>>   (what to do if someone has more that one PGP key?)
>
> Try all of them in descending order of creation time.

Ok. Or the header could contain a link to the preferred key. In which  
case the call's to the foaf and key could be parallelized.

>
>> 8. Romeo's server returns the PGP key
>
> Easier to get them from public servers... keeping a list of all  
> trusted public servers on Juliette's.

well the public server could be an http server right? Or the URL could  
be a specialized public key server url. No need to decide now.
Though I really like the simplicity of having a public key available  
at an http url. It makes it easier to change keys, update them, and
deprecate them.

It may be nice also to have the file containing the pgp key itself be  
RDF so that it can point back to the owner of the file, and also
specify if this is the actual key. That would even allow the key to be  
placed in the foaf file, though as I mentioned it would be somewhat  
less RESTful.

>
>> 9. Juliette's server uses the public key to decrypt the string  
>> passed in 3. Having done this Juliette's server now knows that the  
>> request in 3 came
>>   from software owned by <http://romeo.name/#romeo>.
>
> Passing the same string as before doesn't show that you are romeo,  
> but getting the string from a trusted place (like romeo's server)  
> and comparing to what "the guy that says he's romeo" encripted with  
> romeo's private key might.

I am not sure I understand this. There may be a misunderstanding.
Juliette's server now has a public key, and she has an string Crypt(S)  
encrypted by Romeo's User Agent UA with his private key.
If Cyrpt(S) decrypts with the public key back to the original S, then  
she knows that UA had access to the private key, and so that the foaf  
file which pointed to the public key is owned by the person owning the  
private key. (or else the foaf file would not point to that public key  
in that way)

>
>> 10. Juliette's server after consulting her policies for <http://romeo.name/#rome 
>> >, returns the appropriate response;  a 200 perhaps with a fuller  
>> foaf file. Perhaps something else needs to be returned, a token to  
>> give access to a number of resources (expressed in POWDER perhaps).
>
> You're not dealing with multiple levels of security. You can follow  
> the Unix style of groups or hierarchy or even per-person style (very  
> user unfriendly) but would be good to say which resources from which  
> files each user/group/level might be able to access.

Yes, though this protocol does not need to decide how the permissions  
are granted by Juliette's server.

Another protocol, that would do something like oAuth, could use  
foaf:Groups to allow foaf:Agents to access resources, using POWDER  
perhaps.


>> Some thoughts that just arose from going through the exercise of  
>> specifying each of the steps precisely:
>> - what kind of response should be returned in 2? Should this  
>> redirect to an authentication server perhaps which would then  
>> return some token to give access to all the resources in a domain?
>
> - 401 if you haven't authenticated
> - 206 if you have and is not Juliette (or someone she trusts  
> completely to give full access)
> - 200 else
>
>
>> - What about multiple  pgp keys?
>
> Try all, although that would lead to a DOS if one creates hundreds  
> of keys just for the sake of killing your server. Even restraining  
> by time or only re-reading if the email is different you can still  
> DOS by creating hundreds of emails on your own domain in the last 10  
> minutes.
>
> I say we should restrict the number and if the user have a problem  
> with that he should specify the key server as an additional  
> parameter (HTTP header) to get from where he knows he have less than  
> N keys where N should be *really* small (say 5 or 10). If he still  
> have problems he should clean his pgp keys. ;)
>
> my 2 cents...

Thanks a lot Renato. This is helping a lot. Do you feel we are getting  
closer? Anyone else have any remarks?

Henry


>
> cheers,
> --renato