From salga@bell-labs.com Wed May 1 22:05:58 2002 From: salga@bell-labs.com (Luca Salgarelli) Date: 01 May 2002 17:05:58 -0400 Subject: [eap] Status of the proposed EAP WG? Message-ID: <1020287158.10900.17.camel@valjean> Hello Bernard. After the EAP BOF in Minneapolis not much has been said about what happens next. Given that the results of the BOF were not that clear, at least to me, in terms of what we agreed on for the charter, does anybody have any news on what is going to happen next? Is there going to be an EAP BOF-2 in Yokohama? Thanks Luca From aboba@internaut.com Thu May 2 23:00:02 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 May 2002 15:00:02 -0700 (PDT) Subject: [eap] EAP Status Update In-Reply-To: <1020287158.10900.17.camel@valjean> Message-ID: EAP BOF REPORT The minutes of the EAP BOF at IETF 53 have been posted at: http://www.drizzle.com/~aboba/EAP/eapbof.txt http://www.drizzle.com/~aboba/EAP/presentations.zip As noted in the BOF minutes, there was widespread agreement that an EAP WG should be formed. Discussion relating to the strawman charter (see below) occurred both during the EAP BOF, and to some extent, afterwards, as individuals have posted their views on the charter to the ADs. We can continue that discussion on this list, so as to get closer to agreement on it. PROGRESS REPORT ON RFC 2284bis and RFC 2869bis The latest drafts are available here: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-04.txt http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-01.txt http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt Current issues with RFC 2284bis are tracked here: http://www.drizzle.com/~aboba/EAP/eapissues.html In terms of progress on RFC 2284bis and RFC 2869bis, we seem to be moving along at a reasonable pace. As noted in the RFC 2284bis issues list, the open issues include: Issue #3 Pending EAP needs a formal state machine Issue #7 Pending Ability to authenticate with multiple methods one after another not specified Issue #10 Pending No support for acknowledged Success or Failure Issue #13 Pending Identifier usage not specified Issue #14 Pending EAP transport behavior not specified Issue #18 Pending Identifier behavior details The issue that needs the most work here is the EAP state machine, which is to be submitted as an IETF Internet-Draft by Bryan Payne of University of Maryland. Open issues with RFC 2869bis include: Issue #15 Pending NASREQ Key Distribution insecure Issue #16 Pending EAP corner conditions Issue #19 No Disc. User-Name in EAP/RADIUS Issue #20 No Disc. Reply-Message attribute in Access-Accept or Access-Reject The biggest issue with RFC 2869bis revolves around key distribution and the associated attributes and security model. Analysis is ongoing in this area by Jesse Walker of Intel and Russ Housley of RSA. For details, see: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt CHARTER UPDATE The strawman EAP WG charter is enclosed below. This formed the basis for the discussion at the IETF 53 EAP BOF. During the BOF and subsequent discussion, the comments on the charter fell into several categories: a. Strawman as "minimum set of work items". During the EAP BOF and subsequently, there wasn't much discussion about removing items from the strawman charter. So we seem to have agreement that the strawman represents a minimum set of work items that need to be completed. The discussion therefore centers around what needs to be added. b. Venue. We had a number of comments relating to the RFC 2284bis (PPPEXT WG) and RFC 2869bis (AAA WG) work items. Since these items are already chartered within existing WGs, and seem to be moving forward, it was suggested that they be allowed to complete within the existing WGs, rather than moving them to an EAP WG. This might also better allow the EAP WG to take on additional work items beyond what is in the strawman charter. On the other hand, there were also comments that the RFC 2284bis effort might be integrated with other EAP Work if it were in an EAP WG. c. Need for key management work. There seemed to be agreement that the work on key management was particularly important, though the full extent of the required work is not completely defined. d. Need for review of methods. Quite a few EAP methods were covered in the BOF, and there seemed to be a high level of interest in review/discussion of methods. In general, there seemed to be consensus around the idea that the EAP WG would review methods in some form. However, the relationship of method review to the charter is not as clear. For example, should the EAP WG standardize methods? If so, what kinds of methods, how many and for what purposes? A variety of opinions were expressed on this subject; there was a suggestion that perhaps the usage scenarios could be characterized, and methods could be standardized within the categories. ------------------------------------------------------------------------------ Strawman charter proposal EAP Working Group (EAP) Chair(s): This space for rent Area Director(s): Thomas Narten Erik Nordmark Security Advisor: Bill Arbaugh Mailing Lists: General discussion: eap@frascone.com To subscribe: send a message with "subscribe" in the subject to eap-request@frascone.com Archive: http://mail.frascone.com/pipermail/eap/ The EAP working group will restrict itself to the following short-term work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations. 2. Threat model and security considerations. 3. EAP state machine. 4. Clarification and documentation of EAP keying issues 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. Type space extension to support an expanded Type space. 8. EAP applicability statement 9. Update of RADIUS/EAP section of RFC 2869 Goals and Milestones Jun 02 IANA considerations draft to RFC Editor. Jun 02 EAP type extension section for RFC 2284bis. Jun 02 EAP Security considerations section for RFC 2284bis. Jun 02 EAP state machine section for RFC 2284bis. Sep 02 RFC 2869bis published as Proposed Standard RFC. Sep 02 RFC 2284bis published as Proposed Standard RFC. Sep 02 EAP applicability statement published as Informational RFC. Sep 02 EAP keying issues doc published as Informational RFC. On 1 May 2002, Luca Salgarelli wrote: > Hello Bernard. > > After the EAP BOF in Minneapolis not much has been said about what > happens next. > > Given that the results of the BOF were not that clear, at least to me, > in terms of what we agreed on for the charter, does anybody have any > news on what is going to happen next? Is there going to be an EAP BOF-2 > in Yokohama? > > Thanks > Luca > > > From aboba@internaut.com Fri May 3 19:37:27 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 May 2002 11:37:27 -0700 (PDT) Subject: [eap] Issue #21: Editorial issues in RFC 2284bis-04 Message-ID: Issue 21: Editorial issues with RFC 2284bis-04 Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2869bis-04 Comment type: E Priority: S Section: 2, 2.1, 4.2, 9.1, 9.8 Rationale/Explanation of issue: Section 2, page 5 says under "Advantages": The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one. Certain devices (e.g. a NAS, switch or access point) do not necessarily have to understand each request type and may be able to simply act as a pass-through agent for a "back-end" server on a host. The device only need look for the success/failure code to terminate the authentication phase. A third advantage of EAP might be noted. The separation of authentication from the point of access simplifies credentials management and policy decision making. Section 2, page 5 also says under "Disadvantage": For use in PPP, EAP does require the addition of a new authentication type to PPP LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP. Similarly, switch or access point implementations need to support [IEEE8021X] in order to use EAP. A second disadvantage might be noted. The separation of authentication from the point of access complicates the security analysis and, if it is needed, key distribution. This dichotomy between better management and more fragile security is a property of all schemes that separate the policy decision point from the policy enforcement point, and it would be worthwhile for the text to document it, so that the tradeoffs facing us are clear. Section 2.1 page 6, point (a) has a minor grammar error, "receives a EAP response" instead of "an EAP response." I'd love to produce a document someday that has only a single grammatical error. Section 4.2 page 12 has an implementation note saying Implementation Note: Because the Success and Failure packets are not acknowledged, the Authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the Authenticator, and if they are lost, the Peer will timeout and retry the authentication. Sorry for being so obtuse, but I can't fathom what this is trying to tell me. I find this text confusing, since the pages preceeding it carefully explain that EAP does not permit the Peer to retry anything, but only to respond to the EAP Authenticator. The only conclusion I can draw is it constitutes a reference to some unidentified entity outside of EAP, thus coupling the correct behavior of EAP to the containing environment behaving correctly. This sort of coupling always deserves examination, especially within a scheme allegedly related to authentication. If that is the correct conclusion, this points to a design problem within EAP that we will want to think about more in the long term, as it could imply that misbehaving environments (e.g., those partially controlled by attackers) might be able to subvert the protocol, regardless of the quality of the concrete authentication method. If my surmise is instead incorrect, then please help me understand the intended meaning of the language. Section 9.1 page 22 spells "omitted" as "ommitted." The fifth paragraph of Section 9.8 says: the session key negotiated between the Peer and EAP server will need to be transmitted to the Authenticator. The EAP method might very well have to transmit the key the Peer as well, so this should be noted. From gwz@cisco.com Fri May 3 23:19:55 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 03 May 2002 15:19:55 -0700 Subject: [eap] questions/comments on draft-walker-aaa-key-distribution-00.txt Message-ID: <4.3.2.7.2.20020503132700.00b8a700@franklin.cisco.com> Editorial nit: the first page headers seem misaligned (in my copy). Section 2, paragraph 2 says "The purpose of NASREQ key distribution is to securely establish a session key between the NAS and the NAS client." While this true in a general way, a more precise characterization might be that the purpose is to securely _inform_ the NAS of session keys which have been derived without its knowledge, possibly as a side-effect of a successful EAP authentication. Section 2, paragraph 3 seems to come to some reasonable conclusions, but for the wrong reasons. For example, it says: "[NASREQ] allows the AAA server to distribute a key to the NAS client using EAP, but does not specify how this is accomplished." Actually, this is a mistake in the NASREQ draft: instead of saying (in Section 2.1.2) "The keys MAY be distributed to the user as part of an EAP authentication exchange." it should actually say nothing at all, or maybe something like "The means by which the user obtains the keys is outside the scope of this document.", because it is. Paragraph 3 continues: "EAP fails to specify mechanisms. As a result, all mechanisms assume that the AAA server and the NAS client already share a key that may be used directly to protect the link between the NAS and the NAS client, and so it is unnecessary to distribute any key to the NAS client. Since no specified instances of EAP key distribution to the NAS client exist, the implicit assumption has to be that such mechanisms are unimportant...". Actually, the is another assumption possible, though not particularly implicit: that EAP types which offer key derivation will provide it in a fashion that makes distribution to the NAS client unnecessary. In fact, that's just what has happened: virtually all EAP types that provide for key derivation do so in a such a way that only the EAP server (not identical to the AAA server as is mistakenly implied in your draft) and the EAP client can have knowledge of the keys. Continuing: "and will not be deployed as part of the AAA architecture. That is, the lack of any defined EAP key distribution mechanism, and the further lack of any work on such a mechanism, implies that the AAA Working Group implicitly assumes it is only necessary to distribute the key to the NAS." A very good assumption. The biggest problem with this draft, however, is the apparent misunderstanding of the parties involved and the interactions between them, a mistake I alluded to above: much of the remainder of the draft builds upon the supposed three-party nature of the conversations when actually there are four logical parties involved, one of which (the AAA server) is nonexistent as far as the NAS client is concerned. The NAS client never communicates with the AAA server, the NAS may or may not communicate directly with the EAP server (probably not, if a AAA server is involved). Having said all this, however, there is a lot of good thought in the draft, though it may be more pertinent to the design of special-purpose 802.11 EAP types than to the re-design of AAA key distribution. From aboba@internaut.com Wed May 8 01:49:27 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 May 2002 17:49:27 -0700 (PDT) Subject: [eap] Issue 22: Issues with mandatory to implement method Message-ID: Issue 22: Issues with mandatory to implement method Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2869bis-04 Comment type: T Priority: S Section: 5.4 Rationale/Explanation of issue: Here is an example where we should note that using EAP unchanged can be a more of a danger than a help in some new environments. Section 5.4 says of MD5-Challenge on page 16: All EAP implementations MUST support the MD5-Challenge mechanism. While this might make sense for legacy dial-in environments (does it really? how many times have you seen someone cable their PC modem to their cell-phone in an airport?), it does not for wireless LANs in particular, where MD5-Challenge is simply a credentials publication mechanism when a password is used, and always subject to man-in-the-middle attacks, even if a key rather than a password is somehow used. These problems should be explicitly noted, and we need to develop wide understanding of the problem. From aboba@internaut.com Wed May 8 01:50:54 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 May 2002 17:50:54 -0700 (PDT) Subject: [eap] Issue 23: Contents of Identity Request Payload Message-ID: Issue 23: Contents of Identity Request Payload Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2869bis-04 Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: Section 5.1 page 13 describes the Identity Type thusly: The Identity Type is used to query the identity of the peer. Generally, the Authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity). This language is good as far as it goes, but I wonder if more formal rules should be specified to enable the more mobile enviroments where EAP is being applied? What I have in mind is that it is likely that many (most?) users/devices will have different sets of credentials for many of the security domains they visit. Each of these credentials will assign to the user/device a different artificial and arbitrary "identity". In the wireless roaming case, it is likely that a user will sometimes cross domain boundaries without even knowing it, so the commonly cited industry goal of "seamless" roaming would imply that the Identity Request from the Authenticator should provide some hint as to which "identity" it is expecting, i.e., which domain is in use. While the cited language above does not preclude this, it does not specify any interoperable way of accomplishing this goal. The obvious suggestion would be to insert the domain name portion of the NAI of the Authenticator in some standard way into the Identity Request. The Peer could parse and then attempt to map this to the credentials it should present to this particular Authenticator. From aboba@internaut.com Wed May 8 01:58:47 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 May 2002 17:58:47 -0700 (PDT) Subject: [eap] Issue 24: EAP and ciphersuite negotiation Message-ID: Issue 24: EAP and ciphersuite negotiation Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2869bis-04 Comment type: T Priority: S Section: 9.8 Rationale/Explanation of issue: The seventh paragraph of Section 9.8 says: However, EAP methods deriving keys SHOULD provide keying material that can be used with any ciphersuite, since EAP methods cannot be assumed to provide protected ciphersuite negotiation and the negotiated ciphersuite may not be known beforehand. I think what this is really trying to say is that if EAP distributes any keys, the distributed keys should be master keys, used only for further key derivation, independent of the cipher suite, because it is unreasonable for the Authenticator to know the details for deriving keys for every cipher suite. This is a reasonable requirement. However, this is not what the text says. It says that we shouldn't use EAP for cipher suite negotiation. This position undercuts the Authenticator's role as the policy decision point, i.e., it undercuts EAP's own rationale. An architecture using EAP could include cipher suite registration with the Authenticator. If this were done, there is no reason why it an EAP method cannot negotiate the cipher suites to be used with a key, and if it does, why the Authenticator cannot specify the "best" cipher suite to use on the basis of the capabilities of the communicating peers that best match each other and local policy; in fact, this seems like a desirable property, to allow the Authenticator to deny service when an acceptable cipher suite conforming to policy cannot be found. The Authenticator could delegate this task the NAS, but again this complicates the security analysis and increases the total number of assumptions needed about the system. From aboba@internaut.com Wed May 8 02:06:01 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 May 2002 18:06:01 -0700 (PDT) Subject: [eap] Issue 25: Spoofing and duplicate detection Message-ID: Issue 25: Spoofing and duplicate detection Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2869bis-04 Comment type: T Priority: S Section: 9.3 Rationale/Explanation of issue: Section 9.3 page 23, point 1 says: Silent discard. Since only a single EAP Request can be in progress between an Authenticator and a Peer at a given time, if a Peer receives a new Request before sending a Response, the new Request can be silently discarded. This increases resilience against spoofed Requests. Similarly, an Authenticator can silently discard Responses with Identifiers that do not correspond to the Identifier included in the last Request, or that represent duplicate Responses. This advice seems effective only if both the Authenticator and the Peer respond significantly more rapidly than does the active attacker, or their responses are delivered more expeditiously than the attacker's, i.e., you can't depend on it. The Success and Negotiate messages in particular require their own protection. I suggest noting this method does not work except in very constrained environments because of the race conditions cited. From aboba@internaut.com Mon May 13 15:13:21 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 May 2002 07:13:21 -0700 (PDT) Subject: [eap] Extensible Authentication Protocol State Machine (fwd) Message-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Authentication Protocol State Machine Author(s) : B. Payne, N. Petroni Filename : draft-payne-eap-sm-00.txt Pages : 11 Date : 09-May-02 The specification for the Extensible Authentication Protocol (EAP) [2] omits a state machine description. This omission has led to ambiguity in the specification and potential security problems in EAP implementations. This document outlines a state machine to be integrated into the next revision of the EAP RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt From youskang@etri.re.kr Mon May 20 02:46:54 2002 From: youskang@etri.re.kr (youskang@etri.re.kr) Date: Mon, 20 May 2002 10:46:54 +0900 Subject: [eap] [Question] Is there an EAP method type for EAPOL Key descriptor? Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08926E24@cms1.etri.re.kr> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FFA0.384A7AE0 Content-Type: text/plain; charset="euc-kr" Hello. My name is Yousung Kang. I'm working for ETRI(Electronics and Telecommunication Research Institute) in S.Korea. I'm poor in English, thus execuse me for my raw expressions. I have some questions for EAP Method types. I read IEEE 802.1x of version approved 14 June 2001. In 8.5.5 Authenticator Key Transmit state machine, txKey(x) is explained 'An EAPOL frame of type EAP-Packet, containing an EAPOL Key packet is transmitted to the Supplicant. The Identifier field of the EAP packet carries the value of x, the argument to the procedure.'. Let me know how EAP-Packet(EAP-Request or EAP-Response) indicates EAPOL Key packet. Is there a method type for indication EAPOL Key packet? If not, must I use Vendor-specific type? If there is a list for EAP method types, why don't you send me the list. One more question, Are EAPOL Key packet and Key descriptor of Figure 7-3 in 802.1x spec same? Thank you for your kind answer, in advance. Best Regards. Yousung Kang. ------_=_NextPart_001_01C1FFA0.384A7AE0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [Question] Is there an EAP method type for EAPOL Key = descriptor?

