Subject: [eap] Issue 174: Mandatory to Implement

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Sep 2003 17:34:54 -0700 (PDT)

Issue 174: Mandatory to Implement
Submitter name: Dorothy Stanley
Submitter email address: [email-masked]
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?

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Sep 2003 08:15:29 -0700

> Document: EAP-05 Comment type: T
> Priority: S
> Section: 5, 5.4

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?

> "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."             
> 
> 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
> [email-masked] 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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Sep 2003 09:41:37 -0700 (PDT)

> in the same boat.  Is this really desirable?

Since EAP MD5-Challenge is already illegal for use with IEEE 802.11i, they
are already in this predicament, no?

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Sep 2003 10:23:33 -0700

Bernard Aboba <mailto:[email-masked]> writes:

>> 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?
> 
> Since EAP MD5-Challenge is already illegal for use with IEEE 802.11i,
> they are already in this predicament, no? 

Is the use of EAP MD5-Challenge actually illegal or just ill-advised?

~gwz

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Sep 2003 10:28:55 -0700 (PDT)

> Is the use of EAP MD5-Challenge actually illegal or just ill-advised?

I believe that it's illegal -- mutual authentication is required.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Sep 2003 11:23:21 -0700

> I believe that it's illegal -- mutual authentication is required.

That's too bad.  Is there any reason we need to get ourselves in the
same predicament (other than reducing code size for 802.11 implementers?

~gwz