From porcher@funk.com Wed Apr 2 19:49:47 2003 From: porcher@funk.com (Tom Porcher) Date: Wed, 02 Apr 2003 14:49:47 -0500 Subject: [eap] EAP SIM clients or servers for interoperability testing? Message-ID: <3E8B3EDB.8000400@funk.com> We are developing EAP SIM client and server implementations and would like to be able to test with other implementations. Is there anyone who has an EAP SIM client or server available for interoperability testing? Is there going to be an EAP SIM bakeoff someday? Thanks! --Tom Porcher -- Tom Porcher | porcher@funk.com voice: 978.371.3980 x108 Consulting Engineer | http://www.funk.com fax: 978.371.3990 Funk Software, Inc. | Concord, Massachusetts, USA, Earth From jari.arkko@piuha.net Thu Apr 3 14:46:14 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 03 Apr 2003 17:46:14 +0300 Subject: [eap] state machine design team minutes, march 26th Message-ID: <3E8C4936.6050101@piuha.net> Minutes of the EAP State Machine Design Team Date: Wednesday, March 26, 2003 Time: 8 AM PST Present: Nick Petroni, Paul Congdon, Henrik Levkowetz, Jari Arkko, Bob Moskowitz, John Vollbrecht, Bernard Aboba, Joe Salowey, Yoshihiro Ohba. 1. Summary of Agreements (a) There are two levels of "strictness". One level is where the method disallows everything else except notifications while its still running. This level is called "strict". The other level is where the method disallows everything else, including notifications. This level is called "stricter". (b) All methods MUST be "strict" in RFC 2284bis. (c) Methods MAY be "stricter". This should be defined in the method specification. (d) Peers MUST NOT allow authenticators to switch to a new method in the middle. Need to ask the mailing list whether this rule creates any interoperability problems. (e) Methods MAY silently discard messages. (f) AAA server authenticators MUST check for Type field, and silently discard messages with the incorrect value in it. (g) Passthrough authenticators MUST check for Code, Identifier, and Length fields, and silently discard messages with the incorrect value in them. (h) Possible Type field check in passthrough authenticators is TBD, but one proposal is to say that they shall not look at this field. 2. Detailed Discussion o Strict mode The possible actions related to the use of the strict mode are silently discarding messages or nakking them. John Vollbrecht recommends that we do a silent discard. Joe Salowey wants that if we know thart a certain existing methods behaves in a specific way in this regard, we should document it. Bernard Aboba responds thatr we should distinguish what people are doing now (what the draft documents) and what people might do in the future. Bernard Aboba also notes that the strict interpretation was the consensus in the WG meeting in San Francisco. the question is whether it is the state machine or the method. John Vollbrecht: some of it could be done by method, some by mux. Jari Arkko: It is not a question of who does it. It is a question of whether to do it always or just sometimes. Joe Salowey: That's right. Bernard Aboba: PEAP has a very strict mode, does not even accept notifications. John Vollbrecht: But are notifications delivered to methods? Bernard: No, the method just asks the mux to install a filter that prevents notifications from being processed. John: It could also ask to allow everything, just this method, or not even notifs. Bernard Aboba: Another way to would be to say: SHOULD be strict except for Notificationss. Methods could be even stricter and not allow notifications at all, or possibly not allow identity requery. John Vollbrecht: Are there two states for methods? Jari Arkko: I think its more like a variable. Bernard: Methods can set a variable that makes it stricter, dumping id requeries and notifs. Its simpler. John Vollbrecht: You still have to know you are within the method state, that is the hard part. Jari Arkko: Strict is a SHOULD, stricter is a MAY. John Vollbrecth: i think we prohibited identity requeries. Bernard Aboba: That is ok with me. John Vollbrecht: The only thing you can do within a method is notification. Bernard: Ok, that makes sense. John Vollbrecht: I think we agree that all methods are strict (a SHOULD) and only thing that can come within this is notification. Some methods MAY prevent even this. John Vollbrecht: The next question is: do we allow authenticators to switch a method. I think its a non-question, if everything is strict. Bernard Aboba: I think it becomes a MUST NOT. Jari Arkko: But how come we have SHOULD for strict and MUST NOT for switch? Bernard Aboba: Maybe it should be a SHOULD for both. Jari Arkko: What is the reason that we can't say MUST and MUST NOT? John Vollbrecht: There may be implementations that do this. joe: the question is if there are implementations. Jari Arkko: I don't understand why we need switching. Please tell me. Joe Salowey: For instance, we could find out in the middle of ms-chap-v1 that we can't do it. John Vollbrecht: That would make things very unclear for doing silent discard. My suggestion is to decide now and use either SHOULD NOT or MUST NOT. Jari Arkko: Why isn't this a MUST NOT? Bernard Aboba: It can not be, because implementations are not all strict now. John Vollbrecht asks Joe Salowey: Are you doing some work on compound methods? Joe Salowey: Yes I am, but its lower priority. John Vollbrecht: It could be very useful. Jari Arkko: Lets describe the compound problem first, then look at solutions later. Conclusion: MUST for strict, MUST NOT for switch, ask list whether we can be this tough or if a SHOULD NOT is needed instead. Maybe this is not much an interoperability issue. o Can authenticator silently discard bad messages or should it fail? John Vollbrecht observes that there are the following cases: - Generic validity checks SHOULD/MUST cause silent discard. But it is not clear if passthrough can make all the checks. - Method specific validity checks. Bernard Aboba: In 802.1x, we check the EAP header for the first three fields (code, identifier, and length), but not the Type field. I think we should view passthrough ap as an IP router that only looks at the first three fields. John Vollbrecht: I'm not sure about this. Bernard Aboba: Well, its one way of explaining how things work. John Vollbrecht: I don't think we should limit the passthrough to avoid this check. Bernard Aboba: there are advantages to limiting what the passthrough does. Henrik Levkowetz: It wouldn't have worked for the method 254 (extended Nak) case. John Vollbrecht: But its more efficient to do it in the AP. No RADIUS traffic, less DoS attacks. Jari Arkko: There are three issues: There's a tradeoff between extensibility versus efficiency. Additionally, some folks believe that we need a layering model to make our specifications clear. John Vollbrecht: The state machine should allow validity checks. Jari Arkko: Agreed, and actually I think we must do this check. If it is unclear where it should be done, it could be left undone as everyone assumes someone else checked for it. At the very least, we need to require that the the check is done on the server. Could do it on the passthrough as well, as an optimization (but that would imply limitations to extensibility). John Vollbrech: The real question is whether methods are allowed to silently discard messages. We should take passthrough issues out of 2284bis and move them to 2869bis. Jari Arkko: I think we should avoid policy that specifies whether the checks are done. Instead, they should be required in the method specifications. John Vollbrecht: I agree for the authenticator state machine. Jari Arkko: The next question is what the passthrough should do. John Vollbrecht: That is less clear. These are separate issues. Yoshihiro Ohba: I'm doing a state machine for passthrough authenticator. John Vollbrecht: It is very useful to do a version of the auth state machine for this. Paul Congdon: Not only very useful, we need to incorporate one to the 802.1x annex in early May! o Sequences John Vollbrecht: Should method sequences be allowed? Clearly, some sequences are allowed. For the 2284bis, we agreed in IETF #56 that we don't do general sequences except under tunnels. Jari Arkko: That's right. From dhala@cisco.com Thu Apr 3 21:39:02 2003 From: dhala@cisco.com (David Halasz) Date: Thu, 03 Apr 2003 16:39:02 -0500 Subject: [eap] 802.11i meeting Message-ID: <4.3.2.7.2.20030403145336.029ac648@unitas.cisco.com> There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa Clara, CA. Hosted by NVIDIA. The purpose of the meeting is to continue addressing comments from letter ballot 52. There will also be a discussion about the pros/cons of splitting the PAR on April 22nd, in the afternoon. The meeting will run from 9:00 a.m. to 5:00 p.m. each day at the NVIDIA campus, which is situated at the intersection of San Tomas Expressway and Walsh Avenue. Our postal address is: 2701 San Tomas Expressway Santa Clara, CA 95050 There is ample parking on the campus, and the parking lot has two entrances: One is reachable from the northbound direction of San Tomas, and the other is reachable via the eastbound direction of Walsh. This URL should display a map of the intersection: http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoNU58.jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&country=us Visitors will need to sign in with the receptionist in Building D, which is close to the intersection of San Tomas and Walsh, facing Walsh. If you plan to attend, please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From Pasi.Eronen@nokia.com Fri Apr 4 09:03:42 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 4 Apr 2003 12:03:42 +0300 Subject: [eap] Issue: Identifier conflict Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA7E@esebe023.ntc.nokia.com> EAP Identifier conflict Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: April 4th, 2003 Reference:=20 Document: RFC 2869bis Comment type: T Priority: 1 Section: 2.1 and others? Rationale/Explanation of issue: There seems to be a potential issue with EAP packet Identifiers in 2869bis. Suppose that the EAP conversations is started by NAS (e.g. Identity request, possible followed by something else)=20 and then continues as pass-through. When sending its first=20 EAP Request, the RADIUS server must choose an Identifier value=20 different from the previous packet sent by the NAS (otherwise=20 the client will simply retransmit). If the first Access-Request sent by NAS contains an EAP Response, the AAA server can look at that packet's identifier and choose a different one. However, if it only contains EAP-Start, a conflict can occur (if the NAS already sent something to the client). This can happen, e.g. "The NAS also MAY send an Access-Request packet containing an EAP-Start if, after sending an initial Request for an authentication Type, the peer responds with a Nak" (2869bis-11, section 2.1). I see several possible ways how this could be resolved: - Specify some way for the NAS to transmit its previous=20 Identifier value to RADIUS server. - Allocate Identifier space so that conflicts don't occur (e.g. NAS uses only values 0-127, RADIUS server starts with >=3D128). - Always compare whole packets, not just Identifiers (a big change to RFC 2284, so probably not feasible). There might be other solutions, too. The second one looks the simplest to me, but is it a reasonable change? Best regards, Pasi From jari.arkko@piuha.net Fri Apr 4 10:04:54 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 04 Apr 2003 13:04:54 +0300 Subject: [eap] Issue: Identifier conflict In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA7E@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA7E@esebe023.ntc.nokia.com> Message-ID: <3E8D58C6.8050304@piuha.net> Pasi.Eronen@nokia.com wrote: > EAP Identifier conflict > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: April 4th, 2003 > Reference: > Document: RFC 2869bis > Comment type: T > Priority: 1 > Section: 2.1 and others? > Rationale/Explanation of issue: > > There seems to be a potential issue with EAP packet Identifiers > in 2869bis. > > Suppose that the EAP conversations is started by NAS > (e.g. Identity request, possible followed by something else) > and then continues as pass-through. When sending its first > EAP Request, the RADIUS server must choose an Identifier value > different from the previous packet sent by the NAS (otherwise > the client will simply retransmit). > > If the first Access-Request sent by NAS contains an EAP > Response, the AAA server can look at that packet's identifier > and choose a different one. However, if it only contains > EAP-Start, a conflict can occur (if the NAS already sent > something to the client). > > This can happen, e.g. "The NAS also MAY send an Access-Request > packet containing an EAP-Start if, after sending an initial > Request for an authentication Type, the peer responds with a > Nak" (2869bis-11, section 2.1). Interesting problem! > I see several possible ways how this could be resolved: > > - Specify some way for the NAS to transmit its previous > Identifier value to RADIUS server. > - Allocate Identifier space so that conflicts don't occur (e.g. > NAS uses only values 0-127, RADIUS server starts with >=128). > - Always compare whole packets, not just Identifiers (a big > change to RFC 2284, so probably not feasible). Well, you could also prohibit the use of RADIUS in this situation (after having got a NAK). I'm actually not sure why we need that function; it seems like the typical case where the NAS is sending its own requests is for identity request. But if you don't get an identity response, you may be in trouble already as the RADIUS infrastructure may not be able to route the AAA requests to the right home environment. Other than that, I'd prefer solution 1. Jari From aboba@internaut.com Fri Apr 4 16:18:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Apr 2003 08:18:59 -0800 (PST) Subject: [eap] Last chance to comment Message-ID: The following documents have completed IETF last call, have incorporated existing comments and are on the verge of being submitted to the IESG. Therefore if you have not read them yet, you will need to do so ASAP. Documents which have completed IETF last call and incorporated comments include: http://www.drizzle.com/~aboba/IEEE/draft-congdon-radius-8021x-24.txt http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-11.txt http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-11.txt Please send your comments to the authors, and cc: iesg@ietf.org. From aboba@internaut.com Fri Apr 4 20:11:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Apr 2003 12:11:58 -0800 (PST) Subject: [eap] Issue: Identifier conflict Message-ID: Maybe the right thing to do here is to prohibit use of EAP-Start in this circumstance? We could instead require that the Access-Request contain an EAP-Response/Nak. This would provide the Identifier so that the conflict would not occur. From aboba@internaut.com Fri Apr 4 20:35:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Apr 2003 12:35:53 -0800 (PST) Subject: [eap] Issue: Identifier conflict In-Reply-To: Message-ID: I've taken a shot at eliminating use of EAP-Start when a Nak Response is received. A strawman version of RFC 2869bis-12 including the fix is available for inspection here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-12.txt On Fri, 4 Apr 2003, Bernard Aboba wrote: > Maybe the right thing to do here is to prohibit use of EAP-Start in this > circumstance? We could instead require that the Access-Request contain an > EAP-Response/Nak. This would provide the Identifier so that the conflict > would not occur. > > From tom@bonacci.net Fri Apr 4 23:55:11 2003 From: tom@bonacci.net (tom bonacci) Date: Fri, 04 Apr 2003 16:55:11 -0700 Subject: [eap] Fragmentation: RADIUS obligation to Framed-MTU Message-ID: <3E8E1B39.E8933DA4@ascend.com> Fragmentation: RADIUS obligation to Framed-MTU Submitter name: Tom Bonacci Submitter email address: bonacci@ascend.com Date first submitted: April 4th, 2003 Reference: Document: RFC 2869bis Comment type: Technical Priority: Section: 2.4 Rationale/Explanation of issue: The "Fragmentation" section, 2.4, reads in relevant part: "... the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information." Does this (or should this) imply any obligation on the part of the RADIUS server to observe the value forwarded by the NAS? The current wording indicates the NAS MAY provide this information but is silent on how the RADIUS server is to properly react upon its receipt in an Access-Request packet. Possible resolution: Augment the above with "... the Framed-MTU attribute MAY be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information. A RADIUS server having received a Framed-MTU attribute in an Access-Request packet MUST NOT send any subsequent packet in this EAP conversation containing EAP-Message attributes whose values, when concatenated, exceed the length specified by the Framed-MTU value." The above wording implies strict obligation on the part of the RADIUS server to observe the Framed-MTU value. If strict obligation is not what's intended or desired, then the wording may be modified accordingly. regards, -tom From jari.arkko@piuha.net Sat Apr 5 07:00:06 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat, 05 Apr 2003 10:00:06 +0300 Subject: [eap] Issue: Identifier conflict In-Reply-To: References: Message-ID: <3E8E7EF6.4000108@piuha.net> Bernard Aboba wrote: > Maybe the right thing to do here is to prohibit use of EAP-Start in this > circumstance? We could instead require that the Access-Request contain an > EAP-Response/Nak. This would provide the Identifier so that the conflict > would not occur. Works for me. (But has the use of EAP-Start for this been implemented already somewhere, and if so, what are the backwards compatibility issues?) Jari From aboba@internaut.com Sat Apr 5 07:04:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Apr 2003 23:04:56 -0800 (PST) Subject: [eap] Issue: Identifier conflict In-Reply-To: <3E8E7EF6.4000108@piuha.net> Message-ID: > Works for me. (But has the use of EAP-Start for this been implemented > already somewhere, and if so, what are the backwards compatibility > issues?) No, it hasn't been implemented yet, because this wasn't in RFC 2869. It came up because IEEE 802.1aa didn't like the idea of requiring an EAP-Start in the case where EAP-Request/Identity might not be the first packet sent. The reasons for this was that although 802.1X Supplicants *can* begin with an EAPOL-Start, on wired networks they typically do not do this (because of the effect that an EAPOL-Start had on an early version of some popular hardware). As a result, the Authenticator needs to begin the conversation and until the Supplicant responds, it doesn't know whether the Supplicant is EAP-capable or not. In an environment with lots of EAP-incapable clients, doing an EAP-Start on each "carrier sense" could inundate the RADIUS server with requests, many of which would never be answered and would therefore sit using up memory until they timed out. The alternative is to have the NAS initiate with an EAP-Request, but this too has issues. Unless the EAP-Request is just a "wakeup" packet, or the first EAP-Reponse encapsulates the important fields of the initial EAP-Request, an EAP method will not work well. This is because the NAS only sends the EAP-Response in its Access-Request, *not* the original EAP-Request. If that EAP-Request is content-free (as it is in EAP-TLS), then this works fine. However, if the EAP-Request contains essential information (as it does in EAP-Archie) then there is a problem unless that information is replicated in the Response (e.g. the nonce in the EAP-Request is repeated in the EAP Response). Make sense? From aboba@internaut.com Sat Apr 5 21:30:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Apr 2003 13:30:26 -0800 (PST) Subject: [eap] Fragmentation: RADIUS obligation to Framed-MTU In-Reply-To: <20030405180002.21988.66009.Mailman@wolverine> Message-ID: I've incorporated this change into the -13 version, available for inspection below: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-13.txt > Message: 3 > Date: Fri, 04 Apr 2003 16:55:11 -0700 > From: tom bonacci > Reply-To: tom@bonacci.net > To: "eap@frascone.com" > CC: iesg@ietf.org > Subject: [eap] Fragmentation: RADIUS obligation to Framed-MTU > > Fragmentation: RADIUS obligation to Framed-MTU > Submitter name: Tom Bonacci > Submitter email address: bonacci@ascend.com > Date first submitted: April 4th, 2003 > Reference: > Document: RFC 2869bis > Comment type: Technical > Priority: > Section: 2.4 > Rationale/Explanation of issue: > > The "Fragmentation" section, 2.4, reads in relevant part: > "... the Framed-MTU attribute may be included in an > Access-Request packet containing an EAP-Message > attribute so as to provide the RADIUS server with this > information." > > Does this (or should this) imply any obligation on the part of the > RADIUS server to observe the value forwarded by the NAS? The current > wording indicates the NAS MAY provide this information but is silent on > how the RADIUS server is to properly react upon its receipt in an > Access-Request packet. > > Possible resolution: > Augment the above with > "... the Framed-MTU attribute MAY be included in an > Access-Request packet containing an EAP-Message > attribute so as to provide the RADIUS server with this > information. A RADIUS server having received a Framed-MTU > attribute in an Access-Request packet MUST NOT send any > subsequent packet in this EAP conversation containing > EAP-Message attributes whose values, when concatenated, > exceed the length specified by the Framed-MTU value." > > The above wording implies strict obligation on the part of the RADIUS > server to observe the Framed-MTU value. If strict obligation is not > what's intended or desired, then the wording may be modified accordingly. > > regards, > -tom From jintao@huawei.com Mon Apr 7 03:05:25 2003 From: jintao@huawei.com (Jin Tao) Date: Mon, 07 Apr 2003 10:05:25 +0800 Subject: [eap] Issue: Identifier conflict References: <052E0C61B69C3741AFA5FE88ACC775A608BA7E@esebe023.ntc.nokia.com> <3E8D58C6.8050304@piuha.net> Message-ID: <000e01c2fcc1$fc872c40$6d22810a@huawei.com> Mr. Jari, I am so glad to see you! I do agree with you. In eap, we should keep packet's identifier same in whole RADIUS transaction. If the scenario Mr. Eronen mentioned happens, I prefer to prohibit RADIUS function as what you have said. As a developer, I think RADIUS server cannot know where is the client until NAS reports it. Whatever RADIUS server did before NAS reports its client can be omited. In this scenario, NAS starts eap. If RADIUS does know where the client and NAS is , RADIUS starts first, NAS must obey the identifier of RADIUS. Other than that, I'd prefer solution 1. Best Regards! Yours Sincerely, Tao Jin System Engineer NanJing Institute,Huawei Technologies Co.,Ltd. Floor H,G.E. Plaza Hotel,No.89 Hanzhong Rd. NanJing, P.R. of China Zipcode:210029 TEL:(+86) 25-4723480-3009 FAX:(+86) 25-4723063 Email:jintao@huawei.com ----- Original Message ----- From: "Jari Arkko" To: Cc: Sent: Friday, April 04, 2003 6:04 PM Subject: Re: [eap] Issue: Identifier conflict > Pasi.Eronen@nokia.com wrote: > > EAP Identifier conflict > > Submitter name: Pasi Eronen > > Submitter email address: pasi.eronen@nokia.com > > Date first submitted: April 4th, 2003 > > Reference: > > Document: RFC 2869bis > > Comment type: T > > Priority: 1 > > Section: 2.1 and others? > > Rationale/Explanation of issue: > > > > There seems to be a potential issue with EAP packet Identifiers > > in 2869bis. > > > > Suppose that the EAP conversations is started by NAS > > (e.g. Identity request, possible followed by something else) > > and then continues as pass-through. When sending its first > > EAP Request, the RADIUS server must choose an Identifier value > > different from the previous packet sent by the NAS (otherwise > > the client will simply retransmit). > > > > If the first Access-Request sent by NAS contains an EAP > > Response, the AAA server can look at that packet's identifier > > and choose a different one. However, if it only contains > > EAP-Start, a conflict can occur (if the NAS already sent > > something to the client). > > > > This can happen, e.g. "The NAS also MAY send an Access-Request > > packet containing an EAP-Start if, after sending an initial > > Request for an authentication Type, the peer responds with a > > Nak" (2869bis-11, section 2.1). > > Interesting problem! > > > I see several possible ways how this could be resolved: > > > > - Specify some way for the NAS to transmit its previous > > Identifier value to RADIUS server. > > - Allocate Identifier space so that conflicts don't occur (e.g. > > NAS uses only values 0-127, RADIUS server starts with >=128). > > - Always compare whole packets, not just Identifiers (a big > > change to RFC 2284, so probably not feasible). > > Well, you could also prohibit the use of RADIUS in this situation > (after having got a NAK). I'm actually not sure why we need that > function; it seems like the typical case where the NAS is sending > its own requests is for identity request. But if you don't get an > identity response, you may be in trouble already as the RADIUS > infrastructure may not be able to route the AAA requests to the > right home environment. > > Other than that, I'd prefer solution 1. > > Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From Pasi.Eronen@nokia.com Mon Apr 7 08:41:35 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 7 Apr 2003 10:41:35 +0300 Subject: [eap] One more clarification to 2869bis... Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612225E@esebe023.ntc.nokia.com> Hi, We've been working on pass-through/back-end state diagrams=20 with John, Nick, and Yoshiro, and I noticed one more issue in 2869bis that at least needs clarification: Section 2.1 says that "Success and Failure packets MUST=20 NOT be sent as the result of a timeout." Does this mean that as the result of a timeout, the NAS=20 must not "manufacture" an EAP Failure packet, but simply end=20 the conversation, right? And "timeout" here applies to both=20 peer<->NAS and NAS<->RADIUS server communication? (In the case of peer<->NAS timeout, it probably does not make=20 sense to send Failure since most likely it will be lost, too,=20 but in NAS<->RADIUS timeout it could make sense.) If my interpretation was correct, maybe this could be rephrased something like "The NAS MUST NOT "manufacture" a Success or Failure packet as a result of a timeout, but simply end the EAP conversation." Best regards, Pasi From aboba@internaut.com Tue Apr 8 07:36:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Apr 2003 23:36:12 -0700 (PDT) Subject: [eap] Another shot at resolving Issue 83: Invalid Packet handling Message-ID: Issue 83 dealt with how to allow a RADIUS authentication server to silently discard an invalid EAP packet. The current text of Section 2.2 can be found in draft-aboba-radius-rfc2869bis-12.txt. Here is an alternative resolution that avoids allocation of an additional Service-Type value, and also is less likely to result in a timeout on legacy NASes. Complete text is available at: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-13.txt Comments welcome. ------------------------------------------------------------------------ 2.2. Invalid packets While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to the RADIUS server. However, since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, it is possible for a NAS to forward an invalid EAP packet to the RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD make the determination of whether the error is fatal or non-fatal based on the EAP Type. A RADIUS server determining that a fatal error has occurred MUST send an Access-Reject containing an EAP- Message attribute encapsulating EAP-Failure. In order for the RADIUS server to communicate to the NAS that an invalid EAP packet has been forwarded to it, but that the error is non-fatal, the RADIUS server MAY send an Access-Challenge encapsulating the last EAP-Request with an unchanged Identifier value, within EAP-Message attribute(s), along with an Error-Cause attribute (defined in [DynAuth]) of value 202, "Invalid EAP Packet (Ignored)". On receiving this message, a legacy NAS will decapsulate the EAP-Request and send it to the EAP peer. This will result in the EAP peer retransmitting the EAP- Response. A NAS compliant with this specification, on receiving an Access- Challenge with an Error-Cause attribute containing a value of "Invalid EAP Packet (Ignored)" SHOULD discard the current EAP-Response packet, and check whether additional EAP-Response packets have been received with an Identifier matching that of the last Request. If so, a new EAP- Response packet, if available, MUST be sent to the RADIUS server within an Access-Request. If no EAP-Response packet is available, then the encapsulated EAP-Request is sent to the EAP peer, and the retransmission timer is reset. Once the RADIUS server responds with a packet containing a non-null EAP-Message attribute, the NAS updates the Identifier value, and any pending Responses that do not match this value can be discarded. In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the NAS to allocate a finite buffer for Responses, and to discard packets according to an appropriate policy once that buffer has been exceeded. Also, the RADIUS server is advised to support only a modest number of invalid EAP packets within a single session, prior to terminating the session with an Access-Reject. From jari.arkko@piuha.net Tue Apr 8 10:15:17 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 08 Apr 2003 12:15:17 +0300 Subject: [eap] ietf-56 eap meeting notes (revised) In-Reply-To: References: Message-ID: <3E929325.6060604@piuha.net> Minutes from the IETF-56 Extensible Authentication Protocol WG (eap) meeting CHAIRS: Bernard Aboba Jari Arkko MAILING LIST: Address: eap@frascone.com To subscribe: eap-request@frascone.com, with "subscribe" in Subject line. PRESENTATIONS: http://www.drizzle.com/~aboba/IETF56/EAP MINUTES: Henrik Levkowetz, Paul Funk, Bob Moskowitz (edited by Jari Arkko and Bernard Aboba) SESSION 1: Monday, March 17 at 1530-1730 1. Preliminaries (10 minutes) - Bluesheets - Minute Takers - Agenda Bashing Jari summarized the agenda for today and thursday, and asked for comments - none. 2. Networld+Interop (Karen O'Donoghue) N+I (in three short weeks) will have a 802.1x demo and a 3-day interoperability test session for EAP methods. Methods to be tested include EAP-TLS, EAP-TTLS, and EAP-PEAP, as well as a variety of inner methods. Please come, and bring your EAP method (better tell her first, though). 3. IEEE 802.11 Request (Dorothy Stanley) Dorothy represents the IEEE 802.11 group and is responsible for liaison with the IETF. The IEEE, as a user of IETF protocols, in particular EAP and RADIUS, has formally requested guidance in selection of EAP methods to meet their security goals, in the following categories: methods of authentication via certificate, user-password and GSM/UMTS secrets; key strength and key material (128 bit effective key strength needed); mutual authentication; resistance to dictionary attack; thwarting of MitM attack; replacement for EAP-MD5-Challenge (which is subject to MitM attack). The letter is available at http://www.drizzle.com/~aboba/IETF56/EAP/11-03-243r2-I-Input-to-IETF-EAP-WG-March-2003.doc In addition to the 802.11i work, 802.11f is working on inter-access-point protocols, which will utilize RADIUS. There are issues related to this, as it is necessary to add new Service-Type values and possibly change the behaviour of certain parts of RADIUS. Dorothy presented the IEEE 802 response to IETF issues, which is available here: http://www.drizzle.com/~aboba/IETF56/EAP/11-03-264r0-W-IETF_Liaison_Report_March_2003.ppt 4. Document status Jari summarized the document status: - 2284bis - a lot of issues handled, plan a WG last call when all issues closed. Pointed out that the background for 2284bis is unclear parts of 2284, and having interoperability problems. The goal for 2284bis is to clarify unclear points and ensure interoperability, and *not* add new features. - There's documents for EAP state machine, keying framework, and others. Mentioned the requirements for adopting new documents as working group items. Drafts adopted as working group items must have a level of maturity; there should have been significant review already performed and all major issues should already have been resolved. Bernard added timeframe: June for Keying document. Things may be dropped rather than let them slide. 5. RFC 2284bis, Henrik Levkowetz and Jari Arkko http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt Three major outstanding issues were presented, and a vigorous discussion ensued. Issue 80 - Is EAP-Success required? - There was some discussion of whether the new draft should allow the client to acknowledge success, whether particular EAP types should provide alternative means to acknowledge success, whether all methods that don't perform mutual authentication should be abolished. - Henrik made clear that this issue does not pertain to the authenticator, which always must issue Success if the authentication was successful. However, there are several choices for client behavior: (a) Client does not require Success. (b) Client requires Success, or it must refuse to proceed with connection. (c) Client normally requires Success, but if there is an alternative indication that implies Success client may proceed with connection. - Hum results: (a) inaudible (b) -70 dB (c) -43 dB Loudest: (c) Issue 97 - May packets of another type interrupt an authentication sequence (strict mode) - Some confusion was expressed by commentators as to whether this relates to serial authentications or interruptions of a sequence which may not have completed (e.g. DoS). Also the question was brought up as to whether the authenticator should be allowed to switch to a different method before the first completed; for example, if the authenticator determines that the original method cannot complete and wishes to try an alternative without failing the user. - In the interest of assessing how this decision would affect existing deployments, various implementors rose to describe how badly their code would react to receiving packets of unexpected type, though nobody actually shared source code. Most implementers currently silently discard packets of unexpected type. - Choices were: (a) Yes, they may (no strict mode). (b) No, and this is enforced by the state machine discarding packets of unexpected type (strict mode). (c) Not really, but this is enforced by state machine in consultation with currently running type, so exceptions may be made (limited strict mode). - Hum results: (a) -10 dB (disqualified because it originated from a single point source) (b) -50 dB (c) -49 dB Loudest: (c) Issue 87 - Type change during method - This issue was admittedly closely related to the previous (97). The issue pertains both to the authenticator switching to a new type before the first is complete and starting a new type after the first is complete (serial authentication). - Jesse Walker pointed out a use case for serial authentication that someone may actually want to do: authenticating first the machine, and then the user of the machine. - John Vollbrecht argued that a type change in the middle of a sequence can be distinguished by the client from serial authentication after the first type is complete, and therefore type change should not be outlawed. He also felt that behavior in this regard is a security choice, but should not constrain the protocol. - There was discussion as to whether the client can know that a method has completed. For example, it will know when it has successfully authenticated the server, but may not know whether the server has completed its authentication of the client. - Bernard Aboba felt that allowing type change would pose a challenge to existing implementations. Also, sentiments were expressed that serial authentication would pose problems to the state machine. Jose Puthenkulam argued that the key binding problem, absent a single EAP method that embraces the serial methods, is an open-ended one whose solution is not yet known. - The choices were how strongly to discourage type change: (a) The authenticator SHOULD NOT perform a type change. (b) The authenticator MUST NOT perform a type change. - Hum results: (a) -60 dB (b) -47 dB Loudest: (b) But with the following provision: There may be only a single outer EAP type. However, that type itself may tunnel EAP types, of which there may be multiple. That is, sequences outside tunnels are a MUST NOT. The outer protocol is responsible for defining how that is done and how the results of the inner types are combined to produce a unified session key. 6. EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt Presentation from Pascal about the capabilities of smartcards and the interface to EAP proposed for smartcards. Pascal described an API that would allow EAP to be embedded in a SmartCard. The SmartCard would receive EAP packets from and send them to the network, and perform all cryptographic processing internally as a closed system. A management interface would allow client software to provision the SmartCard with identities, policies, etc. Such a SmartCard could handle protocols such as EAP-SIM, EAP-TLS, etc. No questions 7. Compound Binding, Jose Puthekulam, 10 minutes http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt Presentation from Jose on compound methods. Turns out that there are man-in-the-middle attacks possible on tunnelled compound methods. Compound tunnelled methods may be used in order to - Secure legacy methods in new environments - Ease of deployment for securing legacy methods - Providing consistent security properties and other features for different methods - Securing multiple credentials in sequences. Non-tunnelled compound sequences are also vulnerable but not addressed by this draft. If such sequences were used somewhere, a compound key derivation would have to be designed for them as well. Requirements for the attack: - The MITM is able to run dual roles - rogue authenticator and rogue supplicant - Creds and method re-used with and without tunnel - Tunnel is one-way server authenticed - Use of tunnel session keys alone and no inner method session keys Yoshi: I believe that #3 is not necessary - it's possible also for mutually authenticated tunnells. Jose: Yes, but that's a *trusted* MitM - in which case all bets are off. Jose then laid out a general framework for providing solutions to the problem. Some of the solutions are policy-based (e.g. don't do that); others are cryptographic. Possible solutions: - for non-key deriving methods * Use of separate credentials inside and outside tunnels breaks the attack. * Always use methods inside tunnels?? - for key-deriving methods * Use cryptogrphic bindings: + Compound Keyed MACs + Compound Session keys The attack may be foiled either at the point of authentication or at the point of use. That is, there may be an additional authentication step to assure both parties of the absence of an MitM, or the validity of session keys generated for the connection may be made to depend on absence of MitM. Jose favors the former, as it nips the problem in the bud and precludes a connection from even being set up. Allowing the connection to be set up (only to fail to operate) is expensive and therefore encourages DoS attacks. Jose presented the notion of a "binding phase", which uses single round-trip cryptographic algorithm to perform the compound authentication at the conclusion of the EAP sequence. Bernard asked (a) which PRF is used in the binding phase, and (b) whether this is compatible with IKE v2. Jose replied that (a) each tunneling protocol selects its PRF, and (b) each tunneling protocol defines and exports its own session keys, so the tunneling protocol is independent of the context in which it is carried and is therefore compatible with IKE v2. SESSION 2: Thursday, March 17 at 1530-1730 8. RFC 2869bis, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt Bernard summarised the status of RFC2869bis, there's one open issue currently, issue 83. Here an AAA server can receive an invalid EAP packet from an authenticator in passtrough mode. The message cannot be just dropped, as the authenticator will retransmit the AAA request. Details of the proposed resolutions are the slides. A lot of little nits have been fixed. A solution for "the lying NAS problem" was described in the slides (RFC2869bis). The solution is to require RADIUS proxy verify NAS identifier. 9. EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt Jesse Walker talked about EAP Archie, a proposed solution to the problem that none of the current mandatory 2284 methods are suitable to 802.11. Archie would if accepted be a new mandatory EAP method. The Archie exchange consists of the following message exchanges (see slides [Archie] for details <-- Random Session ID (Request) Hash of Session ID, Random Nonce, Binding (MAC addresses), MIC --> <-- Hash of prev Msg, Encrypted Nonce, Binding(MAC addresses), MIC Finish: Hash, MIC --> Can the EAP MD5 Challenge method be deprecated? Can EAP-Archie be adapted to be suitable for PPP? Is there interest in taking on this work? Simon Misikowski: What kind of hashes? Jesse: The hashes are SHA hashes. Bob Moskowitz: How would this work with a Proxy RADIUS? Not sure that EAP-AKA doesn't also meet the 802.11 requirements? Bernard Aboba: There is no Proxy RADIUS issue as long as the RADIUS server uses NAS-Identifier, NAS-IPv6-Address or NAS-IP-Address attributes to compose or check bindings, *not* the packet source addresses. Alper Yegin: Why should the method be made more suitable for it's transport (PPP) Jesse: I'm asking for input on the appropriate address type for PPP. This is the Called-Station-Id and Calling-Station-Id (e.g. phone number). Alper Yegin: WLAN is primary transport? We may need to change it to adapt to other protocols? Jesse: We'd have to look at whatever is needed to adapt it. The issue in adaptation was only the address type, nothing else. ?: Looking at the differences between this and AKA. There's also the ESE, which should be compared Joe Salowey: I liked the binding aspect, we may need to look at introducing this other places or in a generic fashion? 10. EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt Bernard presented Goals and Objectives for EAP Keying. Slides [Keying]. This is a framework for evaluate keying methods, rather than a proposal of methods. Further: EAP Invariants for keying methods, Terms for Master Key Types, ... Paul Congdon: Should you define the length of these keys if you are trying to be ciphersuite independent? Bernard Aboba: You might get suites deriving keys with different length, maybe quite short keys. The answer could be to require ridiculously large keys, or to settle on lengths which are currently sufficient. It was noted that the issue was not the length of the EMSK or MSK but its equivalent key strength. 64B is plenty long enough -- but in the future the required key strength might increase. Today 802.11 is asking for the ability to negotiate 128-bits of key strength, tommorrow it might be more. Simon (?): The MSK could be derived from the EMSK (or MK)? Bernard Aboba: No, but the EMSK MUST be cryptographically independent of the MSK and MK. The EMSK can be derived from the MK via a one-way function, or it can be a completely independent quantity. Simon: What is the purpose? Bernard Aboba: Purpose not defined yet, but its essence is that it is known by Peer and Server, and *not* by NAS. The MK is never exported, so that the MK cannot be used in computations done outside the EAP method, such as fast handoff. Where PFS is required (such as in deriving a key given to a NAS that cryptographically separate from a key known by another NAS), the only exportable quantity available to derive this from is the EMSK, since NASes never have access to it. Bob Moskowitz: The MSK is known by at least 3 parties, and the 64 bytes keying material - it is distinct from the entroyp. This defines the key lenght, not the key strength. Bernard Aboba: Yes. Bernard, continuing presentation, covering: EAP Key Hierarchy, and EAP (Key) Exchanges. There's a two-way exchange: EAP client <-> NAS, no AAA server small network usable in larger There's also a three-way exchange: client, NAS, AAA frequently deployed in larger networks Bernard continues the presentation and talks about the EAP (Bermuda) triangle. This triangle is as follows: EAP peer /\ EAP mutual auth, / \ TSK derivation, MK, TEK, EMSK / \ mutual auth, / \ TSKs / \ Auth Server ------------ Authenticator AAA mutual auth, AAA session key (TLS, IPsec) Bernard talks about the security requirements: - mutual authentication each leg - fresh session keys on each leg - key protected from compromise - protection against MITM - per-packet authentitcation, integrity, replay protection each leg The Open Issues were: - #15 missing security requirements - #47 keying requirements unspecified (why 64 bytes) what about specifying key strength? - #99 double expansion MK->MSK & MSK->TSK T.J. Kniveton: You said you couldn't get a MK out of a SIM card, but section 17 of the draft describes certain derivations Bernard Aboba: There were papers written which assumed you could get the MK out of the SIM, but we needed to clarify that it never leaves the EAP method. The MK cannot and need not leave the SIM card or the MK box in the Key Hierarchy. Joe Salowey: There are implementations of EAP SIM where the entire calculation takes place on a SIM card. Bob Moskowitz: FIPS has a document which has a key derivation proces which which we maybe we should look at, to make sure it is compatible. May need this in order to be FIPS compliant. Bernard Aboba: The document won't recommend a KDF, but it will pose requirements on KDFs. John Vollbrecht: Wanted a clarification on which keys are carried where. Bernard Aboba: (Clarification given.) John Vollbrecht: Is it likely that these things will change in the future? Bernard Aboba: If we've done a good job, this should be future proof. John Vollbrecht: Can these keys be taken out of the method? Bernard Aboba: The MSK, EMSK and IV are exported from the method. However, only the MSK is sent by the AAA Server to the NAS. The EMSK MUST NOT Be sent by the AAA Server to the NAS. The MK and TEKs are never exported from the method. The IV isn't sent by the AAA Server to the NAS but it's not very useful since it is a known quantity (required by US Export Laws several years ago). As a result it is largely vestigial. Simon: Client is roaming; while in a session, which key is transported to the new (target) NAS? Bernard Aboba: Actually, the MSK is never transported between NASes. Some proposals derive a new master session key on the AAA server, based on the EMSK and send this to the new NAS. This provides PFS. Other proposals have one NAS send a key derived from the MSK via a one-way function and send this to the new NAS. This way the new NAS can't decrypt previous traffic but the old NAS can decrypt new traffic. Simon: But there has to be a coupling between EMSK and TSK, so... Bernard Aboba: There are example formulas and methods in the Appendix. The EMSK, TEKs and TSKs are cryptographically independent. Glenn Zorn: -- Long silence, looking at EAP key hierarchy. Is it true you're treating these entities equally - including a proxy? Bernard Aboba: Yes, although it gets complicated when you have a proxy. Glenn Zorn: It could be handy to have a key known to all, but only useful for a certain purpose, such as AAA interchanges? Bernard Aboba: Yes, but there's a question here from where you derived such a key - and depending on where you derived it from, would it be secret to the people it needed to be secret from? I.e. which key tree should you John Vollbrecht: Are there 1 quantity exported from AAA server? Bernard Aboba: There are 3 entities derived, and 1 exported. Dan Forsberg: Do you specify or recommend any lifetimes for these keys, and if some time out, how do they get renewed, and can ESMK be used for session resumptions? Bernard Aboba: The EMSK is *not* used to resume sessions, because it is known by more than 2 parties. We have talked about including a key lifetime parameter, but currently the key lifetime is equal to the session lifetime, but there's a question if that's sufficient or not. 11. EAP Key Derivation for Multiple Applications, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt Joe Salowey made a presentation on EAP Key Derivation For Multiple Applications. See slides. Highlights: Motivation, Applications (WEP, 802.11i, MPPE, Fast Roaming, ...) Requirements, Key Derivation, and currently open issues. Bernard Aboba: How do we figure out how much material should be derived? Joe: 64 bytes are a lot of material. We need to get input from security experts. Simon: Lucent put out some papers, for 3GPP and 3GPP, requrements on keys for them to be acceptable in 20 years. The resulting key strength (entropy) of 84 bits. Joe Salowey: Yes, 64 bytes are much. Alper Yegin: Any constraints on which applications may use this? Joe: I'd rather make keying materials available to application that needs it, rather than making restrictions. Alper Yegin: There may be security considerations with making keying material available to random applications. Bernard Aboba: Did you choose TLS for some particular purpose, or as just an example? Joe Salowey: No particular significance. Simon: (Examples of other possible KDF). Bob Moskowitz: (Pointed out which documents in the references needed to be looked at in relation to this). 12. EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes Erik Nordmark made a presentation about Methods, Methods, Methods, Or When can we start talking about methods? (See Slides). Highlights: Requirements, Simon: 3GGP2 Requirements should also be considered. Bernard Aboba: We don't have a liaison with 3GPP2 yet? In the case of IEEE and 3GPP, they have to us and told their requirements. Simon: Interoperation between 802.11 and CDMA is an active work item within 3GPP2. You're welcome to get all requirement from the 3GPP2 web site. Erik continued: Selecting methods?, Strawman proposal: Methods can be submitted as individual submission RFCs, need Expert Review but that can start now. Method RFCs must depend on the new versions of RFC 2284 etc, however. Keep MD5 as mandatory, Capture requirements from different scenarios in an informational RFC, start work on a BCP which captures mapping from environments to appropriate methods, and possibly later pick new mandatory methods. Significant delay (9-12) months possible if we tried to do that. Not select methods for other SDOs. John Vollbrecht: We need to test interoperability, so we need some mandatory methods that exercise the features we have in our protocols. Bernard : The reason 802.11 have asked for a new mandatory method is that they are not sure they could do it themselves, so this might leave them in a bit of a quandary. Bob Moskowitz: IEEE ... They have tradentionally have been reluctant to mess with other organizations babies. EAP is your method, so please make it acceptable to our needs. We should make sure that within a year we can provide what they need, a specification of what should be used. A BCP might be good enough, it mustn't necessary be a Standard. Alper: Agree with the strawman approach, it seems a way to go forward without specifying a new mandatory method for each new interested party - IEEE, 3GPP, 3GPP2, ... Simon: The original requirements originally came from 802.11? So whatever we present to them, it will be up to them to select from whatever smorgasbord we present to them. 64 bits, is that their req? Bob Moskowitz: Yes. Simon: and mutual authentication came from them? Bob Moskowitz: Yes. Dave (?): We need to have a recommendation of a mandatory method for use with 802.1i, and this is really out of our scope, this belongs to IETF. We need a published document we can reference in our documents, pointing out a method we can use. Erik Nordmark: So a BCP would be enough, a PS is not needed? John Vollbrecht: We need a specified method in order to measure interoperability Bob Moskowitz: Any methods we can get out quicker rather than later, in the form of an RFC rather than just a draft, makes it possible for them (802.xx) to reference it, and say to vendors "these are the methods to use, go out and implement them" 13. IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 minutes Paul Congdon made a presentation on alignment of different 802.xx and EAP RFCs. (See slides) Highlights: Current status, Document List, Proposed and Agreed Changes to 802.1aa/D5, EAP/802.1X Interface, Key Interface with EAP, 802.1X, 802.11, LinkSec Task Group Formation in 802.1 14. EAP State Machine, John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt John Vollbrecht made a presentation on EAP State Machines. (See Slides). Highlights: URL's, State Machine Style, EAP Mux Model, Peer State Diagram (802.xx style state machine), Pass through, Policy Functions, State Machine next steps, 15. EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.txt Joe Salowey, presentation on Protected EAP-TLV, a way to protect a (tunnelled) series of TLV's. (See Slides), and continued with EAP-Authorization, a method to request authorization for services and session attributes (See Slides) Dave (?): Which endpoints would exchange these TLVs? Joe Salowey: Supplicant and Auth. Server. John Vollbrecht: Is this going to be a method? Joe Salowey: Right now it's just a TLV, and maybe it makes sense to make it a method, but I don't know if it must be. John Vollbrecht: So it could be tagged into other methods? Joe Salowey: Essentially a method, could come at the end of other methods. Could happen inside an EAP message. John Vollbrecht: So I could run EAP within EAP within EAP... 16. EAP SIM and AKA, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt Joe went on with a presentation on EAP-SIM drafts (multiple). (See Slides). Bob Moskowitz: I'd like to see a change in the AKA draft, to talk about a shared secret method, and then a particular GSM application in an Appendix Jari Arkko: So this is only a question of a change in terminology? Bob Moskowitz: Yes, and mapping to GSM terminology as a separate part. Jari Arkko: I think we can do this. Simon: How does SIM fill the 128 bits requirement? Joe: You use multiple triplets. Simon: These triplets doesn't provide mutual auth? Joe: No, but EAP-SIM does provide mutual auth based on these. Bernard suggested that even if this is not yet a WG document, the authors should already now get security reviewers, to speed up the process. 17. Tunneled MD5, Paul Funk, 5 minutes http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt Paul Funk made a presentation on The EAP MD5 Tunneled Authentication Protocol. (See Slides). This is an attempt to cure the MITM problem for tunnelled operation, (the Puthenkulam draft) 18. Meeting ended. From johan.rh.hermans@alcatel.be Fri Apr 11 17:28:16 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Fri, 11 Apr 2003 18:28:16 +0200 Subject: [eap] Issue: Identifier conflict In-Reply-To: References: Message-ID: <3E96ED20.7010103@alcatel.be> Bernard Aboba wrote: >I've taken a shot at eliminating use of EAP-Start when a Nak Response is >received. A strawman version of RFC 2869bis-12 including the fix is >available for inspection here: > >http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-12.txt > >On Fri, 4 Apr 2003, Bernard Aboba wrote: > > Note that the scenario that causes this problem can be found in RFC2869bis-10, on page 34 (Nas sends EAT-Request/EAP-TLS to peer, who refuses). So if the RADIUS server receives an Access-Request/EAP-Response/Nak, that doesn't match any previous request send by this RADIUS-server, it has to assume this scenario, and start a new EAP-conversation (most likely a EAP-Request/Indentity) ? Then we'll also have to change paragraph 4.1 ("The Identifier Field of the Response MUST match that of the currently oustanding Request ..."), which forces us to silently discared 'unknown' responses. -- Jo Hermans That's not encrypted - that's a perl script I'm working on From aboba@internaut.com Mon Apr 14 07:33:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 13 Apr 2003 23:33:09 -0700 (PDT) Subject: [eap] New draft "EAP IKEv2 Method" (fwd) Message-ID: ---------- Forwarded message ---------- Date: Sun, 13 Apr 2003 21:19:43 +0200 From: Hannes Tschofenig To: internet-drafts@ietf.org Cc: aboba@internaut.com, Jari.Arkko@ericsson.com Subject: New draft "EAP IKEv2 Method" Dear editor, we would like to submit a new draft relevant for the EAP working group. You will find the draft attached to this mail. Proposed title: --------------------- EAP IKEv2 Method Proposed name: ------------------------ draft-tschofenig-eap-ikev2-00.txt Abstract: ------------- EAP-IKEv2 is an EAP method which reuses the cryptography and the payloads of IKEv2, creating a flexible EAP method that supports both symmetric and asymmetric authentication. Furthermore protection of legacy authentication mechanisms is supported. This EAP method offers the security benefits of IKEv2 without the goal of establishing IPsec security associations. Best regards, Hannes Tschofenig Dirk Kroeselberg From Pratik_Mehta@Dell.com Wed Apr 9 14:50:58 2003 From: Pratik_Mehta@Dell.com (Pratik_Mehta@Dell.com) Date: Wed, 9 Apr 2003 08:50:58 -0500 Subject: [eap] RE: [802-11Technical] 802.11i meeting Message-ID: <471BC551F7B829438721FE879904D376C9ECCA@ausx2kmps304.aus.amer.dell.com> Could you please provide a call-in number and timeslot for the portion on April 22nd when the PAR split will be discussed? Thnx. -pm. -----Original Message----- From: David Halasz [mailto:dhala@cisco.com] Sent: Thursday, April 03, 2003 3:39 PM To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: [802-11Technical] 802.11i meeting There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa Clara, CA. Hosted by NVIDIA. The purpose of the meeting is to continue addressing comments from letter ballot 52. There will also be a discussion about the pros/cons of splitting the PAR on April 22nd, in the afternoon. The meeting will run from 9:00 a.m. to 5:00 p.m. each day at the NVIDIA campus, which is situated at the intersection of San Tomas Expressway and Walsh Avenue. Our postal address is: 2701 San Tomas Expressway Santa Clara, CA 95050 There is ample parking on the campus, and the parking lot has two entrances: One is reachable from the northbound direction of San Tomas, and the other is reachable via the eastbound direction of Walsh. This URL should display a map of the intersection: http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoNU58. jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&country=us Visitors will need to sign in with the receptionist in Building D, which is close to the intersection of San Tomas and Walsh, facing Walsh. If you plan to attend, please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 This message came from the IEEE 802.11 Technical Reflector List Info at http://www.ieee802.org/11 From TMaufer@nvidia.com Wed Apr 9 21:10:13 2003 From: TMaufer@nvidia.com (Thomas Maufer) Date: Wed, 9 Apr 2003 13:10:13 -0700 Subject: [eap] RE: [802.1] RE: [802-11Technical] 802.11i meeting Message-ID: <128D60D434C15C4ABE1A4E78E03BC1CFFA5EA7@mail-sc-9.nvidia.com> Dave Halasz said he would set up a teleconference bridge. I (or Dave) will make sure that the information is distributed well in advance of the meeting. Cheers, Tom -----Original Message----- From: Pratik_Mehta@Dell.com [mailto:Pratik_Mehta@Dell.com] Sent: Wednesday, 09 April, 2003 06:51 To: dhala@cisco.com; stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: [802.1] RE: [802-11Technical] 802.11i meeting Could you please provide a call-in number and timeslot for the portion on April 22nd when the PAR split will be discussed? Thnx. -pm. -----Original Message----- From: David Halasz [mailto:dhala@cisco.com] Sent: Thursday, April 03, 2003 3:39 PM To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: [802-11Technical] 802.11i meeting There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa Clara, CA. Hosted by NVIDIA. The purpose of the meeting is to continue addressing comments from letter ballot 52. There will also be a discussion about the pros/cons of splitting the PAR on April 22nd, in the afternoon. The meeting will run from 9:00 a.m. to 5:00 p.m. each day at the NVIDIA campus, which is situated at the intersection of San Tomas Expressway and Walsh Avenue. Our postal address is: 2701 San Tomas Expressway Santa Clara, CA 95050 There is ample parking on the campus, and the parking lot has two entrances: One is reachable from the northbound direction of San Tomas, and the other is reachable via the eastbound direction of Walsh. This URL should display a map of the intersection: http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoNU58. jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&country=us Visitors will need to sign in with the receptionist in Building D, which is close to the intersection of San Tomas and Walsh, facing Walsh. If you plan to attend, please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 This message came from the IEEE 802.11 Technical Reflector List Info at http://www.ieee802.org/11 From aboba@internaut.com Mon Apr 14 18:45:50 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 14 Apr 2003 10:45:50 -0700 (PDT) Subject: [eap] Issue 104: Sequence prohibition Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 14th, 2003 Reference: Document: EAP-01 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: At IETF 56, it was proposed that sequences of EAP methods MUST NOT be supported (with an exception for tunneled EAP methods). The following text changes support that proposal. Change Section 2.1 from: " 2.1 Support for sequences An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. However, peer implementations MAY not respond at all, in which case a timeout will result and authentication will fail. Since the authenticator presumably requires successful completion of the sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in Section 4.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed." To: "2.1 Support for sequences An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However a peer MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation. Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method, and MUST NOT send a Request for an additional methods of any Type after completion of the initial authentication method. Supporting multiple authentication methods within an EAP conversation would add complexity to the EAP protocol, would enable man-in-the-middle attacks (see Section 7.4), and would result in interoperablity problems, since existing EAP implementations typically do not support sequences. If an additional authentication method is requested by the authenticator, or if the authenticator sends a Request of a different Type prior to completion of the final round of a given method, the peer SHOULD silently discard the Request. As an alternative, the peer MAY respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. Since spoofed EAP Request packets may be sent by an attacker, an an authenticator receiving an unexpected Nak SHOULD log the event. The case where a single EAP authentication method is utilized, but other methods are run inside it, does not qualify as a sequence of EAP methods as defined here. Such "tunneled" methods appear to the EAP state machine as a single method. Backward compatibility can be provided, since a peer not supporting a "tunneled" method can reply to the initial EAP-Request with a Nak. To avoid adding man-in-the-middle vulnerabilities, "tunneled" methods MUST support protection against these attacks. Within or associated with each EAP server, it is not anticipated that a particular named pper will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. " From aboba@internaut.com Mon Apr 14 19:33:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 14 Apr 2003 11:33:25 -0700 (PDT) Subject: [eap] Issue 97: Strict interpretation Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 7, 2003 Reference: Document: EAP-01 Comment type: Technical Priority: S Section: 4.2.1 Rationale/Explanation of issue: At IETF56 it was proposed to tighten the EAP state machine so as to preclude a number of possibilities, including changing Type in the middle of a method, and sending an EAP Success or Failure before a method is complete. Change Section 4.2.1 "4.2.1 Processing of success and failure Within EAP, success and failure indications consist of the EAP Success and Failure messages, as well as method-specific indications. Within EAP, these indications may be protected or unprotected. EAP Success and Failure packets are considered unprotected indications which may be spoofed, since as described in Section 4.2, they contain no message integrity check (MIC). In order to provide additional protection against tampering, EAP methods MAY support a MIC that covers some or all of the EAP packet, including headers. In addition, such a MIC MAY include coverage of previous Request and Response messages, so as to enable protection of other packets to that do not contain MICs, such as Identity Request/ Response, Notification Request/Response and Nak Response. EAP methods also MAY include support for method-specific acknowledged success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated, as well as for the peer to acknowledge receipt of that indication, and respond with an indication of whether the authenticator has successfully authenticated to the peer. If a key has previously been derived, the result exchange MAY be protected by a Message Integrity Check (MIC), and if so, then this success/failure indication is considered protected. In order to decrease vulnerability to spoofing of success and failure indications, the following processing rules are recommended: [a] Processing of protected success and failure indications. Where a method-specific protected success/failure indication has been received, the implementation MUST validate the EAP method MIC, with a MIC failure handled via silent discard, as specified in Section 4.1. [b] Receipt of EAP Success and Failure packets prior to method completion. A peer EAP implementation receiving an EAP Success packet prior to completion of the method in progress MUST silently discard it. This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. A peer EAP implementation receiving an EAP Failure packet prior to completion of the method in progress MAY silently discard it. When using EAP methods that provide their own (protected) error indications, premature EAP Failure packets are unexpected, so that this technique may be more readily employed. [c] Authentication requirement. An EAP peer implementation that has been configured to require authentication MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [d] Contradictory indications. Where protected and unprotected result indications are both available, protected indications take precedence. For example, where an EAP method provides a protected indication that authentication failure has occurred in either direction, the implementation MUST silently discard subsequent EAP Success packets. Similarly, where an EAP method provides a protected indication that authentication has succeeded in both directions, the EAP implementation MAY silently discard EAP Failure packets. [e] Processing of EAP Success and Failure in the absence of protected indications. Subsequent to the completion of the EAP authentication method (Types 4 and greater), and in the absence of protected result indications, EAP Success and Failure packets MUST be accepted and processed by the EAP implementation." To: "4.2.1 Strict interpretation As noted in Section 2.1, once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method, with the exception of a Notification-Request. The authenticator also MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method. A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. EAP Success or Failure packets MUST NOT be sent by an authenticator prior to completion of the final round of a given method. A peer EAP implementation receiving an EAP Success packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. A peer EAP implementation receiving an EAP Failure packet prior to completion of the method in progress also MUST silently discard it. An EAP method wishing to enforce tighter security MAY indicate within their specification that they follow a "strict interpretation" of EAP. When requested by a method, "strict interpretation" causes the EAP implementation to impose inbound filter rules from the point where an initial Request is answered with a Response of the same Type, until the method completes. "Strict interpretation" also implies that on completion the peer method will indicate whether it succeeded (was able to authenticate the authenticator) or failed (did not succeed in authenticating the authenticator). An EAP method making use of "strict interpretation" MUST include a definition of completion for both the peer and authenticator, and also MUST indicate the conditions under which successful completion will be indicated. The filter rules are as follows: [a] On the peer, all EAP packets are silently discarded, except for those with Code=1 (Request) and Type=Method-Type. This implies that methods supporting "strict interpretation" do not utilize Notification, but instead support their own method-specific error messages. [b] On the peer, once the method completes unsuccessfully, the EAP conversation is terminated and the link is not enabled. If the conversation completes successfully, then EAP Failure packets are silently discarded. [c] On the EAP server, once the initial EAP Request is responded to with an EAP Response of the same Type, all EAP packets are silently discarded, except those with Code=2 (Response) and Type=EAP-Method-Type. Implementation note: While none of the methods defined in this document support strict interpretation, EAP-TLS [RFC2716] implementations SHOULD support strict interpretation." From aboba@internaut.com Mon Apr 14 19:42:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 14 Apr 2003 11:42:08 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 80: Success Indications Message-ID: Change the following text in Section 4.2 from: "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. If acknowledged success and failure indications are desired, these MAY be implemented within individual EAP methods." To: "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. If acknowledged success and failure indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." From aboba@internaut.com Mon Apr 14 19:44:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 14 Apr 2003 11:44:34 -0700 (PDT) Subject: [eap] Update on EAP Issues List Message-ID: Based on the discussions at IETF 56, I've updated the EAP issues list to reflect the proposed resolution of outstanding RFC 2284bis issues: http://www.drizzle.com/~aboba/EAP/eapissues.html Please have a look at the proposed resolutions and comment on them. Once these issues are resolved, RFC 2284bis will go to EAP WG last call, unless new issues arise. From Pasi.Eronen@nokia.com Tue Apr 15 19:50:29 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 15 Apr 2003 21:50:29 +0300 Subject: [eap] Re: Issue 104: Sequence prohibition Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122265@esebe023.ntc.nokia.com> Hi, Was this the consensus at IETF 56? The minutes aren't completely clear on this topic: issue 87 really refers=20 only to starting another method before the first one is=20 completed. Was the decision that not only type change=20 during one method is forbidden, but all sequences=20 (of methods >=3D4) are forbidden? (I'm not an fan of sequences myself, but we've been=20 working on the state machine diagrams with John, Nick and Yoshihiro, and the current versions are in rather good shape, and do support sequences. We can change them to forbid sequences if the consensus is that they must not be allowed.) Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, April 14, 2003 8:46 PM > To: eap@frascone.com > Subject: [eap] Issue 104: Sequence prohibition >=20 >=20 > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 14th, 2003 > Reference: > Document: EAP-01 > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue: >=20 > At IETF 56, it was proposed that sequences of EAP methods MUST NOT be > supported (with an exception for tunneled EAP methods). The=20 > following text > changes support that proposal. >=20 > Change Section 2.1 from: >=20 > " 2.1 Support for sequences >=20 > An EAP conversation MAY utilize a sequence of methods. A common > example of this is an Identity request followed by a single EAP > authentication method such as an MD5-Challenge. However, within or > associated with each EAP server, it is not anticipated that a > particular named peer will utilize multiple authentication methods > (Type 4 or greater), either by supporting a choice of methods or by > using multiple methods in sequence. This would make the peer > vulnerable to attacks that negotiate the least secure method from > among a set (negotiation attacks, described in Section 7.8) or > man-in-the-middle attacks (described in Section 7.4). Instead, for > each named peer there SHOULD be an indication of exactly one method > used to authenticate that peer name. If a peer needs to make use of > different authentication methods under different circumstances, then > distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. If additional authentication > methods are required beyond the initial one, the authenticator MAY > send a Request packet for a subsequent authentication method, or it > MAY send another Identity request. If the peer does not support > additional methods, it SHOULD respond with a Nak, indicating no > acceptable alternative, as described in Section 5.3. However, peer > implementations MAY not respond at all, in which case a timeout will > result and authentication will fail. Since the authenticator > presumably requires successful completion of the sequence in order to > grant access, authentication failure is the correct result. > Therefore, it is not necessary for the authenticator to determine > that the peer supports sequences prior to sending a Request for a > subsequent authentication method. >=20 > The above prescription also applies in the situation where an > authenticator sends a message of a different Type prior to completion > of the final round of a given method. If the peer wishes to continue > authenticating with the method in progress, it SHOULD send a Nak in > response to such a Request, indicating the Type in progress as the > alternative. Otherwise it MAY send a Response with the same Type as > the Request. Since an EAP packet with a different Type may be sent > by an attacker, an authenticator receiving a Nak including a > preference for the Type in progress SHOULD log the event, but > otherwise not take any action. >=20 > Once a peer has sent a Response of the same Type as a Request, some > existing peer implementations might expect the method to run to > completion. As a result, these implementations silently discard EAP > Requests of a Type different from the method in progress, despite the > requirement for a Response in Section 4.1. For this reason, EAP > authenticators that must interoperate with these peers are > discouraged from switching methods before the final round of a given > method has completed." >=20 > To: >=20 > "2.1 Support for sequences >=20 > An EAP conversation MAY utilize a sequence of methods. A common > example of this is an Identity request followed by a single EAP > authentication method such as an MD5-Challenge. However a peer > MUST utilize only one authentication method (Type 4 or greater) > within an EAP conversation. >=20 > Once a peer has sent a Response of the same Type as the initial > Request, an authenticator MUST NOT send a Request of a different Type > prior to completion of the final round of a given method, and > MUST NOT send a Request for an additional methods of any Type > after completion of the initial authentication method. >=20 > Supporting multiple authentication > methods within an EAP conversation would add complexity > to the EAP protocol, would enable man-in-the-middle attacks > (see Section 7.4), and would result in interoperablity problems, > since existing EAP implementations typically do not support > sequences. >=20 > If an additional authentication method is requested by the > authenticator, or if the authenticator sends a Request of > a different Type prior to completion of the final round of > a given method, the peer SHOULD silently discard the > Request. As an alternative, the peer MAY > respond with a Nak, indicating no acceptable alternative, > as described in Section 5.3. Since spoofed EAP > Request packets may be sent by an attacker, an > an authenticator receiving an unexpected Nak SHOULD log the > event. >=20 > The case where a single EAP authentication method is > utilized, but other methods are run inside it, does not > qualify as a sequence of EAP methods as defined here. Such > "tunneled" methods appear to the EAP state machine as a single > method. Backward compatibility can be provided, since a peer > not supporting a "tunneled" method can reply to the initial > EAP-Request with a Nak. To avoid adding man-in-the-middle > vulnerabilities, "tunneled" methods MUST support protection > against these attacks. >=20 > Within or associated with each EAP server, it is not anticipated > that a particular named pper will support a choice of methods. > This would make the peer vulnerable to attacks that negotiate the > least secure method from among a set (negotiation attacks, > described in Section 7.8). Instead, for > each named peer there SHOULD be an indication of exactly one method > used to authenticate that peer name. If a peer needs to make use of > different authentication methods under different circumstances, then > distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. " From alper@docomolabs-usa.com Wed Apr 16 02:17:55 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Tue, 15 Apr 2003 18:17:55 -0700 Subject: [eap] EAP Success/Failure: authentication or access control result? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA76@esebe023.ntc.nokia.com> Message-ID: I'd recommend we interpret EAP result as strictly for "authentication", and leave the "authorization" result to the EAP transport (e.g., 802.1x, PANA, PPP). I don't know if 802.1x and PPP can handle this, but PANA can. PANA has its own message type "PANA Success/Failure". This separation provides greater flexibility and better division of labor, imo. Alper On 3/31/03 12:12 AM, "Pasi.Eronen@nokia.com" wrote: > Hi, > > We had a conference call with John Vollbrecht and Nick Petroni > on Friday, and a couple of issues needing clarification came up. > Here's one of them (which seems to be related to several other > issues that came up, so let's deal with this one first). > > Does EAP Success (Failure) message mean that "I've (not) > succesfully authenticated you" or "I'm allowing (denying) > access"? That is, is it the authentication result or access > control result? > > In both 2284bis and 2869bis, it's always called authentication > result (e.g. 2284bis: "authentication conversation can continue > until the authenticator determines that successful > authentication has occurred, in which case the authenticator > MUST transmit an EAP Success"). 2284bis also mentions the > possibility of allowing access even though authentication > failed (in 7.9, "Implementation idiosyncrasies"). > > However, there are some parts in both documents that are not so > clear, and make more sense if you assume that it really should > be called access control result (or that the server has a policy > where the two are always the same). Note that RADIUS, for > instance, is quite clear about this: Access-Accept and Reject > are access control decisions, not authentication (and the two > don't have to be the same). > > What do others think, which should it be? > > (Although the "authentication result" seems more obvious, it has > some interesting consequences: for instance, the client should > then probably treat both EAP Success and Failure packets as > simply "EAP conversation ended" indication, and decide whether > to continue the link solely based on its local policy, even if > Failure was received). > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From jrv@umich.edu Wed Apr 16 02:22:38 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 15 Apr 2003 21:22:38 -0400 Subject: [eap] Re: Issue 104: Sequence prohibition In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122265@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122265@esebe023.ntc.nokia.com> Message-ID: <17160477.1050441758@[10.0.1.2]> I believe the discussion was that sequences would not be allowed except within a protected method. I think the requirement here is that "protected" variable be set that then allows sequences. We should add this to the state machine. John --On Tuesday, April 15, 2003 9:50 PM +0300 Pasi.Eronen@nokia.com wrote: > > Hi, > > Was this the consensus at IETF 56? The minutes aren't > completely clear on this topic: issue 87 really refers > only to starting another method before the first one is > completed. Was the decision that not only type change > during one method is forbidden, but all sequences > (of methods >=4) are forbidden? > > (I'm not an fan of sequences myself, but we've been > working on the state machine diagrams with John, Nick > and Yoshihiro, and the current versions are in rather > good shape, and do support sequences. We can change > them to forbid sequences if the consensus is > that they must not be allowed.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, April 14, 2003 8:46 PM > > To: eap@frascone.com > > Subject: [eap] Issue 104: Sequence prohibition > > > > > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: April 14th, 2003 > > Reference: > > Document: EAP-01 > > Comment type: T > > Priority: S > > Section: 2.1 > > Rationale/Explanation of issue: > > > > At IETF 56, it was proposed that sequences of EAP methods MUST NOT be > > supported (with an exception for tunneled EAP methods). The > > following text > > changes support that proposal. > > > > Change Section 2.1 from: > > > > " 2.1 Support for sequences > > > > An EAP conversation MAY utilize a sequence of methods. A common > > example of this is an Identity request followed by a single EAP > > authentication method such as an MD5-Challenge. However, within or > > associated with each EAP server, it is not anticipated that a > > particular named peer will utilize multiple authentication methods > > (Type 4 or greater), either by supporting a choice of methods or by > > using multiple methods in sequence. This would make the peer > > vulnerable to attacks that negotiate the least secure method from > > among a set (negotiation attacks, described in Section 7.8) or > > man-in-the-middle attacks (described in Section 7.4). Instead, for > > each named peer there SHOULD be an indication of exactly one method > > used to authenticate that peer name. If a peer needs to make use of > > different authentication methods under different circumstances, then > > distinct identities SHOULD be employed, each of which identifies > > exactly one authentication method. If additional authentication > > methods are required beyond the initial one, the authenticator MAY > > send a Request packet for a subsequent authentication method, or it > > MAY send another Identity request. If the peer does not support > > additional methods, it SHOULD respond with a Nak, indicating no > > acceptable alternative, as described in Section 5.3. However, peer > > implementations MAY not respond at all, in which case a timeout will > > result and authentication will fail. Since the authenticator > > presumably requires successful completion of the sequence in order to > > grant access, authentication failure is the correct result. > > Therefore, it is not necessary for the authenticator to determine > > that the peer supports sequences prior to sending a Request for a > > subsequent authentication method. > > > > The above prescription also applies in the situation where an > > authenticator sends a message of a different Type prior to completion > > of the final round of a given method. If the peer wishes to continue > > authenticating with the method in progress, it SHOULD send a Nak in > > response to such a Request, indicating the Type in progress as the > > alternative. Otherwise it MAY send a Response with the same Type as > > the Request. Since an EAP packet with a different Type may be sent > > by an attacker, an authenticator receiving a Nak including a > > preference for the Type in progress SHOULD log the event, but > > otherwise not take any action. > > > > Once a peer has sent a Response of the same Type as a Request, some > > existing peer implementations might expect the method to run to > > completion. As a result, these implementations silently discard EAP > > Requests of a Type different from the method in progress, despite the > > requirement for a Response in Section 4.1. For this reason, EAP > > authenticators that must interoperate with these peers are > > discouraged from switching methods before the final round of a given > > method has completed." > > > > To: > > > > "2.1 Support for sequences > > > > An EAP conversation MAY utilize a sequence of methods. A common > > example of this is an Identity request followed by a single EAP > > authentication method such as an MD5-Challenge. However a peer > > MUST utilize only one authentication method (Type 4 or greater) > > within an EAP conversation. > > > > Once a peer has sent a Response of the same Type as the initial > > Request, an authenticator MUST NOT send a Request of a different Type > > prior to completion of the final round of a given method, and > > MUST NOT send a Request for an additional methods of any Type > > after completion of the initial authentication method. > > > > Supporting multiple authentication > > methods within an EAP conversation would add complexity > > to the EAP protocol, would enable man-in-the-middle attacks > > (see Section 7.4), and would result in interoperablity problems, > > since existing EAP implementations typically do not support > > sequences. > > > > If an additional authentication method is requested by the > > authenticator, or if the authenticator sends a Request of > > a different Type prior to completion of the final round of > > a given method, the peer SHOULD silently discard the > > Request. As an alternative, the peer MAY > > respond with a Nak, indicating no acceptable alternative, > > as described in Section 5.3. Since spoofed EAP > > Request packets may be sent by an attacker, an > > an authenticator receiving an unexpected Nak SHOULD log the > > event. > > > > The case where a single EAP authentication method is > > utilized, but other methods are run inside it, does not > > qualify as a sequence of EAP methods as defined here. Such > > "tunneled" methods appear to the EAP state machine as a single > > method. Backward compatibility can be provided, since a peer > > not supporting a "tunneled" method can reply to the initial > > EAP-Request with a Nak. To avoid adding man-in-the-middle > > vulnerabilities, "tunneled" methods MUST support protection > > against these attacks. > > > > Within or associated with each EAP server, it is not anticipated > > that a particular named pper will support a choice of methods. > > This would make the peer vulnerable to attacks that negotiate the > > least secure method from among a set (negotiation attacks, > > described in Section 7.8). Instead, for > > each named peer there SHOULD be an indication of exactly one method > > used to authenticate that peer name. If a peer needs to make use of > > different authentication methods under different circumstances, then > > distinct identities SHOULD be employed, each of which identifies > > exactly one authentication method. " > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From florent.bersani@francetelecom.com Wed Apr 16 16:25:27 2003 From: florent.bersani@francetelecom.com (Florent Bersani) Date: Wed, 16 Apr 2003 17:25:27 +0200 Subject: [EAP] New Internet-Draft : EAP-Client-side Transport-00 Message-ID: <029301c3042c$68ba7c70$50a9c10a@pprof> This is a multi-part message in MIME format. ------=_NextPart_000_0290_01C3043D.2C3EB890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to annouce the first release of an Internet-Draft regarding EAP-Client-side Transport : http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt This document aims at defining an architecture for interoperable = client-side transport of authentication with EAP, that is to say the seamless use of "authentication tokens" (a mobile phone, a "smart" keychain, a PDA...) = for authenticating to remote services accessed from a PC. Such services = could include Wireless LANs, but we believe that it is a generic architecture principle. This architecture complements the usual setup considered in EAP by = making it become symmetric: the client-side is divided in two parts, the Authentication Token and the client, which are analogous respectively to = the Authentication Server and the Authenticator on the server-side. = Moreover, this document describes a framework for the use of Authentication Tokens with the EAP protocol. Beno=EEt de Boursetty and myself, as authors, would very much like you = to give us your opinion / comments / etc. on this draft. We are also looking forward to continuing the development of this = architecture in collaboration with anyone willing to join us. Many thanks in advance & best regards, Florent Bersani florent.bersani@francetelecom.com Beno=EEt de Boursetty benoit.deboursetty@francetelecom.com ------=_NextPart_000_0290_01C3043D.2C3EB890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I=20 would like to annouce the first release of an Internet-Draft=20 regarding
EAP-Client-side Transport :

