sketch of a foaf+ssl+openid service

Discussing foaf+ssl with Melvin Carvalho he pointed out that we need a service to help non https enabled servers to participate in our distributed open secure social network. This discussion led me to sketch out the following simple protocol, where I make use of parts of the OpenId protocol at key points. This results in something that does what OpenId does, but without the need for users to remember their URL, and so without many of the problems that plague that protocol. And all this with minimal protocol invention.

So first here is the UML sequence diagram for what I am calling here tentatively foaf+ssl+openid.

  1. First Romeo arrives on a public page with a login button.
    • On an OpenId server there would be a field for the user to enter their ID, with foaf+ssl this is not needed. So we have a simple login button.
    • That button's action attribute points to some foaf+ssl+openid service that server trusts (it is therefore an https URL). It can be any such service. In OpenId the Id entered by the user points the server to a web page that points the service to an openid server the user (Romeo here) trusts. All of this is no longer needed with this protocol. The html for the login button can be static.
    • The URL has to encode information for the foaf+ssl service to know who to contact back. One should use exactly the same URL format here as OpenId does. (minus the need to encode User's URL since that will be in the X509 certificate)
  2. When Romeo clicks the login button he opens an https request to the foaf+ssl+openid service.
  3. The foaf+ssl+openid service on opening the connection asks for the client's certificate after sending its own. This would contain
    • The User's Public key
            Subject Public Key Info:
                  Public Key Algorithm: rsaEncryption
                  RSA Public Key: (1024 bit)
                      Modulus (1024 bit):
                          00:b6:bd:6c:e1:a5:ef:51:aa:a6:97:52:c6:af:2e:
                          71:94:8a:b6:da:9e:5a:5f:08:6d:ba:75:48:d8:b8:
                          01:50:d3:92:11:7d:90:13:89:48:06:2e:ec:6e:cb:
                          57:45:a4:54:91:ee:a0:3a:46:b0:a1:c2:e6:32:4d:
                          54:14:4f:42:cd:aa:05:ca:39:93:9e:b9:73:08:6c:
                          fe:dc:8e:31:64:1c:f7:f2:9a:bc:58:31:0d:cb:8e:
                          56:d9:e6:da:e2:23:3a:31:71:67:74:d1:eb:32:ce:
                          d1:52:08:4c:fb:86:0f:b8:cb:52:98:a3:c0:27:01:
                          45:c5:d8:78:f0:7f:64:17:af
                      Exponent: 65537 (0x10001)
      
    • The Subject's Alternative Name WebId
              X509v3 extensions:
                 ...
                 X509v3 Subject Alternative Name: 
                                 URI:http://romeo.net/#romeo
      
    The ability for browsers to do this is all part of the standard TLS handshake available in most browsers for a few generations.
  4. The server looks in the client certificate for the Subject Alternative Name in the SSLv3 extensions, and fetches the foaf file at that URL
  5. The service then does a simple match on the information from the foaf file and the information from the certificate. If they match the foaf+ssl+openid service knows that the user <http://romeo.net/#rome> controls <http://romeo.net/> web page. This is enough for simple authentication. (For more on this see Creating a Web of Trust withouth Key Signing Parties )
  6. Depending on the result, the foaf+ssl+openid service can return a redirect with an authentication token to the original service Romeo wanted to log into. This can also be done using the patterns developed in the OpenId community. foaf+ssl+openid sequence diagram
  7. The browser then redirects to the Original service.
  8. The service now has Romeo's URL. But to avoid a man in the middle attack, or replay attacks it follows the OpenId protocol and does a little check with its service on a token sent to it in the redirect in step 6.
    ((Perhaps this step could be avoided if the foaf+ssl+openid service made public it's public key, and encrypted some token sent to by the client to the server. But we could just stick closely to the well trodden OpenId path and just reuse their libraries.))
  9. Having verified the identity of the user, the service could optionally GET the user's foaf file, for public information about him.
  10. Or it could check the relation that user has to it's trusted graph of friends,
  11. and return a presonalised resource

One could also imagine a foaf+ssl+openid server enabled with attribute exchange functionality, which it could get access to simply by reading the foaf file.

I am not sure how much of a problem it really is for servers not to have SSL access. But this could easily fill that gap.

Comments:

Bruno Harbulot implemented such a service using SAML

http://lists.foaf-project.org/pipermail/foaf-protocols/2009-March/000403.html

Posted by Henry Story on March 25, 2009 at 11:22 AM CET #

Post a Comment:
Comments are closed for this entry.
About

bblfish

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today