#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/>
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu