Hi, There seems to be agreement on the list to add security considerations on authorization and resumption. With the text from Alan as a basis (thanks again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
Some high level changes from Alas text: - Some considerations also cover the EAP peer - Description of encapsulation protocols moved from resumption to authorization - Added that revocation status and authorization may change before resumption Discussing with me co-author, we agreed that cross-method resumption may be best to discuss in Alans document that talks about various TLS-based EAP methods. That document is expected to go into the various methods in more detail. The text below is what I plan to submit at midnight UTC time. I there are comments before that, I can try to update the text, otherwise we can work on the text in the coming weeks before Prague. Cheers, John 2.2. Identity Verification The identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information SHALL NOT be used for accounting purposes or to give authorization. The authenticator and the EAP server MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. They MAY reject conversations if the identity does not match their policy. Note that this also applies to resumption, see Sections 2.1.2, 5.6, and 5.7. 5.6. Authorization EAP-TLS may be encapsulated in other protocols, such as PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. Systems implementing those protocols interact with EAP-TLS and can make policy decisions and enforce authorization based on information from the EAP-TLS exchange. The encapsulating protocols can also provide additional, non-EAP information to the EAP server. This information can include, but is not limited to, information about the authenticator, information about the EAP peer, or information about the protocol layers below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, etc.). As noted in Section 2.2, the identity presented in EAP-Response/ Identity is not authenticated by EAP-TLS and therefore trivial for an attacker to forge, modify, or replay. Authorization and accounting MUST be based on authenticated information such as information in the certificate or the PSK identity and cached data provisioned for resumption as described in Section 5.7. Note that the requirements for Network Access Identifiers (NAIs) specified in Section 4 of [RFC7542] still apply and MUST be followed. Policy decisions are often based on a mixture of information from TLS, EAP, and encapsulating protocols. EAP servers MAY reject conversations based on unauthenticated information such as an unknown MAC address or an identity provided in in EAP-Response/Identity that do not match a certain policy. 5.7. Resumption There are a number of security issues related to resumption that are not described in [RFC5216]. The problems, guidelines, and requirements in this section therefore applies to all version of TLS. When resumption occurs, it is based on cached information at the TLS layer. As described in Section 2.2, the identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. To perform resumption in a secure way, the EAP peer and EAP server need to be able to securely retrieve information such as certificate chains, revocation status, and other authorization information from the initial full handshake. We use the term "cached data" to describe such information. Any authorization applied during resumption MUST be done using this cached data. There are two ways to retrieve the needed information. The first method is that the TLS server and client caches the information locally, identified by an identifier and secured by the other party showing proof-of-position of a key obtained from the initial full handshake. For TLS versions before 1.3, the identifier can be the session ID, for TLS 1.3, the identifier is the PSK identity. The second method is via [RFC5077], where the TLS server encapsulates the information into a ticket and forwards it to the client. The client can subsequently do resumption using the obtained ticket. Note that the client still need to cache the information locally. The following requirements apply to both methods. If the EAP server or EAP client do not apply any authorization policies, they MAY allow resumption where no cached data is available. In all other cases, they MUST cache data during the initial full authentication to enable resumption. The cached data MUST be sufficient to make authorization decisions during resumption. If cached data cannot be retrieved in a secure way, resumption MUST NOT be done. The above requirements also apply if the EAP server expects some system to perform accounting for the session. Since accounting must be tied to an authenticated identity, and resumption does not supply such an identity, accounting is impossible without access to cached data. Some information such as IP addresses and the identity provided in EAP-Response/Identity may change between the initial full handshake and resumption. This change creates a "Time of check, time of use" (TOCTOU) security vulnerability. A malicious or compromised user could supply one set of data during the initial authentication, and a different set of data during resumption, potentially leading to them obtaining access that they should not have. If any authorization, accounting, or policy decisions were made with information that have changed since the initial full handshake and resumption, and if change may lead to a different decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, and policy decisions are reevaluated based on the information given in the resumption. EAP servers MAY reject resumption where the information supplied during resumption does not match the information supplied during the original authentication. Where a good decision is unclear, EAP servers SHOULD err on the side of caution, and therefore reject the resumption. Any security policies for authorization and revocation MUST be followed also for resumption. The EAP client and server MAY need to recheck the authorization and revocation status of the other party. The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have been reduced. It is difficult to state the above requirements more precisely. If the EAP server determine that the user is acting maliciously, they MUST reject the resumption. It's up to each implementation and / or deploymentment of EAP-TLS to determine which information to examine, and which policies to apply. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
