Thanks Alan, your text looks good. On Thu, Feb 16, 2023 at 5:48 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Feb 16, 2023, at 1:28 AM, Joseph Salowey <j...@salowey.net> wrote: > > [Joe] I think having a separate section in the security considerations > for Session Resumption is a good idea. A few comments on the text below > since I think there is a potential difference between how TTLS recommends > overloading newSessionTicket as a protected result indicator and uses of > NesSessionTicket in other methods where it can be used for session > resumption of TLS while still executing an inner method. > > OK > > > 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. > > > > [Joe] I suggest changing the last sentence to: > > > > "If the server assumes the ticket was issued after the client was > authenticated then, > > the malicious client can then obtain network access without ever being > authenticated. " > > It's the "server" as whole, but really the TLS implementation. A naive > EAP implementation can "hand off" all TLS work to a TLS library. The > library then magically allows resumption and the EAP server has a security > issue. Perhaps change it to: > > If the server allows the session to > resume without verifying that the user had first been authenticated, > the malicious client can then obtain network access without ever being > authenticated 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. > > > > > > [Joe] How about the following. > > I find the suggested text a bit harder to read. For me, there is a > clear distinction between the EAP application, and the underlying TLS > library it uses. Microsoft has a common TLS library used by multiple > applications. OpenSSL plays a similar role elsewhere. > > It's a good idea to suggest re-running the inner method on resumption > where session tickets cannot be validated. And also that policies can > control whether resumed sessions are resumed, or the inner methods are > run. This is how my software works, and it's good to explain those issues > in this document. > > After some major rework, how about the following text. For me, it goes > through all possibilities in excruciating detail. I can say this is what > implementors need, because I've run into pretty much all of these issues. > > As a result, EAP servers MUST NOT assume that a user has been > authenticated simply because a TLS session is being resumed. Even if > a session is being resumed, an EAP server MAY have policies which > still force the inner authentication methods to be run. For example, > the users password may have expired in the time interval between first > authenticaction, and session resumption. > > The guidelines given here therefore describe situations where an EAP > server is permitted to allow session resumption, not where it is > required to allow session resumption. An EAP server could simply > refuse to issue session tickets, or could run the full inner > authentication even if a session was resumed. > > Where session tickets are used, the EAP server SHOULD track the > successful completion of an inner authentication, and associate that > status with any session tickets issued for that session. This > requirement can be met in a number of different ways. > > One way is for the EAP server to simply not send any TLS > NewSessionTicket messages until the inner authentication has completed > successfully. The EAP server then knows that the existence of a > session ticket is proof that a user was authenticated, and the session > can be resumed. > > Another way is for the EAP server to simple discard or invalidate any > session tickets until after the inner authentication has > completed successfully. When the user is authenticated, a new TLS > NewSessionTicket message can be sent to the client, and the new ticket > cached and/or validated. > > Another way is for the EAP server to associate the inner > authentication status with each session ticket. When a session ticket > is used, the authentication status is checked. When a session ticket > shows that the inner authentication did not succeed, the EAP > server MUST run the inner authentication method(s) in the resumed > tunnel, and grant only access based on the success or failure of those > inner methods/ > > However, the interaction between EAP implementations and any > underlying TLS library may be complex, and the EAP server may not be > able to make the above guarantees. Where the EAP server is unable to > determine the users authentication status from the session ticket, it > MUST assume that inner authentication has not completed and it MUST > run the inner authentication methods in the resumed tunnel before > granting access. > > > 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 > > > > > > [Joe] SInce TLS 1.3 allows for client authentication at anytime, but > EAP-TLS only allows it during the initial handshake change the first > sentence to: > > > > This issue is not relevant for EAP-TLS, which only uses client > certificates for authentication > > in the TLS handshake. > > Sure. > > Alan DeKok. > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
