Thanks Katrin, I propose we leave section 4.2.1.1.2 as is and adopt the supplied text to replace 4.2.1.1.3 (keeping the change from issue 22).
Cheers, Joe > -----Original Message----- > From: Hoeper Katrin-QWKN37 [mailto:[email protected]] > Sent: Friday, September 11, 2009 1:21 PM > To: Joseph Salowey (jsalowey); [email protected] > Subject: RE: [Emu] Issue #23: Tunnel Protection requirements > > Please find my comments and suggested solution inline. > > Katrin > > PS: Note that NIST DRAFT SP 800-120 and SP 800-57 part 3 both > completed the public call for comments a while ago and can be > expected to be published soon. > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > Joseph Salowey (jsalowey) > > Sent: Thursday, August 06, 2009 3:12 PM > > To: [email protected] > > Subject: [Emu] Issue #23: Tunnel Protection requirements > > > > #23: Tunnel Protection requirements > > > > > Section 4.2.1.1.2 > > > > > > "See Part 1 of the NIST Recommendation for > > > Key Management [NIST SP 800-57] for a discussion of > the relative > > > strengths of common algorithms." > > > > > > Why not reference the NIST SP 800-120 requirements here? > > > [KH] This issue talks about Section 4.2.1.1.2 "Tunnel Data > Protection Algorithms". Here it is required that "The tunnel > method MUST provide at least one mandatory to implement > cipher suite that provides the equivalent security of 128-bit > AES for encryption and message authentication." > > The reference to NIST SP 800-57 part 3 is meant to help > implementers to determine other cryptographic algorithm with > key lengths that correspond to 128-bit AES security. This > NIST recommendation is the correct reference here because it > lists the security strength of crypto algorithms with > particular key lengths. > > On the other hand, NIST SP 800-120 (not published yet, but > will be soon) describes security requirements for tunnel > protocols, including requirements for data protection. Note > that these requirements are for Federal networks and it would > need to be determined whether these requirements are > reasonable (i.e., not too restrictive) for commercial networks too. > > So either we leave the text as is, i.e. with one example of > how to do it and a reference on how to construct other secure > solutions, or we delete the current text and say that "The > tunnel method MUST provide at least one mandatory to > implement cipher suite that meets all security requirements > for data protections of a tunnel protocol in NIST DRAFT > Recommendation for EAP Methods Used in Wireless Network > Access Authentication [NIST SP 800-120]." > > > > > > > > > "o One-way key derivation > > > o Cryptographically separated keys. > > > o Cryptographically separated entities. > > > o Identity binding > > > o Context binding > > > o Key lifetime > > > o Mutual implicit key authentication > o Key freshness" > > > > > > Given that this document assumes a TLS-based tunnel > method, > the > > text on requirements can be made considerably more > specific and > > actionable based on TLS properties and the > specific > requirements of > > NIST 800-120. > > > As it stands, a number of these requirements either > don't > apply > > to EAP methods at all (e.g. context binding, key > lifetime) but > > rather to other elements of the system, or are > automatically > > provided by TLS (e.g. key freshness, Identity > binding). > > > > > > So these requirements need to be made actionable and > > specific. > > The ones that don't apply to the problem at hand > (e.g. TLS-based > > tunnel euth) should be removed. > > > > > > [KH] This issue addresses Section 4.2.1.1.3. "Tunnel > Authentication and Key Establishment". I agree that the > requirements need to be more specific and some need to be > removed altogether. > > NIST DRAFT Recommendation for Key Management, Part 3 [NIST SP > 800-57, part3] will be published soon and specifically lists > secure ciphersuites for Federal Government Use of TLS v1.0, > v1.1 and v1.2, including conventional public key, elliptic > curve and pre-shared key ciphersuites. > These ciphersuite meet strict security requirements. > > In NIST DRAFT Recommendation for EAP Methods Used in Wireless > Network Access Authentication [NIST SP 800-120], the > requirements for TLS ciphersuites also refer to NIST SP > 800-57, part3. However, in addition requirements for > authentication and key establishments for tunnel protocols are listed. > > I suggest changing the text in Section 4.2.1.1.3 to > > "A tunnel method MUST provide unidirectional authentication > from authentication server to EAP peer or mutual > authentication between authentication server and EAP peer. > The tunnel method MUST provide at least one mandatory to > implement cipher suite that provides certificate-based > authentication of the server and provides optional > certificate-based authentication of the client. Other types > of authentication MAY be supported. > > At least one mandatory to implement cipher suite MUST be > approved by NIST DRAFT Recommendation for Key Management, > Part 3 [NIST SP 800-57, part3], i.e., the ciphersuite MUST be > listed in Table 4-1, 4-2 or 4-3 in [NIST SP 800-57, part 3]. > > The mandatory to implement cipher suites MUST NOT include > "export strength" cipher suites, cipher suites providing > mutually anonymous authentication or static Diffie-Hellman > cipher suites. > > Other ciphersuites MAY be selected following the security > requirements for tunnel protocols in NIST DRAFT > Recommendation for EAP Methods Used in Wireless Network > Access Authentication [NIST SP 800-120]." > > > > -- > > Ticket URL: <http://trac.tools.ietf.org/wg/emu/trac/ticket/23> > > emu <http://tools.ietf.org/wg/emu/> > > > > _______________________________________________ > > Emu mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
