Change:
Based on the PSK authentication was not included in the past. I think specification has some places where "Client Authentication" refer to only certificate-based client authentication and not client authentication is general. Not a big thing, but I think it might confuse some readers, and would be good to clarify.

Discussion:
PSK). The client MUST send a Certificate message if and only if the server <del> has requested client authentication via a CertificateRequest message (certificate-request).  If the server requests client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </del> <ins> has requested certificate-based client authentication via a CertificateRequest message (certificate-request).  If the server requests certificate-based client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </ins> Structure of this message:

values, these two values are always the same. Note: Although the resumption main secret depends on the client's <del> second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished.  This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </del> <ins> second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </ins> %%% Ticket Establishment

4.6.2. When the client has sent the "post_handshake_auth" extension (see <del> post_handshake_auth), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication-messages). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </del> <ins> post_handshake_auth), a server MAY request certificate-based client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication- messages).  If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished.  All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </ins> A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert. <del> Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </del> <ins> Note: Because certificate-based client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </ins> 4.6.3.