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 From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Wong Sent: Tuesday, February 14, 2017 8:18 AM To: David Benjamin <david...@chromium.org> Cc: Cas Cremers <cas.crem...@cs.ox.ac.uk>; tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 On Feb 14 2017, at 4:44 pm, David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> wrote: NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it. Oups, my bad. What about if the client do send a certificate, but the server decides not to accept it, but goes on with the connection (I think nothing in the spec says that the server needs to terminate the connection if the client cert is not good).
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
