Hi Henry, > 1) it will be possible on the same connection to authenticate with multiple > different certificates, With the current proposal as it stands, yes.
> 2) the different identities won't ( necessarily ? ) be cumulative ie, a > server getting the identity I1 and then I2 on the same TLS connection won't > be able to conclude that the referent of I1 is the same as the referent of > I2 ? I believe the server can conclude this; the caveat is that in practice a server can only support a limited number of client identities simultaneously. > Thinking of a possible use of this over HTTP I find this surprising. So > perhaps it is not meant to be applied there. Where is it? Indeed there's a surprising number of sites that have a landing page accessible without client auth, but require client auth when a protected resource is accessed. This is currently done via renegotiation; in TLS1.3 we're looking for a way to accommodate such sites. > If that were to work correctly would one not also have to change the > encryption for each user? So far we don't know that one has to change the encryption keys after each client authentication, but this is still under discussion. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of henry.st...@bblfish.net Sent: Tuesday, September 22, 2015 6:10 AM To: tls@ietf.org Subject: Re: [TLS] Review of PR #209 > On 22 Sep 2015, at 01:40, Geoffrey Keating <geo...@geoffk.org> wrote: > > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > >> Consider a server has an ongoing session wrapped in TLS that uses >> client authentication to approve or deny some requests from the >> client. It remembers what requests the client has made as some sort >> of relevant state. Let's take an imap server working with a client >> that has state of a "currently-examined folder", but this applies to >> servers and clients with much more complex state as well. > ... > > I think for such a protocol, you'd want to say that authentication is > not retroactive. > > For other protocols, you might want something else. For example, in a > protocol which uses client authentication for billing, you might want > to treat an authentication half-way through the session as the account > to bill for the entire session. > > Some protocols will also want to support multiple identities, and some > will not. For some protocols a new authentication might want to in > some fashion dis-trust previous authentications, other protocols might > say that all previous authentications are valid until the end of the > session. If I get this right: 1) it will be possible on the same connection to authenticate with multiple different certificates, 2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of I2 ? Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it? If that were to work correctly would one not also have to change the encryption for each user? (sorry to enter the discussion but I am also just checking because I seem to have made a mistaken claim on the HTTP list if 1) is true ) > > > I think this is something that TLS should allow higher-level protocols > to specify. The TLS model could be that each client authentication > happens at a particular point in the session, breaking it up into > segments, and TLS informs the higher-level protocols of where the > segments start and end; it's up to the higher-level protocol to work > out what that means. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
