[Emu] Issue 61 Clarifying NAI handling during resumption
Please review and discuss the following on this thread. Alan's review raised the issue that the text allows for different identities to be used for the initial handshake and subsequent resumption. Instead the proposal is to always use the same NAI for resumption as for the initial handshake. I'd like to understand the reason for this concern. It seems like this would make things worse from a privacy perspective unless we also required the NAI to just be @REALM which is the minimum amount of information that can be disclosed and still have the current system work. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Issue 47 Certificate identity checks
Please review the following proposal and discuss it on this thread. RFC 5216 lacks guidance on how to validate the EAP server's certificate especially with respect to identities. RFC 5216 recommends validating the certificate path is valid and that the extended key usage attributes are either not present, allow for any usage or allow for TLS server usage. This creates an issue that if the same truest root is used for EAP TLS and for other TLS server usage that any TLS server will be able to extend its privilege and behave as an EAP server. The following recommendations are made for implementations and deployments to avoid this problem. 1. EAP TLS Peer implementations SHOULD allow for configuration of names to match against SANs of type DNS name that are authorized to act as EAP-TLS servers. 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770. EAP TLS peer implementations SHOULD allow for the configuration to require the id-kp-eapOverLAN EKU for validation of EAP server certificates. 3. If the above options are not available then separate trust roots need to be used to issue certificates for EAP-TLS server and for TLS servers. EAP TLS peer implementations MUST allow for configuration of a unique trust root to validate the server's certificate. EAP-TLS peer implementations SHOULD provide ways to automate the configuration of the information necessary for the validation of the certificate. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Issue 59 - Key Update
Please review the following proposal and discuss issues on this thread. Alan's review pointed out the following Section 2.1.1 says: >TLS 1.3 introduced the Post-Handshake KeyUpdate >message which is not useful and not expected in EAP-TLS. > Q: What does it mean that the message is "not expected"? This seems > like a source of implementation-defined behavior, which experience > shows has been a source of interoperability and security issues. This does seem to require some more specification. Here is a proposal. "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not useful and not expected in EAP-TLS. Implementations SHOULD NOT send a KeyUpdate message. If a KeyUpdate message is received then an implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate message in response." I think this is better than "implementations MUST NOT send this message and MUST fail upon reception". The problem here is that the EAP TLS implementation may not have control over this behavior. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
