Re: [Emu] Issue #23: Tunnel Protection requirements

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

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:khoeper at motorola.com] 
> Sent: Friday, September 11, 2009 1:21 PM
> To: Joseph Salowey (jsalowey); emu at ietf.org
> 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: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On 
> Behalf Of 
> > Joseph Salowey (jsalowey)
> > Sent: Thursday, August 06, 2009 3:12 PM
> > To: emu at ietf.org
> > 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
> > Emu at ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
>