Hello.

My name is Yousung Kang. I'm working for = ETRI(Electronics and Telecommunication Research Institute) in S.Korea. = I'm poor in English, thus execuse me for my raw expressions.

I have some questions for EAP Method types.

I read IEEE 802.1x of version approved 14 June 2001. = In 8.5.5 Authenticator Key Transmit state machine, txKey(x) is = explained 'An EAPOL frame of type EAP-Packet, containing an EAPOL Key = packet is transmitted to the Supplicant. The Identifier field of the = EAP packet carries the value of x, the argument to the = procedure.'. 

Let me know how EAP-Packet(EAP-Request or = EAP-Response) indicates EAPOL Key packet. Is there a method type for = indication EAPOL Key packet? If not, must I use Vendor-specific = type?

If there is a list for EAP method types, why don't = you send me the list.

One more question, Are EAPOL Key packet and Key = descriptor of Figure 7-3 in 802.1x spec same?

Thank you for your kind answer, in advance.

Best Regards.
Yousung Kang.


------_=_NextPart_001_01C1FFA0.384A7AE0-- From aboba@internaut.com Mon May 20 21:04:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 20 May 2002 13:04:42 -0700 (PDT) Subject: [eap] Re: EAP method of type EAPOL-Key In-Reply-To: <200205201613.g4KGDpx23381@internaut.com> Message-ID: EAP (RFC 2284) does not define a packet of type EAPOL-Key. Rather, this is an IEEE 802.1X packet. The format of the RC4 key descriptor is not fully defined within IEEE 802.1X however, so this has been added to: http://www.drizzle.com/~aboba/IEEE/draft-congdon-radius-8021x-19.txt The reason that the original EAPOL-Key packet was not defined in EAP was that originally this was only to deal with 802.11-specific keying phenomena (e.g. the default key). However, since then the purpose of this packet has expanded. In the latest 802.11 Tgi draft, it is also used for generic functions such as nonce exchanges, and key synchronization. Adding this functionality to IEEE 802.1X instead of to EAP has some implications that probably need to be thought through. For example, including a nonce exchange outside of EAP means that an EAP method cannot depend on such an exchange being available. Thus, it might choose to do its own exchange, in which case the 802.1X nonce exchange might be considered duplicative. Similarly, key change synchronization seems like a general purpose facility; isn't this something that other media might need? On the other hand, the key exchanges that have been proposed do have some 802.11-specific elements to them, so the case is not entirely clearcut. I ask because one of the major priniciples of EAP is the creation of authentication methods that can work on any media. Adding facilities outside of EAP (such as EAPOL-Start) have tended to bite us either because the facilities lie outside the protective envelope of proposals such as TTLS or PEAP, or because those facilities end up having to be duplicated on other media. So it's worth asking where this functionality should go, and why. From aboba@internaut.com Sat May 25 16:53:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 25 May 2002 08:53:31 -0700 (PDT) Subject: [eap] EAP WG Charter strawman Message-ID: Discussion continues on the formation of an EAP WG, and the possible charter for such a WG. Find below a strawman charter for an EAP WG. Comments welcome. ----------------------------------------------------------------- EAP Working Group (EAP) Chair(s): This space for rent Area Director(s): Thomas Narten Erik Nordmark Security Advisors: Bill Arbaugh Mailing Lists: General discussion: eap@frascone.com To subscribe: send a message with "subscribe" in the subject to eap-request@frascone.com Archive: http://mail.frascone.com/pipermail/eap/ The EAP working group will restrict itself to the following work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. EAP operational model. 3. EAP Threat model and security considerations. 4. EAP state machine. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. Type space extension to support an expanded Type space. 8. Clarification and documentation of EAP keying framework. 9. EAP method requirements. The EAP WG is not currently chartered to review or standardize EAP methods. However, when these work items are completed, the WG may be rechartered, or a new WG may be formed to evaluate proposed methods against the EAP method requirements to be developed by this WG. Goals and Milestones Dec 02 RFC 2284bis published as Proposed Standard RFC. Jun 03 EAP keying framework published as Informational RFC. Jun 03 EAP method requirements published as Informational RFC. From gwz@cisco.com Sat May 25 19:45:10 2002 From: gwz@cisco.com (Glen Zorn) Date: Sat, 25 May 2002 11:45:10 -0700 Subject: [eap] EAP WG Charter strawman In-Reply-To: Message-ID: <4.3.2.7.2.20020525112542.02179eb8@franklin.cisco.com> At 08:53 AM 5/25/2002 -0700, Bernard Aboba wrote: >Discussion continues on the formation of an EAP WG, and the >possible charter for such a WG. > >Find below a strawman charter for an EAP WG. Comments welcome. >----------------------------------------------------------------- >EAP Working Group (EAP) > >Chair(s): > This space for rent > >Area Director(s): > Thomas Narten > Erik Nordmark > >Security Advisors: > Bill Arbaugh > >Mailing Lists: > >General discussion: eap@frascone.com >To subscribe: send a message with "subscribe" in the subject to > eap-request@frascone.com >Archive: http://mail.frascone.com/pipermail/eap/ > > >The EAP working group will restrict itself to the following work items in >order to fully document and improve the interoperability of >the existing EAP protocol: > >1. IANA considerations for EAP. >2. EAP operational model. >3. EAP Threat model and security considerations. >4. EAP state machine. >5. Documentation of interaction between EAP and other layers. >6. Resolution of interoperability issues. >7. Type space extension to support an expanded Type space. >8. Clarification and documentation of EAP keying framework. What is this? Does it exist? > >9. EAP method requirements. This seems extremely vague to me. Are we going to define method requirements for every possible environment (PPP, 3G cellular, WLAN)? With the possible exception of the first (which probably be done in the pppext WG anyway), that seems extraordinarily presumptuous. >The EAP WG is not currently chartered to review or standardize EAP >methods. Since this is the main request of 802.11i (as I understand it the major driver behind the creation of this proposed WG), I can't see how this is very helpful. Maybe there is a need for yet another BOF? >However, when these work items are completed, the WG may be >rechartered, or a new WG may be formed to evaluate proposed methods >against the EAP method requirements to be developed by this WG. See above. >Goals and Milestones > >Dec 02 RFC 2284bis published as Proposed Standard RFC. >Jun 03 EAP keying framework published as Informational RFC. >Jun 03 EAP method requirements published as Informational RFC. > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Sun May 26 17:58:05 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 26 May 2002 09:58:05 -0700 (PDT) Subject: [eap] Re: EAP WG Charter strawman In-Reply-To: <200205261612.g4QGCxx21323@internaut.com> Message-ID: > >8. Clarification and documentation of EAP keying framework. > > What is this? Does it exist? Here are some drafts that relate to this issue: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt > >9. EAP method requirements. > > This seems extremely vague to me. Are we going to define method > requirements for every possible environment (PPP, 3G cellular, WLAN)? With > the possible exception of the first (which probably be done in the pppext > WG anyway), that seems extraordinarily presumptuous. The intent is for EAP WG to produce a document to set the stage for a rechartered EAP WG (or a new WG, EAPEXT) to review methods. The following questions will arise in such a review effort: a. On what basis are the methods reviewed? What do we look for? b. What are the requirements for methods that are standardized? Since there has already been some input from 802.11 (who have sent a letter to IESG) and 3G (who also made requests) relating to EAP methods, this might consist of writing up the requirements we've already gotten from them, and perhaps elaborating on them a bit. I would agree that it is probably not appropriate for an IETF WG to decide what is required for 802.11 or 3G by itself. > >The EAP WG is not currently chartered to review or standardize EAP > >methods. > > Since this is the main request of 802.11i (as I understand it the major > driver behind the creation of this proposed WG), I can't see how this is > very helpful. Maybe there is a need for yet another BOF? The IESG appears willing to consider chartering an EAP WG based on the results of the last BOF. However, before adding a charter item for method review, there is the need to articulate the basis for that review and the goals that are going to be accomplished by it. The EAP IANA considerations describe the process for assignment of type codes, including review requirements. So that establishes the mechanism by which the review occurs. However, there is also the need for some guidelines in the review process; that is what item #9 is about. If the requests of 802.11i were written up in a draft, that would help start the discussion. Out of curiosity, what are you advocating needs to be added to the charter? a. Standardization of a single method that fulfills the requirements articulated by 802.11i? b. Standarization of any method meeting those requirements? c. Review of methods submitted for type code allocation, for correctness in EAP usage? d. Security review of methods submitted for type code allocation? From aboba@internaut.com Thu May 30 02:25:07 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 29 May 2002 18:25:07 -0700 (PDT) Subject: [eap] Some useful links Message-ID: I've had some questions lately on where people can get information relating to EAP. Here are some useful links: IETF links EAP BOF minutes http://www.drizzle.com/~aboba/EAP/eapbof.txt EAP BOF presentations http://www.drizzle.com/~aboba/EAP/presentations.zip EAP mail archive http://mail.frascone.com/pipermail/eap/ RFC 2284bis http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-04.txt EAP state machine proposal http://search.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt RADIUS/EAP update http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-02.txt EAP issues website http://www.drizzle.com/~aboba/EAP/eapissues.html IEEE 802 links 802.11 website http://www.ieee802.org/11/ Unofficial 802.11 security website http://www.drizzle.com/~aboba/IEEE/ IEEE 802.11 Liason letter http://www.ietf.org/IESG/LIAISON/ieee802.11.txt IEEE 802.1X pre-authentication paper http://www.drizzle.com/~aboba/IEEE/11-02-TBDr0-I-Pre-Authentication.doc IEEE 802.1aa website http://www.ieee802.org/1/pages/802.1aa.html 802.1X/RADIUS usage guidelines http://www.drizzle.com/~aboba/IEEE/draft-congdon-radius-8021x-20.txt