advanced uses of TLS-renegotiation & draft-thomson specs

Hi,

  since this group is considering removal of TLS-renegotiation I thought I should
put some time in gathering together a few notes on what I have learnt in using
it to implement WebID over TLS [1] over the past 5 years, noting that I have learnt
the most in implementations in Scala over the past 2 years [2].

   The key requirements for us are that 
  a) a user can authenticate to a server with just a point and click operation
     in a cryptographically secure manner that is controlled by the chrome of the
     browser ( to avoid any phishing or other attacks )
  b) that the same server be able to serve resources that are public as well as
     secured resources on the same TLS port
  c) that the creation of identity be totally distributed, with the creation of
     identities of close to 0 cost, and such that it ties seamlessly into the web 
     of data (enabling trust to be established through a web of linked profiles). 
     This is what the WebID+TLS protocols offers.

How does renegotiation come into the picture? We want to authenticate the user only
if the resource he is requesting requires authentication. As shown in the Authentication 
Sequence of WebID over TLS [3] we have the following steps:

  1.1) a client connects to a server that authenticates itself using either CA certificates
     or in the close future I hope DANE via DNSSEC, or other things still to be invented....
  1.2) the client then sends the request to the server eg:
     GET /people/henry/foaf HTTP/1.1
  1.3) a guard checks the access control rules on the resource /people/henry/foaf
  1.4) if the guard discovers that the resource is protected and that identification is required
     it starts a TLS renegotiation
     ( in Play [2] this is done via a call to the method of the RequestHeader
         def certs(required:Boolean): Future[Seq[Certificate]] 
     )
  1.5) if a certificate with a WebID in place of the X509 SAN is returned it can 
     verify the WebID 
  1.6) Then it can check its access control rules and serve up the resource or return an error
     page ( a 401 or something like that ).


With the draft-thomson-cant [4] we have the following sequence

  2.1) client connects to server as above
  2.2) client makes a request for a resource as above
  2.3) the server returns a 401 with a "WWW-Authenticate: ClientCertificate" header
  2.4) the client opens a new connection requesting client authentication and sends a 
       certificate
     draft-thomson-cant [4] says
   "A client can use the 'ClientCertificate' challenge as a trigger to open
   a new connection and to use client authentication on that connection.
   The client can use the mechanism in [I-D.thomson-tls-care] to prompt
   the server to request a client certificate, to avoid the problem
   where the server doesn't know to make this request."

  --------------
  If TLS renegotiation is removed then UNLESS thomson-TLS-care is part of TLS-1.3 then client 
  authenticated connection won’t work. THEREFORE something thomson-TLS-care this MUST be part of the new TLS-1.3 spec!!!
  --------------

  Still assuming thomson-TLS-care is adopted as part of TLS-1.3 there are a number of further scenarios:

  2.4.1) The client sends a certificate and this is accepted ( public private key verification procedure )
  2.4.1.1) and the public key determines the identity of the user who is then able to access the requested resource
  2.4.1.2) or the resource is authorised for a number of WebIDs so additional WebID verification is required
  2.4.1.2.1) the WebID is verified
  2.4.1.2.1.1) the WebID is authorised for the request method on the resource and so the action is allowed ( a document is returned)
  2.4.1.2.1.2) the WebID is not authorised and a 401 is returned, with some explanation ( would be nice if this were machine readable - RDF for example ) 
  2.4.1.2.2) The WebID is not verified so a 401 is returned with some explanation ( in machine readable format would be nice) such as
    - the remote server is down
    - the remote server was up, but did not contain the relevant information
    - the WebID is an http WebID and not an HTTPS WebID and so security is not strong enough
    - the remote WebID profile server is not trusted for some reason
  2.4.2) the client sends a certificate and this is not accepted 
     The question here is whether the TLS signals that describe failure are sophisticated enough so that the chrome can
     give the user a good explanation as to why the secure connection could not be accomplished
     I suppose the main issue would be if the public key cryptography did not succeed or if the certificate was somehow 
     not parseable.
     All other cases it seems to me could be dealt with at the HTTP layer e.g.:
        - certificate issuer not trusted ( though WebID authentication does not need that )
        - certificate out of date
        - certificate extensions not understood
     That is the server could open a connection and flag it as faulty, so that the HTTP layer could then provide
     explanations, and other means of authenticating.


  But we still have a problem. Currently TLS-renegotiation allows the server to specify what Certificate Authority Distinguished Names
it will accept certificates from. This should allow the browser to filter certificates from certain CAs when presenting them to the user.
draft-thomson-cant [4] needs to offer the same functionality at the HTTP layer. IE to cover current cases of TLS-Authentication the server needs to specify at the HTTP layer in the 401 WWW-Authenticate: ClientCertificate header what Distinguished Names it accepts. Because it is a web protocol, it might as well add the option to identifying issuers not by DN but rather by WebID [6], as specified in a Issuer Alternative Name field of the X509 certificate. If that list is too long one could even imagine the "WWW-Authenticate: ClientCertificate" header containing a field pointing to a list of accepted CAs.

  But as shown by the WebID protocol there is no need for Certificate Authorities when using client side certificates. So there should be a way for the HTTP response from the server to specify that it will accept any WebID enabled certificate ( Ie a certificate with a WebID in the Subject Alternative Name field of the X509 )
 
 In my work on deploying WebID I have come to the conclusion that due to JavaScript weaknesses in the browser ( e.g.: the limitation of CORS security to identifying JS only by its origin ) most of the requests for remote resources will need to go through a proxy on the users personal server that will be able to make these requests. The advantage is that we won't need to wait for browser vendors to implement this. Server to server communication will be able to implement this to great advantage immediately. This means that one will also need to consider that for a period of time there will be clients that understand the "WWW-Authenticate: ClientCertificate" headers that co-exist with one's that don't. So a server will want to offer a number of authentication options.

That's as much I can think of right now.

Hope that helps,

	Henry Story
      

[1] The full set of specs for WebID is here:
    http://www.w3.org/2005/Incubator/webid/spec/
    with curl examples 
    https://github.com/read-write-web/rww-play/wiki/Curl-Interactions

[2] especially in rww-play
    https://github.com/read-write-web/rww-play    
    where I had to patch Play to allow Client side renegotiation 
    https://github.com/bblfish/Play20
    This patch has not been pushed into Play yet, because 
    1) as the patch was written it requires the request for renegotiation to
       be made in the same JVM as the one holding onto the TLS request. Their current implementation
       is based on netty. 
    2) They are moving to a fully actor based framework using akka ( http://akka.io ) 
       and an http framework based on that http://spray.io/ which makes it easy to build
       all these connections as message passing between actors that can then reside on 
       different machines, solving (1) above in a much more elegant fashion. This type
       of programming even makes it easy to send messages across layers.

[3] http://www.w3.org/2005/Incubator/webid/spec/tls/#the-webid-authentication-protocol
[4] http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
[5] http://tools.ietf.org/html/draft-thomson-tls-care-00
[6] http://www.w3.org/2005/Incubator/webid/spec/identity/

Social Web Architect
http://bblfish.net/

Received on Thursday, 3 July 2014 10:42:13 UTC