eap Mailing List: Issue 255: IESG DISCUSS comments on Authorization

[Bernard Aboba (aboba]

Issue 255: IESG DISCUSS comments on Authorization
Submitter name: Allison Mankin
Submitter email address: mankin [at] psg.com
Date first submitted: 6/10/04
Reference:
Document: REQ-03
Comment type: T
Priority: S
Section: 3
Rationale/Explanation of issue:

I think this is a very reasonable document, but I see one glitch, a
gap between the mandatory requirements and the Security Considerations.

In the mandatory requirements (2.2[3]), the requirement is only for
mutual authentication support, but the Security Considerations state
that authorization as well as mutual authentication is required:

     EAP peer and authenticator authorization must be performed.  Issues
     relating to authorization are discussed in [RFC3748] Section 7.15,
     and [RFC3579] Section 4.3.7.

I haven't heard any discussions of authorization by 802.11i, so I have
no knowledge of whether authorization is feasible, out-of-scope, etc.
But the section sticks out, and it makes relationship of the Security
Considerations to the rest of the document unclear.  Does the Security
Considerations section provide further requirements for IEEE 802.11i?
If it doesn't, then there needs to be a sentence noting that the
section is there to provide advisory information.

I don't know if it's possible to give an RFC Editor Note to a document
that comes to the IETF approved by IEEE, but my suggestion is a sentence
introducing the Security Considerations clarifying its role.

I'll change this Discuss to a comment if the AD and Russ (as the
author whose Security Considerations are quoted) believe that there is
no benefit to the community in making a change to the document.

Proposed change:

Replace the Authorization paragraphs of Section 3 with the following:

"Authorization
     Requirement: "EAP peer and authenticator authorization must be
     performed."

     Authorization issues are discussed in [RFC3748] Section 1.2, and
     Section 7.16.  Authentication, Authorization and Accounting (AAA)
     protocols such as RADIUS [RFC2865][RFC3579] may be used to enable
     authorization of EAP peers by a central authority.  AAA
     authorization issues are discussed in [RFC3579] Section 2.6.3 as
     well as in Section 4.3.7."

Also, replace the Key binding paragraphs of Section 3 with the following:

"Key binding
     Requirement: "The key must be bound to the appropriate context."

     This issue is addressed in optional requirement [10] in Section
     2.4.  Channel binding is also discussed in Section 7.15 of
     [RFC3748], and Section 4.3.7 of [RFC3579]."

Proposed Resolution: Accept