Re: [foaf-protocols] new sequence diagram

I mean that the connection is renegotiated in the way RFC 5746 discusses, when it solves the renegotiation issue that came up
a few years ago.

	http://www.ietf.org/rfc/rfc5746.txt

This fix has now been widely implemented - and there is even a note for example in Java 6 and Java 7 on this 
http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation




On 21 Nov 2011, at 04:42, Peter Williams wrote:

> Be aware that you are using loaded terms (to one who is expert on ssl and https).
> 
> For there to be (over https) an (http) application exchange and only then a request for an https client cert implies a double handshake (typically). The first delivers the app data, which (probably by uri component) induces the server to ask the client to perform a second handshake. In the course of that the server may demand a client cert (should no client cert have been previously communicated, in unsolicited manner.)

yes.

> a second app data request is then delivered through the server socket,

I don't think there needs to be a second request at the APP level. The interesting thing about certificate renegotiation as I see it. is that
this happens during the same TLS connection, and whilst the application is processing data. So the server could make a bit PUT of a video streaming a large amount of data to the server as the guard is deciding wether the client needs access. The renegotiation allows the server as I understand to not interrupt the request at the application layer.

> at which point the server variables for both client cert and ssl cipher suite information will typically be attached to the typical web servers http request (cgi/servlet context).

no sure what you mean by server variables.

> 
> This is essentially what foafssl.me does. As I recall, the foafssl idp site acted similarly. It's not obvious from the script code of webauthid site if it also does this.

not sure what webauthid is. 

On the other hand I have got this to work using the netty engine in Scala with the following code (I showed a less elegant version previously). Essentially at line 192 the server does not have the client certificate, yet at 198 he does. (you can click on the line numbers to get to the code)

   188     
   189     val sslh = r.underlying.context.getPipeline.get(classOf[SslHandler])
   190     
   191     trySome(sslh.getEngine.getSession.getPeerCertificates.toIndexedSeq) orElse {
   192       sslh.setEnableRenegotiation(true)
   193       r match {
   194         case UserAgent(agent) if needAuth(agent) => sslh.getEngine.setNeedClientAuth(true)
   195         case _ => sslh.getEngine.setWantClientAuth(true)  
   196       }
   197       val future = sslh.handshake()
   198       future.await(30000) //that's certainly way too long.
   199       if (future.isDone && future.isSuccess)
   200         trySome(sslh.getEngine.getSession.getPeerCertificates.toIndexedSeq)
   201       else
   202         None
   203     }
   204 



> Be clear. The the first app data is to be delivered to layer 7 code (ie some php script) which decides to induce the handshake that demands a mutual auth ssl session, this is subtly different to the following. Alternatively, the php script only ever receives 1 indication, which always has a client cert in its context.
> 
> Make sure it's clear which pattern must be implemented.
> 
> If its the first pattern, can there be multiple http Tewa/resp over https, before one "upgrades" this session to a mutual auth session?
> 
> If its not obvious why there is any need to distinguish these, just delete the mail.

Unless I am mistaken I don't think we need to go into this. I will try to go a little bit more into the RFC 5746 in the explanation in the new version of the spec I am developing, because it is important to point out that this issue has been solved. But as much as possible I want to rely on the TLS standards as they are. 

http://bblfish.net/tmp/2011/11/21/index-respec.html#authentication-sequence

Perhaps we need to say something more.

Here is a question for you: where are the WANT and NEED methods of requesting a client certificate defined? Every server seems to use those concepts, ...

Henry


> 
> 
> On Nov 20, 2011, at 5:05 AM, "Henry Story" <henry.story@bblfish.net> wrote:
> 
>> Peter Williams had some criticism about the sequence diagram, which it is true whilst being simple is perhaps merging too many things together.
>> 
>> So I propose the following much more precise diagram. I plan to also create a state diagram that would show interactions 
>> more clearly. Here we are looking at a request that succeeds.
>> 
>> 1. We set up a TLS session. The server authenticates.
>> 2. The application layer protocol starts. It passes a guard which can look at the application layer protocol metadata
>>    and request the client certificate if needed. (the guard can have access to ACL information to make this decision)
>> 3. the Guard decides 
>>     a. client authentication is needed  (it's not available in cache) and asks the TLS layer to do that
>>     b. the TLS layer sends a client authentication request
>>     c. the client selects a certificate
>>     d. the TLS agent verifies only that the public sent in the certificate can decrypt the encoded token
>>        ( we need to find the technical jargon for this)
>>     e. if it does the guard ends up with the client certificate
>>  
>> 
>> <WebIDSequence-friendly.jpeg>
>> 
>> 4 . The Guard needs to verify the WebID claims in the certificate, so it sends those to the WebID verifier that follows the
>>    well known procedure, either going through a cache or fetching directly the information on the web (5)
>> 
>> 6. given the identities the guard can decide whether the user with that identity has access to the resource requested by considering
>> its ACLs and the graph of trusted information. (out of scope of detailed study here)
>> 
>> 7. the resource is given access to and the server can send the application layer response to the client
>> 
>> -----
>> 
>> The good thing in this diagram is that
>>  
>>  1. we can make clear that the TLS agent can be bog standard - it just needs to not throw an exception if it does not recognise the issuer.
>>  2. The guard is working at the application layer, and can communicate with the underlying TLS layer.
>>  3. we don't need to specify what the protocol of the request is - but we can give examples of HTTP requests
>>  4. the above makes clear how we can get around any browser issues, and how we can get rid of the most problematic user interface problems: namely the automatic request of the client certificate
>>  
>> Henry
>> 
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
http://bblfish.net/