alandekok
commented
1 year ago The consensus was to remove the PAC, so this issue is no longer relevant.
Closed alandekok closed 1 year ago
alandekok
commented
1 year ago The consensus was to remove the PAC, so this issue is no longer relevant.
Section 3.8.1 'PAC Provisioning' reads: The peer MUST successfully authenticate the EAP server and validate the Crypto-Binding TLV as defined in Section 4.2.13 before issuing the request.
The example in Appendix C.1 is correct when considering the section 3.8.1 requirement and would also comply with section 3.2.3 if the text in 3.2.3 is updated to consider the following:
1) A server must not issue a session ticket with NewSessionTicket Handshake Message before the section 3.8.1 requirement is met. In other words, the message flow in Figure 2 of Session ticket RFC is seems to never be applicable with TEAP: https://www.rfc-editor.org/rfc/rfc5077#section-3.1
In this flow NewSessionTicket is sent by the server before it sends ChangeCipherSpec to finish the session ticket based handshake.
Note that this does not prohibit the use of NewSessionTicket. https://www.rfc-editor.org/rfc/rfc5077#section-5.8 reminds that a TLS session renegotiation can be used to send a NewSessionTicket message. Because both the server and the client can renegotiate, they both need to be careful and ensure that the section 3.8.1 requirement is met.
2) I'd say it would be easiest not to distribute PAC with RFC 5077 NewSessionTicket message. However, TEAP RFC section 3.2.2. 'TLS Session Resume Using a PAC' appears to require NewSessionTicket support. A quote from 3.2.2:
Implementations MUST support the TLS Ticket extension [RFC5077] mechanism for distributing a PAC and may provide additional ways to provision the PAC, such as manual configuration.
3) Turning off TLS renegotiation would ensure that NewSessionTicket is not sent after the initial handshake. On the other hand, the TEAP RFC has a number of uses for renegotiation.
4) Based on the above, my understanding is that a TEAP peer must be very careful about when it accepts a NewSessionTicket and the TEAP server must also be careful that it does not send an unexpected NewTicketSession during an initial handshake or renegotiation handshake.
Maybe something like this:
'abbreviated handshake' is based on TLS session ticket or TLS session id. That is, when TLS state kept on client or server side is used to start an initial (or renegotiated) TLS handshake. This hansdhake may succeed or fail.
'resumed session' a session that is re-established after a successful 'abbreviated handshake'.