On Feb 15, 2023, at 9:53 PM, Roman Danyliw via Datatracker <nore...@ietf.org> wrote: > ** Section 2.4 > It is therefore RECOMMENDED that EAP servers always send a TLS > NewSessionTicket message, even if resumption is not configured. When > the EAP peer attempts to use the ticket, the EAP server can instead > request a full authentication. Implementations SHOULD NOT send > NewSessionTicket messages until the "inner tunnel" authentication has > completed, in order to take full advantage of the message as a > protected success indication. > > It is my understanding that this SHOULD NOT is based in implementation > realities. Can text be added to establish the basis for this not being “MUST > NOT”. Please also add cross-references as appropriate into the document on > the > same topic.
The issue is discussed in more detail in the Security Considerations section. I'll add some text here which references RFC 8446 Section 4.6.1. In short, TLS 1.3 allows for NewSessionTicket to be sent from the server, even before the application data has been processed. This means that a client could connect, get a ticket, disconnect, and then immediately "resume" the session, without ever being fully authenticated. As a result, EAP implementations have to either reject session tickets which were sent before the user was authenticated, or delay sending NewSessionTicket until after the user has been authenticated. On closer examination, the text about NewSessionTicket is in the "TTLS" section, but is really applicable to all TLS-based EAP methods. I'll move the text from the Security Considerations section to a new section discussing TLS NewSessionTicket messages in more detail. Here's some new text: Section "Handling of TLS NewSessionTicket Messages" In some cases, client certificates are not used for TLS-based EAP methods. In those cases, the user is authenticated only after successful completion of the inner tunnel authentication. However, [RFC84346] Section 4.6.1 allows that "At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message." This message is sent by the server before the inner authentication method has been run, and therefore before the user has been authenticated. This separation of data allows for a "time of use, time of check" security issue. Malicious clients can begin a session and receive a NewSessionTicket message. The malicious client can then abort the authentication session, and use the obtained NewSessionTicket to "resume" the previous session. The malicious client can then obtain network access without ever being authenticated. As a result, EAP servers MUST NOT permit sessions to be resumed until after authentication has successfully completed. This requirement may be met in a number of ways. Where possible, implementations SHOULD NOT send TLS NewSessionTicket messages until the "inner tunnel" authentication has completed successfully. However, the interaction between EAP implementations and any underlying TLS library may be complex, and this behavior may not always be possible. Is is up to the EAP server to ensure that it does not allow for insecure uses of EAP. It may not be possible to delay the TLS NewSessionTicket messages until the "inner tunnel" authentication has completed successfully. In that case, the EAP server MUST NOT allow the session ticket to be valid (or validated) until after the "inner tunnel" authentication has completed. For example, if the ticket is cached on the server, the server coudl skip caching the session ticket until after authentication has completed. Alternatively, the server could mark up the session ticket with a flag stating whether or not authentication has completed. This issue is not relevant for EAP-TLS, which uses client certificates for authentication. It is only relevant for TLS-based EAP methods which do not use the TLS layer to authenticate _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
