Hi, I think the idea that "this is the best we can do" depends on quite a number of assumptions. In theory, I think it is easy to fix, but of course in the design space we're in, the trade offs are more complex.
We also have to consider the non-web use cases where one might expect more symmetric guarantees between client and server. Indeed, "principle of least surprise": I personally find this lack of agreement for the client surprising, i.e., the fact that the client it is not informed by the server on its authentication status, especially since the server asked for the certificate in the first place. This is even the case if the server doesn't implement the reject-cert-but-continue option, for the post-handshake authentication. I can imagine applications that depend on the assumption that the client knows that it has been authenticated, to both decide what it should send, or to correctly interpret what it is receiving. To me, this means we need to at least document this. We'll draft a PR. Best, Cas On Wed, Feb 15, 2017 at 11:00 AM, Martin Rex <m...@sap.com> wrote: > I think the issue is more about the "principle of least surprise". > > The client needs to know whether it offered authentication by client cert > and which client cert it offered. Whether the server accepted it, and > caches the accepted cert in the session or in a session ticket, is > the business of the server (it may help in troubleshooting to know, > but should not be necessary for application flow control). > > Clients asserting multiple identities sounds extremely awkward to me. > > We do have clients in posession of multiple client certs, but our > application > must specify _before_ each TLS handshake which client identity to use (and > this information is necessary for client-side session caching, > and client-side session lookup. > > There is a significant difference between cached sessions where a > specific client cert was used (or at least offered by the client), > and cached sessions where no client cert was offered. > > If a client tries to access a resource through a session that is > authenticated with SSL client cert A, and the server-side authorization > decision denies access to client cert A, then this will typically > result in an access failure, _without_ the server asking for a different > cert. > > When no client cert has been used in a session then access to a resource > that requires a (particular) client cert may result in a request of the > server for a client cert (renegotiation up to TLSv1.2) after seeing the > request--provided that the server supports renegotiation. > > > -Martin > > > > Andrei Popov wrote: > > > > Is it important for the client to know, from the TLS stack itself, > > whether client authentication succeeded or not? My assumption > > (perhaps incorrect) has been that it is the server that cares about > > the client's identity (or identities) in order to make an > > authorization decision. > > > > This thread also seems to consider client authentication a binary state: > > the client is either authenticated, or not. In practice, the client may > > assert multiple identities, and the server may grant various levels > > of access. > > > > Also, why should the client care whether session ticket X includes client > > identity Y? If a client resumes a TLS session with a session ticket that > > does not include (or point to) a client authenticator needed to satisfy > > the client's request, the server can initiate client auth (or deny the > > request). > > > > Cheers, > > > > Andrei >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