http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.t= xt

This document aims at defining an = architecture for=20 interoperable client-side
transport of authentication with EAP, that = is to=20 say the seamless use of
"authentication tokens" (a mobile phone, a = "smart"=20 keychain, a PDA...) for
authenticating to remote services accessed = from a PC.=20 Such services could
include Wireless LANs, but we believe that it is = a=20 generic architecture
principle.

This architecture complements = the=20 usual setup considered in EAP by making it
become symmetric: the = client-side=20 is divided in two parts, the
Authentication Token and the client, = which are=20 analogous respectively to the
Authentication Server and the = Authenticator on=20 the server-side. Moreover,
this document describes a framework for = the use of=20 Authentication Tokens
with the EAP protocol.

Beno=EEt de = Boursetty and=20 myself, as authors, would very much like you to give
us your opinion = /=20 comments / etc. on this draft.
We are also looking forward to = continuing the=20 development of this architecture
in collaboration with anyone willing = to join=20 us.

Many thanks in advance & best regards,

Florent=20 Bersani
florent.bersani@francetelecom.com

Beno=EEt de Boursetty
benoit.deboursetty@francetelecom.com
= ------=_NextPart_000_0290_01C3043D.2C3EB890-- From TMaufer@nvidia.com Wed Apr 16 21:57:09 2003 From: TMaufer@nvidia.com (Thomas Maufer) Date: Wed, 16 Apr 2003 13:57:09 -0700 Subject: [eap] RE: 802.11i meeting Message-ID: <128D60D434C15C4ABE1A4E78E03BC1CF03607CDE@mail-sc-9.nvidia.com> ============ resending to eap mailing list ========================== David-- This is a friendly reminder so that people who are intending to be here but who have not yet RSVP'ed will let me know if they intend to be present. BTW, I added the teleconference information to the original e-mail below so that all the information pertinent to the meeting would be in one place. Thanks, Tom -----Original Message----- From: David Halasz [mailto:dhala@cisco.com] Sent: Thursday, April 03, 2003 13:39 To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: 802.11i meeting There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa Clara, CA. Hosted by NVIDIA. The purpose of the meeting is to continue addressing comments from letter ballot 52. There will also be a discussion about the pros/cons of splitting the PAR on April 22nd, from 1400-1530 PDT (2100-2230 GMT): Teleconference phone: +1 (408) 902-7862 Meeting ID: 6647389 The meeting will run from 9:00 a.m. to 5:00 p.m. each day at the NVIDIA campus, which is situated at the intersection of San Tomas Expressway and Walsh Avenue. Our postal address is: 2701 San Tomas Expressway Santa Clara, CA 95050 There is ample parking on the campus, and the parking lot has two entrances: One is reachable from the northbound direction of San Tomas, and the other is reachable via the eastbound direction of Walsh. This URL should display a map of the intersection: http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoNU58. jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&country=us Visitors will need to sign in with the receptionist in Building D, which is close to the intersection of San Tomas and Walsh, facing Walsh. If you plan to attend, please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From gwz@cisco.com Thu Apr 17 00:36:40 2003 From: gwz@cisco.com (Glen Zorn) Date: Wed, 16 Apr 2003 16:36:40 -0700 Subject: [eap] FW: 802.11i meeting Message-ID: <001401c30471$1b63b280$85964104@amer.cisco.com> FYI > -----Original Message----- > From: owner-ieee-802-11-tgi@rsa.com > [mailto:owner-ieee-802-11-tgi@rsa.com] On Behalf Of Thomas Maufer > Sent: Wednesday, April 16, 2003 12:58 PM > To: 'David Halasz' > Cc: stds-802-11@ieee.org; > ieee-802-11-tgi@majordomo.rsasecurity.com; > stds-802-1@ieee.org; eap@frascone.com > Subject: RE: 802.11i meeting > > > David-- > > This is a friendly reminder so that people who are intending > to be here but who have not yet RSVP'ed will let me know if > they intend to be present. > > BTW, I added the teleconference information to the original > e-mail below so that all the information pertinent to the > meeting would be in one place. > > Thanks, > Tom > > > -----Original Message----- > From: David Halasz [mailto:dhala@cisco.com] > Sent: Thursday, April 03, 2003 13:39 > To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; > stds-802-1@ieee.org; eap@frascone.com > Subject: 802.11i meeting > > > There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa > Clara, CA. Hosted > by NVIDIA. The purpose of the meeting is to continue > addressing comments > from letter ballot 52. There will also be a discussion about > the pros/cons > of splitting the PAR on April 22nd, from 1400-1530 PDT > (2100-2230 GMT): > > Teleconference phone: +1 (408) 902-7862 > Meeting ID: 6647389 > > The meeting will run from 9:00 a.m. to 5:00 p.m. each day at > the NVIDIA > campus, which is situated at the intersection of San Tomas > Expressway and > Walsh Avenue. Our postal address is: > > 2701 San Tomas Expressway > Santa Clara, CA 95050 > > There is ample parking on the campus, and the parking lot has two > entrances: One is reachable from the northbound direction of > San Tomas, and > the other is reachable via the eastbound direction of Walsh. > This URL > should display a map of the intersection: > http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoN U58. jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&countr y=us Visitors will need to sign in with the receptionist in Building D, which is close to the intersection of San Tomas and Walsh, facing Walsh. If you plan to attend, please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From jrv@umich.edu Thu Apr 17 19:44:48 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 17 Apr 2003 14:44:48 -0400 Subject: [eap] Issue 104: Sequence prohibition In-Reply-To: References: Message-ID: <902951.1050590688@[10.0.1.2]> I think this is fine. I would suggest dropping the last paragraph or adding it to a security appendix. --On Monday, April 14, 2003 10:45 AM -0700 Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 14th, 2003 > Reference: > Document: EAP-01 > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue: > > At IETF 56, it was proposed that sequences of EAP methods MUST NOT be > supported (with an exception for tunneled EAP methods). The following text > changes support that proposal. > > Change Section 2.1 from: > > " 2.1 Support for sequences > > An EAP conversation MAY utilize a sequence of methods. A common > example of this is an Identity request followed by a single EAP > authentication method such as an MD5-Challenge. However, within or > associated with each EAP server, it is not anticipated that a > particular named peer will utilize multiple authentication methods > (Type 4 or greater), either by supporting a choice of methods or by > using multiple methods in sequence. This would make the peer > vulnerable to attacks that negotiate the least secure method from > among a set (negotiation attacks, described in Section 7.8) or > man-in-the-middle attacks (described in Section 7.4). Instead, for > each named peer there SHOULD be an indication of exactly one method > used to authenticate that peer name. If a peer needs to make use of > different authentication methods under different circumstances, then > distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. If additional authentication > methods are required beyond the initial one, the authenticator MAY > send a Request packet for a subsequent authentication method, or it > MAY send another Identity request. If the peer does not support > additional methods, it SHOULD respond with a Nak, indicating no > acceptable alternative, as described in Section 5.3. However, peer > implementations MAY not respond at all, in which case a timeout will > result and authentication will fail. Since the authenticator > presumably requires successful completion of the sequence in order to > grant access, authentication failure is the correct result. > Therefore, it is not necessary for the authenticator to determine > that the peer supports sequences prior to sending a Request for a > subsequent authentication method. > > The above prescription also applies in the situation where an > authenticator sends a message of a different Type prior to completion > of the final round of a given method. If the peer wishes to continue > authenticating with the method in progress, it SHOULD send a Nak in > response to such a Request, indicating the Type in progress as the > alternative. Otherwise it MAY send a Response with the same Type as > the Request. Since an EAP packet with a different Type may be sent > by an attacker, an authenticator receiving a Nak including a > preference for the Type in progress SHOULD log the event, but > otherwise not take any action. > > Once a peer has sent a Response of the same Type as a Request, some > existing peer implementations might expect the method to run to > completion. As a result, these implementations silently discard EAP > Requests of a Type different from the method in progress, despite the > requirement for a Response in Section 4.1. For this reason, EAP > authenticators that must interoperate with these peers are > discouraged from switching methods before the final round of a given > method has completed." > > To: > > "2.1 Support for sequences > > An EAP conversation MAY utilize a sequence of methods. A common > example of this is an Identity request followed by a single EAP > authentication method such as an MD5-Challenge. However a peer > MUST utilize only one authentication method (Type 4 or greater) > within an EAP conversation. > > Once a peer has sent a Response of the same Type as the initial > Request, an authenticator MUST NOT send a Request of a different Type > prior to completion of the final round of a given method, and > MUST NOT send a Request for an additional methods of any Type > after completion of the initial authentication method. > > Supporting multiple authentication > methods within an EAP conversation would add complexity > to the EAP protocol, would enable man-in-the-middle attacks > (see Section 7.4), and would result in interoperablity problems, > since existing EAP implementations typically do not support > sequences. > > If an additional authentication method is requested by the > authenticator, or if the authenticator sends a Request of > a different Type prior to completion of the final round of > a given method, the peer SHOULD silently discard the > Request. As an alternative, the peer MAY > respond with a Nak, indicating no acceptable alternative, > as described in Section 5.3. Since spoofed EAP > Request packets may be sent by an attacker, an > an authenticator receiving an unexpected Nak SHOULD log the > event. > > The case where a single EAP authentication method is > utilized, but other methods are run inside it, does not > qualify as a sequence of EAP methods as defined here. Such > "tunneled" methods appear to the EAP state machine as a single > method. Backward compatibility can be provided, since a peer > not supporting a "tunneled" method can reply to the initial > EAP-Request with a Nak. To avoid adding man-in-the-middle > vulnerabilities, "tunneled" methods MUST support protection > against these attacks. > > Within or associated with each EAP server, it is not anticipated > that a particular named pper will support a choice of methods. > This would make the peer vulnerable to attacks that negotiate the > least secure method from among a set (negotiation attacks, > described in Section 7.8). Instead, for > each named peer there SHOULD be an indication of exactly one method > used to authenticate that peer name. If a peer needs to make use of > different authentication methods under different circumstances, then > distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. " > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Fri Apr 18 12:47:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 18 Apr 2003 04:47:45 -0700 (PDT) Subject: [eap] Issue 105: Multiplexing Clarification Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 17th, 2003 Reference: Document: EAP-01 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: Section 2.2 does not describe how EAP packets are forwarded by a pass-through authenticator. This is an area where there are known interoperability problems (e.g. pass-through authenticators that cannot handle any EAP method). Change: "2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE.802-1X.2001]; IEEE 802.11 wireless LANs [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements the EAP state machine, and delivers and receives EAP messages to and from EAP methods. [c] EAP method. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP layer. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. Within EAP, the Type field functions much like a port number in UDP or TCP. With the exception of Types handled by the EAP layer, it is assumed that the EAP layer multiplexes incoming EAP packets according to their Type, and delivers them only to the EAP method corresponding to that Type code, with one exception. Since EAP methods may wish to access the Identity, the Identity Response can be assumed to be stored within the EAP layer so as to be available to methods of Types other than 1 (Identity). The Identity Type is discussed in Section 5.1. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | ! | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Layer | | EAP ! Layer | | ! | | ! | | (Nak, ! Success, | | (Nak, ! Success, | | ! Failure, | | ! Failure, | | ! Notification, | | ! Notification, | | ! Identity) | | ! Identity) | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! Layer | | Lower ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! +------------>-------------+ Figure 1: EAP Multiplexing Model A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. The Nak method is utilized for the purposes of method negotiation. Peers MUST respond to an EAP Request for an unacceptable Type with a Nak Response. It cannot be assumed that the contents of the Nak Response is available to another method. The Nak Type is discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response and Notification Request/Response messages MUST NOT used to carry data destined for delivery to EAP authentication Types (4 or greater)." To: "2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE.802-1X.2001]; IEEE 802.11 wireless LANs [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements the EAP state machine, and delivers and receives EAP messages to and from EAP methods. [c] EAP method. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP layer. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Layer | | EAP ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! Layer | | Lower ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Type field functions much like a port number in UDP or TCP. With the exception of Types handled by the EAP layer, it is assumed that the EAP layer multiplexes incoming EAP packets according to their Type, and delivers them only to the EAP method corresponding to that Type code, with one exception. Since EAP methods may wish to access the Identity, the Identity Response can be assumed to be stored within the EAP layer so as to be available to methods of Types other than 1 (Identity). The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. The Nak method is utilized for the purposes of method negotiation. Peers MUST respond to an EAP Request for an unacceptable Type with a Nak Response (legacy or expanded). It cannot be assumed that the contents of the Nak Response is available to another method. The Nak Type is discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response and Notification Request/Response messages MUST NOT used to carry data destined for delivery to other EAP methods. Where a pass-through authenticator is present, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP header fields (Code, Identifier, Length). Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method header fields (Type, Type-Data) are not examined as part of the forwarding decision. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method. +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | Layer | | Layer | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | |EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer| | ! | | +-----+---------+ | | ! | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!Layer| |Lower!Layer| AAA/IP ! | |Lower!Layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ ! ! ! ! ! Peer ! Pass-through ! Auth.!Server +-------->-----+ +----->----+ Figure 2: Pass-through Authenticator" From TMaufer@nvidia.com Tue Apr 22 05:14:13 2003 From: TMaufer@nvidia.com (Thomas Maufer) Date: Mon, 21 Apr 2003 21:14:13 -0700 Subject: [eap] 802.11i ad-hoc meeting -- final details -- I M P O R T A N T Message-ID: <128D60D434C15C4ABE1A4E78E03BC1CF03607D33@mail-sc-9.nvidia.com> The instructions below have now been updated! Please report to the entrance of Building _A_ tomorrow morning. Identify yourself as being with the IEEE meeting. Building A is also near the intersection of Walsh and San Tomas, but Building A faces San Tomas. Feel free to use any nearby parking, including visitor parking. After entering the lobby, sign in with Security and you will be escorted to the room where the meeting will be held. Please do not attend if you didn't already RSVP, we're going to be quite densely packed as it is. I know who you are. ;-) I look forward to seeing you tomorrow, Tom p.s. FYI, food will be provided all three days (breakfast, hot lunch, snacks). -----Original Message----- From: Thomas Maufer Sent: Wednesday, 16 April, 2003 12:58 To: 'David Halasz' Cc: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: RE: 802.11i meeting David-- This is a friendly reminder so that people who are intending to be here but who have not yet RSVP'ed will let me know if they intend to be present. BTW, I added the teleconference information to the original e-mail below so that all the information pertinent to the meeting would be in one place. Thanks, Tom -----Original Message----- From: David Halasz [mailto:dhala@cisco.com] Sent: Thursday, April 03, 2003 13:39 To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; stds-802-1@ieee.org; eap@frascone.com Subject: 802.11i meeting There is an 802.11i "Ad-Hoc" April 22, 23 & 24 in Santa Clara, CA. Hosted by NVIDIA. The purpose of the meeting is to continue addressing comments from letter ballot 52. There will also be a discussion about the pros/cons of splitting the PAR on April 22nd, from 1400-1530 PDT (2100-2230 GMT): Teleconference phone: +1 (408) 902-7862 Meeting ID: 6647389 The meeting will run from 9:00 a.m. to 5:00 p.m. each day at the NVIDIA campus, which is situated at the intersection of San Tomas Expressway and Walsh Avenue. Our postal address is: 2701 San Tomas Expressway Santa Clara, CA 95050 There is ample parking on the campus, and the parking lot has two entrances: One is reachable from the northbound direction of San Tomas, and the other is reachable via the eastbound direction of Walsh. This URL should display a map of the intersection: http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=svoRO.p_0ToRzfYIjQwQmxwDEoNU58. jmDi_RnGyDzG2CbJwGS3jka01EPS3x6M-&csz=santa%20clara,%20ca%2095050&country=us Visitors will need to sign in with the Security office in Building A, which is close to the intersection of San Tomas and Walsh, facing San Tomas. Due to the overwhelming response to this meeting, no more people can be accommodated. Please respond by sending an email to Thomas Maufer at TMaufer@nvidia.com Dave H. Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From henrik@levkowetz.com Tue Apr 22 18:03:39 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 22 Apr 2003 19:03:39 +0200 Subject: [eap] New intermediate 2284bis draft: 02.c Message-ID: <20030422190339.441ff1f7.henrik@levkowetz.com> Hi, A new intermediate rfc2284bis draft is available at http://www.levkowetz.com/pub/ietf/drafts/eap/ , numbered -02.c . There's: A slight revision of Appendix A.1 text [Issue 74 revisited]. The implementation note in Section 4.2 is updated with respect to success indications [Issue 80]. A revision of the Section 2, item [3], text regarding EAP being a lock-step protocol. [Issue 94 revisited]. A changed Section 4.2.1 and added Section 7.14; regarding strict interpretation [Issue 97]. New text for Section 2.1, regarding support for sequences [Issue 104] Regards, Henrik -- Cheops' Law: Nothing ever gets built on schedule or within budget. From jari.arkko@piuha.net Wed Apr 23 13:39:53 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 23 Apr 2003 15:39:53 +0300 Subject: [eap] non-keygen methods & binding problem draft Message-ID: <3EA68999.5010206@piuha.net> Bernard and I were discussing potential solutions for the binding problem with the "worst case" legacy EAP methods. These methods are such which don't generate session keys. During this discussion, it became apparent that draft-puthenkulam-eap-binding-02.txt could perhaps be improved by adding more details about this case. Specifically, Section 3.2 rule S2 states the following: Guarantee that the same peer credential is never usable inside and outside a tunnel using server and client policy. This prevents condition CC-A. This solution actually works for all methods, but is sometimes hard to deploy, due to legacy deployments, and since clients and servers need to be synchronized for proper policy enforcement. An additional problem with this solution is the manageability issues due to the multiple credentials that have to be managed by the same client and server. and then later: S2 is realizable just using policy techniques on the client and server ends. In Section 3.3 the non-key generating method issue is expanded a bit: [1] Providing separate credentials for a user identity supported inside and outside tunnels. ... [2] Enforce client and server policy to always use authentication methods inside tunnels. ... For non-key deriving methods, if they are modifiable, then using a signal to indicate when they are running inside a tunnel would also prevent the attack. This works because the server is able to distinguish between an attacker diverting a method into a tunnel versus a client method intentionally initiated inside a tunnel. However such signals need protection from spoofing. The case of non-key deriving methods is an important one. Both PIC and IKEv2 have large user groups interested in running existing password-based methods. Our concern is that the above description does not fully describe the possibilities available for these users. Namely, the problem is that there has been some confusion about exactly what it means to support "legacy authentication". For example, are we trying to support 1. "Password authentication" i.e. the use of existing passwords in a new context? or 2. Are we trying to support existing methods, e.g. CHAP? It seems that the main interest is *not* supporting legacy authentication methods, since today EAP support is available on virtually all shipping servers, including FreeRADIUS. Therefore, all devices will be able to support EAP, and intermediate devices will be able to support any method. We believe that the issue is rather supporting legacy credentials, such as passwords or token cards. If so, it may be possible to keep the credentials as they are but replace the existing method with a modified one when running inside a tunnel (or within EAP). When running outside tunnels, use the existing method as-is. There appears to be key generating variants available for many of the popular legacy credentials. For instance, the existing passwords for dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2, which can generate keys. The choice between the variant is easy as long as both the authentication method and the tunnel endpoints are in the same nodes, because then both nodes know whether a tunnel is being used. Similarly, the same credentials could be used inside the tunnel even without key generation if the authentication method is changed slightly. For instance, using "password" as the password outside the tunnel and SHA1("password") as the password inside the tunnel. This would appear to prevent the man-in-the-middle attack. These types of solutions may be necessary in order to deal with legacy credentials that currently don't generate keys, and with tunneling protocols that can't be changed easily. As an example of the latter, changing HTTP/TLS to take in account compound keys may be hard but the "password"/SHA("password") trick may be easier to do within HTTP Digest running inside HTTP/TLS. Does this make sense? If yes, perhaps some of the aspects from the above should be discussed in the draft. --Jari From Hannes.Tschofenig@siemens.com Thu Apr 24 12:01:28 2003 From: Hannes.Tschofenig@siemens.com (Hannes Tschofenig) Date: Thu, 24 Apr 2003 13:01:28 +0200 Subject: [eap] EAP IKEv2 Method Message-ID: <00cd01c30a50$db0fc0d0$010aa8c0@joe> hi all, some time ago we submitted a new eap method (EAP IKEv2) for publication. unfortunately the draft is not yet available at the official ietf draft directory. if you would like to read the draft already please then please take a look at: http://www.tschofenig.com/drafts/draft-tschofenig-eap-ikev2-00.txt ciao hannes From jari.arkko@piuha.net Thu Apr 24 12:30:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 24 Apr 2003 14:30:47 +0300 Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: References: Message-ID: <3EA7CAE7.70207@piuha.net> Ok, but nits inline: > "2.2 EAP multiplexing model > > Conceptually, EAP implementations consist of the following > components: > > [a] Lower layer. The lower layer is responsible for transmitting and > receiving EAP frames between the peer and authenticator. EAP has > been run over a variety of lower layers including PPP; wired IEEE > 802 LANs [IEEE.802-1X.2001]; IEEE 802.11 wireless LANs > [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); and > TCP [PIC]. Lower layer behavior is discussed in Section 3. > > [b] EAP layer. The EAP layer receives and transmits EAP packets via > the lower layer, implements the EAP state machine, and delivers > and receives EAP messages to and from EAP methods. > > [c] EAP method. EAP methods implement the authentication algorithms > and receive and transmit EAP messages via the EAP layer. Since > fragmentation support is not provided by EAP itself, this is the > responsibility of EAP methods, which are discussed in Section 5. > > The EAP multiplexing model is illustrated in figure 1 below. Note > that there is no requirement that an implementation conform to this > model, as long as the on-the-wire behavior is consistent with it. > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | > | EAP method| EAP method| | EAP method| EAP method| > | Type = X | Type = Y | | Type = X | Type = Y | > | V | | | ^ | | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! Layer | | EAP ! Layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | Lower ! Layer | | Lower ! Layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > ! ! > ! Peer ! Authenticator > +------------>-------------+ (You used tabs on some lines and spaces on others, better use one consistently. Could show up as a difference in some cases.) > Figure 1: EAP Multiplexing Model > > Within EAP, the Type field functions much like a port number in UDP > or TCP. With the exception of Types handled by the EAP layer, it is > assumed that the EAP layer multiplexes incoming EAP packets according > to their Type, and delivers them only to the EAP method corresponding > to that Type code, with one exception. > > Since EAP methods may wish to access the Identity, the Identity > Response can be assumed to be stored within the EAP layer so as to be > available to methods of Types other than 1 (Identity). The Identity > Type is discussed in Section 5.1. > > A Notification Response is only used as confirmation that the peer > received the Notification Request, not that it has processed it, or > displayed the message to the user. It cannot be assumed that the > contents of the Notification Request or Response is available to > another method. The Notification Type is discussed in Section 5.2. > > The Nak method is utilized for the purposes of method negotiation. > Peers MUST respond to an EAP Request for an unacceptable Type with > a Nak Response (legacy or expanded). It cannot be assumed that > the contents of the Nak Response is available to another method. > The Nak Type is discussed in Section 5.3. > > EAP packets with codes of Success or Failure do not include a Type, > and therefore are not delivered to an EAP method. Success and Failure > are discussed in Section 4.2. > > Given these considerations, the Success, Failure, Nak Response and > Notification Request/Response messages MUST NOT used to carry data s/used/be used/ > destined for delivery to other EAP methods. > > Where a pass-through authenticator is present, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP header fields (Code, Identifier, s/EAP header/EAP layer header/ ? > Length). Since pass-through authenticators rely on a backend > authenticator server to implement methods, the EAP method s/EAP method header/EAP method layer header/ ? > header fields (Type, Type-Data) are not examined as part of > the forwarding decision. The forwarding model is illustrated > in Figure 2. Compliant pass-through authenticator implementations > MUST by default be capable of forwarding packets from any EAP method. > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | > |EAP method | |EAP method | > | Layer | | Layer | > | V | | ^ | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | | | | ! | > |EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer| > | ! | | +-----+---------+ | | ! | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!Layer| |Lower!Layer| AAA/IP ! | |Lower!Layer| > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ > ! ! ! ! > ! Peer ! Pass-through ! Auth.!Server > +-------->-----+ +----->----+ How about this instead: Peer Pass-through Auth.Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | Layer | | Layer | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | | EAP !Layer| | EAP Layer | EAP Layer | | EAP !Layer| | ! | | +-----+-----+ | | ! | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! | +-------->-----+ +------->------+ --Jari From jari.arkko@piuha.net Thu Apr 24 13:28:52 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 24 Apr 2003 15:28:52 +0300 Subject: [eap] EAP IKEv2 Method In-Reply-To: <00cd01c30a50$db0fc0d0$010aa8c0@joe> References: <00cd01c30a50$db0fc0d0$010aa8c0@joe> Message-ID: <3EA7D884.7020901@piuha.net> Hannes, Dirk, Thank you for your contribution. An interesting new method! A few comments after the first quick read: * I found it funny that you list "support of legacy authentication" as one of the improvements in IKEv2 ;-) Seriously though, the introduction of your document should be more clear about the scope of the protocol. This appears to be: (1) use a well known IKEv2 shared/cert authentication, AND (2) provide a new EAP tunneling method All in all, this would be quite a super method by any standards! Shared secrets, certs, CRL exchange, and EAP tunneling in a single method. At the very least, you should have a requirement that implementations MUST check they don't perform infinite recursion just because the bad guy offers to run EAP and IKEv2 in a looping fashion against it ;-) * Section 1 talks about phases, but I believe the adopted IKEv2 term is "exchange". I think your intention is to use the IKE_SA_INIT and IKE_AUTH exchanges? * I believe SAi2, SAr2, TSi, TSr are mandatory in IKE_AUTH exchange currently. So this is one case where you have to deviate from the IKEv2 specification? Should be listed at the start of Section 3, I think. * I don't understand the statement "... differs from IKEv2 only in the computation of the AUTH payload. For symmetric authentication no CERT and CERTREQ payloads are required." Is the latter statement the difference? Anyway, in IKEv2 thees payloads are optional so you may not need to state this. * s/provides information where the protocol messages described below terminate/provides information about the identities of the EAP endpoints/ * The discussion of identities probably deserves its own section. I suspect the current scheme is quite complex, and might benefit from simplification e.g. by requiring that some of the identities either be either omitted or are always the same as some other identities. FYI: Figure 3 example and some of the text in Section 3 is in conflict with the IKEv2 requirement that EAP identity requests should not be used (section 3.16 of ikev2-07). * "To counter this threat IKEv2 provides a compound authentication by including the EAP provided session key inside the AUTH payload." To my knowledge IKEv2 does this only for methods that provide session keys. Note that it does not currently specify anything meaningful (imho) for non-key-generating methods. * Open issue on fragmentation: IKEv2 does not need to worry about fragmentation because lower layer provides that (well, there are debates about that too). However, in EAP we do not provide fragmentation at the lower layer, at least not in all contexts where EAP is used. So it seems like you do need to handle fragmentation, and extend the packet format accordingly. Or? * Open issue on cert revokation. Wouldn't it be easiest to follow IKEv2? Is there a specific need to do OCSP in this protocol which does not exist for IKEv2? (Perhaps the lack of network access by the time EAP is typically run could be one such reason...) Jari From aboba@internaut.com Thu Apr 24 14:01:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 24 Apr 2003 06:01:35 -0700 (PDT) Subject: [eap] "Pseudo-WG last call" on draft-aboba-radius-rfc2869bis-20.txt Message-ID: RFC 2869bis has completed IETF last call and has incorporated last call comments. To make sure that there are not any lingering issues, we are going to hold a "Pseudo-WG last call" on RFC 2869bis, since it relates to EAP (although it is not an EAP WG work item). After addressing comments from "Pseudo-WG last call" we will pass RFC 2869bis to the IESG for publication as an Informational RFC. The document is now available on the IETF archive: http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-20.txt "Pseudo" WG last call will run until Monday, May 12, 2003. Please send any comments to the authors, and CC: the EAP WG mailing list (eap@frascone.com) using the EAP Issues format found at: http://www.drizzle.com/~aboba/EAP/eapissues.html From aboba@internaut.com Thu Apr 24 14:05:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 24 Apr 2003 06:05:52 -0700 (PDT) Subject: [eap] WG last call on draft-ietf-eap-rfc2284bis-02.txt Message-ID: This is an announcement of EAP WG last call on RFC2284bis-02. Once comments from EAP WG last call are incorporated, the document will be passed on to the IESG for consideration as an IETF Proposed Standard. The document will be available on the IETF archive by Monday at this location: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-02.txt EAP WG last call will run until Monday, May 12, 2003. Please send any comments to the authors, and CC: the EAP WG mailing list (eap@frascone.com) using the EAP Issues format found at: http://www.drizzle.com/~aboba/EAP/eapissues.html From jrv@umich.edu Thu Apr 24 16:00:17 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 24 Apr 2003 11:00:17 -0400 Subject: [eap] EAP State Machines Draft Message-ID: <6177879.1051182017@[10.0.1.2]> In case this didn't get posted some other way, a new Internet Draft " State Machines for EAP Peer and Authenticator" - draft-vollbrecht-eap-state-02 has been sent to the ietf draft repository. This draft includes state machines for EAP Peer, Authenticator, Passthrough Method and "Backend Adapter". It describes a way of implementing EAP with a common state machine in the Authenticator (or Access Point/NAS) and Backend Server. The draft is also available from http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-02.html and http://www.cs.umd.edu/~npetroni/EAP/ has pointers to the draft in text and postscript format. The draft is very graphic oriented, with the actual state machines diagrams being the central focus - so the html or ps version is best for reading. The Diagrams are also available on http://www.cs.umd.edu/~npetroni/EAP/. The work on this was done by Nick Petroni, Pasi Eronen, Yoshihiro Ohba and myself. We would like this to become an EAP working group document with review and update in the EAP wg. Comments and questions are welcome and can be directed to the authors or to the EAP list eap@frascone.com. From yohba@tari.toshiba.com Wed Apr 23 15:39:20 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 23 Apr 2003 07:39:20 -0700 Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: <3EA7CAE7.70207@piuha.net> References: <3EA7CAE7.70207@piuha.net> Message-ID: <20030423143920.GA2301@steelhead> On Thu, Apr 24, 2003 at 02:30:47PM +0300, Jari Arkko wrote: > > > > > >+-+-+-+-+-+-+ +-+-+-+-+-+-+ > >| | | | > >|EAP method | |EAP method | > >| Layer | | Layer | > >| V | | ^ | > >+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > >| ! | | | | | ! | > >|EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer| > >| ! | | +-----+---------+ | | ! | > >| ! | | ! | ! | | ! | > >+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ > >| ! | | ! | ! | | ! | > >|Lower!Layer| |Lower!Layer| AAA/IP ! | |Lower!Layer| > >| ! | | ! | ! | | ! | > >+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-!-+ +-+-+-!-+-+-+ > > ! ! ! ! > > ! Peer ! Pass-through ! Auth.!Server > > +-------->-----+ +----->----+ > > How about this instead: > > Peer Pass-through Auth.Server > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | > |EAP method | |EAP method | > | Layer | | Layer | > | V | | ^ | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | | | | ! | > | EAP !Layer| | EAP Layer | EAP Layer | | EAP !Layer| > | ! | | +-----+-----+ | | ! | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > ! ! ! ! > ! ! ! | > +-------->-----+ +------->------+ > > --Jari > I think these passthrough model figures are misleading because those gives an impression that the NAS acts as an EAP peer for the backend EAP server while it acts as an EAP authenticator for the real EAP peer. But actually the NAS does not need to have an EAP peer functionality at all. Instead of this model, the latest state machine draft introduces a different model based on using a special "passthough method" for NAS. The model can be illustrated below. Peer Pass-through Auth.Server +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | |EAP method | | Passthrough mechanism | |EAP method | | Layer | | +-----------+ | | Layer | | V | | ! ! | | ^ | +-+-+-!-+-+-+ +-+-+-!-+-+-+ ! | +-+-+-!-+-+-+ | ! | | ! | ! | | ! | | EAP !Layer| | EAP !Layer| ! | | EAP !Layer| | ! | | ! | ! | | ! | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! | +-------->-----+ +------->------+ Note that I don't want to use the term "passthrough method" in RFC2284bis, since the definition of passthrough method is specific to the state machine draft and other implementations are possible without being based on the state machine draft as long as on-the-wire behavior satisfies the EAP specification. That is why I use "passthrough mechanism" instead of "passthrough method". Make sense? Yoshihiro Ohba From aboba@internaut.com Thu Apr 24 17:31:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 24 Apr 2003 09:31:25 -0700 (PDT) Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: <20030423143920.GA2301@steelhead> References: <3EA7CAE7.70207@piuha.net> <20030423143920.GA2301@steelhead> Message-ID: > I think these passthrough model figures are misleading because those > gives an impression that the NAS acts as an EAP peer for the backend > EAP server while it acts as an EAP authenticator for the real EAP > peer. But actually the NAS does not need to have an EAP peer > functionality at all. The pass-through does validate EAP layer headers (Code, Identifier, Length), much as a peer would. For example, it looks at the Code field to see if it is appropriate in both directions; checks or stores state from the Identifier and checks the Length. So I'm not sure that this is misleading -- unless there is some EAP layer peer functionality that you believe that the pass-through does not do. Can you be more specific? > Instead of this model, the latest state machine draft introduces a > different model based on using a special "passthough method" for NAS. > The model can be illustrated below. > > > Peer Pass-through Auth.Server > > +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | | | > |EAP method | | Passthrough mechanism | |EAP method | > | Layer | | +-----------+ | | Layer | > | V | | ! ! | | ^ | > +-+-+-!-+-+-+ +-+-+-!-+-+-+ ! | +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > | EAP !Layer| | EAP !Layer| ! | | EAP !Layer| > | ! | | ! | ! | | ! | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > ! ! ! ! > ! ! ! | > +-------->-----+ +------->------+ This figure suggests that the pass-through authenticator acts on EAP method headers (Type, Type-Code). This is typically not the case. Pass-through functionality is not a method. Much like a router forwards IP packets but doesn't terminate TCP connections, an EAP pass-through forwards EAP packets but doesn't terminate method conversations. Since we've had interoperability problems relating to this issue where pass-through authenticators are unable to handle all EAP methods, we've had to clarify this in the spec. The figure above would be likely to confuse implementers. > > Note that I don't want to use the term "passthrough method" in > RFC2284bis, since the definition of passthrough method is specific to > the state machine draft and other implementations are possible without > being based on the state machine draft as long as on-the-wire behavior > satisfies the EAP specification. That is why I use "passthrough > mechanism" instead of "passthrough method". Introducing new terminology in the state machine draft probably isn't a good idea. From yohba@tari.toshiba.com Wed Apr 23 17:33:52 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 23 Apr 2003 09:33:52 -0700 Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: References: <3EA7CAE7.70207@piuha.net> <20030423143920.GA2301@steelhead> Message-ID: <20030423163352.GB2931@steelhead> On Thu, Apr 24, 2003 at 09:31:25AM -0700, Bernard Aboba wrote: > > I think these passthrough model figures are misleading because those > > gives an impression that the NAS acts as an EAP peer for the backend > > EAP server while it acts as an EAP authenticator for the real EAP > > peer. But actually the NAS does not need to have an EAP peer > > functionality at all. > > The pass-through does validate EAP layer headers (Code, Identifier, > Length), much as a peer would. For example, it looks at the Code field to > see if it is appropriate in both directions; checks or stores state from > the Identifier and checks the Length. So I'm not sure that this is > misleading -- unless there is some EAP layer peer functionality that you > believe that the pass-through does not do. Can you be more specific? EAP layer peer does not have a functionality to forward EAP packets to EAP layer authenticator or to AAA client in the same physical box. If the NAS were to have the EAP layer peer functionality, it is not allowed to pass a duplicate Request to some other entity other than returning the copy of the original Response that was sent in response to the original Request. This does not allow the following bahavior described in RFC2869bis: "A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [DynAuth] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response." > > > Instead of this model, the latest state machine draft introduces a > > different model based on using a special "passthough method" for NAS. > > The model can be illustrated below. > > > > > > Peer Pass-through Auth.Server > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ > > | | | | | | > > |EAP method | | Passthrough mechanism | |EAP method | > > | Layer | | +-----------+ | | Layer | > > | V | | ! ! | | ^ | > > +-+-+-!-+-+-+ +-+-+-!-+-+-+ ! | +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > | EAP !Layer| | EAP !Layer| ! | | EAP !Layer| > > | ! | | ! | ! | | ! | > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > ! ! ! ! > > ! ! ! | > > +-------->-----+ +------->------+ > > This figure suggests that the pass-through authenticator acts on EAP > method headers (Type, Type-Code). This is typically not the case. > Pass-through functionality is not a method. Much like a router forwards IP > packets but doesn't terminate TCP connections, an EAP pass-through > forwards EAP packets but doesn't terminate method conversations. Since > we've had interoperability problems relating to this issue where > pass-through authenticators are unable to handle all EAP methods, we've > had to clarify this in the spec. The figure above would be likely to > confuse implementers. I'm not sure how it would confuse implementers. If we discuss based on the analogy to TCP/IP stack, the figure above is comparative with the following figure (this example is based on email access via SSH-based VPN) : enterprise email enterprise email server VPN gateway client +----+ +-------------------+ +---------------+ |POP3| | SSH port- | | POP3 | +----+ +----+ forwarding | +---------------+ |TCP | |TCP | mechanism | | TCP | +----+ +----+--------------+ +---------------+ | IP | | IP |SSH/SSL/TCP/IP| | SSH/SSL/TCP/IP| +----+ +----+--------------+ +---------------+ > > > > Note that I don't want to use the term "passthrough method" in > > RFC2284bis, since the definition of passthrough method is specific to > > the state machine draft and other implementations are possible without > > being based on the state machine draft as long as on-the-wire behavior > > satisfies the EAP specification. That is why I use "passthrough > > mechanism" instead of "passthrough method". > > Introducing new terminology in the state machine draft probably isn't a > good idea. This part can be separately discussed. Yoshihiro Ohba From aboba@internaut.com Thu Apr 24 22:07:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 24 Apr 2003 14:07:24 -0700 (PDT) Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: <20030423163352.GB2931@steelhead> References: <3EA7CAE7.70207@piuha.net> <20030423143920.GA2301@steelhead> <20030423163352.GB2931@steelhead> Message-ID: > > The pass-through does validate EAP layer headers (Code, Identifier, > > Length), much as a peer would. For example, it looks at the Code field to > > see if it is appropriate in both directions; checks or stores state from > > the Identifier and checks the Length. So I'm not sure that this is > > misleading -- unless there is some EAP layer peer functionality that you > > believe that the pass-through does not do. Can you be more specific? > > EAP layer peer does not have a functionality to forward EAP packets to > EAP layer authenticator or to AAA client in the same physical box. True. On the other hand, an IP router doesn't act like a host on both interfaces. For example, an IP router typically won't support reassembly of IP fragments not addressed to it at the IP layer, so that it could be argued that a similar diagram shouldn't show a router operating on the IP layer. My advice would be to clarify the text rather than the figure -- the figure is meant to show what EAP layers the pass-through authenticator operates on, not to indicate each layer as a monolithic entity that is handled exactly the same on all entities. The major point being made is that pass-through authenticators don't forward based on EAP method headers. > If the NAS were to have the EAP layer peer functionality, it is not > allowed to pass a duplicate Request to some other entity other than > returning the copy of the original Response that was sent in response > to the original Request. This does not allow the following bahavior > described in RFC2869bis: Correct. I think your comment underlines that perhaps we are not 100% clear on what operations a pass-through authenticator performs on an EAP packet before forwarding. For example, it might be argued that the NAS should behave the same as the peer in this case. > I'm not sure how it would confuse implementers. If we discuss based > on the analogy to TCP/IP stack, the figure above is comparative with > the following figure (this example is based on email access via > SSH-based VPN) : > > enterprise > email enterprise email > server VPN gateway client > > +----+ +-------------------+ +---------------+ > |POP3| | SSH port- | | POP3 | > +----+ +----+ forwarding | +---------------+ > |TCP | |TCP | mechanism | | TCP | > +----+ +----+--------------+ +---------------+ > | IP | | IP |SSH/SSL/TCP/IP| | SSH/SSL/TCP/IP| > +----+ +----+--------------+ +---------------+ Not sure this is analagous because SSH gateways terminate traffic at the application layer whereas pass-through authenticators don't look at EAP message layer headers. Also, don't SSH gateways use TCP on both interfaces? So why is TCP present at different layers of the stack in each of the entities in the diagram? From yohba@tari.toshiba.com Wed Apr 23 21:39:11 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 23 Apr 2003 13:39:11 -0700 Subject: [eap] Issue 105: Multiplexing Clarification In-Reply-To: References: <3EA7CAE7.70207@piuha.net> <20030423143920.GA2301@steelhead> <20030423163352.GB2931@steelhead> Message-ID: <20030423203911.GA17811@steelhead> On Thu, Apr 24, 2003 at 02:07:24PM -0700, Bernard Aboba wrote: > > > The pass-through does validate EAP layer headers (Code, Identifier, > > > Length), much as a peer would. For example, it looks at the Code field to > > > see if it is appropriate in both directions; checks or stores state from > > > the Identifier and checks the Length. So I'm not sure that this is > > > misleading -- unless there is some EAP layer peer functionality that you > > > believe that the pass-through does not do. Can you be more specific? > > > > EAP layer peer does not have a functionality to forward EAP packets to > > EAP layer authenticator or to AAA client in the same physical box. > > True. On the other hand, an IP router doesn't act like a host on both > interfaces. For example, an IP router typically won't support > reassembly of IP fragments not addressed to it at the IP layer, so that it > could be argued that a similar diagram shouldn't show a router operating > on the IP layer. My advice would be to clarify the text rather than the > figure -- the figure is meant to show what EAP layers the pass-through > authenticator operates on, not to indicate each layer as a monolithic > entity that is handled exactly the same on all entities. The major point > being made is that pass-through authenticators don't forward based > on EAP method headers. I think text-only is ok if it is diffucult to draw a perfect figure that does not confuse people at all. > > If the NAS were to have the EAP layer peer functionality, it is not > > allowed to pass a duplicate Request to some other entity other than > > returning the copy of the original Response that was sent in response > > to the original Request. This does not allow the following bahavior > > described in RFC2869bis: > > Correct. I think your comment underlines that perhaps we are not 100% > clear on what operations a pass-through authenticator performs on an EAP > packet before forwarding. For example, it might be argued that the NAS > should behave the same as the peer in this case. Yes (and I believe that the state machine draft can help understand and clarify the behavior of pass-through authenticator). > > > I'm not sure how it would confuse implementers. If we discuss based > > on the analogy to TCP/IP stack, the figure above is comparative with > > the following figure (this example is based on email access via > > SSH-based VPN) : > > > > enterprise > > email enterprise email > > server VPN gateway client > > > > +----+ +-------------------+ +---------------+ > > |POP3| | SSH port- | | POP3 | > > +----+ +----+ forwarding | +---------------+ > > |TCP | |TCP | mechanism | | TCP | > > +----+ +----+--------------+ +---------------+ > > | IP | | IP |SSH/SSL/TCP/IP| | SSH/SSL/TCP/IP| > > +----+ +----+--------------+ +---------------+ > > Not sure this is analagous because SSH gateways terminate traffic at the > application layer whereas pass-through authenticators don't look at > EAP message layer headers. > Also, don't SSH gateways use TCP on both > interfaces? So why is TCP present at different layers of the stack in > each of the entities in the diagram? OK, the ssh example was not a good example. Please ignore the example. Yoshihiro Ohba From henrik@levkowetz.com Fri Apr 25 10:36:56 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 25 Apr 2003 11:36:56 +0200 Subject: [eap] Missing subsection 5.x on Experimental Type Message-ID: <20030425113656.3c8d58df.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: April 25, 2003 Document: EAP-02.c Comment type: E Priority: 1 Section: 5 Rationale/Explanation of issue: Going over the draft to compile a list of changes compared with rfc 2284, I've noticed that we lack a subsection to section 5 which says something about type 255, Experimental use. What about: 5.8 Experimental Description The Experimental Type has no fixed format or content. It is intended for use when experimenting with new EAP types. This type MUST NOT be used for regular deployment of draft features. Type 255 Type-Data Undefined Henrik -- Basic research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun From henrik@levkowetz.com Fri Apr 25 11:42:11 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 25 Apr 2003 12:42:11 +0200 Subject: [eap] Issue: Changes Appendix Message-ID: <20030425124211.58099350.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: April 25, 2003 Document: EAP-02.c Comment type: E Priority: S Section: Appendix B Rationale/Explanation of issue: Our appendix B (Changes from RFC 2284) is incomplete. Below is proposed text for this section: ---- Appendix B. Changes from RFC 2284 This section lists the major changes between [RFC2284] and this document. Minor changes, including style, grammar, spelling and editorial changes are not mentioned here. o The Terminology section (Section 1.2) has been expanded, defining more concepts and giving more exact definitions. o In Section 2, it is explicitly specified that more than one exchange of Request and Response packets may occur as part of the EAP authentication exchange. How this may and may not be used is specified in detail in Section 2.1. o Also in Section 2, some requirements on the authenticator when acting in pass-through mode has been made explicit. o An EAP multiplexing model (Section 2.2) has been added, to illustrate a typical implementation of EAP. There is no requirement that an implementation conforms to this model, as long as the on-the-wire behavior is consistent with it. o As EAP is now in use with a variety of lower layers, not just PPP for which it was first designed, Section 3 on lower layer behavior has been added. o In the description of the EAP Request and Response interaction (Section 4.1), it has been more exactly specified when packets should be silently discarded, and also the behavior on receiving duplicate requests. The implementation notes in this section has been substantially expanded. o In Section 4.2, it has been clarified that Success and Failure packets must not contain additional data, and the implementation note has been expanded. A sub-section giving requirements on processing of success and failure packets has been added. o Section 5 on EAP Request/Response Types lists two new type values: the Expanded type (Section 5.7), which is used to expand the type value number space, and the Experimental type. In the Expanded type number space, the new Expanded Nak (Section 5.3.2) type has been added. Clarifications have been made in the description of most of the existing types. Security claims summaries has been added for authentication methods. o An IANA Considerations section (Section 6) has been added, giving registration policies for the numbering spaces defined for EAP. o The Security Considerations (Section 7) have been greatly expanded, aiming at giving a much more comprehensive coverage of possible threaths and other security considerations. ---- Henrik -- "For NASA, space is still a high priority." -- J. Danforth Quayle, 9/5/90 From benoit.deboursetty@francetelecom.com Fri Apr 25 13:51:21 2003 From: benoit.deboursetty@francetelecom.com (=?iso-8859-1?Q?DE_BOURSETTY_Beno=EEt_FTRD/DTL/ISS?=) Date: Fri, 25 Apr 2003 14:51:21 +0200 Subject: [eap] Issue: Downgrading attacks on lower-layer ciphersuite negotiation Message-ID: Hi, I'm not sure this comment bears on the latest version of the draft. = Apologies if this point has been raised already. Best, Beno=EEt de Boursetty France Telecom R&D benoit.deboursetty@francetelecom.com / +33-1-4529-5926 Downgrading attacks on lower-layer ciphersuite negotiation Submitter name: Benoit de Boursetty Submitter email address: benoit.deboursetty@francetelecom.com Date first submitted: April 25, 2003 Document: draft-ietf-eap-rfc2284bis-01.txt Comment type: T Priority: 1 Section: 7.1 and 7.11 Rationale/Explanation of issue:=20 In section 3.1 on lower layer requirements, requirement 2 indicates a = need for physically insecure links to be used with per-packet integrity, = authentication and replay protection.=20 Although the problem of downgrading attack on EAP method negotiation is = identified in 7.8, I cannot find word about the issue of downgrading = attacks on ciphersuite negotiation for the lower layer ciphersuite. = However there is mention of weak lower-layer ciphersuites being a threat = to security, at least in section 7.1 #8 and in section 7.11. I understand that in actual cases deployed now, there is no or little = lower layer ciphersuite negotiation. But to take an example, = self-admittedly PPP's MPPE is currently vulnerable to downgrading = attacks (cf. par. 2, section 9 of RFC 3078) and there is no proposed = workaround (apart from explicit client configuration). Another way to function is that parts of the keying material resulting = from EAP can be used by the link layer to authenticate a negotiation = handshake afterwards (I would have thought Auth-RECV-Key and = Auth-SEND-Key, but according to the new Keying Framework draft I'm not = so sure). In the short term, I suggest mentioning the issue in the Security = Considerations section, as well as the workaround of using EAP-provided = keying material to enable negotiation integrity protection ex-post. In the longer term, it could be desirable that the lower-layer = handshakes be integrity-verified during EAP authentication, as a = "handshake integrity checking service" offered by some EAP methods -- = just as they can provide now mutual authentication, keying material = generation etc. This is left to the consideration of the EAP charter. In the meantime: Suggested changes:=20 Section 7.1: adding point 9 following point 8: "[9]. An attacker may attempt to perform downgrading attacks on = link-level ciphersuite negotiation in order to ensure that a weaker = ciphersuite is used subsequently to EAP authentication." Section 7.11: adding following paragraph at the end of the section: "Additionally, if the lower layer performs ciphersuite negotiation, it = should be understood that EAP does not provide by itself integrity = protection of that negotiation. Therefore, in order to avoid downgrading = attacks which would lead to weaker ciphersuites being used, clients = implementing lower layer ciphersuite negotiation SHOULD protect against = negotiation downgrading. This can be done by enabling users to configure which are the acceptable = ciphersuites as a matter of security policy; or, the ciphersuite = negotiation MAY be authenticated using keying material derived from the = EAP authentication and a MAC algorithm agreed upon in advance by = lower-layer peers." From benoit.deboursetty@francetelecom.com Fri Apr 25 13:52:49 2003 From: benoit.deboursetty@francetelecom.com (=?iso-8859-1?Q?DE_BOURSETTY_Beno=EEt_FTRD/DTL/ISS?=) Date: Fri, 25 Apr 2003 14:52:49 +0200 Subject: [eap] Issue: Attacker or Adversary? Message-ID: Submitter name: Benoit de Boursetty Submitter email address: benoit.deboursetty@francetelecom.com Date first submitted: April 25, 2003 Document: draft-ietf-eap-rfc2284bis-01.txt Comment type: E Priority: 1 Section: 7.1 Rationale/Explanation of issue: In section 7.1, the word "adversary" and "attacker" are both used to = talk about the same kind of person. It is the only place in the draft = where "adversary" is used, every where else the word "attacker" is used. = Also all issues are "[attacker|adversary] may" but number 4 is a "might" = (offline attacks). Does it really seem less likely than other attacks? Suggested Change: Unless the above is a subtlety beyond my grasping of the English = language: s/adversary/attacker/ s/might/may/ in issue 4 From jari.arkko@piuha.net Fri Apr 25 14:18:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 25 Apr 2003 16:18:40 +0300 Subject: [eap] Issue: Changes Appendix In-Reply-To: <20030425124211.58099350.henrik@levkowetz.com> References: <20030425124211.58099350.henrik@levkowetz.com> Message-ID: <3EA935B0.8060503@piuha.net> Looks very good, though I'm not sure this covers everything. Perhaps we should go through the issue list and look at each issue to figure out what technical changes have gone in to the draft. What about sequences, lock-step, strictness, Nak of identity, to mention a few -- or are some of these covered in the bullet item about 4.1? Anyway, I think the text you posted is good enough for -02. A few nits below. > Appendix B. Changes from RFC 2284 > > This section lists the major changes between [RFC2284] and this > document. Minor changes, including style, grammar, spelling and > editorial changes are not mentioned here. Might be an idea to separate functional changes from (major) document changes such as the addition of IANA or security considerations sections. > o The Terminology section (Section 1.2) has been expanded, defining > more concepts and giving more exact definitions. > > o In Section 2, it is explicitly specified that more than one > exchange of Request and Response packets may occur as part of the > EAP authentication exchange. How this may and may not be used is > specified in detail in Section 2.1. > > o Also in Section 2, some requirements on the authenticator when > acting in pass-through mode has been made explicit. > > o An EAP multiplexing model (Section 2.2) has been added, to > illustrate a typical implementation of EAP. There is no > requirement that an implementation conforms to this model, as long > as the on-the-wire behavior is consistent with it. > > o As EAP is now in use with a variety of lower layers, not just PPP > for which it was first designed, Section 3 on lower layer behavior > has been added. > > o In the description of the EAP Request and Response interaction > (Section 4.1), it has been more exactly specified when packets > should be silently discarded, and also the behavior on receiving > duplicate requests. The implementation notes in this section has > been substantially expanded. > > o In Section 4.2, it has been clarified that Success and Failure > packets must not contain additional data, and the implementation > note has been expanded. A sub-section giving requirements on subsection? > processing of success and failure packets has been added. > > o Section 5 on EAP Request/Response Types lists two new type values: > the Expanded type (Section 5.7), which is used to expand the type > value number space, and the Experimental type. In the Expanded > type number space, the new Expanded Nak (Section 5.3.2) type has > been added. Clarifications have been made in the description of > most of the existing types. Security claims summaries has been > added for authentication methods. s/has/have/ > o An IANA Considerations section (Section 6) has been added, giving > registration policies for the numbering spaces defined for EAP. > > o The Security Considerations (Section 7) have been greatly > expanded, aiming at giving a much more comprehensive coverage of > possible threaths and other security considerations. s/threaths/threats/ From jari.arkko@piuha.net Fri Apr 25 14:23:02 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 25 Apr 2003 16:23:02 +0300 Subject: [eap] Missing subsection 5.x on Experimental Type In-Reply-To: <20030425113656.3c8d58df.henrik@levkowetz.com> References: <20030425113656.3c8d58df.henrik@levkowetz.com> Message-ID: <3EA936B6.6030801@piuha.net> Ok, but some details inline: Henrik Levkowetz wrote: > Submitter name: Henrik Levkowetz > Submitter email address: henrik@levkowetz.com > Date first submitted: April 25, 2003 > Document: EAP-02.c > Comment type: E > Priority: 1 > Section: 5 > Rationale/Explanation of issue: > > Going over the draft to compile a list of changes compared with rfc 2284, > I've noticed that we lack a subsection to section 5 which says something > about type 255, Experimental use. What about: > > 5.8 Experimental > > Description > > The Experimental Type has no fixed format or content. It is > intended for use when experimenting with new EAP types. This type > MUST NOT be used for regular deployment of draft features. The last part of the sentence sounds a bit strange. How about something like "This type is intended for experimental and testing purposes. No guarantee is made for interoperability between peers using this type, as outlined in [IANA-EXP]." [IANA-EXP] T. Narten, "Assigning Experimental and Testing Numbers Considered Useful", IETF Work in Progress. > > Type > > 255 > > Type-Data > > Undefined > > > > > Henrik > From henrik@levkowetz.com Fri Apr 25 14:32:39 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 25 Apr 2003 15:32:39 +0200 Subject: [eap] Issue: Changes Appendix In-Reply-To: <3EA935B0.8060503@piuha.net> References: <20030425124211.58099350.henrik@levkowetz.com> <3EA935B0.8060503@piuha.net> Message-ID: <20030425153239.46032d8e.henrik@levkowetz.com> Thanks, Jari. Some comments inline. On Fri, 25 Apr 2003 16:18:40 +0300 Jari Arkko wrote: > > Looks very good, though I'm not sure this covers everything. > Perhaps we should go through the issue list and look at each > issue to figure out what technical changes have gone in to > the draft. What about sequences, lock-step, strictness, > Nak of identity, to mention a few -- or are some of these > covered in the bullet item about 4.1? Sequences and lock-step is covered in the second bullet. Nak of identity is covered in the bullet about section 5, but very invisibly ,:-). I think it would be good to do a list of the technical changes based on the issues, Yes. > > Anyway, I think the text you posted is good enough for -02. > A few nits below. > > > Appendix B. Changes from RFC 2284 > > > > This section lists the major changes between [RFC2284] and this > > document. Minor changes, including style, grammar, spelling and > > editorial changes are not mentioned here. > > Might be an idea to separate functional changes from (major) document > changes such as the addition of IANA or security considerations sections. Ok. Next time 'round. > > > o The Terminology section (Section 1.2) has been expanded, defining > > more concepts and giving more exact definitions. > > > > o In Section 2, it is explicitly specified that more than one > > exchange of Request and Response packets may occur as part of the > > EAP authentication exchange. How this may and may not be used is > > specified in detail in Section 2.1. > > > > o Also in Section 2, some requirements on the authenticator when > > acting in pass-through mode has been made explicit. > > > > o An EAP multiplexing model (Section 2.2) has been added, to > > illustrate a typical implementation of EAP. There is no > > requirement that an implementation conforms to this model, as long > > as the on-the-wire behavior is consistent with it. > > > > o As EAP is now in use with a variety of lower layers, not just PPP > > for which it was first designed, Section 3 on lower layer behavior > > has been added. > > > > o In the description of the EAP Request and Response interaction > > (Section 4.1), it has been more exactly specified when packets > > should be silently discarded, and also the behavior on receiving > > duplicate requests. The implementation notes in this section has > > been substantially expanded. > > > > o In Section 4.2, it has been clarified that Success and Failure > > packets must not contain additional data, and the implementation > > note has been expanded. A sub-section giving requirements on > > subsection? Fixed. > > > processing of success and failure packets has been added. > > > > o Section 5 on EAP Request/Response Types lists two new type values: > > the Expanded type (Section 5.7), which is used to expand the type > > value number space, and the Experimental type. In the Expanded > > type number space, the new Expanded Nak (Section 5.3.2) type has > > been added. Clarifications have been made in the description of > > most of the existing types. Security claims summaries has been > > added for authentication methods. > > s/has/have/ Fixed. > > > o An IANA Considerations section (Section 6) has been added, giving > > registration policies for the numbering spaces defined for EAP. > > > > o The Security Considerations (Section 7) have been greatly > > expanded, aiming at giving a much more comprehensive coverage of > > possible threaths and other security considerations. > > s/threaths/threats/ Fixed. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- "If we don't succeed, we run the risk of failure." -- J. Danforth Quayle From henrik@levkowetz.com Fri Apr 25 14:40:08 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 25 Apr 2003 15:40:08 +0200 Subject: [eap] Missing subsection 5.x on Experimental Type In-Reply-To: <3EA936B6.6030801@piuha.net> References: <20030425113656.3c8d58df.henrik@levkowetz.com> <3EA936B6.6030801@piuha.net> Message-ID: <20030425154008.3271cfc9.henrik@levkowetz.com> On Fri, 25 Apr 2003 16:23:02 +0300 Jari Arkko wrote: > Ok, but some details inline: > > Henrik Levkowetz wrote: > > Submitter name: Henrik Levkowetz > > Submitter email address: henrik@levkowetz.com > > Date first submitted: April 25, 2003 > > Document: EAP-02.c > > Comment type: E > > Priority: 1 > > Section: 5 > > Rationale/Explanation of issue: > > > > Going over the draft to compile a list of changes compared with rfc 2284, > > I've noticed that we lack a subsection to section 5 which says something > > about type 255, Experimental use. What about: > > > > 5.8 Experimental > > > > Description > > > > The Experimental Type has no fixed format or content. It is > > intended for use when experimenting with new EAP types. This type > > MUST NOT be used for regular deployment of draft features. > > The last part of the sentence sounds a bit strange. How about something > like "This type is intended for experimental and testing purposes. No > guarantee is made for interoperability between peers using this type, > as outlined in [IANA-EXP]." > > [IANA-EXP] T. Narten, "Assigning Experimental and Testing Numbers > Considered Useful", IETF Work in Progress. Ok, changing the last sentence. Yes, I considered refering to this draft, but decided not to as this can stand pretty much on it's own. Henrik -- The dinosaurs became extinct because they didn't have a space program. - Larry Niven And if we become extinct because we don't have a space program, it'll serve us right! - AC Clark From aboba@internaut.com Fri Apr 25 16:53:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 25 Apr 2003 08:53:02 -0700 (PDT) Subject: [eap] RFC 2284bis-02 Now Available Message-ID: RFC 2284bis-02 has been submitted to the IETF archive. The document is available here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-02.txt An HTML version is available here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-02.html The RFC 2284bis editor's web page is available here: http://www.levkowetz.com/pub/ietf/drafts/eap/ Issues should be summitted to the EAP WG mailing list (eap@frascone.com) using the format described on the EAP Issues Web page: http://www.drizzle.com/~aboba/EAP/eapissues.html From aboba@internaut.com Sat Apr 26 21:27:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 13:27:42 -0700 (PDT) Subject: [eap] Issue 110: Miscellaneous NITs Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: E Priority: 1 Section: Various Rationale/Explanation of issue: Throughout the document: EAP Methods => EAP methods Method Type => method Type type => Type local users => local peers pass through => pass-through expanded Type => Expanded Type method- specific => method-specific Authenticator => authenticator First page: Expiration and submission dates are wrong. should be April 2003 submission and October 2003 expiration. Please change in the header and Status of this Memo sections. Abstract is somewhat awkward. Change to: "This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B." Rewrite the first paragraph of Section 1 to: "This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this." In third paragraph of section 1: "specific authenticaiton mechanism(s) to be used" => "specific authentication method to be used" "some or all methods and users" => "some or all methods and peers" Last paragraph of Section 2.1 "Without or associated..." should be moved to section 7.8 after the last paragraph there. Section 3.2 "Authentication- Protocol" => "Authentication Protocol" "back- end server" => "backend authentication server" Section 3.2.1 "the EAP Authentication Protocol" => "EAP" "PPP Extensible Authentication Protocol" => "Extensible Authentication Protocol" Section 3.4 Last paragraph "In IEEE 802.11 a..." should be moved to after the last paragraph of 7.12. Section 2.2, figure 2: The "!" symbols are not aligned correctly -- they need to be moved to the right 3 spaces. Section 4.2.1: "Processing of success and failure" should be "Processing of Success and Failure" Section 5.3.2 under Identifier "a Expanded Nak Response" => "an Expanded Nak Response" Section 5.7, under "Vendor-Type" "If Vendor-Id is zero" => "If the Vendor-Id is zero" Section 8: Please change to the following: "This protocol derives much of its inspiration from Dave Carrel's AHA draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback was provided by Yoshihiro Ohba of Toshiba America Research, Jari Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Payne of the University of Maryland, Steve Bellovin of AT&T Research, Paul Funk of Funk Software and Pasi Eronen of Nokia." Informative References [RFC2869] version is now 20, date is April 2003. Appendix A.1 "a fatal error.." => "a fatal error." "a MIC validation failures" => "a MIC validation failure" Appendix B, please add the following paragraphs: "o In Section 5.5, support for OTP Extended Responses [RFC2243] has been added to EAP OTP. o Appendix A has been added on method-specific behavior, providing guidance on how EAP method-specific integrity checks should be processed." From aboba@internaut.com Sat Apr 26 22:15:06 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 14:15:06 -0700 (PDT) Subject: [eap] Issue 111: Lower Layer Requirements Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 3.1 Rationale/Explanation of issue: This section says that a a lower layer CRC or checksum is not necessary, but if it is absent there will be problems. Rewrite the section to the following: "3.1 Lower layer requirements EAP makes the following assumptions about lower layers: [1] Unreliable transport. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines it own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer. Note that EAP Success and Failure packets are not retransmitted. Without a reliable lower layer, and a non-negligible error rate, these packets can be lost, resulting in timeouts. It is therefore desirable for implementations to improve their resilience to loss of EAP Success or Failure packets, as described in Section 4.2. [2] Lower layer error detection. While EAP does not assume that the lower layer is reliable, it does rely on lower layer error detection. EAP methods may not include a MIC, or if they do, it may not be run over all the fields in the EAP packet, such as the Code, Identifier, Length or Type fields. As a result, without lower layer error detection, undetected errors could creep into the EAP layer header or EAP method header fields, resulting in authentication failures. For example, EAP TLS [RFC2716], which computes its MIC only over the Type-Data field, regards MIC validation failures as a fatal error. Without lower layer error detection, this method and others like it will not perform reliably. [3] Lower layer security. EAP assumes that lower layers either provide physical security for data (e.g. wired PPP or IEEE 802 links) or support per-packet authentication, integrity and replay protection. EAP SHOULD NOT be used on physically insecure links (e.g. wireless) where per-packet authentication, integrity and replay protection is unavailable. After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Alternatively, the lower layer needs to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked, or replayed. Where keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus it may only be possible to use the lower layer ciphersuite to protect a portion of the EAP conversation, such as the EAP Success or Failure packet. [4] MTU known a-priori. The EAP layer does not support fragmentation and reassembly. However, EAP methods SHOULD be capable of handling fragmentation and reassembly. As a result, EAP is capable of functioning across a range of MTU sizes, as long as the MTU is known a-priori. EAP does not support path MTU discovery. [5] Possible duplication. Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement. The Identifier field provides both the peer and authenticator with the ability to detect duplicates. [6] Ordering guarantees. EAP does not require the Identifier to be monotonically increasing, and so is reliant on lower layer ordering guarantees for correct operation. EAP was originally defined to run on PPP, and [RFC1661] Section 1 has an ordering requirement: "The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full- duplex simultaneous bi-directional operation, and are assumed to deliver packets in order." Lower lower transports for EAP MUST preserve ordering between a source and destination, at a given priority level (the ordering guarantee provided by [IEEE.802.1990])." From aboba@internaut.com Sat Apr 26 22:43:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 14:43:54 -0700 (PDT) Subject: [eap] Issue 112: Rewrite of IANA Considerations Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 6.2 Rationale/Explanation of issue: It is desirable to require a published RFC for EAP methods, if possible. Rewrite Section 6.2 to the following: "For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. Packet Codes have a range from 1 to 255, of which 1-4 have been allocated. Because a new Packet Code has considerable impact on interoperability, a new Packet Code requires Standards Action, and should be allocated starting at 5. The original EAP Method Type space has a range from 1 to 255, and is the scarcest resource in EAP, and thus must be allocated with care. Method Types 1-41 have been allocated, with 20 available for re-use. Method Types 42-191 may be allocated on the advice of a Designated Expert, with Specification Required. Allocation of blocks of Method Types (more than one for a given purpose) should require IETF Consensus. EAP Type Values 192-253 are reserved and allocation requires Standards Action. Method Type 254 is allocated for the Expanded Type. Where the Vendor-Id field is non-zero, the Expanded Type is used for functions specific only to one vendor's implementation of EAP, where no interoperability is deemed useful. When used with a Vendor-Id of zero, Method Type 254 can also be used to provide for an expanded IETF Method Type space. Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated. Method Type 255 is allocated for Experimental use, such as testing of new EAP methods before a permanent Type code is allocated." From aboba@internaut.com Sat Apr 26 23:56:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 15:56:29 -0700 (PDT) Subject: [eap] Issue 113: Rewrite of Security Considerations Section Message-ID: Issue 113: Rewrite of Security Considerations Section Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: 1 Section: 7 Rationale/Explanation of issue: Given changes in the key framework and sequence support, the security considerations section needs to be updated. See the issues list for complete suggested text: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 113 From aboba@internaut.com Sun Apr 27 01:27:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 17:27:18 -0700 (PDT) Subject: [eap] Issue 114: Terminology fixes Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 1.2 Rationale/Explanation of issue: Some terms aren't defined in the terminology section and there some minor cleanup to do. Change: "authenticator The end of the EAP link initiating the EAP authentication methods. [Note: This terminology is also used in [IEEE.802-1X.2001], and has the same meaning in this document]. peer The end of the EAP Link that responds to the authenticator. [Note:In [IEEE.802-1X.2001], this end is known as the Supplicant.] backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP Methods for the authenticator. [This terminology is also used in [IEEE.802-1X.2001].] " To: " authenticator The end of the EAP link initiating EAP authentication. The term Authenticator is used in [IEEE.802-1X.2001], and has the same meaning in this document. peer The end of the EAP Link that responds to the authenticator. In [IEEE.802-1X.2001], this end is known as the Supplicant. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE.802-1X.2001]." Change: " Key derivation This refers to the ability of the EAP method to derive a Master Key which is not exported, as well as a ciphersuite- independent Master Session Keys. Both the Master Key and Master Session Keys are used only for further key derivation, not directly for protection of the EAP conversation or subsequent data." To: " Key derivation This refers to the ability of the EAP method to derive a Master Key (MK) which is not exported, as well as exportable keying material such as the Master Session Key (MSK), Extended Master Session Key (EMSK) and (optionally) an Initialization Vector (IV). The MK, MSK and IV are used only for further key derivation, not directly for protection of the EAP conversation or subsequent data. Use of the EMSK is reserved." Change: "Man-in-the-Middle resistance The ability for the peer to demonstrate to the authenticator that it has acted as the peer for each method within the conversation. Similarly, the authenticator demonstrates to the peer that it has acted as the authenticator for each method within the conversation. If this is not possible, then the authentication sequence or tunnel may be vulnerable to a man-in-the-middle attack." To: "Man-in-the-Middle resistance The ability for the peer to demonstrate to the authenticator that it has acted as the peer for each authentication method within the conversation. Similarly, the authenticator demonstrates to the peer that it has acted as the authenticator for each authentication method within the conversation. If this is not possible, then the authentication sequence or tunnel may be vulnerable to a man-in-the-middle attack." Change: " Acknowledged result indications The ability of the authenticator to provide the peer with an indication of whether the peer has successfully authenticated to it, and for the peer to acknowledge receipt, as well as providing an indication of whether the authenticator has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method- specific result exchange that is integrity protected." To: " Acknowledged result indications The ability of the authenticator to provide the peer with an indication of whether the peer has successfully authenticated to it, and for the peer to acknowledge receipt, as well as providing an indication of whether the authenticator has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis." Add the following definitions: "Cryptographic binding The demonstration of the EAP peer to the EAP server that a single entity has acted as the EAP peer for all methods executed within a sequence or tunnel. Binding MAY also imply that the EAP server demonstrates to the peer that a single entity has acted as the EAP server for all methods executed within a sequence or tunnel. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. Cryptographic separation Two keys (x and y) are "cryptographically separate" if an adversary that knows all messages exchanged in the protocol cannot compute x from y or y from x without "breaking" some cryptographic assumption. In particular, this definition allows that the adversary has the knowledge of all nonces sent in cleartext as well as all predictable counter values used in the protocol. Breaking a cryptographic assumption would typically require inverting a one- way function or predicting the outcome of a cryptographic pseudo- random number generator without knowledge of the secret state. In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x, but the work an adversary must do to perform this computation is equivalent to performing exhaustive search for the secret state value." EAP Master key (MK) A key derived between the EAP client and server during the EAP authentication process that is purely local to the EAP method. The MK MUST NOT be exported from the EAP method or be made available to a third party. Since derivation of the MK is a residue of the successful completion of the EAP authentication exchange, proof of MK possession may be used to shorten future EAP exchanges between the same EAP client and server, a technique known as "fast resume". Master Session Key (MSK) Keying material (64 octets) that is derived between the EAP client and server. The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. Where a backend authentication server is present, acting as an EAP server, it will typically transport the MSK to the authenticator. The MSK differs from the MK in that it not assumed to remain local to the EAP method, and is known by all parties in the EAP exchange: the peer, authenticator and the authentication server (if present). The MSK MAY be derived from the MK via a one-way function, or it may be an independent quantity. However possession of the MSK MUST NOT provide any information useful in determining the MK. Extended Master Session Key (EMSK) Additional keying material (64 octets) derived between the EAP client and server that is not assumed to remain local to the EAP method. However, unlike the MSK, the EMSK is known only to the EAP client and server and MUST NOT be provided to a third party. The EMSK therefore MUST NOT be transported by the backend authentication server to the authenticator. The EMSK is reserved for future uses that are not defined yet. For example, it could be used to derive additional keying material for purposes such as fast handoff, man-in-the-middle vulnerability protection, etc. " From aboba@internaut.com Sun Apr 27 01:41:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 17:41:21 -0700 (PDT) Subject: [eap] Issue 115: Multiplexing fixes Message-ID: Issue 115: EAP multiplexing fixes Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: It is necessary to clarify what aspects of on the wire behavior are determined by the EAP layer versus other layers. Also, the sharing of Identity Request as well as Response info could be made more clear. Finally it is somewhat confusing to talk about method implemented in the EAP layer. Change: " [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements the EAP state machine, and delivers and receives EAP messages to and from EAP methods." To: " [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission and delivers and receives EAP messages to and from EAP methods." Change: "Within EAP, the Type field functions much like a port number in UDP or TCP. With the exception of Types handled by the EAP layer, it is assumed that the EAP layer multiplexes incoming EAP packets according to their Type, and delivers them only to the EAP method corresponding to that Type code, with one exception. Since EAP methods may wish to access the Identity, the Identity Response can be assumed to be stored within the EAP layer so as to be available to methods of Types other than 1 (Identity). The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. The Nak method is utilized for the purposes of method negotiation. Peers MUST respond to an EAP Request for an unacceptable Type with a Nak Response (legacy or expanded). It cannot be assumed that the contents of the Nak Response is available to another method. The Nak Type is discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. Where a pass-through authenticator is present, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method." To: "Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP layer multiplexes incoming EAP packets according to their Type, and delivers them only to the EAP method corresponding to that Type code. Since EAP authentication methods may wish to access the Identity, the Identity Request and Response can be assumed to be accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to an authentication method. The Notification Type is discussed in Section 5.2. The Nak method is utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (legacy or expanded). It cannot be assumed that the contents of the Nak Response is available to another method. The Nak Type is discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. Where an authenticator operates as a pass-through, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method." From aboba@internaut.com Sun Apr 27 02:02:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 18:02:49 -0700 (PDT) Subject: [eap] Issue 116: Success and Failure fixes Message-ID: Issue 116: Success and Failure fixes Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 4.2, 4.2.1 Rationale/Explanation of issue: Delete Section 4.2.1 and change Section 4.2 to: "4.2 Success and Failure The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater), to indicate that the peer has authenticated successfully to the authenticator. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then after unsuccessful completion of the EAP method in progress, the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. Success and Failure packets MUST NOT contain additional data. EAP Success or Failure packets MUST NOT be sent by an authenticator prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. 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. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 3 for Success 4 for Failure Identifier The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to. Length 4" From aboba@internaut.com Sun Apr 27 02:16:23 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 26 Apr 2003 18:16:23 -0700 (PDT) Subject: [eap] Issue 117: Miscellaneous Technical NITs Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 25th, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 4.1, 5, 5.2, 5.3.1, Appendix B Rationale/Explanation of issue: Section 4.1, third paragraph, add to the end: "An EAP server receiving a Response not meeting this requirement MUST silently discard it." Section 5, second paragraph. Change: " The remaining Types define authentication exchanges. The Nak Type is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be sent in response to a Request which uses an authentication Type code (i.e., Type of 4 or greater)." To: " The remaining Types define authentication exchanges. The Nak Type (3) or Expanded Nak (254) is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be sent in response to a Request which uses an authentication Type code (i.e., Type of 4 or greater). An EAP server receiving a Nak Request MUST silently discard it." Section 5.2, first paragraph. Change: "An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request." To: "An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method." Section 5.3.1 Change: " Where any peer receives a Request for an unacceptable Type in the range (1-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a legacy Nak Response MUST be sent. The Type-Data field of the legacy Nak Response MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. A peer supporting Expanded Types that receives a Request for an unacceptable Type (1-253, 255) MAY include the value 254 in the legacy Nak Response in order to indicate the desire for an Expanded authentication Type. If the authenticator can accomodate this preference, it will respond with an Expanded Type Request." To: " Where a peer receives a Request for an unacceptable authentication Type (4-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a legacy Nak Response MUST be sent. The Type-Data field of the legacy Nak Response MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. A peer supporting Expanded Types that receives a Request for an unacceptable authentication Type (4-253, 255) MAY include the value 254 in the legacy Nak Response in order to indicate the desire for an Expanded authentication Type. If the authenticator can accomodate this preference, it will respond with an Expanded Type Request." Appendix B Add the following sentence to the next to last paragraph: "Where possible it is desirable for a method-specific MIC to be computed over the entire EAP packet, including the EAP layer (Code, Identifier, Length) and EAP method layer headers (Type, Type-Data)." From dror_caspi@atrica.com Sun Apr 27 17:14:12 2003 From: dror_caspi@atrica.com (Dror Caspi) Date: Sun, 27 Apr 2003 19:14:12 +0300 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: [I'm resending this message since it seems the original got lost - sorry = if any of you got it the second time] Description of issue=20 Submitter name: Dror Caspi Submitter email address: dror_caspi@atrica.com=20 Date first submitted: April 21, 2003=20 Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057=20 Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa Comment type: Technical Priority: '2' May fix Section: N/A=20 Rationale/Explanation of issue: =20 Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa, = it seems that most of the attention is given to systems where there is a = distinction between an authenticator and a peer/supplicant. This = distinction still exists even where mutual authentication is proposed = (e.g., EAP-Archie). But what happens when both parties are peers (e.g., two bridge devices)? = The possibility of role reversal is mentioned (i.e., run a session = where one system is Authenticator and the other Peer, and then reverse = the role). However it seems quite cumbersome; a single session of a = protocol such as EAP-Archie would seem to provide the required = authentication - yet there needs to be a mechanism to (randomly?) decide = which party plays which role. Probably some of the above is misunderstanding on my part. However = there seems to be a need for some explanatory text in the standards, if = not for actual changes to accomodate peer-to-peer mutual authentication. Requested change:=20 Add explanatory text about peer-to-peer mutual authentication. Modify = the standards if required. From aboba@internaut.com Sun Apr 27 17:54:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 27 Apr 2003 09:54:12 -0700 (PDT) Subject: [eap] Re: Issue 118: Mutual authentication In-Reply-To: <20030427170002.27889.74734.Mailman@wolverine> References: <20030427170002.27889.74734.Mailman@wolverine> Message-ID: > Requested change: > > Add explanatory text about peer-to-peer mutual authentication. Modify > the standards if required. FYI -- In order to consider this issue we will need a detailed proposal for changes to RFC 2284bis, including suggested text. I'll add this to the Issues list under "EAP Extensions" until text is provided. From jari.arkko@piuha.net Sun Apr 27 18:34:24 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 27 Apr 2003 20:34:24 +0300 Subject: [eap] Issue 115: Multiplexing fixes In-Reply-To: References: Message-ID: <3EAC14A0.5080804@piuha.net> Looks good to me. --Jari Bernard Aboba wrote: > Issue 115: EAP multiplexing fixes > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 25th, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > > It is necessary to clarify what aspects of on the wire behavior are > determined by the EAP layer versus other layers. Also, the sharing of > Identity Request as well as Response info could be made more clear. > Finally it is somewhat confusing to talk about method implemented in the > EAP layer. > > Change: > > " [b] EAP layer. The EAP layer receives and transmits EAP packets via > the lower layer, implements the EAP state machine, and delivers > and receives EAP messages to and from EAP methods." > > To: > > " [b] EAP layer. The EAP layer receives and transmits EAP packets via > the lower layer, implements duplicate detection and retransmission > and delivers and receives EAP messages to and from EAP methods." > > Change: > > "Within EAP, the Type field functions much like a port number in UDP > or TCP. With the exception of Types handled by the EAP layer, it is > assumed that the EAP layer multiplexes incoming EAP packets according > to their Type, and delivers them only to the EAP method corresponding > to that Type code, with one exception. > > Since EAP methods may wish to access the Identity, the Identity > Response can be assumed to be stored within the EAP layer so as to be > available to methods of Types other than 1 (Identity). The Identity > Type is discussed in Section 5.1. > > A Notification Response is only used as confirmation that the peer > received the Notification Request, not that it has processed it, or > displayed the message to the user. It cannot be assumed that the > contents of the Notification Request or Response is available to > another method. The Notification Type is discussed in Section 5.2. > > The Nak method is utilized for the purposes of method negotiation. > Peers MUST respond to an EAP Request for an unacceptable Type with a > Nak Response (legacy or expanded). It cannot be assumed that the > contents of the Nak Response is available to another method. The Nak > Type is discussed in Section 5.3. > > EAP packets with codes of Success or Failure do not include a Type, > and therefore are not delivered to an EAP method. Success and Failure > are discussed in Section 4.2. > > Given these considerations, the Success, Failure, Nak Response and > Notification Request/Response messages MUST NOT be used to carry data > destined for delivery to other EAP methods. > > Where a pass-through authenticator is present, it forwards packets > back and forth between the peer and a backend authentication server, > based on the EAP layer header fields (Code, Identifier, Length). > Since pass-through authenticators rely on a backend authenticator > server to implement methods, the EAP method layer header fields > (Type, Type-Data) are not examined as part of the forwarding > decision. The forwarding model is illustrated in Figure 2. Compliant > pass-through authenticator implementations MUST by default be capable > of forwarding packets from any EAP method." > > To: > > "Within EAP, the Type field functions much like a port number in UDP > or TCP. It is assumed that the EAP layer multiplexes incoming EAP > packets according to their Type, and delivers them only to the > EAP method corresponding to that Type code. > > Since EAP authentication methods may wish to access the Identity, > the Identity Request and Response can be assumed to be > accessible to authentication methods (Types 4 or greater) in addition > to the Identity method. The Identity Type is discussed in Section 5.1. > > A Notification Response is only used as confirmation that the peer > received the Notification Request, not that it has processed it, or > displayed the message to the user. It cannot be assumed that the > contents of the Notification Request or Response is available to > an authentication method. The Notification Type is discussed in Section > 5.2. > > The Nak method is utilized for the purposes of method negotiation. > Peers respond to an initial EAP Request for an unacceptable Type with a > Nak Response (legacy or expanded). It cannot be assumed that the > contents of the Nak Response is available to another method. The Nak > Type is discussed in Section 5.3. > > EAP packets with codes of Success or Failure do not include a Type, > and therefore are not delivered to an EAP method. Success and Failure > are discussed in Section 4.2. > > Given these considerations, the Success, Failure, Nak Response and > Notification Request/Response messages MUST NOT be used to carry data > destined for delivery to other EAP methods. > > Where an authenticator operates as a pass-through, it forwards packets > back and forth between the peer and a backend authentication server, > based on the EAP layer header fields (Code, Identifier, Length). > Since pass-through authenticators rely on a backend authenticator > server to implement methods, the EAP method layer header fields > (Type, Type-Data) are not examined as part of the forwarding > decision. The forwarding model is illustrated in Figure 2. Compliant > pass-through authenticator implementations MUST by default be capable > of forwarding packets from any EAP method." > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From jari.arkko@piuha.net Sun Apr 27 18:39:39 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 27 Apr 2003 20:39:39 +0300 Subject: [eap] Issue 114: Terminology fixes In-Reply-To: References: Message-ID: <3EAC15DB.9050405@piuha.net> I agree. --Jari Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 25th, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 1.2 > Rationale/Explanation of issue: > > Some terms aren't defined in the terminology section and there some minor > cleanup to do. > > Change: > > "authenticator > The end of the EAP link initiating the EAP authentication > methods. [Note: This terminology is also used in > [IEEE.802-1X.2001], and has the same meaning in this > document]. > > peer > The end of the EAP Link that responds to the authenticator. > [Note:In [IEEE.802-1X.2001], this end is known as the > Supplicant.] > > backend authentication server > A backend authentication server is an entity that provides > an authentication service to an authenticator. When used, > this server typically executes EAP Methods for the > authenticator. [This terminology is also used in > [IEEE.802-1X.2001].] > " > > To: > > " authenticator > The end of the EAP link initiating EAP authentication. > The term Authenticator is used in > [IEEE.802-1X.2001], and has the same meaning in this > document. > > peer > The end of the EAP Link that responds to the authenticator. > In [IEEE.802-1X.2001], this end is known as the > Supplicant. > > backend authentication server > A backend authentication server is an entity that provides > an authentication service to an authenticator. When used, > this server typically executes EAP methods for the > authenticator. This terminology is also used in > [IEEE.802-1X.2001]." > Change: > > " Key derivation > This refers to the ability of the EAP method to derive a > Master Key which is not exported, as well as a ciphersuite- > independent Master Session Keys. Both the Master Key and > Master Session Keys are used only for further key > derivation, not directly for protection of the EAP > conversation or subsequent data." > > To: > > " Key derivation > This refers to the ability of the EAP method to derive a > Master Key (MK) which is not exported, as well as > exportable keying material such as the Master Session Key > (MSK), Extended Master Session Key (EMSK) and (optionally) > an Initialization Vector (IV). > > The MK, MSK and IV are used only for further key > derivation, not directly for protection of the EAP > conversation or subsequent data. Use of the EMSK > is reserved." > > Change: > > "Man-in-the-Middle resistance > The ability for the peer to demonstrate to the > authenticator that it has acted as the peer for each method > within the conversation. Similarly, the authenticator > demonstrates to the peer that it has acted as the > authenticator for each method within the conversation. If > this is not possible, then the authentication sequence or > tunnel may be vulnerable to a man-in-the-middle attack." > > To: > > > "Man-in-the-Middle resistance > The ability for the peer to demonstrate to the > authenticator that it has acted as the peer for each > authentication method within the conversation. Similarly, > the authenticator demonstrates to the peer that it has > acted as the authenticator for each authentication method > within the conversation. If this is not possible, then > the authentication sequence or tunnel may be vulnerable > to a man-in-the-middle attack." > > Change: > > " Acknowledged result indications > The ability of the authenticator to provide the peer with > an indication of whether the peer has successfully > authenticated to it, and for the peer to acknowledge > receipt, as well as providing an indication of whether the > authenticator has successfully authenticated to the peer. > Since EAP Success and Failure packets are neither > acknowledged nor integrity protected, this claim requires > implementation of a method- specific result exchange that > is integrity protected." > > To: > > " Acknowledged result indications > The ability of the authenticator to provide the peer with > an indication of whether the peer has successfully > authenticated to it, and for the peer to acknowledge > receipt, as well as providing an indication of whether the > authenticator has successfully authenticated to the peer. > Since EAP Success and Failure packets are neither > acknowledged nor integrity protected, this claim requires > implementation of a method-specific result exchange that > is authenticated, integrity and replay protected on a > per-packet basis." > > Add the following definitions: > > "Cryptographic binding > The demonstration of the EAP peer to the EAP server that a single > entity has acted as the EAP peer for all methods executed within a > sequence or tunnel. Binding MAY also imply that the EAP server > demonstrates to the peer that a single entity has acted as the EAP > server for all methods executed within a sequence or tunnel. If > executed correctly, binding serves to mitigate man-in-the-middle > vulnerabilities. > > Cryptographic separation > Two keys (x and y) are "cryptographically separate" if an adversary > that knows all messages exchanged in the protocol cannot compute x > from y or y from x without "breaking" some cryptographic > assumption. In particular, this definition allows that the > adversary has the knowledge of all nonces sent in cleartext as well > as all predictable counter values used in the protocol. Breaking a > cryptographic assumption would typically require inverting a one- > way function or predicting the outcome of a cryptographic pseudo- > random number generator without knowledge of the secret state. In > other words, if the keys are cryptographically separate, there is > no shortcut to compute x from y or y from x, but the work an > adversary must do to perform this computation is equivalent to > performing exhaustive search for the secret state value." > > EAP Master key (MK) > A key derived between the EAP client and server during the EAP > authentication process that is purely local to the EAP method. The > MK MUST NOT be exported from the EAP method or be made available to > a third party. Since derivation of the MK is a residue of the > successful completion of the EAP authentication exchange, proof of > MK possession may be used to shorten future EAP exchanges between > the same EAP client and server, a technique known as "fast resume". > > Master Session Key (MSK) > Keying material (64 octets) that is derived between the EAP client > and server. The MSK is used in the derivation of Transient Session > Keys (TSKs) for the ciphersuite negotiated between the EAP peer and > authenticator. Where a backend authentication server is present, > acting as an EAP server, it will typically transport the MSK to the > authenticator. > > The MSK differs from the MK in that it not assumed to remain local > to the EAP method, and is known by all parties in the EAP exchange: > the peer, authenticator and the authentication server (if present). > The MSK MAY be derived from the MK via a one-way function, or it > may be an independent quantity. However possession of the MSK MUST > NOT provide any information useful in determining the MK. > > Extended Master Session Key (EMSK) > Additional keying material (64 octets) derived between the EAP > client and server that is not assumed to remain local to the EAP > method. However, unlike the MSK, the EMSK is known only to the EAP > client and server and MUST NOT be provided to a third party. The > EMSK therefore MUST NOT be transported by the backend > authentication server to the authenticator. The EMSK is reserved > for future uses that are not defined yet. For example, it could be > used to derive additional keying material for purposes such as fast > handoff, man-in-the-middle vulnerability protection, etc. " > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From jari.arkko@piuha.net Sun Apr 27 19:07:49 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 27 Apr 2003 21:07:49 +0300 Subject: [eap] Issue 111: Lower Layer Requirements In-Reply-To: References: Message-ID: <3EAC1C75.30107@piuha.net> Ok. --Jari Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 25th, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 3.1 > Rationale/Explanation of issue: > > This section says that a a lower layer CRC or checksum is not necessary, > but if it is absent there will be problems. Rewrite the section to the > following: > > "3.1 Lower layer requirements > > EAP makes the following assumptions about lower layers: > > [1] Unreliable transport. In EAP, the authenticator > retransmits Requests that have not yet received Responses, so > that EAP does not assume that lower layers are reliable. Since > EAP defines it own retransmission behavior, when run over a > reliable lower layer, it is possible (though undesirable) for > retransmission to occur both in the lower layer and the EAP > layer. > > Note that EAP Success and Failure packets are not retransmitted. > Without a reliable lower layer, and a non-negligible > error rate, these packets can be lost, resulting in timeouts. > It is therefore desirable for implementations to improve > their resilience to loss of EAP Success or Failure packets, > as described in Section 4.2. > > [2] Lower layer error detection. While EAP does not assume that the > lower layer is reliable, it does rely on lower layer > error detection. EAP methods may not include a MIC, or if they > do, it may not be run over all the fields in the EAP packet, > such as the Code, Identifier, Length or Type fields. As a result, > without lower layer error detection, undetected errors could > creep into the EAP layer header or EAP method header fields, > resulting in authentication failures. > > For example, EAP TLS [RFC2716], which computes its MIC > only over the Type-Data field, regards MIC validation failures > as a fatal error. Without lower layer error detection, this > method and others like it will not perform reliably. > > [3] Lower layer security. EAP assumes that lower layers either > provide physical security for data (e.g. wired PPP or IEEE > 802 links) or support per-packet authentication, integrity > and replay protection. EAP SHOULD NOT be used on physically > insecure links (e.g. wireless) where per-packet authentication, > integrity and replay protection is unavailable. > > After EAP authentication is complete, the peer will typically > transmit data to the network via the authenticator. In order > to provide assurance that the peer transmitting data is the > same entity that successfully completed EAP > authentication, the lower layer needs to bind per-packet > integrity, authentication and replay protection to the > original EAP authentication, using keys derived during EAP > authentication. Alternatively, the lower layer needs to be > physically secure. Otherwise it is possible for > subsequent data traffic to be hijacked, or replayed. > > Where keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite cannot be > enabled until late in the EAP conversation, after key derivation > has completed. Thus it may only be possible to use the lower > layer ciphersuite to protect a portion of the EAP conversation, > such as the EAP Success or Failure packet. > > [4] MTU known a-priori. The EAP layer does not support fragmentation and > reassembly. However, EAP methods SHOULD be capable of handling > fragmentation and reassembly. As a result, EAP is capable of > functioning across a range of MTU sizes, as long as the MTU is > known a-priori. EAP does not support path MTU discovery. > > [5] Possible duplication. Where the lower layer is reliable, it will > provide the EAP layer with a non-duplicated stream of packets. > However, while it is desirable that lower layers provide for > non-duplication, this is not a requirement. The Identifier field > provides both the peer and authenticator with the ability to > detect duplicates. > > [6] Ordering guarantees. EAP does not require the Identifier to be > monotonically increasing, and so is reliant on lower layer > ordering guarantees for correct operation. EAP was > originally defined to run on PPP, and [RFC1661] Section 1 has an > ordering requirement: > > "The Point-to-Point Protocol is designed for simple links which > transport packets between two peers. These links provide full- > duplex simultaneous bi-directional operation, and are assumed to > deliver packets in order." > > Lower lower transports for EAP MUST preserve ordering between a > source and destination, at a given priority level (the > ordering guarantee provided by [IEEE.802.1990])." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From dror_caspi@atrica.com Mon Apr 28 07:21:50 2003 From: dror_caspi@atrica.com (Dror Caspi) Date: Mon, 28 Apr 2003 09:21:50 +0300 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: 802.1aa/D5 (section 6.7) talks about this issue, but unless I = misunderstood some of the text it is still problematic. - The suggested method in the text for peers (e.g., two bridges) is to = play both Authenticatior and Supplicant. Such systems should be prepared for = role reversal. - However the text clearly notes that from the two one-way = authentication exchanges in each direction are not equivalent to a single mutual = authentication exchange. - The text also notes that EAP methods that perform mutual = authentication can be used - and that the Supplicant action at the end of such exchange is = currently undefined. So based on the above, what I would really like to do is use a single = exchange with a mutual authentication method (e.g., EAP-Archie). But = then how do you decide on who plays the Authenticator and who plays the = Supplicant? - both sides are equal peers. One way we thought of was for = both peers start as Authenticator and do some pseudo-random decision - = say based on the highest MAC address or highest pseudo-random NONCE = value sent as part of the initial EAP request. However I am not sure that the above is still within the standard - = i.e., if we implement this (say as a proprietary EAP method) it would = still fit within the 802.1aa/D5 and RFC2284bis framework. Dror > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: Monday, April 28, 2003 7:22 AM > To: Dror Caspi; eap@frascone.com > Cc: Yael Dayan > Subject: RE: [eap] FW: peer-to-peer mutual authentication >=20 >=20 >=20 > We did attempt to put some words in 802.1aa/D4 around this=20 > topic. I'm not > sure they were exactly what was needed, so there maybe some slight > re-wording in 802.1aa/D5 when it comes out this week. Have a=20 > look and see > if your issue is still not properly addressed. >=20 > Paul >=20 > -----Original Message----- > From: Dror Caspi [mailto:dror_caspi@atrica.com]=20 > Sent: Sunday, April 27, 2003 9:14 AM > To: eap@frascone.com > Cc: Yael Dayan > Subject: [eap] FW: peer-to-peer mutual authentication >=20 >=20 > [I'm resending this message since it seems the original got=20 > lost - sorry if > any of you got it the second time] >=20 > Description of issue=20 > Submitter name: Dror Caspi > Submitter email address: dror_caspi@atrica.com=20 > Date first submitted: April 21, 2003=20 > Reference:=20 http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057=20 Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa = Comment type: Technical Priority: '2' May fix Section: N/A=20 Rationale/Explanation of issue: =20 Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa, = it seems that most of the attention is given to systems where there is a distinction between an authenticator and a peer/supplicant. This distinction still exists even where mutual authentication is proposed = (e.g., EAP-Archie). But what happens when both parties are peers (e.g., two bridge devices)? The possibility of role reversal is mentioned (i.e., run a session where = one system is Authenticator and the other Peer, and then reverse the role). However it seems quite cumbersome; a single session of a protocol such = as EAP-Archie would seem to provide the required authentication - yet there needs to be a mechanism to (randomly?) decide which party plays which = role. Probably some of the above is misunderstanding on my part. However = there seems to be a need for some explanatory text in the standards, if not = for actual changes to accomodate peer-to-peer mutual authentication. Requested change:=20 Add explanatory text about peer-to-peer mutual authentication. Modify = the standards if required. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Mon Apr 28 07:43:35 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 28 Apr 2003 09:43:35 +0300 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: References: Message-ID: <3EACCD97.1040806@piuha.net> Dror Caspi wrote: > 802.1aa/D5 (section 6.7) talks about this issue, but unless I misunderstood some of the text it is still problematic. > > - The suggested method in the text for peers (e.g., two bridges) is to play both > Authenticatior and Supplicant. Such systems should be prepared for role > reversal. > - However the text clearly notes that from the two one-way authentication > exchanges in each direction are not equivalent to a single mutual authentication > exchange. Right. One mutual auth is good enough, however, in theory. But there may still be protocol problems (see below). > - The text also notes that EAP methods that perform mutual authentication can be > used - and that the Supplicant action at the end of such exchange is currently > undefined. > > So based on the above, what I would really like to do is use a single exchange with a mutual authentication method (e.g., EAP-Archie). But then how do you decide on who plays the Authenticator and who plays the Supplicant? - both sides are equal peers. One way we thought of was for both peers start as Authenticator and do some pseudo-random decision - say based on the highest MAC address or highest pseudo-random NONCE value sent as part of the initial EAP request. Yes. > However I am not sure that the above is still within the standard - i.e., if we implement this (say as a proprietary EAP method) it would still fit within the 802.1aa/D5 and RFC2284bis framework. This would be easier to determine if we had details available on exactly how the two peers go about doing the mutual authentication. As I see it, there are two fundamental issues: - Who acts as the initiator (FCFS, highest identity/addrs/nonce/whatever, ...) - How to identify the initiator. As a responder, I can send my identity in the Identity Response, but what if we are running a shared secret method and I have different shared secrets for you and someone else? I would need to know your identity before I can proceed with the execution of the method. I don't know of a way how to do this in EAP. OTOH, this is a similar issue as exists in the case of multiple providers and credentials even in e.g. regular WLAN access from a client, which I believe is solved with information from the link layer (SSID). Secondly, I see two approaches to solving these issues. One, we could do it at the EAP level. Two, we could do it at the link-layer level. For instance, the initiator could be chosen to be the peer with the smallest MAC address, and if the link-layer identity and other published information suffices to identify the initiator, I believe 2284bis would work fine in this case. But you wouldn't see this at the EAP layer; all the decisions take place at the link layer and then magically the EAP protocol is run in one direction between the two parties. --Jari From aboba@internaut.com Mon Apr 28 07:44:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 27 Apr 2003 23:44:12 -0700 (PDT) Subject: [eap] Re: Peer to Peer mutual authentication In-Reply-To: <20030428064501.9961.88720.Mailman@wolverine> References: <20030428064501.9961.88720.Mailman@wolverine> Message-ID: > - How to identify the initiator. As a responder, I can send my identity > in the Identity Response, but what if we are running a shared secret > method and I have different shared secrets for you and someone else? > I would need to know your identity before I can proceed with the > execution of the method. In practice, there are some implementations where the authenticator sends its Identity in the Identity Request, and the peer responds with an Identity Response. However, since this is peer to peer it would probably make more sense to choose a method that had its own identity exchange built-in. That way it might be possible to support identity privacy. > from a client, which I believe is solved with information from the > link layer (SSID). A hint from the link layer (SSID) is preferred because it is available prior to authentication, but some EAP implementations also provide a hint in the Identity Request. > Two, we could do it at the link-layer level. > For instance, the initiator could be chosen to be the peer with the > smallest MAC address That's what comes to mind. For example, both sides can send an EAPOL-Start to the 8021X multicast address, and then the peer with the lowest MAC address can respond with an EAP-Request (authenticator role). From Pasi.Eronen@nokia.com Mon Apr 28 08:28:55 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 28 Apr 2003 10:28:55 +0300 Subject: [eap] Re: Issue 114: Terminology fixes Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122273@esebe023.ntc.nokia.com> One comment and addition: > On April 27th, Bernard Aboba wrote: > ... > Master Session Key (MSK) > Keying material (64 octets) that is derived between the EAP client > and server. The MSK is used in the derivation of Transient Session > Keys (TSKs) for the ciphersuite negotiated between the EAP peer and > authenticator. Where a backend authentication server is present, > acting as an EAP server, it will typically transport the MSK to the > authenticator. >=20 > The MSK differs from the MK in that it not assumed to remain local > to the EAP method, and is known by all parties in the EAP exchange: > the peer, authenticator and the authentication server (if present). > The MSK MAY be derived from the MK via a one-way function, or it > may be an independent quantity. However possession of the MSK MUST > NOT provide any information useful in determining the MK. I think the last sentence is a method detail that applies to some methods, but not to all. It's possible to envision a perfectly good method where the MSK does provide information about MK, but this does not weaken the security in any way (or a method where an intermediate "MK step" does not really exist, so MK=3D=3DMSK). Whether this is a good idea depends on the details of the method; but if it's not necessary, I think it shouldn't be specified in 2284bis with a "MUST" (the same requirement occurs also in section 7.10). Would a "SHOULD" be a better choice? And here's an another addition to the terminology list (I submitted this on March 7th, but I guess it got lost somewhere). Message Integrity Code (MIC) A keyed hash function used to protect integrity of data. This is=20 usually called a Message Authentication Code (MAC), but IEEE 802=20 specifications (and this document) use the acronym MIC to avoid=20 confusion with Medium Access Control. Best regards, Pasi From jari.arkko@piuha.net Mon Apr 28 08:31:27 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 28 Apr 2003 10:31:27 +0300 Subject: [eap] Issue 117: Miscellaneous Technical NITs In-Reply-To: References: Message-ID: <3EACD8CF.4030901@piuha.net> A few question marks inline: > Section 5, second paragraph. Change: > > " The remaining Types define authentication exchanges. The Nak Type is > valid only for Response packets, it MUST NOT be sent in a Request. > The Nak Type MUST only be sent in response to a Request which uses an > authentication Type code (i.e., Type of 4 or greater)." > > To: > > " The remaining Types define authentication exchanges. The Nak Type > (3) or Expanded Nak (254) is valid only for Response packets, it > MUST NOT be sent in a Request. The Nak Type MUST only be sent in > response to a Request which uses an authentication Type code > (i.e., Type of 4 or greater). An EAP server receiving a Nak Request > MUST silently discard it." This seems a bit odd. First of all, Expanded Nak (254) does not really exist, all we have is "Expanded Types (254)" which is used both for the methods as well as the Nak. Secondly, the third and fourth sentences are about Nak while the rest of the paragraph applies both to Nak and Extended Nak. Finally, it seems odd that we have to list these things in the beginning of section 5, but not at the subsections devoted to Nak/Extended Nak. Suggested fix: Just keep the first two sentences of the original second paragraph. Formulate Nak and Extended Nak specific texts to sections 5.3.1 and 5.3.2. > Section 5.2, first paragraph. > > Change: > > "An authenticator MAY send a Notification Request to the peer at any time > when there is no outstanding Request." > > To: > > "An authenticator MAY send a Notification Request to the peer at any time > when there is no outstanding Request, prior to completion of an EAP > authentication method." Hmm... why? So Notification can't appear between a completed method and success, for instance? --Jari From Internet-Drafts@ietf.org Mon Apr 28 12:26:25 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 28 Apr 2003 07:26:25 -0400 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-02.txt Message-ID: <200304281126.HAA26902@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-02.txt Pages : 52 Date : 2003-4-25 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP, but is reliant on lower layer ordering guarantees as in PPP and IEEE 802. EAP does provide its own support for duplicate elimination and retransmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in the 'Change Log' Appendix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-25120801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-25120801.I-D@ietf.org> --OtherAccess-- --NextPart-- From henrik@levkowetz.com Mon Apr 28 13:28:15 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 28 Apr 2003 14:28:15 +0200 Subject: [eap] Issue 110: Miscellaneous NITs In-Reply-To: References: Message-ID: <20030428142815.2c6b10f2.henrik@levkowetz.com> I'm working on the nits, most seem pretty clear-cut, but there's this one though: On Sat, 26 Apr 2003 13:27:42 -0700 (PDT) Bernard Aboba wrote: ... > Last paragraph of Section 2.1 "Within or associated..." should be > moved to section 7.8 after the last paragraph there. I'm not convinced it really fits much better there. Maybe it would be just as well to remove it completely? It seems to be somewhat at odds with what is stated in the first paragraph of 2.1 Henrik -- The dinosaurs became extinct because they didn't have a space program. - Larry Niven And if we become extinct because we don't have a space program, it'll serve us right! - AC Clark From henrik@levkowetz.com Mon Apr 28 14:23:17 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 28 Apr 2003 15:23:17 +0200 Subject: [eap] Issue 111: Lower Layer Requirements In-Reply-To: <3EAC1C75.30107@piuha.net> References: <3EAC1C75.30107@piuha.net> Message-ID: <20030428152317.5eb41796.henrik@levkowetz.com> On Sun, 27 Apr 2003 21:07:49 +0300 Jari Arkko wrote: Yes, looks fine, except 1 possible query made separately. Henrik > Ok. --Jari > > Bernard Aboba wrote: > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: April 25th, 2003 > > Reference: > > Document: EAP-02 > > Comment type: T > > Priority: S > > Section: 3.1 > > Rationale/Explanation of issue: > > > > This section says that a a lower layer CRC or checksum is not necessary, > > but if it is absent there will be problems. Rewrite the section to the > > following: > > > > "3.1 Lower layer requirements > > > > EAP makes the following assumptions about lower layers: > > > > [1] Unreliable transport. In EAP, the authenticator > > retransmits Requests that have not yet received Responses, so > > that EAP does not assume that lower layers are reliable. Since > > EAP defines it own retransmission behavior, when run over a > > reliable lower layer, it is possible (though undesirable) for > > retransmission to occur both in the lower layer and the EAP > > layer. > > > > Note that EAP Success and Failure packets are not retransmitted. > > Without a reliable lower layer, and a non-negligible > > error rate, these packets can be lost, resulting in timeouts. > > It is therefore desirable for implementations to improve > > their resilience to loss of EAP Success or Failure packets, > > as described in Section 4.2. > > > > [2] Lower layer error detection. While EAP does not assume that the > > lower layer is reliable, it does rely on lower layer > > error detection. EAP methods may not include a MIC, or if they > > do, it may not be run over all the fields in the EAP packet, > > such as the Code, Identifier, Length or Type fields. As a result, > > without lower layer error detection, undetected errors could > > creep into the EAP layer header or EAP method header fields, > > resulting in authentication failures. > > > > For example, EAP TLS [RFC2716], which computes its MIC > > only over the Type-Data field, regards MIC validation failures > > as a fatal error. Without lower layer error detection, this > > method and others like it will not perform reliably. > > > > [3] Lower layer security. EAP assumes that lower layers either > > provide physical security for data (e.g. wired PPP or IEEE > > 802 links) or support per-packet authentication, integrity > > and replay protection. EAP SHOULD NOT be used on physically > > insecure links (e.g. wireless) where per-packet authentication, > > integrity and replay protection is unavailable. > > > > After EAP authentication is complete, the peer will typically > > transmit data to the network via the authenticator. In order > > to provide assurance that the peer transmitting data is the > > same entity that successfully completed EAP > > authentication, the lower layer needs to bind per-packet > > integrity, authentication and replay protection to the > > original EAP authentication, using keys derived during EAP > > authentication. Alternatively, the lower layer needs to be > > physically secure. Otherwise it is possible for > > subsequent data traffic to be hijacked, or replayed. > > > > Where keying material for the lower layer ciphersuite is itself > > provided by EAP, typically the lower layer ciphersuite cannot be > > enabled until late in the EAP conversation, after key derivation > > has completed. Thus it may only be possible to use the lower > > layer ciphersuite to protect a portion of the EAP conversation, > > such as the EAP Success or Failure packet. > > > > [4] MTU known a-priori. The EAP layer does not support fragmentation and > > reassembly. However, EAP methods SHOULD be capable of handling > > fragmentation and reassembly. As a result, EAP is capable of > > functioning across a range of MTU sizes, as long as the MTU is > > known a-priori. EAP does not support path MTU discovery. > > > > [5] Possible duplication. Where the lower layer is reliable, it will > > provide the EAP layer with a non-duplicated stream of packets. > > However, while it is desirable that lower layers provide for > > non-duplication, this is not a requirement. The Identifier field > > provides both the peer and authenticator with the ability to > > detect duplicates. > > > > [6] Ordering guarantees. EAP does not require the Identifier to be > > monotonically increasing, and so is reliant on lower layer > > ordering guarantees for correct operation. EAP was > > originally defined to run on PPP, and [RFC1661] Section 1 has an > > ordering requirement: > > > > "The Point-to-Point Protocol is designed for simple links which > > transport packets between two peers. These links provide full- > > duplex simultaneous bi-directional operation, and are assumed to > > deliver packets in order." > > > > Lower lower transports for EAP MUST preserve ordering between a > > source and destination, at a given priority level (the > > ordering guarantee provided by [IEEE.802.1990])." > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Certainly the game is rigged. Don't let that stop you; if you don't bet, you can't win. From aboba@internaut.com Mon Apr 28 14:21:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 06:21:54 -0700 (PDT) Subject: [eap] Issue 117: Miscellaneous Technical NITs In-Reply-To: <3EACD8CF.4030901@piuha.net> References: <3EACD8CF.4030901@piuha.net> Message-ID: > This seems a bit odd. First of all, Expanded Nak (254) does not > really exist, all we have is "Expanded Types (254)" which is used > both for the methods as well as the Nak. Secondly, the third > and fourth sentences are about Nak while the rest of the paragraph > applies both to Nak and Extended Nak. Finally, it seems odd that > we have to list these things in the beginning of section 5, but > not at the subsections devoted to Nak/Extended Nak. > > Suggested fix: Just keep the first two sentences of the original > second paragraph. Formulate Nak and Extended Nak specific texts > to sections 5.3.1 and 5.3.2. Will do. I think that the last sentence is redundant anyway, given the existing text, so we can just drop it. > Hmm... why? So Notification can't appear between a completed method and > success, for instance? Right. Or between a completed method and failure. That way after the method is complete the next packet (Success/Failure) is pre-determined. From henrik@levkowetz.com Mon Apr 28 14:52:46 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 28 Apr 2003 15:52:46 +0200 Subject: [eap] Issue 113: Rewrite of Security Considerations Section In-Reply-To: References: Message-ID: <20030428155246.26a3cd47.henrik@levkowetz.com> In the proposed new security considerations text, there is this notice at the end of section 7.1: "Section 7.11: adding following paragraph at the end of the section: Where EAP is used over wireless networks, an attacker needs to be within the coverage area of the wireless medium in order to carry out these attacks. However, where EAP is used over the Internet, no such restrictions apply." I believe this a misspelling of the section number, so this is intended to be added at the end of 7.1, rather than 7.11? Henrik On Sat, 26 Apr 2003 15:56:29 -0700 (PDT) Bernard Aboba wrote: > Issue 113: Rewrite of Security Considerations Section > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 25th, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: 1 > Section: 7 > Rationale/Explanation of issue: > > Given changes in the key framework and sequence support, the security > considerations section needs to be updated. See the issues list for > complete suggested text: > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 113 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Error message in Haiku form: Stay the patient course Of little worth is your ire The network is down -- David Ansel From jari.arkko@piuha.net Mon Apr 28 15:06:50 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 28 Apr 2003 17:06:50 +0300 Subject: [eap] Issue 117: Miscellaneous Technical NITs In-Reply-To: References: <3EACD8CF.4030901@piuha.net> Message-ID: <3EAD357A.30806@piuha.net> Bernard Aboba wrote: >>Suggested fix: Just keep the first two sentences of the original >>second paragraph. Formulate Nak and Extended Nak specific texts >>to sections 5.3.1 and 5.3.2. > > > Will do. I think that the last sentence is redundant anyway, given the > existing text, so we can just drop it. Ok. >>Hmm... why? So Notification can't appear between a completed method and >>success, for instance? > > > Right. Or between a completed method and failure. That way after the > method is complete the next packet (Success/Failure) is pre-determined. Ok. The stricter this is, the better... --Jari From aboba@internaut.com Mon Apr 28 14:50:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 06:50:02 -0700 (PDT) Subject: [eap] Issue 110: Miscellaneous NITs In-Reply-To: <20030428142815.2c6b10f2.henrik@levkowetz.com> References: <20030428142815.2c6b10f2.henrik@levkowetz.com> Message-ID: > I'm not convinced it really fits much better there. Maybe it would be > just as well to remove it completely? It seems to be somewhat at odds > with what is stated in the first paragraph of 2.1 They should not be at odds -- the first paragraph talks about multiple authentication methods within a sequence. This paragraph talks about a choice of methods. Maybe we need to clarify that more. I believe that the movement to the security considerations section was requested by John Vollbrecht, and it does seem better suited in the section devoted to that particular type of attack. From henrik@levkowetz.com Mon Apr 28 15:15:46 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 28 Apr 2003 16:15:46 +0200 Subject: [eap] Issue 110: Miscellaneous NITs In-Reply-To: References: <20030428142815.2c6b10f2.henrik@levkowetz.com> Message-ID: <20030428161546.1d20c869.henrik@levkowetz.com> On Mon, 28 Apr 2003 06:50:02 -0700 (PDT) Bernard Aboba wrote: > > I'm not convinced it really fits much better there. Maybe it would be > > just as well to remove it completely? It seems to be somewhat at odds > > with what is stated in the first paragraph of 2.1 > > They should not be at odds -- the first paragraph talks about multiple > authentication methods within a sequence. This paragraph talks about a > choice of methods. Maybe we need to clarify that more. > > I believe that the movement to the security > considerations section was requested by John Vollbrecht, and it does seem > better suited in the section devoted to that particular type of attack. Ok. I've done so for now. And with the other changes you've proposed in the security considerations it seems to fit in better. Henrik -- # efdtt.c Author: Charles M. Hannum # Represented as 1045 digit prime number by Phil Carmody # Prime as DNS cname chain by Roy Arends and Walter Belgers # # Usage is: cat title-key scrambled.vob | efdtt >clear.vob # where title-key = "153 2 8 105 225" or other similar 5-byte key dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}' From aboba@internaut.com Mon Apr 28 14:58:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 06:58:05 -0700 (PDT) Subject: [eap] Issue 113: Rewrite of Security Considerations Section In-Reply-To: <20030428155246.26a3cd47.henrik@levkowetz.com> References: <20030428155246.26a3cd47.henrik@levkowetz.com> Message-ID: > "Section 7.11: adding following paragraph at the end of the section: > > Where EAP is used over wireless networks, an attacker needs to be > within the coverage area of the wireless medium in order to carry out > these attacks. However, where EAP is used over the Internet, no such > restrictions apply." > > I believe this a misspelling of the section number, so this is intended to > be added at the end of 7.1, rather than 7.11? Hmm. I'm not sure where this came from. I'll look into it and apply a fix on the Issues page. From aboba@internaut.com Mon Apr 28 15:05:17 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 07:05:17 -0700 (PDT) Subject: [eap] Re: Issue 114: Terminology fixes In-Reply-To: <20030428141601.20012.8334.Mailman@wolverine> References: <20030428141601.20012.8334.Mailman@wolverine> Message-ID: > I think the last sentence is a method detail that applies to some > methods, but not to all. It's possible to envision a perfectly good > method where the MSK does provide information about MK, but this does > not weaken the security in any way (or a method where an intermediate > "MK step" does not really exist, so MK=3D=3DMSK). By "information" I meant the ability to recover the MK with less effort than brute force. Is it possible to envisage a good method where that would be true? > Message Integrity Code (MIC) > A keyed hash function used to protect integrity of data. This is=20 > usually called a Message Authentication Code (MAC), but IEEE 802=20 > specifications (and this document) use the acronym MIC to avoid=20 > confusion with Medium Access Control. Good. I will add this. From Pasi.Eronen@nokia.com Mon Apr 28 15:33:22 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 28 Apr 2003 17:33:22 +0300 Subject: [eap] Re: Issue 117: Miscellaneous Technical NITs Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122275@esebe023.ntc.nokia.com> Bernard Aboba wrote: >> Hmm... why? So Notification can't appear between a=20 >> completed method and success, for instance? > > Right. Or between a completed method and failure. That way after the > method is complete the next packet (Success/Failure) is=20 > pre-determined. Just to clarify this: do you mean by "pre-determined" that=20 the peer knows which one (Success or Failure) the authenticator is going to send, or knows just that either one of them is coming next? (I assume it's the latter, but just checking that I've understood this right..) BTW, I think Notifications could be quite useful between=20 a completed method and failure, to tell the client why the connection failed. Otherwise each method will have to specify its own mechanism for communicating this. This might actually be a good idea, but then I guess we should deprecate Notifications completely. Best regards, Pasi From sgoswami@umich.edu Mon Apr 28 15:40:59 2003 From: sgoswami@umich.edu (Subrata Goswami) Date: Mon, 28 Apr 2003 07:40:59 -0700 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: Message-ID: <000701c30d94$2f664be0$0300a8c0@SGOSWAMIPCL> Does not the Supplicant know that it is trying to join an infrastructure network ? In other words, the EAP Authenticator sends an Request Identity packet as soon as it sees a Supplicant connecting to it. There would be a race condition (or conflict) when two EAP Authenticators try to connect to each other. Such a situation can arise when two isolated networks try to connect to each other. This can be solved by the usual random back-off technique. In other words the following table shows the situation for connecting entities of two networks. Network 1 Entity Network 2 Entity Behavior =============================================================== Supplicant Supplicant Can not connect Supplicant Authenticator 2 sends Request Identity packet to 1 Authenticator Supplicant 1 sends Request Identity packet to 2 Authenticator Authenticator 1 and 2 sends Request Identity packet after random time. Subrata > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Dror Caspi > Sent: Sunday, April 27, 2003 11:22 PM > To: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com > Cc: Yael Dayan > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > misunderstood some of the text it is still problematic. > > - The suggested method in the text for peers (e.g., two > bridges) is to play both > Authenticatior and Supplicant. Such systems should be > prepared for role > reversal. > - However the text clearly notes that from the two one-way > authentication > exchanges in each direction are not equivalent to a single > mutual authentication > exchange. > - The text also notes that EAP methods that perform mutual > authentication can be > used - and that the Supplicant action at the end of such > exchange is currently > undefined. > > So based on the above, what I would really like to do is use > a single exchange with a mutual authentication method (e.g., > EAP-Archie). But then how do you decide on who plays the > Authenticator and who plays the Supplicant? - both sides are > equal peers. One way we thought of was for both peers start > as Authenticator and do some pseudo-random decision - say > based on the highest MAC address or highest pseudo-random > NONCE value sent as part of the initial EAP request. > > However I am not sure that the above is still within the > standard - i.e., if we implement this (say as a proprietary > EAP method) it would still fit within the 802.1aa/D5 and > RFC2284bis framework. > > Dror > > > > -----Original Message----- > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > Sent: Monday, April 28, 2003 7:22 AM > > To: Dror Caspi; eap@frascone.com > > Cc: Yael Dayan > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > We did attempt to put some words in 802.1aa/D4 around this topic. > > I'm not sure they were exactly what was needed, so there maybe some > > slight re-wording in 802.1aa/D5 when it comes out this week. Have a > > look and see > > if your issue is still not properly addressed. > > > > Paul > > > > -----Original Message----- > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > Sent: Sunday, April 27, 2003 9:14 AM > > To: eap@frascone.com > > Cc: Yael Dayan > > Subject: [eap] FW: peer-to-peer mutual authentication > > > > > > [I'm resending this message since it seems the original got lost - > > sorry if any of you got it the second time] > > > > Description of issue > > Submitter name: Dror Caspi > > Submitter email address: dror_caspi@atrica.com > > Date first submitted: April 21, 2003 > > Reference: > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, > IEEE-802.1aa Comment > type: Technical > Priority: '2' May fix > Section: N/A > Rationale/Explanation of issue: > > Having looked at the drafts of RFC2284bis, EAP-Archie and > IEEE-802.1aa, it seems that most of the attention is given to > systems where there is a distinction between an authenticator > and a peer/supplicant. This distinction still exists even > where mutual authentication is proposed (e.g., EAP-Archie). > > But what happens when both parties are peers (e.g., two > bridge devices)? The possibility of role reversal is > mentioned (i.e., run a session where one system is > Authenticator and the other Peer, and then reverse the role). > However it seems quite cumbersome; a single session of a > protocol such as EAP-Archie would seem to provide the > required authentication - yet there needs to be a mechanism > to (randomly?) decide which party plays which role. > > Probably some of the above is misunderstanding on my part. > However there seems to be a need for some explanatory text in > the standards, if not for actual changes to accomodate > peer-to-peer mutual authentication. > > Requested change: > > Add explanatory text about peer-to-peer mutual > authentication. Modify the standards if required. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From sgoswami@umich.edu Mon Apr 28 16:27:14 2003 From: sgoswami@umich.edu (Subrata Goswami) Date: Mon, 28 Apr 2003 08:27:14 -0700 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: <499DC368E25AD411B3F100902740AD65129928E4@xrose03.rose.hp.com> Message-ID: <001801c30d9a$a5554760$0300a8c0@SGOSWAMIPCL> If two authenticators connect, neither would send an EAPOL-Start type message. Also EAPOL messages are outside the EAP framework - correct ? So EAP need to have a way of its own to determine who would be the authenticator. Also , there is the issue of is one being the authenticator the same as the other being the authenticator ? This assumption of equality of authenticators is not correct as the authentication mechanism that can be used is different. Subrata > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: Monday, April 28, 2003 8:14 AM > To: 'Subrata Goswami'; eap@frascone.com > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > If the underlying link layer is 802.1X, then it is pretty > clear who is supplicant and who is authenticator since the > supplicant sends EAPOL-Start messages. If someone who is > interested in playing either role receives an EAPOL-Start, it > may play the role of authenticator. > > Paul > > -----Original Message----- > From: Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Monday, April 28, 2003 7:41 AM > To: eap@frascone.com > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > Does not the Supplicant know that it is trying to join an > infrastructure network ? In other words, the EAP > Authenticator sends an Request Identity packet as soon as it > sees a Supplicant connecting to it. There would be a race > condition (or conflict) when two EAP Authenticators try to > connect to each other. Such a situation can arise when two > isolated networks try to connect to each other. This can be > solved by the usual random back-off technique. > > In other words the following table shows the situation for > connecting entities of two networks. > > Network 1 Entity Network 2 Entity Behavior > =============================================================== > Supplicant Supplicant Can not connect > Supplicant Authenticator 2 sends > Request Identity > packet to 1 > Authenticator Supplicant 1 sends > Request Identity > packet to 2 > Authenticator Authenticator 1 and 2 sends Request > Identity packet after random time. > > > Subrata > > > > -----Original Message----- > > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com] On Behalf > > Of Dror Caspi > > Sent: Sunday, April 27, 2003 11:22 PM > > To: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com > > Cc: Yael Dayan > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > > misunderstood some of the text it is still problematic. > > > > - The suggested method in the text for peers (e.g., two > > bridges) is to play both > > Authenticatior and Supplicant. Such systems should be > prepared for > > role > > reversal. > > - However the text clearly notes that from the two one-way > > authentication > > exchanges in each direction are not equivalent to a single > > mutual authentication > > exchange. > > - The text also notes that EAP methods that perform mutual > > authentication can be > > used - and that the Supplicant action at the end of such > > exchange is currently > > undefined. > > > > So based on the above, what I would really like to do is > use a single > > exchange with a mutual authentication method (e.g., > EAP-Archie). But > > then how do you decide on who plays the Authenticator and who plays > > the Supplicant? - both sides are equal peers. One way we > thought of > > was for both peers start as Authenticator and do some > pseudo-random > > decision - say based on the highest MAC address or highest > > pseudo-random NONCE value sent as part of the initial EAP request. > > > > However I am not sure that the above is still within the standard - > > i.e., if we implement this (say as a proprietary EAP > method) it would > > still fit within the 802.1aa/D5 and RFC2284bis framework. > > > > Dror > > > > > > > -----Original Message----- > > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > > Sent: Monday, April 28, 2003 7:22 AM > > > To: Dror Caspi; eap@frascone.com > > > Cc: Yael Dayan > > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > > > > We did attempt to put some words in 802.1aa/D4 around this topic. > > > I'm not sure they were exactly what was needed, so there > maybe some > > > slight re-wording in 802.1aa/D5 when it comes out this > week. Have a > > > look and see if your issue is still not properly addressed. > > > > > > Paul > > > > > > -----Original Message----- > > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > > Sent: Sunday, April 27, 2003 9:14 AM > > > To: eap@frascone.com > > > Cc: Yael Dayan > > > Subject: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > [I'm resending this message since it seems the original > got lost - > > > sorry if any of you got it the second time] > > > > > > Description of issue > > > Submitter name: Dror Caspi > > > Submitter email address: dror_caspi@atrica.com > > > Date first submitted: April 21, 2003 > > > Reference: > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, > IEEE-802.1aa > > Comment > > type: Technical > > Priority: '2' May fix > > Section: N/A > > Rationale/Explanation of issue: > > > > Having looked at the drafts of RFC2284bis, EAP-Archie and > > IEEE-802.1aa, it seems that most of the attention is given > to systems > > where there is a distinction between an authenticator and a > > peer/supplicant. This distinction still exists even where mutual > > authentication is proposed (e.g., EAP-Archie). > > > > But what happens when both parties are peers (e.g., two bridge > > devices)? The possibility of role reversal is mentioned > (i.e., run a > > session where one system is Authenticator and the other > Peer, and then > > reverse the role). However it seems quite cumbersome; a > single session > > of a protocol such as EAP-Archie would seem to provide the > > required authentication - yet there needs to be a mechanism > > to (randomly?) decide which party plays which role. > > > > Probably some of the above is misunderstanding on my part. However > > there seems to be a need for some explanatory text in the > standards, > > if not for actual changes to accomodate peer-to-peer mutual > > authentication. > > > > Requested change: > > > > Add explanatory text about peer-to-peer mutual > authentication. Modify > > the standards if required. > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From sgoswami@umich.edu Mon Apr 28 17:04:38 2003 From: sgoswami@umich.edu (Subrata Goswami) Date: Mon, 28 Apr 2003 09:04:38 -0700 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: <499DC368E25AD411B3F100902740AD65129928EA@xrose03.rose.hp.com> Message-ID: <001b01c30d9f$deee5bb0$0300a8c0@SGOSWAMIPCL> The second question (or point) has to be do with the authentication mechanism used by either authenticators. The strength of authentication mechanisms are different, hence a rouge authenticator can potentially fool the other authenticator to be the supplicant or use a less strong authentication mechanism. Suppose Authenticator 1 can only use PAP, whereas Authenticator 2 understands both PAP and Certificates. The election mechanism could elect the strongest authentication, and it may happen that the elected supplicant may not have the certificates. So now the authenticators know that they have to go down to PAP. As they are equal now, either can be the authenticator. Even in this situation the elected supplicant may not have the security credentials, so now the authenticators can reverse their roles and try again. Here a rouge authenticator can just let the peer in and explorer the peer's network at will. Subrata > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: Monday, April 28, 2003 8:36 AM > To: 'Subrata Goswami'; eap@frascone.com > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > >If two authenticators connect, neither would send an EAPOL-Start type > message. Also EAPOL messages are outside the EAP > >framework - correct ? So EAP need to have a way of its own > to determine > >who > would be the authenticator. > > > > Correct that EAPOL is outside of EAP, but could offer a link > layer solution to the problem. Presummably a node capabile > of being both supplicant and authenticator would act as both > and send EAPOL-Start messages. An infrastructure device > would seem to be the one wanting to act as either/both. > > >Also , there is the issue of is one being the authenticator > the same > >as > the other being the authenticator ? This > >assumption of equality of authenticators is not correct as the > authentication mechanism that can be used is different. > > Don't fully understand the question, but neither EAP nor > EAPOL (802.1X) are symmetric in how the conversation is > driven and takes place. An election process or set of rules > as described earlier would seem to offer the best approach > for selecting the one who will drive the conversation given > the current framework. > > Paul > > > -----Original Message----- > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > Sent: Monday, April 28, 2003 8:14 AM > > To: 'Subrata Goswami'; eap@frascone.com > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > If the underlying link layer is 802.1X, then it is pretty > clear who is > > supplicant and who is authenticator since the supplicant sends > > EAPOL-Start messages. If someone who is interested in > playing either > > role receives an EAPOL-Start, it may play the role of authenticator. > > > > Paul > > > > -----Original Message----- > > From: Subrata Goswami [mailto:sgoswami@umich.edu] > > Sent: Monday, April 28, 2003 7:41 AM > > To: eap@frascone.com > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > Does not the Supplicant know that it is trying to join an > > infrastructure network ? In other words, the EAP > Authenticator sends > > an Request Identity packet as soon as it sees a Supplicant > connecting > > to it. There would be a race condition (or conflict) when two EAP > > Authenticators try to connect to each other. Such a situation can > > arise when two isolated networks try to connect to each other. This > > can be solved by the usual random back-off technique. > > > > In other words the following table shows the situation for > connecting > > entities of two networks. > > > > Network 1 Entity Network 2 Entity Behavior > > =============================================================== > > Supplicant Supplicant Can not connect > > Supplicant Authenticator 2 sends > > Request Identity > > packet to 1 > > Authenticator Supplicant 1 sends > > Request Identity > > packet to 2 > > Authenticator Authenticator 1 and 2 > sends Request > > Identity packet after random time. > > > > > > Subrata > > > > > > > -----Original Message----- > > > From: eap-admin@frascone.com > > [mailto:eap-admin@frascone.com] On Behalf > > > Of Dror Caspi > > > Sent: Sunday, April 27, 2003 11:22 PM > > > To: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com > > > Cc: Yael Dayan > > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > > > misunderstood some of the text it is still problematic. > > > > > > - The suggested method in the text for peers (e.g., two > > > bridges) is to play both > > > Authenticatior and Supplicant. Such systems should be > > prepared for > > > role > > > reversal. > > > - However the text clearly notes that from the two one-way > > > authentication > > > exchanges in each direction are not equivalent to a single > > > mutual authentication > > > exchange. > > > - The text also notes that EAP methods that perform mutual > > > authentication can be > > > used - and that the Supplicant action at the end of such > > > exchange is currently > > > undefined. > > > > > > So based on the above, what I would really like to do is > > use a single > > > exchange with a mutual authentication method (e.g., > > EAP-Archie). But > > > then how do you decide on who plays the Authenticator and > who plays > > > the Supplicant? - both sides are equal peers. One way we > > thought of > > > was for both peers start as Authenticator and do some > > pseudo-random > > > decision - say based on the highest MAC address or highest > > > pseudo-random NONCE value sent as part of the initial EAP request. > > > > > > However I am not sure that the above is still within the > standard - > > > i.e., if we implement this (say as a proprietary EAP > > method) it would > > > still fit within the 802.1aa/D5 and RFC2284bis framework. > > > > > > Dror > > > > > > > > > > -----Original Message----- > > > > From: CONGDON,PAUL (HP-Roseville,ex1) > [mailto:paul.congdon@hp.com] > > > > Sent: Monday, April 28, 2003 7:22 AM > > > > To: Dror Caspi; eap@frascone.com > > > > Cc: Yael Dayan > > > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > > > > > > > > We did attempt to put some words in 802.1aa/D4 around > this topic. > > > > I'm not sure they were exactly what was needed, so there > > maybe some > > > > slight re-wording in 802.1aa/D5 when it comes out this > > week. Have a > > > > look and see if your issue is still not properly addressed. > > > > > > > > Paul > > > > > > > > -----Original Message----- > > > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > > > Sent: Sunday, April 27, 2003 9:14 AM > > > > To: eap@frascone.com > > > > Cc: Yael Dayan > > > > Subject: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > > > > [I'm resending this message since it seems the original > > got lost - > > > > sorry if any of you got it the second time] > > > > > > > > Description of issue > > > > Submitter name: Dror Caspi > > > > Submitter email address: dror_caspi@atrica.com > > > > Date first submitted: April 21, 2003 > > > > Reference: > > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > > > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, > > IEEE-802.1aa > > > Comment > > > type: Technical > > > Priority: '2' May fix > > > Section: N/A > > > Rationale/Explanation of issue: > > > > > > Having looked at the drafts of RFC2284bis, EAP-Archie and > > > IEEE-802.1aa, it seems that most of the attention is given > > to systems > > > where there is a distinction between an authenticator and a > > > peer/supplicant. This distinction still exists even where mutual > > > authentication is proposed (e.g., EAP-Archie). > > > > > > But what happens when both parties are peers (e.g., two bridge > > > devices)? The possibility of role reversal is mentioned > > (i.e., run a > > > session where one system is Authenticator and the other > > Peer, and then > > > reverse the role). However it seems quite cumbersome; a > > single session > > > of a protocol such as EAP-Archie would seem to provide > the required > > > authentication - yet there needs to be a mechanism to (randomly?) > > > decide which party plays which role. > > > > > > Probably some of the above is misunderstanding on my part. However > > > there seems to be a need for some explanatory text in the > > standards, > > > if not for actual changes to accomodate peer-to-peer mutual > > > authentication. > > > > > > Requested change: > > > > > > Add explanatory text about peer-to-peer mutual > > authentication. Modify > > > the standards if required. > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > From paul.congdon@hp.com Mon Apr 28 05:22:02 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Mon, 28 Apr 2003 00:22:02 -0400 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: <499DC368E25AD411B3F100902740AD65129928D5@xrose03.rose.hp.com> We did attempt to put some words in 802.1aa/D4 around this topic. I'm not sure they were exactly what was needed, so there maybe some slight re-wording in 802.1aa/D5 when it comes out this week. Have a look and see if your issue is still not properly addressed. Paul -----Original Message----- From: Dror Caspi [mailto:dror_caspi@atrica.com] Sent: Sunday, April 27, 2003 9:14 AM To: eap@frascone.com Cc: Yael Dayan Subject: [eap] FW: peer-to-peer mutual authentication [I'm resending this message since it seems the original got lost - sorry if any of you got it the second time] Description of issue Submitter name: Dror Caspi Submitter email address: dror_caspi@atrica.com Date first submitted: April 21, 2003 Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa Comment type: Technical Priority: '2' May fix Section: N/A Rationale/Explanation of issue: Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa, it seems that most of the attention is given to systems where there is a distinction between an authenticator and a peer/supplicant. This distinction still exists even where mutual authentication is proposed (e.g., EAP-Archie). But what happens when both parties are peers (e.g., two bridge devices)? The possibility of role reversal is mentioned (i.e., run a session where one system is Authenticator and the other Peer, and then reverse the role). However it seems quite cumbersome; a single session of a protocol such as EAP-Archie would seem to provide the required authentication - yet there needs to be a mechanism to (randomly?) decide which party plays which role. Probably some of the above is misunderstanding on my part. However there seems to be a need for some explanatory text in the standards, if not for actual changes to accomodate peer-to-peer mutual authentication. Requested change: Add explanatory text about peer-to-peer mutual authentication. Modify the standards if required. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From paul.congdon@hp.com Mon Apr 28 07:47:04 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Sun, 27 Apr 2003 23:47:04 -0700 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: <499DC368E25AD411B3F100902740AD65129928DD@xrose03.rose.hp.com> The current draft under development (not yet published) suggests making a change to the item below >- The text also notes that EAP methods that perform mutual authentication can be > used - and that the Supplicant action at the end of such exchange is currently > undefined. It indicates what the supplicant should do, and from my understanding, 802.11i will go a step further and indicate that the supplicant must take appropriate action. We haven't gone as far as create a purely symmetrical 802.1X with controlled ports on both sides, as the LinkSec group would likely want to do, but we have created a portStatus variable on the Supplicant that can be used for this purpose. I believe 802.11i will take advantage of this. >So based on the above, what I would really like to do is use a single exchange with a mutual authentication method (e.g., >EAP-Archie). But then how do you decide on who plays the Authenticator and who plays the Supplicant? - both sides are >equal peers. One way we thought of was for both peers start as Authenticator and do some pseudo-random decision - say >based on the highest MAC address or highest pseudo-random NONCE value sent as part of the initial EAP request. > >However I am not sure that the above is still within the standard - i.e., if we implement this (say as a proprietary EAP>Lmethod) it would still fit within the 802.1aa/D5 and RFC2284bis framework. This doesn't sound like it is within what rfc2284bis would support. EAP is still very one-sided in who is driving the conversation. Paul > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: Monday, April 28, 2003 7:22 AM > To: Dror Caspi; eap@frascone.com > Cc: Yael Dayan > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > We did attempt to put some words in 802.1aa/D4 around this > topic. I'm not > sure they were exactly what was needed, so there maybe some slight > re-wording in 802.1aa/D5 when it comes out this week. Have a > look and see > if your issue is still not properly addressed. > > Paul > > -----Original Message----- > From: Dror Caspi [mailto:dror_caspi@atrica.com] > Sent: Sunday, April 27, 2003 9:14 AM > To: eap@frascone.com > Cc: Yael Dayan > Subject: [eap] FW: peer-to-peer mutual authentication > > > [I'm resending this message since it seems the original got > lost - sorry if > any of you got it the second time] > > Description of issue > Submitter name: Dror Caspi > Submitter email address: dror_caspi@atrica.com > Date first submitted: April 21, 2003 > Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa Comment type: Technical Priority: '2' May fix Section: N/A Rationale/Explanation of issue: Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa, it seems that most of the attention is given to systems where there is a distinction between an authenticator and a peer/supplicant. This distinction still exists even where mutual authentication is proposed (e.g., EAP-Archie). But what happens when both parties are peers (e.g., two bridge devices)? The possibility of role reversal is mentioned (i.e., run a session where one system is Authenticator and the other Peer, and then reverse the role). However it seems quite cumbersome; a single session of a protocol such as EAP-Archie would seem to provide the required authentication - yet there needs to be a mechanism to (randomly?) decide which party plays which role. Probably some of the above is misunderstanding on my part. However there seems to be a need for some explanatory text in the standards, if not for actual changes to accomodate peer-to-peer mutual authentication. Requested change: Add explanatory text about peer-to-peer mutual authentication. Modify the standards if required. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From paul.congdon@hp.com Mon Apr 28 16:13:50 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Mon, 28 Apr 2003 11:13:50 -0400 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: <499DC368E25AD411B3F100902740AD65129928E4@xrose03.rose.hp.com> If the underlying link layer is 802.1X, then it is pretty clear who is supplicant and who is authenticator since the supplicant sends EAPOL-Start messages. If someone who is interested in playing either role receives an EAPOL-Start, it may play the role of authenticator. Paul -----Original Message----- From: Subrata Goswami [mailto:sgoswami@umich.edu] Sent: Monday, April 28, 2003 7:41 AM To: eap@frascone.com Subject: RE: [eap] FW: peer-to-peer mutual authentication Does not the Supplicant know that it is trying to join an infrastructure network ? In other words, the EAP Authenticator sends an Request Identity packet as soon as it sees a Supplicant connecting to it. There would be a race condition (or conflict) when two EAP Authenticators try to connect to each other. Such a situation can arise when two isolated networks try to connect to each other. This can be solved by the usual random back-off technique. In other words the following table shows the situation for connecting entities of two networks. Network 1 Entity Network 2 Entity Behavior =============================================================== Supplicant Supplicant Can not connect Supplicant Authenticator 2 sends Request Identity packet to 1 Authenticator Supplicant 1 sends Request Identity packet to 2 Authenticator Authenticator 1 and 2 sends Request Identity packet after random time. Subrata > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf > Of Dror Caspi > Sent: Sunday, April 27, 2003 11:22 PM > To: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com > Cc: Yael Dayan > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > misunderstood some of the text it is still problematic. > > - The suggested method in the text for peers (e.g., two > bridges) is to play both > Authenticatior and Supplicant. Such systems should be > prepared for role > reversal. > - However the text clearly notes that from the two one-way > authentication > exchanges in each direction are not equivalent to a single > mutual authentication > exchange. > - The text also notes that EAP methods that perform mutual > authentication can be > used - and that the Supplicant action at the end of such > exchange is currently > undefined. > > So based on the above, what I would really like to do is use a single > exchange with a mutual authentication method (e.g., EAP-Archie). But > then how do you decide on who plays the Authenticator and who plays > the Supplicant? - both sides are equal peers. One way we thought of > was for both peers start as Authenticator and do some pseudo-random > decision - say based on the highest MAC address or highest > pseudo-random NONCE value sent as part of the initial EAP request. > > However I am not sure that the above is still within the standard - > i.e., if we implement this (say as a proprietary EAP method) it would > still fit within the 802.1aa/D5 and RFC2284bis framework. > > Dror > > > > -----Original Message----- > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > Sent: Monday, April 28, 2003 7:22 AM > > To: Dror Caspi; eap@frascone.com > > Cc: Yael Dayan > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > We did attempt to put some words in 802.1aa/D4 around this topic. > > I'm not sure they were exactly what was needed, so there maybe some > > slight re-wording in 802.1aa/D5 when it comes out this week. Have a > > look and see > > if your issue is still not properly addressed. > > > > Paul > > > > -----Original Message----- > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > Sent: Sunday, April 27, 2003 9:14 AM > > To: eap@frascone.com > > Cc: Yael Dayan > > Subject: [eap] FW: peer-to-peer mutual authentication > > > > > > [I'm resending this message since it seems the original got lost - > > sorry if any of you got it the second time] > > > > Description of issue > > Submitter name: Dror Caspi > > Submitter email address: dror_caspi@atrica.com > > Date first submitted: April 21, 2003 > > Reference: > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, > IEEE-802.1aa Comment > type: Technical > Priority: '2' May fix > Section: N/A > Rationale/Explanation of issue: > > Having looked at the drafts of RFC2284bis, EAP-Archie and > IEEE-802.1aa, it seems that most of the attention is given to systems > where there is a distinction between an authenticator and a > peer/supplicant. This distinction still exists even where mutual > authentication is proposed (e.g., EAP-Archie). > > But what happens when both parties are peers (e.g., two bridge > devices)? The possibility of role reversal is mentioned (i.e., run a > session where one system is Authenticator and the other Peer, and then > reverse the role). However it seems quite cumbersome; a single session > of a protocol such as EAP-Archie would seem to provide the > required authentication - yet there needs to be a mechanism > to (randomly?) decide which party plays which role. > > Probably some of the above is misunderstanding on my part. However > there seems to be a need for some explanatory text in the standards, > if not for actual changes to accomodate peer-to-peer mutual > authentication. > > Requested change: > > Add explanatory text about peer-to-peer mutual authentication. Modify > the standards if required. > _______________________________________________ > eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From paul.congdon@hp.com Mon Apr 28 16:35:35 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Mon, 28 Apr 2003 11:35:35 -0400 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: <499DC368E25AD411B3F100902740AD65129928EA@xrose03.rose.hp.com> >If two authenticators connect, neither would send an EAPOL-Start type message. Also EAPOL messages are outside the EAP >framework - correct ? So EAP need to have a way of its own to determine who would be the authenticator. > Correct that EAPOL is outside of EAP, but could offer a link layer solution to the problem. Presummably a node capabile of being both supplicant and authenticator would act as both and send EAPOL-Start messages. An infrastructure device would seem to be the one wanting to act as either/both. >Also , there is the issue of is one being the authenticator the same as the other being the authenticator ? This >assumption of equality of authenticators is not correct as the authentication mechanism that can be used is different. Don't fully understand the question, but neither EAP nor EAPOL (802.1X) are symmetric in how the conversation is driven and takes place. An election process or set of rules as described earlier would seem to offer the best approach for selecting the one who will drive the conversation given the current framework. Paul > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: Monday, April 28, 2003 8:14 AM > To: 'Subrata Goswami'; eap@frascone.com > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > If the underlying link layer is 802.1X, then it is pretty > clear who is supplicant and who is authenticator since the > supplicant sends EAPOL-Start messages. If someone who is > interested in playing either role receives an EAPOL-Start, it > may play the role of authenticator. > > Paul > > -----Original Message----- > From: Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Monday, April 28, 2003 7:41 AM > To: eap@frascone.com > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > Does not the Supplicant know that it is trying to join an > infrastructure network ? In other words, the EAP > Authenticator sends an Request Identity packet as soon as it > sees a Supplicant connecting to it. There would be a race > condition (or conflict) when two EAP Authenticators try to > connect to each other. Such a situation can arise when two > isolated networks try to connect to each other. This can be > solved by the usual random back-off technique. > > In other words the following table shows the situation for > connecting entities of two networks. > > Network 1 Entity Network 2 Entity Behavior > =============================================================== > Supplicant Supplicant Can not connect > Supplicant Authenticator 2 sends > Request Identity > packet to 1 > Authenticator Supplicant 1 sends > Request Identity > packet to 2 > Authenticator Authenticator 1 and 2 sends Request > Identity packet after random time. > > > Subrata > > > > -----Original Message----- > > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com] On Behalf > > Of Dror Caspi > > Sent: Sunday, April 27, 2003 11:22 PM > > To: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com > > Cc: Yael Dayan > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > > misunderstood some of the text it is still problematic. > > > > - The suggested method in the text for peers (e.g., two > > bridges) is to play both > > Authenticatior and Supplicant. Such systems should be > prepared for > > role > > reversal. > > - However the text clearly notes that from the two one-way > > authentication > > exchanges in each direction are not equivalent to a single > > mutual authentication > > exchange. > > - The text also notes that EAP methods that perform mutual > > authentication can be > > used - and that the Supplicant action at the end of such > > exchange is currently > > undefined. > > > > So based on the above, what I would really like to do is > use a single > > exchange with a mutual authentication method (e.g., > EAP-Archie). But > > then how do you decide on who plays the Authenticator and who plays > > the Supplicant? - both sides are equal peers. One way we > thought of > > was for both peers start as Authenticator and do some > pseudo-random > > decision - say based on the highest MAC address or highest > > pseudo-random NONCE value sent as part of the initial EAP request. > > > > However I am not sure that the above is still within the standard - > > i.e., if we implement this (say as a proprietary EAP > method) it would > > still fit within the 802.1aa/D5 and RFC2284bis framework. > > > > Dror > > > > > > > -----Original Message----- > > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > > Sent: Monday, April 28, 2003 7:22 AM > > > To: Dror Caspi; eap@frascone.com > > > Cc: Yael Dayan > > > Subject: RE: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > > > > We did attempt to put some words in 802.1aa/D4 around this topic. > > > I'm not sure they were exactly what was needed, so there > maybe some > > > slight re-wording in 802.1aa/D5 when it comes out this > week. Have a > > > look and see if your issue is still not properly addressed. > > > > > > Paul > > > > > > -----Original Message----- > > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > > Sent: Sunday, April 27, 2003 9:14 AM > > > To: eap@frascone.com > > > Cc: Yael Dayan > > > Subject: [eap] FW: peer-to-peer mutual authentication > > > > > > > > > [I'm resending this message since it seems the original > got lost - > > > sorry if any of you got it the second time] > > > > > > Description of issue > > > Submitter name: Dror Caspi > > > Submitter email address: dror_caspi@atrica.com > > > Date first submitted: April 21, 2003 > > > Reference: > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, > IEEE-802.1aa > > Comment > > type: Technical > > Priority: '2' May fix > > Section: N/A > > Rationale/Explanation of issue: > > > > Having looked at the drafts of RFC2284bis, EAP-Archie and > > IEEE-802.1aa, it seems that most of the attention is given > to systems > > where there is a distinction between an authenticator and a > > peer/supplicant. This distinction still exists even where mutual > > authentication is proposed (e.g., EAP-Archie). > > > > But what happens when both parties are peers (e.g., two bridge > > devices)? The possibility of role reversal is mentioned > (i.e., run a > > session where one system is Authenticator and the other > Peer, and then > > reverse the role). However it seems quite cumbersome; a > single session > > of a protocol such as EAP-Archie would seem to provide the required > > authentication - yet there needs to be a mechanism to (randomly?) > > decide which party plays which role. > > > > Probably some of the above is misunderstanding on my part. However > > there seems to be a need for some explanatory text in the > standards, > > if not for actual changes to accomodate peer-to-peer mutual > > authentication. > > > > Requested change: > > > > Add explanatory text about peer-to-peer mutual > authentication. Modify > > the standards if required. > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > _______________________________________________ > eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > From Pasi.Eronen@nokia.com Mon Apr 28 19:17:30 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 28 Apr 2003 21:17:30 +0300 Subject: [eap] Re: Issue 113: Rewrite of Security Considerations Section Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122276@esebe023.ntc.nokia.com> Hi, In a message earlier today, I commented that the cryptographic separation of MK and MSK might be unnecessarily restrictive in some cases. It seems that the requirement that TEKs are cryptographically separate from TSKs (and thus cryptographically separate from MSK) is also be too restrictive, and actually might prohibit certain types of completely sound EAP methods (e.g. DLC-based key transport from NIST 800-56 draft). Thus, I'm beginning to feel that we should avoid discussion of how the keys are derived in this document (especially when that discussion contains MUSTs or MUST NOTs). Also, there is some duplication between section 7.10 and 7.13, so I decided to try to rephrase it. Here's a proposed replacement for section 7.10: "7.10 Key derivation It is possible for the peer and EAP server to mutually authenticate, and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a 64 octet Master Session Key (MSK), and a 64 octet Extended Master Session Key (EMSK), and MAY export a 64 octet Initialization Vector (IV). MSK, EMSK, and IVs are not used directly to protect data; however, they are of sufficient size to enable subsequent derivation of Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the MSK. EAP methods provide Master Session Keys and not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media. The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.) This specification does not provide detailed guidance on how EAP methods are to derive the MSK, EMSK and IV. Key derivation is an art that is best practiced by professionals; rather than inventing new key derivation algorithms, reuse of existing algorithms such as those specified in IKE [RFC2409], or TLS [RFC2246] is recommended." (I also added more restrictive text about EMSK; the previous version could be read to allow any use except as-is transportation to third parties) Best regards, Pasi From Internet-Drafts@ietf.org Mon Apr 28 19:21:31 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 28 Apr 2003 14:21:31 -0400 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-02.txt Message-ID: <200304281821.OAA09327@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-02.txt Pages : 52 Date : 2003-4-25 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP, but is reliant on lower layer ordering guarantees as in PPP and IEEE 802. EAP does provide its own support for duplicate elimination and retransmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in the 'Change Log' Appendix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-25120801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-25120801.I-D@ietf.org> --OtherAccess-- --NextPart-- From Pasi.Eronen@nokia.com Mon Apr 28 19:37:41 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 28 Apr 2003 21:37:41 +0300 Subject: [eap] (Issue 113) Small nits about new section 7.2 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BACF@esebe023.ntc.nokia.com> Couple of small proposals for section 7.2:=20 - Remove "key strength" from the list in [c] (no need to=20 mention it twice) - Move the key strength definition back from terminology to [d]=20 like it was in -02. The following paragraph doesn't make much=20 sense otherwise (actually, we don't need to include it in the=20 terminology section since it's not used anywhere else in this document). - Replace "...to achieve N bits of entropy..." with=20 "...to achieve the stated key strength...", and=20 "..by the entropy of the long-term secret..." with "..by the strength of the long-term secret..."=20 (since technically, the (Shannon) entropy of both=20 of them is very likely to be zero bits) Best regards, Pasi From aboba@internaut.com Mon Apr 28 21:38:06 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 13:38:06 -0700 (PDT) Subject: [eap] Re: Issue 113: Rewrite of Security Considerations Section In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122276@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122276@esebe023.ntc.nokia.com> Message-ID: > In a message earlier today, I commented that the cryptographic > separation of MK and MSK might be unnecessarily restrictive in > some cases. Are you saying that there is no problem if possession of the MSK allows the recovery of the MK by methods more efficient than brute force? Since the MK is the residual of a successful authentication, if fast resume or fast handoff is supported, then once obtained, the MK allows an attacker to impersonate the EAP peer in attaching to another NAS. So the compromise of the MK has considerable impact. If one can get from the MSK to the MK, then any NAS (or a proxy for that matter) that has access to any MSK could potentially impersonate the EAP peer and gain access elsewhere. That seems undesirable. > It seems that the requirement that TEKs are cryptographically > separate from TSKs (and thus cryptographically separate from > MSK) is also be too restrictive, and actually might prohibit > certain types of completely sound EAP methods (e.g. DLC-based > key transport from NIST 800-56 draft). Are you saying that based on capture the EAP conversation, it should be possible to recover the transient session keys used to protect data by methods more efficient than brute force? The TSKs are only used for a particular session at a particular NAS, so their compromise isn't as serious as compromise of the MKs. However, if one can go from the TSKs to the TEKs, then the next step would be compromise the MK. So it still seems to me that you'd want these quantities to be cryptographically separate. > Thus, I'm beginning to feel that we should avoid discussion of > how the keys are derived in this document (especially when that > discussion contains MUSTs or MUST NOTs). I think there are two issues here -- one is whether some of the material in Section 7 belongs elsewhere (such as the Key Framework document). Another issue is whether it belongs anywhere. In terms of deciding what material belongs in at least one document, the Security ADs have prepared a list of requirements that EAP/AAA documents must satisfy in order to survive IESG review: http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt On slide 5, there are two requirements that appear relevant to the issue of cryptographic separation: 2. "Maintain confidentiality of session keys" 3. "Compromise of a single NAS cannot compromise any other part of the system, including session keys and long term keys" I interpret #2 to relate to key wrap as well as to the ability to recover session keys based on passive eavesdropping or active attacks such as offline dictionary attack. My interpretation of #3 is that this is mandating PFS between NASes, as well as inability to recover other keys based on compromise of the MSK. We could of course leave much of this discussion to the Key Framework document, but then it would be hard to argue that it should be Informational, since it would contain requirements that were not present in RFC 2284bis, that are needed to meet the security guidelines. >I've added language about the EMSK... This looks pretty good. From aboba@internaut.com Tue Apr 29 06:34:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 22:34:59 -0700 (PDT) Subject: [eap] Re: Issue 113: Rewrite of Security Considerations Section In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122276@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122276@esebe023.ntc.nokia.com> Message-ID: > In a message earlier today, I commented that the cryptographic > separation of MK and MSK might be unnecessarily restrictive in > some cases. You're right. The definition of "cryptographic separation" we're using requires that that the MSK not be derivable from the MK, as well as the other way around. This *is* too strict. All we really need is that the MK not be derivable from the MSK. Perhaps we need another term for this? > It seems that the requirement that TEKs are cryptographically > separate from TSKs (and thus cryptographically separate from > MSK) is also be too restrictive The TSKs are *not* cryptographically separate from the MSK typically, since the TSKs are derived from the MSK. However, the TEKs and TSKs are on separate branches of the key hierarchy, so I think they *do* meet the definition of cryptographic separation. Is that right?? From aboba@internaut.com Tue Apr 29 07:14:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Apr 2003 23:14:58 -0700 (PDT) Subject: [eap] Re: (Issue 113) Small nits about new section 7.2 Message-ID: Thanks. I've reflected these changes in the revised text of Issue 113 on the EAP Issues web page: http://www.drizzle.com/~aboba/EAP/eapissues.html In this revised text, I've also cleaned up section 7.10. ----------------------------------------------------------- Couple of small proposals for section 7.2: - Remove "key strength" from the list in [c] (no need to mention it twice) - Move the key strength definition back from terminology to [d] like it was in -02. The following paragraph doesn't make much sense otherwise (actually, we don't need to include it in the terminology section since it's not used anywhere else in this document). - Replace "...to achieve N bits of entropy..." with "...to achieve the stated key strength...", and "..by the entropy of the long-term secret..." with "..by the strength of the long-term secret..." (since technically, the (Shannon) entropy of both of them is very likely to be zero bits) Best regards, Pasi From Pasi.Eronen@nokia.com Tue Apr 29 09:08:38 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 29 Apr 2003 11:08:38 +0300 Subject: [eap] RE: Issue 113: Rewrite of Security Considerations Section Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BAD0@esebe023.ntc.nokia.com> Hi, See comments inline. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, April 28, 2003 11:38 PM > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: Re: Issue 113: Rewrite of Security Considerations Section >=20 >=20 > > In a message earlier today, I commented that the cryptographic > > separation of MK and MSK might be unnecessarily restrictive in > > some cases. >=20 > Are you saying that there is no problem if possession of the MSK > allows the recovery of the MK by methods more efficient than brute > force? Since the MK is the residual of a successful authentication, > if fast resume or fast handoff is supported, then once obtained, the > MK allows an attacker to impersonate the EAP peer in attaching to > another NAS. So the compromise of the MK has considerable impact. If > one can get from the MSK to the MK, then any NAS (or a proxy for > that matter) that has access to any MSK could potentially > impersonate the EAP peer and gain access elsewhere. That seems > undesirable. MK is currently defined to be internal to a method, so the method knows exactly what it is used for. If the compromise of MK doesn't allow anything worse than compromise of MSK, then it doesn't matter if MSK would help in recovering MK. If the method uses MK for fast resume (again, something internal to a method), it knows this, and then it has to ensure that MSK does't help in recoving MK. If we change that so that the MK can be exported by the method to some unforeseen use (e.g. to some "fast handoff" protocol), then it becomes necessary for all methods to do this. However, this is probably a very bad idea, since this would make the derivation of "fast handoff keys" from MK method-specific (something that we would like to avoid; these keys should probably be derived from EMSK). > > It seems that the requirement that TEKs are cryptographically > > separate from TSKs (and thus cryptographically separate from > > MSK) is also be too restrictive, and actually might prohibit > > certain types of completely sound EAP methods (e.g. DLC-based > > key transport from NIST 800-56 draft). >=20 > Are you saying that based on capture the EAP conversation, it > should be possible to recover the transient session keys used > to protect data by methods more efficient than brute force? > > The TSKs are only used for a particular session at a > particular NAS, so their compromise isn't as serious as > compromise of the MKs. However, if one can go from the TSKs to > the TEKs, then the next step would be compromise the MK. So it > still seems to me that you'd want these quantities to be > cryptographically separate. No, of course not :) I intended to say that in some perfectly good protocols, knowing TEKs allows you to recover the MSK (and thus TSKs). Naturally, then it must not be possible to recover TEKs from the EAP conversation (more efficiently than brute force). > > Thus, I'm beginning to feel that we should avoid discussion of > > how the keys are derived in this document (especially when that > > discussion contains MUSTs or MUST NOTs). >=20 > I think there are two issues here -- one is whether some of > the material in Section 7 belongs elsewhere (such as the Key > Framework document). Another issue is whether it belongs > anywhere. >=20 > In terms of deciding what material belongs in at least one > document, the Security ADs have prepared a list of > requirements that EAP/AAA documents must satisfy in order to > survive IESG review: >=20 > http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt >=20 > On slide 5, there are two requirements that appear relevant to > the issue of cryptographic separation: >=20 > 2. "Maintain confidentiality of session keys" >=20 > 3. "Compromise of a single NAS cannot compromise any other > part of the system, including session keys and long term keys" > > I interpret #2 to relate to key wrap as well as to the ability > to recover session keys based on passive eavesdropping or > active attacks such as offline dictionary attack. > > My interpretation of #3 is that this is mandating PFS between > NASes, as well as inability to recover other keys based on > compromise of the MSK. >=20 > We could of course leave much of this discussion to the Key > Framework document, but then it would be hard to argue that it > should be Informational, since it would contain requirements > that were not present in RFC 2284bis, that are needed to meet > the security guidelines. The requirements in AAA-Key-Mgmt.ppt are good. I'm just thinking that those requirements could be met by an EAP method that is internally completely different than EAP-TLS or the model presented in Key Framework. What we should specify is what the "method black box" looks to outside, and speaking of that, there's one very important requirement we've forgotten so far. Proposed text (after reference to IKE and TLS): "Non-overlapping substrings of MSK MUST be cryptographically separate from each other. This is required because some existing ciphersuites form TSKs by simply splitting the MSK to pieces of appropriate length. Likewise, non-overlapping substrings of EMSK MUST be cryptographically separate from each other, and from substrings of MSK." (This forbids expanding a short key to a longer MSK by simply repeating the original key, or padding it with zeroes). Another issue related to this: Should we say something more about IVs? For instance, CBC mode encryption requires that IVs are unpredictable (but e.g. the IVs exported by EAP-TLS are not). Or maybe we shouldn't mention them at all, since it seems that no ciphersuites actually use them? Best regards, Pasi From Hannes.Tschofenig@siemens.com Tue Apr 29 12:17:43 2003 From: Hannes.Tschofenig@siemens.com (Hannes Tschofenig) Date: Tue, 29 Apr 2003 13:17:43 +0200 Subject: [eap] EAP IKEv2 Method References: <3EA7D884.7020901@piuha.net> Message-ID: <000901c30e40$f55574a0$010aa8c0@joe> hi jari, thank you for the review. please see my comments inline: ----- Original Message ----- From: "Jari Arkko" Cc: eap@frascone.com Sent: Thursday, April 24, 2003 2:28 PM Subject: Re: [eap] EAP IKEv2 Method > > Hannes, Dirk, > > Thank you for your contribution. An interesting new method! > A few comments after the first quick read: > > * I found it funny that you list "support of legacy > authentication" as one of the improvements in IKEv2 ;-) > > Seriously though, the introduction of your document > should be more clear about the scope of the protocol. > This appears to be: > > (1) use a well known IKEv2 shared/cert authentication, > AND > (2) provide a new EAP tunneling method you are certainly right. we should highlight these issues. > > All in all, this would be quite a super method by any > standards! Shared secrets, certs, CRL exchange, and > EAP tunneling in a single method. > > At the very least, you should have a requirement > that implementations MUST check they don't perform > infinite recursion just because the bad guy offers > to run EAP and IKEv2 in a looping fashion against it ;-) > yes, we should add a short comment to this fact. > * Section 1 talks about phases, but I believe the adopted > IKEv2 term is "exchange". I think your intention is > to use the IKE_SA_INIT and IKE_AUTH exchanges? > right. needs to be fixed in order to be aligned better with the language used in ikev2 (i.e. not using ikev1 language) > * I believe SAi2, SAr2, TSi, TSr are mandatory in IKE_AUTH > exchange currently. So this is one case where you have to > deviate from the IKEv2 specification? Should be listed at > the start of Section 3, I think. > we have pointed to this circumstance in a separate paragraph. we thought that it might be good not to exchange these payloads (since they are not used afterwards). however, it might be good point to this issue at the beginning of section 3. > * I don't understand the statement "... differs from IKEv2 > only in the computation of the AUTH payload. For symmetric > authentication no CERT and CERTREQ payloads are required." > Is the latter statement the difference? Anyway, in IKEv2 > thees payloads are optional so you may not need to state > this. > this sentence sounds somewhat strange. the statements about the IKEv2 payloads still need some more clarification in the draft. > * s/provides information where the protocol messages described > below terminate/provides information about the identities > of the EAP endpoints/ > > * The discussion of identities probably deserves its own > section. I suspect the current scheme is quite complex, > and might benefit from simplification e.g. by requiring > that some of the identities either be either omitted > or are always the same as some other identities. yes, this complexity indeed is an issue, as it is for other EAP methods (particularly for all tunneling methods). Is there any general guideline on dealing with this, or are there any recommendations? We agree that some simplification is useful here. > > FYI: Figure 3 example and some of the text in Section 3 > is in conflict with the IKEv2 requirement that > EAP identity requests should not be used (section > 3.16 of ikev2-07). > the ipsec group was very busy in the last few month. this was introduced with a recent version of the ikev2 draft. with the next version of the document we try to get these issues updated. > * "To counter this threat IKEv2 provides a compound > authentication by including the EAP provided session > key inside the AUTH payload." To my knowledge IKEv2 > does this only for methods that provide session keys. > Note that it does not currently specify anything > meaningful (imho) for non-key-generating methods. this is certainly true. i have contacted the authors regarding this issue (a nd others) some time ago. they indicated that this is subject to change in future document versions. i might need to contact them again. > > * Open issue on fragmentation: IKEv2 does not need to > worry about fragmentation because lower layer provides > that (well, there are debates about that too). However, > in EAP we do not provide fragmentation at the lower layer, > at least not in all contexts where EAP is used. So it > seems like you do need to handle fragmentation, and extend > the packet format accordingly. Or? thank you for you comment. we will add fragmentation support (as done by other methods) especially with fragmentation handling i guess it would be good to have a general guidelines since the procedure might be applicable to a number of documents (basically to all pk-based authentication methods). > > * Open issue on cert revokation. Wouldn't it be easiest to > follow IKEv2? Is there a specific need to do OCSP in this > protocol which does not exist for IKEv2? (Perhaps the lack > of network access by the time EAP is typically run could be > one such reason...) > we certainly want to follow the approach taken by ikev2. there are reasons to include support for ocsp (you mention one of them). we see some room for improvement (in ikev2) :-) ciao hannes > Jari > From aboba@internaut.com Tue Apr 29 13:35:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Apr 2003 05:35:51 -0700 (PDT) Subject: [eap] RE: Issue 113: Rewrite of Security Considerations Section In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BAD0@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BAD0@esebe023.ntc.nokia.com> Message-ID: > If the method uses MK for fast resume (again, something internal > to a method), it knows this, and then it has to ensure that MSK > doesn't help in recoving MK. Correct. Perhaps this is expressed in a requirement that knowing one MSK cannot make it easier to recover another one more efficiently than brute force? This is the problem that is observable. > However, this is probably a very bad idea, since this would make > the derivation of "fast handoff keys" from MK method-specific > (something that we would like to avoid; these keys should > probably be derived from EMSK). Yes. It would also require that the *all* EAP methods export the MK, which quite a few methods (SIM, TLS-derived methods, Kerberos, etc.) cannot do. > No, of course not :) I intended to say that in some perfectly good > protocols, knowing TEKs allows you to recover the MSK (and thus > TSKs). Naturally, then it must not be possible to recover TEKs > from the EAP conversation (more efficiently than brute force). Hmm. Isn't recovery of the TEKs a function of the ciphersuite negotiated within the EAP method? For example in EAP TLS, if RC4 is negotiated, then presumably recovery of the TEKs is easier than if say, AES had been negotiated instead. > that those requirements could be met by an EAP method that is > internally completely different than EAP-TLS or the model > presented in Key Framework. Sure. The question is what requirements we impose on the EAP method so that the "black box" outputs are guaranteed to meet requirements. Ideally we should not be ruling out good methods in the process. > What we should specify is what the "method black box" looks to > outside, and speaking of that, there's one very important > requirement we've forgotten so far. Proposed text (after > reference to IKE and TLS): > > "Non-overlapping substrings of MSK MUST be cryptographically > separate from each other. This is required because some > existing ciphersuites form TSKs by simply splitting the MSK to > pieces of appropriate length. Likewise, non-overlapping > substrings of EMSK MUST be cryptographically separate from > each other, and from substrings of MSK." > > (This forbids expanding a short key to a longer MSK by simply > repeating the original key, or padding it with zeroes). Yes. This is a good requirement. Will add. > Another issue related to this: Should we say something more > about IVs? For instance, CBC mode encryption requires that IVs > are unpredictable (but e.g. the IVs exported by EAP-TLS are > not). Or maybe we shouldn't mention them at all, since > it seems that no ciphersuites actually use them? The EAP TLS IV derivation is taken from the TLS key hierarchy, which uses them with ciphersuites such as 3DES CBC mode. While the IVs are not a secret (this resulted from now-defunct export rules) they are based on the client and server nonces so they are live. From Pasi.Eronen@nokia.com Tue Apr 29 14:26:02 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 29 Apr 2003 16:26:02 +0300 Subject: [eap] RE: Issue 113: Rewrite of Security Considerations Section Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122277@esebe023.ntc.nokia.com> > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, April 29, 2003 3:36 PM > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: RE: Issue 113: Rewrite of Security Considerations Section ... > The EAP TLS IV derivation is taken from the TLS key=20 > hierarchy, which uses them with ciphersuites such as=20 > 3DES CBC mode. While the IVs are not a secret (this=20 > resulted from now-defunct export rules) they are=20 > based on the client and server nonces so they are live. Yes, but we shouldn't repeat that mistake. CBC mode=20 is simply not secure enough for many applications=20 if the IVs are predictable (and TLS 1.1 drafts no longer use predictable IVs). So, considering that it seems that no ciphersuites actually use the IVs yet, I propose we remove all=20 references to them from 2284bis, and just say that an EAP method exports MSK and EMSK. Best regards, Pasi From aboba@internaut.com Tue Apr 29 18:47:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Apr 2003 10:47:21 -0700 (PDT) Subject: [eap] RE: Issue 113: Rewrite of Security Considerations Section In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122277@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122277@esebe023.ntc.nokia.com> Message-ID: > So, considering that it seems that no ciphersuites > actually use the IVs yet, I propose we remove all > references to them from 2284bis, and just say > that an EAP method exports MSK and EMSK. I agree. From aboba@internaut.com Tue Apr 29 19:41:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Apr 2003 11:41:13 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 109: Attacker or Adversary? Message-ID: Issue 109 is included below. I would like to propose that the changes proposed in this issue be accepted. Any objections? --------------------------------------------------------------- Issue 109: Attacker or Adversary? Submitter name: Benoit de Boursetty Submitter email address: benoit.deboursetty@francetelecom.com Date first submitted: April 25th, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-April/001046.html Document: EAP-01 Comment type: E Priority: 1 Section: 7.1 Rationale/Explanation of issue: In section 7.1, the word "adversary" and "attacker" are both used to talk about the same kind of person. It is the only place in the draft where "adversary" is used, every where else the word "attacker" is used. Also all issues are "[attacker|adversary] may" but number 4 is a "might" (offline attacks). Does it really seem less likely than other attacks? Suggested Change: Unless the above is a subtlety beyond my grasping of the English language: s/adversary/attacker/ s/might/may/ in issue 4 From aboba@internaut.com Tue Apr 29 19:42:31 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Apr 2003 11:42:31 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 108: Downgrade attack Message-ID: The text of Issue 108 is included below. I would like to propose that the changes described in this issue be accepted. Any objections? ---------------------------------------------------------- Issue 108: Downgrade attacks on lower layer ciphersuite negotiation Submitter name: Benoit de Boursetty Submitter email address: benoit.deboursetty@francetelecom.com Date first submitted: April 25th, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-April/001045.html Document: EAP-01 Comment type: T Priority: 1 Section: 7.1 and 7.11 Rationale/Explanation of issue: In section 3.1 on lower layer requirements, requirement 2 indicates a need for physically insecure links to be used with per-packet integrity, authentication and replay protection. Although the problem of downgrading attack on EAP method negotiation is identified in 7.8, I cannot find word about the issue of downgrading attacks on ciphersuite negotiation for the lower layer ciphersuite. However there is mention of weak lower-layer ciphersuites being a threat to security, at least in section 7.1 #8 and in section 7.11. I understand that in actual cases deployed now, there is no or little lower layer ciphersuite negotiation. But to take an example, self-admittedly PPP's MPPE is currently vulnerable to downgrading attacks (cf. par. 2, section 9 of RFC 3078) and there is no proposed workaround (apart from explicit client configuration). Another way to function is that parts of the keying material resulting from EAP can be used by the link layer to authenticate a negotiation handshake afterwards (I would have thought Auth-RECV-Key and Auth-SEND-Key, but according to the new Keying Framework draft I'm not so sure). In the short term, I suggest mentioning the issue in the Security Considerations section, as well as the workaround of using EAP-provided keying material to enable negotiation integrity protection ex-post. In the longer term, it could be desirable that the lower-layer handshakes be integrity-verified during EAP authentication, as a "handshake integrity checking service" offered by some EAP methods -- just as they can provide now mutual authentication, keying material generation etc. This is left to the consideration of the EAP charter. In the meantime: Suggested changes: Section 7.1: adding point 9 following point 8: "[9]. An attacker may attempt to perform downgrading attacks on link-level ciphersuite negotiation in order to ensure that a weaker ciphersuite is used subsequently to EAP authentication." Section 7.11: adding following paragraph at the end of the section: "Additionally, if the lower layer performs ciphersuite negotiation, it should be understood that EAP does not provide by itself integrity protection of that negotiation. Therefore, in order to avoid downgrading attacks which would lead to weaker ciphersuites being used, clients implementing lower layer ciphersuite negotiation SHOULD protect against negotiation downgrading. This can be done by enabling users to configure which are the acceptable ciphersuites as a matter of security policy; or, the ciphersuite negotiation MAY be authenticated using keying material derived from the EAP authentication and a MAC algorithm agreed upon in advance by lower-layer peers." From aboba@internaut.com Tue Apr 29 19:45:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Apr 2003 11:45:03 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication Message-ID: The text of Issue 118 is enclosed below. Based on the discussion so far, it does not appear that any additional text is required in RFC 2284bis to address this (though additional text might be added in IEEE 802.1X). As a result, my recommendation is that this issue be rejected. Any objections? ----------------------------------------------------------------------- Issue 118: Mutual Authentication Submitter name: Dror Caspi Submitter email address: dror_caspi@atrica.com Date first submitted: April 21, 2003 Reference: Document: EAP-02 Comment type: T Priority: 2 Section: Various Rationale/Explanation of issue: Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa, it seems that most of the attention is given to systems where there is a distinction between an authenticator and a peer/supplicant. This distinction still exists even where mutual authentication is proposed (e.g., EAP-Archie). But what happens when both parties are peers (e.g., two bridge devices)? The possibility of role reversal is mentioned (i.e., run a session where one system is Authenticator and the other Peer, and then reverse the role). However it seems quite cumbersome; a single session of a protocol such as EAP-Archie would seem to provide the required authentication - yet there needs to be a mechanism to (randomly?) decide which party plays which role. Probably some of the above is misunderstanding on my part. However there seems to be a need for some explanatory text in the standards, if not for actual changes to accommodate peer-to-peer mutual authentication. Requested change: Add explanatory text about peer-to-peer mutual authentication. Modify the standards if required. From jesse.walker@intel.com Tue Apr 29 16:43:56 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Tue, 29 Apr 2003 08:43:56 -0700 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: Hi Dror, In my opinion (emprical data amply demonstrates that no one has to agree ;-) the EAP framework is inappropriate in general for peer-to-peer operation. If you think through the model specified for peer-to-peer operation, you get into a mire of problems that raise the issue of whether EAP as constituted today is appropriately matched to the problem. The first problem requires a solution outside (and way outside at that) of EAP. Authentication presupposes a notion of a community with a common set of credentials. It does not make sense to allow anyone to use any credential in any context, because by definition all members of the community must be able to somehow recognize one another as being legitimate members of **THIS** community. In all systems I am aware of this is accomplished through a common policy to utilize a common set of credentials. In particular, a community corresponds to some common credentialing or enrollment function, where each credential identifies its bearer as a member of the community in some uniform way, and also implies an access control (membership in the community) that is universally recognized by all other members of the community. So point number one is it is not feasible to establish a peer-to-peer network without first establishing a notion of a network or community, and doing so is not EAP's problem to solve. The second problem is a special case of this. There are only three basic trust models. The first is direct bilateral trust, where two parties authenticate each other directly and make up a key shared only between themselves. This model essentially works only in networks of two parties, so is not a general solution; there is no way to enforce that all members of a larger group will authenticate and establish their session keys in exactly the same way. The second model is to rely on an on-line trusted third party. This is the model used by 802.1X and Kerberos. All members of the group are enrolled with the on-line trusted third party, and the on-line trusted third party provides some mechanism for distributing pairwise keys to any pair of communicating parties within the community. In the peer-to-peer model one can imagine communities ranging from those with one such on-line trusted third party (completely centralized admission control) to those where every group member becomes an on-line trusted third party (completely distributed admission control). However, by definition, one and only one on-line trusted third party can mediate any particular session between two members of the community, because it is only one session. The third model relies on an off-line trusted third party. TLS is an example that exploits this model. This model relies on public/private key technology, as proof-of-possesion of the private key pair is the ultimate basis for electronic identity. In this model, since possession of a private key is assumed to establish identity, the use of such a key by another member can be used to attest to the membership of another party. This is a model that scales, because the community member making an attestation need not be within communication range when the access control decision is being made. In my mind a general-purpose secure peer-to-peer model would need to support all three approaches. The impression I get is that people are thinking almost exclusively of the bilateral case, and they are struggling to wedge the on-line trusted third party model that EAP is based on to fit this, and this can't be done elegantly. If this impression is correct (and I'm not claiming that is is, but rather only that it is my impression), then the current approach is technically flawed in two dimensions: the on-line trusted third party model is not the same as the bilateral model that people are thinking of, and EAP should be expanded to support all three models instead of just one. Oh, sure, any model can be used to emulate any other model, but emulation costs MIPs, and my employer is eternally grateful ("Sell more Pentiums") for each. Emulation abandons many otherwise fine applications (e.g., the secure wireless lightbulb) because of cost constraints. The third problem centers around limitations of the security of data links like 802.11. In particular, the security associations in this class of networks use the **SAME** key for both directions of traffic flow between two peers. This implies that the two peers must somehow agree on what this key is. This is a much trickier problem than first appears, and EAP's structure does not help solve it. I've pointed out this problem before: it is essential to cryptographically relate the two independent authentications. In particular, a cyrptographically sound authentication method will establish a notion of a session that can be distinguish **THIS** session from every other session between the **SAME** peers, so one can figure out **WHICH** session key to use during **THIS** session. Temproality of messages by themselves does nothing to establish this. Indeed, protocols like TLS and AKEP and Archie establish session identity by exchanging random nonces and mutually authenticating. For instance, when EAP-TLS is used, clientHello.random and serverHello.random together with the authentication information identify **THIS** session. But there is nothing in EAP that can be used to accomplish this function. The EAP Identifier field is the only possible candidate for the nonce space, but the size of the Identifier field is way too small to provide anything meaningful, and there are no native EAP cryptographic protections to protect this field anyway. Identifying each session requires restricting the authentication protocol to those that already come with all the necessary bells and whisteles. But this is not enough, because, to solve the 802.11 keying problem, one still has to identify that the sessions established by each direction of authentication are both extant between the same peers at the same time. One can imagine, for instance, some sort of meta-EAP protocol that relies on the larger nonce space when specificly restricted to protocols like TLS or Archie; one could, for instance, make up rules that say in peer-to-peer mode, if one receives an authenticate request from a peer to whom one has an outstanding request, you must use the same nonce that you have outstanding, etc. But this feels uncomfortably like trying to pound a round peg into a square hole, and one has to struggle to suppress the observation that we are really, really reaching here, and that there has to be a better and easier and cheaper way. The fourth problem is easy is some cases, if the other problems can be solved. And that is how to pick out the session key to use. If you **CAN** identify the two sessions in each direction, and **CAN** authoritatively establish that both are indeed between the same pair of parties, then any arbitrary scheme can be used to select one of the two session keys to use to protect the underlying link, e.g., picking the smaller of two MAC addresses in the 802 case. So I am deeply skeptical about extending the current instantiation of EAP to cover peer-to-peer; the intellectual spadework has not been done, and the tiny bit I may have contributed in this missive tends to indicate, at least to me, that EAP does not have the right shape. This strikes me as a case, as the adage says, everything looks like a nail to someone who only has a hammer. For whatever it is worth, that's my two cents. -- Jesse > -----Original Message----- > From: Dror Caspi [mailto:dror_caspi@atrica.com] > Sent: Sunday, April 27, 2003 9:14 AM > To: eap@frascone.com > Cc: Yael Dayan > Subject: [eap] FW: peer-to-peer mutual authentication > > > [I'm resending this message since it seems the original got > lost - sorry if any of you got it the second time] > > Description of issue > Submitter name: Dror Caspi > Submitter email address: dror_caspi@atrica.com > Date first submitted: April 21, 2003 > Reference: > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa > Comment type: Technical > Priority: '2' May fix > Section: N/A > Rationale/Explanation of issue: > > Having looked at the drafts of RFC2284bis, EAP-Archie and > IEEE-802.1aa, it seems that most of the attention is given to > systems where there is a distinction between an authenticator > and a peer/supplicant. This distinction still exists even > where mutual authentication is proposed (e.g., EAP-Archie). > > But what happens when both parties are peers (e.g., two > bridge devices)? The possibility of role reversal is > mentioned (i.e., run a session where one system is > Authenticator and the other Peer, and then reverse the role). > However it seems quite cumbersome; a single session of a > protocol such as EAP-Archie would seem to provide the > required authentication - yet there needs to be a mechanism > to (randomly?) decide which party plays which role. > > Probably some of the above is misunderstanding on my part. > However there seems to be a need for some explanatory text in > the standards, if not for actual changes to accomodate > peer-to-peer mutual authentication. > > Requested change: > > Add explanatory text about peer-to-peer mutual > authentication. Modify the standards if required. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From henrik@levkowetz.com Tue Apr 29 22:39:48 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 29 Apr 2003 23:39:48 +0200 Subject: [eap] Proposed resolution of Issue 109: Attacker or Adversary? In-Reply-To: References: Message-ID: <20030429233948.35d46917.henrik@levkowetz.com> Definitely fine by me. Henrik On Tue, 29 Apr 2003 11:41:13 -0700 (PDT), Bernard Aboba wrote: > Issue 109 is included below. I would like to propose that the changes > proposed in this issue be accepted. Any objections? > > --------------------------------------------------------------- > Issue 109: Attacker or Adversary? > Submitter name: Benoit de Boursetty > Submitter email address: benoit.deboursetty@francetelecom.com > Date first submitted: April 25th, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-April/001046.html > Document: EAP-01 > Comment type: E > Priority: 1 > Section: 7.1 > Rationale/Explanation of issue: > > In section 7.1, the word "adversary" and "attacker" are both used to > talk about the same kind of person. It is the only place in the draft > where "adversary" is used, every where else the word "attacker" is used. > > Also all issues are "[attacker|adversary] may" but number 4 is a "might" > (offline attacks). Does it really seem less likely than other attacks? > > Suggested Change: > Unless the above is a subtlety beyond my grasping of the English > language: > s/adversary/attacker/ > s/might/may/ in issue 4 > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > Henrik -- Never miss a good chance to shut up. From alper@docomolabs-usa.com Wed Apr 30 02:23:27 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Tue, 29 Apr 2003 18:23:27 -0700 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: Message-ID: > The third problem centers around limitations of the security of data links > like 802.11. In particular, the security associations in this class of > networks use the **SAME** key for both directions of traffic flow between > two peers. This implies that the two peers must somehow agree on what this > key is. This is a much trickier problem than first appears, and EAP's > structure does not help solve it. I've pointed out this problem before: it > is essential to cryptographically relate the two independent > authentications. In particular, a cyrptographically sound authentication > method will establish a notion of a session that can be distinguish **THIS** > session from every other session between the **SAME** peers, so one can > figure out **WHICH** session key to use during **THIS** session. Temproality > of messages by themselves does nothing to establish this. Indeed, protocols > like TLS and AKEP and Archie establish session identity by exchanging random > nonces and mutually authenticating. For instance, when EAP-TLS is used, > clientHello.random and serverHello.random together with the authentication > information identify **THIS** session. But there is nothing in EAP that can > be used to accomplish this function. The EAP Identifier field is the only > possible candidate for the nonce space, but the size of the Identifier field > is way too small to provide anything meaningful, and there are no native EAP > cryptographic protections to protect this field anyway. Identifying each > session requires restricting the authentication protocol to those that > already come with all the necessary bells and whisteles. This can be solved within the EAP transport. For example, we are working on adding a session-id to the PANA header, which might help with the above problem. Alper From dror_caspi@atrica.com Wed Apr 30 07:32:18 2003 From: dror_caspi@atrica.com (Dror Caspi) Date: Wed, 30 Apr 2003 09:32:18 +0300 Subject: [eap] FW: peer-to-peer mutual authentication Message-ID: Hi Jesse, Thanks for your elaborate answer. Based on that and other answers we = have received so far, we have decided to go with a proprietary solution = - which is fine for now since we provide the equipment on both sides. Hopefully some day there will be a standardized way to do this (maybe as = part of the new link security effort). Dror > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Tuesday, April 29, 2003 6:44 PM > To: Dror Caspi; eap@frascone.com > Cc: Yael Dayan > Subject: RE: [eap] FW: peer-to-peer mutual authentication >=20 >=20 > Hi Dror, >=20 > In my opinion (emprical data amply demonstrates that no one=20 > has to agree ;-) > the EAP framework is inappropriate in general for=20 > peer-to-peer operation. If > you think through the model specified for peer-to-peer=20 > operation, you get > into a mire of problems that raise the issue of whether EAP=20 > as constituted > today is appropriately matched to the problem. >=20 > The first problem requires a solution outside (and way=20 > outside at that) of > EAP. Authentication presupposes a notion of a community with=20 > a common set of > credentials. It does not make sense to allow anyone to use=20 > any credential in > any context, because by definition all members of the=20 > community must be able > to somehow recognize one another as being legitimate members=20 > of **THIS** > community. In all systems I am aware of this is accomplished through a > common policy to utilize a common set of credentials. In particular, a > community corresponds to some common credentialing or=20 > enrollment function, > where each credential identifies its bearer as a member of=20 > the community in > some uniform way, and also implies an access control=20 > (membership in the > community) that is universally recognized by all other members of the > community. So point number one is it is not feasible to establish a > peer-to-peer network without first establishing a notion of a=20 > network or > community, and doing so is not EAP's problem to solve. >=20 > The second problem is a special case of this. There are only=20 > three basic > trust models. The first is direct bilateral trust, where two parties > authenticate each other directly and make up a key shared only between > themselves. This model essentially works only in networks of=20 > two parties, so > is not a general solution; there is no way to enforce that=20 > all members of a > larger group will authenticate and establish their session=20 > keys in exactly > the same way. The second model is to rely on an on-line=20 > trusted third party. > This is the model used by 802.1X and Kerberos. All members of=20 > the group are > enrolled with the on-line trusted third party, and the=20 > on-line trusted third > party provides some mechanism for distributing pairwise keys=20 > to any pair of > communicating parties within the community. In the=20 > peer-to-peer model one > can imagine communities ranging from those with one such=20 > on-line trusted > third party (completely centralized admission control) to=20 > those where every > group member becomes an on-line trusted third party=20 > (completely distributed > admission control). However, by definition, one and only one=20 > on-line trusted > third party can mediate any particular session between two=20 > members of the > community, because it is only one session. The third model=20 > relies on an > off-line trusted third party. TLS is an example that exploits=20 > this model. > This model relies on public/private key technology, as=20 > proof-of-possesion of > the private key pair is the ultimate basis for electronic=20 > identity. In this > model, since possession of a private key is assumed to=20 > establish identity, > the use of such a key by another member can be used to attest to the > membership of another party. This is a model that scales, because the > community member making an attestation need not be within=20 > communication > range when the access control decision is being made. >=20 > In my mind a general-purpose secure peer-to-peer model would=20 > need to support > all three approaches. The impression I get is that people are thinking > almost exclusively of the bilateral case, and they are=20 > struggling to wedge > the on-line trusted third party model that EAP is based on to=20 > fit this, and > this can't be done elegantly. If this impression is correct=20 > (and I'm not > claiming that is is, but rather only that it is my=20 > impression), then the > current approach is technically flawed in two dimensions: the on-line > trusted third party model is not the same as the bilateral=20 > model that people > are thinking of, and EAP should be expanded to support all=20 > three models > instead of just one. Oh, sure, any model can be used to=20 > emulate any other > model, but emulation costs MIPs, and my employer is eternally grateful > ("Sell more Pentiums") for each. Emulation abandons many=20 > otherwise fine > applications (e.g., the secure wireless lightbulb) because of cost > constraints. >=20 > The third problem centers around limitations of the security=20 > of data links > like 802.11. In particular, the security associations in this class of > networks use the **SAME** key for both directions of traffic=20 > flow between > two peers. This implies that the two peers must somehow agree=20 > on what this > key is. This is a much trickier problem than first appears, and EAP's > structure does not help solve it. I've pointed out this=20 > problem before: it > is essential to cryptographically relate the two independent > authentications. In particular, a cyrptographically sound=20 > authentication > method will establish a notion of a session that can be=20 > distinguish **THIS** > session from every other session between the **SAME** peers,=20 > so one can > figure out **WHICH** session key to use during **THIS**=20 > session. Temproality > of messages by themselves does nothing to establish this.=20 > Indeed, protocols > like TLS and AKEP and Archie establish session identity by=20 > exchanging random > nonces and mutually authenticating. For instance, when=20 > EAP-TLS is used, > clientHello.random and serverHello.random together with the=20 > authentication > information identify **THIS** session. But there is nothing=20 > in EAP that can > be used to accomplish this function. The EAP Identifier field=20 > is the only > possible candidate for the nonce space, but the size of the=20 > Identifier field > is way too small to provide anything meaningful, and there=20 > are no native EAP > cryptographic protections to protect this field anyway.=20 > Identifying each > session requires restricting the authentication protocol to those that > already come with all the necessary bells and whisteles. >=20 > But this is not enough, because, to solve the 802.11 keying=20 > problem, one > still has to identify that the sessions established by each=20 > direction of > authentication are both extant between the same peers at the=20 > same time. One > can imagine, for instance, some sort of meta-EAP protocol=20 > that relies on the > larger nonce space when specificly restricted to protocols like TLS or > Archie; one could, for instance, make up rules that say in=20 > peer-to-peer > mode, if one receives an authenticate request from a peer to=20 > whom one has an > outstanding request, you must use the same nonce that you=20 > have outstanding, > etc. But this feels uncomfortably like trying to pound a=20 > round peg into a > square hole, and one has to struggle to suppress the=20 > observation that we are > really, really reaching here, and that there has to be a=20 > better and easier > and cheaper way. >=20 > The fourth problem is easy is some cases, if the other problems can be > solved. And that is how to pick out the session key to use.=20 > If you **CAN** > identify the two sessions in each direction, and **CAN**=20 > authoritatively > establish that both are indeed between the same pair of=20 > parties, then any > arbitrary scheme can be used to select one of the two session=20 > keys to use to > protect the underlying link, e.g., picking the smaller of two=20 > MAC addresses > in the 802 case. >=20 > So I am deeply skeptical about extending the current=20 > instantiation of EAP to > cover peer-to-peer; the intellectual spadework has not been=20 > done, and the > tiny bit I may have contributed in this missive tends to=20 > indicate, at least > to me, that EAP does not have the right shape. This strikes=20 > me as a case, as > the adage says, everything looks like a nail to someone who only has a > hammer. For whatever it is worth, that's my two cents. >=20 > -- Jesse >=20 > > -----Original Message----- > > From: Dror Caspi [mailto:dror_caspi@atrica.com] > > Sent: Sunday, April 27, 2003 9:14 AM > > To: eap@frascone.com > > Cc: Yael Dayan > > Subject: [eap] FW: peer-to-peer mutual authentication > >=20 > >=20 > > [I'm resending this message since it seems the original got=20 > > lost - sorry if any of you got it the second time] > >=20 > > Description of issue=20 > > Submitter name: Dror Caspi > > Submitter email address: dror_caspi@atrica.com=20 > > Date first submitted: April 21, 2003=20 > > Reference:=20 > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057=20 > > Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa > > Comment type: Technical > > Priority: '2' May fix > > Section: N/A=20 > > Rationale/Explanation of issue: > > =20 > > Having looked at the drafts of RFC2284bis, EAP-Archie and=20 > > IEEE-802.1aa, it seems that most of the attention is given to=20 > > systems where there is a distinction between an authenticator=20 > > and a peer/supplicant. This distinction still exists even=20 > > where mutual authentication is proposed (e.g., EAP-Archie). > >=20 > > But what happens when both parties are peers (e.g., two=20 > > bridge devices)? The possibility of role reversal is=20 > > mentioned (i.e., run a session where one system is=20 > > Authenticator and the other Peer, and then reverse the role).=20 > > However it seems quite cumbersome; a single session of a=20 > > protocol such as EAP-Archie would seem to provide the=20 > > required authentication - yet there needs to be a mechanism=20 > > to (randomly?) decide which party plays which role. > >=20 > > Probably some of the above is misunderstanding on my part. =20 > > However there seems to be a need for some explanatory text in=20 > > the standards, if not for actual changes to accomodate=20 > > peer-to-peer mutual authentication. > >=20 > > Requested change:=20 > >=20 > > Add explanatory text about peer-to-peer mutual=20 > > authentication. Modify the standards if required. > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From dror_caspi@atrica.com Wed Apr 30 07:34:31 2003 From: dror_caspi@atrica.com (Dror Caspi) Date: Wed, 30 Apr 2003 09:34:31 +0300 Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication Message-ID: I believe that Jesse Walker's last responce should be taken into = account; i.e., if EAP can't really be used properly for peer-to-peer = situation, this should be stated clearly in EAP as well as in 802.1X. Dror > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, April 29, 2003 9:45 PM > To: eap@frascone.com > Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication >=20 >=20 > The text of Issue 118 is enclosed below. Based on the=20 > discussion so far, > it does not appear that any additional text is required in=20 > RFC 2284bis to > address this (though additional text might be added in IEEE=20 > 802.1X). As a > result, my recommendation is that this issue be rejected. Any=20 > objections? >=20 >=20 > -------------------------------------------------------------- > --------- > Issue 118: Mutual Authentication > Submitter name: Dror Caspi > Submitter email address: dror_caspi@atrica.com > Date first submitted: April 21, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: 2 > Section: Various > Rationale/Explanation of issue: >=20 > Having looked at the drafts of RFC2284bis, EAP-Archie and=20 > IEEE-802.1aa, > it seems that most of the attention is given to systems where=20 > there is a > distinction between an authenticator and a peer/supplicant. This > distinction still exists even where mutual authentication is proposed > (e.g., EAP-Archie). >=20 > But what happens when both parties are peers (e.g., two=20 > bridge devices)? > The possibility of role reversal is mentioned (i.e., run a session > where one system is Authenticator and the other Peer, and then reverse > the role). However it seems quite cumbersome; a single session of a > protocol such as EAP-Archie would seem to provide the required > authentication - yet there needs to be a mechanism to=20 > (randomly?) decide > which party plays which role. >=20 > Probably some of the above is misunderstanding on my part. However > there seems to be a need for some explanatory text in the=20 > standards, if > not for actual changes to accommodate peer-to-peer mutual=20 > authentication. >=20 > Requested change: >=20 > Add explanatory text about peer-to-peer mutual authentication. Modify > the standards if required. >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From ltarkkal@ssh.com Wed Apr 30 12:36:17 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Wed, 30 Apr 2003 14:36:17 +0300 Subject: [eap] passphrases in EAP Message-ID: <20030430113617.GA1200@tehdas> I have unfortunately not had time to follow the WG work actively all the time, so my apologies if this item has already been discussed. Lauri Interoperability problems in passphrase authentication protocols. Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Date first submitted: April 30, 2003 Document: draft-ietf-eap-rfc2284bis-02.txt Comment type: general Rationale/Explanation of Issue: Several of the PPP/EAP authentication protocols are in essence "password authentication protocols" (PAP, CHAP, EAP-MD5). This means that the shared secret is in essence a string in some alphabet (most often US-ASCII), as opposed to the more low-level view of a bitstring. Currently the specifications of these protocols define the shared secret as an arbitrary string of octets. This has caused in practice a serious interoperability problem, leaving implementations free to define the following: - Alphabet the password is defined in. - Derivation of shared secret from password. As an example some implementations assume CHAP to encode the password as US-ASCII (or Latin-1 or some other 8-bit alphabet) and MS-CHAPv2 to encode the password as UCS-2. This leads to obvious problems. If the user actually has characters in his/her password not expressible in US-ASCII. He/she/it should have sufficient know-how to be able to disable CHAP when negotiating an authentication protocol. An implementation also might have to guess the alphabet to use. These settings might also differ from system to system. In some cases one could try to deduce an intelligent guess based on some (e.g. out-of-band) vendor identification for the peer. These pitfalls should be avoided in the future. I propose that the working group standardize the following functions: a) If an authentication protocol is keyed by a "passphrase", then the algorithm used to derive a representation of a shared secret. If any cryptography is involved, the protection of the shared secret (if performed) should still be left to the individual EAP method. b) The alphabet to be used for this (assuming the WG feels that a superset alphabet exists), or if the WG feels that it is not prudent to specify a superset alphabet at this point in time, a tagging mechanism in the protocol to denote the alphabet used in mapping a passphrase to a bitstring. The current draft specifies that the UTF-8 is used to represent all human-readable data. An acceptable solution would be to state, that ALL human readable data in ALL EAP methods (except methods specified before xx.yy.zzzz) must be represented using UTF-8. This would include passphrases. Also the alphabsets used in methods before xx.yy.zzzz should be defined, by a poll checking current implementations. This would require introduction of two EAP-MD5 methods. -- Lauri Tarkkala SSH Communications Security Corp From aboba@internaut.com Wed Apr 30 14:57:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Apr 2003 06:57:42 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication In-Reply-To: References: Message-ID: Indeed it would appear that a clarification is needed -- and I've filed this issue as #119. However, I don't agree that the clarification is the type suggested by Jesse. EAP was created for use with a peer-to-peer protocol, PPP. Although it is initiated by the "authenticator", either PPP peer can play that role, and in fact both can do so in two simulataneous conversations. In 802.1X-2001 it was the intent to support this feature of EAP, but that was not made clear. The IEEE 802.1aa effort is in the process of adding text to make it clear that peer-to-peer operation is supported, and that use of a backend authentication server is entirely optional (as it is in both EAP and PPP). Of course, without a backend authentication server, there is a credential provisioning problem -- but that problem exists even without EAP and is not made significantly more difficult by use of EAP as a transport instead of say, UDP. True "peer to peer" authentication between network devices is a problem that exists in context such as routing protocol security -- and the same methods are easily translatable to use with EAP. However, provisioning a large number of routers with the appropriate credentials is no small task -- and if an appropriate solution is not put in place, then the solution is undeployable -- regardless of the transport used to carry authentication. From jesse.walker@intel.com Wed Apr 30 16:49:42 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 30 Apr 2003 08:49:42 -0700 Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication Message-ID: Bernard, > EAP was created for use with a peer-to-peer protocol, PPP. > Although it is > initiated by the "authenticator", either PPP peer can play > that role, and > in fact both can do so in two simulataneous conversations. While this is true, it is irrelevant, because it diverts attention from the issue. The EAP model is clearly client-server, not peer-to-peer. This is not wrong or bad; security association establishment protocols (at least the ones that work :-) seem to be inherently client/server. > In 802.1X-2001 it was the intent to support this feature of > EAP, but that > was not made clear. The IEEE 802.1aa effort is in the process > of adding > text to make it clear that peer-to-peer operation is > supported, and that > use of a backend authentication server is entirely optional (as it is > in both EAP and PPP). My point is that the current peer-to-peer direction does not appear sound or even properly thought through. It will take a lot of infrastructure outside of 802.1aa or EAP to make peer-to-peer work, and it will only work when the concrete EAP method is restricted to methods with very specific properties, and when the credentials used are restricted in very specific ways. The currently language in both 2284bis and in 802.1aa fails to reflect any of these constraints. My suspcion is neither does so because we as a community still don't comprehend the issues involved. I know I don't, but the discussion thus far has blithely tiptoed along without any recognition that this is the middle of a mine field. Peer-to-peer is harder than client/server because the roles of the participants are not fixed in advance. This is not a problem in a protocol like IPsec, because there are separate security associations in each direction of the conversation, so each can be keyed by an independent security association establishment. It is a problem when dealing with constructions like 802.11i, however, because there is only one security association per link. This forces one to deal with issues that do not fit comfortably into the client/server model; it forces one to deal with the problem of which peer gets priority for key assignment and how both recognize and establish this. This is a cryptographic design problem. The authentications that might be initiated simultaneously by the peers have to somehow be related in a way that both sides can trust in the presence of a malicious adversary, or it will not be possible to reliably establish agreement on precedence or that there is even a precedence decision. It is hard enough to get one authentication right let alone two. It is certainly feasible to glue together separate authentications initiated by each of two peers, but so far as I can tell how this is accomplished is still an art dependent on the internals of the specific concrete method. One can certainly try to abstract this art and make a common recipe for doing so for authentication methods with certain characteristics, but it is not plausible that the EAP state machines will remain intact in their present form. Hence it appears to be a work item that can be deferred until EAP2 (or whatever it is called this week). If EAP and 802.1aa continue on their present courses, here are some constraints I'd suggest: both parties MUST use the same concrete authentication method with the same credentials for both authentications; the authentication method MUST exchange random nonces; the authentication method MUST protect the nonces from modification; each authentication MUST detect replay and man-in-the-middle attack in BOTH directions; if the two peers initiate their separate authentications simultaneously, then they MUST reuse the nonce they supplied for the authentication they initiated in the authentication to which they are responding; if the peers do not initiate simultaneously, then the peer that has not initiated should fall back to the client-server model if it receives an authentication initiated by the peer (is it the Authenticator or the Supplicant, in 802.1X-speak? I don't know). More constraints may be needed, and some of these proposed constraints may not be right, because, like I said, I don't claim I understand the problem, but if you remove any one of these constraints, then I think it is possible to construct attacks that can compromise at least an 802.11i protected link. At this stage of my confusion and attempts to understand, peer-to-peer usage of EAP appears to me to be as subtle or subtler than tunneled authentication, and we already know we screwed up in the designs of PEAP and TTLS. My appeal is for us to try not to screw up yet again. The discussion thus far has treated the peer-to-peer case as mechanical. I hope that people agree with me that it is not, and much more toil is required. -- Jesse From aboba@internaut.com Wed Apr 30 17:58:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Apr 2003 09:58:11 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication In-Reply-To: References: Message-ID: > While this is true, it is irrelevant, because it diverts attention from the > issue. The EAP model is clearly client-server, not peer-to-peer. This is not > wrong or bad; security association establishment protocols (at least the > ones that work :-) seem to be inherently client/server. What makes EAP "inherently client-server"? There are a few things about the protocol that are asymmetric, such as retransmission behavior (handled by the authenticator), and the sending of Success/Failure (the authenticator sends this to the peer). However, with the recent decisions to only allow a single EAP authentication method per conversation, the Success/Failure packets can be viewed as largely vestigial within a mutually authenticating method, and the latest draft of IEEE 802.1aa includes the notion of "controlled/uncontrolled ports" on both the supplicant and authenticator. While many of the original EAP methods are client-server protocols (e.g. TLS), we have examples of peer-to-peer authentication technologies being proposed for use with EAP. An example is EAP-IKE. IKE is a peer-to-peer protocol (no distinction made between Initiator and Responder with respect to say, authentication modes or certificate usage) -- yet it is being proposed to encapsulate this within EAP, without requiring any changes to EAP. > My point is that the current peer-to-peer direction does not appear sound or > even properly thought through. I think we need to make a distinction between peer-to-peer usage as envisaged in RFC 2284 and IEEE 802.1aa, and the "adhoc" or "mesh networking" scenarios being contemplated in IEEE 802.11. The "adhoc" or "mesh networking" scenarios in IEEE 802.11 are indeed considerably more complex. In garden variety peer-to-peer between say, two Bridges on a wired network, the Bridges are stationary and typically within the same administrative domain. In that situation there are certainly credential provisioning issues, but given some "tie breaker" functionality, an appropriate EAP method supporting peer-to-peer authentication, and sufficient intestinal fortitude on the part of administrators, it can be made to work. However, in the "adhoc" or "mesh networking" scenarios contemplated in IEEE 802.11, we have mobile stations that can potentially be continually bringing up and tearing down security associations where there is no inherent trust model. Just as using OSPF for mesh network routing isn't advisable in these situations, without some care it is likely that stations will be unable to authenticate at all, or if they can, will spend much of their time authenticating and very little time communicating. However, I'm not clear to what extent use of EAP makes this problem worse. I'd also note that IEEE 802.11i is running two authentications, one in each direction, deriving two sets of keys, and *then* running a tie-breaker. This seems wasteful, particularly when we are talking about providing keying material for a ciphersuite that uses the same keys in both directions. > It will take a lot of infrastructure outside > of 802.1aa or EAP to make peer-to-peer work If by peer-to-peer you mean "IEEE 802.11 ahoc or mesh networking", I would agree. However, the senarios contemplated in IEEE 802.1aa are considerably simpler than this. > My suspcion is neither does so because we as a community > still don't comprehend the issues involved. I know I don't, but the > discussion thus far has blithely tiptoed along without any recognition that > this is the middle of a mine field. Since mesh network security is an active research area, I'd agree that this is not something that is sufficiently well understood. We could certainly put in a section that describes some of the issues when attempting to apply EAP to those problems. > This is not a problem in a protocol > like IPsec, because there are separate security associations in each > direction of the conversation, so each can be keyed by an independent > security association establishment. I'm curious as to why IKE can be used for independent security association establishment, whereas EAP-IKE cannot be. What is it about the EAP transport that somehow changes the security properties of an existing protocol? > constructions like 802.11i, however, because there is only one security > association per link. That seems like an 802.11 problem to me. There are certainly situations where EAP can be used with more than one security association per link. An example of this is PPPOE where it is possible to have a single host bringing up multiple PPP sesssions to different ISPs, all operating over the same link. Where EAP is used for authentication and key management, it is possible to use PPPOE today to bring up multiple security associations per link. So this isn't an EAP issue -- it's a link layer issue. > It is hard enough to get one authentication right let alone two. I would agree that the decision of IEEE 802.11i to do two authentications *then* do election seems odd. But I'm not sure why this decision was forced by the use of EAP. In general, I'd observe that in situations where problem requirements are poorly understood it is best to gain clarity *before* introducing potential solutions. There are quite a few situations where conventional EAP methods will not work well, but that's different from saying that *some* EAP method cannot be made to work. > Hence it appears to be a work item that can be deferred until EAP2 (or > whatever it is called this week). Since this problem is neither caused by, or solved by EAP, creating a new protocol is unlikely to add either to the clarity of the problem statement, or to the value of a solution. > If EAP and 802.1aa continue on their present courses, here are some > constraints I'd suggest: both parties MUST use the same concrete > authentication method with the same credentials for both authentications; Why? RFC 2284 explicitly states that this is *not* a constraint. > the authentication method MUST exchange random nonces; For a mutually authenticating method this is sound advice and we should add this. For a one-way method, it doesn't seem necessary though. > the authentication method MUST protect the nonces from modification; Seems reasonable. > each authentication MUST detect replay and man-in-the-middle attack in > BOTH directions; Seems reasonable. > if the two > peers initiate their separate authentications simultaneously, then they MUST > reuse the nonce they supplied for the authentication they initiated in the > authentication to which they are responding; Since we're already saying that two separate authentications is not equivalent to one mutual one, I'm not sure why we should try to mandate that they be interlinked. If the intent is to do something like this, why do two separate authentications in the first place, why not just do a single mutual auth? > if the peers do not initiate > simultaneously, then the peer that has not initiated should fall back to the > client-server model if it receives an authentication initiated by the peer It seems reasonable to suggest some sort of tie breaking behavior in the case where a single mutually authenticating conversation is desired. > More constraints may be needed, and some of these proposed constraints may > not be right, because, like I said, I don't claim I understand the problem, > but if you remove any one of these constraints, then I think it is possible > to construct attacks that can compromise at least an 802.11i protected link. Such an attack, if feasible, would derive from allowing two non-interlinked authentications, one in each direction. This isn't an EAP problem per say -- though we can certainly insert additional language advising against this. > The discussion > thus far has treated the peer-to-peer case as mechanical. I hope that people > agree with me that it is not, and much more toil is required. I would certainly agree that IEEE 802.11 "adhoc" or "mesh networking" requires more thought. But few of the issues you've brought up so far apply to the simple Bridge-Bridge cases discussed in IEEE 802.1aa. From yohba@tari.toshiba.com Wed Apr 30 07:08:26 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 29 Apr 2003 23:08:26 -0700 Subject: [eap] Issue 117: Miscellaneous Technical NITs In-Reply-To: References: <3EACD8CF.4030901@piuha.net> Message-ID: <20030430060826.GC659@steelhead> On Mon, Apr 28, 2003 at 06:21:54AM -0700, Bernard Aboba wrote: > > This seems a bit odd. First of all, Expanded Nak (254) does not > > really exist, all we have is "Expanded Types (254)" which is used > > both for the methods as well as the Nak. Secondly, the third > > and fourth sentences are about Nak while the rest of the paragraph > > applies both to Nak and Extended Nak. Finally, it seems odd that > > we have to list these things in the beginning of section 5, but > > not at the subsections devoted to Nak/Extended Nak. > > > > Suggested fix: Just keep the first two sentences of the original > > second paragraph. Formulate Nak and Extended Nak specific texts > > to sections 5.3.1 and 5.3.2. > > Will do. I think that the last sentence is redundant anyway, given the > existing text, so we can just drop it. > > > Hmm... why? So Notification can't appear between a completed method and > > success, for instance? > > Right. Or between a completed method and failure. That way after the > method is complete the next packet (Success/Failure) is pre-determined. What about a case where multiple authentication methods are running in a tunneling authentication method? (Prohibition of sequence of methods does not apply to methods inside a tunneling method.) In this case a completion of an authentication method is not always followed by by Success/Failure, but should we prohibit Notification at any method boundaries? Yoshihiro Ohba > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >