- From: <henry.story@bblfish.net>
- Date: Sun, 9 Mar 2014 18:28:23 +0100
- To: public-webid <public-webid@w3.org>
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