Subject: [Emu] Issue #22: Collection of smaller issues

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 6 Aug 2009 13:10:45 -0700

#22: Collection of smaller issues

 > Section 4.1.1
 >
 > "  The tunnel method MUST meet all the MUST and SHOULD requirements
 >    relevant to EAP methods 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."
 >
 > The primary aspects of [RFC5247] that apply to EAP methods is
 > the generation of the Peer-Id, Server-Id and Session-Id.  Why
 > not just spell out those requirements specifically?
 >
 Suggested Text:
 "The tunnel method MUST meet all the MUST and SHOULD requirements
    relevant to EAP methods contained in the EAP Key Management
Framework
    [RFC5247] or its successor.  This includes the generation of the
MSK,
 EMSK, Peer-Id, Server-Id and Session-Id.  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.
 "

 > "  The tunnel method MUST meet the SHOULD and MUST requirements
 >    pertinent to EAP method contained in Section 3 of RFC 4962
 > [RFC4962].
 >    This includes: cryptographic algorithm independence; strong, fresh
 >    session keys; replay detection; keying material confidentiality
and
 >    integrity; confirm cipher suite selection; and uniquely
 > named keys."
 >
 > The key naming requirement is handled by generation of the
 > Session-Id, so it needn't be mentioned specifically.
 >
 > With respect to some of these issues, NIST 800-120 provides
 > more detailed and specific requirements.
 >

 Proposal to remove key naming from list

 > Section 4.1.2
 >
 > "   Several existing tunnel methods are already in widespread
 > usage: EAP-
 >    FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP."
 >
 > The definitive reference for the PEAP protocol is:
 > http://msdn.microsoft.com/en-us/library/cc238354(PROT.10).aspx
 >

 Propose resolution to update reference

 > Section 4.2.1.1.3
 >
 > "   A tunnel method MUST provide unidirectional authentication from
 >    authentication server to EAP peer or mutual authentication between
 >    authentication server and EAP peer."
 >
 > Is this really an or?  For example, would a tunnel method
 > that only supports undirectional authentication satisfy the
 > requirement?
 >

 It should be "and"

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/emu/trac/ticket/22>
emu <http://tools.ietf.org/wg/emu/>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 6 Aug 2009 23:57:27 +0300

[snip]
>  > that only supports undirectional authentication satisfy the
[YS] Why? This is discussing the "outer" method, which may indeed provide
only unidirectional auth.

Thanks,
	Yaron
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 6 Aug 2009 14:26:21 -0700

In section 3.7 we say:

"The tunnel method MUST be
   capable of providing client side authentication during tunnel
   establishment."

So the tunnel MUST be capable of proving mutual authentication.  Does
the text need modification?

Joe 

> -----Original Message-----
> From: Yaron Sheffer [mailto:[email-masked]] 
> Sent: Thursday, August 06, 2009 1:57 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: Issue #22: Collection of smaller issues
> 
> [snip]
> > 
> >  > Section 4.2.1.1.3
> >  >
> >  > Is this really an or?  For example, would a tunnel 
> method  > that 
> > only supports undirectional authentication satisfy the  > 
> requirement?
> >  >
> > 
> >  It should be "and"
> > 
> [YS] Why? This is discussing the "outer" method, which may 
> indeed provide only unidirectional auth.
> 
> Thanks,
> 	Yaron
> > --

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 7 Aug 2009 00:42:11 +0300

Yes, you are right.

	Yaron

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Friday, August 07, 2009 0:26
> To: Yaron Sheffer; [email-masked]