On Tue, 10 Jan 2023 at 03:52, Alan DeKok <al...@deployingradius.com> wrote:
> On Jan 9, 2023, at 2:43 AM, Alexander Clouter <alex+i...@coremem.com> > wrote: > > > Appendix C.1 - Successful Authentication > [cut] > > 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. 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. > Now I have been blending to mean the same 'resumed' and 'abbreviated > handshake' which probably means other readers will too. Maybe we should > explicitly state somewhere: > > > > 'resumed session' - no inner authentication methods take place > > 'abbreviated handshake' - shorter TLS handshake > > I'll take a note about that. > 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'. -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
