See also: IRC log
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
<ivan> Henry Story owl:sameAs bblfish
-> slide 1
Pipian: FOAF+SSL is a new single-signon authentication scheme
pipian: we believe this is superior to
OpenID
... secure by default as it is built on SSL
... single URI to identify a user
<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
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
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
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]