I think this draft is a good start. At the meeting at IETF 65 the working group desired to take this draft as a working group item. Would the authors submit this draft as draft-ietf-emu-rfc2716bis-00.txt.
Comments on the draft: 1. Section 2.4 Identity verification The document specifies that the peer as server ID is carried in the subjectAltName extension. A. It is possible that this extension may be empty and the name be carried in the subjectName. Should this be taken into account? What is the format of the ID, is it represented in ASN.1 format? B. It seems that there may be more than one SubjectAltName. Are both used as the ID? It seems that order would matter for constructing a key name. C. This document should probably reference RFC 3280. D. I think the last paragraph might not be quite correct: "... Please note that in the case where the EAP authentication is remoted that the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination and whether the EAP server exists within a target sub-domain." I'm not quite sure what the is meant by "target sub-domain." In any case it is important that the peer be able to authorize the server as an EAP-Server that can authorize the authenticator the peer is connecting to. This is more than being issued by an organizational CA since that particular CA may issue certificates for many purposes. There either needs to be something in the certificate or the peer must have configuration to be able to perform the authorization. 2. Section 2.5 Key Hierarchy A. Why is the EMSK broken into two halves? It should not be as this implies a particular usage for the EMSK. It should just be one 64 byte value. B. Does this section tie the implementation of the PRF 10 2246? What if TLS 1.2 supports a different PRF? C. This section shoes the TLS key hierarchy, shouldn't it show the EAP-TLS key hierarchy? 3. Section 2.6 Ciphersuite negotiation A. At the SAAG meeting in IETF 65 Sam brought up an issue with multiple layers of negotiation with EAP-TLS. Is there a vulnerability introduced by multiple levels of negotiation? Is it possible that an peer or server will negotiate a weaker authentication method though the negotiation of TLS ciphersuites than it would through EAP negotiation? B. The draft does not seem to specify which ciphersuites it is intended to be used with. Should it? 4. General The document should define a Method-ID (for computing session-ID and key names). The method ID could be as simple as the concatenation of the server and client Finished messages. (these hashes contain the Client and Hello Random's as well as the identities exchanged in the certificates). _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
