[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Thu Mar 19 18:43:36 CET 2009


Hi Toby and Melvin,

Toby Inkster wrote:
> Started writing this yesterday, but then I decided to stop and come back
> to it later. Haven't had an opportunity to put any more thought into it
> yet, but thought I'd forward my thoughts so far...
> 
> On Wed, 2009-03-18 at 00:54 +0100, Melvin Carvalho wrote:
>> 1. Consumer redirects User Agent to a FOAF+SSL service provider with
>> known public key
>> 2. User authenticates, and service provider signs the webid with
>> private key, redirecting User Agent back
>> 3. Consumer decodes with public key authenticates as webid
>>
>> Issue: possible replay attack, but this can be repelled by also
>> sending a timestamp/nonce pair to be encoded also
> 
> This will work. Possible version avoiding replay attacks would be:
> 
> Service Provider (SP): website wanting to provide an authenticated
> service, but lacking the ability to provide HTTPS in general, or FOAF
> +SSL in particular. We'll assume their domain name is example.org.
> User: person with a FOAF+SSL-enabled certificate installed in their
> browser, and wishing to use SP's service.
> Authentication Service (AS): suitable FOAF+SSL website. We'll assume
> their domain name is secure.example.net.
> 
> 1. AS provides SP with its public key. This is done beforehand.
> 
> 2. SP publishes a public key at http://example.org/key.txt (or any other
> URI at their domain). This is done beforehand.
> 
> 3. SP redirects User to http://secure.example.net/as, providing AS with
> the following parameters in the query string. An [e] indicates that a
> field is encrypted using AS's public key and signed using SP's private
> key:
> 
>    * Return URI (URI it wants the User to ultimately end up at) [e]
>    * Current timestamp [e]
>    * Public Key URI

I'm not sure we need to encrypt and sign here. The request to the AS 
will be done over SSL between the user's browser and the AS. The return 
URI will be the same as the one the user was trying to access in the 
first place (so someone between the user and the SP would know it anyway).

For this reason, I don't think the AS needs to know the SP's public key: 
steps 2, 3(e), 5, 6 and encryption in 8 (not signing) could be removed. 
(Unlike Shibboleth, which discloses only certain attributes to certain 
SPs, we're just verifying the ID here. The SP can get further 
information from the FOAF files itself later.)

If we do want encryption of the WebID between the user's browser and the 
SP in 8, we need to use the SP's public key indeed. My guess is that, 
since the communication between the user and the SP would be encrypted 
anyway, an eavesdropper could find out the WebID quite easily 
(especially if the page says "Welcome <http://example.com/#user>!").


> 4. AS authenticates User with FOAF+SSL. It may offer additional
> services, such as alternative authentication methods if the user has no
> FOAF+SSL certificate installed in their browser.
> 
> 5. AS fetches SP's public key (preferably checking a cache first) and
> decrypts the other request fields.
> 
> 6. If the host name of the return URI and the host name of the public
> key URI do not match, AS raises an error. (Is this unnecessary?)
> 
> 7. If the current timestamp param is "old", then AS raises an error.
> 
> 8. AS redirects User to the return URI passing additional query string
> parameters. An [E] indicates that a field is encrypted using SP's public
> key and signed using AS's private key:
> 
>    * Current timestamp [E]
>    * User's WebID [E]
> 
> This should make it possible for any service provider to use the AS
> without having to pre-register any encryption secrets with the AS.

We could use a nonce instead of the timestamp to prevent replay attacks.

If using SAML, the response could look like Section 3.1.2.1 of 
<http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-200509.pdf> 
(with a much simpler <saml:Assertion>/<saml:Subject> that would only 
contain the WebID).
The downside of this type of response is that it's still a bit big for 
being passed as a query parameter (hence the reliance on automatic POST 
upon a GET in Shibboleth).


Best wishes,

Bruno.


More information about the foaf-protocols mailing list