14:02:22 RRSAgent has joined #foafssl 14:02:22 logging to http://www.w3.org/2009/02/19-foafssl-irc 14:02:24 ted has joined #foafssl 14:02:29 zakim, code 14:02:30 I don't understand 'code', ted 14:02:32 zakim, move global here 14:02:32 I don't understand 'move global here', tlr 14:02:36 zakim, move global to here 14:02:37 ok, tlr; that matches Team_Global(review)8:00AM 14:02:39 zakim, code? 14:02:39 the conference code is 4562 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr 14:02:41 -Richard 14:02:45 +Cooper 14:04:01 ericP has joined #foafssl 14:04:36 +EricP 14:04:46 Slides: http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html 14:04:52 +Felix 14:04:53 -Judy 14:04:54 zakim, mute thomas 14:04:54 Thomas should now be muted 14:05:01 pipian has joined #foafssl 14:05:06 plh has changed the topic to: Slides: http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html 14:05:37 IanJ has joined #foafssl 14:05:39 jules has joined #foafssl 14:06:10 zakim, mit531 has Oshani_S, Ian_Jacobi, Philippe, Ralph 14:06:10 Philippe was already listed in MIT531, Ralph 14:06:11 Ralph was already listed in MIT531, Ralph 14:06:12 +Oshani_S, Ian_Jacobi; got it 14:06:17 +Henry S. 14:06:18 zakim, passcode? 14:06:19 the conference code is 4562 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), plh 14:07:14 -> http://lists.w3.org/Archives/Team/w3t/2009Feb/0134.html Project Review slides 14:07:42 +Francois 14:08:01 + +1.781.674.aabb 14:08:19 Henry Story owl:sameAs bblfish 14:08:24 rrsagent, please make record public 14:08:47 ericP has changed the topic to: Slides: http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html -- meeting record public 14:08:56 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html slide 1 14:09:06 zakim, who's on the phone? 14:09:06 On the phone I see Jeanne (muted), Jose (muted), MIT531, Ivan, Ian, mauro (muted), Ted (muted), josema (muted), Felix (muted), Thomas (muted), Sandro, Cooper, EricP, Henry S., 14:09:09 ... Francois, +1.781.674.aabb 14:09:09 MIT531 has Oshani_S, Ian_Jacobi 14:09:26 Pipian: FOAF+SSL is a new single-signon authentication scheme 14:09:38 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[2] slide 2: Overview 14:09:56 pipian: we believe this is superior to OpenID 14:10:11 ... secure by default as it is built on SSL 14:10:33 ... single URI to identify a user 14:10:43 http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[4] 14:10:49 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[3] slide 3: Why FOAF+SSL? 14:12:13 leverages SW inclination towards shared identifiers to aggregate permissions 14:12:39 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[4] slide 5: CUrrent Alternatives: HTTP Authentication 14:12:54 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[5] slide 5: CUrrent Alternatives: HTTP Authentication 14:13:09 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[6] slide 6: Current Alternatives: OpenID 14:13:34 zakim, mute me 14:13:34 Jose was already muted, jose 14:14:15 pipian: OpenID does not work nicely with non-graphical UIs; part of it depends on forms 14:14:32 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[7] slide 7: Using FOAF+SSL 14:14:51 pipian: like OpenID, F+S does provide a single 'username' 14:15:44 in the cons, I would add the use of https 14:16:09 agenda+ use of https 14:16:33 pipian: we're interested in feedback from security experts on the current protocol 14:16:55 I wonder whether the approach can be taken with other protocols than ssl so you can swap another one in when ssl proves insecure 14:17:00 ... Safari and Google Chrome reportedly do not handle client certificates well 14:17:14 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[8] slide 8: Technical Background - FOAF 14:17:17 ianj, if "ssl proves insecure", then it will be updated 14:17:35 pipian: FOAF is a SemWeb vocabulary for describing individuals and relationships between individuals 14:17:47 ... I can state that foaf:knows 14:17:53 Bert has joined #foafssl 14:18:13 ... the key to this being useful for FOAF+SSL is that individuals and usernames can be given unique URIs 14:18:26 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[9] slide 9: FOAF+SSL - The Protocol 14:18:56 pipian: Juliette's public FOAF file contains a reference to a security-protected FOAF file 14:19:07 WHERE Romeo 14:19:08 ... Romeo wants to learn more about Juliette 14:19:21 WHERE4ART[barstow]THOU? 14:19:43 pipian: Romeo finds an rdfs:seeAlso link in Juliette's public FOAF file 14:20:00 ... sees the link is to an https: URI 14:20:00 seeAslo, the most overloaded predicate in all RDF 14:20:08 (Passcode 93277 doesn't seem to work.) 14:20:11 zakim, code? 14:20:11 the conference code is 4562 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Bert 14:20:44 +Bert 14:20:51 ... in addition to the SSL setup, Juliette's server requests an X509 certificate from Romeo's client 14:21:03 ... inside that certificate there is a reference to Romeo's public FOAF document 14:21:28 ... this reference to Romeo's public FOAF file is the key link to allow authentication 14:21:37 ... Juliette's server requests Romeo's public FOAF file 14:21:58 ... inside Romeo's FOAF file, Juliette's server finds further information about Romeo's X509 certificate 14:22:11 ... via SSL the public & private keys will have already been used successfully 14:22:40 q+ 14:22:56 ... 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 14:23:24 q+ 14:23:25 ack t 14:24:08 Thomas: need to verify that the FOAF file you retrieved is actually the one identified in the certificate 14:24:23 ... can send a signature of the FOAF file but this would still be attackable 14:24:40 ... the dereference of [Romeo's] FOAF URI must be protected 14:24:56 ... so need to use https to retrieve Romeo's FOAF file too 14:25:02 ... and use a server key you can trust 14:25:13 ... as with OpenID you build a distributed system of credentials 14:25:22 ... which ultimately ends up relying on the classical CA system 14:25:30 ... however, this does scale differently 14:25:48 pipian: agree; it's important to check Romeo's FOAF document 14:26:01 ... it might be possible to use a detached signature of the FOAF document 14:26:23 ... not sure if [detached signature] would be insecure 14:26:32 sandro has joined #foafssl 14:26:36 q? 14:26:37 Thomas: need to test some link between the signing key and the domain of the URI 14:26:55 -josema 14:26:59 ... 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 14:27:07 ... only the classical CA system currently authenticates that link 14:27:10 olivier has joined #foafssl 14:27:19 ... dereferencing URIs is a classical step in your protocol 14:27:25 ... so the retrieval must be secured 14:27:36 ... so use of http would make this no better than OpenID 14:27:57 HenryS: I agree that Romeo's FOAF file must be retrieved via HTTPS 14:28:12 ... but getting certificates for servers is much easier than getting certificates for individuals 14:28:20 q- 14:28:29 zakim, unmute me 14:28:29 Jose should no longer be muted 14:28:33 signing the foaf document will not reduce the reliance on the classical CA system. 14:28:41 Using a key fingerprint would, but you don't get a FOAF file that way. 14:28:43 ... it would be interesting to look into whether the FOAF document can be secured in some other way 14:28:46 DanC has joined #foafssl 14:29:00 +Olivier 14:29:07 Jose: the protocol is missing a reference to the public key that Romeo uses in step 2 14:29:13 pipian: that's what we have 14:29:24 ... the reference to Romeo's public key is inside his FOAF file 14:29:40 zakim, mute me 14:29:40 Jose: in my opinion this won't scale well 14:29:40 Jose should now be muted 14:30:02 q+ 14:30:12 Sandro: this only authenticates as well as the site that wants the authentication can reliably get Romeo's FOAF file 14:30:15 ack jose 14:30:16 zakim, mute me 14:30:16 Jose should now be muted 14:30:39 ... so if Romeo uses https it's better but if Romeo [chooses to] use http, it's not reliable but maybe good enough 14:30:54 Thomas: be careful about what is authenticated 14:31:09 ... just using client certificates it is possible to recognize the entity who's talking to you 14:31:23 ... however, the binding between the key material and the URI is completely weak for http: URIs 14:31:39 Sandro: is it really that easy to intercept these HTTP requests? 14:31:43 -mauro 14:31:45 Thomas: yes, particularly on a wireless network 14:31:52 mauro-bbl has left #foafssl 14:31:56 Sandro: but unlikely that both servers in this example are on a wireless network 14:32:14 Thomas: point accepted but in general there's lots of possibilities for man-in-the-middle attacks 14:32:28 Sandro: https guarantees the domain part of the URI is accurate? 14:32:34 you can uplug the server and plug it in on the far side of your man-in-the-middle machine 14:32:43 Thomas: @@ in theory binds the key material to the domain name 14:32:50 ... but @2@ is shaky by itself 14:33:09 ... problem reduces to sending email to a whois database, and that's not secure 14:33:21 s/@2@/CA process for DV certs/ 14:33:28 ... so there's a dirty step in most of these systems 14:33:41 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[10] slide 10: FOAF+SSL - Adding Authorization 14:33:47 +Sandro.a 14:33:53 -Sandro 14:34:08 pipian: in the previous slide all we've established is that Romeo has control of some URI 14:34:23 ... it could be someone else who has written her own description of Romeo 14:34:48 ... the URI of the FOAF document _together with_ the certificate must be used 14:34:58 s/used/used to establish truct 14:35:01 s/truct/trust 14:35:16 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). 14:35:22 q+ 14:35:23 ... can permit self-signed certificates as this system scales well due to clients saying whom they trust 14:35:34 ... harder to build a web of trust between servers; 14:35:42 ... easier to build web of trust between clients 14:36:01 Thomas: pay attention to what we put our trust _in_ 14:36:41 ... difference between ... 14:36:55 I can say "Henry has key 0xdeadbeef" 14:37:03 or "I trust Henry to say that Ralph has key 0xdeadbeef" 14:37:21 pipian: this is a crucial difference 14:37:35 ... we've only been able thus far to establish that a person has control over a URI 14:37:57 ... we can't trust anything inside [the document at] that URI other than comparing the public key with the public key from the certificate 14:38:33 ... 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 14:38:53 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[11] slide 11: FOAF+SSL - Adding Authorization 14:38:59 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). 14:39:10 pipian: after retrieving Romeo's public FOAF document we examine what we get 14:39:20 ... this example uses an RSA key 14:39:37 ... after confirming the RSA public key information with the public key information in the certificate 14:40:15 m. 14:40:16 ... 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' 14:40:17 interesting 14:40:36 ... can have any number of authorization policies in place 14:40:42 we basically authenticate these statements based on server keys 14:40:45 ... e.g. is the URI in a list, ... 14:40:54 ... the policy is stored in Juliette's server 14:41:05 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[12] slide 12: Use Cases 14:41:21 pipian: most of these use cases show the utility of single-signon 14:41:35 ... because there's a semantic representation of the URI we can use it to personalize Web services 14:41:38 q+ 14:42:01 ... my X.509 cert might have a description of my claim of Henry and Oshani as friends 14:42:17 q- 14:42:50 this deosn't sound scary to anybody here? 14:42:50 ... 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 14:42:54 s/deosn/doesn/ 14:43:03 MichaelC_ has joined #foafssl 14:43:20 ... this personal identification can scale to other services; e.g. populating an instant message buddy list 14:43:53 ... distributed HTTP access control no longer based on a single centralized list 14:44:06 i think future work should be in the direction of use cases for extensible expression of privs, regardless of the auth system 14:44:30 ... 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 14:44:40 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[13] slide 13: Deployment Hurdles 14:44:59 pipian: these are small things we recognize should be addressed 14:45:20 ... need a method for client-side cert creation 14:45:49 test.foafssl.org/cert 14:45:50 ... HenryS has developed an implementation 14:46:02 Henry: uses keygen but extremely useful 14:46:13 ... and HTML5 is, I believe, about to drop 14:46:38 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[14] slide 14: Deployment Hurdles: Ontology Design 14:46:53 pipian: example on the left shows a key from a cert having a foaf:Agent as its identity 14:47:05 ... foaf:Agent is usually a Person but can also be an Organization 14:47:25 ... in this example we link a key to an individual, not to an account the individual holds 14:47:55 ... [right side] is an alternative design 14:48:16 ... deployment simpler in the alternative design as it requires tracking fewer foaf:Agent keys 14:48:42 ... alternative only requires tracking foaf:OnlineAccount 14:48:56 ... still need to determine trustworthiness of foaf:Agent 14:49:24 ... hope to show that foaf:Agent relationship to foaf:OnlineAccount is "most probably" true 14:49:36 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[15] slide 15: FOAF+SSL Implementations 14:49:51 pipian: TAAC 14:50:10 ... I'm working on an implementation of TAAC that is not dependent on apache 14:50:29 ... HenryS is working on FoafServer, a java-based implementation 14:50:41 ... some test implementations in other languages have appeared in the last month or two 14:51:04 ... the protocol is still under development 14:51:15 ... so some of these schemes may not remain compatible 14:51:23 -> http://dig.csail.mit.edu/2009/02/19-foafssl-proj-rev/index.html#[16] slide 16: Open Questions 14:52:08 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 14:53:07 ... Safari is an example of a browser that doesn't prompt for optional certificates 14:53:30 ... we've heard that Google Chrome may be an example of a browser that doesn't accept client certs 14:53:48 q? 14:53:51 agenda? 14:54:00 zakim, drop agendum 1 14:54:00 agendum 1, use of https, dropped 14:54:04 ... authorization is out of scope for this work but we recognize a standard for this is needed 14:54:28 ... there's been discussion of implmenting an apache module rather than using mod_python 14:54:53 q+ to give comments on further thoughts: browser aa from scratch, mapping to openid, optimization, browser generating self-certificates 14:54:58 ... TAAC's full-fledged authorization reasoning is an example of what could be done, not meant to be a full requirement 14:55:02 ack jose 14:55:03 jose, you wanted to give comments on further thoughts: browser aa from scratch, mapping to openid, optimization, browser generating self-certificates 14:55:20 Jose: other directions you might take: 14:55:51 ... most of the auth+auth protocols on the Web today are, like OpenID, hacks 14:56:17 ... what would you do if you had the opportunity to design a browser from the ground-up with security and authorization in mind? 14:56:36 pipian: FOAF+SSL is an interesting scheme that could be implemented in a browser 14:56:51 ... it works below the HTTP layer and doesn't rely on so many hacks to the HTTP layer 14:57:08 ... so something like this would be useful in a bottom-up approach 14:57:44 ... because this uses ssl certs, this could be used with XMP as well 14:57:54 HenryS: OpenID requires 7 or 8 https connections 14:58:01 ... this protocol gets that down to just 2 14:58:19 ... could get it down to 1 by working on the https stack 14:58:33 ... FOAF+SSL does require that there is a server on-line while the user is on line 14:58:46 ... could imagine that user's client runs a server 14:59:09 ... so connections would be possible with only the user's computer and [Juliette's] server being connected 14:59:20 q+ 14:59:21 s/being connected/being on the Net 14:59:32 Jose: might be a variant that relies less on SSL 14:59:39 q- 14:59:48 HenryS: there used to be problems in the 1990's with SSL performance but computers have gotten faster 15:00:13 I believe that ssl performance is still an issue for the w3c website 15:00:14 q? 15:00:15 ... we have an example of a FOAF+SSL login that creates session cookies then proceed with usual HTTP cookie-based authentication 15:00:39 Jose: it could be useful to map this protocol to a real OpenID use case 15:01:00 ... show how it would work for a real OpenID use case 15:01:21 ... I have done some work on distributed authentication using X.509 certificates and single signon 15:01:40 ... I was using self-signed certs but my procotol had the client authenticate to a centralized authentication server 15:01:45 - +1.781.674.aabb 15:01:54 ... the centralized server grants privileges that are stored in a certificate 15:02:02 ... with some certificate lifetimes 15:02:02 ssl performance cost is not eliminated/solved afaik, the added calculations are not free 15:02:15 HenryS: we use keygen to generate self-signed certs 15:02:23 zakim, mute me 15:02:23 Jose should now be muted 15:02:24 ... others have used keygen for this as well 15:02:40 Thomas: I believe that is slated to be dropped from HTML5 15:02:45 ... you might want to submit a comment to the HTML WG 15:02:51 HenryS: I have submitted sugh a comment 15:02:59 (? gee... I never noticed it.) 15:03:06 Eric: argue that this is useful in other contexts as well 15:03:32 [adjourned] 15:03:33 -EricP 15:03:34 -Bert 15:03:34 -Thomas 15:03:35 -Ian 15:03:37 -Cooper 15:03:39 zakim, dorp me 15:03:39 -Francois 15:03:40 zakim, list attendees 15:03:41 -Ted 15:03:42 zakim, drop me 15:03:43 MichaelC has left #foafssl 15:03:43 I don't understand 'dorp me', jose 15:03:48 As of this point the attendees have been Dave_Raggett, Jeanne, Karen, Jose, Ralph, koalie, bert, jules, francois, Ivan, Josema, Phil_Archer, Mauro, Steve, Kazuyuki, Mike, Ian, 15:03:51 ... +7.902.aaaa, andrew, Ted, Judy, Shadi, marie, Felix, Rigo, Philippe, Richard, Thomas, Ht, DanielD, Sandro, Cooper, EricP, Oshani_S, Ian_Jacobi, Henry S., +1.781.674.aabb, 15:03:51 yeah, Zakim, drop jose. 15:03:52 zakim, who's a dorp ? 15:03:53 ... Olivier 15:03:55 Jose is being disconnected 15:03:55 yeah, Zakim, dorp jose. 15:03:57 -Jose 15:03:59 ivan has left #foafssl 15:03:59 -Sandro.a 15:04:02 -Olivier 15:04:04 I don't understand your question, Ralph. 15:04:06 -Henry S. 15:04:08 -MIT531 15:04:09 Bert has left #foafssl 15:04:15 -Ivan 15:04:16 rrsagent, please draft minutes 15:04:16 I have made the request to generate http://www.w3.org/2009/02/19-foafssl-minutes.html Ralph 15:04:36 -Jeanne 15:04:43 -Felix 15:04:45 Team_Global(review)8:00AM has ended 15:04:46 Attendees were Dave_Raggett, Jeanne, Karen, Jose, Ralph, koalie, bert, jules, francois, Ivan, Josema, Phil_Archer, Mauro, Steve, Kazuyuki, Mike, Ian, +7.902.aaaa, andrew, Ted, 15:04:52 ... Judy, Shadi, marie, Felix, Rigo, Philippe, Richard, Thomas, Ht, DanielD, Sandro, Cooper, EricP, Oshani_S, Ian_Jacobi, Henry S., +1.781.674.aabb, Olivier 15:05:09 -> http://lists.w3.org/Archives/Team/w3t/2009Feb/0122.html Henry Story's notes on his test implementation 15:05:13 jules has left #foafssl 15:06:02 Meeting: FOAF+SSL Project Review 15:06:05 rrsagent, please draft minutes 15:06:05 I have made the request to generate http://www.w3.org/2009/02/19-foafssl-minutes.html Ralph 15:14:23 IanJ has left #foafssl 15:21:17 plh has left #foafssl 15:25:08 pipian has left #foafssl 15:38:40 tlr has left #foafssl 15:49:30 zakim, bye 15:49:31 Zakim has left #foafssl 15:49:33 rrsagent, bye 15:49:33 I see no action items