FOAF+SSL Project Review

Ralph: Ian Jacobi (aka 'pipian') and Oshani S. are graduate students at MIT. Ian will present.

-> Henry Story's notes on his test implementation

 <plh> Slides: 19-foafssl-proj-rev

-> Project Review slides

<ivan> Henry Story owl:sameAs bblfish

-> slide 1

Pipian: FOAF+SSL is a new single-signon authentication scheme

-> slide 2: Overview

pipian: we believe this is superior to OpenID
... secure by default as it is built on SSL
... single URI to identify a user

-> slide 3: Why FOAF+SSL?

<ericP> leverages SW inclination towards shared identifiers to aggregate permissions

-> slide 5: CUrrent Alternatives: HTTP Authentication

-> slide 5: CUrrent Alternatives: HTTP Authentication

-> slide 6: Current Alternatives: OpenID

pipian: OpenID does not work nicely with non-graphical UIs; part of it depends on forms

-> slide 7: Using FOAF+SSL

pipian: like OpenID, F+S does provide a single 'username'

<plh> in the cons, I would add the use of https

pipian: we're interested in feedback from security experts on the current protocol

<IanJ> I wonder whether the approach can be taken with other protocols than ssl so you can swap another one in when ssl proves insecure

pipian: Safari and Google Chrome reportedly do not handle client certificates well

-> slide 8: Technical Background - FOAF

<tlr> ianj, if "ssl proves insecure", then it will be updated

pipian: FOAF is a SemWeb vocabulary for describing individuals and relationships between individuals
... I can state that <pipian> foaf:knows <henrystory>
... the key to this being useful for FOAF+SSL is that individuals and usernames can be given unique URIs

-> slide 9: FOAF+SSL - The Protocol

pipian: Juliette's public FOAF file contains a reference to a security-protected FOAF file

<IanJ> WHERE Romeo

pipian: Romeo wants to learn more about Juliette

pipian: Romeo finds an rdfs:seeAlso link in Juliette's public FOAF file
... sees the link is to an https: URI

<ericP> seeAslo, the most overloaded predicate in all RDF

