Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[[e-mail] (Martin Rex)]

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