On Mar 11, 2019, at 12:52 PM, John Mattsson <[email protected]> wrote: > 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
Sounds good. > 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. It may be worth mentioning it here, and saying that the implementations should be aware of it, and take steps to address it. > 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. That looks good. > 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 nit: "therefore is trivial", or "is therefore trivial" > 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 nit: I'd say "based on examining unauthenticated information" Otherwise it could be seen as rejecting the session if unauthenticated information *exists*. > 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. It might be worth mentioning the unauthenticated data here, too. > 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 nit: "needs" > 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. Very good points, and something I had missed. > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