<Bert> (Passcode 93277 doesn't seem to work.)

pipian: in addition to the SSL setup, Juliette's server requests an X509 certificate from Romeo's client
... inside that certificate there is a reference to Romeo's public FOAF document
... this reference to Romeo's public FOAF file is the key link to allow authentication
... Juliette's server requests Romeo's public FOAF file
... inside Romeo's FOAF file, Juliette's server finds further information about Romeo's X509 certificate
... via SSL the public & private keys will have already been used successfully
... if the public key in the X509 certificate is the same as the public key provided in the FOAF document, FOAF+SSL can verify that Romeo has access to the private part of the key

Thomas: need to verify that the FOAF file you retrieved is actually the one identified in the certificate
... can send a signature of the FOAF file but this would still be attackable
... the dereference of [Romeo's] FOAF URI must be protected
... so need to use https to retrieve Romeo's FOAF file too
... and use a server key you can trust
... as with OpenID you build a distributed system of credentials
... which ultimately ends up relying on the classical CA system
... however, this does scale differently

pipian: agree; it's important to check Romeo's FOAF document
... it might be possible to use a detached signature of the FOAF document
... not sure if [detached signature] would be insecure

Thomas: need to test some link between the signing key and the domain of the URI
... the basic link you are establishing via retrieval of FOAF documents is a link between the information you retrieve and the domain name of the information
... only the classical CA system currently authenticates that link
... dereferencing URIs is a classical step in your protocol
... so the retrieval must be secured
... so use of http would make this no better than OpenID

HenryS: I agree that Romeo's FOAF file must be retrieved via HTTPS
... but getting certificates for servers is much easier than getting certificates for individuals

<tlr> signing the foaf document will not reduce the reliance on the classical CA system.

<tlr> Using a key fingerprint would, but you don't get a FOAF file that way.

HenryS: it would be interesting to look into whether the FOAF document can be secured in some other way

Jose: the protocol is missing a reference to the public key that Romeo uses in step 2

pipian: that's what we have
... the reference to Romeo's public key is inside his FOAF file

Jose: in my opinion this won't scale well

Sandro: this only authenticates as well as the site that wants the authentication can reliably get Romeo's FOAF file
... so if Romeo uses https it's better but if Romeo [chooses to] use http, it's not reliable but maybe good enough

Thomas: be careful about what is authenticated
... just using client certificates it is possible to recognize the entity who's talking to you
... however, the binding between the key material and the URI is completely weak for http: URIs

Sandro: is it really that easy to intercept these HTTP requests?

Thomas: yes, particularly on a wireless network

Sandro: but unlikely that both servers in this example are on a wireless network

Thomas: point accepted but in general there's lots of possibilities for man-in-the-middle attacks

Sandro: https guarantees the domain part of the URI is accurate?

<ericP> you can uplug the server and plug it in on the far side of your man-in-the-middle machine

Thomas: @@ in theory binds the key material to the domain name
... but CA process for DV certs is shaky by itself
... problem reduces to sending email to a whois database, and that's not secure
... so there's a dirty step in most of these systems

-> slide 10: FOAF+SSL - Adding Authorization

pipian: in the previous slide all we've established is that Romeo has control of some URI
... it could be someone else who has written her own description of Romeo
... the URI of the FOAF document _together with_ the certificate must be used to establish trust

<sandro> Right -- it proves that the person using the client-certificate has control over that URI (at that moment, from the perspective of the verifier, who might have his routers hacked or something).

pipian: can permit self-signed certificates as this system scales well due to clients saying whom they trust
... harder to build a web of trust between servers;
... easier to build web of trust between clients

Thomas: pay attention to what we put our trust _in_
... difference between ...

<tlr> I can say "Henry has key 0xdeadbeef"

<tlr> or "I trust Henry to say that Ralph has key 0xdeadbeef"

pipian: this is a crucial difference
... we've only been able thus far to establish that a person has control over a URI
... we can't trust anything inside [the document at] that URI other than comparing the public key with the public key from the certificate
... I can claim to be HenryStory and show I have the same public key as that other X509 certificate claims for HenryStory. But that doesn't allow you to trust any other information in my FOAF file about HenryStory

-> slide 11: FOAF+SSL - Adding Authorization

<sandro> Right - even when the system is working perfectly, the user name and information presented at the URI is not verified by anyone (except perhaps the social network).

pipian: after retrieving Romeo's public FOAF document we examine what we get
... this example uses an RSA key
... after confirming the RSA public key information with the public key information in the certificate

<tlr> m.

pipian: do an authorization query for 'anyone whom Juliette has called a friend or anyone whom any of Juliette's friends have called friends may have access'

<tlr> interesting

pipian: can have any number of authorization policies in place

<tlr> we basically authenticate these statements based on server keys

pipian: e.g. is the URI in a list, ...
... the policy is stored in Juliette's server

-> slide 12: Use Cases

pipian: most of these use cases show the utility of single-signon
... because there's a semantic representation of the URI we can use it to personalize Web services
... my X.509 cert might have a description of my claim of Henry and Oshani as friends

<tlr> this doesn't sound scary to anybody here?

pipian: if I login to Facebook for the first time, Facebook server could use the information in my file -- though not necessearily trustable -- use it to customize my access by, e.g., introducing me to Oshani who's already been on Facebooko
... this personal identification can scale to other services; e.g. populating an instant message buddy list
... distributed HTTP access control no longer based on a single centralized list

<ericP> i think future work should be in the direction of use cases for extensible expression of privs, regardless of the auth system

pipian: e.g. W3C and MIT ACLs could be combined in a rule that only grants access to MIT students as described by MIT who are W3C participants as described by W3C

-> slide 13: Deployment Hurdles

pipian: these are small things we recognize should be addressed
... need a method for client-side cert creation

<pipian> http://test.foafssl.org/cert

pipian: HenryS has developed an implementation

Henry: uses keygen but extremely useful

<tlr> ... and HTML5 is, I believe, about to drop <keygen/>

-> slide 14: Deployment Hurdles: Ontology Design

pipian: example on the left shows a key from a cert having a foaf:Agent as its identity
... foaf:Agent is usually a Person but can also be an Organization
... in this example we link a key to an individual, not to an account the individual holds
... [right side] is an alternative design
... deployment simpler in the alternative design as it requires tracking fewer foaf:Agent keys
... alternative only requires tracking foaf:OnlineAccount
... still need to determine trustworthiness of foaf:Agent
... hope to show that foaf:Agent relationship to foaf:OnlineAccount is "most probably" true

-> slide 15: FOAF+SSL Implementations

pipian: TAAC
... I'm working on an implementation of TAAC that is not dependent on apache
... HenryS is working on FoafServer, a java-based implementation
... some test implementations in other languages have appeared in the last month or two
... the protocol is still under development
... so some of these schemes may not remain compatible

-> slide 16: Open Questions

pipian: we believe self-signing clients are more secure than self-signing servers but some aspects may not be as fully secure as clients authenticated via PKI
... Safari is an example of a browser that doesn't prompt for optional certificates
... we've heard that Google Chrome may be an example of a browser that doesn't accept client certs
... authorization is out of scope for this work but we recognize a standard for this is needed
... there's been discussion of implmenting an apache module rather than using mod_python
... TAAC's full-fledged authorization reasoning is an example of what could be done, not meant to be a full requirement

<Zakim> jose, you wanted to give comments on further thoughts: browser aa from scratch, mapping to openid, optimization, browser generating self-certificates

Jose: other directions you might take:
... most of the auth+auth protocols on the Web today are, like OpenID, hacks
... what would you do if you had the opportunity to design a browser from the ground-up with security and authorization in mind?

pipian: FOAF+SSL is an interesting scheme that could be implemented in a browser
... it works below the HTTP layer and doesn't rely on so many hacks to the HTTP layer
... so something like this would be useful in a bottom-up approach
... because this uses ssl certs, this could be used with XMP as well

HenryS: OpenID requires 7 or 8 https connections
... this protocol gets that down to just 2
... could get it down to 1 by working on the https stack
... FOAF+SSL does require that there is a server on-line while the user is on line
... could imagine that user's client runs a server
... so connections would be possible with only the user's computer and [Juliette's] server being on the Net

Jose: might be a variant that relies less on SSL

HenryS: there used to be problems in the 1990's with SSL performance but computers have gotten faster

<plh> I believe that ssl performance is still an issue for the w3c website

HenryS: we have an example of a FOAF+SSL login that creates session cookies then proceed with usual HTTP cookie-based authentication

Jose: it could be useful to map this protocol to a real OpenID use case
... show how it would work for a real OpenID use case
... I have done some work on distributed authentication using X.509 certificates and single signon
... I was using self-signed certs but my procotol had the client authenticate to a centralized authentication server
... the centralized server grants privileges that are stored in a certificate
... with some certificate lifetimes

<ted> ssl performance cost is not eliminated/solved afaik, the added calculations are not free

HenryS: we use keygen to generate self-signed certs
... others have used keygen for this as well

Thomas: I believe that <keygen /> is slated to be dropped from HTML5
... you might want to submit a comment to the HTML WG

HenryS: I have submitted sugh a comment

<DanC> (<keygen />? gee... I never noticed it.)

Eric: argue that this is useful in other contexts as well

[adjourned]