On Jan 10, 2023, at 2:46 PM, Heikki Vatiainen <[email protected]> wrote: > > For me there is a little confusion caused by "PAC-Opaque in SessionTicket > > extension" which leads to a resumed session...which then leads to a > > refreshing of a PAC in a resumed session which conflicts with section 3.2.3 > > stating "A peer SHOULD NOT request that a new PAC be provisioned after the > > abbreviated handshake, as requesting a new session ticket based on resumed > > session is not permitted.". > > I noticed the same thing. The sentence Alexander quoted above was added in > TEAP draft -05. Section 3.2.3 was not changed otherwise: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-eap-tunnel-method-04&url2=draft-ietf-emu-eap-tunnel-method-05&difftype=--html > > The other changes between versions seem not to explain why the above sentence > was added. My take is that the sentence was added to further enforce this > requirement: > > 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.
I'll take that as a note to update. > 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. I'm not sure what it means to distribute a PAC in a NewSessionTicket message. How is the client supposed to know that the NewSessionTicket contains a PAC? The overlap in functionality between TEAP and TLS is confusing, and likely to cause problems. If I were to start "fresh", I would suggest that the two are completely unrelated. i.e. the provisioning of "inner method" credentials is entirely unrelated to TLS session resumption. I'm not sure that change can be done with TEAPv1 as it is. > 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. And TLS 1.3 allows for NewSessionTicket to be sent before the client is authenticated. :( > 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. I agree. > 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'. I'll see if I can put something together based on that. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
