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. 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
