On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan
<karthik.bharga...@gmail.com> wrote:
> As dkg points out, dynamically authenticating clients later in the connection
> brings up
> API issues of how to notify the application about the scope of this new
> authentication event.
>
> I think it is inevitable that implementation will store the client credential
> in the session, and
> that the new (authenticated) stream of data will be concatenated to the older
> (unauthenticated) stream.
> Both of these design choices will lead to the following answers to dkg’s
> questions:
> (a) all messages in TLS sessions (past and present) will be attested to by
> every certificate
> (b) all traffic in earlier and future resumed sessions will be attested to by
> every certificate
>
> In other words, if we do allow this change to client authentication, to be
> safe, we must analyze the
> resulting protocol *as if* applications will use the authentication event to
> attest to all
> data, past and present, that may be associated with the data in the current
> connection.
But this combination is pretty weird for servers to deal with. For
example:
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.
The client is currently examining folder Y.
Some client identities *do not* have authorization to visit folder X.
others do.
The client requests a change to folder X.
The server rejects the change.
The client subsequently authenticates to an identity that is authorized
to access folder X.
What is the currently-examined folder for this session?
The "easy" (and right) answer here is "folder Y, of course" -- but
telling peers that the authentication should apply retroactively to all
previous data sent suggests that maybe it should be folder X.
This is confusing. Confusing semantics are bound to lead to problematic
implementations and usage :(
Sorry that this mail doesn't have a better suggestion to offer.
--dkg
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
