eap Mailing List: RE: Issue 174: Mandatory to Implement

[Glen Zorn (gwz]

> Issue 174: Mandatory to Implement
> Submitter name: Dorothy Stanley
> Submitter email address: dstanley [at] agere.com
> Date first submitted: 9/11/2003
> Reference:
>
http://mail.frascone.com/pipermail/public/eap/2003-September/001657.html
> Document: EAP-05 Comment type: T
> Priority: S
> Section: 5, 5.4
> Rationale/Explanation of issue:
> 
> It seems wasteful to require an EAP peer to implement the
> EAP MD5-Challenge method, even in situations (such as
> IEEE 802.11i) where mutual authentication is required. Can
> we relax this requirement?

The obvious problem is that this leaves EAP as essentially an empty
framework, removing the basis for any but purely formal
interoperability.  In addition, since AFAIK 802.11i doesn't specify any
EAP method as mandatory (relying instead upon RFC 2284), it leaves them
in the same boat.  Is this really desirable?

> 
> In Section 5, change:
> 
> "All EAP implementations MUST support Types 1-4, which are defined in
> this document, and SHOULD support Type 254. Implementations MAY
> support other Types defined here or in future RFCs."  
> 
> To:
> 
> "All EAP server implementations MUST support Types 1-4, which are
> defined in this document, and SHOULD support Type 254. EAP peer
> implementations which support physically secure lower layers MUST
> support types 1-4, and SHOULD support Type 254. EAP Peer
> implementations which only support physically insecure lower layers
> requiring mutual authentication MAY NOT support Type 4 (EAP
> MD5-Challenge). An authenticator that supports only pass-through MUST
> allow communication with a backend authentication server that is
> capable of supporting Type 4 (MD5-Challenge), although the
> implementation need not support MD5-Challenge itself. However, if the
> EAP authenticator can be configured to authenticate peers locally
> (e.g., not operate in pass-through), then it MUST support Type 4
> (MD5-Challenge). Implementations MAY support other Types defined here
> or in future RFCs."             
> 
> Delete the following from Section 5.4:
> 
> "EAP peer and EAP server implementations MUST support the
> MD5-Challenge mechanism.  An authenticator that supports only
> pass-through MUST allow communication with a backend authentication
> server that is capable of supporting MD5-Challenge, although the EAP
> authenticator implementation need not support MD5-Challenge itself. 
> However, if the EAP authenticator can be configured to authenticate
> peers locally (e.g., not operate in pass-through), then the
> requirement for support of the MD5-Challenge mechanism applies."
> _______________________________________________ eap mailing list
> eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap      

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire