address comments from Alissa

draft-ietf-emu-eap-tls13.xml

@@ -172,7 +172,7 @@ href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
 
 			<t>For TLS 1.3, resumption is described in Section 2.2 of <xref target="RFC8446"/>. If the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity received in the ticket to negotiate the use of the associated PSK. If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. It is left up to the EAP-TLS peer whether to use resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption as long as the ticket is valid. However, the EAP-TLS server MAY choose to require a full authentication. EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of <xref target="RFC8446"/>.</t>
 
-			<t>It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm in the resumption and the original full authentication. This requirement allows EAP packets to be routable to the same destination as the original full authentication. If this recommendation is not followed, resumption is likely to be impossible. When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication. For example, the NAI @realm can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS PSK identity is typically derived by the TLS implementation and may be an opaque blob without a routable realm. The TLS PSK identity is therefore in general unsuitable for deriving a NAI to use in the Identity Response.</t>
+			<t>It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm in the resumption and the original full authentication. This requirement allows EAP packets to be routable to the same destination as the original full authentication. If this recommendation is not followed, resumption is likely to be impossible. When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication <xref target="RFC7542"/>. For example, the NAI @realm can safely be reused since it does not provide any specific information to associate a user's resumption attempt with the original full authentication. However, reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm can allow a potential attacker to associate the resumption attempt with the original full authentication. The TLS PSK identity is typically derived by the TLS implementation and may be an opaque blob without a routable realm. The TLS PSK identity is therefore in general unsuitable for deriving a NAI to use in the Identity Response.</t>
 
 			<t>A subsequent authentication using resumption, where both sides authenticate successfully (without the issuance of more resumption tickets) is shown in <xref target="figresumption"/>.</t>
 
@@ -627,7 +627,7 @@ SEND-IV      = IV(32, 63)
 
 		<t>Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP addresses) 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 allowing them to obtain access that they should not have.</t>
 
-		<t>If any authorization, accounting, or policy decisions were made with information that has changed between 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-TLS 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-TLS servers SHOULD reject the resumption and continue with a full handshake.</t>
+		<t>If any authorization, accounting, or policy decisions were made with information that has changed between 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-TLS servers MAY reject resumption where the information supplied during resumption does not match the information supplied during the original authentication. If a safe decision is not possible, EAP-TLS servers SHOULD reject the resumption and continue with a full handshake.</t>
 
 		<t>Section 2.2 and 4.2.11,<xref target="RFC8446"/> provides security considerations for resumption.</t>