Re: RDFAuth: an initial sketch

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.


>    - a 403 Forbidden

401 "Authentication required" will trigger some form of authentication 
on normal browsers (such as htaccess).


>    In either case a header returning some information regarding the type 
> of authentication required is sent back

via WWW-Authenticate header...


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


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

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.


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



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



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


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



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

cheers,
--renato

Received on Thursday, 27 March 2008 14:00:20 UTC