Fwd: [TLS] Renegotiation and client authentication

Below an interesting thread on the TLS mailing list
with a protocol extension for TLS 1.3
> http://datatracker.ietf.org/doc/draft-thomson-tls-care/

which would allow WebID perhaps to be better integrated into the 
HTTP layer.

Begin forwarded message:

> From: "henry.story@bblfish.net" <henry.story@bblfish.net>
> Subject: Re: [TLS] Renegotiation and client authentication
> Date: 9 March 2014 18:13:14 CET
> To: Martin Thomson <martin.thomson@gmail.com>
> Cc: Jim Schaad <ietf@augustcellars.com>, "tls@ietf.org" <tls@ietf.org>
> 
> 
> On 8 Mar 2014, at 17:25, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>> On 8 March 2014 16:19, Jim Schaad <ietf@augustcellars.com> wrote:
>>> There is a major requirement for renegotiation for protection of the client
>>> credentials that is being used in various EAP methods as well.  HTTP is not
>>> the only use of this.
>> 
>> I'd be interested in learning whether a similar mechanism would suffice for you.
>> 
>> Nonetheless, this is a decision that is being made for HTTP.
>> Presumably EAP could continue to use renegotiation.
>> 
>> I recommend you explain your use case for renegotiation, since it's at
>> risk in TLS 1.3.
> 
> Btw, I have a use case for renegotiation that I would like to check here.
> The WebID over TLS spec needs it as things stand at present:
> 
> http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence
> 
> It's all a question of politeness: of when one should ask a client for its identity.
> We need to be able to allow a well behaved site to respect people's desire for anonymity
> as long as possible.
> 	On many sites most pages may not need client authentication at all, and only a few 
> pages (which may only be accessible after a longer browse through the site) may require it. Not
> having client authentication renegotiation would require the client to authenticate to the 
> site before even having seen the first page. This would be akin to not allowing someone 
> into a shop before they showed their ID. It may be fine in a war/military situation, but not in a 
> commercial  environment. In all shops I know of one allows people to browse what is available
> without bothering them for their identity. Allowing a client to browser information is what
> is going to allow the client to make a decision as to the value of revealing her identity.
> 
> Also some pages MUST NOT have client authentication. For the WebID protocol this would
> be the WebID profile page. Having client authentication on that page could result in an
> infinite loop, since servers can be clients too in that spec. Consider what would happen
> in step 6 of the spec without renegotiation:
>  If Alice's server was required to authenticate to get Bob's profile, and used the WebID
> enabled certificate of Alice, then Bob's server would need to authenticate Alice. This would
> require it to get Alice's profile. But if that also required authentication we'd be back at 
> step 6 of the diagram mentioned above, and there would be deadlock.
> 
> 
> ----
> 
> But perhaps with "Client Authentication Request Extension for (D)TLS" [1] mentioned earlier in this
> thread the HTTP2.0 spec could be updated to allow the server in a 401 to express it's capacity
> to accept TLS authentication too - perhaps even WebID certificate authentication. 
> In which case browsers would be able to offer that option to their end users.
> 
> -----
> 
> Perhaps this would also solve the current problem with the need for servers to be set up in WANT or NEED 
> mode (which is also a problem of politeness) and which I think is tied to 
> section 7.4.6 of RFC5246 [2]. If a server is in WANT mode and asks the client for a certificate,
> but the client does not wish to authenticate, then the server can continue - by for example politely
> returning an HTTP 401 and a human readable error message, or by redirecting to another page 
> ( a login page with username-password for example ). In NEED mode the server breaks down the connection
> in an ugly way - since the error handling of TLS is much less advanced than that of HTTP.
> I have not yet worked out why some clients - such as curl or Opera ) only send a certificate when 
> the server is in NEED mode, and not in WANT mode. ( please let me know ).
> 
> But again with "Client Authentication Request Extension for DTLS" that could be left to the HTTP
> layer to ask the client for authentication, and so perhaps that problem would go away too...
> 
> Henry
> 
> 
> [1] http://datatracker.ietf.org/doc/draft-thomson-tls-care/
> [2] http://tools.ietf.org/html/rfc5246#page-55
> 
> 7.4.6.  Client Certificate
> 
>   When this message will be sent:
> 
>      This is the first message the client can send after receiving a
>      ServerHelloDone message.  This message is only sent if the server
>      requests a certificate.  If no suitable certificate is available,
>      the client MUST send a certificate message containing no
>      certificates.  That is, the certificate_list structure has a
>      length of zero.  If the client does not send any certificates, the
>      server MAY at its discretion either continue the handshake without
>      client authentication, or respond with a fatal handshake_failure
>      alert.  Also, if some aspect of the certificate chain was
>      unacceptable (e.g., it was not signed by a known, trusted CA), the
>      server MAY at its discretion either continue the handshake
>      (considering the client unauthenticated) or send a fatal alert.
> 
> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/

Received on Sunday, 9 March 2014 17:29:13 UTC