eap Mailing List: Re: [Issue 294] Rewrite of Security Considerations Section

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> Issue 294: Rewrite of the Security Considerations & Requirements Sections
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> Date first submitted: 3/31/05
> Reference:
> Document: KEY-05
> Comment type: T
> Priority: S
> Section: 6, 7
> Rationale/Explanation of issue
>
> The major rationale for creating the EAP Key Management Framework document
> in the first place was to provide a security analysis of EAP usage in
> existing applications.
>
> However, while Section 6.1 defines terminology and Section 6.2 provides a
> Threat Model based on the Housley Criteria, the document never actually
> provides a security analysis of existing EAP Usage.
>
> For example, does EAP when used with PPP & RADIUS satisfy the security
> requirements?  How about when used with 802.11i, and Diameter EAP?  The
> document does not provide any guidance.  It is no wonder that the reader
> is left to wonder what the point of the document is.
>
> Section 7 consists of requirements on EAP methods, AAA
> protocols, Secure Association Protocols and Ciphersuites that is in no way
> tied back to the security requirements and threat model.  One is left to
> wonder whether these "requirements" were developed out of thin air, or
> whether there is any basis/justification for them.
>
> The recommended fix is to rewrite Section 6 to analyze the following EAP
> usage scenarios according to the security requirements:
>
> 1. EAP over PPP [RFC3748]
>   a. With RADIUS ([RFC3579] + [RFC2548])
>   b. With Diameter-EAP & Redirect
> 2. EAP over 802.1X
>   a. With RADIUS ([RFC3579] + [RFC2548])
>   b. With Diameter-EAP & Redirect
> 3. EAP over 802.11i
>   a. With RADIUS ([RFC3579] + [RFC2548])
>   b. With Diameter-EAP & Redirect
>
> Then, based on the outcome of this Section 6 analysis, we can decide which
> of the "requirements" are actually required.
>  

Agreed.

--Jari