Re: [TLS] Review of PR #209

[Geoffrey Keating <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> 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.