General comments: There are several instances of the pernicious practice of treating references to references as if they were something other than pointers; among the most glaring of which are found in 4.2.1.1.3: "NIST publication [NIST SP 800-57p3] can be consulted for a list of acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST publication [NIST SP 800-108] for additional information on secure key derivation." Do these NIST publications have names? If so, please use them (or an appropriately shortened version thereof), along with providing a pointer to the reference itself.
Hyphenation needs to be checked; for example, "certificate based authentication" makes no sense, but "certificate-based authentication" does. Section 3.1, first paragraph, last two sentences say: The tunnel method MUST support this use case. However, it MUST NOT expose the username and password to untrusted parties and it MUST provide protection against man-in-the-middle and dictionary attacks. The combination of the tunnel authentication and password authentication MUST enable mutual authentication. By whom (or what) are the "untrusted patties" referred to not trusted? For example, the AAA proxies in a visited network are certainly trusted _by that network_ (and by inference, the home network) but they may not be trusted (at least as much) as similar entities in the home network _by the user_. Some clarification of the trust model seems to be necessary here, especially given the specification of absolute requirements in the text. Same section, last paragraph, says: Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable an inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems. "New token mode" and "new PIN mode" refer to the proprietary SecureID system from RSA. I don't know why we should be giving RSA free advertising ;-), nor why their system deserves explicit mention. Suggestion: CHANGE: change, "new PIN mode", and "next token mode" required by some systems. TO change and other "housekeeping" functions required by some systems. This might also be a good place to mention that certain data related to authorization may need to be communicated to the peer; it is forbidden to do this in an EAP Success message, but there is no such constraint (yet) upon the TLS tunnel. In section 3.2, first paragraph, third sentence, CHANGE special type of man-in-the-middle attacks TO special type of man-in-the-middle attack Section 3.3, last sentence: CHANGE on the method chaining. TO on method chaining. The meaning of section 3.7 isn't clear to me: what, exactly, is meant by "client" here? Is it the EAP peer, the client machine, both or neither? Is it the user? If so, then that would seem to make a tunneled method unnecessary, except possibly for transmitting other data. Section 3.8, first sentence of first paragraph says: The tunnel method MUST provide extensibility so that additional types of data can be carried inside the tunnel in the future. This statement seems awfully broad to me. Do we really mean _any_ "additional types of data" or is it "additional types of security-related data" or maybe "additional types of data related to network access"? Section 4.1.1, third paragraph says: The tunnel method MUST meet all the EAP method requirements contained in the EAP Key Management Framework [RFC5247] or its successor. The tunnel method MUST include MSK and EMSK generation. This will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework. While it is undoubtedly tempting to simply require compliance with RFC 5247, given the rather incredible amount of drivel and nonsense present in that RFC, it might be a better idea to be specific about precisely what requirements need to be satisfied. Same section, last paragraph: same comment as the last, but in spades. Just one example that leaps out: Section 4.1.1, 4th paragraph of the draft in question says "The tunnel method MUST NOT be tied to any single cryptographic algorithm." and the last paragraph says "The tunnel method MUST meet requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence..." but the subsection on algorithm independence in Section 3 of RFC 4962 says "...an EAP method MAY depend on a specific cryptographic algorithm." While this specific contradiction might be addressed by adding a sentence stating that conflicts are resolved in favor of this draft other, more subtle problems might not. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
