From aboba@internaut.com Sun Feb 2 20:55:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 2 Feb 2003 12:55:34 -0800 (PST) Subject: [eap] RFC 2869bis "pseudo WG last call" Message-ID: RFC 2869bis IETF last call will be occurring soon. To give EAP WG participants an opportunity to comment on the draft prior to IETF last call, we are going to hold a week-long "pseudo WG last call" prior to submitting a final -08 draft to the IETF archive on 2/9/03 and beginning a two week IETF last call. A copy of the strawman -08 draft is available here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt Please send any issues to the EAP WG mailing list, using the format described below: http://www.drizzle.com/~aboba/EAP/eapissues.html From henrik@levkowetz.com Mon Feb 3 14:08:52 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 3 Feb 2003 15:08:52 +0100 Subject: [eap] [Issue] Various 2284bis comments Message-ID: <20030203150852.000043c9.henrik@levkowetz.com> Hi, Going over the 2284bis draft, I've come up with some points I'd like to raise as issues for discussion. My comments are marked with HENRIK: -------------------------------------- In section 3.4: In 802.11 a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. In 802.11, control and management frames are not authenticated and an attacker within range can gain access to the physical medium. Link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). HENRIK: Very well, but what do we wish to say with that? Is there a conclusion here, or is this just FYI -------------------------------------- In section 4.1: When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. HENRIK: (I assume the state machine covers this? and also has other timers to guarantee that the protocol doesn't hang forever waiting for an infinite timer to expire. How much of this should be described here? Should some text be removed, with reference to the state machine document?) -------------------------------------- In section 4.2.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. HENRIK: In view of the possibility of inserting a false EAP Failure packet in e.g. wireless networks, maybe there should be a RECOMMENDED discard of premature Failure packets in the case of insecure link in combination with EAP methods with protected error indications? -------------------------------------- In section 7.2: [d] Key strength. If the method derives keys, then the effective key strength MUST be estimated. HENRIK: How should the estimated effective key strength be indicated? -------------------------------------- In section 7.: HENRIK: I believe I can see one security issue which has not been discussed in this section, but might be mentioned: If the authenticator uses pass-through to a backend authentication server, it seems to me that the authenticator will not understand method-specific success and failure indications, and are dependent on seeing the final EAP Success (or Failure) packet in order to know the outcome of the authentication. This means that the link between authenticator and backend authentication server needs to be secure against injection of false EAP Success or Failure indications. This is probably the case in most deployments, but might want mentioning for completeness? I can propose some text for your consideration. -------------------------------------- Regards, Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ From henrik@levkowetz.com Mon Feb 3 17:33:20 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 3 Feb 2003 18:33:20 +0100 Subject: [eap] new 2284bis intermediate draft available Message-ID: <20030203183320.00004746.henrik@levkowetz.com> Hi, I've put up a new intermediate version of the 22844bis draft on http://www.levkowetz.com/pub/ietf/drafts/eap/ . The changes are language and editorial changes, there are no changes related to open issues. I've also put up a diff against the -00a version (which has the same text as the -pppext -10 version), so you easily can see which changes have been made. Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow. From aboba@internaut.com Mon Feb 3 18:40:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 3 Feb 2003 10:40:24 -0800 (PST) Subject: [eap] concern on invalid MIC (fwd) Message-ID: This is an interesting corner case, Yoshi. How do people feel this should be handled? ---------- Forwarded message ---------- Date: Mon, 3 Feb 2003 12:25:58 -0500 From: Yoshihiro Ohba To: Bernard Aboba Subject: concern on invalid MIC Bernard, I'm sorry for discussing this issue again, but I am still not sure whether mandating silent discard of packets with invalid MIC is always good. For example, EAP-TLS and PEAP haves its own fragmentation mechanism outside the TLS, in which each fragment is carried in a single EAP Request/Response packet. In this case, since TLS MIC validation cannot be performed before reassembling the fragmented packets, so an attacker Authenticator can send a fragment with broken MIC. The packet will be accepted by the Peer as long as it is valid except for MIC, and EAP Requests sent by legitimate Authenticator after the attacker's attempt may be treated just as a deplicate Request. Finally, when all fragments are received by the Peer, the Peer reassembles a TLS record and will find invalid in terms of MIC. If this is a possible situation, how silently discarding the packet with invalid MIC can improve robustness againt the DoS attack of blindly injecting fragments? Yoshihiro Ohba From james.d.carlson@east.sun.com Mon Feb 3 19:56:43 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 3 Feb 2003 14:56:43 -0500 Subject: [eap] concern on invalid MIC (fwd) In-Reply-To: Bernard Aboba's message of 3 February 2003 10:40:24 References: Message-ID: <15934.51579.713355.112373@gargle.gargle.HOWL> Bernard Aboba writes: > This is an interesting corner case, Yoshi. > > How do people feel this should be handled? It sounds like breakage in the EAP-TLS and PEAP fragmentation mechanisms, rather than a problem with EAP itself. > If this is a possible situation, how silently discarding the packet > with invalid MIC can improve robustness againt the DoS attack of > blindly injecting fragments? If you're not doing a MIC per message, then it's hard for me to see what the value of the thing called a "MIC" might be. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Mon Feb 3 20:53:18 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 03 Feb 2003 15:53:18 -0500 Subject: [eap] editorial change - issue submission Message-ID: <839743.1044287598@[10.0.1.2]> Issue: Wording of some terminology Submitter: John Vollbrecht - jrv@umich.edu Date: Feb 3, 2003 Document:draft-ietf-eap-rfc2284bis-00a.txt Comment: Editorial Priority: 1 Section: 1.2 There are several change items described below. --------------------------- Item 1: authenticator description Rationale: EAP is a peer to peer protocol, supporting methods that do mutual authentication as well as methods that authenticate the user or server alone. suggested Change: change- authenticator The end of the link requiring the authentication. This terminology is also used in [IEEE.802-1X.2001], and has the same meaning in this document. to- 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]. --------------------------- Item 2: peer description Rationale: same as above, plus I think it is unnecessary to give examples of the media in the peer. If needed, perhaps a separate category could be created to describe the "link". I personally don't think that is necessary. suggested change: change- peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802 wired media) or 802.11 wireless link, which being authenticated by the authenticator. In [IEEE.802-1X.2001], this end is known as the Supplicant. to- 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. --------------------------- Item 3: backend authentication server Rationale: the description is too wordy and implies that the backend server is required for EAP. suggested change: change- backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. This service verifies from the credentials provided by the peer, the claim of identity made by the peer. This terminology is also used in [IEEE.802-1X.2001]. to- backend authentication server A backend authentication server is an entity that provides 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]. From jrv@umich.edu Mon Feb 3 21:16:43 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 03 Feb 2003 16:16:43 -0500 Subject: [eap] editorial change - issue submission Message-ID: <924022.1044289003@[10.0.1.2]> Issue: Wording of some terminology Submitter: John Vollbrecht - jrv@umich.edu Date: Feb 3, 2003 Document:draft-ietf-eap-rfc2284bis-00a.txt Comment: Editorial Priority: 1 Section: 1.2 There are several change items described below. ------------------------------ Item-a: EAP server description Rationale: The wording seems a bit confusing. Suggested Change: change- EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server. to- EAP server The entity that supports EAP method exchanges with the peer. This may be in the same device as the authenticator or it may be in a backend authetication server. ------------------------------ Item-b: Silently discard description Rationale: Implementation suggestions should be marked as notes. Probably should not be protocol SHOULDs Suggested Change: change- Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. to- Silently Discard This means the implementation discards the packet without further processing. [Note: Good practice indicates that implementations should provide the capability of logging the event, including the contents of the silently discarded packet, and shouldrecord the event in a statistics counter.] From henrik@levkowetz.com Mon Feb 3 21:33:40 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 3 Feb 2003 22:33:40 +0100 Subject: [eap] editorial change - issue submission In-Reply-To: <839743.1044287598@[10.0.1.2]> References: <839743.1044287598@[10.0.1.2]> Message-ID: <20030203223340.0000032d.henrik@levkowetz.com> >From an editorial viewpoint, comments marked HENRIK: below On Mon, 03 Feb 2003 15:53:18 -0500, John Vollbrecht wrote: > Issue: Wording of some terminology > Submitter: John Vollbrecht - jrv@umich.edu > Date: Feb 3, 2003 > Document:draft-ietf-eap-rfc2284bis-00a.txt > Comment: Editorial > Priority: 1 > Section: 1.2 > > There are several change items described below. > > --------------------------- > Item 1: authenticator description > Rationale: > > EAP is a peer to peer protocol, supporting methods that do mutual > authentication as well as methods that authenticate the user or server > alone. > > suggested Change: > > change- > authenticator > The end of the link requiring the authentication. This > terminology is also used in [IEEE.802-1X.2001], and has > the same meaning in this document. > to- > 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]. HENRIK: Makes sense to me. > --------------------------- > Item 2: peer description > Rationale: > same as above, plus I think it is unnecessary to give examples of the > media in the peer. If needed, perhaps a separate category could be created > to describe the "link". I personally don't think that is necessary. > > suggested change: > > change- > peer The other end of the point-to-point link (PPP), > point-to-point LAN segment (IEEE 802 wired media) or 802.11 > wireless link, which being authenticated by the > authenticator. In [IEEE.802-1X.2001], this end is known as > the Supplicant. > to- > 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. HENRIK: Looks good to me. > --------------------------- > Item 3: backend authentication server > Rationale: the description is too wordy and implies that the backend > server is required for EAP. > > suggested change: > > change- > backend authentication server > A backend authentication server is an entity that provides > an authentication service to an authenticator. This service > verifies from the credentials provided by the peer, the > claim of identity made by the peer. This terminology is > also used in [IEEE.802-1X.2001]. > to- > backend authentication server > A backend authentication server is an entity that provides > 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]. HENRIK: Makes sense to me, except I'd say either ... provides an authentication service ... or ... provides authentication services ... Regards, Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ Duct tape is like the Force. It has a light side and a dark side, and holds the universe together. From jrv@umich.edu Mon Feb 3 22:36:14 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 03 Feb 2003 17:36:14 -0500 Subject: [eap] issue - method sequence documentation Message-ID: <1210290.1044293774@[10.0.1.2]> Issue: Wording of some terminology Submitter: John Vollbrecht - jrv@umich.edu Date: Feb 3, 2003 Document:draft-ietf-eap-rfc2284bis-00a.txt Comment: Editorial Priority: 3 Section: 2.1 Issue: multiple methods in a sequence Rationale: Multiple methods may be used in sequence, some before and some after an actual authentication method. Thus an identity method may precede authentication, and a QoS method may follow. The wording in the RFC should not indicate that this is unexpected behaviour. Also, the details on when a NAK can be sent and what responses should occur should be moved to a separate section, or should reference a state machine document (rfc or appendix) Suggested Change change- 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- 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. Another example is an authentication method followed by a method that negotiates QoS parameters with the user. In both cases only one authentication Method is used. [Note: it is not considered good practice to allow the peer to "negotiate down" the EAP methods that do authentication. That is, trying a different authentication method after failing a method SHOULD not be allowed.] Sequences are driven by the authenticator end of the EAP connection. The authenticator proposes a method by sending an EAP request for that Method. The Peer can accept the method by responding to the request or refuse the method by responding with a NAK. On completion of one method the authenticator may attempt to initiate another method or may signal completion by sending either a Success or Failure message. Success or Failure messages indicate to the peer that the sequence is complete and that the authenticator believes the sequence has succeeded or failed. Note that each end of the EAP connection may independently decide whether to activate the connection, and in particular the peer may decide not to activate the connection based on the results of its EAP methods, regardless of the Success or Failure from the authenticator. This is what allow mutual authentication to work. Interactions between authenticator and peer in cases where messages are lost and retransmitted, where unexpected NAKs or timeouts occur are described in section (xxx or rfc xxx state machine). From henrik@levkowetz.com Tue Feb 4 00:48:42 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 4 Feb 2003 01:48:42 +0100 Subject: [eap] [issue] 2284bis - 7.2 security claim [f] excessive? Message-ID: <20030204014842.3b890376.henrik@levkowetz.com> Reviewing the 2284bis -eap -00b changes myself, I see there's one change which I think may warrant an issue after all: Issue: 7.2 security claim [f] excessive? Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: 4 Feb 2003 Document: draft-ietf-eap-rfc2284bis-00a.txt Comment type: Editorial Priority: 1 Section: 7.2 Rationale: 2284bis itself does not adhere to item [f] of section 7.2. So it seems that this item may be an excessive requirement, and might be removed or reworded? Discussion: In section 7.2, item [f] says about security claims for EAP methods: [f] Indication of vulnerabilities. In addition to the security claims that are made, the specification MUST indicate which of the security claims detailed in Section 1.2 are NOT being made, and discuss the security implications. However, for the methods specified in this draft in sections 5.4, 5.5, 5.6, there is no discussion of the security implications of the security claims not made. Either this requirement is excessive, or we need to produce discussions of the security implications made and not made for the MD5-challenge, One Time Password and Generic Token Card methods. Proposal: The last part of Section 7.2 item [f] is removed, producing this text: [f] Indication of vulnerabilities. In addition to the security claims that are made, the specification MUST indicate which of the security claims detailed in Section 1.2 are NOT being made. Regards, Henrik From henrik@levkowetz.com Tue Feb 4 14:27:32 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 4 Feb 2003 15:27:32 +0100 Subject: [eap] issue - method sequence documentation In-Reply-To: <1210290.1044293774@[10.0.1.2]> References: <1210290.1044293774@[10.0.1.2]> Message-ID: <20030204152732.0000591f.henrik@levkowetz.com> John, This change looks fine to me, with regards to the text, the proposed text is an easier read. The requirement "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." which is made in the old text but not in the proposed is covered under 7.8 Negotiation attacks, and not lost. There are some other requirements in the old text (mainly SHOULD's) which are not expressed with requirement language in the new text, but I think that the new text is ok on this point nevertheless. There's one thing, however, I'd like to question: The reference to the EAP state machine document in the last proposed paragraph seems to be normative, and binds the publication of 2284 bis to the publication of the state machine docment. Is that desireable? Henrik On Mon, 03 Feb 2003 17:36:14 -0500, John Vollbrecht wrote: > Issue: Wording of some terminology > Submitter: John Vollbrecht - jrv@umich.edu > Date: Feb 3, 2003 > Document:draft-ietf-eap-rfc2284bis-00a.txt > Comment: Editorial > Priority: 3 > Section: 2.1 > > Issue: multiple methods in a sequence > > Rationale: > > Multiple methods may be used in sequence, some before and some after an > actual authentication method. Thus an identity method may precede > authentication, and a QoS method may follow. The wording in the RFC should > not indicate that this is unexpected behaviour. > > Also, the details on when a NAK can be sent and what responses should occur > should be moved to a separate section, or should reference a state machine > document (rfc or appendix) > > Suggested Change > change- > > 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- > 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. Another example > is an authentication method followed by a method that negotiates QoS > parameters with the user. In both cases only one authentication Method > > is used. > [Note: it is not considered good practice to allow the peer to > "negotiate down" the EAP methods that do authentication. That is, > trying a different authentication method after failing a method SHOULD > not be allowed.] > > Sequences are driven by the authenticator end of the EAP connection. > The authenticator proposes a method by sending an EAP request for that > Method. The Peer can accept the method by responding to the request or > refuse the method by responding with a NAK. > > On completion of one method the authenticator may attempt to initiate > another method or may signal completion by sending either a Success or > Failure message. Success or Failure messages indicate to the peer that > the sequence is complete and that the authenticator believes the > sequence has succeeded or failed. > > Note that each end of the EAP connection may independently decide whether > > to activate the connection, and in particular the peer may decide not to > > activate the connection based on the results of its EAP methods, > regardless of the Success or Failure from the authenticator. This is > what allow mutual authentication to work. > > Interactions between authenticator and peer in cases where messages are > lost and retransmitted, where unexpected NAKs or timeouts occur are > described in section (xxx or rfc xxx state machine). > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ It is impossible for a man to love his wife wholeheartedly without loving all women somewhat. I suppose that the converse must be true of women. -- Lazarus Long in 'Time Enough for Love' From henrik@levkowetz.com Tue Feb 4 14:32:02 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 4 Feb 2003 15:32:02 +0100 Subject: [eap] editorial change - issue submission In-Reply-To: <924022.1044289003@[10.0.1.2]> References: <924022.1044289003@[10.0.1.2]> Message-ID: <20030204153202.00005a40.henrik@levkowetz.com> John, To me these look good. Henrik On Mon, 03 Feb 2003 16:16:43 -0500, John Vollbrecht wrote: > Issue: Wording of some terminology > Submitter: John Vollbrecht - jrv@umich.edu > Date: Feb 3, 2003 > Document:draft-ietf-eap-rfc2284bis-00a.txt > Comment: Editorial > Priority: 1 > Section: 1.2 > > There are several change items described below. > ------------------------------ > Item-a: EAP server description > Rationale: > The wording seems a bit confusing. > > Suggested Change: > change- > EAP server > The entity that terminates the EAP authentication with the > peer. In the case where there is no backend authentication > server, this term refers to the authenticator. Where the > authenticator operates in pass-through, it refers to the > backend authentication server. > to- > EAP server > The entity that supports EAP method exchanges with the > peer. This may be in the same device as the authenticator or > > it may be in a backend authetication server. > > ------------------------------ > Item-b: Silently discard description > Rationale: > Implementation suggestions should be marked as notes. Probably should not > be protocol SHOULDs > > Suggested Change: > change- > Silently Discard > This means the implementation discards the packet without > further processing. The implementation SHOULD provide the > capability of logging the event, including the contents of > the silently discarded packet, and SHOULD record the event > in a statistics counter. > to- > Silently Discard > This means the implementation discards the packet without > further processing. > [Note: Good practice indicates that implementations should > provide the capability of logging the event, including the > contents of the silently discarded packet, and shouldrecord > the event in a statistics counter.] > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ "Welcome to President Bush, Mrs. Bush, and my fellow astronauts." -- J. Danforth Quayle From jsalowey@cisco.com Tue Feb 4 17:02:38 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Tue, 4 Feb 2003 09:02:38 -0800 Subject: [eap] EAP-Keying issue Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF3FE@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Description of issue: Inconsistency in EAP Keying Submitter name: Joseph Salowey=20 Submitter email address: jsalowey@cisco.com=20 Date first submitted: Feb 4, 2003 Reference:=20 Document: RFC2284bis, Keying Framework Comment type: T=20 Priority: 1 Section: 7.9=20 Rationale/Explanation of issue:=20 Currently EAP provides a consistent interface to authentication data but it does not provide a consistent interface to deal with key data. This makes it difficult to treat EAP mechanisms similarly. EAP mechanisms end up needing to know more about applications then they should and applications do not have a consistent way of deriving keys. The following proposal addresses this. Requested change:=20 In the description below the term "EAP Framework" controls the interaction between and EAP mechanism and the environment. The term "application" refers to a consumer of EAP authentication service and key material. An application may be a link layer protocol such as 802.11 or another EAP mechanism chained into the EAP conversation after initial authentication. If an EAP mechanism derives keys then it MUST be able to export a 256-bit Master Session Key (MSK) to the EAP framework. THis key must be cryptographically independent of the Master Key (MK) established within the authentication mechanism or any other key used by the authentication mechanism. In this case cryptographically independent means that knowledge of the MSK will not give away information of the MK. The underlying entropy used to generate the key SHOULD be at least a 128 bits (more if greater than 128-bit ciphers are in use by applications). The MSK is never used in an application directly rather it is used to derive application specific master session keys and ciphering keys. The following describes the EAP key derivation mechanism. The EAP key derivation function is as follows Key =3D PRF(MSK, key seed, length) Where MSK is the master session keys described above, the key seed is an application specific value which is unique to each application, and length is the number of bytes of key material needed. The PRF is a suitable pseudo-random function. Good candidates for the PRF are the IKE PRF, the TLS PRF and possibly the SHS PRF. The keys seed is an octet string which should be assigned by IANA for application uses. Examples of some key seeds are: "IEEE 802.11i Master Session Key" "IEEE 802.11 WEP session key" "IEEE 802.11 WEP authentication key" "Protected TLV master key" "Blah Blah Re-authentication key" Each application must register a key seed and a length. The EAP framework implementation SHOULD provide a means for obtaining an application specific key. For example the framework may provide a function: byte[] getAppKey(byte[] seed, int length) This would allow the MSK to be kept internally and only application specific keys be returned to the requester. A savy implementation my restrict access to a particular key based on the caller. This function would return null no keys have been generated. If multiple EAP methods have generated MSKs then these MSKs are combined using the PRF in the following way. MSK =3D PRF(MSK1, MSK2, 32) The new master session key is used to derive further keys. =20 It should be noted that a small amount of entropy is lost each time the PRF is run. This is not expected to be much of a problem since typically only a few application specific keys will be required. In addition most application derived keying material is kept secret and would only be exposed in th case of weak ciphering (as in WEP).=20 From henrik@levkowetz.com Tue Feb 4 17:29:16 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 4 Feb 2003 18:29:16 +0100 Subject: [eap] EAP-Keying issue In-Reply-To: <4D1E846548771F4AA7FAE28F4B358DB5012EF3FE@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> References: <4D1E846548771F4AA7FAE28F4B358DB5012EF3FE@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Message-ID: <20030204182916.000008ee.henrik@levkowetz.com> Joe, Is this issue regarding the rfc2284bis document: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-10.txt , or regarding the Keying Framework document: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt , or do you propose changes to both documents? Henrik On Tue, 4 Feb 2003 09:02:38 -0800, "Joe Salowey" wrote: > Description of issue: Inconsistency in EAP Keying > Submitter name: Joseph Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: Feb 4, 2003 > Reference: > Document: RFC2284bis, Keying Framework > Comment type: T > Priority: 1 > Section: 7.9 > Rationale/Explanation of issue: > Currently EAP provides a consistent interface to authentication data but > it does not provide a consistent interface to deal with key data. This > makes it difficult to treat EAP mechanisms similarly. EAP mechanisms > end up needing to know more about applications then they should and > applications do not have a consistent way of deriving keys. The > following proposal addresses this. > > Requested change: > > In the description below the term "EAP Framework" controls the > interaction between and EAP mechanism and the environment. The term > "application" refers to a consumer of EAP authentication service and key > material. An application may be a link layer protocol such as 802.11 or > another EAP mechanism chained into the EAP conversation after initial > authentication. > > If an EAP mechanism derives keys then it MUST be able to export a > 256-bit Master Session Key (MSK) to the EAP framework. THis key must be > cryptographically independent of the Master Key (MK) established within > the authentication mechanism or any other key used by the authentication > mechanism. In this case cryptographically independent means that > knowledge of the MSK will not give away information of the MK. The > underlying entropy used to generate the key SHOULD be at least a 128 > bits (more if greater than 128-bit ciphers are in use by applications). > The MSK is never used in an application directly rather it is used to > derive application specific master session keys and ciphering keys. The > following describes the EAP key derivation mechanism. > > The EAP key derivation function is as follows > > Key = PRF(MSK, key seed, length) > > Where MSK is the master session keys described above, the key seed is an > application specific value which is unique to each application, and > length is the number of bytes of key material needed. The PRF is a > suitable pseudo-random function. Good candidates for the PRF are the > IKE PRF, the TLS PRF and possibly the SHS PRF. The keys seed is an > octet string which should be assigned by IANA for application uses. > Examples of some key seeds are: > > "IEEE 802.11i Master Session Key" > "IEEE 802.11 WEP session key" > "IEEE 802.11 WEP authentication key" > "Protected TLV master key" > "Blah Blah Re-authentication key" > > Each application must register a key seed and a length. The EAP > framework implementation SHOULD provide a means for obtaining an > application specific key. For example the framework may provide a > function: > > byte[] getAppKey(byte[] seed, int length) > > This would allow the MSK to be kept internally and only application > specific keys be returned to the requester. A savy implementation my > restrict access to a particular key based on the caller. This function > would return null no keys have been generated. If multiple EAP methods > have generated MSKs then these MSKs are combined using the PRF in the > following way. > > MSK = PRF(MSK1, MSK2, 32) > > The new master session key is used to derive further keys. > > It should be noted that a small amount of entropy is lost each time the > PRF is run. This is not expected to be much of a problem since > typically only a few application specific keys will be required. In > addition most application derived keying material is kept secret and > would only be exposed in th case of weak ciphering (as in WEP). > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ An elephant: A mouse built to government specifications. -- Lazarus Long in 'Time Enough for Love' From jsalowey@cisco.com Tue Feb 4 17:50:33 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Tue, 4 Feb 2003 09:50:33 -0800 Subject: [eap] EAP-Keying issue Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF3FF@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Hi Henrik, I am targeting the changes to rfc2284bis, however it may impact the keying document as well. I don't have specific information for the keying document, so I guess we should mark it as 2284bis and if it results in changes in the keying document we can make it a separate issue. Joe > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Tuesday, February 04, 2003 9:29 AM > To: Joe Salowey > Cc: eap@frascone.com > Subject: Re: [eap] EAP-Keying issue >=20 >=20 > Joe, >=20 > Is this issue regarding the rfc2284bis document:=20 > =20 > http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b > is-10.txt , >=20 > or regarding the Keying Framework document: > =20 > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-pro > blem-05.txt , >=20 > or do you propose changes to both documents? >=20 > Henrik >=20 > On Tue, 4 Feb 2003 09:02:38 -0800, "Joe Salowey"=20 > wrote: > > Description of issue: Inconsistency in EAP Keying > > Submitter name: Joseph Salowey > > Submitter email address: jsalowey@cisco.com=20 > > Date first submitted: Feb 4, 2003 > > Reference:=20 > > Document: RFC2284bis, Keying Framework > > Comment type: T=20 > > Priority: 1 > > Section: 7.9=20 > > Rationale/Explanation of issue:=20 > > Currently EAP provides a consistent interface to=20 > authentication data but > > it does not provide a consistent interface to deal with=20 > key data. This > > makes it difficult to treat EAP mechanisms similarly. EAP=20 > mechanisms > > end up needing to know more about applications then they should and > > applications do not have a consistent way of deriving keys. The > > following proposal addresses this. > >=20 > > Requested change: > >=20 > > In the description below the term "EAP Framework" controls the=20 > > interaction between and EAP mechanism and the environment. =20 > The term=20 > > "application" refers to a consumer of EAP authentication=20 > service and=20 > > key material. An application may be a link layer protocol such as=20 > > 802.11 or another EAP mechanism chained into the EAP conversation=20 > > after initial authentication. > >=20 > > If an EAP mechanism derives keys then it MUST be able to export a=20 > > 256-bit Master Session Key (MSK) to the EAP framework. =20 > THis key must=20 > > be cryptographically independent of the Master Key (MK) established=20 > > within the authentication mechanism or any other key used by the=20 > > authentication mechanism. In this case cryptographically=20 > independent means that > > knowledge of the MSK will not give away information of the MK. The > > underlying entropy used to generate the key SHOULD be at=20 > least a 128=20 > > bits (more if greater than 128-bit ciphers are in use by=20 > > applications). The MSK is never used in an application=20 > directly rather=20 > > it is used to derive application specific master session keys and=20 > > ciphering keys. The following describes the EAP key derivation=20 > > mechanism. > >=20 > > The EAP key derivation function is as follows > >=20 > > Key =3D PRF(MSK, key seed, length) > >=20 > > Where MSK is the master session keys described above, the=20 > key seed is=20 > > an application specific value which is unique to each=20 > application, and=20 > > length is the number of bytes of key material needed. The PRF is a=20 > > suitable pseudo-random function. Good candidates for the=20 > PRF are the=20 > > IKE PRF, the TLS PRF and possibly the SHS PRF. The keys seed is an=20 > > octet string which should be assigned by IANA for application uses.=20 > > Examples of some key seeds are: > >=20 > > "IEEE 802.11i Master Session Key" > > "IEEE 802.11 WEP session key" > > "IEEE 802.11 WEP authentication key" > > "Protected TLV master key" > > "Blah Blah Re-authentication key" > >=20 > > Each application must register a key seed and a length. The EAP=20 > > framework implementation SHOULD provide a means for obtaining an=20 > > application specific key. For example the framework may provide a > > function: > >=20 > > byte[] getAppKey(byte[] seed, int length) > >=20 > > This would allow the MSK to be kept internally and only application=20 > > specific keys be returned to the requester. A savy=20 > implementation my=20 > > restrict access to a particular key based on the caller.=20 > This function=20 > > would return null no keys have been generated. If multiple EAP=20 > > methods have generated MSKs then these MSKs are combined using the=20 > > PRF in the following way. > >=20 > > MSK =3D PRF(MSK1, MSK2, 32) > >=20 > > The new master session key is used to derive further keys. > >=20 > > It should be noted that a small amount of entropy is lost each time=20 > > the PRF is run. This is not expected to be much of a problem since=20 > > typically only a few application specific keys will be=20 > required. In=20 > > addition most application derived keying material is kept=20 > secret and=20 > > would only be exposed in th case of weak ciphering (as in WEP).=20 > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 > Henrik >=20 > --=20 >=20 > Henrik Levkowetz +46708321608 henrik@ipunplugged.com=20 www.ipunplugged.com ------------------------------------------------------------------------ An elephant: A mouse built to government specifications.=20 -- Lazarus Long in 'Time Enough for Love' From jrv@umich.edu Tue Feb 4 19:50:13 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Feb 2003 14:50:13 -0500 Subject: [eap] issue - method sequence documentation In-Reply-To: <20030204152732.0000591f.henrik@levkowetz.com> References: <1210290.1044293774@[10.0.1.2]> <20030204152732.0000591f.henrik@levkowetz.com> Message-ID: <1830236.1044370212@[10.0.1.2]> comment inline --On Tuesday, February 4, 2003 3:27 PM +0100 Henrik Levkowetz wrote: > John, > > This change looks fine to me, with regards to the text, > the proposed text is an easier read. > > The requirement > "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." > > which is made in the old text but not in the proposed is covered > under 7.8 Negotiation attacks, and not lost. There are some other > requirements in the old text (mainly SHOULD's) which are not expressed > with requirement language in the new text, but I think that the new text > is ok on this point nevertheless. > > There's one thing, however, I'd like to question: The reference > to the EAP state machine document in the last proposed paragraph seems > to be normative, and binds the publication of 2284 bis to the > publication of the state machine docment. Is that desireable? > > Henrik > I think the state machine will not be normative if it is a separate rfc. I am wondering if it should not be an appendix to the eap-bis rfc. what do others think? -- JohnV > On Mon, 03 Feb 2003 17:36:14 -0500, John Vollbrecht wrote: > > Issue: Wording of some terminology > > Submitter: John Vollbrecht - jrv@umich.edu > > Date: Feb 3, 2003 > > Document:draft-ietf-eap-rfc2284bis-00a.txt > > Comment: Editorial > > Priority: 3 > > Section: 2.1 > > > > Issue: multiple methods in a sequence > > > > Rationale: > > > > Multiple methods may be used in sequence, some before and some after an > > actual authentication method. Thus an identity method may precede > > authentication, and a QoS method may follow. The wording in the RFC > > should not indicate that this is unexpected behaviour. > > > > Also, the details on when a NAK can be sent and what responses should > > occur should be moved to a separate section, or should reference a > > state machine document (rfc or appendix) > > > > Suggested Change > > change- > > > > 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- > > 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. Another example > > is an authentication method followed by a method that negotiates QoS > > parameters with the user. In both cases only one authentication > > Method > > > > is used. > > [Note: it is not considered good practice to allow the peer to > > "negotiate down" the EAP methods that do authentication. That is, > > trying a different authentication method after failing a method SHOULD > > not be allowed.] > > > > Sequences are driven by the authenticator end of the EAP connection. > > The authenticator proposes a method by sending an EAP request for that > > Method. The Peer can accept the method by responding to the request > > or refuse the method by responding with a NAK. > > > > On completion of one method the authenticator may attempt to initiate > > another method or may signal completion by sending either a Success or > > Failure message. Success or Failure messages indicate to the peer > > that the sequence is complete and that the authenticator believes the > > sequence has succeeded or failed. > > > > Note that each end of the EAP connection may independently decide > > whether > > > > to activate the connection, and in particular the peer may decide not > > to > > > > activate the connection based on the results of its EAP methods, > > regardless of the Success or Failure from the authenticator. This is > > what allow mutual authentication to work. > > > > Interactions between authenticator and peer in cases where messages > > are lost and retransmitted, where unexpected NAKs or timeouts occur > > are described in section (xxx or rfc xxx state machine). > > > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > Henrik > > -- > > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > ------------------------------------------------------------------------ > > It is impossible for a man to love his wife wholeheartedly without > loving all women somewhat. I suppose that the converse must be true of > women. > -- Lazarus Long in 'Time Enough for Love' From aboba@internaut.com Tue Feb 4 23:27:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 15:27:18 -0800 (PST) Subject: [eap] Issue 73: Various RFC 2284bis Comments In-Reply-To: <20030203180002.10550.56211.Mailman@wolverine> Message-ID: > Message: 2 > Date: Mon, 3 Feb 2003 15:08:52 +0100 > From: Henrik Levkowetz > To: "eap@frascone.com" > Subject: [eap] [Issue] Various 2284bis comments > > Hi, > > Going over the 2284bis draft, I've come up with some points I'd like > to raise as issues for discussion. My comments are marked with HENRIK: Filed as Issue #73 From aboba@internaut.com Wed Feb 5 00:01:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 16:01:08 -0800 (PST) Subject: [eap] Issue 77: Section 7.2 security claim [f] excessive In-Reply-To: <20030204142802.2508.72096.Mailman@wolverine> Message-ID: I would like to recommend that we accept this change. Claim [f] is indeed excessive -- it was so bothersome that it hardly even seemed worthwhile to bothering complying with it, within the same document! > Issue: 7.2 security claim [f] excessive? > Submitter name: Henrik Levkowetz > Submitter email address: henrik@levkowetz.com > Date first submitted: 4 Feb 2003 > Document: draft-ietf-eap-rfc2284bis-00a.txt > Comment type: Editorial > Priority: 1 > Section: 7.2 > Rationale: > > 2284bis itself does not adhere to item [f] of section 7.2. So it seems > that this item may be an excessive requirement, and might be removed > or reworded? From aboba@internaut.com Wed Feb 5 00:12:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 16:12:14 -0800 (PST) Subject: [eap] Issue 76: Multiple methods in sequence Message-ID: I would like to recommend against this change. RFC 2284bis is not a greenfield protocol, and so an important consideration is backward compatibility with existing implementations. To my knowledge, there are no existing EAP implementations that support sequences. In discussion it was noted that some implementations would have fundamental problems in supporting sequences. Also James Carlson noted that for his implementation, he interpreted the original RFC 2284 language as discouraging sequences: In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user 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. In terms of the suggested language here are some issues: "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. Another example is an authentication method followed by a method that negotiates QoS parameters with the user. In both cases only one authentication Method is used." [BA] -- RFC 2284bis is focused on clarifying the existing specification and addressing interoperability issues, not adding major new functionality such as QoS negotiation. [Note: it is not considered good practice to allow the peer to "negotiate down" the EAP methods that do authentication. That is, trying a different authentication method after failing a method SHOULD not be allowed.] [BA] - this would introduce indeterminacy in the state machine, I think. Sequences are driven by the authenticator end of the EAP connection. The authenticator proposes a method by sending an EAP request for that Method. The Peer can accept the method by responding to the request or refuse the method by responding with a NAK. On completion of one method the authenticator may attempt to initiate another method or may signal completion by sending either a Success or Failure message. Success or Failure messages indicate to the peer that the sequence is complete and that the authenticator believes the sequence has succeeded or failed. Note that each end of the EAP connection may independently decide whether to activate the connection, and in particular the peer may decide not to activate the connection based on the results of its EAP methods, regardless of the Success or Failure from the authenticator. This is what allow mutual authentication to work. [BA] This seems like it would create interoperability problems, and potentially add some security vulnerabilities as well. Interactions between authenticator and peer in cases where messages are lost and retransmitted, where unexpected NAKs or timeouts occur are described in section (xxx or rfc xxx state machine)." [BA] RFC 2284bis is designed to be a standalone document and should not depend on the state machine document. From aboba@internaut.com Wed Feb 5 00:34:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 16:34:08 -0800 (PST) Subject: [eap] Issue 74: Concern on invalid MIC Message-ID: I agree with James that it is best if the MIC applies to individual datagrams, but there are situations in which this is not possible. For example, unlike GSS-API, in EAP a key is not assumed available until it is derived later in the conversation. This means that the Identity and Nak messages cannot be authenticated when they are sent -- because the method hasn't run yet, there is no key with which to authenticate them. However, as we've discussed, it is possible to authenticate the uncovered part of the conversation by including those packets in a MIC sent later on, after keys have been derived. How about this suggested text? " If a per-packet Message Integrity Check (MIC) is employed within an EAP method, then implementations MUST silently discard any message that fails this check. In this document, the descriptions of EAP message handling assume that per-packet MIC validation is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code'). Some EAP methods may define MICs that cover more than one EAP packet. Since the Identity Request/Response, Nak Response or Notification Request/Response messages are not authenticated, once an EAP method derives keys it may be desirable to exchange MICs that cover these unauthenticated packets, so as to be able to detect forgeries after the fact. Alternatively, an EAP method may define a MIC covering an extended PDU that could be split into multiple fragments. In these situations, failure of MIC validation is typically a fatal error, since it may not be possible to recover the original state and continue the exchange. It should be understood that this increases vulnerability to denial of service attacks." ----------------------------------------------------------------------- Issue 74: Concern on invalid MIC Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: Section 4.1 says: " If a Message Integrity Check (MIC) is employed within an EAP method, then implementations MUST silently discard any message that fails this check. In this document, the descriptions of EAP message handling assume that MIC validation is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code')." I'm sorry for discussing this issue again, but I am still not sure whether mandating silent discard of packets with invalid MIC is always good. For example, EAP-TLS and PEAP haves its own fragmentation mechanism outside the TLS, in which each fragment is carried in a single EAP Request/Response packet. In this case, since TLS MIC validation cannot be performed before reassembling the fragmented packets, so an attacker Authenticator can send a fragment with broken MIC. The packet will be accepted by the Peer as long as it is valid except for MIC, and EAP Requests sent by legitimate Authenticator after the attacker's attempt may be treated just as a deplicate Request. Finally, when all fragments are received by the Peer, the Peer reassembles a TLS record and will find invalid in terms of MIC. If this is a possible situation, how silently discarding the packet with invalid MIC can improve robustness againt the DoS attack of blindly injecting fragments? Yoshihiro Ohba Comment from James Carlson: It sounds like breakage in the EAP-TLS and PEAP fragmentation mechanisms, rather than a problem with EAP itself. > If this is a possible situation, how silently discarding the packet > with invalid MIC can improve robustness againt the DoS attack of > blindly injecting fragments? If you're not doing a MIC per message, then it's hard for me to see what the value of the thing called a "MIC" might be. From yohba@tari.toshiba.com Wed Feb 5 01:50:45 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 4 Feb 2003 20:50:45 -0500 Subject: [eap] additional concern on invalid MIC Message-ID: <20030205015044.GA7984@catfish> I think the policy of silently discarding packets with invalid MIC might not work as expected when a pass-through authenticator is used. Since the pass-through authenticator is not able to perform integrity check for EAP Response messages, when an attacker Peer sends an EAP Response with invalid MIC, the authenticator will pass it to the backend EAP server as long as it is valid except for MIC. Once this happens, an EAP Response message sent from the legitimate Peer will be treated as duplicate Response and thus silently discarded at the pass-through authenticator. The policy of silently discarding packets with invalid MIC does not seem to work anything good for this type of DoS attack, and this problem seems to be common to all methods. It seems that lower-layer needs to be secure to EAP, or the EAP server might need to inform the pass-through authenticator whenever it finds an EAP Response with invalid MIC so that the authenticator can treat the already forwarded EAP Response as "invalid". Yoshihiro Ohba From aboba@internaut.com Wed Feb 5 01:01:23 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 17:01:23 -0800 (PST) Subject: [eap] Re: Issue 73: Various RFC 2284bis Comments Message-ID: Some thoughts: "HENRIK: Very well, but what do we wish to say with that? Is there a conclusion here, or is this just FYI" BA: There used to be a conclusion there, but somehow it got lost :) I think that the point of this (if indeed there is one) was to clarify a paragraph in RFC 2284 (has anyone implemented this?): Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure. The idea of the new text is to clarify that packets like LCP Terminate-Request can cause a link to go down, and therefore can cause EAP authentication to fail. But packets like NCP mentioned above do not cause EAP authentication to succeed. ----------------------------------- HENRIK: (I assume the state machine covers this? and also has other timers to guarantee that the protocol doesn't hang forever waiting for an infinite timer to expire. How much of this should be described here? Should some text be removed, with reference to the state machine document?) BA: I think that the state machine should probably cover the various ways in which the RTO timer can be set. This includes [RFC2988] algorithms by default; RFC 2869bis and 2284bis already has text that state how the RTO can be set via the Session-Timeout attribute in RADIUS. So that same interface can presumably be used by the lower layer to manipulate the EAP RTO value. ----------------------------------- HENRIK: In view of the possibility of inserting a false EAP Failure packet in e.g. wireless networks, maybe there should be a RECOMMENDED discard of premature Failure packets in the case of insecure link in combination with EAP methods with protected error indications? BA: I would argue that premature Failure packets should always be discarded. If the method isn't "complete" then they are unexpected. This isn't that much of a constraint, since methods should probably terminate via their own error messages, as opposed to by sending an EAP Failure right away. ----------------------------------- HENRIK: How should the estimated effective key strength be indicated? BA: An excellent question :) Do you have a proposal? ----------------------------------- HENRIK: I believe I can see one security issue which has not been discussed in this section, but might be mentioned: If the authenticator uses pass-through to a backend authentication server, it seems to me that the authenticator will not understand method-specific success and failure indications, and are dependent on seeing the final EAP Success (or Failure) packet in order to know the outcome of the authentication. This means that the link between authenticator and backend authentication server needs to be secure against injection of false EAP Success or Failure indications. This is probably the case in most deployments, but might want mentioning for completeness? I can propose some text for your consideration. BA: Actually, the authenticator only looks for the AAA Accept/Reject and does not peer into the encapsulated EAP packet. Nevertheless, injection of spoofed EAP packets of any kind between the AAA server and authenticator would be a bad thing. This is discussed in the Security Considerations section of RFC 2869bis, and you might want to steal some text from there: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt ================================================================= Issue 73: Various RFC 2284bis Comments Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: T Priority: S Section: various Rationale/Explanation of issue: Hi, Going over the 2284bis draft, I've come up with some points I'd like to raise as issues for discussion. My comments are marked with HENRIK: -------------------------------------- In section 3.4: In 802.11 a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. In 802.11, control and management frames are not authenticated and an attacker within range can gain access to the physical medium. Link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). HENRIK: Very well, but what do we wish to say with that? Is there a conclusion here, or is this just FYI -------------------------------------- In section 4.1: When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. HENRIK: (I assume the state machine covers this? and also has other timers to guarantee that the protocol doesn't hang forever waiting for an infinite timer to expire. How much of this should be described here? Should some text be removed, with reference to the state machine document?) -------------------------------------- In section 4.2.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. HENRIK: In view of the possibility of inserting a false EAP Failure packet in e.g. wireless networks, maybe there should be a RECOMMENDED discard of premature Failure packets in the case of insecure link in combination with EAP methods with protected error indications? -------------------------------------- In section 7.2: [d] Key strength. If the method derives keys, then the effective key strength MUST be estimated. HENRIK: How should the estimated effective key strength be indicated? -------------------------------------- In section 7.: HENRIK: I believe I can see one security issue which has not been discussed in this section, but might be mentioned: If the authenticator uses pass-through to a backend authentication server, it seems to me that the authenticator will not understand method-specific success and failure indications, and are dependent on seeing the final EAP Success (or Failure) packet in order to know the outcome of the authentication. This means that the link between authenticator and backend authentication server needs to be secure against injection of false EAP Success or Failure indications. This is probably the case in most deployments, but might want mentioning for completeness? I can propose some text for your consideration. From aboba@internaut.com Wed Feb 5 01:32:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 17:32:11 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: <20030205021401.18642.87449.Mailman@wolverine> Message-ID: Yoshi wrote: > I think the policy of silently discarding packets with invalid MIC > might not work as expected when a pass-through authenticator is used. > > Since the pass-through authenticator is not able to perform integrity > check for EAP Response messages, when an attacker Peer sends an EAP > Response with invalid MIC, the authenticator will pass it to the > backend EAP server as long as it is valid except for MIC. Once this > happens, an EAP Response message sent from the legitimate Peer will be > treated as duplicate Response and thus silently discarded at the > pass-through authenticator. Yes, I think this is right. > The policy of silently discarding packets with invalid MIC does not > seem to work anything good for this type of DoS attack, and this > problem seems to be common to all methods. It seems that lower-layer > needs to be secure to EAP, or the EAP server might need to inform the > pass-through authenticator whenever it finds an EAP Response with > invalid MIC so that the authenticator can treat the already forwarded > EAP Response as "invalid". But by then it is presumably too late, no? Do you have a recommendation? From jrv@umich.edu Wed Feb 5 03:35:33 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Feb 2003 22:35:33 -0500 Subject: [eap] Issue 76: Multiple methods in sequence In-Reply-To: References: Message-ID: <3000830.1044398132@[10.0.1.2]> --On Tuesday, February 4, 2003 4:12 PM -0800 Bernard Aboba wrote: > I would like to recommend against this change. RFC 2284bis is not a > greenfield protocol, and so an important consideration is backward > compatibility with existing implementations. To my knowledge, there > are no existing EAP implementations that support sequences. > [JohnV]I am not sure what the comment about greenfield is meant to imply. I don'at think the intent of this is to only define what someone has implemented. If that was the case then a lot of what we have been discussing would be moot. I believe we are to clarify the wording to make interoperation possible. If you do not think sequences should be part of this then why have we been discussing them? Implementations should not be required to implement sequences, but they should be allowed. > In discussion it was noted that some implementations would have > fundamental problems in supporting sequences. Also James Carlson noted > that for his implementation, he interpreted the original RFC 2284 > language as discouraging sequences: > > In practice, within or associated with each PPP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set (such as PAP > rather than EAP). Instead, for each named user there should be an > indication of exactly one method used to authenticate that user name. > If a user 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. > [JohnV] We have had this discussionon the list. we agree that negotiating down authentication methods is a bad idea. We apparently don't agree that other methods should be allowed. I know that there are designs which expect to use eap method sequences, and prohibiting them would limit what can be done within the scope of the original rfc. > In terms of the suggested language here are some issues: > > "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. Another example > is an authentication method followed by a method that negotiates QoS > parameters with the user. In both cases only one authentication Method > is used." > > [BA] -- RFC 2284bis is focused on clarifying the existing specification > and addressing interoperability issues, not adding major new functionality > such as QoS negotiation. [JohnV] Nothing here is adding QoS functionality. The intent was to indicate that sequences are legal. If QoS is a bad example then we should find another. > > [Note: it is not considered good practice to allow the peer to > "negotiate down" the EAP methods that do authentication. That is, > trying a different authentication method after failing a method SHOULD > not be allowed.] > > [BA] - this would introduce indeterminacy in the state machine, I think. > [JohnV] - I don't think so -- the state machines are designed to handle exactly this. > Sequences are driven by the authenticator end of the EAP connection. > The authenticator proposes a method by sending an EAP request for that > Method. The Peer can accept the method by responding to the request or > refuse the method by responding with a NAK. > > On completion of one method the authenticator may attempt to initiate > another method or may signal completion by sending either a Success or > Failure message. Success or Failure messages indicate to the peer that > the sequence is complete and that the authenticator believes the > sequence has succeeded or failed. > > Note that each end of the EAP connection may independently decide whether > to activate the connection, and in particular the peer may decide not to > activate the connection based on the results of its EAP methods, > regardless of the Success or Failure from the authenticator. This is > what allow mutual authentication to work. > > [BA] This seems like it would create interoperability problems, and > potentially add some security vulnerabilities as well. > [JohnV] I don't see why -- can you be more specific about the problems and vulnerabilities? > Interactions between authenticator and peer in cases where messages are > lost and retransmitted, where unexpected NAKs or timeouts occur are > described in section (xxx or rfc xxx state machine)." > > [BA] RFC 2284bis is designed to be a standalone document and should not > depend on the state machine document. > [JohnV] I agree that it should be stand alone. That is why I suggested section xxx. Some of the text for section xxx might be driven off the state machine, and I am beginning to think the state machine would be a good appendix. Without it there will confusion about how EAP should actually work. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Feb 5 04:13:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 20:13:08 -0800 (PST) Subject: [eap] Issue 76: Multiple methods in sequences In-Reply-To: <3000830.1044398132@[10.0.1.2]> Message-ID: > If you do not think sequences should be part of > this then why have we been discussing them? Implementations should not be > required to implement sequences, but they should be allowed. There's no language in RFC 2284 suggesting that sequences are a MUST NOT, nor has anyone so far suggested that they be forbidden. On the other hand, we have had input from implementors that say that their implementations would not react well to sequences, can't implement sequences, or interpret RFC 2284 as discouraging use of sequences. Also, there have been questions about whether sequences open up new security vulnerabilities (draft-puthenkulam-eap-binding-01.txt). Given all of this, it's hard to make a case that RFC 2284bis can be neutral on the subject. The suggestion from James (and others) was to interpret the RFC 2284 admonitions as applying to sequences. Given all the evidence, this seems like a reasonable thing to do. > [JohnV] We have had this discussionon the list. we agree that negotiating > down authentication methods is a bad idea. We apparently don't agree that > other methods should be allowed. I know that there are designs which > expect to use eap method sequences, and prohibiting them would limit what > can be done within the scope of the original rfc. It's hard to argue that RFC 2284bis is imposing a limitation when implementors seem to be assuming that the limitation was part of RFC 2284. > > Note that each end of the EAP connection may independently decide whether > > to activate the connection, and in particular the peer may decide not to > > activate the connection based on the results of its EAP methods, > > regardless of the Success or Failure from the authenticator. This is > > what allow mutual authentication to work. > > > > [BA] This seems like it would create interoperability problems, and > > potentially add some security vulnerabilities as well. > > > [JohnV] I don't see why -- can you be more specific about the problems and > vulnerabilities? Bill Arbaugh's group has written about attacks by rogue APs where the rogue can convince the peer that it has connected to a legitimate network. This occurs because the peer accepts an EAP Success in the middle of an EAP method. The solution to that was addressed in Section 4.2.1 -- potentially to drop unexpected Success/Failure messages. There is also some text relating to protected/unprotected EAP Success/Failure. However, the problem is that these indications apply only to methods, not to the EAP conversation as a whole. So the client can't just say "I'm authenticated" because it succeeded within a method -- because the EAP authentication might not be complete. However, it can say "I've failed or the authenticator has failed" and disconnect if any method fails. > > [BA] RFC 2284bis is designed to be a standalone document and should not > > depend on the state machine document. > > > [JohnV] I agree that it should be stand alone. That is why I suggested > section xxx. Some of the text for section xxx might be driven off the > state machine, and I am beginning to think the state machine would be a > good appendix. Without it there will confusion about how EAP should > actually work. The problem is that the state machine document is likely to take quite a bit longer to complete (after all, it's not even a WG work item yet) and there are hard deadlines for completion of RFC 2284bis. Pushing out RFC 2284bis is likely to cause references to it to be removed in other documents, and will also delay followon work requested by IEEE 802.11i and 3GPP. From yohba@tari.toshiba.com Wed Feb 5 06:28:27 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 5 Feb 2003 01:28:27 -0500 Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: References: <20030205021401.18642.87449.Mailman@wolverine> Message-ID: <20030205062827.GA759@catfish> On Tue, Feb 04, 2003 at 05:32:11PM -0800, Bernard Aboba wrote: > Yoshi wrote: > > > I think the policy of silently discarding packets with invalid MIC > > might not work as expected when a pass-through authenticator is used. > > > > Since the pass-through authenticator is not able to perform integrity > > check for EAP Response messages, when an attacker Peer sends an EAP > > Response with invalid MIC, the authenticator will pass it to the > > backend EAP server as long as it is valid except for MIC. Once this > > happens, an EAP Response message sent from the legitimate Peer will be > > treated as duplicate Response and thus silently discarded at the > > pass-through authenticator. > > Yes, I think this is right. > > > The policy of silently discarding packets with invalid MIC does not > > seem to work anything good for this type of DoS attack, and this > > problem seems to be common to all methods. It seems that lower-layer > > needs to be secure to EAP, or the EAP server might need to inform the > > pass-through authenticator whenever it finds an EAP Response with > > invalid MIC so that the authenticator can treat the already forwarded > > EAP Response as "invalid". > > But by then it is presumably too late, no? Actually not too late. In general, it is the responsibility of each method to perform validity check for the payload of Request/Response and to inform the switch of the result of the method-specific validity check. The switch should wait until the result of the method-specific validity check is obtained from the method. In the case of path-through authenticator, it is the "pass-through method" that performs validity check which is specific to the pass-through method. The method-specific validity check for the pass-through authenticator method would be a bit different from other methods in that it would requires the EAP server to return the validity check result from the actual method. A new EAP Request sent from the EAP server can be used as an indication that previously forwarded EAP Response was valid. However, if the EAP server silently discards the invalid EAP Response, the pass-through authenticator will be stuck until the EAP conversation times out. Based on this, the requirement is that (a) lower-layer needs to be secure to carry EAP whatever method is used, or (b) a AAA protocol needs to provide a way for the EAP server to inform the NAS whenever it finds an EAP Response invalid. If neither requirement is satisfied, it will be a broken EAP usage. The other alternative might be that (c) the EAP server shuts down the EAP conversation whenever it finds an EAP Response invalid but this is not much different from silent discard in that both ends up with EAP conversation failure, but c) might be better than silent discard since quick reaction to errornous case is possible with c). > > Do you have a recommendation? a) + c) would be perfect, but unfortunately IEEE 802.11i does not satisfy a). So I think b) might be the next choice. But I'm not sure how b) impacts on the RADIUS/Diameter EAP application protocol design. Yoshihiro Ohba From aboba@internaut.com Wed Feb 5 05:31:55 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 21:31:55 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: <20030205062827.GA759@catfish> Message-ID: > Actually not too late. In general, it is the responsibility of each > method to perform validity check for the payload of Request/Response > and to inform the switch of the result of the method-specific validity > check. The switch should wait until the result of the method-specific > validity check is obtained from the method. In the case of > path-through authenticator, it is the "pass-through method" that > performs validity check which is specific to the pass-through method. Let us assume that The NAS sends an Access-Request to the AAA server, containing an EAP Response with a bad MIC, injected by an attacker. The AAA server checks the MIC, and finds that it is bad. If it silently discards the packet, then the NAS will retransmit, thinking that the packet did not arrive. So that does not work. If the AAA servers sends an Access-Reject, then the conversation is over the authentication needs to be rerun. With one packet, the attacker gets the AAA server and client to rerun authentication, which could involve public key operations. So that is not so good either. > Based on this, the requirement is that (a) lower-layer needs to be > secure to carry EAP whatever method is used, or (b) a AAA protocol > needs to provide a way for the EAP server to inform the NAS whenever > it finds an EAP Response invalid. The question is: what good does it do for the AAA server to tell the NAS that the packet was invalid? The NAS has already silently discarded the good packet, no? > but c) might be better than silent discard since quick reaction to > errornous case is possible with c). Yes. At least the conversation will die quickly :( > So I think b) might be the next choice. But I'm not sure how b) > impacts on the RADIUS/Diameter EAP application protocol design. I guess my question is what the NAS can do with the information that would help the situation. If the NAS discards duplicate Responses before sending them to the AAA server, I think it will not do any good. If it doesn't, then the AAA server can say "that one was bad, send me another one". If the NAS doesn't have another one, I'm not sure what it can do with that information either :( From yohba@tari.toshiba.com Wed Feb 5 07:07:10 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 5 Feb 2003 02:07:10 -0500 Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: References: <20030205062827.GA759@catfish> Message-ID: <20030205070710.GA899@catfish> On Tue, Feb 04, 2003 at 09:31:55PM -0800, Bernard Aboba wrote: > The question is: what good does it do for the AAA server to tell the NAS > that the packet was invalid? The NAS has already silently discarded the > good packet, no? I think the NAS might need to queue incoming Response messages until the Response sent to the AAA server is determined to be valid by the AAA server. Yoshihiro Ohba From aboba@internaut.com Wed Feb 5 06:32:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 22:32:58 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: <20030205070710.GA899@catfish> Message-ID: > I think the NAS might need to queue incoming Response messages until > the Response sent to the AAA server is determined to be valid by the > AAA server. So you are saying that duplicate detection should be turned off when going into pass-through mode? I am curious whether any NASes implement this today. From aboba@internaut.com Wed Feb 5 07:59:37 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 4 Feb 2003 23:59:37 -0800 (PST) Subject: [eap] Re: Issue 78: More Terminology Message-ID: The language on silent discard in RFC 2284bis is unchanged from RFC 2284, Section 1.2: silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. While the SHOULD is an implementation suggestion, presumably there was a security reason for making them normative. I'd suggest that relaxing normative security recommendations is probably not a good idea -- particularly without evidence that implementations aren't following them. The term EAP server is being used to refer to either the authenticator (when no authentication server is present) or the authentication server, if present. The proposed text seems to cloud the meaning somewhat. In a system with an authentication server where the authenticator operates in pass-through, doesn't it "support EAP method exchanges"? --------------------------------------------------------------- Issue 78: More Terminology Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: Technical Priority: 1 Section: 1.2 Rationale/Explanation of issue: Item-a: EAP server description Rationale: The wording seems a bit confusing. Change: "EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server." To: "EAP server The entity that supports EAP method exchanges with the peer. This may be in the same device as the authenticator or it may be a backend authetication server." ------------------------------ Item-b: Silently discard description Rationale: Implementation suggestions should be marked as notes. Probably should not be protocol SHOULDs Change: " Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." to: " Silently Discard This means the implementation discards the packet without further processing. [Note: Good practice indicates that implementations should provide the capability of logging the event, including the contents of the silently discarded packet, and should record the event in a statistics counter." From Dan.Forsberg@nokia.com Wed Feb 5 12:15:06 2003 From: Dan.Forsberg@nokia.com (Dan.Forsberg@nokia.com) Date: Wed, 5 Feb 2003 14:15:06 +0200 Subject: [eap] preserving packet order in EAP? Message-ID: > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 23 January, 2003 21:33 > To: Forsberg Dan (NRC/Helsinki); james.d.carlson@east.sun.com > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > eap@frascone.com > Subject: Re: [eap] preserving packet order in EAP? >=20 >=20 > On 1/23/03 5:26 AM, "Dan.Forsberg@nokia.com"=20 > wrote: >=20 > > Thank you for your comments. Just a quick question. What if=20 > PANA would specify > > a "EAPv2" that wasn't backwards compatible with EAP but=20 > better suitable for > > UDP/ICMP or TCP/SCTP? This new version could carry EAP=20 > methods specified in > > the current EAP wg. For my understanding this wasn't the=20 > intention of PANA wg, > > but it would make things simpler/easier for PANA(?). Just an idea. >=20 > First we really need to understand what problems arise from=20 > carrying EAP > above IP. Re-ordering was brought up, but that can be handled by > including an identifier field in a PANA header. So I don't > see this as a requirement for a new version of EAP. Is there=20 > anything else? > Let's think... >=20 > Also let's note that if modifications to EAP are needed, PANA is not > the right WG to take over this. We need to bring it up to the EAP WG. It's not possible to make changes to EAP, because it MUST be backwards = compatible with RFC2284. That is what I've understood. So, the = playground is around the EAP methods and requirements set to them = (classification). - Dan =20 > alper >=20 >=20 >=20 > >=20 > > - Dan > >=20 > >=20 > >> -----Original Message----- > >> From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > >> Sent: 23 January, 2003 15:09 > >> To: Forsberg Dan (NRC/Helsinki) > >> Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > >> eap@frascone.com > >> Subject: RE: [eap] preserving packet order in EAP? > >>=20 > >>=20 > >> Dan.Forsberg@nokia.com writes: > >>> One possible solution for this problem is to require the > >>> Authenticatee to remember the ID numbers inside the EAP method > >>> (message id's between the initial request and Success/Failure > >>> msgs). This would imply that no EAP method should produce=20 > more than > >>> 256 requests per authentication. > >>=20 > >> That doesn't work because of rechallenge. (Well, unless you're > >> willing to drop the link when you run out of ID space for=20 > rechallenges > >> ...) > >>=20 > >>> Anyway, I think this should be fixed in the EAP protocol simply > >>> because it is standardized here in the IETF. A new issue perhaps? > >>> EAP already provides retransmission and "duplicate" > >>> detection. Making the duplicate detection work within=20 > this example, > >>> would make EAP suitable for carriers such as UDP, ICMP,=20 > and IP. This > >>> would increase the possibilities for EAP in the Internet. > >>=20 > >> EAP has no problem with retransmission or duplicates (or other bad > >> packets, for that matter). It does have a problem with reordering, > >> and that can't actually be fixed without making the "new" version > >> incompatible with the old. If you're going to make it=20 > incompatible, > >> I'd suggest starting with a blank slate. > >>=20 > >> EAP just wasn't designed to be used as you suggest. It needs an > >> order-preserving peer-to-peer link. > >>=20 > >> --=20 > >> James Carlson, Solaris Networking > >> > >> Sun Microsystems / 1 Network Drive 71.234W Vox +1 > >> 781 442 2084 > >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > >> 781 442 1677 > >>=20 > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > >=20 >=20 >=20 From james.d.carlson@east.sun.com Wed Feb 5 12:28:17 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 5 Feb 2003 07:28:17 -0500 Subject: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 5 February 2003 14:15:06 References: Message-ID: <15937.865.122299.906641@gargle.gargle.HOWL> Dan.Forsberg@nokia.com writes: > It's not possible to make changes to EAP, because it MUST be > backwards compatible with RFC2284. That is what I've understood. So, > the playground is around the EAP methods and requirements set to > them (classification). I find that assertion hard to follow. Yes, it's true that redefining the way EAP works when it runs over PPP or 802.1X would be somewhere between 'hard' and 'impossible,' but I don't see how that's necessarily true for PANA, which, as best I can tell, has no fielded implementations. If you had a different transport mechanism for non-point-to-point links, you could still carry encapsulated EAP messages and be compatible with the existing AAA infrastructure and with the defined EAP methods. The one thing you'd lose is compatibility with EAP's existing retransmission framework, and thus 2284, but since the draft authors are going to great pains to separate "method" definitions from the "EAP base," I don't see how that's a terrible loss. (None of that should be read as endorsing such a plan, since I don't agree that PANA is necessary or desirable in the face of L2 authentication technologies, but it doesn't seem right to me to say that it's not possible.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jari.arkko@piuha.net Wed Feb 5 13:52:50 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 15:52:50 +0200 Subject: [eap] Issue 76: Multiple methods in sequences References: Message-ID: <3E411732.6080301@piuha.net> >>[JohnV] We have had this discussionon the list. we agree that negotiating >>down authentication methods is a bad idea. We apparently don't agree that >>other methods should be allowed. I know that there are designs which >>expect to use eap method sequences, and prohibiting them would limit what >>can be done within the scope of the original rfc. > > > It's hard to argue that RFC 2284bis is imposing a limitation when > implementors seem to be assuming that the limitation was part of > RFC 2284. John, when you say "there are designs" -- do you mean existing implementations that use sequences for something, or planned implementations that use sequences for some new task? Do you have specific knowledge of deployment which uses sequences? I agree with Bernard in that sequences seem to bring a number of troublesome issues for us. If people seem to believe that they were forbidden in the original RFC (even if the text is unclear), it might make sense to disallow sequences. However, if the use of sequences is already widespread I wouldn't feel too good about making them illegal. > The problem is that the state machine document is likely to take quite a > bit longer to complete (after all, it's not even a WG work item yet) and > there are hard deadlines for completion of RFC 2284bis. > > Pushing out RFC 2284bis is likely to cause references to it to be removed > in other documents, and will also delay followon work requested by IEEE > 802.11i and 3GPP. This is important. We need to get 2284bis out as soon as possible. It is OK if the state machine comes out slightly later. Question: where are we now in terms of the relationship of the two documents? Are we expecting to be able to produce 2284bis without a normative reference to the state machine document? Jari From james.d.carlson@east.sun.com Wed Feb 5 14:05:23 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 5 Feb 2003 09:05:23 -0500 Subject: [eap] Issue 76: Multiple methods in sequences In-Reply-To: Jari Arkko's message of 5 February 2003 15:52:50 References: <3E411732.6080301@piuha.net> Message-ID: <15937.6691.24385.48624@gargle.gargle.HOWL> Jari Arkko writes: > I agree with Bernard in that sequences seem to bring a number of > troublesome issues for us. If people seem to believe that they were > forbidden in the original RFC (even if the text is unclear), it > might make sense to disallow sequences. However, if the use of > sequences is already widespread I wouldn't feel too good about > making them illegal. Just to clarify (or perhaps muddy the water even further): I read the text in 2284 as indicating that it was a "bad idea" to use sequences. I therefore support arbitrary sequences (including switching methods midstream) fully in the authenticatee (client) side, but provide no means of configuring any multiple authentication method sequence on the authenticator (server) side. The authenticator issues Identity (if it does not have a preconfigured peer identity), and then tries configured authentication methods until it finds one that isn't Nak'd (or gives up). Once that one agreed-on method is complete, it sends Success/Failure, and it's done. > Question: where are we now in terms of the relationship of the > two documents? Are we expecting to be able to produce 2284bis without > a normative reference to the state machine document? I would be opposed to normative references to a state machine document. That is one *possible* implementation, but I see no reason to require it as the only implementation. If published as a separate document, I'd expect a state machine description to be on Informational track, and RFC 2026 says: Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) 2284 needs to be complete on its own. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Wed Feb 5 14:32:55 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 05 Feb 2003 09:32:55 -0500 Subject: [eap] Issue 76: Multiple methods in sequences In-Reply-To: References: Message-ID: <3211866.1044437572@[10.0.1.2]> --On Tuesday, February 4, 2003 8:13 PM -0800 Bernard Aboba wrote: > > If you do not think sequences should be part of > > this then why have we been discussing them? Implementations should not > > be required to implement sequences, but they should be allowed. > > There's no language in RFC 2284 suggesting that sequences are a MUST NOT, > nor has anyone so far suggested that they be forbidden. > So this means they are ok if used properly, right? > On the other hand, we have had input from implementors that say that their > implementations would not react well to sequences, can't implement > sequences, or interpret RFC 2284 as discouraging use of sequences. > Others have not interpreted it this way. Allowing it does not require it. > Also, there have been questions about whether sequences open up new > security vulnerabilities (draft-puthenkulam-eap-binding-01.txt). > but not if the other methods are not authentication methods. > Given all of this, it's hard to make a case that RFC 2284bis can > be neutral on the subject. The suggestion from James (and others) was to > interpret the RFC 2284 admonitions as applying to sequences. Given all the > evidence, this seems like a reasonable thing to do. > I think the existing wording is way too strong and implies that sequences are not allowed. I think the same warning about multiple authentication methods can be included without implying that sequences with methods for other purposes can be included. > > [JohnV] We have had this discussionon the list. we agree that > > negotiating down authentication methods is a bad idea. We apparently > > don't agree that other methods should be allowed. I know that there > > are designs which expect to use eap method sequences, and prohibiting > > them would limit what can be done within the scope of the original rfc. > > It's hard to argue that RFC 2284bis is imposing a limitation when > implementors seem to be assuming that the limitation was part of > RFC 2284. > not all implementors > > > Note that each end of the EAP connection may independently decide > > > whether to activate the connection, and in particular the peer may > > > decide not to activate the connection based on the results of its EAP > > > methods, regardless of the Success or Failure from the authenticator. > > > This is what allow mutual authentication to work. > > > > > > [BA] This seems like it would create interoperability problems, and > > > potentially add some security vulnerabilities as well. > > > > > [JohnV] I don't see why -- can you be more specific about the problems > > and vulnerabilities? > > Bill Arbaugh's group has written about attacks by rogue APs where the > rogue can convince the peer that it has connected to a legitimate network. > This occurs because the peer accepts an EAP Success in the middle of an > EAP method. The solution to that was addressed in Section 4.2.1 -- > potentially to drop unexpected Success/Failure messages. > the language I suggest did not contradict this. > There is also some text relating to protected/unprotected EAP > Success/Failure. However, the problem is that these indications apply only > to methods, not to the EAP conversation as a whole. So the client can't > just say "I'm authenticated" because it succeeded within a method -- > because the EAP authentication might not be complete. However, it can say > "I've failed or the authenticator has failed" and disconnect if any method > fails. > yes - the language about protected/unprotected success and failure is confusing. I think we should do something about it, but I don't think it impacts the sequence issue. > > > [BA] RFC 2284bis is designed to be a standalone document and should > > > not depend on the state machine document. > > > > > [JohnV] I agree that it should be stand alone. That is why I suggested > > section xxx. Some of the text for section xxx might be driven off the > > state machine, and I am beginning to think the state machine would be a > > good appendix. Without it there will confusion about how EAP should > > actually work. > > The problem is that the state machine document is likely to take quite a > bit longer to complete (after all, it's not even a WG work item yet) and > there are hard deadlines for completion of RFC 2284bis. > Actually I think the state machine is closer to being done than the rest of the document. Nick has a new set of diagrams, and we have worked out the interactions with 802.1x. We are planning to work with 802.11 to sort that out. > Pushing out RFC 2284bis is likely to cause references to it to be removed > in other documents, and will also delay followon work requested by IEEE > 802.11i and 3GPP. > I understand. I think having a section on how retransmisssion, duplicate detection, handling of success and failure, naks, DOS would be useful and speed things up rather than slow them down. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From npetroni@cs.umd.edu Wed Feb 5 14:43:41 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Wed, 5 Feb 2003 09:43:41 -0500 (EST) Subject: [eap] state machine document In-Reply-To: <15937.6691.24385.48624@gargle.gargle.HOWL> Message-ID: [ sorry for changing the subject, but I think the previous message had two ]. I am an IETF newbie, so forgive my ignorance. I am sure the following text is not as limiting as it reads, but what are our actual options for not referencing/including the state machine in 2284bis? Since the words are "intended to be covered", does that mean it could be left out completely? This is from the EAP WG page: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. EAP state machine. 6. Documentation of interaction between EAP and other layers. 7. Resolution of interoperability issues. 8. EAP keying problem description and requirements. Items 1-7 are intended to be covered within RFC 2284bis, the revision to the EAP specification. Item 8 will be covered within a separate document On Wed, 5 Feb 2003, James Carlson wrote: > I would be opposed to normative references to a state machine > document. That is one *possible* implementation, but I see no reason > to require it as the only implementation. If published as a separate > document, I'd expect a state machine description to be on > Informational track, and RFC 2026 says: > > Note: Standards track specifications normally must not depend on > other standards track specifications which are at a lower maturity > level or on non standards track specifications other than referenced > specifications from other standards bodies. (See Section 7.) > > 2284 needs to be complete on its own. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From james.d.carlson@east.sun.com Wed Feb 5 15:07:28 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 5 Feb 2003 10:07:28 -0500 Subject: [eap] state machine document In-Reply-To: Nick Petroni's message of 5 February 2003 09:43:41 References: <15937.6691.24385.48624@gargle.gargle.HOWL> Message-ID: <15937.10416.713011.313609@gargle.gargle.HOWL> Nick Petroni writes: > [ sorry for changing the subject, but I think the previous > message had two ]. > > I am an IETF newbie, so forgive my ignorance. I am sure the following text > is not as limiting as it reads, but what are our actual options for not > referencing/including the state machine in 2284bis? So-called "informative references" (cases where the reader might want to refer to the state machine document, but is not required to) are fine. "Normative references" (cases where the reader _must_ refer to the state machine document in order to understand the material completely) are bad, assuming that the state machine document is at a lower level than the base document. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jari.arkko@piuha.net Wed Feb 5 15:22:15 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 17:22:15 +0200 Subject: [eap] Proposed Resolution of Issue 72 References: Message-ID: <3E412C27.1080106@piuha.net> Bernard Aboba wrote: > I've put my proposed responses inline with a BA: preceeding them. > > Issue 72: RFC 2869bis review > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net > Date first submitted: January 26, 2003 > Document: draft-aboba-radius-rfc2869bis-07.txt > Comment type: T > Priority: S > Section: various > Rationale/Explanation of issue: > > Comments marked with "JARI:" > > JARI: I think we need a section on what has been updated since RFC 2869. > BA: Yes. I will add this. > > 1. Introduction > > [RFC2865] describes the RADIUS Protocol as it is implemented and deployed > today, and [RFC2866] describes how Accounting can be performed with > RADIUS. > > JARI: Remove "as it is implemented and deployed today". I don't think > RFC2865 talks about implementation or deployment. > BA: Done. > > In order to provide for support of EAP within RADIUS, two new > > JARI: s/provide for support of/support/ > BA: Done. > > Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request > message to the authenticating peer. This will typically be an > EAP-Request/Identity, although an EAP-Request for an alternate EAP method > is possible. For example, a NAS might be > > JARI: s/alternate/actual authentication/? > BA: Done. > > This could be usefulin cases where the identity is determined by another > means (such as the Called-Station-Id or Calling-Station-Id), a single > authentication method is required (so that the identity is not needed to > determine the method), or where identity hiding is desired, so that the > identity is not requested until after a protected channel has been set up. > > The peer responds with an EAP-Response, which the NAS encapsulates within > EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to > the RADIUS server. For example, if an EAP-Request/Identity message is sent > by the NAS as the first packet, the peer responds with an > EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity > message within EAP-Message attribute(s), enclosed within an Access-Request > sent to the RADIUS server. > > JARI: In the above, we need a discussion of the possibility that the > NAS decides at this point to run a local method. Add: "Alternatively, the > NAS may determine from the response that it should proceed with local > authentication. Once the NAS has begun the use of RADIUS authentication > for a particular session, it no longer can perform local authentication." > > If the RADIUS server supports EAP, it MUST respond with an > Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS > server does not support EAP, it MUST respond with an Access-Reject. > BA: Done. > > JARI: Support vs. wants to do vs. wants to do for this particular user? > BA: Done. > > EAP-Message attribute(s) encapsulate a single EAP packet which the NAS > decapsulates and passes on to the authenticating peer. The conversation > continues until either a RADIUS Access-Reject or Access-Accept packet is > received from the RADIUS server. Reception of an RADIUS Access-Reject > packet MUST result in the NAS denying access to the authenticating peer. A > RADIUS Access-Accept packet successfully ends the authentication phase. > > JARI: This could my lack of knowledge in RADIUS, but what about the > simultaneous bidir authentications? What does the Access-Accept signify in > that case? Both end at that time, or can we open up a new RADIUS dialog > for the other auth? And what happens if the NAS/RADIUS doesn't even want > to authenticate the peer, but the peer insists on authenticating the > NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong > in such a case. > BA: Each authentication is handled as a separate RADIUS session, or > else things get very confusing. However, where the client is attempting to > authenticate the NAS, Accept doesn't mean "grant access" or that would > open a security loophole. Perhaps that is an argument to remove this text > altogether. It can cause trouble and I don't expect it to be implemented > widely. Everything above looks OK. Just out of curiosity: If a rogue client dials up a NAS supporting original RFC 2869 and does the following, what will happen: - Open the lower layer connection - The NAS starts EAP towards the client but it doesn't answer - Instead, it starts EAP towards the NAS (e.g. sends identity request) - The client doesn't really execute any method but sends a Success message to the NAS My question is, will the NAS/AAA respond with Access-Accept to the Success message sent by the client, even if the EAP authentication to the other direction is still ongoing. If so, will the NAS let the user in? > Using RADIUS, the NAS can act as a pass-through for an EAP conversation > between the peer and backend authentication Server, without needing to > implement the EAP method used between them. Even where the NAS initiates > the conversation by sending an EAP-Request, it is not required that the > NAS fully implement the EAP method sent in the first packet. Depending on > the method, it may be sufficient for the NAS to be configured with the > initial packet to be sent to the peer, and for the NAS to act as a > pass-through for subsequent messages. > > JARI: The above is somewhat unclear. Do you or do you not require just the > identity request to be sent by the NAS? Or do you require also a canned > first message to be sent if no id request is needed? Besides, not all > methods can have a canned first message, e.g. challenge-response... > > BA: I've rewritten this section to improve clarity. See what you think: > http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt > > In order to permit non-EAP aware RADIUS proxies to forward the > Access-Request packet, if the NAS initially sends an EAP-Request/Identity > message to the peer, the NAS MUST copy the contents of the Type-Data field > of the EAP-Response/Identity received from the peer into the User-Name > attribute and MUST include the Type-Data field of the EAP- > Response/Identity in the User-Name attribute in every subsequent > Access-Request. > > JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy > use for routing the messages to the right direction, User-Name or contents > of the EAP messages? I think the former... so its for the operation of all > proxies, right? > > BA: User-Name, because the proxies also act as pass-throughs. I've added > some text to clarify this. > > JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id > req/resp pair appearing within a tunneled method or in a sequence... (the > NAS might be able to see this message pair if it executed the first part > itself and *then* let RADIUS handle the rest. Or did we prohibit such > cases already?) > > BA: The NAS cannot see the inner method in a tunnel because it acts as a > pass-through and does not decrypt EAP messages passing through it. The use > of Reply-Message is now deprecated, in favor of EAP-Request/Notification. > > The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in > the Access-Request packet, and either NAS-Identifier or NAS-IP-Address > attributes MUST be included. In order to permit forwarding of the > Access-Reply by EAP-unaware proxies, if a User-Name attribute was included > in an Access-Request, the RADIUS server MUST include the User-Name > attribute in subsequent Access-Challenge, Access-Accept or Access-Reject > packets. Without the User-Name attribute, accounting and billing becomes > difficult to manage. If the identity is determined by another means, such > as the Calling-Station-Id, the NAS MUST include these identifying > attributes in every Access-Request, and the RADIUS server MUST copy these > identifying attributes into subsequent Access-Challenge, Access-Accept or > Access-Reject packets. > > JARI: Uh.... so identity hiding breaks roaming completely? There seems to > be two issues that we need to deal with: > > 1) How to route the request to the right place. Here it is hard for me to > see any solutions. Or perhaps hiding just the user name but not the domain > as was done in EAP SIM & AKA. But we don't have the general machinery in > EAP for that. > > 2) How to associate the accounting records with the right user? Would the > Class attribute be suitable in this situation? The records would carry the > information, but only the home network can correlate them with the actual > user. > > BA: Class attribute can be added, yes. I've added to the table of > attributes to make this clear. OK, but you may need to list this in section 2.1 where it says "identity is determined by other means". Shouldn't we also explain how Class might help here? > Having the NAS send the initial EAP-Request packet has a number of > advantages: > > JARI: [3] Allowing for local authentication for some users. > BA: Done. > > In this case, the NAS MAY also send an Access-Request packet to the RADIUS > server containing an EAP-Message attribute signifying EAP-Start. This > allows the RADIUS server to take over the task of negotiating a more > suitable method. > > JARI: Question - does the NAS include the contents of the Nak and the > request that led to it when sending this EAP-Start? > BA: I've clarified the text to indicate that it is possible to send > the Nak embedded in the initial Access-Request, to give the RADIUS server > a hint about what the peer wants to do. However, when that is done, an > EAP-Start is *not* included as well. > > 2.2. Role reversal > > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction. Both peers may act > as authenticators and authenticatees at the same time. > > Support for role reversal is optional on the RADIUS server, and requires > > JARI: Why optional? How about mandatory to implement, optional to > configure the server to actually do it? If we required mandatory support > for this, would this increase the likelihood protection against rogue > NASes? Or maybe we should require mutual auth support in EAP. > BA: I'm now leaning toward removing support for role reversal. Ok. > The RADIUS server then replies with an Access-Accept (in response to an > EAP-Success) or an Access-Reject (in response to an EAP-Failure), > containing no EAP-Message attribute. > > JARI: May need to explain how the two RADIUS dialogs are independent, i.e. > Access-Accept as a response to the above kind of Access-Request does *not* > mean the other auth is complete and the user should be let in. Also, I'm > uncertain what happens in the user is authenticated to the NAS/RADIUS > first and an Access-Accept is returned, and *then* the user initiates EAP > in another direction. Can this happen with PPP? 802.1X? > BA: I don't think I can explain it -- so it probably should be removed. > > This can be accomplished by inclusion of Session-Timeout and > Password-Retry attributes within the Access- Challenge packet. > > JARI: I don't understand Password-Retry in this context. Wouldn't it be > the RADIUS server that only is aware of an authentication failure, and > would also need to send the new Requests to make possible the use of a new > password? > BA: On reflection, neither do I. I've removed all mention of this > attribute in the text, and indicated in the attribute table that it > isn't used in EAP conversations. > > If Session-Timeout is present in an Access-Challenge packet that also > contains an EAP-Message, the value of the Session-Timeout provides the NAS > with the maximum number of seconds the NAS should wait for an EAP-Response > before retransmitting the EAP-Request. > > JARI: Please clarify whether this can be received multiple times, and what > the semantics are. E.g. first you start PEAP and timeout is 5 s, then > inside you'll be running token caard and timeout is 60 s, apparently the > NAS takes the latest received timeout value, and starts counting from the > time that it received this value from the NAS? > BA: Yes. > > As described in [RFC2284], the EAP Success and Failure packets are not > > JARI: Update refs to 2284bis? > BA: Since RFC 2869bis needs to be published right away since it is a > dependency of IEEE 802.1aa, and 802.1aa does not have a dependency on > RFC2284bis so far, adding one is probably not a good idea. > > Since the responsibility for avoiding these conflicts lies with the RADIUS > server, the NAS MUST NOT "manufacture" EAP packets in order to correct > contradictory messages that it receives. This behavior, originally > mandated within [IEEE8021X], has since been deprecated. > > JARI: So, what does it do then? MUST disconnect? > BA: The client can't tell if the NAS is manufacturing or not, so I can't > see any way to act differently. > > 2.6.2. Priority > > In addition to containing EAP-Message attributes, RADIUS messages may also > contain other attributes. In order to ensure the correct processing of > RADIUS messages, the NAS SHOULD process EAP-Message attributes last. > > JARI: We need more detail here. Say, Session-Timeout is one of these other > attributes. What does 'process' mean? Look at the EAP message contained in > the packet? Send that message to the peer and expect it to answer -- if > so, the timeout setting would be handled too late. > BA: It means send the message to the peer. > > > It is possible that the chosen Identifier value will conflict with a value > chosen by the RADIUS server for another packet within the EAP > conversation. This would violate the requirement that the Identifier be > unique within an EAP conversation. > > JARI: And after this, its still a MAY? Backwards compatibility prevents us > prohibiting it? > BA: I've made it a SHOULD NOT. > > When used within an EAP conversation, a Reply-Message attribute received > by the NAS MAY be translated to an EAP-Request/Notification sent to the > peer. As a result, a Reply-Message attribute MUST NOT be included in a > RADIUS message containing an EAP-Message attribute. An > EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT > be included within an Access-Accept or Access-Reject packet representing > the conclusion of an EAP conversation. > > JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead? > BA: I've integrated this with 2.6.3. > > Value > > The Value field is four octets, containing an integer specifying the > number of password retry attempts to permit the user. > > JARI: I must be missing something obvious again. What does the NAS do with > this information? If it is running EAP and carrying it over to the RADIUS > server, it doesn't appear to be able to tell whether the response messages > from the peer used the right password or not. Nor can it resend Requests, > there'd be Identifier conflicts, no? > BA: Good catch. I've removed mention of Password-Retry, since on > reflection it doesn't make sense to me either. > > RADIUS over IPsec, defined in [RFC3162] will eventually make this > attribute obsolete, so it should be considered an interim measure. > > JARI: When is the time to start requiring this? Or should new protocols > just start using DIameter instead? > BA: I've made it a SHOULD. > > > Vulnerabilities include: > > Separation of EAP server and authenticator > Dictionary attacks > Known plaintext attacks > Replay protection > Connection hijacking > Man in the middle attacks > Multiple databases > Negotiation attacks > > JARI: No DoS? Reading on... > BA: Do you have some text to suggest? No, one of my later comments was that I couldn't figure out any specific DoS attack on this. > For the authenticating peer, authentication policy should be set on a > per-connection basis. Per-connection policy allows an authenticating peer > to negotiate a strong EAP method when connecting to one service, while > negotiating a weaker EAP method for another service. > > JARI: Per-service or per-connection? If its per-connection, what if the > attacker causes a disconnect, then offers a weaker method? Ah, the > explanation below clarifies this. Wouldn't the right name for this be > "per-service"? > BA: Yes. Now using that term. > > An authenticating peer expecting EAP to be negotiated for a session MUST > NOT negotiate a weaker method, such CHAP or PAP. > > JARI: s/such/such as/ > BA: Done. > > wireless networks, the service advertisement itself may be spoof-able, so > that an attacker could fool the peer into negotiating an authentication > method suitable for a less secure network. > > JARI: Ouch! So, per-service isn't very helpful either unless you support > the same security level for all services. > BA: yes. > > EAP-capable authenticating peer MUST refuse to renegotiate the > authentication protocol if EAP had initially been negotiated. Note that > problems with a non-EAP capable RADIUS proxy could prove difficult to > diagnose, since a user connecting from one location (with an EAP-capable > proxy) might be able to successfully authenticate via EAP, while the same > user connecting at another location (and encountering an EAP-incapable > proxy) might be consistently disconnected. > > JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think > of any additional dos problems beyond those already present in EAP. > BA: OK. > > 5. Normative references > > JARI: I'm not sure why the above ones are normative. At least the first > one should be informative? > BA: Probably. I've taken a look at your -08 and the above responses. Everything looks good, except maybe some additional clarification for Class. Jari From aboba@internaut.com Wed Feb 5 14:18:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 06:18:49 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 72 In-Reply-To: <3E412C27.1080106@piuha.net> Message-ID: > Just out of curiosity: If a rogue client dials up a NAS supporting > original RFC 2869 and does the following, what will happen: > - Open the lower layer connection My guess is that most implementations will not send a RADIUS Request with an EAP-Start. > - The NAS starts EAP towards the client but it doesn't answer The EAP conversation will time out, and no RADIUS Access-Request will be sent. > - Instead, it starts EAP towards the NAS (e.g. sends identity request) Hmm. We would have to ask implementors what they will do. Hopefully they can handle it :) > - The client doesn't really execute any method but sends a Success > message to the NAS Hopefully this won't result in access to the NAS :) > My question is, will the NAS/AAA respond with Access-Accept to the Success > message sent by the client, even if the EAP authentication to the other > direction is still ongoing. If so, will the NAS let the user in? I certainly hope not. But we should ask implementors what they do. From jari.arkko@piuha.net Wed Feb 5 15:39:36 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 17:39:36 +0200 Subject: [eap] state machine document References: Message-ID: <3E413038.4080406@piuha.net> There appears to be two issues here: 1. Getting RFC 2284 bis published in the next few weeks or in the next IETF without waiting for the state machines to be fully approved at the same time. If we are to do this, we can't refer to normative references that aren't done yet. 2. The type of the state machine document, standards track mandatory-to-support or informational? My desire is to make no 1 above happen somehow. Perhaps we can omit any reference to the state machine or have it in the non-normative references part. Also, we can't contradict anything that will eventually be in the state machine document when its approved. Hopefully we have a good idea about that already. On no 2 above... why do you James think that it should be only an informational? Do you believe there is something that would not apply to all implementations? Or do you think that the rules in 2284 bis are sufficient and the state machine is just an illustration of them in a state machine form? Or do you think the implementations shouldn't require to implement the state machine just as described, only the results should be the same? I certainly hope we don't describe any behaviour in the state machine document that isn't followed by all implementations! Jari From aboba@internaut.com Wed Feb 5 14:33:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 06:33:26 -0800 (PST) Subject: [eap] Re: Issue 76: Multiple methods in sequence In-Reply-To: <20030205152301.32105.32937.Mailman@wolverine> Message-ID: > Just to clarify (or perhaps muddy the water even further): I read the > text in 2284 as indicating that it was a "bad idea" to use sequences. Given the text, that's not an unreasonable conclusion. > I therefore support arbitrary sequences (including switching methods > midstream) fully in the authenticatee (client) side, but provide no > means of configuring any multiple authentication method sequence on > the authenticator (server) side. "Be liberal in what you accept, conservative in what you send." > 2284 needs to be complete on its own. I agree. From aboba@internaut.com Wed Feb 5 14:37:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 06:37:27 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 72 In-Reply-To: <3E412C27.1080106@piuha.net> Message-ID: > OK, but you may need to list this in section 2.1 where it says "identity > is determined by other means". Shouldn't we also explain how Class might > help here? OK. Can you propose some text? From npetroni@cs.umd.edu Wed Feb 5 15:50:08 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Wed, 5 Feb 2003 10:50:08 -0500 (EST) Subject: [eap] state machine document In-Reply-To: <3E413038.4080406@piuha.net> Message-ID: A previous mail I sent (possibly just to eap-design) inquired about whether MUSTs only should be in the state machine, or SHOULDs as well. I assume not all implementations will do SHOULDs, so how does that play out? I believe a popular opinion at that point was to include as much of the document as possible. > only the results should be the same? I certainly hope we don't > describe any behaviour in the state machine document that isn't > followed by all implementations! > > Jari > > From aboba@internaut.com Wed Feb 5 14:44:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 06:44:52 -0800 (PST) Subject: [eap] Issue 76: Multiple methods in sequences In-Reply-To: <3211866.1044437572@[10.0.1.2]> Message-ID: > So this means they are ok if used properly, right? I think that it's more along the lines of "this is discouraged, so think carefully before you do this." But there is no prohibition. > Others have not interpreted it this way. Can you give an example of who those "others" are? Are these deployed implementations? Implementations in progress? EAP peers? Authenticators? > but not if the other methods are not authentication methods. Unless the additional methods are somehow protected by keys that are sent earlier, it would seem like a vulnerability would be created, since the additional "method" would be unprotected. And since the [RFC2548] keying attributes can only be sent in an Access-Accept, it isn't clear how existing implementations could accomplish that. > I think the existing wording is way too strong and implies that sequences > are not allowed. I think the same warning about multiple authentication > methods can be included without implying that sequences with methods for > other purposes can be included. Can you cite the text that says that sequences MUST NOT be used? This is probably more like a SHOULD NOT. From james.d.carlson@east.sun.com Wed Feb 5 15:59:51 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 5 Feb 2003 10:59:51 -0500 Subject: [eap] state machine document In-Reply-To: Jari Arkko's message of 5 February 2003 17:39:36 References: <3E413038.4080406@piuha.net> Message-ID: <15937.13559.15677.453976@gargle.gargle.HOWL> Jari Arkko writes: > On no 2 above... why do you James think that it should be only an > informational? Because it doesn't actually document the bits on the wire, but rather documents one possible way to achieve those bits. Anything that achieves the right interoperable result (including -- yecch! -- an O-O decomposition or -- double yecch! -- hard-coded message processing or -- unspeakable -- internal message passing) is acceptable. > Do you believe there is something that would not > apply to all implementations? Or do you think that the rules in > 2284 bis are sufficient and the state machine is just an illustration > of them in a state machine form? Or do you think the implementations > shouldn't require to implement the state machine just as described, > only the results should be the same? As far as IETF documents go, interoperability is all that really matters, and it's the only goal. Standards-track documents generally don't talk about how to implement the protocol, but rather only how the protocol behaves. This is the tradition -- protocols last a long time, but design methods and computing systems don't. So, yes, it's that I see no requirement that anyone actually implement the state machine as documented. As long as the implementation is interoperable and the observed behavior on the wire conforms with what other EAP implementations and RFC 2284 require, I don't see how an outside observer (lacking access to the source code) could actually "know" whether the internal implementation details included an explicit state machine or something rather different. Since there's no way to tell the difference, it seems rather vacuous to "require" that as part of an implementation. > I certainly hope we don't > describe any behaviour in the state machine document that isn't > followed by all implementations! That's exactly the point. If the state machine somehow documents something that is *NOT* documented by 2284, and that behavior is actually required for interoperability, then I think you have a problem. If the behavior of the state machine itself is the normative reference for how the protocol is supposed to behave, then I think it needs to be part of 2284, and I have a hard time seeing how they could live independently. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From yohba@tari.toshiba.com Wed Feb 5 16:00:38 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 5 Feb 2003 11:00:38 -0500 Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: References: <20030205070710.GA899@catfish> Message-ID: <20030205160038.GA769@catfish> On Tue, Feb 04, 2003 at 10:32:58PM -0800, Bernard Aboba wrote: > > I think the NAS might need to queue incoming Response messages until > > the Response sent to the AAA server is determined to be valid by the > > AAA server. > > So you are saying that duplicate detection should be turned off when going > into pass-through mode? I would say that duplicate detection might need to be delayed (not be turned off) until the validation result comes back from the AAA server. Yoshihiro Ohba From aboba@internaut.com Wed Feb 5 14:50:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 06:50:56 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: <20030205160038.GA769@catfish> Message-ID: > I would say that duplicate detection might need to be delayed (not be > turned off) until the validation result comes back from the AAA > server. I think we are going to have to hear about how authenticators currently interpret the RFC 2284 text to see if something like this is feasible or not. From jari.arkko@piuha.net Wed Feb 5 17:10:22 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 19:10:22 +0200 Subject: [eap] state machine document References: Message-ID: <3E41457E.3060700@piuha.net> Nick Petroni wrote: > A previous mail I sent (possibly just to eap-design) inquired about > whether MUSTs only should be in the state machine, or SHOULDs as well. I > assume not all implementations will do SHOULDs, so how does that play out? > I believe a popular opinion at that point was to include as much of the > document as possible. I think the right answer is that the state machine transitions should somehow indicate the "keyword strength" involved. I'm sure some are MUST, some are weaker such as SHOULD or MAY. Can you make the MUST arrows black, SHOULD arrows red, and MAY arrows green ;-) ? Jari From jari.arkko@piuha.net Wed Feb 5 17:27:00 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 19:27:00 +0200 Subject: [eap] state machine document References: <3E413038.4080406@piuha.net> <15937.13559.15677.453976@gargle.gargle.HOWL> Message-ID: <3E414964.90102@piuha.net> James Carlson wrote: > Because it doesn't actually document the bits on the wire, but rather > documents one possible way to achieve those bits. Anything that > achieves the right interoperable result (including -- yecch! -- an O-O > decomposition or -- double yecch! -- hard-coded message processing or > -- unspeakable -- internal message passing) is acceptable. First, I agree with your yecch-classification of implementation techniques ;-) But I actually think the state machine is not about the internal way to achieve bits. It may seem that way because it describes a picture which you might not exactly follow in your implementation if you used one of the yecchy techniques. However, what I think matters is the set of legal message sequences defined by the state machine. You could think of it as a the BNF description of what the protocol message sequences can be. Like an implementation of an RFC containing some BNF, we don't actually require you to use this specific technique (BNF) but we do require you to follow the language defined by it. The distinction should be made clear in the state machine draft. For instance: "All EAP implementations MUST follow the legal sequences of events defined by the state machine, regardless of whether the used implementation technique actually provides a state machine or not." > As far as IETF documents go, interoperability is all that really > matters, and it's the only goal. Standards-track documents generally > don't talk about how to implement the protocol, but rather only how > the protocol behaves. This is the tradition -- protocols last a long > time, but design methods and computing systems don't. I agree, but I see a state machine as a specification rather than an implemetnation. > So, yes, it's that I see no requirement that anyone actually implement > the state machine as documented. As long as the implementation is > interoperable and the observed behavior on the wire conforms with what Exactly. > other EAP implementations and RFC 2284 require, I don't see how an > outside observer (lacking access to the source code) could actually > "know" whether the internal implementation details included an > explicit state machine or something rather different. > > Since there's no way to tell the difference, it seems rather vacuous > to "require" that as part of an implementation. I think one could see a difference. For instance, the peer state machine doesn't allow any sequence of EAP messages to be sent. As an example, it would surely be against the state machine to send a response without receiving a request. If your implementation sends a response without me sending a request to it, I would have been able to tell that your implementation doesn't follow the RFC. Of course, this particular rule is also in 2284bis. Are all rules in 2284bis? In exactly the same form? If yes, then we may have a state machine that is used more for illustrative purposes, another representation of the *same* rules that you have to follow anyway. In that case it may not be _necessary_ to make the state machine RFC mandatory. (But this is still different from saying that we don't have to follow the state machine.) Where does all this leave us? I guess we are finding out that whatever we do, 2284bis and the state machine need to be in good sync... We do have some options as to the RFC status of the state machine document. And I think we can agree that in any case the state machines should not be viewed as implementation requirements but rather as specifications defining rules the implementations must follow. Jari From jari.arkko@piuha.net Wed Feb 5 17:54:28 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 05 Feb 2003 19:54:28 +0200 Subject: [eap] EAP State Machine Design Team conference call on 2/5/03 References: Message-ID: <3E414FD4.8080609@piuha.net> EAP State Machine Design Team conference call on 2/5/03 Date: Wednesday, February 5, 2003 Time: 8-9 AM PST Present: I got in last, but at least Bernard, Nick, Yoshihiro, John, Bob, Paul, and Jari o Peer-to-peer nature of the EAP protocol Bob: The IEEE link security group wants a peer-to-peer protocol, and isn't quite sure EAP is. Bob said it is. Bernard: It is, but there are some issues involved in running EAP both ways that Jari brought up in the context of RFC 2869bis. What happens when access-accept is given for a client-initiated EAP run, for instance? John: I think we have a terminology problem. The authenticator in a mutual authentication method is more like an initiator a la IKE than the authenticator. Bob: You could use these terms, but each system would still have both roles. Bernard: In most cases one doesn't want them to be both roles, except maybe in 802.11 ad hoc mode. Jari: There isn't complete symmetry here, identity is given only to peer not to the authenticator. Bernard: some people have been asking for this functionality. Bob: There are race conditions. In 802.1x, there can be multiple identity requests sent with different identifier counter values, so they are not detected as duplicates. The RADIUS server will get multiple requests, and this can be confusing. Bernard: Two-way authentication and 2869bis has a problem: Jari was asking too many questions and I removed the support for this as a result. John: I will take a look at the discussion to see if the two-way authentication would still be possible. o Protected successes and failures John: not too happy with this in the current document. Bernard: Question to Paul: What is the order of processing in 2869 of keys vs. attributes. Paul: The state machine, I think, makes this clear. The attributes have to be processed first before anything else is done. Bernard: RFC 2869bis and the state machine are at least in sync then. John: The protected success and failures may be a bit of a red herring. Waybe we should put something about this in the security considerations and delete the rest of the text. Bernard: this has already been done in -10, we now talk only about protected indications with EAP itself, no relation to lower layer protection etc. Bernard: Does who tells you matters? What if method tells me it failed. Should I be able to send a success? John: No. It would be better to use terms like "method signals success or failure" than the current ones. If the authenticator can tell the peer through a method that it succeeded, that would be useful. Bernard: the question is are the success and failure messages processed differently based on what happened in the method? John: yes. Bernard: we agree on this, but we need to specify how. For instance, we talked about not accepting a success before the method was done. o Peer state machine document - A preliminary state machine for the peer state machine has been posted to the design team list. A slide set describing the interfaces between 802.1x and EAP has also been posted to the same list. - Nick: In the current peer state machine, I'm not very happy with the specific names for variables. The variables need to be generalized to make the state machine more generally applicable for different environments. - Methods either do integrity checks or don't, and go back to the Idle state through different routes based on this. - Based on Yoshihiro's comments an ability has been added to resend a response if the request id is the same as the last id. - Nick: success and failure conditions are currently unclear. I'd like to enumerate all conditions when I can fail or succeed. - Bob: One comment I have: The machine starts with a link enabled signal. In the link security discussion at IEEE, there's discussion on needing authentication where there is no link signaling. John: I think this is a part of Nick's desire to have more generic names: Nick: Yes. Bob: when link comes up, you still need other mechanisms to find out who you want to authenticate with. Nick: Its like 802.11 Associate. Bob: Yes. We also have link-down-link-up events, which can cause problems if they go unnoticed. Bob: if the authentication is to an end system, you may not care about the link which doesn't matter so much. Nick: I agree that link is the wrong term here. Bob: there has to be some sort of discovery process. Nick: Yes. Maybe its something coming from the hardware. Also, if we get the signal that the other side is no longer there, we have to abort EAP. John: there should be two signals, a reset and a "start authentication" signal. Nick: Link enabled could become something like "channel enabled" and this would have to stay true all the time, otherwise we abort. A single variable like this works well, as long as we have the "channel" structure. For reauthentication we may need another variable, because you want to stay port open while working through reauthentication. That still leaves the question of which state to go in that case. Maybe you should remain in the success state. - Question: does the method signal the success/failure result? Nick: that's the method state variable. - Question: does the method control policy or the policy the method? Bob: We have been talking about a sequence of method. You could imagine a policy which is more of a decision tree of a method. Yoshiri: yes, and I think that is needed. It should be possible to allow one method only once, for instance. I suggest adding an update policy call in the peer state machine outside the method exchange. - Comment: I'm unclear how to go back to dialog if i discard a message through mic. Oh I see, there's a retransmission and through this i get to dialog. Bernard: its a problem, because the authenticator would just retransmit the same bad message. John: this is for an injected message on the path. bernard: Yes, for that it would work. It would be good to document what we can do with DoS. All: Agreed. Bernard: it is important to avoid rogue successes. Other stuff is hard to protect against, for instance diassociate link message can be easily spoofed and that would disable the link. Bernard: the mic check on the authenticator in passthrough mode isn't doaable, as Yoshihiro noted. Given that the NAS would also be eliminating duplicates, this is a dos attack. Yoshihiro: I think we should just delay the duplicate elimination until the AAA server incidcates whether the packet was correct or not. Bernard: Today it would send back an access-reject. Unless duplicate detection is turned off or delayed we can't do more. John: We could provide a RADIUS message that says "I didn't like this, give me another one if you have". Bernard: the problem is that this would be a massive change. And this isn't backwards compatible. John: before we decide this we should design it first so that we can see if this would happen. Certainly for the way its presented now it would not work. Bernard: there are limitations what we can do because we have deployed protocol implementations to the field already. Jari: It would have been better if passthrough NASes didn't do duplicate detection and left it to AAA. Bernard: Yes. John: Not sure if we couldn't still do it? - Nick: Do we agree that the only time you can get success is at the end of a method? Bernard: yes. John: No. I think it can go to success if its satisfied with its policy and it gets a timeout. If the other end failed the link won't be up. Both ends have to enable it. I'm willing to go along with the above, however, if we have a real discussion about this and people agree. Bernard: this is about the 2284 text on alternative indications. John: Generally, this indication is that "the link worked". Bernard: The problem is that you can spoof link up messages. From yohba@tari.toshiba.com Wed Feb 5 18:04:10 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 5 Feb 2003 13:04:10 -0500 Subject: [eap] Issue 76: Multiple methods in sequences In-Reply-To: <3E411732.6080301@piuha.net> References: <3E411732.6080301@piuha.net> Message-ID: <20030205180410.GA6519@catfish> On Wed, Feb 05, 2003 at 03:52:50PM +0200, Jari Arkko wrote: > > >>[JohnV] We have had this discussionon the list. we agree that negotiating > >>down authentication methods is a bad idea. We apparently don't agree that > >>other methods should be allowed. I know that there are designs which > >>expect to use eap method sequences, and prohibiting them would limit what > >>can be done within the scope of the original rfc. > > > > > >It's hard to argue that RFC 2284bis is imposing a limitation when > >implementors seem to be assuming that the limitation was part of > >RFC 2284. > > John, when you say "there are designs" -- do you mean existing > implementations > that use sequences for something, or planned implementations that use > sequences > for some new task? Do you have specific knowledge of deployment which > uses sequences? > Actually, there is a DSL scenario in PANA that might use sequences, in which one method is used for NAP (network access provider) to authenticate the client, and the other method is used for ISP to authenticate the client. The client would use different identities for each method. By this way, the NAP can provide NAP-specific network access services independent of what the ISP provides. (Note that the assumption is both NAP and ISP shares the same NAS for authenticating the client.) To be fair, it is also possible to run multiple set of EAP conversations in a single PANA conversation, where each EAP conversation contains one authentication method (besides Identity). Yoshihiro Ohba From yohba@tari.toshiba.com Thu Feb 6 01:27:03 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 5 Feb 2003 20:27:03 -0500 Subject: [eap] Issue 74: Concern on invalid MIC In-Reply-To: References: Message-ID: <20030206012703.GJ754@catfish> The suggested text works fine for me. Thanks, Yoshihiro Ohba On Tue, Feb 04, 2003 at 04:34:08PM -0800, Bernard Aboba wrote: > I agree with James that it is best if the MIC applies to individual > datagrams, but there are situations in which this is not possible. For > example, unlike GSS-API, in EAP a key is not assumed available until it is > derived later in the conversation. This means that the Identity and Nak > messages cannot be authenticated when they are sent -- because the > method hasn't run yet, there is no key with which to authenticate > them. > > However, as we've discussed, it is possible to authenticate the > uncovered part of the conversation by including those packets in a MIC > sent later on, after keys have been derived. > > How about this suggested text? > > " If a per-packet Message Integrity Check (MIC) is employed within an EAP > method, then implementations MUST silently discard any message that > fails this check. In this document, the descriptions of EAP message > handling assume that per-packet MIC validation is effectively performed > as though it occurs before examining any of the EAP message fields > (such as 'Code'). > > Some EAP methods may define MICs that cover more than one EAP packet. > Since the Identity Request/Response, Nak Response or Notification > Request/Response messages are not authenticated, once an EAP method > derives keys it may be desirable to exchange MICs that cover these > unauthenticated packets, so as to be able to detect forgeries after > the fact. Alternatively, an EAP method may define a MIC covering an > extended PDU that could be split into multiple fragments. > > In these situations, failure of MIC validation is typically a fatal > error, since it may not be possible to recover the original state and > continue the exchange. It should be understood that this increases > vulnerability to denial of service attacks." > > ----------------------------------------------------------------------- > Issue 74: Concern on invalid MIC > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date first submitted: Feburary 3, 2003 > Document: RFC2284bis-10 > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > Section 4.1 says: > " If a Message Integrity Check (MIC) is employed within an EAP method, > then implementations MUST silently discard any message that fails > this check. In this document, the descriptions of EAP message > handling assume that MIC validation is effectively performed as > though it occurs before examining any of the EAP message fields (such > as 'Code')." > > I'm sorry for discussing this issue again, but I am still not sure > whether mandating silent discard of packets with invalid MIC is always > good. > > For example, EAP-TLS and PEAP haves its own fragmentation mechanism > outside the TLS, in which each fragment is carried in a single EAP > Request/Response packet. In this case, since TLS MIC validation > cannot be performed before reassembling the fragmented packets, so an > attacker Authenticator can send a fragment with broken MIC. The > packet will be accepted by the Peer as long as it is valid except for > MIC, and EAP Requests sent by legitimate Authenticator after the > attacker's attempt may be treated just as a deplicate Request. > Finally, when all fragments are received by the Peer, the Peer > reassembles a TLS record and will find invalid in terms of MIC. > > If this is a possible situation, how silently discarding the packet > with invalid MIC can improve robustness againt the DoS attack of > blindly injecting fragments? > > Yoshihiro Ohba > Comment from James Carlson: > It sounds like breakage in the EAP-TLS and PEAP fragmentation > mechanisms, rather than a problem with EAP itself. > > > If this is a possible situation, how silently discarding the packet > > with invalid MIC can improve robustness againt the DoS attack of > > blindly injecting fragments? > > If you're not doing a MIC per message, then it's hard for me to see > what the value of the thing called a "MIC" might be. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From alper@docomolabs-usa.com Thu Feb 6 01:42:03 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 05 Feb 2003 17:42:03 -0800 Subject: [eap] preserving packet order in EAP? In-Reply-To: <15937.865.122299.906641@gargle.gargle.HOWL> Message-ID: > (None of that should be read as endorsing such a plan, since I don't > agree that PANA is necessary or desirable in the face of L2 > authentication technologies, but it doesn't seem right to me to say > that it's not possible.) Not all networks are running IEEE 802 links, and not all (if any) other link technologies are supporting EAP. And inserting PPP in the stack just for the sake of carrying EAP is not the best idea obviously. Or developing other ad-hoc solutions. PANA usage scenarios draft is where this is covered, and its updated version will be available soon. alper From aboba@internaut.com Thu Feb 6 05:41:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Feb 2003 21:41:52 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 74 In-Reply-To: <20030206012703.GJ754@catfish> Message-ID: Actually, I think we need to say something about the issues you raised in passthrough mode. How about this? "If a per-packet Message Integrity Check (MIC) is employed within an EAP method, then peers and authenticators not operating in pass-through mode MUST silently discard any message that fails this check. Since authenticators operating in pass-through mode do not check method-specific MICs, this requirement does not apply to them. In this document, the descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code'). Some EAP methods may define MICs that cover more than one EAP packet. Since the Identity Request/Response, Nak Response or Notification Request/Response messages are not authenticated, once an EAP method derives keys it may be desirable to exchange MICs that cover these unauthenticated packets, so as to be able to detect forgeries after the fact. Alternatively, an EAP method may define a MIC covering an extended PDU that could be split into multiple fragments. In these situations, failure of MIC validation is typically a fatal error, since it may not be possible to recover the original state and continue the exchange. It should be understood that this increases vulnerability to denial of service attacks." From Pasi.Eronen@nokia.com Thu Feb 6 08:26:33 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 6 Feb 2003 10:26:33 +0200 Subject: [eap] Re: Proposed Resolution of Issue 74 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA1A@esebe023.ntc.nokia.com> On 6 Feb 2003, Bernard Aboba wrote: > Some EAP methods may define MICs that cover more than one EAP packet. > Since the Identity Request/Response, Nak Response or Notification > Request/Response messages are not authenticated, once an EAP method > derives keys it may be desirable to exchange MICs that cover these > unauthenticated packets, so as to be able to detect forgeries after > the fact. Alternatively, an EAP method may define a MIC covering an > extended PDU that could be split into multiple fragments. >=20 > In these situations, failure of MIC validation is typically a fatal > error, since it may not be possible to recover the original state and > continue the exchange. It should be understood that this increases > vulnerability to denial of service attacks." Is this a a protocol issue or an implementation issue? It is=20 possible to imagine an implementation which would work much like a=20 "non-deterministic state machine" in this case. Consider an example where an attacker and the legitimate peer both send EAP packet with identifier N, and we can't yet validate the MIC (so we can't know which is the correct one).=20 I guess that most implementations simply pick the packet which arrived=20 first, but an alternative would be to "fork" the state: if before receiving either of the packes we were in state S0, and receiving the packets would take us to states S1 and S2, we could consider this a state set {S1,S2}. Then a conversation would be successful if the final state set contains a successful state. I admit that I'm not really sure if such an implementation would make sense, but then, you get these strange ideas when you haven't had your morning coffee yet :-) And, of course,=20 storing all those states also takes up memory, which could lead to a different kind of DoS attack. Best regards, Pasi From jari.arkko@piuha.net Thu Feb 6 09:20:17 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 06 Feb 2003 11:20:17 +0200 Subject: [eap] Proposed Resolution of Issue 72 References: Message-ID: <3E4228D1.1040804@piuha.net> Bernard Aboba wrote: >>OK, but you may need to list this in section 2.1 where it says "identity >>is determined by other means". Shouldn't we also explain how Class might >>help here? > > > OK. Can you propose some text? Well here's one suggestion. This is intended to be appended to the 2.1 paragraph that begins with "The NAS-Port or NAS-Port-Id attributes SHOULD ...": None of these attributes may be present where identity hiding is desired. It is generally not possible to hide the full NAI if proxies with User-Name based routing are used. In some networks all the attributes can be hidden, however. If the User-Name attribute is not present in the Access-Request packet, the RADIUS server SHOULD include a Class attribute in the Access-Challenge, Access-Accept, and Access-Reject packets. According to the rules in [RFC2865] the contents of this attribute are copied unmodified to Accounting-Request packets. This allows the RADIUS server to provide information that enables it to correlate the accounting records with the particular user that was authenticated. If the Class attribute is used, its contents MUST be encrypted to hide the identity of the user from those not in the possession of a local secret known to the RADIUS authentication and accounting servers. Similarly, if the Access-Request packet did not include a User-Name attribute, the RADIUS server MUST NOT add a User-Name attribute to the Access-Challenge, Access-Accept, or Access-Reject packets even if it knows the identity of the user. Jari From Pasi.Eronen@nokia.com Thu Feb 6 13:00:25 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 6 Feb 2003 15:00:25 +0200 Subject: [eap] Comments about draft-aboba-pppext-key-problem-05 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122237@esebe023.ntc.nokia.com> Comments about draft-aboba-pppext-key-problem-05 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 6 Feb 2003 Document: draft-aboba-pppext-key-problem-05 Comment type: Technical and editorial Priority: 1 (should be fixed) Section: various Rationale/Explanation of issue: PASI: Document looks reasonably good, and most of these issues are simply editorial. Some technical clarifications or questions are included as well. -- Section: 1.2 Comment type: Editorial > Authentication Server > An Authentication Server is an entity that provides an > Authentication Service to a Network Access Server (NAS). This > service verifies from the credentials provided by the Client, the > claim of identity made by the Client. Where an Authentication > Server is provided, it acts as the EAP Server, terminating EAP > conversation with the EAP Client. In the EAP Keying architecture > the Authentication Server acts as a KDC, distributing the Master > Session Keys (MSKs) to the EAP Client and NAS. PASI: Proposed change: "In the EAP Keying architecture the = Authentication Server acts as a KDC, distributing the Master Session Keys (MSKs)=20 to the NAS (using AN-Token), and in some EAP methods, also to the EAP Client (using CS-Token)." -- Section: 1.2 Comment type: Technical > Cryptographic binding > The demonstration of the EAP Client to the EAP Server that a = single > entity has acted as the EAP Client for all methods executed within > a sequence or tunnel. Binding MAY also imply that the EAP Server > demonstrates to the Client 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. PASI: Proposed change: add "If tunneling is used, the binding MUST/SHOULD also demonstrate that the same entity has acted as the tunnel endpoint and EAP Client" after the first sentence, and=20 "(and if applicable also as the tunnel endpoint)" after the next sentence. (Valtteri Niemi et al. paper) -- Section: 1.2 Comment type: Editorial > Pairwise Master Key (PMK) > As defined in [RFC2716], the MSK is 192 octets (1536 bits) in > length. Octets 0-31 of the MSK are known as the "Peer to > ... PASI: I think this text only confuses here. Perhaps it could be included in Appendix B, if necessary. Proposed change: Delete. -- Section: 2.1 Comment type: Editorial > Similarly, because the NAS is not required to implement any EAP = methods, > the NAS cannot be assumed to implement code specific to any EAP = method. > Since operating systems provide EAP APIs in order to remain = "EAP-Method > Agnostic", EAP APIs cannot be assumed to implement EAP method-specific > code either. PASI: Operating system EAP APIs are an implementation issue; the EAP methods could be part of the NAS software instead of a separate module. Also, the document is already quite convincing about why cipher suite independence is a good idea. =20 Proposed change: Delete the last sentence. -- Section: 2.1 Comment type: Editorial > EAP methods deriving keys MUST support mutual authentication and = provide > for the derivation of an EAP Master Key (EMK), known only to the EAP > Client and Server. EAP methods deriving keys also MUST provide for the > distribution of the CS-Token between the AAA Server and EAP Client, = and > the AN-Token between the AAA server and NAS. The MSK contained within > the CS-Token and AN-Tokens is suitable for use with any negotiated > ciphersuite, and therefore an EAP method MUST NOT directly use the MSK > as a Transient Session Key (TSK). Rather, the TSK(s) are derived from > the MSK in a separate step, once the negotiated ciphersuite is known. PASI: This text duplicates information contained later, and I don't think most of it really belongs to the "cipher suite independence" = section. Proposed change: Replace with "The MSK is suitable for use with any negotiated ciphersuite, and therefore an EAP method MUST NOT directly use the MSK as a Transient Session Key (TSK). Rather, the TSK(s) are derived from the MSK in a separate step, once the negotiated ciphersuite is known." -- Section: 3 Comment type: Editorial > [a] Two-party exchange. The two-party exchange occurs where the EAP > Client and NAS act as the endpoints of the EAP conversation, and = no > Authentication Server is present. Here the NAS implements the EAP > method locally, rather than acting as a pass-through. In this = mode, > the EAP method used between the EAP Client and NAS (EAP Server) > derives the EMK, as well as providing for the distribution of the > Client-Server token containing the MSK. > > [b] Three-party exchange. This mode is used where the NAS acts as a > pass-through and an Authentication Server (acting as an EAP = Server) > is present. In this mode, the EAP Server and Client derive the = EMK, > and the Authentication Server distributes to the CS-Token to the > EAP Client and the AN-Token to the NAS. Both the CS-Token and AN- > Token contain the embedded MSK. PASI: I think this should be rephrased a little, since earlier the document says that most EAP methods don't actually use CS-Token, but derive the MSK using the EMK key. Proposed change: Replace last sentence of [a] with "In this mode, the EAP method used between the EAP Client and NAS (EAP Server) derives the EMK, and if the MSK is not derived from the EMK, provides for the distribution of the CS-Token containing the MSK", and in [b] "In this mode, the EAP Server and Client derive the EMK, and the=20 Authentication Server distributes the AN-Token to the NAS, and if the MSK is not derived from the EMK, the CS-Token=20 to the EAP Client". -- Section: 3.1 Comment type: Editorial > If the authentication occurs with a method not implemented on the NAS, > or involves a non-local user whose credentials the Server is unable to > validate, then the NAS functions as a "pass-through". For = pass-through > authentication methods, instead of implementing the authentication > method locally, the NAS delegates the authentication to an > Authentication Server. The Authentication Server installs the desired > EAP method, typically by interfacing with the operating system via an > EAP API, such as that described in [EAPAPI]. PASI: Proposed change: delete last sentence. -- Section: 3.2 Comment type: Editorial and technical > [c] TSK derivation. During this phase, the EAP Client and NAS confirm > mutual possession of the MSK, and derive the Transient Session = Keys > used in the negotiated ciphersuite. TSK derivation occurs out of > band of EAP; an example is the 4-way handshake provided in IEEE > 802.11 RSN. PASI: Proposed change: Add Section 3.3 for discussion of the TSK derivation step, so we don't have to duplicate it in 3.1 and 3.2. Move text from 3.2 (paragraphs starting with "During the (optional) TSK derivation step" and "If the TSK derivation does not"...) there. Some of this text could be in 4.4 as well (as requirements for TSK derivation step). This also needs some clarification, since proving possession of=20 the MSK can be implicit (by proving possession of TSKs).=20 -- Section: 3.2 Comment type: Technical=20 > If the TSK derivation does not support mutual authentication, then the > EAP Client will not have assurance that it is connected to the right > NAS, only that the NAS and AAA server share a trust relationship > (assuming that the AAA protocol supports mutual authentication). This > distinction can become important when multiple NASes receive MSKs from > the Authentication Server, as may be the case where fast handoff is > supported. If the TSK derivation does not provide for protected > ciphersuite negotiation, then downgrade attacks are possible. PASI: I think the "mutual authentication" part should be clarified. The TSK proof of possession and protection of the negotiated cipher suite must include some connection-specific information (such as addresses) to ensure that the client is connected to the right NAS. -- Section: 3.3 Comment type: Technical > In order to protect against compromise of the EMK, the EMK MUST NOT > be directly used to protect data; rather the TEKs derived from the > EMK are used for this purpose. Examples of the EMK branch of the > key hierarchy are given in Appendix A. PASI: What properties are required of the EMK->TEK derivation? Does it have to be cryptographically one-way? (see also next comment abount MSK branch) -- Section: 3.3 Comment type: Technical > [b] Master Session Key (MSK) branch. The MSK is (optionally) > distributed by the Authentication Server to the EAP Client within > the CS-Token (or alternatively, derived from the EMK). It is > transported from the Authentication Server to the NAS within the > AN-Token. Since the MSK is not ciphersuite-specific, it is larger > than necessary, and is truncated to fit as part of the Transient > Session Key (TSK) derivation process. As with the EMK, the MSK = MUST > NOT be directly used to protect data; rather TSKs derived from the > MSK are used for this purpose. Examples of the MSK hierarchy are > given in Appendix B. PASI: Truncation might not be the only possible option for TSK derivation, especially if some strange ciphersuite would require more than MSKs length of keys. Also, if the TSK would be exactly the same length as MSK (unlikely, but possible in theory) using TSK=3DMSK could be allowed (so the MSK->TSK derivation can be simple splitting, and it does not have to be cryptographically one-way, right?) -- Section: 4.1 Comment type: Editorial > The security of the three-party exchange is highly dependent on the > security properties of the each of the protocols. For example, if > mutual authentication is not completed between the EAP Client and > Authentication server, then the Client will be vulnerable to rogue > Authentication Servers and NASes. If the EMK is not derived between = the > Client and Authentication Server, then there will be no binding = between > the authentication and subsequent data traffic, leaving the session > vulnerable to hijack. PASI: Proposed change: "If the subsequent data traffic is not protected using TSKs derived from the MSK (which is either derived from EMK, or sent in a CS-Token protected by EMK), then there=20 will be..." -- Section: 4.2 Comment type: Technical and editorial > EMK hierarchy > Methods deriving keys MUST support mutual authentication and > derivation of the EMK, as well as specifying how TEKs are derived > from the EMK. The EMK MUST NOT be used to directly protect data. PASI: There might be cases where it is difficult for an attacker to masquerade as the NAS, but passive eavesdropping is still a problem. In this kind of environment, mutual authentication is not absolutely required, so I think it should say "SHOULD" instead of "MUST". Proposed change 1: Add "Mutual Authentication: Methods deriving keys = SHOULD support mutual authentication to protect against rogue Authentication Servers and NASes".=20 Proposed change 2: Replace text with "EMK hierarchy: Methods deriving keys MUST support derivation of the EMK, as well as specifying how TEKs are derived from the EMK. The EMK SHOULD NOT be used to directly protect data. If multiple TEKs are used, they SHOULD be = cryptographically=20 separate from each other." Is a SHOULD enough here? Depending on what algorithms are used in a particular method, this might not be absolutely necessary (although using cryptographically separate TEKs would certainly be a good idea, as a generic design advice). -- Section: 4.2 Comment type: Editorial > CS-Token specification > Methods supporting key derivation MUST specify the format of the > CS-Token containing the MSK. If no explicit CS-Token format is > used, then the formulas for derivation of the MSK MUST be = provided. PASI: Proposed change: "CS-Token specification / MSK derivation: Methods supporting key derivation MUST specify either the format of the CS-Token containing the MSK (if a CS-Token is used), or the formulas for derivation of the MSK from other information (e.g. EMK)." -- Section: 4.2 Comment type: Editorial > Ciphersuite Independence > The MSK derivation SHOULD be ciphersuite-independent and the EAP > method SHOULD NOT assume knowledge of the ciphersuite. PASI: Proposed change: "The MSK derivation SHOULD be independent of the ciphersuite used later to protect data traffic, and the EAP method SHOULD NOT assume knowledge of this ciphersuite". -- Section: 4.4 Comment type: Editorial > TEK derivation > In order to establish a protected channel between the EAP Client > and Server as part of the EAP exchange, a ciphersuite needs to be > negotiated and keyed, using TEKs derived from the EMK. The > ciphersuite used to protect the EAP exchange is distinct from the > ciphersuite negotiated between the EAP client and NAS, used to > protect data. Where a protected channel is established within the > EAP method, the method specification MUST specify the mechanism by > which the EAP ciphersuite is negotiated, as well as the algorithms > for derivation of TEKs from the EMK during the EAP authentication > exchange. PASI: This is a requirement for an EAP method, so if it's needed, it should be in Section 4.2 instead of here. However, 4.2 already says that the method must specify how TEKs are derived, and any ciphersuite negotiation is a method-internal issue (e.g., it could use a fixed cipher suite without any negotiation). Proposed change: Delete. -- Section: 4.4 Comment type: Editorial > EAP method independence > Algorithms for deriving TSKs from the MSK MUST NOT depend on the > EAP method. However, algorithms for deriving TEKs from the EMK MAY > be specific to the EAP method. PASI: Even how many TEKs are needed, and how long they should be, is quite specific to the EAP method. This is also clear from previous text. Proposed change: delete last sentence. -- Section: 4.4 Comment type: Editorial and technical > Cryptographic separation > The TSKs derived from the MSK MUST be cryptographically separate > from each other. Similarly, TEKs MUST be cryptographically = separate > from each other. In addition, the TSKs MUST be cryptographically > separate from the TEKs. PASI: TEK separation really belongs to Section 4.2. Assuring that TSKs and TEKs are cryptographically separate requires some=20 clarification, since TEKs are derived in a method-specific way, while MSK->TSK derivation should be method-independent. In most cases it would be enough that MSK can't be derived from TEKs (it might not harm most EAP methods if TEKs can be derived from MSK/TSK). If we want to require bidirectional separation, I propose we add "MSK must be cryptographically separate from TEKs" to Section 4.2, "CS-Token specification...". Best regards, Pasi From yohba@tari.toshiba.com Thu Feb 6 16:28:11 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 6 Feb 2003 11:28:11 -0500 Subject: [eap] Re: Proposed Resolution of Issue 74 In-Reply-To: References: <20030206012703.GJ754@catfish> Message-ID: <20030206162811.GA749@catfish> On Wed, Feb 05, 2003 at 09:41:52PM -0800, Bernard Aboba wrote: > Actually, I think we need to say something about the issues you raised in > passthrough mode. How about this? > > "If a per-packet Message Integrity Check (MIC) is employed within an EAP > method, then peers and authenticators not operating in pass-through > mode MUST silently discard any message that fails this check. Since > authenticators operating in pass-through mode do not check > method-specific MICs, this requirement does not apply to them. I think we can describe without necessarily using the term "passthrough". And I also come to think that it is not necessary to turn-off or delay duplicate Response detection. How about the following text? "The authenticator MUST NOT send a new Request until a valid Response is received to an outstanding Request. Since the authenticator can retransmit before receiving a valid Response from the peer, the authenticator can receive duplicate Responses. The authenticator MUST silently discard these duplicate Responses. Note that authenticators which delegate the task of method-specific validity check to other entities (e.g., EAP servers) are assumed to be able to obtain the validity check result from the delegated entities. If a per-packet Message Integrity Check (MIC) is employed within an EAP method, then peers and authenticators MUST silently discard any message that fails this check." (continued to the following text) > > In this document, the descriptions of EAP message handling assume that > per-packet MIC validation, where it occurs, is effectively performed > as though it occurs before examining any of the EAP message fields > (such as 'Code'). > > Some EAP methods may define MICs that cover more than one EAP packet. > Since the Identity Request/Response, Nak Response or Notification > Request/Response messages are not authenticated, once an EAP method > derives keys it may be desirable to exchange MICs that cover these > unauthenticated packets, so as to be able to detect forgeries after > the fact. Alternatively, an EAP method may define a MIC covering an > extended PDU that could be split into multiple fragments. > > In these situations, failure of MIC validation is typically a fatal > error, since it may not be possible to recover the original state and > continue the exchange. It should be understood that this increases > vulnerability to denial of service attacks." > Yoshihiro Ohba From aboba@internaut.com Fri Feb 7 14:59:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Feb 2003 06:59:42 -0800 (PST) Subject: [eap] Re: Proposed Resolution of Issue 74 In-Reply-To: <20030206180002.24789.1538.Mailman@wolverine> Message-ID: > > "If a per-packet Message Integrity Check (MIC) is employed within an EAP > > method, then peers and authenticators not operating in pass-through > > mode MUST silently discard any message that fails this check. Since > > authenticators operating in pass-through mode do not check > > method-specific MICs, this requirement does not apply to them. > > I think we can describe without necessarily using the term > "passthrough". And I also come to think that it is not necessary to > turn-off or delay duplicate Response detection. How about the following > text? > > "The authenticator MUST NOT send a new Request until a valid Response > is received to an outstanding Request. Since the authenticator can > retransmit before receiving a valid Response from the peer, the > authenticator can receive duplicate Responses. The authenticator > MUST silently discard these duplicate Responses. Note that > authenticators which delegate the task of method-specific > validity check to other entities (e.g., EAP servers) are assumed to > be able to obtain the validity check result from the delegated > entities. I guess I don't understand how this is supposed to work. If the authenticator doesn't turn off duplicate Response detection, then what good is it for the AAA server to indicate that the Request was invalid? The NAS will have already thrown away the other Requests in the queue, so it won't be able to do anything about it. > > In this document, the descriptions of EAP message handling assume that > > per-packet MIC validation, where it occurs, is effectively performed > > as though it occurs before examining any of the EAP message fields > > (such as 'Code'). > > > > Some EAP methods may define MICs that cover more than one EAP packet. > > Since the Identity Request/Response, Nak Response or Notification > > Request/Response messages are not authenticated, once an EAP method > > derives keys it may be desirable to exchange MICs that cover these > > unauthenticated packets, so as to be able to detect forgeries after > > the fact. Alternatively, an EAP method may define a MIC covering an > > extended PDU that could be split into multiple fragments. > > > > In these situations, failure of MIC validation is typically a fatal > > error, since it may not be possible to recover the original state and > > continue the exchange. It should be understood that this increases > > vulnerability to denial of service attacks." > > > > Yoshihiro Ohba > > > --__--__-- > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > > End of eap Digest > From aboba@internaut.com Fri Feb 7 15:13:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Feb 2003 07:13:30 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 72 In-Reply-To: <3E4228D1.1040804@piuha.net> Message-ID: > Well here's one suggestion. This is intended to be appended to the > 2.1 paragraph that begins with "The NAS-Port or NAS-Port-Id > attributes SHOULD ...": > > None of these attributes may be present where identity hiding > is desired. Here's what RFC 2865, Section 4.1 says: An Access-Request SHOULD contain a User-Name attribute. It MUST contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both). So I think that this would be a violation of RFC 2865, no? > It is generally not possible to hide the full NAI > if proxies with User-Name based routing are used. In some > networks all the attributes can be hidden, however. How are they hidden? Using the MD5 encryption construction in RFC 2865? By some other means? > If the User-Name > attribute is not present in the Access-Request packet, the > RADIUS server SHOULD include a Class attribute in the Access-Challenge, > Access-Accept, and Access-Reject packets. The Class attribute is forbidden in Request, Reject and Challenge packets in RFC 2865, so we will need to figure out another way to do this. Here's what RFC 2865, Section 5.1 says: This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. If the Access- Accept includes Service-Type = Rlogin and the User-Name attribute, a NAS MAY use the returned User-Name when performing the Rlogin function. Would it be possible to return the desired identifier within the User-Name attribute in the Access-Accept? I think that would accomplish what you want. > According to the rules > in [RFC2865] the contents of this attribute are copied unmodified > to Accounting-Request packets. This allows the RADIUS server to > provide information that enables it to correlate the accounting > records with the particular user that was authenticated. If the > Class attribute is used, its contents MUST be encrypted to > hide the identity of the user from those not in the possession > of a local secret known to the RADIUS authentication and > accounting servers. The original specification for the Class attribute does not include any mention of message hiding. So I don't think that we can introduce that in RFC 2869bis. We could of course define a new attribute -- or since IPsec usage is now a SHOULD, we could assume IPsec protection and not worry about it. > Similarly, if the Access-Request packet > did not include a User-Name attribute, the RADIUS server MUST > NOT add a User-Name attribute to the Access-Challenge, Access-Accept, > or Access-Reject packets even if it knows the identity of the user. In RFC 2865, User-Name is a MUST NOT in the Reject and Challenge. From yohba@tari.toshiba.com Fri Feb 7 16:43:37 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 7 Feb 2003 11:43:37 -0500 Subject: [eap] Re: Proposed Resolution of Issue 74 In-Reply-To: References: <20030206180002.24789.1538.Mailman@wolverine> Message-ID: <20030207164337.GG1215@catfish> On Fri, Feb 07, 2003 at 06:59:42AM -0800, Bernard Aboba wrote: > > > "If a per-packet Message Integrity Check (MIC) is employed within an EAP > > > method, then peers and authenticators not operating in pass-through > > > mode MUST silently discard any message that fails this check. Since > > > authenticators operating in pass-through mode do not check > > > method-specific MICs, this requirement does not apply to them. > > > > I think we can describe without necessarily using the term > > "passthrough". And I also come to think that it is not necessary to > > turn-off or delay duplicate Response detection. How about the following > > text? > > > > "The authenticator MUST NOT send a new Request until a valid Response > > is received to an outstanding Request. Since the authenticator can > > retransmit before receiving a valid Response from the peer, the > > authenticator can receive duplicate Responses. The authenticator > > MUST silently discard these duplicate Responses. Note that > > authenticators which delegate the task of method-specific > > validity check to other entities (e.g., EAP servers) are assumed to > > be able to obtain the validity check result from the delegated > > entities. > > I guess I don't understand how this is supposed to work. If the > authenticator doesn't turn off duplicate Response detection, then what > good is it for the AAA server to indicate that the Request was invalid? > The NAS will have already thrown away the other Requests in the queue, so > it won't be able to do anything about it. Regarding the words "outstanding Request", I assume that the authenticator keeps a copy of the Request. The Request is "outstanding" and retransmission and duplicate detection could be performed in parallel to validity check until a Response turns out to be valid. The same thing would apply to the case the delegated entitity is physically co-located on the same device as the authenticator (e.g., an "EAP server" process or thread separated from "EAP authenticator" process or thread, both are running on the same OS of the device.) So I think this issue is not specific to the pass-through authenticator. Yoshihiro Ohba > > > > In this document, the descriptions of EAP message handling assume that > > > per-packet MIC validation, where it occurs, is effectively performed > > > as though it occurs before examining any of the EAP message fields > > > (such as 'Code'). > > > > > > Some EAP methods may define MICs that cover more than one EAP packet. > > > Since the Identity Request/Response, Nak Response or Notification > > > Request/Response messages are not authenticated, once an EAP method > > > derives keys it may be desirable to exchange MICs that cover these > > > unauthenticated packets, so as to be able to detect forgeries after > > > the fact. Alternatively, an EAP method may define a MIC covering an > > > extended PDU that could be split into multiple fragments. > > > > > > In these situations, failure of MIC validation is typically a fatal > > > error, since it may not be possible to recover the original state and > > > continue the exchange. It should be understood that this increases > > > vulnerability to denial of service attacks." > > > > > > > Yoshihiro Ohba > > > > > > --__--__-- > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > End of eap Digest > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From henrik@levkowetz.com Fri Feb 7 17:05:57 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Feb 2003 18:05:57 +0100 Subject: [eap] Re: Issue 73: Various RFC 2284bis Comments In-Reply-To: References: Message-ID: <20030207180557.685ba1b9.henrik@levkowetz.com> Sorry for the response time. My machine crashed yesterday, I'm now up and about again with a new box. Some comments: On Tue, 4 Feb 2003 17:01:23 -0800 (PST) Bernard Aboba wrote: > Some thoughts: > > "HENRIK: Very well, but what do we wish to say with that? Is there a > conclusion here, or is this just FYI" > > BA: There used to be a conclusion there, but somehow it got lost :) > > I think that the point of this (if indeed there is one) was to clarify a > paragraph in RFC 2284 (has anyone implemented this?): > > Implementation Note: Because the Success and Failure packets > are not acknowledged, they may be potentially lost. A peer > MUST allow for this circumstance. The peer can use a Network > Protocol packet as an alternative indication of Success. > Likewise, the receipt of a LCP Terminate-Request can be taken > as a Failure. > > The idea of the new text is to clarify that packets like LCP Terminate-Request > can cause a link to go down, and therefore can cause EAP authentication to fail. But > packets like NCP mentioned above do not cause EAP authentication to > succeed. Ok. Do we want to add something regarding how to treat link down indication on a wireless link? Maybe: "Link down indications on 802.11 SHOULD NOT be taken as an authentication failure indication." > > ----------------------------------- > HENRIK: (I assume the state machine covers this? and also has other > timers to guarantee that the protocol doesn't hang forever > waiting for an infinite timer to expire. How much of this should > be described here? Should some text be removed, with reference > to the state machine document?) > > BA: I think that the state machine should probably cover the various ways > in which the RTO timer can be set. This includes [RFC2988] algorithms by > default; RFC 2869bis and 2284bis already has text that state how the RTO can > be set via the Session-Timeout attribute in RADIUS. So that same interface > can presumably be used by the lower layer to manipulate the EAP RTO value. Ok. I propose we leave the text as it is. > > ----------------------------------- > HENRIK: In view of the possibility of inserting a false EAP Failure > packet in e.g. wireless networks, maybe there should be a > RECOMMENDED discard of premature Failure packets in the case of > insecure link in combination with EAP methods with protected > error indications? > > BA: I would argue that premature Failure packets should always be > discarded. If the method isn't "complete" then they are unexpected. This > isn't that much of a constraint, since methods should probably terminate > via their own error messages, as opposed to by sending an EAP Failure right > away. I would agree. I propose we change the text accordingly From: "... 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." To: "... 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. In this case any premature EAP failure packet SHOULD be silently discarded." > ----------------------------------- > > HENRIK: How should the estimated effective key strength be indicated? > > BA: An excellent question :) Do you have a proposal? Mmm, could we assume that effective key strength can be indicated through effective key length? Then we might change the text as follows: From: "[d] Key strength. If the method derives keys, then the effective key strength MUST be estimated." To: "[d] Key strength. If the method derives keys, then the effective key length MUST be estimated." > ----------------------------------- > HENRIK: I believe I can see one security issue which has not > been discussed in this section, but might be mentioned: If the > authenticator uses pass-through to a backend authentication > server, it seems to me that the authenticator will not > understand method-specific success and failure indications, and > are dependent on seeing the final EAP Success (or Failure) > packet in order to know the outcome of the authentication. This > means that the link between authenticator and backend > authentication server needs to be secure against injection of > false EAP Success or Failure indications. This is probably the > case in most deployments, but might want mentioning for > completeness? I can propose some text for your consideration. > > BA: Actually, the authenticator only looks for the AAA Accept/Reject and > does not peer into the encapsulated EAP packet. > > Nevertheless, injection of spoofed EAP packets of any kind between the AAA > server and authenticator would be a bad thing. This is discussed in the > Security Considerations section of RFC 2869bis, and you might want to > steal some text from there: > > http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt There is some text there, but as it is talking about the RADIUS case, not all is applicable, and it does not specifically talk about the case of the unprotected generic EAP Success and Failure messages. I propose a new section: "7.12 Separation of EAP server and authenticator It is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to derive and pass a Transient Session Key (TSK) to the ciphersuite module. However, in the case where the EAP server and authenticator reside on different machines, there are several implications for security. [a] Authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone. [b] The authenticator is dependent on seeing the General EAP Success or Failure indications in order to know the outcome of an authentication conversation. It will not understand any method specific success or failure indications. And whereas individual EAP methods may employ Message Integrity Checks to ensure that individual packets have not been tampered with, the general EAP Success and Failure indications cannot be protected in this manner. This means that even if an authentication conversation between EAP server and peer has failed, injection of a EAP Success packet on the link between server and authenticator at the right time may lead to unauthenticated access. It is therefore important that the link between server and authenticator is either physically secure, or a secure transport mechanism for EAP packets are provided between EAP server and authenticator. The specification of such a wrapping mechanism is outside the scope of this document. [c] A EAP Master Session Key (MSK) negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the EAP server to the authenticator or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. " Henrik > ================================================================= > Issue 73: Various RFC 2284bis Comments > Submitter name: Henrik Levkowetz > Submitter email address: henrik@levkowetz.com > Date first submitted: Feburary 3, 2003 > Document: RFC2284bis-10 > Comment type: T > Priority: S > Section: various > Rationale/Explanation of issue: > Hi, > > Going over the 2284bis draft, I've come up with some points I'd like > to raise as issues for discussion. My comments are marked with HENRIK: > > > -------------------------------------- > In section 3.4: > > In 802.11 a "link down" indication is an unreliable indication of link > failure, since wireless signal strength can come and go and may be > influenced by radio frequency interference generated by an attacker. In > 802.11, control and management frames are not authenticated and an > attacker within range can gain access to the physical medium. Link layer > indications include Disassociate and Deauthenticate frames (link failure > indications), and Association and Reassociation Response frames (link > success indications). > > HENRIK: Very well, but what do we wish to say with that? Is there a > conclusion here, or is this just FYI > > -------------------------------------- > In section 4.1: > > When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as > within [PIC]), the EAP retransmission timer SHOULD be set to an > infinite value, so that retransmissions do not occur at the EAP > layer. > > HENRIK: (I assume the state machine covers this? and also has other > timers to guarantee that the protocol doesn't hang forever > waiting for an infinite timer to expire. How much of this should > be described here? Should some text be removed, with reference > to the state machine document?) > > > -------------------------------------- > In section 4.2.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. > > HENRIK: In view of the possibility of inserting a false EAP Failure > packet in e.g. wireless networks, maybe there should be a > RECOMMENDED discard of premature Failure packets in the case of > insecure link in combination with EAP methods with protected > error indications? > > -------------------------------------- > In section 7.2: > > [d] Key strength. If the method derives keys, then the effective key > strength MUST be estimated. > > HENRIK: How should the estimated effective key strength be indicated? > > -------------------------------------- > In section 7.: > > HENRIK: I believe I can see one security issue which has not > been discussed in this section, but might be mentioned: If the > authenticator uses pass-through to a backend authentication > server, it seems to me that the authenticator will not > understand method-specific success and failure indications, and > are dependent on seeing the final EAP Success (or Failure) > packet in order to know the outcome of the authentication. This > means that the link between authenticator and backend > authentication server needs to be secure against injection of > false EAP Success or Failure indications. This is probably the > case in most deployments, but might want mentioning for > completeness? I can propose some text for your consideration. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Fri Feb 7 20:49:12 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Feb 2003 22:49:12 +0200 Subject: [eap] Proposed Resolution of Issue 72 References: Message-ID: <3E441BC8.5030803@piuha.net> Bernard Aboba wrote: > Here's what RFC 2865, Section 4.1 says: > > An Access-Request SHOULD contain a User-Name attribute. It MUST > contain either a NAS-IP-Address attribute or a NAS-Identifier > attribute (or both). ... > The Class attribute is forbidden in Request, Reject and Challenge > packets in RFC 2865, so we will need to figure out another way to do this. ... > The original specification for the Class attribute does not include any > mention of message hiding. So I don't think that we can introduce that in > RFC 2869bis. We could of course define a new attribute -- or since IPsec usage > is now a SHOULD, we could assume IPsec protection and not worry about it. Ok, I'm convinced that we can't do what I originally thought. > Would it be possible to return the desired identifier within the User-Name > attribute in the Access-Accept? I think that would accomplish what you > want. Yes. But I was worried about attacks that might expose the AAA packet on the wireless side, and RADIUS a la plain 2865 would then expose User-Name. But as you say, maybe this isn't an issue if we have IPsec running. Jari From aboba@internaut.com Fri Feb 7 20:05:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Feb 2003 12:05:07 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 72 In-Reply-To: <3E441BC8.5030803@piuha.net> Message-ID: > Yes. But I was worried about attacks that might expose the AAA packet on > the wireless side, and RADIUS a la plain 2865 would then expose User-Name. > But as you say, maybe this isn't an issue if we have IPsec running. This is just one of many reasons why I think IPsec is very important. Would like some text describing how the User-Name could be sent in the access accept, or why IPsec is very important when Identity hiding is in use? From aboba@internaut.com Sun Feb 9 07:54:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 8 Feb 2003 23:54:14 -0800 (PST) Subject: [eap] Issue 73: Rewrite of Section 3.4 Message-ID: Here is a partial solution to Issue 73, requiring a rewrite of Section 3.4. Comments welcome. --------------------------------------------------------------------- 3.4. Link layer indications The reliability and security of link layer indications is dependent on the medium. Since EAP is media independent, the presence or absence of link layer security is not taken into account in the processing of EAP messages. Link layer failure indications provided to EAP by the link layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, link layer success indications MUST NOT affect EAP message processing so that an EAP implementation MUST NOT conclude that authentication has succeeded based on those indications. This ensures that an attacker spoofing link layer indications can at best succeed in a denial of service attack. Below is a discussion of some of the reliability and security issues with link layer indications in PPP, IEEE 802 wired networks and IEEE 802.11 wireless LANs: [1] PPP. In PPP, link layer indications such as LCP-Terminate (a link failure indication) and NCP (a link success indication) are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the physical medium. [2] IEEE 802 wired networks. On wired networks, IEEE 802.1X messages are sent to a non-forwardable multicast MAC address. As a result, while the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated or integrity protected, only an attacker with access to the physical link can spoof these messages. [3] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range. In IEEE 802.11, IEEE 802.1X data frames are sent as Class 3 unicast data frames, are therefore forwardable. This implies that while EAPOL-Start and EAPOL-Logoff messages may be authenticated and integrity protected, they can be spoofed by an authenticated attacker far from the target when "pre-authentication" is enabled. In IEEE 802.11 a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses. From aboba@internaut.com Sun Feb 9 08:15:28 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 00:15:28 -0800 (PST) Subject: [eap] Issue 79: Key Strength Estimate Message-ID: I'd like to split off a portion of Issue 73 (relating to key strength) into a separate issue. A number of changes are going to have to be made to deal with this, and so it is a subject of discussion in its own right. ----------------------------------------------------------------------- Issue 79: Key Strength Estimate Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: Technical Priority: S Section: 7.2 Rationale/Explanation of issue: [d] Key strength. If the method derives keys, then the effective key strength MUST be estimated. HENRIK: How should the estimated effective key strength be indicated? BA: An excellent question :) Do you have a proposal? From henrik@levkowetz.com Sun Feb 9 09:38:28 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Sun, 9 Feb 2003 10:38:28 +0100 Subject: [eap] Issue 73: Rewrite of Section 3.4 In-Reply-To: References: Message-ID: <20030209103828.2f99e134.henrik@levkowetz.com> The text looks good to me. However, I'd like to propose that we keep the first two and the last proposed paragraph in 3.4, while the remaining paragraphs are moved to Security Considerations, with a reference to them in 3.4. Specifics inline: On Sat, 8 Feb 2003 23:54:14 -0800 (PST), Bernard Aboba wrote: > Here is a partial solution to Issue 73, requiring a rewrite of Section > 3.4. Comments welcome. > > --------------------------------------------------------------------- > 3.4. Link layer indications > > The reliability and security of link layer indications is > dependent on the medium. Since EAP is media independent, > the presence or absence of link layer security is not > taken into account in the processing of EAP messages. Yes, keep in 3.4 > Link layer failure indications provided to EAP by the link layer > MUST be processed and will cause an EAP exchange > in progress to be aborted. However, link layer success indications > MUST NOT affect EAP message processing so that an EAP implementation > MUST NOT conclude that authentication has succeeded based on those > indications. This ensures that an attacker spoofing link layer > indications can at best succeed in a denial of service attack. Yes, keep in 3.4 In 3.4, replace the next para. with: A discussion of some reliability and security issues with link layer indications in PPP, IEEE 802 wired networks and IEEE 802.11 wireless LANs can be found in the Security Considerations, Section 7.xx. In Section 7, Security considerations, add a subsection "Link layer", with the following 5 para's: > Below is a discussion of some reliability and security > issues with link layer indications in PPP, IEEE 802 wired > networks and IEEE 802.11 wireless LANs: > > [1] PPP. In PPP, link layer indications such as LCP-Terminate > (a link failure indication) and NCP (a link success indication) are > not authenticated or integrity protected. They can therefore be > spoofed by an attacker with access to the physical medium. > > [2] IEEE 802 wired networks. On wired networks, IEEE 802.1X > messages are sent to a non-forwardable multicast MAC address. > As a result, while the IEEE 802.1X EAPOL-Start and > EAPOL-Logoff frames are not authenticated or integrity protected, > only an attacker with access to the physical link can spoof these > messages. > > [3] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer > indications include Disassociate and Deauthenticate frames > (link failure indications), and Association > and Reassociation Response frames (link success indications). > These messages are not authenticated or integrity protected, > and although they are not forwardable, they are spoofable by > an attacker within range. > > In IEEE 802.11, IEEE 802.1X data frames are sent as Class 3 > unicast data frames, are therefore forwardable. This implies > that while EAPOL-Start and EAPOL-Logoff messages may be > authenticated and integrity protected, they can be spoofed > by an authenticated attacker far from the target > when "pre-authentication" is enabled. -- end of text to move. Keep the following in 3.4: > In IEEE 802.11 a "link down" indication is an unreliable > indication of link failure, since wireless signal strength > can come and go and may be influenced by radio frequency > interference generated by an attacker. To avoid unnecessary > resets, it is advisable to damp these indications, > rather than passing them directly to the EAP. Since EAP supports > retransmission, it is robust against transient connectivity losses. Regards, Henrik From aboba@internaut.com Sun Feb 9 18:23:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 10:23:11 -0800 (PST) Subject: [eap] Issue 73: Rewrite of Section 3.4 In-Reply-To: <20030209103828.2f99e134.henrik@levkowetz.com> Message-ID: Sounds fine. On Sun, 9 Feb 2003, Henrik Levkowetz wrote: > The text looks good to me. However, I'd like to propose that we > keep the first two and the last proposed paragraph in 3.4, while the > remaining paragraphs are moved to Security Considerations, with > a reference to them in 3.4. Specifics inline: > > On Sat, 8 Feb 2003 23:54:14 -0800 (PST), Bernard Aboba wrote: > > Here is a partial solution to Issue 73, requiring a rewrite of Section > > 3.4. Comments welcome. > > > > --------------------------------------------------------------------- > > 3.4. Link layer indications > > > > The reliability and security of link layer indications is > > dependent on the medium. Since EAP is media independent, > > the presence or absence of link layer security is not > > taken into account in the processing of EAP messages. > > Yes, keep in 3.4 > > > Link layer failure indications provided to EAP by the link layer > > MUST be processed and will cause an EAP exchange > > in progress to be aborted. However, link layer success indications > > MUST NOT affect EAP message processing so that an EAP implementation > > MUST NOT conclude that authentication has succeeded based on those > > indications. This ensures that an attacker spoofing link layer > > indications can at best succeed in a denial of service attack. > > Yes, keep in 3.4 > > In 3.4, replace the next para. with: > > A discussion of some reliability and security > issues with link layer indications in PPP, IEEE 802 wired > networks and IEEE 802.11 wireless LANs can be found in the > Security Considerations, Section 7.xx. > > In Section 7, Security considerations, add a subsection > "Link layer", with the following 5 para's: > > > Below is a discussion of some reliability and security > > issues with link layer indications in PPP, IEEE 802 wired > > networks and IEEE 802.11 wireless LANs: > > > > [1] PPP. In PPP, link layer indications such as LCP-Terminate > > (a link failure indication) and NCP (a link success indication) are > > not authenticated or integrity protected. They can therefore be > > spoofed by an attacker with access to the physical medium. > > > > [2] IEEE 802 wired networks. On wired networks, IEEE 802.1X > > messages are sent to a non-forwardable multicast MAC address. > > As a result, while the IEEE 802.1X EAPOL-Start and > > EAPOL-Logoff frames are not authenticated or integrity protected, > > only an attacker with access to the physical link can spoof these > > messages. > > > > [3] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer > > indications include Disassociate and Deauthenticate frames > > (link failure indications), and Association > > and Reassociation Response frames (link success indications). > > These messages are not authenticated or integrity protected, > > and although they are not forwardable, they are spoofable by > > an attacker within range. > > > > In IEEE 802.11, IEEE 802.1X data frames are sent as Class 3 > > unicast data frames, are therefore forwardable. This implies > > that while EAPOL-Start and EAPOL-Logoff messages may be > > authenticated and integrity protected, they can be spoofed > > by an authenticated attacker far from the target > > when "pre-authentication" is enabled. > > -- end of text to move. Keep the following in 3.4: > > > In IEEE 802.11 a "link down" indication is an unreliable > > indication of link failure, since wireless signal strength > > can come and go and may be influenced by radio frequency > > interference generated by an attacker. To avoid unnecessary > > resets, it is advisable to damp these indications, > > rather than passing them directly to the EAP. Since EAP supports > > retransmission, it is robust against transient connectivity losses. > > Regards, > Henrik > From aboba@internaut.com Sun Feb 9 19:13:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 11:13:22 -0800 (PST) Subject: [eap] Potential resolution of Issue 41: Expanded Nak Message-ID: At the risk of misunderstanding Paul's suggested fix once again, I would like to submit the following potential resolution of Issue 41. This involves replacing the current Section 5.3 with the following: 5.3. Nak 5.3.1 Legacy Nak Description The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives. Since the legacy Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. Code 2 for Response. Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a legacy Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Length >=6 Type 3 Type-Data 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. 5.3.2 Expanded Nak Description The expanded Nak Type is valid only in Response messages. It MUST be sent only in reply to a Request of Type 254 (expanded Type) where the authentication Type is unacceptable. The expanded Nak Type uses the expanded Type format itself, and the Response contains one or more authentication Types desired by the peer, all in expanded Type format. Type zero (0) is used to indicate that the sender has no viable alternatives. Since the expanded Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. Code 2 for Response. Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a expanded Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Length >=40 Type 254 Vendor-Id 0 (IETF) Vendor-Type 3 (Nak) Vendor-Data The expanded Nak Type is only sent when the Request contains an expanded Type (254) as defined in Section 5.7. The Vendor-Data field of the Nak Response MUST contain one or more authentication Types (4 or greater), all in expanded format, 8 octets per Type, or the value zero (0), also in expanded Type format, to indicate no proposed alternative. The desired authentication Types may include a mixture of Vendor-Specific and IETF Types. For example, an expanded Nak Response indicating a preference for OTP (Type 5), and an MIT (Vendor-Id=20) Vendor-Specific Type of 6 would appear as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (OTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 20 (MIT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An expanded Nak Response indicating a no desired alternative would appear as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (No alternative) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From aboba@internaut.com Sun Feb 9 21:17:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 13:17:48 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through Message-ID: As a step toward resolution of Issue 74, I would like to ask implementers of EAP Authenticators supporting pass-through mode how they implementation Duplicate detection. For example: a. Do you perform duplicate Response detection on the authenticator prior to forwarding Responses to the authentication server? b. If so, can you provide details of how a duplicate is determined? Is this based solely on the Identifier value? Does it matter if the duplicate is received before or after another Request is sent? From aboba@internaut.com Sun Feb 9 21:30:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 13:30:27 -0800 (PST) Subject: [eap] Re: Issue 78: More terminology Message-ID: The term "EAP server" was meant to be used to denote *either* the authenticator (when local authentication is occurring) *or* the authentication server (when authentication is occurring in pass-through mode). The phrase "supports EAP method exchanges" seems like it could apply to *both* the authenticator and the authentication server. So I'm not sure that this is really a clarification. With respect to the definition of Silently Discard, this is the original text from RFC 2284. The intent here is to define auditable events; it is common practice in security specifications to make normative statements about which events are auditable in order to ensure that implementations keep appropriate logs, in order to be able to analyze attacks after the fact. Therefore it would seem that making these recommendations non-normative would decrease security. ------------------------------------------------------- Issue 78: More Terminology Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: Technical Priority: 1 Section: 1.2 Rationale/Explanation of issue: Item-a: EAP server description Rationale: The wording seems a bit confusing. Change: "EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server." To: "EAP server The entity that supports EAP method exchanges with the peer. This may be in the same device as the authenticator or it may be a backend authetication server." ------------------------------ Item-b: Silently discard description Rationale: Implementation suggestions should be marked as notes. Probably should not be protocol SHOULDs Change: " Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." to: " Silently Discard This means the implementation discards the packet without further processing. [Note: Good practice indicates that implementations should provide the capability of logging the event, including the contents of the silently discarded packet, and should record the event in a statistics counter." From james.d.carlson@east.sun.com Sun Feb 9 22:53:03 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sun, 9 Feb 2003 17:53:03 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: Bernard Aboba's message of 9 February 2003 13:17:48 References: Message-ID: <15942.56271.898949.775380@gargle.gargle.HOWL> Bernard Aboba writes: > a. Do you perform duplicate Response detection on the authenticator prior > to forwarding Responses to the authentication server? I don't have a pass-through implementation, but I do think there's a problem with the wording of this survey. There's no such thing as "duplicate Response detection." The only thing one can detect here is a Response with an invalid ID -- an Identifier value that does not match the last Request. Unmatching messages *might* be duplicates, but may also be any sort of arbitrary unexpected message. The issue of duplicate detection, as defined by EAP, matters only for Request messages, and then only on the authenticatee side, where, presumably, nobody has a pass-through implementation. I think that question should read: a. Do you discard any received Response messages that have an invalid Identifier field, or do you pass these along to the authentication server? ... of course, with that wording, I doubt that anyone would consider the pass-through behavior in the latter case to be anything other than a bug. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Sun Feb 9 22:24:17 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 14:24:17 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <15942.56271.898949.775380@gargle.gargle.HOWL> Message-ID: > a. Do you discard any received Response messages that have an > invalid Identifier field, or do you pass these along to the > authentication server? > > ... of course, with that wording, I doubt that anyone would consider > the pass-through behavior in the latter case to be anything other than > a bug. Assuming that there is an outstanding Request, why would a received Response message with a matching Identifier field be considered invalid? The Identifier doesn't change until another Request is sent. By this logic, it would seem that the authenticator operating in pass-through should forward any Response message with a matching Identifier field; but once a Request is sent, the Response messages would be considered invalid, and not forwarded. From aboba@internaut.com Sun Feb 9 23:04:41 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 15:04:41 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC Message-ID: I believe that discussion on Issue 74 has exposed a mistake in the handling of Responses in Section 4.1 Request and Response. With this mistake corrected, I believe that the resolution of this issue becomes more apparent. As a result, I would like to propose a rewrite of the Description text as follows: ----------------------------------- 4.1 Request and Response Description The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. In [IEEE8021X], the retry counter is effectively set to zero, so that retransmission never occurs, and instead the peer times out and authentication is restarted. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request. An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response. The Type field of a Response MUST either match that of the Request, or correspond to a legacy or expanded Nak (see Section 5.3). An EAP server receiving a Response packet with an invalid Type field MUST silently discard the Response. The authenticator MUST NOT send a new Request until a valid Response is received to an outstanding Request. Since the authenticator can retransmit before receiving a valid Response from the peer, the authenticator can receive duplicate Responses. If a Message Integrity Check (MIC) is employed within an EAP method, then peer and EAP server implementations MUST silently discard any message that fails this check. In this document, the descriptions of EAP message handling assume that MIC validation is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code'). Implementation Note: The authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The authenticator is also responsible for discarding Response messages with a non-matching Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. However, if an authenticator receives multiple Responses, each with a matching Identifier, then it will pass each of them on to the backend authentication server. Similarly, the peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party. Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be computed as described in [RFC2988]. This includes use of Karn's algorithm to filter RTT estimates resulting from retransmissions. A maximum of 3-5 retransmissions is suggested. When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Note that in this case the peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. Where the authentication process requires user input, the measured round trip times are largely be determined by user responsiveness rather than network characteristics, so that RTO estimation is not helpful. Instead, the retransmission timers SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). From paul@funk.com Mon Feb 10 00:26:14 2003 From: paul@funk.com (Paul Funk) Date: Sun, 09 Feb 2003 19:26:14 -0500 Subject: [eap] Re: Potential resolution of Issue 41: Expanded Nak In-Reply-To: Message-ID: <5.2.0.9.0.20030209191515.02605610@mail.funk.com> Bernard, Yes, this is exactly what I had in mind. You use the term "expanded type" to refer to 254, but section 5.7 defines "vendor-specific type" to mean the same thing. I prefer "expanded type" and would suggest updating 5.7 with that term. Paul At 11:13 AM 2/9/2003 -0800, Bernard Aboba wrote: >At the risk of misunderstanding Paul's suggested fix once again, I would >like to submit the following potential resolution of Issue 41. This >involves replacing the current Section 5.3 with the following: > >5.3. Nak > >5.3.1 Legacy Nak > >Description > > The legacy Nak Type is valid only in Response messages. It is sent > in reply to a Request where the desired authentication Type is > unacceptable. Authentication Types are numbered 4 and above. > The Response contains one or more authentication Types desired > by the Peer. Type zero (0) is used to indicate that the sender > has no viable alternatives. > > Since the legacy Nak Type is only valid in Responses and has very > limited functionality, it MUST NOT be used as a general purpose error > indication, such as for communication of error messages, or > negotiation of parameters specific to a particular EAP method. > >Code > > 2 for Response. > >Identifier > > The Identifier field is one octet and aids in matching Responses > with Requests. The Identifier field of a legacy Nak Response > MUST match the Identifier field of the Request packet that it > is sent in response to. > >Length > > >=6 > >Type > > 3 > >Type-Data > > 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. > >5.3.2 Expanded Nak > >Description > > The expanded Nak Type is valid only in Response messages. It MUST > be sent only in reply to a Request of Type 254 (expanded Type) > where the authentication Type is unacceptable. The expanded Nak > Type uses the expanded Type format itself, and the Response > contains one or more authentication Types desired by the peer, > all in expanded Type format. Type zero (0) is used to indicate > that the sender has no viable alternatives. > > Since the expanded Nak Type is only valid in Responses and > has very limited functionality, it MUST NOT be used as a > general purpose error indication, such as for communication > of error messages, or negotiation of parameters specific to > a particular EAP method. > >Code > > 2 for Response. > >Identifier > > The Identifier field is one octet and aids in matching Responses > with Requests. The Identifier field of a expanded Nak Response > MUST match the Identifier field of the Request packet that it > is sent in response to. > >Length > > >=40 > >Type > > 254 > >Vendor-Id > > 0 (IETF) > >Vendor-Type > > 3 (Nak) > >Vendor-Data > > The expanded Nak Type is only sent when the Request contains an > expanded Type (254) as defined in Section 5.7. The Vendor-Data > field of the Nak Response MUST contain one or more authentication > Types (4 or greater), all in expanded format, 8 octets per Type, > or the value zero (0), also in expanded Type format, to indicate > no proposed alternative. The desired authentication Types may > include a mixture of Vendor-Specific and IETF Types. For example, > an expanded Nak Response indicating a preference for OTP (Type 5), > and an MIT (Vendor-Id=20) Vendor-Specific Type of 6 would > appear as follows: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 2 | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=254 | 0 (IETF) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 (Nak) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=254 | 0 (IETF) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5 (OTP) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=254 | 20 (MIT) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > An expanded Nak Response indicating a no desired alternative > would appear as follows: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 2 | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=254 | 0 (IETF) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 (Nak) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=254 | 0 (IETF) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 (No alternative) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From aboba@internaut.com Sun Feb 9 23:16:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 15:16:51 -0800 (PST) Subject: [eap] Re: Potential resolution of Issue 41: Expanded Nak In-Reply-To: <5.2.0.9.0.20030209191515.02605610@mail.funk.com> Message-ID: Wow! I actually got it right this time :) I agree that section 5.7 should be updated as you state. On Sun, 9 Feb 2003, Paul Funk wrote: > Bernard, > > Yes, this is exactly what I had in mind. > > You use the term "expanded type" to refer to 254, but section 5.7 > defines "vendor-specific type" to mean the same thing. I prefer > "expanded type" and would suggest updating 5.7 with that term. > > Paul From aboba@internaut.com Sun Feb 9 23:30:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 15:30:48 -0800 (PST) Subject: [eap] More on Issue 74 Message-ID: The proposed text on Issue 74 (see previous message) also implies a change to RFC 2869bis to handle the case of a MIC failure detected by the authentication server. With the proposed text, a Response spoofed by an attacker would be sent to the AAA server, and would fail the MIC check. While the authentication server would silently discard the Response, unless it responded to the NAS in some way, the NAS would retransmit the invalid Response until it timed out. This is undesirable -- so the AAA server needs to send an Access-Challenge saying "this one was bad, send another if you have it." I would propose this be done by sending an EAP-Message attribute with nothing in it (EAP-Start) within the Access-Challenge. The NAS then sends additional Responses with an Identifier value matching the outstanding Request, if any exist. This would presumably include the authentic EAP Response sent by the peer, which would pass the MIC check. The conversation would then continue. Given all of this, I think that James' original suggested text with respect to MIC processing stands as written. Assuming that the WG agrees, I will make the change to RFC 2869bis as part of dealing with IETF last call comments. IETF last call on RFC 2869bis will last longer than usual (4 weeks) in order to provide the community with adequate opportunity to read it and comment. From aboba@internaut.com Mon Feb 10 00:46:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 9 Feb 2003 16:46:48 -0800 (PST) Subject: [eap] Yet more on Issue 74 Message-ID: Here is the text I would propose to add to RFC 2869bis to complete the proposed fix of Issue 74: 2.5. Invalid packets EAP methods may contain a per-packet Message Integrity Check (MIC). Although EAP methods such as EAP-TLS [RFC2716] treat MIC check failures as fatal errors, it may be desirable for an EAP method to silently discard an invalid EAP packet, and subsequently continue the conversation. This provides additional resilience against Denial of Service (DoS) attacks. When a RADIUS server receives an Access-Request containing an EAP- Message attribute encapsulating an invalid EAP packet, it SHOULD NOT silently discard the Access-Request without informing the NAS. This would cause the NAS to retransmit the Access-Request, then eventually time-out and initiate failover. As a result, it is best for the RADIUS server to formulate a response of some kind. If the error is considered fatal, an Access-Reject can be sent. In order for the RADIUS server to communicate that an invalid EAP packet has been received, but that the problem is non-fatal, an Access- Challenge containing an EAP-Start MAY be sent. A NAS receiving an Access-Challenge with an EAP-Start MUST discard the EAP packet that it had previously encapsulated within an Access-Request. It will then check whether it has received additional EAP Response packets with an Identifier matching that of the last Request. If so, a new EAP Response packet will be sent to the RADIUS server within an Access-Request packet. 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. From johan.rh.hermans@alcatel.be Mon Feb 10 10:11:54 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Mon, 10 Feb 2003 11:11:54 +0100 Subject: [eap] EAP-in-Radius test tool ? Message-ID: <3E477AEA.2080402@alcatel.be> Hello, does anyone have a pointer to a simple tool that can be used to test EAP-messages, encapsulated in Radius ? I was thinking of a kind of "radping"-tool. Just the MD5-challenge will be enough. I do have one of my own ofcourse, but I want to make sure that interworking works. -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From james.d.carlson@east.sun.com Mon Feb 10 11:25:41 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 10 Feb 2003 06:25:41 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: Bernard Aboba's message of 9 February 2003 14:24:17 References: <15942.56271.898949.775380@gargle.gargle.HOWL> Message-ID: <15943.35893.992997.158134@gargle.gargle.HOWL> Bernard Aboba writes: > > a. Do you discard any received Response messages that have an > > invalid Identifier field, or do you pass these along to the > > authentication server? > > > > ... of course, with that wording, I doubt that anyone would consider > > the pass-through behavior in the latter case to be anything other than > > a bug. > > Assuming that there is an outstanding Request, why would a received > Response message with a matching Identifier field be considered invalid? > The Identifier doesn't change until another Request is sent. Once you've got a Response to a given Request, there can be no more valid Responses -- you're done. This feels like familiar ground. What we're looking at here is time skew. From the point of view of the authenticator, this case cannot occur. Once you receive a valid Response message (one that has an Identifier field that is equal to the Identifier in the last transmitted Request), you are then required to send the next Request or the Success/Failure termination. There's no case in which you've received a Response and you're just pondering what's next. If you extend this mechanism through intermediaries, I don't see how or why the model should be any different. Once the valid Response is seen, that round is done. > By this logic, it would seem that the authenticator operating in > pass-through should forward any Response message with a matching > Identifier field; but once a Request is sent, the Response messages would > be considered invalid, and not forwarded. This certainly sounds to me like another MIC-related issue -- that is, one that pops up only because the security model has been altered from the original EAP design to include the possibility of a man-in-the- middle attacker. Otherwise, why would you care about the treatment of "duplicate" responses? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Mon Feb 10 13:10:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 10 Feb 2003 05:10:22 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <15943.35893.992997.158134@gargle.gargle.HOWL> Message-ID: > Once you've got a Response to a given Request, there can be no more > valid Responses -- you're done. I would agree to that once the EAP server has gotten a *valid* Response to a given Request -- because at that point the Identifier has changed. But the question is what the behavior is on an authenticator in pass through mode. It can't know that the Response that it just forwarded to the authentication server is valid or not -- and it doesn't know what the new Identifier is. > This feels like familiar ground. What we're looking at here is time > skew. From the point of view of the authenticator, this case cannot > occur. Once you receive a valid Response message (one that has an > Identifier field that is equal to the Identifier in the last > transmitted Request), I'd claim that a valid Response requires more than just a valid Identifier. > you are then required to send the next Request > or the Success/Failure termination. There's no case in which you've > received a Response and you're just pondering what's next. For a valid Response, that is true. > If you extend this mechanism through intermediaries, I don't see how > or why the model should be any different. Once the valid Response is > seen, that round is done. It is different because the intermediary can only determine the validity of the Response when it receives a new Request from the authentication server. It's at that point that the Identifier changes. > This certainly sounds to me like another MIC-related issue -- that is, Yes, it is. From james.d.carlson@east.sun.com Mon Feb 10 14:40:25 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 10 Feb 2003 09:40:25 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: Bernard Aboba's message of 10 February 2003 05:10:22 References: <15943.35893.992997.158134@gargle.gargle.HOWL> Message-ID: <15943.47577.643241.307015@gargle.gargle.HOWL> Bernard Aboba writes: > > Once you've got a Response to a given Request, there can be no more > > valid Responses -- you're done. > > I would agree to that once the EAP server has gotten a *valid* Response to > a given Request -- because at that point the Identifier has changed. But the > question is what the behavior is on an authenticator in pass through mode. > It can't know that the Response that it just forwarded to the > authentication server is valid or not -- and it doesn't know what the > new Identifier is. I don't follow. The EAP server in pass-through mode must certainly know what a valid Identifier value looks like. It must know this because it is the one that is performing Request retransmissions, and thus it has a copy of the most recent Request sent. (We've already established that this cannot be driven by DIAMETER or RADIUS, correct?) If you're proposing that somehow the authenticatee can generate a Response with an Identifier that corresponds to a Request that it has not yet seen, and have these two cross in flight, I don't think I understand why it would be useful to support that. > > This feels like familiar ground. What we're looking at here is time > > skew. From the point of view of the authenticator, this case cannot > > occur. Once you receive a valid Response message (one that has an > > Identifier field that is equal to the Identifier in the last > > transmitted Request), > > I'd claim that a valid Response requires more than just a valid > Identifier. RFC 2284 would claim otherwise. There are four clear cases: - Packet is hopelessly mangled and unrecognizable -- drop. - Identifier field is wrong -- drop. - Identifier field is right, but contents are wrong. Send Failure. - Identifier field and contents are right. Send Success. You're proposing a fifth possibility here -- Identifier is correct but contents are wrong, and yet we're just going to drop it. I don't see how that's a valid thing to do. Moreover, this case seems to exist solely for the purpose of supporting MICs. In that case, why not define the MIC such that the pass-through device is in on the game? In other words, why not define these protocols such that you can have the EAP server do the MIC validation before ever passing the data along to the authenticator? > > If you extend this mechanism through intermediaries, I don't see how > > or why the model should be any different. Once the valid Response is > > seen, that round is done. > > It is different because the intermediary can only determine the > validity of the Response when it receives a new Request from the > authentication server. It's at that point that the Identifier changes. That doesn't actually matter, because it can't possibly get any valid Response messages to that new Request until it's seen the new Request and forwarded it along. At that point, it knows the new Identifier value of interest. The assumption here seems to be that the EAP server doesn't support the MIC feature and that (somehow) the Identifier value serves as a cleartext MIC-like thing. Considering the absurd lengths that folks will go to in order to reduce load on authentication servers (lightweight rechallenges, short hold, and such), that seems to me to be the wrong sort of direction to head because it allows attackers connected to distributed EAP servers to inundate a central authenticator with garbage to validate and discard. Thought experiment: suppose you did have the EAP server functionality as you propose, and the EAP server passed through all messages with the current Identifier value until a new Request was seen. You've previously said that it's "illegal" for an authenticator to offer a new EAP Request without having received a Response to its last one.[1] How does the EAP server, which is not privy to the validity of the Response messages, know when it can pass along a new Request and when it cannot? Does this mechanism violate the never-change-type- midstream requirement? [1] And I still disagree that this is the right thing to do. I still see no reason to disallow this RFC 2284-compliant behavior. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Mon Feb 10 13:54:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 10 Feb 2003 05:54:49 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <15943.47577.643241.307015@gargle.gargle.HOWL> Message-ID: > the most recent Request sent. (We've already established that this > cannot be driven by DIAMETER or RADIUS, correct?) Yes, retransmission cannot be driven by AAA. And yes, the authenticator knows that the currently valid Identifier is, regardless of the mode. The question is the precise moment at which that Identifier value *changes*. The claim is that when the authenticator isn't in pass-through, that moment occurs when it receives a valid Response, with validity including *all* checks made on the packet (including a MIC). If the packet fails any of the validity checks, it is silently discarded as if it was never sent. In this case that would mean that the Identifier doesn't change and the authenticator will retransmit the Request. When the authenticator operates in pass-through, the claim is that the Identifier doesn't change until a valid Request is received from the authentication server. > RFC 2284 would claim otherwise. There are four clear cases: > > - Packet is hopelessly mangled and unrecognizable -- drop. > - Identifier field is wrong -- drop. > - Identifier field is right, but contents are wrong. Send > Failure. Where in RFC 2284 does it indicate this? > - Identifier field and contents are right. Send Success. > > You're proposing a fifth possibility here -- Identifier is correct but > contents are wrong, and yet we're just going to drop it. I don't see > how that's a valid thing to do. The text you added on processing of MICs indicates this course of action, no? > Moreover, this case seems to exist solely for the purpose of > supporting MICs. In that case, why not define the MIC such that the > pass-through device is in on the game? That would only be possible if the MIC was in EAP itself, rather than within a method. Otherwise the authenticator will have to have EAP-method specific knowledge to check the MIC. > That doesn't actually matter, because it can't possibly get any valid > Response messages to that new Request until it's seen the new Request > and forwarded it along. At that point, it knows the new Identifier > value of interest. Yes. > The assumption here seems to be that the EAP server doesn't support > the MIC feature and that (somehow) the Identifier value serves as a > cleartext MIC-like thing. The assumption is that the authentication server does support the EAP method-specific MIC, and that by sending a Request it is implicitly indicating that it has found the previous Response valid. > be the wrong sort of direction to head because it allows attackers > connected to distributed EAP servers to inundate a central > authenticator with garbage to validate and discard. One way to judge the vulnerability to DoS is to look at the ratio of cycles required for the attack versus those consumed on the target. Checking a MIC is a relatively lightweight operation compared to say, a public key operation which will often occur early in the method. So it is actually less expensive for the method to check the MIC and silently discard than it is to fail authentication, and presumably have to do the entire method over again, including the public key operations. That means that failure is not a more secure approach, and more advanced protocols almost always prefer silent discard. Look at IKE (silent discard) vs. TLS (MIC as fatal error); AES CCMP (silent discard) vs. TKIP (counter-measures). > Thought experiment: suppose you did have the authenticator functionality > as you propose, and the authenticator passed through all messages with > the current Identifier value until a new Request was seen. Actually, what is being proposed is that the authenticator passes through the first Response; if it receives a new Request, the Identifier changes and additional Responses with the old Identifier are discarded. It only forwards additional Responses with the matching Identifier if the authentication server indicates that the initially forwarded Response is invalid. > previously said that it's "illegal" for an authenticator to offer a > new EAP Request without having received a Response to its last one.[1] Actually, we're proposing to remove that. > How does the authenticator, which is not privy to the validity of the > Response messages, know when it can pass along a new Request and when > it cannot? When it receives a new Request, it forwards it to the peer. > Does this mechanism violate the never-change-type- > midstream requirement? I don't think so. From james.d.carlson@east.sun.com Mon Feb 10 17:14:06 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 10 Feb 2003 12:14:06 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: Bernard Aboba's message of 10 February 2003 05:54:49 References: <15943.47577.643241.307015@gargle.gargle.HOWL> Message-ID: <15943.56798.850198.605679@gargle.gargle.HOWL> Bernard Aboba writes: > > RFC 2284 would claim otherwise. There are four clear cases: > > > > - Packet is hopelessly mangled and unrecognizable -- drop. > > - Identifier field is wrong -- drop. > > - Identifier field is right, but contents are wrong. Send > > Failure. > > Where in RFC 2284 does it indicate this? The first case is just basic networking; it's implied. (For example, if the Length field indicates that the message is *longer* than the actual message received, then the implementation MUST silently discard the malformed message. Not in the text, but obviously implied.) The second case is in 2.2.1 -- "The Identifier field of the Response MUST match that of the Request." The third case is in 2.2.2 -- "If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure)." > > You're proposing a fifth possibility here -- Identifier is correct but > > contents are wrong, and yet we're just going to drop it. I don't see > > how that's a valid thing to do. > > The text you added on processing of MICs indicates this course of action, > no? No. Perhaps there's still imprecision in the text. I view MICs as being identical to other frame integrity checks in terms of their position in the architecture. It's the responsibility of the receiver (the EAP server, in this case) to perform those checks before passing the message along. I don't see this as being terribly different from what the peer is required to do if the packets are completely malformed (what do you do with a message whose Length exceeds the size of the actual data, or with one that has a bad CRC?), nor different from what you do with (for example) IP datagrams that have a bad header checksum at an intermediate hop. You drop. > > Moreover, this case seems to exist solely for the purpose of > > supporting MICs. In that case, why not define the MIC such that the > > pass-through device is in on the game? > > That would only be possible if the MIC was in EAP itself, rather than > within a method. Otherwise the authenticator will have to have EAP-method > specific knowledge to check the MIC. Not necessarily. It implies that the protocol used to separate the EAP server from the authenticator needs to convey the MIC-related data from the authenticator to the EAP server. In other words, it's not different from the shared-key derivation problem or from the "how does the EAP server know to trust the AAA server when the latter says Success?" problem. > > The assumption here seems to be that the EAP server doesn't support > > the MIC feature and that (somehow) the Identifier value serves as a > > cleartext MIC-like thing. > > The assumption is that the authentication server does support the EAP > method-specific MIC, and that by sending a Request it is implicitly > indicating that it has found the previous Response valid. That's not necessarily true. A good implementation should fake its way through the rest of the sequence, if possible, in order to deny an attacker additional information. If you fail part way through, then you are telling your attacker what bits of his attack are incorrect. > > be the wrong sort of direction to head because it allows attackers > > connected to distributed EAP servers to inundate a central > > authenticator with garbage to validate and discard. > > One way to judge the vulnerability to DoS is to look at the ratio of > cycles required for the attack versus those consumed on the target. > Checking a MIC is a relatively lightweight operation compared to say, a > public key operation which will often occur early in the method. So it is > actually less expensive for the method to check the MIC and silently > discard than it is to fail authentication, and presumably have to do the > entire method over again, including the public key operations. Note that we have a distributed attacker and a centralized target here. > That means that failure is not a more secure approach, and more > advanced protocols almost always prefer silent discard. Look at IKE > (silent discard) vs. TLS (MIC as fatal error); AES CCMP (silent discard) > vs. TKIP (counter-measures). That's not the question. The question is *where* the discard ought to be done, not *if*. > > Thought experiment: suppose you did have the authenticator functionality > > as you propose, and the authenticator passed through all messages with > > the current Identifier value until a new Request was seen. > > Actually, what is being proposed is that the authenticator passes through > the first Response; if it receives a new Request, the Identifier changes > and additional Responses with the old Identifier are discarded. It only > forwards additional Responses with the matching Identifier if the > authentication server indicates that the initially forwarded Response is > invalid. How does the authentication server indicate that the initially forwarded Response was invalid? If the authentication server sends a new Request to issue to the authenticatee, with or without a new Identifier, then I'd argue that this finishes the problem -- no special handling is required at all because now the EAP server can do the "right" thing and let through exactly one Response. > > previously said that it's "illegal" for an authenticator to offer a > > new EAP Request without having received a Response to its last one.[1] > > Actually, we're proposing to remove that. That sounds good. > > How does the authenticator, which is not privy to the validity of the > > Response messages, know when it can pass along a new Request and when > > it cannot? > > When it receives a new Request, it forwards it to the peer. Then no new mechanism is needed here on the EAP server, because this devolves to the already-known case: authenticator sends Request, EAP server forwards exactly one matching Response, and drops all others (duplicate or otherwise) until the next Request is received from the authentication server. (Not that I'm arguing that this MIC-related stuff is a good thing. It seems to be based on questionable assumptions.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From dhala@cisco.com Mon Feb 10 21:11:52 2003 From: dhala@cisco.com (David Halasz) Date: Mon, 10 Feb 2003 16:11:52 -0500 Subject: [eap] Re: TGi Ad-hoc meeting information In-Reply-To: Message-ID: <4.3.2.7.2.20030210160147.022bf300@unitas.cisco.com> --=====================_1063598854==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The tentative agenda for the IEEE 802.11i Ad-Hoc is as follows, 2/19 AM CCMP Protocol stack discussion 2/19 PM Sub-groups 2/20 AM Sub-groups 2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams 2/21 AM Fast roaming discussion 2/21 PM Sub-groups We divided into 5 sub-groups. 1. Clauses 2, 3, 4, 7, Appendix A (Dave Halasz) 2. Clauses 5, 10, 11 (Dorothy Stanley) 3. Clause 8, Annex F - CCMP (Paul Lambert) 4. Clause 8, Annex F - TKIP (Tim Moore) 5. Clause 8, Annex F - Other (Jesse Walker) I think most of sub-group 3 was taken care of at the January meeting. The comments received are at, http://www.ieee802.org/11/Documents/DocumentHolder/3-033.zip Please note that all comments resolved are not yet reflected in 03-033. The January meeting minutes are at, http://www.ieee802.org/11/Documents/DocumentHolder/3-096.zip Dave H. At 03:51 PM 2/10/2003, Tim Moore wrote: >Information for the TGi Ad-hoc meeting Feb 19-21, Sorry for the delay in >sending the details out. > >It will be on the the main Redmond campus in Building 50. Okanogan room. > >Breakfast and Lunch will be supplied. > >Directions to the Main Microsoft Campus from Seatac Airport: > * Follow signs to Freeways, this will put you on SR 518 eastbound, > merge carefully. > * Follow signs to I-5 and I-405. > * Take I-405 North-Renton (center lane). > * Continue on North I-405 thru Renton and Bellevue, approx. 14 miles. > * Take SR-520 East exit toward Redmond. > * Exit SR-520 at NE 40th St exit. > * Turn Right at exit onto NE 40th St. > > > > >A list of hotels that are nearby are below. There isn't any special >arrangement with any particular hotel. > >Local Hotel Listing >A. DoubleTree >300 112th Ave SE >Bellevue >(425) 455-1300 >(800) 733-5466 >http://www.doubletree.com/ B. Hyatt Regency >NE 8th and Bellevue Way >Bellevue >(425) 462-2626 >(800) 462-1234 >http://www.hyatt.com/ C. Hilton Bellevue >100 112th Ave NE >Bellevue WA >(425) 455-3330 >(800) 235-4458 >http://www.hilton.com/ D. Timberlawn Apts. >15850 NE 40th Street >Redmond, WA 98052 >425-883-6801 >E. Residence Inn at >Redmond Town Center >7575 164th Avenue NE >Redmond, WA 98052 >425-497-9226 >800-331-3131 >http://www.residenceinn.com/ F. The >Residence Inn >14455 NE 29th Place >Bellevue, WA >(425) 882-1222 >(800) 331-3131 >http://www.residenceinn.com G. Homestead >Village >15805 NE 28th St >Bellevue WA 98008 >425-885-6675 >888-782-7473 >http://www.homesteadvillage.com >H. Embassy Suites >3225 158th Avenue SE >Bellevue WA 98008 >425-644-2500 >800-362-2779 >http://www.embassysuites.com >I. Bellevue Club >11200 SE 6th Street >Bellevue, WA 98004 >425-454-4424 >800-579-1110 >http://www.bellevueclub.com/hotel.htm >J. Courtyard Bellevue >14615 NE 29th Place >Bellevue, WA 98007 >425-869-5300 >800-321-2211 >http://www.courtyard.com/ K. Fairfield Inn >14595 NE 29th Place >Bellevue, WA 98007 >425-869-6548 >800-228-2800 >http://www.fairfieldinn.com/ > >Tim > Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 --=====================_1063598854==_.ALT Content-Type: text/html; charset="us-ascii" The tentative agenda for the IEEE 802.11i Ad-Hoc is as follows,

2/19 AM CCMP Protocol stack discussion
2/19 PM Sub-groups

2/20 AM Sub-groups
2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams

2/21 AM Fast roaming discussion
2/21 PM Sub-groups

We divided into 5 sub-groups.

1. Clauses 2, 3, 4, 7, Appendix A (Dave Halasz)
2. Clauses 5, 10, 11 (Dorothy Stanley)
3. Clause 8, Annex F - CCMP (Paul Lambert)
4. Clause 8, Annex F - TKIP (Tim Moore)
5. Clause 8, Annex F - Other (Jesse Walker)

I think most of sub-group 3 was taken care of at the January meeting.

The comments received are at,
http://www.ieee802.org/11/Documents/DocumentHolder/3-033.zip
Please note that all comments resolved are not yet reflected in 03-033.

The January meeting minutes are at,
http://www.ieee802.org/11/Documents/DocumentHolder/3-096.zip


        Dave H.

At 03:51 PM 2/10/2003, Tim Moore wrote:
Information for the TGi Ad-hoc meeting Feb 19-21, Sorry for the delay in sending the details out.
 
It will be on the the main Redmond campus in Building 50. Okanogan room.
 
Breakfast and Lunch will be supplied.
 
Directions to the Main Microsoft Campus from Seatac Airport:
  • Follow signs to Freeways, this will put you on SR 518 eastbound, merge carefully.
  • Follow signs to I-5 and I-405.
  • Take I-405 North-Renton (center lane).
  • Continue on North I-405 thru Renton and Bellevue, approx. 14 miles.
  • Take SR-520 East exit toward Redmond.
  • Exit SR-520 at NE 40th St exit.
  • Turn Right at exit onto NE 40th St.


 

A list of hotels that are nearby are below. There isn't any special arrangement with any particular hotel.

Local Hotel Listing
A.  DoubleTree
300 112th Ave SE
Bellevue
(425) 455-1300
(800) 733-5466
http://www.doubletree.com/ B.  Hyatt Regency
NE 8th and Bellevue Way
Bellevue
(425) 462-2626
(800) 462-1234
http://www.hyatt.com/ C.  Hilton Bellevue
100 112th Ave NE
Bellevue WA
(425) 455-3330
(800) 235-4458
http://www.hilton.com/ D.  Timberlawn Apts.
15850 NE 40th Street
Redmond, WA 98052
425-883-6801
E.  Residence Inn at
Redmond Town Center
7575 164th Avenue NE
Redmond, WA 98052
425-497-9226
800-331-3131
http://www.residenceinn.com/ F.  The Residence Inn
14455 NE 29th Place
Bellevue, WA
(425) 882-1222
(800) 331-3131
http://www.residenceinn.com G.  Homestead Village
15805 NE 28th St
Bellevue WA 98008
425-885-6675
888-782-7473
http://www.homesteadvillage.com H.  Embassy Suites
3225 158th Avenue SE
Bellevue WA 98008
425-644-2500
800-362-2779
http://www.embassysuites.com
I.  Bellevue Club
11200 SE 6th Street
Bellevue, WA 98004
425-454-4424
800-579-1110 http://www.bellevueclub.com/hotel.htm J.  Courtyard Bellevue
14615 NE 29th Place
Bellevue, WA 98007
425-869-5300
800-321-2211
http://www.courtyard.com/ K.  Fairfield Inn
14595 NE 29th Place
Bellevue, WA 98007
425-869-6548
800-228-2800
http://www.fairfieldinn.com/
 
Tim
 


Dave Halasz
Cisco Systems, Inc.
320 Springside Drive
Akron, OH  44333
--=====================_1063598854==_.ALT-- From henrik@levkowetz.com Mon Feb 10 22:29:19 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 10 Feb 2003 23:29:19 +0100 Subject: [eap] Intermediate rfc2284bis draft available Message-ID: <20030210232919.4bd2f230.henrik@levkowetz.com> Hi, A new intermediate rfc2284bis draft is available at http://www.levkowetz.com/pub/ietf/drafts/eap/ , numbered -01.a . I've: Updated Section 3.4, Link layer indications [from issue 73]. Updated Section 5.3, Legacy and Expanded Nak [issue 41]. Changed Vendor-Specific to Expanded in Sections 5, 5.7 &c. [from issue 41 resolution]. Added a new section 7.12 [from issue 73]. There's a html diff and a changebar version available, too. Best regards, Henrik From npetroni@cs.umd.edu Mon Feb 10 23:34:21 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Mon, 10 Feb 2003 18:34:21 -0500 (EST) Subject: [eap] success indications and protected success/failure Message-ID: I am requesting some comments/clarification on the topic of when the success state can be reached by the peer. Executive summary: ----------------- 1. Is a satisfied policy enough for a peer transition to the success state, or is a SUCCESS packet required? 2. Is the text in 4.2.1 contradicting the current EAP model, or do I have an incorrect understanding of the model? (these are not mutually exclusive) Full explanation: ---------------- Through conversation with the state machine design team, I have come to question the conditions for success of an EAP conversation. All parties seem to agree that a satisfied policy is necessary for the peer to begin using the link, but the question is whether or not the condition is sufficient. That is, if a SUCCESS message never comes, can the peer transition to the SUCCESS state? The "alternate indications" of RFC2284 seem to imply that it can, however, section 3.4 of 2284bis explicitly warns against accepting link-layer indications (and for good reason). Since SUCCESS messages are neither acknowledged nor retransmitted, it is possible that SUCCESS messages could be lost causing an unneeded timeout. Assuming the link never goes down and the peer is satisfied, it may be acceptable to just begin using the link. If so, when should this happen? Presumably, it would be when a timeout has occurred and the policy is satisfied. This problem is closely related to so-called "protected" indications discussed in section 4.2.1 (from resolved issue 49). Design team conversations have concluded that such method-specific indications cannot actually indicate the success/failure of the overall conversation, but just the method itself. Some of the text in 4.2.1 seems to contradict this paradigm. For example, [c] states, "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." I believe I understand the spirit of this text, but I am not sure it fits the current model- are such indications really "contradictory", or has the method just said things are going well and the authenticator decided otherwise? Note: I believe I could make an equally long-winded argument for saying this is all just implementation detail because I could implement EAP such that the methods DO know the end result and still fits the wire protocol. Thanks for reading all the way through. Comments welcome. nick From aboba@internaut.com Tue Feb 11 01:54:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 10 Feb 2003 17:54:30 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <15943.56798.850198.605679@gargle.gargle.HOWL> Message-ID: > The third case is in 2.2.2 -- "If the authenticator cannot > authenticate the peer (unacceptable Responses to one or more Requests) > then the implementation MUST transmit an EAP packet with the Code > field set to 4 (Failure)." It does say "one or more" -- implying that a single unacceptable Response may not be sufficient to cause transmission of a Failure. > I don't see this as being terribly different from what the peer is > required to do if the packets are completely malformed (what do you do > with a message whose Length exceeds the size of the actual data, or > with one that has a bad CRC?), nor different from what you do with > (for example) IP datagrams that have a bad header checksum at an > intermediate hop. You drop. Certainly if there is no authentication server, that is the case. With an authentication server there are checks that can't be done on the authenticator, only the authentication server. > Not necessarily. It implies that the protocol used to separate the > authentication server from the authenticator needs to convey the > MIC-related data from the authenticator to the authentication server. Well, it already does that, by encapsulating the EAP packet, and sending it to the authentication server, no? You'd need to do that anyway, in order to allow the authentication server to validate the MIC, since it is run over the packet. So one can think of the authenticator as sending the "MIC and associated data" (e.g. the packet) the authentication server for validation. If the authentication server validates the packet, it sends an Access-Challenge containing a new EAP Request. If not, it sends an Access-Challenge containing an EAP-Start. Does this reformulation somehow change the way the authenticator functions? From Internet-Drafts@ietf.org Tue Feb 11 11:44:06 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 11 Feb 2003 06:44:06 -0500 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-00.txt Message-ID: <200302111144.GAA28217@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-00.txt Pages : 0 Date : 2003-2-10 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-00.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-00.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-00.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-2-10132650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132650.I-D@ietf.org> --OtherAccess-- --NextPart-- From james.d.carlson@east.sun.com Tue Feb 11 12:08:57 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 11 Feb 2003 07:08:57 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: Bernard Aboba's message of 10 February 2003 17:54:30 References: <15943.56798.850198.605679@gargle.gargle.HOWL> Message-ID: <15944.59353.553684.99064@gargle.gargle.HOWL> Bernard Aboba writes: > > The third case is in 2.2.2 -- "If the authenticator cannot > > authenticate the peer (unacceptable Responses to one or more Requests) > > then the implementation MUST transmit an EAP packet with the Code > > field set to 4 (Failure)." > > It does say "one or more" -- implying that a single unacceptable Response > may not be sufficient to cause transmission of a Failure. That text cannot be referring to any sort of "duplicate but different Response," since there's no way for an authenticatee to send an unbidden Response message. Instead, that text is really referring to the retry-on-human-failure mechanism, as described in the very next sentence in section 2.2.2: [...] An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. > > I don't see this as being terribly different from what the peer is > > required to do if the packets are completely malformed (what do you do > > with a message whose Length exceeds the size of the actual data, or > > with one that has a bad CRC?), nor different from what you do with > > (for example) IP datagrams that have a bad header checksum at an > > intermediate hop. You drop. > > Certainly if there is no authentication server, that is the case. With an > authentication server there are checks that can't be done on the > authenticator, only the authentication server. Let's drop back to look at the linkage to the authentication server, since that's one of the gating items here, and let's assume that the EAP server is unable to validate the MIC. If you pass along this MIC-failing message, you're sending another Access-Request message to the server. The server then (based on the fact that the message is garbage) must either send Access-Challenge (and retry the authentication using a *NEW* EAP Request message) or send Access-Reject. The reply to the Access-Request itself triggers EAP into sending a new message. There's really no way for the access server to say "yeah, ok, I see your Access-Request message, but the contents are nonsense, so I'd like you to try sending another one a bit later when you've come to your senses." Note that, if you have a broken architecture that allows for the possibility of men-in-the-middle, your state is really quite trashed at this point. The DoS case is fairly obvious -- all the attacker needs to do is keep the authenticator busy with MIC-failing messages until the session dies. Thus, I claim that if MIC is a useful concept at all with EAP, then it MUST be checked at the EAP server, even if that's running in "pass- through" mode. The authenticator may check it as well if it likes, or apply some stronger or additional checks to it, but the EAP server must be involved to make the AAA linkage work right. (I'm not at all sure that MIC is a useful concept, because I think it's based on an assumption that breaks EAP -- a system that allows for something other than exactly two communicating peers on a link.) > > Not necessarily. It implies that the protocol used to separate the > > authentication server from the authenticator needs to convey the > > MIC-related data from the authenticator to the authentication server. > > Well, it already does that, by encapsulating the EAP packet, and sending > it to the authentication server, no? You'd need to do that anyway, in > order to allow the authentication server to validate the MIC, since it is run > over the packet. No -- I meant the other way around. The MIC validation key needs to be sent from the authenticator to the EAP server so that the EAP server can discard MIC-failing messages without attempting to issue new AAA requests for each one. > So one can think of the authenticator as sending the "MIC and associated > data" (e.g. the packet) the authentication server for validation. If the > authentication server validates the packet, it sends an Access-Challenge > containing a new EAP Request. If not, it sends an Access-Challenge > containing an EAP-Start. > > Does this reformulation somehow change the way the authenticator > functions? Yes, because it doesn't address the nature of MIC failure. MIC failure is not just a "bad access request" -- it's a spurious message that doesn't originate from the legitimate peer. It's really quite a different thing. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Tue Feb 11 18:20:08 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 13:20:08 -0500 Subject: [eap] Issue 73: Rewrite of Section 3.4/alternative indication In-Reply-To: References: Message-ID: <1054634.1044969608@[10.0.1.2]> The following is a discussion of the alternative indication issue, not yet a set of wording for the rfc. Before going to specific wording I would like to be sure we are all on the same page as far as what we want to happen. I would like to see the wording tied to L2 implemetation issues, and more EAP specific. It seems to me that EAP implementations have two ends, each of which is capable of determining whether to "enable" a link (or application). At the end of a sequence each end may decide independently whether to enable the link, and if both do not enable it, then the link will not work. The authenticator is the sole controller of this for most existing implementations, but 802.1x allows both ends to have such control. Other future implementations where mutual authentication/authorization is required will likely also support this ability of each end to "enable" its end of the link. When the peer determines it is "ok" to connect to the authenticator, it could enable its end of the connection. One reason NOT to do that would be if the authenticator has not completed its sequence of methods. In that case subsequent EAP methods might be sent out both the controlled and uncontrolled port (in 802.1x PAE model). I am not sure that this is bad, but it does get messages beyond the authenticator and so could be dangerous. A reason FOR permitting this would be to allow a link to be enabled in the face of loss of a EAP Success message. This would seem to be advantageous only if we expect high packet losses. I think that 802.11 may have higher loss rate than other media, and it is a primary target for EAP. I would be interested in comments on that. Both of the have some problems, so the alternative indication is introduced. If the peer is in a state where it would accept a "Success" (it is "ok" to connect to the authenticator) and it gets some link layer indication that the authenticator believes it has sent a Success and has turned on its controlled port (in 802.1x case), then the peer could take this as a "virtual Success" and enable the port. This would require the peer,s lower layer to recognize something from the controlled port on the authenticator and communicate it to the EAP layer. It is this recognition that is the "alternative" indication, and is probably different for different media layers. My suggestion is that the peer not enable the link until it gets either a Success or an "alternative indication" from the authenticator. Alternative indications are from the lower layer, but EAP must allow for them. -- Discussion? John --On Saturday, February 8, 2003 11:54 PM -0800 Bernard Aboba wrote: > Here is a partial solution to Issue 73, requiring a rewrite of Section > 3.4. Comments welcome. > > --------------------------------------------------------------------- > 3.4. Link layer indications > > The reliability and security of link layer indications is > dependent on the medium. Since EAP is media independent, > the presence or absence of link layer security is not > taken into account in the processing of EAP messages. > > Link layer failure indications provided to EAP by the link layer > MUST be processed and will cause an EAP exchange > in progress to be aborted. However, link layer success indications > MUST NOT affect EAP message processing so that an EAP implementation > MUST NOT conclude that authentication has succeeded based on those > indications. This ensures that an attacker spoofing link layer > indications can at best succeed in a denial of service attack. > > Below is a discussion of some of the reliability and security > issues with link layer indications in PPP, IEEE 802 wired > networks and IEEE 802.11 wireless LANs: > > [1] PPP. In PPP, link layer indications such as LCP-Terminate > (a link failure indication) and NCP (a link success indication) are > not authenticated or integrity protected. They can therefore be > spoofed by an attacker with access to the physical medium. > > [2] IEEE 802 wired networks. On wired networks, IEEE 802.1X > messages are sent to a non-forwardable multicast MAC address. > As a result, while the IEEE 802.1X EAPOL-Start and > EAPOL-Logoff frames are not authenticated or integrity protected, > only an attacker with access to the physical link can spoof these > messages. > > [3] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer > indications include Disassociate and Deauthenticate frames > (link failure indications), and Association > and Reassociation Response frames (link success indications). > These messages are not authenticated or integrity protected, > and although they are not forwardable, they are spoofable by > an attacker within range. > > In IEEE 802.11, IEEE 802.1X data frames are sent as Class 3 > unicast data frames, are therefore forwardable. This implies > that while EAPOL-Start and EAPOL-Logoff messages may be > authenticated and integrity protected, they can be spoofed > by an authenticated attacker far from the target > when "pre-authentication" is enabled. > > In IEEE 802.11 a "link down" indication is an unreliable > indication of link failure, since wireless signal strength > can come and go and may be influenced by radio frequency > interference generated by an attacker. To avoid unnecessary > resets, it is advisable to damp these indications, > rather than passing them directly to the EAP. Since EAP supports > retransmission, it is robust against transient connectivity losses. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Tue Feb 11 18:33:24 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 13:33:24 -0500 Subject: [eap] Re: Issue 78: More terminology In-Reply-To: References: Message-ID: <1102401.1044970404@[10.0.1.2]> --On Sunday, February 9, 2003 1:30 PM -0800 Bernard Aboba wrote: > The term "EAP server" was meant to be used to denote *either* the > authenticator (when local authentication is occurring) *or* the > authentication server (when authentication is occurring in pass-through > mode). I think of EAP server as the equivalent of the AS in 802.1x and not the same as the authenticator. This may be a confusion of models, but I think it helpful to keep the distinction. > > The phrase "supports EAP method exchanges" seems like it could apply to > *both* the authenticator and the authentication server. So I'm not sure > that this is really a clarification. > only if authenticator is also an AS, which I think it is not. > With respect to the definition of Silently Discard, this is the original > text from RFC 2284. The intent here is to define auditable events; it is > common practice in security specifications to make normative statements > about which events are auditable in order to ensure that implementations > keep appropriate logs, in order to be able to analyze attacks after the > fact. Therefore it would seem that making these recommendations > non-normative would decrease security. > If it is required for auditability, then I think some reference to the requirement would be helpful. If it is and implementation suggestion then I would think it should be noted as such. This is not a major problem either way for me. > ------------------------------------------------------- > Issue 78: More Terminology > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: Feburary 3, 2003 > Document: RFC2284bis-10 > Comment type: Technical > Priority: 1 > Section: 1.2 > Rationale/Explanation of issue: > > Item-a: EAP server description > Rationale: > The wording seems a bit confusing. > > Change: > > "EAP server > The entity that terminates the EAP authentication with the > peer. In the case where there is no backend authentication > server, this term refers to the authenticator. Where the > authenticator operates in pass-through, it refers to the > backend authentication server." > > To: > > "EAP server > The entity that supports EAP method exchanges with the > peer. This may be in the same device as the authenticator or > it may be a backend authetication server." > > ------------------------------ > Item-b: Silently discard description > Rationale: > Implementation suggestions should be marked as notes. Probably should not > be protocol SHOULDs > > Change: > > " Silently Discard > This means the implementation discards the packet without > further processing. The implementation SHOULD provide the > capability of logging the event, including the contents of > the silently discarded packet, and SHOULD record the event > in a statistics counter." > > to: > > " Silently Discard > This means the implementation discards the packet without > further processing. > [Note: Good practice indicates that implementations should > provide the capability of logging the event, including the > contents of the silently discarded packet, and should record > the event in a statistics counter." > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Feb 11 17:23:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 09:23:59 -0800 (PST) Subject: [eap] Re: [Issue 80] Success Indications Message-ID: With respect to the "alternative indications" of RFC 2284, the implementation survey we did about 18 months ago indicated that noone implemented alternative link indications of success (thankfully). So I also feel quite comfortable with prohibiting this in Section 3.4. The issue here I think relates to sequences. If sequences were to be prohibited (MUST NOT), then it seems to me that a protected success indication would be enough to transition to the Success state. But if a sequence is possible, then the peer could receive a Request for another method after the first one was done. On the other hand, I do believe that a protected failure indication is enough to transition to the Failure state. I do not want to leave the interpretation of failure up to "policy" -- that seems like an invitation to interoperability problems. Assuming that the peer has been told via a protected indication that authentication has failed, then an EAP Success is unexpected. The part that is trickier is handling of Failure messages. Just because a method has succeeded doesn't mean that the conversation succeeds. So I don't know if it makes sense for a peer to believe that a Failure message is unexpected in that circumstance. --------------------------------------------------------------------------- Issue 80: Success Indications Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: February 10, 2003 Document: EAP-00 Comment type: Technical Priority: S Section: 4.2.1 Rationale/Explanation of issue: I am requesting some comments/clarification on the topic of when the success state can be reached by the peer. Executive summary: ----------------- 1. Is a satisfied policy enough for a peer transition to the success state, or is a SUCCESS packet required? 2. Is the text in 4.2.1 contradicting the current EAP model, or do I have an incorrect understanding of the model? (these are not mutually exclusive) Full explanation: ---------------- Through conversation with the state machine design team, I have come to question the conditions for success of an EAP conversation. All parties seem to agree that a satisfied policy is necessary for the peer to begin using the link, but the question is whether or not the condition is sufficient. That is, if a SUCCESS message never comes, can the peer transition to the SUCCESS state? The "alternate indications" of RFC2284 seem to imply that it can, however, section 3.4 of 2284bis explicitly warns against accepting link-layer indications (and for good reason). Since SUCCESS messages are neither acknowledged nor retransmitted, it is possible that SUCCESS messages could be lost causing an unneeded timeout. Assuming the link never goes down and the peer is satisfied, it may be acceptable to just begin using the link. If so, when should this happen? Presumably, it would be when a timeout has occurred and the policy is satisfied. This problem is closely related to so-called "protected" indications discussed in section 4.2.1 (from resolved issue 49). Design team conversations have concluded that such method-specific indications cannot actually indicate the success/failure of the overall conversation, but just the method itself. Some of the text in 4.2.1 seems to contradict this paradigm. For example, [c] states, "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." I believe I understand the spirit of this text, but I am not sure it fits the current model- are such indications really "contradictory", or has the method just said things are going well and the authenticator decided otherwise? Note: I believe I could make an equally long-winded argument for saying this is all just implementation detail because I could implement EAP such that the methods DO know the end result and still fits the wire protocol. Thanks for reading all the way through. Comments welcome. nick From aboba@internaut.com Tue Feb 11 17:27:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 09:27:15 -0800 (PST) Subject: [eap] Re: Issue 78: More terminology In-Reply-To: <1102401.1044970404@[10.0.1.2]> Message-ID: > I think of EAP server as the equivalent of the AS in 802.1x and not the > same as the authenticator. This may be a confusion of models, but I think > it helpful to keep the distinction. However, that is not how the term is used in RFC 2869, or in RFC 2284bis. The reason a new term was needed was to avoid having to constantly say "the authenticator if not in pass-through mode or the authentication server if in pass-through mode". > only if authenticator is also an AS, which I think it is not. The term as used can apply in either case. > If it is required for auditability, then I think some reference to the > requirement would be helpful. If it is and implementation suggestion then > I would think it should be noted as such. This is not a major problem > either way for me. Overall, the spec is not clear what events are auditable or not. We should probably use the term "auditable event" to refer to those things that we want to keep records of. From jrv@umich.edu Tue Feb 11 18:56:05 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 13:56:05 -0500 Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: References: Message-ID: <1183982.1044971763@[10.0.1.2]> I think this looks very good. I have a couple questions inline. --On Sunday, February 9, 2003 3:04 PM -0800 Bernard Aboba wrote: > I believe that discussion on Issue 74 has exposed a mistake in the > handling of Responses in Section 4.1 Request and Response. With this > mistake corrected, I believe that the resolution of this issue becomes > more apparent. As a result, I would like to propose a rewrite of the > Description text as follows: > > ----------------------------------- > 4.1 Request and Response > > Description > > The Request packet (Code field set to 1) is sent by the > authenticator to the peer. Each Request has a Type field which > serves to indicate what is being requested. Additional Request > packets MUST be sent until a valid Response packet is received, > or an optional retry counter expires. In [IEEE8021X], the retry > counter is effectively set to zero, so that retransmission never > occurs, and instead the peer times out and authentication is > restarted. > > Retransmitted Requests MUST be sent with the same Identifier value in > order to distinguish them from new Requests. The contents of the data > field is dependent on the Request type. The peer MUST send a > Response packet in reply to a valid Request packet. Responses MUST > only be sent in reply to a valid Request and never retransmitted on a > timer. > presumably the peer only has to send one response if it gets a retransmitted request before it responds to the original. > The Identifier field of the Response MUST match that of the > Request. An authenticator receiving a Response whose Identifier > value does not match that of the currently outstanding Request > MUST silently discard the Response. The Type field of a Response > MUST either match that of the Request, or correspond to a legacy > or expanded Nak (see Section 5.3). An EAP server receiving a Response > packet with an invalid Type field MUST silently discard > the Response. > > The authenticator MUST NOT send a new Request until a valid Response > is received to an outstanding Request. Since the authenticator can > retransmit before receiving a valid Response from the peer, the > authenticator can receive duplicate Responses. > > If a Message Integrity Check (MIC) is employed within an EAP method, > then peer and EAP server implementations MUST silently discard any > message that fails this check. In this document, the descriptions > of EAP message handling assume that MIC validation is effectively > performed as though it occurs before examining any of the EAP > message fields (such as 'Code'). > > Implementation Note: The authenticator is responsible for > retransmitting Request messages. If the Request message is > obtained from elsewhere (such as from a backend authentication > server), then the authenticator will need to save a copy of the > Request in order to accomplish this. The authenticator is also > responsible for discarding Response messages with a non-matching > Identifier value before acting on them in any way, including > passing them on to the backend authentication server for > verification. However, if an authenticator receives multiple > Responses, each with a matching Identifier, then it will pass > each of them on to the backend authentication server. Does it HAVE to pass them all, or only till it gets a "new" request? Sending all might be pretty hard to do with RADIUS, > Similarly, the peer is responsible for detecting and > handling duplicate Request messages before processing them in any > way, including passing them on to an outside party. > the peer checks for duplicates - but only those that arrive before it sends a response. > Because the authentication process will often involve user input, > some care must be taken when deciding upon retransmission > strategies and authentication timeouts. By default, where EAP is > run over an unreliable lower layer, the EAP retransmission timer > SHOULD be computed as described in [RFC2988]. This > includes use of Karn's algorithm to filter RTT estimates resulting > from retransmissions. A maximum of 3-5 retransmissions is > suggested. > > When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as > within [PIC]), the authenticator retransmission timer SHOULD be set > to an infinite value, so that retransmissions do not occur at the EAP > layer. Note that in this case the peer may still maintain a > timeout value so as to avoid waiting indefinitely for a Request. > > Where the authentication process requires user input, the measured > round trip times are largely be determined by user responsiveness > rather than network characteristics, so that RTO estimation is not > helpful. Instead, the retransmission timers SHOULD be set so as > to provide sufficient time for the user to respond, with longer > timeouts required in certain cases, such as where Token Cards are > involved. > > In order to provide the EAP authenticator with guidance as to the > appropriate timeout value, a hint can be communicated to the > authenticator by the backend authentication server (such as via > the RADIUS Session-Timeout attribute). > is this a standard use of Session-Timeout? Is resending an EAP Request the same as restarting RADIUS? > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Feb 11 17:50:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 09:50:14 -0800 (PST) Subject: [eap] Re: Issue 74: Concern on invalid MIC In-Reply-To: <1183982.1044971763@[10.0.1.2]> Message-ID: > presumably the peer only has to send one response if it gets a > retransmitted request before it responds to the original. Yes, I think that's handled in language relating to the peer. > Does it HAVE to pass them all, or only till it gets a "new" request? > Sending all might be pretty hard to do with RADIUS, I think only until it gets a "new" Request. Is this stated clearly enough? > the peer checks for duplicates - but only those that arrive before it sends > a response. Yes. Does this section make that clear enough? If not, any ideas on how to improve it? > > appropriate timeout value, a hint can be communicated to the > > authenticator by the backend authentication server (such as via > > the RADIUS Session-Timeout attribute). > > > is this a standard use of Session-Timeout? Is resending an EAP Request the > same as restarting RADIUS? It's a use that was defined in RFC 2869. It's just an EAP retransmission timeout, so it doesn't cause any RADIUS traffic until the Response arrives. From jrv@umich.edu Tue Feb 11 19:06:20 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 14:06:20 -0500 Subject: [eap] Yet more on Issue 74 In-Reply-To: References: Message-ID: <1220880.1044972378@[10.0.1.2]> This sounds good to me. --On Sunday, February 9, 2003 4:46 PM -0800 Bernard Aboba wrote: > Here is the text I would propose to add to RFC 2869bis to complete the > proposed fix of Issue 74: > > 2.5. Invalid packets > > EAP methods may contain a per-packet Message Integrity Check (MIC). > Although EAP methods such as EAP-TLS [RFC2716] treat MIC check failures > as fatal errors, it may be desirable for an EAP method to silently > discard an invalid EAP packet, and subsequently continue the > conversation. This provides additional resilience against Denial of > Service (DoS) attacks. > > When a RADIUS server receives an Access-Request containing an EAP- > Message attribute encapsulating an invalid EAP packet, it SHOULD NOT > silently discard the Access-Request without informing the NAS. This > would cause the NAS to retransmit the Access-Request, then eventually > time-out and initiate failover. As a result, it is best for the RADIUS > server to formulate a response of some kind. > > If the error is considered fatal, an Access-Reject can be sent. In > order for the RADIUS server to communicate that an invalid EAP packet > has been received, but that the problem is non-fatal, an Access- > Challenge containing an EAP-Start MAY be sent. A NAS receiving an > Access-Challenge with an EAP-Start MUST discard the EAP packet that it > had previously encapsulated within an Access-Request. It will then check > whether it has received additional EAP Response packets with an > Identifier matching that of the last Request. If so, a new EAP Response > packet will be sent to the RADIUS server within an Access-Request > packet. 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. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Feb 11 17:57:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 09:57:30 -0800 (PST) Subject: [eap] Re: Issue 78: More terminology In-Reply-To: <1102401.1044970404@[10.0.1.2]> Message-ID: I would propose to open a new Issue 81: Auditable Events to address your concern about the lack of clarity in audit requirements. I think this will require going through the document to understand what events we want to be auditable and which ones are auditable as the document is written today. > If it is required for auditability, then I think some reference to the > requirement would be helpful. If it is and implementation suggestion then > I would think it should be noted as such. This is not a major problem > either way for me. From jrv@umich.edu Tue Feb 11 19:27:24 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 14:27:24 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <15944.59353.553684.99064@gargle.gargle.HOWL> References: <15943.56798.850198.605679@gargle.gargle.HOWL> <15944.59353.553684.99064@gargle.gargle.HOWL> Message-ID: <1296796.1044973644@[10.0.1.2]> If I understand this conversation I believe the issue that James is raising is that trying to do DOS mitigation on a protocol that was not designed for that is of highly questionable value. The original idea was that we are worried about DOS attacks, so we should attempt to allow the protocol to succeed in the face of them. This leads to some fairly complicated schemes which keep a particular authentication sequence in the face of "injected" messages. The end result is that the DOS attack is more successful since it can last longer. It would be better to restart the authentication and get it right than try to find the needle in the haystack of attacking trash. I find this argument to be quite persuasive. --On Tuesday, February 11, 2003 7:08 AM -0500 James Carlson wrote: > Bernard Aboba writes: > > > The third case is in 2.2.2 -- "If the authenticator cannot > > > authenticate the peer (unacceptable Responses to one or more Requests) > > > then the implementation MUST transmit an EAP packet with the Code > > > field set to 4 (Failure)." > > > > It does say "one or more" -- implying that a single unacceptable > > Response may not be sufficient to cause transmission of a Failure. > > That text cannot be referring to any sort of "duplicate but different > Response," since there's no way for an authenticatee to send an > unbidden Response message. Instead, that text is really referring to > the retry-on-human-failure mechanism, as described in the very next > sentence in section 2.2.2: > > [...] An > authenticator MAY wish to issue multiple Requests before sending a > Failure response in order to allow for human typing mistakes. > > > > I don't see this as being terribly different from what the peer is > > > required to do if the packets are completely malformed (what do you do > > > with a message whose Length exceeds the size of the actual data, or > > > with one that has a bad CRC?), nor different from what you do with > > > (for example) IP datagrams that have a bad header checksum at an > > > intermediate hop. You drop. > > > > Certainly if there is no authentication server, that is the case. With > > an authentication server there are checks that can't be done on the > > authenticator, only the authentication server. > > Let's drop back to look at the linkage to the authentication server, > since that's one of the gating items here, and let's assume that the > EAP server is unable to validate the MIC. > > If you pass along this MIC-failing message, you're sending another > Access-Request message to the server. The server then (based on the > fact that the message is garbage) must either send Access-Challenge > (and retry the authentication using a *NEW* EAP Request message) or > send Access-Reject. > > The reply to the Access-Request itself triggers EAP into sending a new > message. There's really no way for the access server to say "yeah, > ok, I see your Access-Request message, but the contents are nonsense, > so I'd like you to try sending another one a bit later when you've > come to your senses." > > Note that, if you have a broken architecture that allows for the > possibility of men-in-the-middle, your state is really quite trashed > at this point. The DoS case is fairly obvious -- all the attacker > needs to do is keep the authenticator busy with MIC-failing messages > until the session dies. > > Thus, I claim that if MIC is a useful concept at all with EAP, then it > MUST be checked at the EAP server, even if that's running in "pass- > through" mode. The authenticator may check it as well if it likes, or > apply some stronger or additional checks to it, but the EAP server > must be involved to make the AAA linkage work right. > > (I'm not at all sure that MIC is a useful concept, because I think > it's based on an assumption that breaks EAP -- a system that allows > for something other than exactly two communicating peers on a link.) > > > > Not necessarily. It implies that the protocol used to separate the > > > authentication server from the authenticator needs to convey the > > > MIC-related data from the authenticator to the authentication server. > > > > Well, it already does that, by encapsulating the EAP packet, and sending > > it to the authentication server, no? You'd need to do that anyway, in > > order to allow the authentication server to validate the MIC, since it > > is run over the packet. > > No -- I meant the other way around. The MIC validation key needs to > be sent from the authenticator to the EAP server so that the EAP > server can discard MIC-failing messages without attempting to issue > new AAA requests for each one. > > > So one can think of the authenticator as sending the "MIC and associated > > data" (e.g. the packet) the authentication server for validation. If the > > authentication server validates the packet, it sends an Access-Challenge > > containing a new EAP Request. If not, it sends an Access-Challenge > > containing an EAP-Start. > > > > Does this reformulation somehow change the way the authenticator > > functions? > > Yes, because it doesn't address the nature of MIC failure. MIC > failure is not just a "bad access request" -- it's a spurious message > that doesn't originate from the legitimate peer. It's really quite a > different thing. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From yohba@tari.toshiba.com Tue Feb 11 19:36:25 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 11 Feb 2003 14:36:25 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: References: <15943.47577.643241.307015@gargle.gargle.HOWL> Message-ID: <20030211193625.GE1645@catfish> On Mon, Feb 10, 2003 at 05:54:49AM -0800, Bernard Aboba wrote: > > One way to judge the vulnerability to DoS is to look at the ratio of > cycles required for the attack versus those consumed on the target. > Checking a MIC is a relatively lightweight operation compared to say, a > public key operation which will often occur early in the method. So it is > actually less expensive for the method to check the MIC and silently > discard than it is to fail authentication, and presumably have to do the > entire method over again, including the public key operations. That is true in one side. On the other hand, checking a MIC is a relatively heavyweight operation compared to flooding the copies of the same packet with broken MIC. So I think the proposed solution will introduce another DoS. That's why I indicated earlier that "this is next choice". The perfect solution is running EAP over secure lower-layer. It is getting clear that EAP has some limitation when it runs over insecure lower-layer. > > That means that failure is not a more secure approach, and more > advanced protocols almost always prefer silent discard. Look at IKE > (silent discard) vs. TLS (MIC as fatal error); AES CCMP (silent discard) > vs. TKIP (counter-measures). > IMHO, the behavior in the errornous event depends on the characteristics of the underlying transport the protection mechanism runs. TLS treats MIC error as fatal because it is assumed to run over reliable transport. The current discussion seems to be based on the assumption that EAP always runs over unreliable transport. But the assumption does not always hold. BTW, RFC 2828 does not recommend the term "message integrity check": $ message integrity check $ message integrity code (D) ISDs SHOULD NOT use these terms because they mix concepts in a potentially misleading way. (The word "message" is misleading because it suggests that the mechanism is particularly suitable for or limited to electronic mail. The word "code" is misleading because it suggests that either encoding or encryption is involved, or that the term refers to computer software.) Instead, use "checksum", "error detection code", "hash", "keyed hash", "Message Authentication Code", or "protected checksum", depending on what is meant. Yoshihiro Ohba From aboba@internaut.com Tue Feb 11 18:34:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 10:34:20 -0800 (PST) Subject: [eap] Re: Issue 80, Success Indications In-Reply-To: <20030211191102.18435.42240.Mailman@wolverine> Message-ID: > When the peer determines it is "ok" to connect to the authenticator, it > could enable its end of the connection. One reason NOT to do that would be > if the authenticator has not completed its sequence of methods. Assuming we allow sequences, the peer can't know this until a Success or Failure is sent, no? > case subsequent EAP methods might be sent out both the controlled and > uncontrolled port (in 802.1x PAE model). Does IEEE 802.1aa now support this? > A reason FOR permitting this would be to allow a link to be enabled in the > face of loss of a EAP Success message. This would seem to be advantageous > only if we expect high packet losses. I think that 802.11 may have higher > loss rate than other media, and it is a primary target for EAP. IEEE 802.11 does include its own retransmission support. But of course a STA can wander out of range. > Both of the have some problems, so the alternative indication is > introduced. If the peer is in a state where it would accept a "Success" (it > is "ok" to connect to the authenticator) and it gets some link layer > indication that the authenticator believes it has sent a Success and has > turned on its controlled port (in 802.1x case), then the peer could take > this as a "virtual Success" and enable the port. The problem is defining what this "success" state would be on the peer. With sequences, even if all methods up to that point had concluded successfully, the peer cannot conclude that authentication has been successful. As a result, while I believe that the peer can enter a "failure" state based on method outcomes alone, I am not sure that it can enter a "success" state that way. > It is this recognition > that is the "alternative" indication, and is probably different for > different media layers. Yes, those indications are now discussion in Section 7.12. The problem of course is that most of them are unprotected. > My suggestion is that the peer not enable the link until it gets either a > Success or an "alternative indication" from the authenticator. Alternative > indications are from the lower layer, but EAP must allow for them. -- > Discussion? So far, section 3.4 enables link layer failure indications to be acted upon, but not link layer success indications. Your requirement that the peer be in a "success" state before acting on them makes it a bit more palatable to consider acting on these alternative success indications. The problem I think comes in defining exactly what they are, and also in determining whether such a "success" state can exist prior to receiving an EAP Success. If Sequences were prohibited, I would feel more comfortable talking about this, because then method Success = EAP success. From npetroni@cs.umd.edu Tue Feb 11 19:46:58 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Tue, 11 Feb 2003 14:46:58 -0500 (EST) Subject: [eap] Re: [Issue 80] Success Indications In-Reply-To: Message-ID: > With respect to the "alternative indications" of RFC 2284, the > implementation survey we did about 18 months ago indicated that noone > implemented alternative link indications of success (thankfully). So I > also feel quite comfortable with prohibiting this in Section 3.4. I agree. > On the other hand, I do believe that a protected failure indication is > enough to transition to the Failure state. I do not want to leave the > interpretation of failure up to "policy" -- that seems like an invitation > to interoperability problems. Assuming that the peer has been told via a > protected indication that authentication has failed, then an EAP Success > is unexpected. Couldn't this exact situation result from a configuration problem though? For example, assume a particular authenticator is configured to allow either method A or method B (each of which is on a different back-end server), which are both very secure and trusted. Also, assume that for some reason (maybe A is just more efficient?) they always try A first. If the peer has something misconfigured for method A (e.g. old or corrupted certificate), but has method B configured correctly, failing A would result in never doing method B, even though the policy would then be satisfied. Perhaps this is a bit contrived, but it seems possible nevertheless. > The part that is trickier is handling of Failure messages. Just because a > method has succeeded doesn't mean that the conversation succeeds. So I > don't know if it makes sense for a peer to believe that a Failure message > is unexpected in that circumstance. I agree. Furthermore, I am having trouble right now determining if there is ever a time Failure could be ignored. From aboba@internaut.com Tue Feb 11 18:46:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 10:46:58 -0800 (PST) Subject: [eap] Re: [Issue 80] Success Indications In-Reply-To: Message-ID: > Couldn't this exact situation result from a configuration problem though? > For example, assume a particular authenticator is configured to allow > either method A or method B (each of which is on a different back-end > server), which are both very secure and trusted. Also, > assume that for some reason (maybe A is just more efficient?) they always > try A first. If the peer has something misconfigured for method A (e.g. > old or corrupted certificate), but has method B configured correctly, > failing A would result in never doing method B, even though the policy > would then be satisfied. Perhaps this is a bit contrived, but it seems > possible nevertheless. Yes, that could be the result. But that is why RFC 2284, Security Considerations says: In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user 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. > > The part that is trickier is handling of Failure messages. Just because a > > method has succeeded doesn't mean that the conversation succeeds. So I > > don't know if it makes sense for a peer to believe that a Failure message > > is unexpected in that circumstance. > I agree. Furthermore, I am having trouble right now determining if there > is ever a time Failure could be ignored. I'm not sure there is -- unless sequences are prohibited. From npetroni@cs.umd.edu Tue Feb 11 20:11:35 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Tue, 11 Feb 2003 15:11:35 -0500 (EST) Subject: [eap] Re: [Issue 80] Success Indications In-Reply-To: Message-ID: > In practice, within or associated with each PPP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set (such as PAP > rather than EAP). Instead, for each named user there should be an > indication of exactly one method used to authenticate that user name. > If a user 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. I am reading this as a PPP recommendation, not an EAP recommendation. In fact, it refers to EAP as one of the methods. I don't read this text as talking about EAP Methods, just PPP auth methods. Of course, I have no experience with PPP so this may not make sense. I am not sure I see how one could "negotiate down" in the situation I presented. Assuming a correct policy, I don't see the harm in allowing method negotiaton (in fact, a Naks allows this anyway). From yohba@tari.toshiba.com Tue Feb 11 22:19:05 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 11 Feb 2003 17:19:05 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <1296796.1044973644@[10.0.1.2]> References: <15943.56798.850198.605679@gargle.gargle.HOWL> <15944.59353.553684.99064@gargle.gargle.HOWL> <1296796.1044973644@[10.0.1.2]> Message-ID: <20030211221905.GL1645@catfish> On Tue, Feb 11, 2003 at 02:27:24PM -0500, John Vollbrecht wrote: > If I understand this conversation I believe the issue that James is raising > is that trying to do DOS mitigation on a protocol that was not designed for > that is of highly questionable value. > > The original idea was that we are worried about DOS attacks, so we should > attempt to allow the protocol to succeed in the face of them. This leads > to some fairly complicated schemes which keep a particular authentication > sequence in the face of "injected" messages. The end result is that the > DOS attack is more successful since it can last longer. It would be better > to restart the authentication and get it right than try to find the needle > in the haystack of attacking trash. Is it really better? The problem is that once a needle is there, it is highly possible that the needle is found again after restarting the authentication... > > I find this argument to be quite persuasive. > > Yoshihiro Ohba From jari.arkko@piuha.net Tue Feb 11 22:25:02 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 12 Feb 2003 00:25:02 +0200 Subject: [eap] Yet more on Issue 74 References: <1220880.1044972378@[10.0.1.2]> Message-ID: <3E49783E.3010703@piuha.net> John Vollbrecht wrote: > This sounds good to me. I like it as well. Jari From jari.arkko@piuha.net Tue Feb 11 22:29:21 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 12 Feb 2003 00:29:21 +0200 Subject: [eap] Implementer Survey: Duplicate detection in pass-through References: Message-ID: <3E497941.9020601@piuha.net> Bernard Aboba wrote: > And yes, the authenticator knows that the currently valid Identifier is, > regardless of the mode. The question is the precise moment at which that > Identifier value *changes*. The claim is that when the authenticator isn't > in pass-through, that moment occurs when it receives a valid Response, > with validity including *all* checks made on the packet (including a MIC). > If the packet fails any of the validity checks, it is silently discarded > as if it was never sent. In this case that would mean that the > Identifier doesn't change and the authenticator will retransmit the > Request. > > When the authenticator operates in pass-through, the claim is that the > Identifier doesn't change until a valid Request is received from the > authentication server. Yes. If we don't do this, then I worry about making the protocol behave in different ways towards the peer, depending on whether there's a pass-through or not. If we are directly authenticating then we wait until we get a packet that is good in all aspects. If there's a pass-through in the middle then we only wait until we get a packet that passes the EAP level tests -- identifier values and so on. I'm not sure this brings any specific problems to us, but I'd rather avoid if possible. This would indicate that we should either search for a solution that tries to provide the same functionality in both cases, or try to avoid "survivable" tests at the method layer. Jari From aboba@internaut.com Tue Feb 11 21:49:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 13:49:09 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <3E497941.9020601@piuha.net> Message-ID: > If there's a pass-through in the middle then we only wait until > we get a packet that passes the EAP level tests -- identifier > values and so on. The question is whether that "packet" is a Response or a Request. > I'm not sure this brings any specific problems to us, but > I'd rather avoid if possible. This would indicate that > we should either search for a solution that tries to > provide the same functionality in both cases, or try to avoid > "survivable" tests at the method layer. I believe that waiting for the Request provides some uniformity in both cases. From jrv@umich.edu Tue Feb 11 23:19:54 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 18:19:54 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <20030211221905.GL1645@catfish> References: <15943.56798.850198.605679@gargle.gargle.HOWL> <15944.59353.553684.99064@gargle.gargle.HOWL> <1296796.1044973644@[10.0.1.2]> <20030211221905.GL1645@catfish> Message-ID: <1913743.1044987594@[10.0.1.2]> --On Tuesday, February 11, 2003 5:19 PM -0500 Yoshihiro Ohba wrote: > On Tue, Feb 11, 2003 at 02:27:24PM -0500, John Vollbrecht wrote: > > If I understand this conversation I believe the issue that James is > > raising is that trying to do DOS mitigation on a protocol that was not > > designed for that is of highly questionable value. > > > > The original idea was that we are worried about DOS attacks, so we > > should attempt to allow the protocol to succeed in the face of them. > > This leads to some fairly complicated schemes which keep a particular > > authentication sequence in the face of "injected" messages. The end > > result is that the DOS attack is more successful since it can last > > longer. It would be better to restart the authentication and get it > > right than try to find the needle in the haystack of attacking trash. > > Is it really better? The problem is that once a needle is there, it > is highly possible that the needle is found again after restarting the > authentication... > I am not clear what you mean here. In my mind the needle would be the one good message in a haystack of DOS attacks. Of course it could be one bad message in a haystack of good messages. I am thinking that restarting the authentication is better in both cases. If it is a massive DOS attack restarting takes longer and gives less opportunity to use resources. If it is a single bad message restarting once may be simpler and not significantly more expensive. I think either could be made to work - but without a strong motivation for something more complex, I think simple is better. > > > > I find this argument to be quite persuasive. > > > > > > Yoshihiro Ohba From jrv@umich.edu Tue Feb 11 23:53:13 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 18:53:13 -0500 Subject: [eap] Re: Issue 80, Success Indications In-Reply-To: References: Message-ID: <2033657.1044989593@[10.0.1.2]> --On Tuesday, February 11, 2003 10:34 AM -0800 Bernard Aboba wrote: > > When the peer determines it is "ok" to connect to the authenticator, it > > could enable its end of the connection. One reason NOT to do that > > would be if the authenticator has not completed its sequence of methods. > > Assuming we allow sequences, the peer can't know this until a Success or > Failure is sent, no? I think the peer can know if it would enable the link if it recieved a Success at that instant. This may or may not be enough -- but I think it is - because the peer will have some minimum requirement for content of sequence. Once it is satisfied, it is the authenticatior that will also have to be satisfied, and perhaps determine QoS or other information with additional sequences. If the sequences don't happen, the default values would be applied. Comments? > > > case subsequent EAP methods might be sent out both the controlled and > > uncontrolled port (in 802.1x PAE model). > > Does IEEE 802.1aa now support this? I am not sure what you mean support this. Both ends are PAEs and each have controlled and uncontrolled ports - at least in principal. Not all applications support this. In the current state machine I believe the peer/supplicant will just not go to authenticated state. The point is that each end determines whether to enable its end. The success/failure indicates to the peer that the authenticator thinks it succeeded or failed. Certainly if it thinks it succeeded and the peer thinks it failed, the peer will not enable to link. If the peer thinks it succeeded and the authenticator sends a Failure, then it doesn't really matter what the peer does because the authenticator will not enable the link. > > > A reason FOR permitting this would be to allow a link to be enabled in > > the face of loss of a EAP Success message. This would seem to be > > advantageous only if we expect high packet losses. I think that 802.11 > > may have higher loss rate than other media, and it is a primary target > > for EAP. > > IEEE 802.11 does include its own retransmission support. But of course a > STA can wander out of range. > > > Both of the have some problems, so the alternative indication is > > introduced. If the peer is in a state where it would accept a "Success" > > (it is "ok" to connect to the authenticator) and it gets some link layer > > indication that the authenticator believes it has sent a Success and has > > turned on its controlled port (in 802.1x case), then the peer could take > > this as a "virtual Success" and enable the port. > > The problem is defining what this "success" state would be on the peer. > With sequences, even if all methods up to that point had concluded > successfully, the peer cannot conclude that authentication has been > successful. As a result, while I believe that the peer can enter a > "failure" state based on method outcomes alone, I am not sure that it can > enter a "success" state that way. > > > It is this recognition > > that is the "alternative" indication, and is probably different for > > different media layers. > > Yes, those indications are now discussion in Section 7.12. The problem of > course is that most of them are unprotected. > I am not sure why protection is an issue here? If a Success can be faked (and since it is not protected it certainly can) why would a lower layer indication worse? > > My suggestion is that the peer not enable the link until it gets either > > a Success or an "alternative indication" from the authenticator. > > Alternative indications are from the lower layer, but EAP must allow > > for them. -- Discussion? > > So far, section 3.4 enables link layer failure indications to be acted > upon, but not link layer success indications. Your requirement that the > peer be in a "success" state before acting on them makes it a bit more > palatable to consider acting on these alternative success indications. > > The problem I think comes in defining exactly what they are, and also in > determining whether such a "success" state can exist prior to receiving an > EAP Success. If Sequences were prohibited, I would feel more comfortable > talking about this, because then method Success = EAP success. > My contention is that an alternative indication and a Success could be equivalent in the state machine. If I can handle a success in a sequence, I can handle an alternative indication. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From yohba@tari.toshiba.com Tue Feb 11 23:58:51 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 11 Feb 2003 18:58:51 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <1913743.1044987594@[10.0.1.2]> References: <15943.56798.850198.605679@gargle.gargle.HOWL> <15944.59353.553684.99064@gargle.gargle.HOWL> <1296796.1044973644@[10.0.1.2]> <20030211221905.GL1645@catfish> <1913743.1044987594@[10.0.1.2]> Message-ID: <20030211235851.GA2333@catfish> On Tue, Feb 11, 2003 at 06:19:54PM -0500, John Vollbrecht wrote: > >Is it really better? The problem is that once a needle is there, it > >is highly possible that the needle is found again after restarting the > >authentication... > > > I am not clear what you mean here. In my mind the needle would be the one > good message in a haystack of DOS attacks. Of course it could be one bad > message in a haystack of good messages. I meant latter, but it does not really matter which is the needle or haystack. > > I am thinking that restarting the authentication is better in both cases. It seems that if restarting the authentication is needed, it means that the simple DoS attack succeeds. Nothing good for users. > If it is a massive DOS attack restarting takes longer and gives less > opportunity to use resources. If it is a single bad message restarting > once may be simpler and not significantly more expensive. > > I think either could be made to work - but without a strong motivation for > something more complex, I think simple is better. > Yoshihiro Ohba From npetroni@cs.umd.edu Wed Feb 12 00:23:11 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Tue, 11 Feb 2003 19:23:11 -0500 (EST) Subject: [eap] Re: Issue 80, Success Indications In-Reply-To: <2033657.1044989593@[10.0.1.2]> Message-ID: > > Assuming we allow sequences, the peer can't know this until a Success or > > Failure is sent, no? > I think the peer can know if it would enable the link if it recieved a > Success at that instant. This may or may not be enough -- but I think it > is - because the peer will have some minimum requirement for content of > sequence. Once it is satisfied, it is the authenticatior that will also > have to be satisfied, and perhaps determine QoS or other information with > additional sequences. If the sequences don't happen, the default values > would be applied. Comments? By if it doesn't happen, do you mean if it times out and hasn't received another request (or Success)? What is the actual even that leads to the success state? once you are there, presumably you won't be handling more requests. > I am not sure why protection is an issue here? If a Success can be faked > (and since it is not protected it certainly can) why would a lower layer > indication worse? > My contention is that an alternative indication and a Success could be > equivalent in the state machine. If I can handle a success in a sequence, > I can handle an alternative indication. I think I agree with these two points. Is there a case when you could fake a lower-layer indication and not a Success? From jrv@umich.edu Wed Feb 12 02:41:12 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 21:41:12 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <3E497941.9020601@piuha.net> References: <3E497941.9020601@piuha.net> Message-ID: <2209440.1044999672@[10.0.1.2]> --On Wednesday, February 12, 2003 12:29 AM +0200 Jari Arkko wrote: > Bernard Aboba wrote: > > > And yes, the authenticator knows that the currently valid Identifier is, > > regardless of the mode. The question is the precise moment at which that > > Identifier value *changes*. The claim is that when the authenticator > > isn't in pass-through, that moment occurs when it receives a valid > > Response, with validity including *all* checks made on the packet > > (including a MIC). If the packet fails any of the validity checks, it > > is silently discarded as if it was never sent. In this case that would > > mean that the > > Identifier doesn't change and the authenticator will retransmit the > > Request. > > > > When the authenticator operates in pass-through, the claim is that the > > Identifier doesn't change until a valid Request is received from the > > authentication server. > > Yes. If we don't do this, then I worry about making the protocol > behave in different ways towards the peer, depending on whether > there's a pass-through or not. If we are directly authenticating > then we wait until we get a packet that is good in all aspects. > If there's a pass-through in the middle then we only wait until > we get a packet that passes the EAP level tests -- identifier > values and so on. I think that if we wait for a good request from the authentication server then the packet the authentication server is responding to is good in all respects. Therefore it seems to me the cases are identical whether acting in pass through or not. > > I'm not sure this brings any specific problems to us, but > I'd rather avoid if possible. This would indicate that > we should either search for a solution that tries to > provide the same functionality in both cases, or try to avoid > "survivable" tests at the method layer. > > Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Wed Feb 12 02:50:39 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Feb 2003 21:50:39 -0500 Subject: [eap] Re: Issue 80, Success Indications In-Reply-To: References: Message-ID: <2243461.1045000239@[10.0.1.2]> These are hard conversations to have without pictures. :) --On Tuesday, February 11, 2003 7:23 PM -0500 Nick Petroni wrote: > > > Assuming we allow sequences, the peer can't know this until a Success > > > or Failure is sent, no? > > I think the peer can know if it would enable the link if it recieved a > > Success at that instant. This may or may not be enough -- but I think > > it is - because the peer will have some minimum requirement for content > > of sequence. Once it is satisfied, it is the authenticatior that will > > also have to be satisfied, and perhaps determine QoS or other > > information with additional sequences. If the sequences don't happen, > > the default values would be applied. Comments? > By if it doesn't happen, do you mean if it times out and hasn't received > another request (or Success)? What is the actual even that leads to the > success state? once you are there, presumably you won't be handling more > requests. > What I mean is that the authenticator is the "driver" of sequences. If it decides not to initiate more methods, it stops, sends success or failure and enables its end of the link (or not). The peer doesn't know what the authenticator is going to do. It may have its own policy that expects a particular sequence, or it may have a policy that it will do any methods it understands after doing an approved authentication method. Since the peer needs to be able to respond to an success or failure at any time, it can treat the alternative success (knowing the other end enabled its end of the link) as a success. Whether there is a reasonable chance that such an indication exists is a question I have started to wonder about. > > I am not sure why protection is an issue here? If a Success can be > > faked (and since it is not protected it certainly can) why would a > > lower layer indication worse? > > > My contention is that an alternative indication and a Success could be > > equivalent in the state machine. If I can handle a success in a > > sequence, I can handle an alternative indication. > I think I agree with these two points. Is there a case when you could fake > a lower-layer indication and not a Success? From aboba@internaut.com Wed Feb 12 05:26:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 11 Feb 2003 21:26:45 -0800 (PST) Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: <2209440.1044999672@[10.0.1.2]> Message-ID: > I think that if we wait for a good request from the authentication server > then the packet the authentication server is responding to is good in all > respects. Therefore it seems to me the cases are identical whether acting > in pass through or not. Yes, I would agree. From dave@frascone.com Wed Feb 12 12:51:03 2003 From: dave@frascone.com (David Frascone) Date: Wed, 12 Feb 2003 06:51:03 -0600 Subject: [eap] test Message-ID: <20030212125102.GC27654@wolverine> Testing, please ignore -- David Frascone If Murphy's Law can go wrong, it will. From aboba@internaut.com Wed Feb 12 14:25:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Feb 2003 06:25:43 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications Message-ID: I'd like to propose a rewrite of Section 4.2.1 to address some of these concerns: "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, as discussed 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 easily 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 an authenticator provides a protected indication that peer authentication has failed, or (where a method supporting mutual authentication is supported) the authenticator fails to authenticate to the peer, the peer implementation MUST silently discard subsequent EAP Success 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." -------------------------------------------------------------- Issue 80: Success Indications Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: February 10, 2003 Document: EAP-00 Comment type: Technical Priority: S Section: 4.2.1 Rationale/Explanation of issue: I am requesting some comments/clarification on the topic of when the success state can be reached by the peer. Executive summary: ----------------- 1. Is a satisfied policy enough for a peer transition to the success state, or is a SUCCESS packet required? 2. Is the text in 4.2.1 contradicting the current EAP model, or do I have an incorrect understanding of the model? (these are not mutually exclusive) Full explanation: ---------------- Through conversation with the state machine design team, I have come to question the conditions for success of an EAP conversation. All parties seem to agree that a satisfied policy is necessary for the peer to begin using the link, but the question is whether or not the condition is sufficient. That is, if a SUCCESS message never comes, can the peer transition to the SUCCESS state? The "alternate indications" of RFC2284 seem to imply that it can, however, section 3.4 of 2284bis explicitly warns against accepting link-layer indications (and for good reason). Since SUCCESS messages are neither acknowledged nor retransmitted, it is possible that SUCCESS messages could be lost causing an unneeded timeout. Assuming the link never goes down and the peer is satisfied, it may be acceptable to just begin using the link. If so, when should this happen? Presumably, it would be when a timeout has occurred and the policy is satisfied. This problem is closely related to so-called "protected" indications discussed in section 4.2.1 (from resolved issue 49). Design team conversations have concluded that such method-specific indications cannot actually indicate the success/failure of the overall conversation, but just the method itself. Some of the text in 4.2.1 seems to contradict this paradigm. For example, [c] states, "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." I believe I understand the spirit of this text, but I am not sure it fits the current model- are such indications really "contradictory", or has the method just said things are going well and the authenticator decided otherwise? Note: I believe I could make an equally long-winded argument for saying this is all just implementation detail because I could implement EAP such that the methods DO know the end result and still fits the wire protocol. Thanks for reading all the way through. Comments welcome. nick From Pasi.Eronen@nokia.com Wed Feb 12 15:54:18 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 12 Feb 2003 17:54:18 +0200 Subject: [eap] Proposed text for Issue 79 (Key strength estimate) Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA2A@esebe023.ntc.nokia.com> Here's my shot at Issue 79: [d] Key strength. If the method derives keys, then the effective key strength MUST be estimated. This estimate is meant for potential users of the method to determine if the keys produced are strong enough for the intended application. The effective key strength SHOULD be stated as number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require an effort comparable to 2^N operations of=20 a typical block cipher. The statement SHOULD be accompanied by a=20 short rationale, explaining how this number was arrived at. (Note: Although it is difficult to define what "comparable effort" and "typical block cipher" exactly mean, reasonable approximations are sufficient here. Refer to e.g. [SILVERMAN] for more discussion.) The key strength depends on the methods used to derive the keys. For instance, if keys are derived from a shared secret (such as a=20 password or master key), and possibly some public information =20 such as nonces, the effective key strength is limited by the entropy of the long-term secret (assuming that the derivation=20 procedure is computationally simple). To take another example, when=20 using public key algorithms, the strength of the symmetric key=20 depends on the strength of the public keys used. And add this to "Informative References": [SILVERMAN] Robert D. Silverman: A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths. RSA Laboratories Bulletin 13, April 2000 (Revised November 2001). http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html (I know that there are other papers about the same subject as Silverman's, some of which present somewhat different estimates about how strong various key lengths are, but for this purpose, a rough estimate is probably good enough) Best regards, Pasi From aboba@internaut.com Wed Feb 12 17:25:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Feb 2003 09:25:52 -0800 (PST) Subject: [eap] Re: Issue 79: Proposed text (Key strength estimate) Message-ID: This looks good to me. What do other people think? Message: 9 Date: Wed, 12 Feb 2003 17:54:18 +0200 From: To: Subject: [eap] Proposed text for Issue 79 (Key strength estimate) Here's my shot at Issue 79: [d] Key strength. If the method derives keys, then the effective key strength MUST be estimated. This estimate is meant for potential users of the method to determine if the keys produced are strong enough for the intended application. The effective key strength SHOULD be stated as number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require an effort comparable to 2^N operations of a typical block cipher. The statement SHOULD be accompanied by a short rationale, explaining how this number was arrived at. (Note: Although it is difficult to define what "comparable effort" and "typical block cipher" exactly mean, reasonable approximations are sufficient here. Refer to e.g. [SILVERMAN] for more discussion.) The key strength depends on the methods used to derive the keys. For instance, if keys are derived from a shared secret (such as a password or master key), and possibly some public information such as nonces, the effective key strength is limited by the entropy of the long-term secret (assuming that the derivation procedure is computationally simple). To take another example, when using public key algorithms, the strength of the symmetric key depends on the strength of the public keys used. And add this to "Informative References": [SILVERMAN] Robert D. Silverman: A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths. RSA Laboratories Bulletin 13, April 2000 (Revised November 2001). http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html (I know that there are other papers about the same subject as Silverman's, some of which present somewhat different estimates about how strong various key lengths are, but for this purpose, a rough estimate is probably good enough) Best regards, Pasi From jsalowey@cisco.com Wed Feb 12 19:47:19 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Wed, 12 Feb 2003 11:47:19 -0800 Subject: [eap] Re: Issue 79: Proposed text (Key strength estimate) Message-ID: <4D1E846548771F4AA7FAE28F4B358DB503B64942@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Looks good. I think we need to expand upon the fact that for many mechanisms the entropy of generated keys is variable (based on the underlying secrets, passwords and asymmetric key parameters).=20 To clarify this we could add the following "The statement SHOULD be accompanied by a short rationale, explaining how this number was arrived at. This explaination SHOULD include the parameters required to achieve N bits of entropy based on current knowledge of the algorithms." Joe > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Wednesday, February 12, 2003 9:26 AM > To: eap@frascone.com > Subject: [eap] Re: Issue 79: Proposed text (Key strength estimate) >=20 >=20 > This looks good to me. What do other people think? >=20 > Message: 9 > Date: Wed, 12 Feb 2003 17:54:18 +0200 > From: > To: > Subject: [eap] Proposed text for Issue 79 (Key strength estimate) >=20 >=20 > Here's my shot at Issue 79: >=20 > [d] Key strength. If the method derives keys, then the effective key > strength MUST be estimated. This estimate is meant for=20 > potential users > of the method to determine if the keys produced are strong=20 > enough for > the intended application. >=20 > The effective key strength SHOULD be stated as number of=20 > bits, defined > as follows: If the effective key strength is N bits, the best > currently known methods to recover the key (with non-negligible > probability) require an effort comparable to 2^N operations of > a typical block cipher. The statement SHOULD be accompanied by a > short rationale, explaining how this number was arrived at. >=20 > (Note: Although it is difficult to define what "comparable=20 > effort" and > "typical block cipher" exactly mean, reasonable approximations are > sufficient here. Refer to e.g. [SILVERMAN] for more discussion.) >=20 > The key strength depends on the methods used to derive the keys. > For instance, if keys are derived from a shared secret (such as a > password or master key), and possibly some public information > such as nonces, the effective key strength is limited by the > entropy of the long-term secret (assuming that the derivation > procedure is computationally simple). To take another example, when > using public key algorithms, the strength of the symmetric key > depends on the strength of the public keys used. >=20 > And add this to "Informative References": >=20 > [SILVERMAN] > Robert D. Silverman: A Cost-Based Security Analysis of Symmetric and > Asymmetric Key Lengths. RSA Laboratories Bulletin 13, April 2000 > (Revised November 2001). > http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html >=20 > (I know that there are other papers about the same subject as=20 > Silverman's, some of which present somewhat different=20 > estimates about how strong various key lengths are, but for=20 > this purpose, a rough estimate is probably good enough) >=20 > Best regards, > Pasi >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jrv@umich.edu Wed Feb 12 21:28:38 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 12 Feb 2003 16:28:38 -0500 Subject: [eap] Re: Issue 80: Success Indications Message-ID: <805236.1045067318@[10.0.1.2]> I suggest that we restructure this to move the MIC sections to a security considerations appendix. That moves paragraphs 3 and 4 and rule a to an appendix. The remainder deals with the fact that success and failure messages are not protected and can be spoofed, and with the possibility of "alternative indications". My other comments are inline --On Wednesday, February 12, 2003 6:25 AM -0800 Bernard Aboba wrote: > I'd like to propose a rewrite of Section 4.2.1 to address some of these > concerns: > > "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. > I don't see how these can be protected within EAP. Within an EAP method perhaps. Within 802.1x perhaps. But EAP doesn't seem to provide a way to protect them. If it is only method specific indications I think these should be dealt with as method issues, not EAP. Am I missing something? > 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). > I agree - and this is the issue to be clarified here - how to deal with the possible spoofing of unprotected Success and Failure Messages. > 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. > These are good paragraphs which should be in an appendix. I am not sure however that method specific success/failure carries through to the sequence as a whole. > 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, > as discussed in Section 4.1. > good - but for appendix > [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 easily employed. > This is good. I would prefer something with a positive statement that peer EAP MUST determine when it is satisfied and not just take success from the authenticator as an indication that it should be happy. > [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). > this seems a subset of rule b. > [d] Contradictory indications. Where an authenticator provides a > protected indication that peer authentication has failed, or > (where a method supporting mutual authentication is supported) > the authenticator fails to authenticate to the peer, > the peer implementation MUST silently discard subsequent > EAP Success packets. > ok > [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." > I still don't know what a protected indication means at this level. Is is something the method passes on? Is the assumption that there are no sequences? > -------------------------------------------------------------- > Issue 80: Success Indications > Submitter name: Nick Petroni > Submitter email address: npetroni@cs.umd.edu > Date first submitted: February 10, 2003 > Document: EAP-00 > Comment type: Technical > Priority: S > Section: 4.2.1 > Rationale/Explanation of issue: > I am requesting some comments/clarification on the topic of when the > success state can be reached by the peer. > > Executive summary: > ----------------- > 1. Is a satisfied policy enough for a peer transition to the success > state, or is a SUCCESS packet required? > > 2. Is the text in 4.2.1 contradicting the current EAP model, or do I have > an incorrect understanding of the model? (these are not mutually > exclusive) > > > Full explanation: > ---------------- > Through conversation with the state machine design team, I have come to > question the conditions for success of an EAP conversation. All parties > seem to agree that a satisfied policy is necessary for the peer to begin > using the link, but the question is whether or not the condition is > sufficient. That is, if a SUCCESS message never comes, can the peer > transition to the SUCCESS state? The "alternate indications" of RFC2284 > seem to imply that it can, however, section 3.4 of 2284bis explicitly > warns against accepting link-layer indications (and for good reason). > Since SUCCESS messages are neither acknowledged nor retransmitted, it is > possible that SUCCESS messages could be lost causing an unneeded timeout. > Assuming the link never goes down and the peer is satisfied, it may be > acceptable to just begin using the link. If so, when should this happen? > Presumably, it would be when a timeout has occurred and the policy is > satisfied. > > This problem is closely related to so-called "protected" indications > discussed in section 4.2.1 (from resolved issue 49). Design team > conversations have concluded that such method-specific indications cannot > actually indicate the success/failure of the overall conversation, but > just the method itself. Some of the text in 4.2.1 seems to contradict this > paradigm. For example, [c] states, > > "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." > > I believe I understand the spirit of this text, but I am not sure it fits > the current model- are such indications really "contradictory", or has the > method just said things are going well and the authenticator decided > otherwise? > > Note: > I believe I could make an equally long-winded argument for saying this is > all just implementation detail because I could implement EAP such that the > methods DO know the end result and still fits the wire protocol. > > Thanks for reading all the way through. Comments welcome. > > nick > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Feb 12 20:36:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Feb 2003 12:36:36 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <805236.1045067318@[10.0.1.2]> Message-ID: > I don't see how these can be protected within EAP. Within an EAP method > perhaps. Within 802.1x perhaps. But EAP doesn't seem to provide a way to > protect them. If it is only method specific indications I think these > should be dealt with as method issues, not EAP. Am I missing something? Removed "Within EAP" > These are good paragraphs which should be in an appendix. I am not sure > however that method specific success/failure carries through to the > sequence as a whole. I would argue that authentication cannot succeed if method authentication fails. Otherwise, we open a vulnerability to rogue authenticators. > good - but for appendix Moved into text for Issue 74 (a new section). > This is good. I would prefer something with a positive statement that peer > EAP MUST determine when it is satisfied and not just take success from the > authenticator as an indication that it should be happy. Any text to suggest? > this seems a subset of rule b. I think so. Will consolidate. > I still don't know what a protected indication means at this level. Is is > something the method passes on? Is the assumption that there are no > sequences? It's something the method passing on. Sequences can be supported -- but if an authentication method fails, the sequence cannot continue. Is this better? "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. EAP Success and Failure packets may be spoofed, since as described in Section 4.2, they contain no message integrity check (MIC). They are therefore considered unprotected. 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), (see Section 7.13) and if so, then these success/failure indications are considered protected. In order to decrease vulnerability to spoofing of success and failure indications, the following processing rules are recommended: [a] Handling 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 error indications, premature EAP Failure packets are unexpected, so that this technique may be easily employed. [b] Authentication requirement. Where mutual authentication is required, and the authenticator fails to authenticate successfully to the peer, the peer implementation MUST NOT consider authentication to be successful even upon receipt of an EAP Success packet. Instead, the peer MUST terminate the authentication conversation and refuse to enable the link. This implies, for an example, that a peer configured to require mutual authentication will not consider authentication to be successful on receipt of a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [c] Contradictory indications. Where an authenticator provides a protected method-specific indication that peer authentication has failed the peer implementation MUST NOT consider authentication to be successful even upon receipt of an EAP Success packet. Instead, the peer MUST terminate the authentication conversation and refuse to enable the link. [d] Processing of EAP Success and Failure in the absence of method-specific indications. Subsequent to the completion of the EAP authentication method (Types 4 and greater), and in the absence of method-specific indications, EAP Success and Failure packets MUST be accepted and processed by the EAP implementation." From aboba@internaut.com Wed Feb 12 23:05:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Feb 2003 15:05:08 -0800 (PST) Subject: [eap] RADIUS/EAP to IETF last call (fwd) Message-ID: Although RFC 2869bis is technically an individual submission and not an EAP WG work item, I would like to request that EAP WG members treat the IETF last call that has begun as though it were an EAP WG last call. That is, please read the draft thoroughly, and send your comments to the EAP WG mailing list at eap@frascone.com, using the EAP WG issue format: http://www.drizzle.com/~aboba/EAP/eapissues.html We will track the issues as we would issues on any other EAP WG item. The -09 version of the draft is not available online yet (should be up by the end of the week). ================================================================================ Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational From: The IESG Date: Wed, 12 Feb 2003 13:39:41 -0500 Reply-to: iesg@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- The IESG has received a request to consider RADIUS Support For Extensible Authentication Protocol (EAP) as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-11. Files can be obtained via http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt From Pasi.Eronen@nokia.com Thu Feb 13 09:01:26 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 13 Feb 2003 11:01:26 +0200 Subject: [eap] Minor editorial comments for 2869bis-09 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA2B@esebe023.ntc.nokia.com> 2869bis-09 looks good! Various minor editorial issues: --------------- Extended/vendor-specific NAK in 2869bis-09? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 13 Feb 2003 Document: RFC 2869bis-09 Comment type: Editorial Priority: 2 (May fix) Section: Various Rationale/Explanation of issue: If we add a new "vendor-specific Nak" or "extended Nak" type=20 to 2284bis, we probably have to make some minor editorial changes in 2869bis as well. ------------ Typos and minor editorial changes for 2869bis-09 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 13 Feb 2003 Document: RFC 2869bis-09 Comment type: Editorial Priority: 2 (May fix) Section: Various Rationale/Explanation of issue: 2.1: s/in a a large/in a large/ 3.2: s/The is calculated/The Message-Authenticator is calculated/ 4.3.1: s/To address this vulnerabilities/To address these = vulnerabilities/ 4.3.7: s/MD5/MD5-Challenge/ 4.3.8: s/EAP methode-specific/EAP method-specific/ Appendix A, 2nd example: last message sent by RADIUS server s:EAP-Message/EAP-Request/EAP-Success:EAP-Message/EAP-Success: Appendix A, 3rd, 4th and 7th, 9th examples: first message sent by RADIUS = server s:EAP-Message/Identity:EAP-Message/EAP-Request/Identity: The informative references [MD5Attack] and [RFC2486] are=20 never cited anywhere in the text, so maybe they are unnecessary. Best regards, Pasi From james.d.carlson@east.sun.com Thu Feb 13 15:33:47 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 13 Feb 2003 10:33:47 -0500 Subject: [eap] Implementer Survey: Duplicate detection in pass-through In-Reply-To: John Vollbrecht's message of 11 February 2003 14:27:24 References: <15943.56798.850198.605679@gargle.gargle.HOWL> <15944.59353.553684.99064@gargle.gargle.HOWL> <1296796.1044973644@[10.0.1.2]> Message-ID: <15947.47835.229888.624845@gargle.gargle.HOWL> John Vollbrecht writes: > If I understand this conversation I believe the issue that James is raising > is that trying to do DOS mitigation on a protocol that was not designed for > that is of highly questionable value. Exactly. > The original idea was that we are worried about DOS attacks, so we should > attempt to allow the protocol to succeed in the face of them. This leads > to some fairly complicated schemes which keep a particular authentication > sequence in the face of "injected" messages. The end result is that the > DOS attack is more successful since it can last longer. It would be better > to restart the authentication and get it right than try to find the needle > in the haystack of attacking trash. Right. Should you want to fix this, I believe that you will need some way for the EAP server (NAS) to perform the MIC itself. Storing Response messages and submitting them one at a time to the AAA server doesn't work, since each one ends up being an individual Access-Request, it necessarily facilitates the DoS attack by fobbing the load off onto the centeralized server, and you have to suppose a very strange implementation of the AAA server -- that server has to go into a mode where it reissues the same Access-Challenge over and over, hoping that a useful Access-Request in reply to the original Access-Challenge eventually shows up. Worse still, the EAP server is required to buffer an arbitrary number of messages while it waits on the AAA server, since there's perhaps a needle in that haystack somewhere. I'm seeing no benefits for DoS protection from that path. It looks to me like it just gets worse the further one travels down it. I can think of at least three ways to make the EAP server validation of MICs happen: have the shared validation data used in the MIC be agreed upon between the EAP server and the authenticatee alone (leaving the authenticator out of the picture), have the protocol from which the shared MIC-related validation data is derived structured such that both the EAP server and the authenticator can derive the correct data (and both perform MIC), or have the authenticator deliver the validation data to the EAP server when MIC is first enabled. The first of these three corresponds to pushing the MIC down to the sub-EAP transport layer. This seems quite fair to me, since the real design fault (allowing injection) lies in the L2 in question, not in EAP or its methods. The second seems somewhat infeasible, since it means that the MIC really ought to be part of the EAP framework itself, and that sounds like a hazard. The third seems promising, but will obviously require changes in that 2869bis draft. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Feb 13 15:53:14 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 13 Feb 2003 10:53:14 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: Bernard Aboba's message of 12 February 2003 12:36:36 References: <805236.1045067318@[10.0.1.2]> Message-ID: <15947.49002.62196.48558@gargle.gargle.HOWL> Bernard Aboba writes: > 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. I disagree with that bit of wording because I see no particular value in it. I realize that what you're concerned about here is the DoS attack by someone who can generate EAP Failure messages towards the authenticatee, but this recommendation isn't sufficient to solve the problem (it merely means that the DoS attacker needs to flood the authenticatee with EAP Failure messages -- so that the timing will work out right, and one of the messages will hit at the "end" of a method), and it clearly is incompatible with 2284. If DoS or other message injection is a problem in some particular usage of EAP, then there needs to be a real solution to this, rather than minor and distributed tweaks to EAP message handling. In general, I think that any references in the EAP base document itself to methods being "incomplete" in some way is incorrect. If some method wants to define such behavior, that's a problem for that method document, but I don't see it as a basic feature of EAP itself. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Feb 13 15:57:17 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 13 Feb 2003 10:57:17 -0500 Subject: [eap] Re: Issue 80, Success Indications In-Reply-To: Nick Petroni's message of 11 February 2003 19:23:11 References: <2033657.1044989593@[10.0.1.2]> Message-ID: <15947.49245.381502.893259@gargle.gargle.HOWL> Nick Petroni writes: > > My contention is that an alternative indication and a Success could be > > equivalent in the state machine. If I can handle a success in a sequence, > > I can handle an alternative indication. > I think I agree with these two points. Is there a case when you could fake > a lower-layer indication and not a Success? Only if you believe in MICs for EAP. I agree that alternative indications are no more or less secure than EAP Success and that (for PPP at least), they're a helpful robustness feature. I would not like to see them disallowed by an update to 2284. If we simply must have special documentation features for MICs, then we need to say that, for implementations that have some sort of MIC, the alternative indication can be accepted only if it has the same MIC guarantees as the EAP Success message would have had. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Feb 13 16:10:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 08:10:27 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15947.49002.62196.48558@gargle.gargle.HOWL> Message-ID: > work out right, and one of the messages will hit at the "end" of a > method), and it clearly is incompatible with 2284. I'm curious why you say it is incomptible with RFC 2284. The problem of forged Success and Failure messages was noted in the University of Maryland state machine analysis, and as a result the behavior described is exhibited by several implementations. > If DoS or other message injection is a problem in some particular > usage of EAP, then there needs to be a real solution to this, rather > than minor and distributed tweaks to EAP message handling. What would a "real" solution be? EAP provides basic transport over which "real" security protocols (IKE, Kerberos, TLS, etc.) can be run. Those protocols have been well analyzed, but sandwiching them between unsecured EAP messages (Nak, Identity Request/Respose, Success/Failure) or allowing unsecured messages to intercede (allowing random Type codes to abort the exchange) creates vulnerabilities that didn't exist in those original protocols. So it seems to me that if we either allow the unsecured messages to be ommitted (optional Identity), cover them with a MIC, ignore them when the protected exchanges contradict, and don't allow the exchange to be aborted in the middle, we've recovered the security of the original protocols. > In general, I think that any references in the EAP base document > itself to methods being "incomplete" in some way is incorrect. If > some method wants to define such behavior, that's a problem for that > method document, but I don't see it as a basic feature of EAP itself. Most security protocols have well defined states that describe when the exchange has finished successfully or not. That is not an EAP concept. From jrv@umich.edu Thu Feb 13 18:35:39 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 13 Feb 2003 13:35:39 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: References: Message-ID: <1694916.1045143339@[10.0.1.2]> Thanks for the feedback. there is a lot of info here. I have some questions in line. --On Thursday, February 13, 2003 8:10 AM -0800 Bernard Aboba wrote: > > work out right, and one of the messages will hit at the "end" of a > > method), and it clearly is incompatible with 2284. > > I'm curious why you say it is incomptible with RFC 2284. The problem of > forged Success and Failure messages was noted in the University of > Maryland state machine analysis, and as a result the behavior described is > exhibited by several implementations. > so does the analysis actually say what should be done to resolve the problems? Is the analysis posted somewhere? > > If DoS or other message injection is a problem in some particular > > usage of EAP, then there needs to be a real solution to this, rather > > than minor and distributed tweaks to EAP message handling. > > What would a "real" solution be? EAP provides basic transport over which > "real" security protocols (IKE, Kerberos, TLS, etc.) can be run. Those > protocols have been well analyzed, but sandwiching them between unsecured > EAP messages (Nak, Identity Request/Respose, Success/Failure) or allowing > unsecured messages to intercede (allowing random Type codes to abort the > exchange) creates vulnerabilities that didn't exist in those original > protocols. > > So it seems to me that if we either allow the unsecured messages to be > ommitted (optional Identity), cover them with a MIC, ignore them when > the protected exchanges contradict, and don't allow the exchange to be > aborted in the middle, we've recovered the security of the original > protocols. > Would doing these things make the protocol more secure? Is so then there is a stronger reason that just eliminating DOS attacks for some of the state machine things we have talked about. > > In general, I think that any references in the EAP base document > > itself to methods being "incomplete" in some way is incorrect. If > > some method wants to define such behavior, that's a problem for that > > method document, but I don't see it as a basic feature of EAP itself. > > Most security protocols have well defined states that describe when the > exchange has finished successfully or not. That is not an EAP concept. is this "end" necessary for eap or just for methods? what would eapv2 look like? From jrv@umich.edu Thu Feb 13 18:43:26 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 13 Feb 2003 13:43:26 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15947.49002.62196.48558@gargle.gargle.HOWL> References: <805236.1045067318@[10.0.1.2]> <15947.49002.62196.48558@gargle.gargle.HOWL> Message-ID: <1722947.1045143806@[10.0.1.2]> --On Thursday, February 13, 2003 10:53 AM -0500 James Carlson wrote: > Bernard Aboba writes: > > 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. > > I disagree with that bit of wording because I see no particular value > in it. > > I realize that what you're concerned about here is the DoS attack by > someone who can generate EAP Failure messages towards the > authenticatee, but this recommendation isn't sufficient to solve the > problem (it merely means that the DoS attacker needs to flood the > authenticatee with EAP Failure messages -- so that the timing will > work out right, and one of the messages will hit at the "end" of a > method), and it clearly is incompatible with 2284. > true - we need to define what DOS attacks we think are worth defending. > If DoS or other message injection is a problem in some particular > usage of EAP, then there needs to be a real solution to this, rather > than minor and distributed tweaks to EAP message handling. > > In general, I think that any references in the EAP base document > itself to methods being "incomplete" in some way is incorrect. If > some method wants to define such behavior, that's a problem for that > method document, but I don't see it as a basic feature of EAP itself. > I disagree about needing to know about method state. I don't think it is possible to make a decision about whether a sequence is valid without knowing which methods have completed successfully. That would seem to mean you would need to know if they were incomplete as well. > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From npetroni@cs.umd.edu Thu Feb 13 18:49:59 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Thu, 13 Feb 2003 13:49:59 -0500 (EST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <1694916.1045143339@[10.0.1.2]> Message-ID: > > I'm curious why you say it is incomptible with RFC 2284. The problem of > > forged Success and Failure messages was noted in the University of > > Maryland state machine analysis, and as a result the behavior described is > > exhibited by several implementations. > > > > so does the analysis actually say what should be done to resolve the > problems? Is the analysis posted somewhere? The paper can be found at http://www.cs.umd.edu/~waa/pubs/1x.pdf, but it does not actually address DoS specifically (at least to the best of my recollection). The problem described has to do with binding problems when not using WEP, as well as the ability to forge SUCCESS. DoS by forged FAILURE follows easily. From aboba@internaut.com Thu Feb 13 18:24:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 10:24:53 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <1694916.1045143339@[10.0.1.2]> Message-ID: > so does the analysis actually say what should be done to resolve the > problems? Is the analysis posted somewhere? Here's a pointer to the original paper: http://www.cs.umd.edu/~waa/1x.pdf > Would doing these things make the protocol more secure? Is so then there > is a stronger reason that just eliminating DOS attacks for some of the > state machine things we have talked about. Doing those things would ensure that EAP would not add security vulnerabilities to existing security protocols. > > Most security protocols have well defined states that describe when the > > exchange has finished successfully or not. That is not an EAP concept. > > is this "end" necessary for eap or just for methods? what would eapv2 look > like? Methods indicate when they're "done" and the result (Failure/Success). If they're not done, then you can't receive Failure/Success/Another Type. Also, if there are no sequences, then presumably the result of the single method authentication is identical to the EAP result. At that point, the Failure/Success packet becomes completely vestigial. Note that it is necessary for the final packet to go from Server to Client, if only because that is the direction of the final RADIUS message. So that final message cannot be ACK'd because there is no RADIUS conversation possible after that point. So there's no reason to believe that EAPv2 could do any better. From james.d.carlson@east.sun.com Thu Feb 13 19:50:40 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 13 Feb 2003 14:50:40 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: Bernard Aboba's message of 13 February 2003 08:10:27 References: <805236.1045067318@[10.0.1.2]> <15947.49002.62196.48558@gargle.gargle.HOWL> <1722947.1045143806@[10.0.1.2]> <1694916.1045143339@[10.0.1.2]> Message-ID: <15947.63248.254321.317448@gargle.gargle.HOWL> Bernard Aboba writes: > > work out right, and one of the messages will hit at the "end" of a > > method), and it clearly is incompatible with 2284. > > I'm curious why you say it is incomptible with RFC 2284. The authentication phase ends when EAP Success or Failure is received: 3. The authenticator ends the authentication phase with a Success or Failure packet. This proposed change is now saying that the authentication phase can continue along if (in one peer's opinion? both? the method's judgement? EAP itself? how do we know?) the Failure is somehow deemed as "unacceptable." This is new in comparison to 2284, and looks to me to be hard to implement in an interoperable manner, because it requires that everyone always agrees on which precise timing is "valid," and differing interpretations will cause hangs. It's still not clear to me precisely when one is "in the middle of" a method, and when one is not. If I'm in the middle of a multi-method sequence (however unlikely), but between methods, am I vulnerable to unexpected EAP Failure? > The problem of > forged Success and Failure messages was noted in the University of > Maryland state machine analysis, and as a result the behavior described is > exhibited by several implementations. I think the problem there is at a much higher level. If you get EAP Success and you're not happy about the current state FOR ANY REASON, then by all means, drop the link. It makes no sense to open the floodgates before *YOUR* side of the connection is satisfied with the progress. This isn't really a protocol issue. It's an implementation error that doesn't quite need to be enshrined in a specification (except, perhaps, as offhand advice). Moreover, I think it makes no sense to mandate things that some implementations may be unable or unwilling to do. If I'm a dial-up PPP implementation, and my security model is the commonly-used one (I prove my identity to my ISP, and he proves *nothing* to me), then I really don't care what the EAP progress looks like. If I get Success, then I'm really quite happy. My criteria have been satisfied, and I'm not expecting anything else. > > If DoS or other message injection is a problem in some particular > > usage of EAP, then there needs to be a real solution to this, rather > > than minor and distributed tweaks to EAP message handling. > > What would a "real" solution be? EAP provides basic transport over which > "real" security protocols (IKE, Kerberos, TLS, etc.) can be run. Those > protocols have been well analyzed, but sandwiching them between unsecured > EAP messages (Nak, Identity Request/Respose, Success/Failure) or allowing > unsecured messages to intercede (allowing random Type codes to abort the > exchange) creates vulnerabilities that didn't exist in those original > protocols. Agreed, and that's the problem. The problem is in the transport mechanism that EAP is using. That transport violates the assumptions made by EAP -- in particular, that it's a point-to-point link, and thus has no possibility of any sort of interception or injection. > So it seems to me that if we either allow the unsecured messages to be > ommitted (optional Identity), cover them with a MIC, ignore them when > the protected exchanges contradict, and don't allow the exchange to be > aborted in the middle, we've recovered the security of the original > protocols. If we do that, then I think we need to push this down lower: the MIC needs to occur at a sublayer between EAP and the next level down. It needs to protect EAP against the sort of corruption you're describing. Trying to build it into EAP, when EAP was *not* designed to do this, just leads to trouble. > > In general, I think that any references in the EAP base document > > itself to methods being "incomplete" in some way is incorrect. If > > some method wants to define such behavior, that's a problem for that > > method document, but I don't see it as a basic feature of EAP itself. > > Most security protocols have well defined states that describe when the > exchange has finished successfully or not. That is not an EAP concept. Right; that's what I'm saying. It's a problem for the method, not for EAP. John Vollbrecht writes: > > So it seems to me that if we either allow the unsecured messages to be > > ommitted (optional Identity), cover them with a MIC, ignore them when > > the protected exchanges contradict, and don't allow the exchange to be > > aborted in the middle, we've recovered the security of the original > > protocols. > > > Would doing these things make the protocol more secure? Is so then there > is a stronger reason that just eliminating DOS attacks for some of the > state machine things we have talked about. Yes, if we had a MIC that protected all of the EAP messages, then it would be more secure. John Vollbrecht writes: > > In general, I think that any references in the EAP base document > > itself to methods being "incomplete" in some way is incorrect. If > > some method wants to define such behavior, that's a problem for that > > method document, but I don't see it as a basic feature of EAP itself. > > > I disagree about needing to know about method state. I don't think it is > possible to make a decision about whether a sequence is valid without > knowing which methods have completed successfully. That would seem to mean > you would need to know if they were incomplete as well. The requirement flows the other direction, in my estimation. In other words, EAP doesn't need to care about this. For methods that have multiple rounds, *AND* where the security model of the method requires for the authenticatee that all the rounds are completed (i.e., mutual authentication), then it makes sense to say that EAP Success before that point is really a failure indication. Otherwise, the "in the middle" definition is not useful, and serves only to create new complexity and corner cases that weren't present in 2284. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From yohba@tari.toshiba.com Thu Feb 13 19:57:42 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 13 Feb 2003 14:57:42 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: References: <15947.49002.62196.48558@gargle.gargle.HOWL> Message-ID: <20030213195742.GE760@catfish> On Thu, Feb 13, 2003 at 08:10:27AM -0800, Bernard Aboba wrote: > > work out right, and one of the messages will hit at the "end" of a > > method), and it clearly is incompatible with 2284. > > I'm curious why you say it is incomptible with RFC 2284. The problem of > forged Success and Failure messages was noted in the University of > Maryland state machine analysis, and as a result the behavior described is > exhibited by several implementations. > > > If DoS or other message injection is a problem in some particular > > usage of EAP, then there needs to be a real solution to this, rather > > than minor and distributed tweaks to EAP message handling. > > What would a "real" solution be? EAP provides basic transport over which > "real" security protocols (IKE, Kerberos, TLS, etc.) can be run. Those > protocols have been well analyzed, but sandwiching them between unsecured > EAP messages (Nak, Identity Request/Respose, Success/Failure) or allowing > unsecured messages to intercede (allowing random Type codes to abort the > exchange) creates vulnerabilities that didn't exist in those original > protocols. > > So it seems to me that if we either allow the unsecured messages to be > ommitted (optional Identity), cover them with a MIC, ignore them when > the protected exchanges contradict, and don't allow the exchange to be > aborted in the middle, we've recovered the security of the original > protocols. If we omit the Identity, it would work only for limited environments where the authenticator and EAP server is co-located or there is only one EAP server. So omitting optional Identity increases security at the cost of limiting the coverage of the protocol usage. Covering multiple unprotected EAP messages with a MIC is vulnerable to a DoS attack which can be launched easier than a DoS attack to the original protocol. It seems to me that we have not fully recovered. Yoshihiro Ohba > > > In general, I think that any references in the EAP base document > > itself to methods being "incomplete" in some way is incorrect. If > > some method wants to define such behavior, that's a problem for that > > method document, but I don't see it as a basic feature of EAP itself. > > Most security protocols have well defined states that describe when the > exchange has finished successfully or not. That is not an EAP concept. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Thu Feb 13 19:34:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 11:34:32 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <20030213195742.GE760@catfish> Message-ID: > If we omit the Identity, it would work only for limited environments > where the authenticator and EAP server is co-located or there is only > one EAP server. Not really. If the default method can be terminated on a proxy, it can be used even in roaming scenarios. For example, you could create a method that does a DH, then exchanges identities, and potentially then does an auth exchange. > So omitting optional Identity increases security at > the cost of limiting the coverage of the protocol usage. Covering > multiple unprotected EAP messages with a MIC is vulnerable to a DoS > attack which can be launched easier than a DoS attack to the original > protocol. It seems to me that we have not fully recovered. Existing EAP methods already do this. EAP TLS includes a finished message that MICs previous messasges. So it really isn't an EAP issue at all. From yohba@tari.toshiba.com Thu Feb 13 21:13:59 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 13 Feb 2003 16:13:59 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: References: <20030213195742.GE760@catfish> Message-ID: <20030213211359.GG760@catfish> On Thu, Feb 13, 2003 at 11:34:32AM -0800, Bernard Aboba wrote: > > If we omit the Identity, it would work only for limited environments > > where the authenticator and EAP server is co-located or there is only > > one EAP server. > > Not really. If the default method can be terminated on a proxy, it can be > used even in roaming scenarios. For example, you could create a method > that does a DH, then exchanges identities, and potentially then does an > auth exchange. Is the proxy also applicable to EAP TLS? > > > So omitting optional Identity increases security at > > the cost of limiting the coverage of the protocol usage. Covering > > multiple unprotected EAP messages with a MIC is vulnerable to a DoS > > attack which can be launched easier than a DoS attack to the original > > protocol. It seems to me that we have not fully recovered. > > Existing EAP methods already do this. EAP TLS includes a finished message > that MICs previous messasges. So it really isn't an EAP issue at all. > What about fragmentated PEAP messages that may be exchanged after TLS handshake? Yoshihiro Ohba From aboba@internaut.com Thu Feb 13 21:11:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 13:11:52 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <20030213211359.GG760@catfish> Message-ID: > Is the proxy also applicable to EAP TLS? Sure. In fact with EAP TLS there is no need to go back to the authentication server at all. See: http://www.drizzle.com/~aboba/IEEE/draft-ietf-roamops-cert-02.txt > > Existing EAP methods already do this. EAP TLS includes a finished message > > that MICs previous messasges. So it really isn't an EAP issue at all. > > What about fragmentated PEAP messages that may be exchanged after TLS > handshake? You won't normally see fragmentation unless a cert-based protocol is being run within the tunnel -- and there's no reason to run such a protocol. From jrv@umich.edu Thu Feb 13 22:33:35 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 13 Feb 2003 17:33:35 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: References: Message-ID: <2075653.1045157615@[10.0.1.2]> Thanks for the pointer. Sounds like the paper doesn't give a reason (pro or con) to implement the DOS mitigation steps, so we have to decide based on DOS/ efficiency reasons. --On Thursday, February 13, 2003 1:49 PM -0500 Nick Petroni wrote: > > > I'm curious why you say it is incomptible with RFC 2284. The problem > > > of forged Success and Failure messages was noted in the University of > > > Maryland state machine analysis, and as a result the behavior > > > described is exhibited by several implementations. > > > > > > > so does the analysis actually say what should be done to resolve the > > problems? Is the analysis posted somewhere? > The paper can be found at http://www.cs.umd.edu/~waa/pubs/1x.pdf, but it > does not actually address DoS specifically (at least to the best of my > recollection). The problem described has to > do with binding problems when not using WEP, as well as the ability to > forge SUCCESS. DoS by forged FAILURE follows easily. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Feb 13 21:31:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 13:31:10 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15947.63248.254321.317448@gargle.gargle.HOWL> Message-ID: > 3. The authenticator ends the authentication phase with a Success or > Failure packet. Sure. The authenticator ends the conversation -- this doesn't say that the peer has to enable the link based on such an indication. > This proposed change is now saying that the authentication phase can > continue along if (in one peer's opinion? both? the method's > judgement? EAP itself? how do we know?) the Failure is somehow > deemed as "unacceptable." I would agree that it is necessary to act on the Failure after the method is complete, if only because of sequences. But if the method fails at any point, then the peer can disconnect at will - whether or not an EAP Success is received. > This is new in comparison to 2284, and looks to me to be hard to > implement in an interoperable manner, because it requires that > everyone always agrees on which precise timing is "valid," and > differing interpretations will cause hangs. A method that has its own mechanisms for completing unsuccessfully will not send an EAP Failure prior to method completion. If the client knows that it is using such a method, then it also knows that an EAP Failure is not an allowable packet until the state machine reaches a terminal state, and can discard such a packet if received. > It's still not clear to > me precisely when one is "in the middle of" a method, and when one is > not. If I'm in the middle of a multi-method sequence (however > unlikely), but between methods, am I vulnerable to unexpected EAP > Failure? We're only talking about "in the middle of" a single method. Sequences are another issue, and I agree that there is a vulnerability to unexpected EAP Failure where sequences can be used. > I think the problem there is at a much higher level. If you get EAP > Success and you're not happy about the current state FOR ANY REASON, > then by all means, drop the link. It makes no sense to open the > floodgates before *YOUR* side of the connection is satisfied with the > progress. Sure. > This isn't really a protocol issue. It's an implementation > error that doesn't quite need to be enshrined in a specification > (except, perhaps, as offhand advice). Implementation advice is fine. > Moreover, I think it makes no sense to mandate things that some > implementations may be unable or unwilling to do. If I'm a dial-up > PPP implementation, and my security model is the commonly-used one (I > prove my identity to my ISP, and he proves *nothing* to me), then I > really don't care what the EAP progress looks like. If I get Success, > then I'm really quite happy. My criteria have been satisfied, and I'm > not expecting anything else. Sure. > Agreed, and that's the problem. The problem is in the transport > mechanism that EAP is using. That transport violates the assumptions > made by EAP -- in particular, that it's a point-to-point link, and > thus has no possibility of any sort of interception or injection. But if you look at the protocol, it really wouldn't be different in many respects if the transport were UDP. There are no keys at the start, so you couldn't MIC the Identity or Nak. About the only thing you could do differently is to MIC the Failure (if you have a key) or the Success. If you had to support methods that only did one-way auth, you couldn't even guarantee that you'd be able to do that, because you might not have a key. So it seems to me that the "assumptions" of EAP are largely derivable from the basic scenario of network access authentication. > If we do that, then I think we need to push this down lower: the MIC > needs to occur at a sublayer between EAP and the next level down. It > needs to protect EAP against the sort of corruption you're describing. > Trying to build it into EAP, when EAP was *not* designed to do this, > just leads to trouble. That's like saying that a MIC needs to be built into IP in order to be used in protocols like IPsec. IPsec ESP or AH are built as shims on top of IP, yet they can cover portions of the IP header directly (AH) or indirectly (ESP through the TCP/UDP pseudo-header). Similarly, you could build an EAP method with a per-packet MIC in each packet without having to change EAP at all. > Right; that's what I'm saying. It's a problem for the method, not for > EAP. Sure -- but it affects how implementations should process Success packets (maybe not Failure packets for the reasons you state). > Yes, if we had a MIC that protected all of the EAP messages, then it > would be more secure. You can't do that because you don't have keys to calculate such a MIC until they are derived later. The only EAP packet that could benefit from such a field would be Success (for some methods) and Failure (some of the time, for some methods). > The requirement flows the other direction, in my estimation. In other > words, EAP doesn't need to care about this. For methods that have > multiple rounds, *AND* where the security model of the method requires > for the authenticatee that all the rounds are completed (i.e., mutual > authentication), then it makes sense to say that EAP Success before > that point is really a failure indication. Otherwise, the "in the > middle" definition is not useful, and serves only to create new > complexity and corner cases that weren't present in 2284. Since the peer can't know what methods are going to be run, it is hard to apply this in practice. However, the peer *can* know whether the EAP method it is currently running is complete or not, and whether Failure or Success is expected. From aboba@internaut.com Thu Feb 13 21:44:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 13:44:24 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15947.63248.254321.317448@gargle.gargle.HOWL> Message-ID: Let's see if we can streamline the proposed resolution to Issue 80 a bit: How does this look? "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. EAP Success and Failure packets may be spoofed, since as described in Section 4.2, they contain no message integrity check (MIC). They are therefore considered unprotected. EAP methods also MAY include support for acknowledged success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated to it, 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), (see Section 7.13) and if so, then these success/failure indications are considered protected. In order to decrease vulnerability to spoofing of success and failure indications, the following implementation advice is provided: [a] Handling of EAP Success and Failure packets prior to method completion. It is recommended that a peer EAP implementation receiving an EAP Success packet prior to method completion 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. For methods that provide their own error indications prior to termination, an EAP Failure packet prior to completion is unexpected, so that it also can be disregarded. [b] Authentication requirement. Where mutual authentication is required, and the authenticator fails to authenticate successfully to the peer, it is recommended that the peer not enable the link as a result of receiving an EAP Success packet. Instead, termination of the authentication conversation is recommended. This implies, for an example, that a peer configured to require mutual authentication will not consider authentication to be successful on receipt of a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [c] Contradictory indications. It is recommended that the peer terminate authentication after failure of an authentication method, even if an EAP Success packet is received. [d] Processing of EAP Success and Failure. With the exception of the above cases, EAP Success and Failure packets are accepted and processed by the EAP implementation." From jrv@umich.edu Thu Feb 13 23:01:25 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 13 Feb 2003 18:01:25 -0500 Subject: [eap] EAPv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA08@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA08@esebe023.ntc.nokia.com> Message-ID: <2175800.1045159284@[10.0.1.2]> --On Monday, January 27, 2003 11:23 AM +0200 Pasi.Eronen@nokia.com wrote: > On 20 Jan 2003, Bernard Aboba wrote: > > > Overall, it is important to understand that PANA (and IEEE 802.11i for > > that matter) represent very major extensions to the existing EAP usage > > model. RFC 2284 was created with the assumption that the underlying > > physical medium was secure, as was IEEE 802.1X (which was created for > > use with wired networks only). Where EAP is run over wireless that is > > not the case. This greatly expands the potential security > > vulnerabilities. > > > > IEEE 802.11i has put in substantial effort to address these issues: > > addition of a "third leg" of mutual auth and key derivation > > between the NAS and client; proper key wrapping between the AAA server > > and NAS; definition of the key hierarchy, both for individual sessions, > > and for fast handoff; support for pre-authentication; EAP method > > requirements. > > > > To get an idea of what you're up against, I would suggest a careful > > reading of IEEE 802.11i. > > Given that many people seem to be interested in using EAP in > environments where the underlying medium is not secure, and getting it > right seems to be very difficult, would there be any point or interest > in developing "EAPv2"? > > Some ideas what properties this "EAPv2" could have: > > - Designed to be used in environments where the underlying > medium is not secure. > - Designed and specified so that it is easy to "embed" EAPv2 in > other protocols (EAPv1 was designed to be extensible, but it > was not intended as a "building block" for other protocols). > - Maybe better support for mutual authentication and method > negotiation related to it. > - EAPv2 records could be transported as an EAPv1 method, so it could > be used in PPP/802.1X environments without changing NAS boxes. > - Clear specification of behavior (state machines, etc.), so that > EAPv2 would be simpler and easier to implement than EAPv1. > > Clearly, the main target of this work would not be PPP, or even > 802.1X/11i, but new protocols which would like to reuse an existing > "building block" (PANA, PIC, others?). > > What do you think, is there demand for this kind of work? Are people > interested in thinking more about this? If so, how should the thing > get started? (Perhaps some of the more difficult issues in 2284bis > could be postponed to this "EAPv2", so we can get 2284bis accepted > sooner? Or maybe this isn't a good idea...) > I am interested. One possibility would be to start in the AAAARCH Research Group. I think this would be a reasonable thing to do, and would allow archtiteture and research issues to be discussed and documented. Would others be interested in doing this? > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From yohba@tari.toshiba.com Thu Feb 13 23:21:17 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 13 Feb 2003 18:21:17 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: References: <20030213211359.GG760@catfish> Message-ID: <20030213232117.GB1163@catfish> On Thu, Feb 13, 2003 at 01:11:52PM -0800, Bernard Aboba wrote: > > Is the proxy also applicable to EAP TLS? > > Sure. In fact with EAP TLS there is no need to go back to the > authentication server at all. See: > > http://www.drizzle.com/~aboba/IEEE/draft-ietf-roamops-cert-02.txt Thank you for sending the URL. I'll read it. > > > > Existing EAP methods already do this. EAP TLS includes a finished message > > > that MICs previous messasges. So it really isn't an EAP issue at all. > > > > What about fragmentated PEAP messages that may be exchanged after TLS > > handshake? > > You won't normally see fragmentation unless a cert-based protocol is being > run within the tunnel -- and there's no reason to run such a protocol. > Some authentication might require machine certficiate and user certificate. Even a non-cert-based authentication method may generate large-sized authentication data. Yoshihiro Ohba From aboba@internaut.com Fri Feb 14 00:13:01 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Feb 2003 16:13:01 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <20030213232117.GB1163@catfish> Message-ID: > Even a non-cert-based authentication method may generate large-sized > authentication data. I'm not aware of any EAP method not involving certs that supports fragmentation. From james.d.carlson@east.sun.com Fri Feb 14 13:56:57 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 14 Feb 2003 08:56:57 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: Bernard Aboba's message of 13 February 2003 13:31:10 References: <15947.63248.254321.317448@gargle.gargle.HOWL> Message-ID: <15948.62889.631390.92418@gargle.gargle.HOWL> Bernard Aboba writes: > > 3. The authenticator ends the authentication phase with a Success or > > Failure packet. > > Sure. The authenticator ends the conversation -- this doesn't say that the > peer has to enable the link based on such an indication. I think that's perhaps missing the point. I wasn't talking about EAP Success. We were talking about whether it was legitimate to add language to the draft that allows an implementation to ignore EAP Failure under some circumstances. I don't believe that's a valid choice. > > This proposed change is now saying that the authentication phase can > > continue along if (in one peer's opinion? both? the method's > > judgement? EAP itself? how do we know?) the Failure is somehow > > deemed as "unacceptable." > > I would agree that it is necessary to act on the Failure after the method > is complete, if only because of sequences. But if the method fails at any > point, then the peer can disconnect at will - whether or not an EAP Success is received. If you're expecting some sort of interoperability to occur here, I think you need to specify how you want EAP Failure to be treated. The default today is that EAP Failure ends the authentication session. If we change this such that EAP Failure sometimes does *not* end the authentication session, then I think that all we've achieved is to add new ways that implementations can fail to interoperate in a reasonable manner. That is, if an authenticatee ignores EAP Failure, but the message itself was perfectly valid, then the authenticatee will have to wait until some internal timeout to give up on the non-converging session, and the failure reported will likely be wrong. This seems like a bad thing to me, especially so since the functionality proposed doesn't appear to address the DoS problem in a complete way. > > This is new in comparison to 2284, and looks to me to be hard to > > implement in an interoperable manner, because it requires that > > everyone always agrees on which precise timing is "valid," and > > differing interpretations will cause hangs. > > A method that has its own mechanisms for completing unsuccessfully will > not send an EAP Failure prior to method completion. If the client knows > that it is using such a method, then it also knows that an EAP Failure is > not an allowable packet until the state machine reaches a terminal state, > and can discard such a packet if received. How about for methods that do *NOT* have such mechanisms, and yet have multiple rounds? Are we now requiring that all methods that require multiple rounds MUST define a "protected failure" message? I suppose I would have less trouble with this if it were described in a method document. That is, if some wacky method decided to say something like, "EAP Failure can't occur between messages A and B, so if one is received, it should be ignored," then I'd have less trouble with it. I do have trouble with putting such a thing in the base document. I suspect that an underlying issue here is that you might be trying to document the actual implementation details, such as APIs used for method/EAP interfaces, and thus you want to be able to document all the quirks that might be possible here. I don't think that's a good idea at all. > > It's still not clear to > > me precisely when one is "in the middle of" a method, and when one is > > not. If I'm in the middle of a multi-method sequence (however > > unlikely), but between methods, am I vulnerable to unexpected EAP > > Failure? > > We're only talking about "in the middle of" a single method. Sequences are > another issue, and I agree that there is a vulnerability to unexpected > EAP Failure where sequences can be used. So, then, what's the point? All I have to do is flood the authenticatee with EAP Failure messages, and one of them is bound to make it there after the last (or only) method is complete but before the legitimate server has issued EAP Success. I don't see that this language has actually fixed anything. > > Agreed, and that's the problem. The problem is in the transport > > mechanism that EAP is using. That transport violates the assumptions > > made by EAP -- in particular, that it's a point-to-point link, and > > thus has no possibility of any sort of interception or injection. > > But if you look at the protocol, it really wouldn't be different in many > respects if the transport were UDP. I strongly disagree with that. First of all, if it were UDP, then reordering and duplication would need to be considered and handled, and they're not. Additionally, if it were UDP, one would have to consider man-in-the-middle and message injection cases, and they're not. I think part of the problem is that we're not distinguishing among two very different things: EAP as the PPP-derived signaling mechanism, replete with Identifiers and retransmission, and EAP as the method- related messaging system. The two are already different -- EAP on the wire is not the same protocol as EAP encapsulated in AAA. I suggest that the former is of much lower importance, and might be made medium- specific, and that the latter is of very high importance, and is the area where "preserving the existing implementation base" is a key concern. > There are no keys at the start, so you > couldn't MIC the Identity or Nak. About the only thing you could do differently is to > MIC the Failure (if you have a key) or the Success. If you had to support > methods that only did one-way auth, you couldn't even guarantee that you'd > be able to do that, because you might not have a key. So it seems to me > that the "assumptions" of EAP are largely derivable from the basic > scenario of network access authentication. That doesn't look right to me for two reasons. First, let's suppose you do have some sort of EAP mechanism that defines a MIC. If you have that, then there's clearly some point in the exchange at which MIC is enabled and un-MIC'd messages are no longer allowed. Once that point is reached, from EAP's point of view, there's no such thing as *ANY* message that doesn't have a valid MIC. It's exactly the same as a CRC. You don't have to write language into the EAP draft to say specifically that EAP Failure messages with a bad CRC are ignored, and you thus don't have to write language into the draft that says that messages with a bad or missing MIC are ignored. For that reason, I think that any language that attempts to describe the handling of MIC'd and un-MIC'd messages is flawed because it provides the incorrect idea that (somehow) there are cases where MIC becomes "optional" after being enabled. Yes, I'm specifically saying that burying the MIC into the method itself, and failing to protect all other subsequent EAP messages with it, is a design mistake. Second, I disagree that what you're suggesting is really impossible. Let's suppose we design a new transport for EAP to be used on non- point-to-point media. One part of that transport could be the generation of a session context and a key exchange *before* any EAP messages are used. It looks like a walk off into certificate-land, but someone who needs to handle arbitrary multi-access cases needs that anyway. > > If we do that, then I think we need to push this down lower: the MIC > > needs to occur at a sublayer between EAP and the next level down. It > > needs to protect EAP against the sort of corruption you're describing. > > Trying to build it into EAP, when EAP was *not* designed to do this, > > just leads to trouble. > > That's like saying that a MIC needs to be built into IP in order to be > used in protocols like IPsec. IPsec ESP or AH are built as shims on top of > IP, yet they can cover portions of the IP header directly (AH) or > indirectly (ESP through the TCP/UDP pseudo-header). I don't think the analogy holds up very well. When you're using IPsec (by coincidence, I actually am right now ;-}), the MIC really is built into IP, because, by policy, all unprotected messages are discarded. The fact that the implementation is realized as a shim header is really an artifact of the way IP was designed, not of how the MIC works. TCP doesn't have and doesn't need language to describe what you do with AH'd and non-AH'd segments. > Similarly, you could > build an EAP method with a per-packet MIC in each packet without having to > change EAP at all. The problem is that you're still allowing some of EAP to be unprotected. To make the analogy with IPsec work, you need to have a way to protect all the messages. (And EAP doesn't have a mechanism to insert shim headers.) > > The requirement flows the other direction, in my estimation. In other > > words, EAP doesn't need to care about this. For methods that have > > multiple rounds, *AND* where the security model of the method requires > > for the authenticatee that all the rounds are completed (i.e., mutual > > authentication), then it makes sense to say that EAP Success before > > that point is really a failure indication. Otherwise, the "in the > > middle" definition is not useful, and serves only to create new > > complexity and corner cases that weren't present in 2284. > > Since the peer can't know what methods are going to be run, it is hard to > apply this in practice. However, the peer *can* know whether the EAP > method it is currently running is complete or not, and whether Failure or > Success is expected. Right. Thus, as I suggest, it would make some sense to treat an unexpected EAP Success as though it were EAP Failure. It's the "Error: peer is an idiot" case, and, as noted many times, either peer can disconnect at any time for any reason. Idiocy on the peer's part is a darned good reason to disconnect. However, simply discarding either EAP message makes no sense, and is contrary to the intent of 2284. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Fri Feb 14 14:49:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Feb 2003 06:49:29 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15948.62889.631390.92418@gargle.gargle.HOWL> Message-ID: To start off, I should say that I agree that discarding EAP Failure messages can be problematic, and that we should probably stop at trying to avoid spoofing of EAP Success. But I couldn't resist replying to your message anyway :) > How about for methods that do *NOT* have such mechanisms, and yet have > multiple rounds? Then EAP Failure needs to be accepted and processed, as stated in the proposed text. > Are we now requiring that all methods that require multiple rounds > MUST define a "protected failure" message? No. > I suppose I would have less trouble with this if it were described in > a method document. That is, if some wacky method decided to say > something like, "EAP Failure can't occur between messages A and B, so > if one is received, it should be ignored," then I'd have less trouble > with it. I do have trouble with putting such a thing in the base > document. Since in many implementations EAP Failure messages are not sent to the method, this is typically not something that the method can control. > I suspect that an underlying issue here is that you might be trying to > document the actual implementation details, such as APIs used for > method/EAP interfaces, and thus you want to be able to document all > the quirks that might be possible here. I don't think that's a good > idea at all. I'd agree that documenting APIs is a bad idea. But documenting on the wire behavior seems reasonable. And some implementations do things along the lines of what 4.2.1 describes (though perhaps we should hear more about exactly what their behavior is). > So, then, what's the point? All I have to do is flood the > authenticatee with EAP Failure messages, and one of them is bound to > make it there after the last (or only) method is complete but before > the legitimate server has issued EAP Success. I agree that adding support for sequences creates a security vulnerability of this kind. > I don't see that this language has actually fixed anything. It may not have. > I strongly disagree with that. First of all, if it were UDP, then > reordering and duplication would need to be considered and handled, > and they're not. UDP doesn't provide any support for reordering or duplicate elimination. It's all the responsibility of the application. What is it about EAP that makes these services impossible for an EAP method to provide? > Additionally, if it were UDP, one would have to > consider man-in-the-middle and message injection cases, and they're > not. UDP doesn't provide any support for man-in-the-middle or message injection detection. This is all done in the upper layers -- look at IKE [RFC2409]. So again, I'm not clear what services UDP provides that EAP does not that makes this possible for UDP applications, but somehow impossible for EAP methods. > The two are already different -- EAP on the > wire is not the same protocol as EAP encapsulated in AAA. I suggest > that the former is of much lower importance, and might be made medium- > specific, and that the latter is of very high importance, and is the > area where "preserving the existing implementation base" is a key > concern. In practice, it would be very difficult to write methods that would operate on all media if EAP itself were media dependent. This would require the NAS to act as an "EAP translation gateway", wouldn't it? > It's exactly the same as a CRC. You don't have to write language into > the EAP draft to say specifically that EAP Failure messages with a bad > CRC are ignored, and you thus don't have to write language into the > draft that says that messages with a bad or missing MIC are ignored. If we had EAP Success and Failure messages with an embedded MIC field, it would operate as you say. Note that the MIC could only be verified by the peer, because the NAS never receives the keys used in generation of EAP MICs, only the MSK, which is crytographically independent of any of the EAP method transient session keys. The question is: what happens if the EAP Failure packet fails the MIC? Since EAP Failure is not retransmitted, the only response the peer can have is "silent discard" -- and so an attacker could send a peer an EAP Failure with a bad MIC and end the conversation, just as if the MIC wasn't here at all. That means that in practice a MIC'd EAP Failure, without adding retransmission, would accomplish nothing. In practice, I think a three way handshake is probably required, and then we are really talking about a Success/Failure method -- which would require sequence support. > provides the incorrect idea that (somehow) there are cases where MIC > becomes "optional" after being enabled. That is true. It's not optional. > Yes, I'm specifically saying that burying the MIC into the method > itself, and failing to protect all other subsequent EAP messages with > it, is a design mistake. This is also true -- but the question is whether it is possible to introduce MIC'd success and failure indications and maintain backward compatibility. > One part of that transport could be the > generation of a session context and a key exchange *before* any EAP > messages are used. How is that different than introduction of an EAP method that does the same thing? You can write an EAP method today that does DH, and then tunnels EAP methods. In fact, this is exactly what EAP TTLS and PEAP do, when they negotiate DH key exchange within TLS. If that method were to run with no initial identity exchange, and in a situation where both parties mandated its use, the wire exchanges could be made to look very similar. > I don't think the analogy holds up very well. When you're using IPsec > (by coincidence, I actually am right now ;-}), the MIC really is built > into IP, because, by policy, all unprotected messages are discarded. That depends on the IPsec policy. > The fact that the implementation is realized as a shim header is > really an artifact of the way IP was designed, not of how the MIC > works. IPv6 was designed to require IPsec support, and yet IPsec functionality wasn't folded into the IPv6 header. So it seems more like a layering decision than an artifact of IPv4's design. > TCP doesn't have and doesn't need language to describe what you do > with AH'd and non-AH'd segments. Yes. > The problem is that you're still allowing some of EAP to be > unprotected. To make the analogy with IPsec work, you need to have a > way to protect all the messages. (And EAP doesn't have a mechanism to > insert shim headers.) The Identity exchange is optional, so this can be ommitted entirely. If the method is made mandatory and is supported on both sides, there is no Nak Response. That means that the only messages (other than Notification which doesn't change state) that are unprotected are the EAP Success and Failure messages. As I argued previously, merely adding a MIC to those messages wouldn't help without also adding support for retransmission. As for shim headers, several EAP methods implement them already. This is what EAP TTLS and PEAP do. They can't be inserted in Identity, and Nak messages, but I'd argue that since there are no keys when those messages are typically sent, including a shim in those messages would do no good anyway. > Right. Thus, as I suggest, it would make some sense to treat an > unexpected EAP Success as though it were EAP Failure. It's the > "Error: peer is an idiot" case, and, as noted many times, either peer > can disconnect at any time for any reason. Idiocy on the peer's part > is a darned good reason to disconnect. However, simply discarding > either EAP message makes no sense, and is contrary to the intent of > 2284. From aboba@internaut.com Fri Feb 14 15:15:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Feb 2003 07:15:54 -0800 (PST) Subject: [eap] Issue 86: Separation of EAP server and authenticator Message-ID: Issue 86: Separation of EAP server and authenticator Submitter name: Henrik Levkowetz Submitter email address: henrik.levkowetz.com Date first submitted: February 14, 2003 Document: EAP-00 Comment type: Technical Priority: S Section: 7.X Rationale/Explanation of issue: There's one section of the original Issue 73 which I feel we may have lost track of. We were talking about the injection of failure or success packets between the authenticator and the eap server, and you mentioned possibly stealing some text from 2869bis; I replied something like the following on Feb 7: There is some text there, but as it is talking about the RADIUS case, not all is applicable, and it does not specifically talk about the case of the unprotected generic EAP Success and Failure messages. I propose a new section: "7.xx Separation of EAP server and authenticator It is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to derive and pass a Transient Session Key (TSK) to the ciphersuite module. However, in the case where the EAP server and authenticator reside on different machines, there are several implications for security. [a] Authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone. [b] As discussed in [RFC2869bis], the authenticator is dependent on the AAA protocol in order to know the outcome of an authentication conversation, and does not look at the encapsulated EAP packet (if one is present) to determine the outcome. In practice this means that the AAA protocol spoken between the authenticator and authentication server MUST support per-packet authentication, integrity and replay protection. [c] A EAP Master Session Key (MSK) negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the EAP server to the authenticator or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. " Henrik From aboba@internaut.com Fri Feb 14 15:16:39 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Feb 2003 07:16:39 -0800 (PST) Subject: [eap] Re: Issue 86: Separation of EAP server and authenticator In-Reply-To: Message-ID: I would like to propose that we accept the change suggested by Henrik in Issue 86. On Fri, 14 Feb 2003, Bernard Aboba wrote: > Issue 86: Separation of EAP server and authenticator > Submitter name: Henrik Levkowetz > Submitter email address: henrik.levkowetz.com > Date first submitted: February 14, 2003 > Document: EAP-00 > Comment type: Technical > Priority: S > Section: 7.X > Rationale/Explanation of issue: > > There's one section of the original Issue 73 which I feel we may have > lost track of. We were talking about the injection of failure or > success packets between the authenticator and the eap server, and > you mentioned possibly stealing some text from 2869bis; I replied > something like the following on Feb 7: > > There is some text there, but as it is talking about the RADIUS case, > not all is applicable, and it does not specifically talk about the > case of the unprotected generic EAP Success and Failure messages. > I propose a new section: > > "7.xx Separation of EAP server and authenticator > > It is possible for the EAP peer and authenticator to mutually > authenticate, and derive a Master Session Key (MSK) for a ciphersuite > used to protect subsequent data traffic. This does not present an > issue on the peer, since the peer and EAP client reside on the same > machine; all that is required is for the EAP client module to derive > and pass a Transient Session Key (TSK) to the ciphersuite module. > > However, in the case where the EAP server and authenticator reside on > different machines, there are several implications for security. > > [a] Authentication will occur between the peer and the EAP server, > not between the peer and the authenticator. This means that it is > not possible for the peer to validate the identity of the NAS or > tunnel server that it is speaking to, using EAP alone. > > [b] As discussed in [RFC2869bis], the authenticator is dependent > on the AAA protocol in order to know the outcome of an > authentication conversation, and does not look at the encapsulated > EAP packet (if one is present) to determine the outcome. In > practice this means that the AAA protocol spoken between the > authenticator and authentication server MUST support per-packet > authentication, integrity and replay protection. > > [c] A EAP Master Session Key (MSK) negotiated between the peer and > EAP server will need to be transmitted to the authenticator. > Therefore a mechanism needs to be provided to transmit the MSK > from the EAP server to the authenticator or tunnel server that > needs it. The specification of the key transport and wrapping > mechanism is outside the scope of this document. > " > > Henrik > > > > From jari.arkko@piuha.net Sun Feb 16 08:06:15 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 16 Feb 2003 10:06:15 +0200 Subject: [eap] state machine design team minutes, feb 12th, 2003 Message-ID: <3E4F4677.9030402@piuha.net> EAP State Machine Design Team conference call minutes Date: Wednesday, February 12, 2003 Time: 8-9 AM PST Scribe: Jari Arkko o Participants: Jari Arkko, Bob Moskowitz, Nick Petroni, Chuk Yang Seng, John Vollbrecht, Bernard Aboba, Paul Congdon (maybe more) o Agenda - Discussion of EAP Issues http://www.drizzle.com/~aboba/EAP/eapissues.html - Discussion of EAP state machine document http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps o Issue 74 -- Concern on an invalid MIC This issue relates to the handling of duplicates, particularly by passthrough authenticators when the method supports a per-message MIC. John: Normally you have a MIC as a part of a method. You could specify perhaps it at an eap level, but not clear how to do it. Nick: The way I read it, is that if you have a fragment, the passthrough sends the wrong packet to the AAA and the real packet will be throgh away. Bob: This is very hard, we shouldn't open even the discussion. Bernard: It is an EAP state machine issue, not MIC specific. its really about duplicate elimination. John: One possibility is to allow MICs. The mechanics were that in a passthrough you would forward responses to the backend. When it sends the next request you would start waiting for new messages. Bernard: That's the way things work now. the identifier doesn't change until a new request arrives. All this means that you don't silently discard until you get a new request. Bernard: You don't send all the messages to AAA at once, because it is illegal in RFC 2869. In all cases if the mic fails you will send a reject. John: We need a message that says "I got it but its not good". Bernard: In RADIUS, we can't send new Access-Requests until a response is received. In RFC 2869bis, instead of sending a new request, the AAA server sends an EAP-Start as a response. Then the NAS continues to expect more messages from the peer. Jari: This makes sense to me. Nick (?): I'm not sure. (After some clarifications we finally agree: 1. We must hold on to messages and 2. One message at a time to AAA.) Question: Is the MIC per fragment or per "message" that makes sense to the method? Jari: MIC has to be per fragment. Otherwise you can get to a situation where you have to accept a fragement, but will detect later that there's been a bad fragment. At this point, it is no longer possible to reject the fragment. Bernard: Existing methods such as EAP TLS work, because MIC failure is fatal. but allows the construction of methods that do. John: We should not talk too much about MICs in the documents. Bernard: Yes. Need to restructure the documents and take the MIC text somewhere else. Paul: I wonder if it should be a new message and not EAP-Start. John: I agree. Bernard: It has to be EAP-Start. John: Yoshi's argument on the list: If there's a DoS attack, you should just start over again. Jari: There's a difference in building in MICs vs. fixing the state machine so that it works the same way for passthrough and regular authenticators. Bernard: We need to do this to clarify the specification. John: I fear state machine fix is not easy. Bernard: Your state machine does this now! Paul: Isn't this the only way to fix DoS attacks? John: This may make attacks different or worse, not completely fixable. Bernard: Its the same issue as in TLS vs. IPsec; TLS is vulnerable to MitMs and as a result the peers may have to start all over again. John: The the SIM example: the choices are stopping or handling all packets. Not sure about which uses more resources, cpu, memory etc. Bernard: The same issue is in 802.11i CCMP vs. TKIP protection. Bernard: If you look at protocols and literature, the agreement is that silent discard is the right thing to do. All new protocols do that. John: I'm not sure its worth it. Jari: I'm not sure either, but I'd like to get back to my earlier argument about other reasons e.g. make the behaviour over passthroughs and integrated NAS-AAA the same -- we don't have to decide about MICs right now. But I'd like to have a protocol that behaves the same way in all cases, regardless of the usefulness of the MICs in potential future methods. Bernard: I agree. Bernard: Take the EAP SIM as an example. It would be possible to protect messages with a MIC in there. Jari: I don't think we do it right now. Bernard: And there's a few messages in the beginning that can't yet be protected before the keys are in place. Paul: We need to reset timers when you get EAP-Start. Jari: Why? Paul: Because when the access-request is sent, the timers are stopped. Jari: Ok. Bernard: There's an additional reason to do what we are suggesting here. We may need to do this because not all EAP transports use a CRC -- so even a bad packet could get to an authenticator and cause the whole process to restart. Bernard: Here's what I think we have now concluded: - RFC 2869bis will have 4 week IETF last call. - We will take all MIC discussion out of the docuemnts. - RFC 2284bis will not to discuss this issue at all. - RFC 2869bis will expect new message identity only after receiving a new request from AAA. - We will ask Bill Arbaugh's opinion on the DoS issue. Bernard: The only question in my mind is if a method would actually use this? Someone: I would think the per-fragment issue would make things hard anyway. John: DoS not defendable anyway. Bernard: EAP, RADIUS have been found to be the most vulnerable in future WLAN networks, not 802.11i! Bob: There's interesting attacks on EAP. For instance, override messages against eap servers. John: We should document these issues. Bernard: We should have an appendix in RFC 2284bis that talks about these issues and warns implementors. Question: Is the new duplicate detection scheme for passthroughs mandatory? And for who? Bernard: Its optional for the AP. John: No, it needs to be mandatory. Bernard: Ok. Question: What is the backwards compatibility? (No answer) John: There's a problem in that when this retry process is going on with the AAA server and NAS, you tie up the client too, because the client hasn't got a failure back yet. Jari: Bernard said this kind of functionality already in 802.1aa. John: No problem with that. Nick: The only question is what to do with the new request, should it be retransmitted or not? (Unclear to participants if something needs to be done or not). John: No problem with EAP start that I know of. o Status of the state machine drafts Jari: What is the status of the state machine drafts? Nick: We are reluctant to put anything forward until all issues resolved. Jari: Everything included that we have agreed? Nick: Probably, not sure. John: DoS issues unclear also in the state machine. Nick: Also, not all agreements are clear. Paul (?): Can we articulate the unclear points and the assumptions? Nick: I will post this together with John. From aboba@internaut.com Sun Feb 16 15:41:33 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 16 Feb 2003 07:41:33 -0800 (PST) Subject: [eap] Another shot at Issue 80 Message-ID: Based on the recent discussion, here is another try at resolving Issue 80. 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. EAP Success and Failure packets may be spoofed, since as described in Section 4.2, they contain no message integrity check (MIC). They are therefore considered unprotected. EAP methods also MAY include support for acknowledged success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated to it, 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), (see Section 7.13) and if so, then these success/failure indications are considered protected. In order to decrease vulnerability to spoofing of success and failure indications, the following implementation advice is provided: [a] Authentication requirement. Where mutual authentication is required, and the authenticator fails to authenticate successfully to the peer, the peer SHOULD silently discard an EAP Success packet. This implies, for an example, that a peer configured to require mutual authentication will not consider authentication to be successful on receipt of a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [b] Orderly termination. Methods may define states in which an EAP Failure message is unexpected. For example, once a method derives a key, it may require that a protected error message be sent prior to termination. When such methods are run, an EAP Failure message MAY be silently discarded in keeping with the method specification. [c] Processing of EAP Success and Failure. With the exception of the above cases, EAP Success and Failure packets are accepted and processed by the EAP implementation." From aboba@internaut.com Sun Feb 16 16:11:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 16 Feb 2003 08:11:14 -0800 (PST) Subject: [eap] Re: Issue 74 Message-ID: Here is another shot at resolving Issue 74: "7.13 Message Integrity Checks Typically, EAP methods such as EAP-TLS [RFC2716] treat message integrity check (MIC) failures as a fatal error. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet. If a per-packet Message Integrity Check (MIC) is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC and SHOULD silently discard any message that fails verification. Alternatively, a MIC validation failure MAY be considered a fatal error. In this document, the descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code'). Today, EAP methods commonly define MICs that cover more than one EAP packet. For example, EAP methods such as EAP-TLS [RFC2716] define a MIC covering an extended PDU that could be split into multiple fragments, or that can cover portions of earlier messages (FINISHED message). Once an EAP method derives keys it may be desirable to exchange MICs that cover otherwise unauthenticated packets, (such as the Identity Request/Response, Notification Request/Response or Nak Response) so as to be able to detect forgeries after the fact. Where the MIC covers more than one EAP packet, a failure to validate the MIC will typically be considered a fatal error." From aboba@internaut.com Sun Feb 16 16:14:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 16 Feb 2003 08:14:38 -0800 (PST) Subject: [eap] Proposed resolution to Issue 75: Terminology wording Message-ID: I would like to propose that the changes recommended in Issue 75 be accepted. Any objections? ========================================================== Issue 75: Terminology wording Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: Feburary 3, 2003 Document: RFC2284bis-10 Comment type: Editorial Priority: 1 Section: 1.2 Rationale/Explanation of issue: Item 1: authenticator description Rationale: EAP is a peer to peer protocol, supporting methods that do mutual authentication as well as methods that authenticate the user or server alone. Change: "authenticator The end of the link requiring the authentication. This terminology is also used in [IEEE.802-1X.2001], and has the same meaning in this document." to: "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]." --------------------------- Item 2: peer description Rationale: same as above, plus I think it is unnecessary to give examples of the media in the peer. If needed, perhaps a separate category could be created to describe the "link". I personally don't think that is necessary. suggested change: change: "peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802 wired media) or 802.11 wireless link, which being authenticated by the authenticator. In [IEEE.802-1X.2001], this end is known as the Supplicant." to: "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." --------------------------- Item 3: backend authentication server Rationale: the description is too wordy and implies that the backend server is required for EAP. change: "backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. This service verifies from the credentials provided by the peer, the claim of identity made by the peer. This terminology is also used in [IEEE.802-1X.2001]." to: "backend authentication server A backend authentication server is an entity that provides 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]." From jrv@umich.edu Mon Feb 17 21:15:25 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 17 Feb 2003 16:15:25 -0500 Subject: [eap] Re: Issue 74 In-Reply-To: References: Message-ID: <2210540.1045498524@[10.0.1.2]> I think that this is good text, but belongs in an appendix for methods. I don't think anything is needed in EAP RFC other than to say that Intgegrity checking is not supported in the EAP layer. Methods may support it. -- John --On Sunday, February 16, 2003 8:11 AM -0800 Bernard Aboba wrote: > Here is another shot at resolving Issue 74: > > "7.13 Message Integrity Checks > > Typically, EAP methods such as EAP-TLS [RFC2716] treat message > integrity check (MIC) failures as a fatal error. However, > it is also possible to develop EAP methods that support > per-packet MICs, and respond to verification failures by > silently discarding the offending packet. > > If a per-packet Message Integrity Check (MIC) is employed > within an EAP method, then peers, authentication > servers, and authenticators not operating in pass-through > mode MUST validate the MIC and SHOULD silently discard > any message that fails verification. Alternatively, a > MIC validation failure MAY be considered a fatal error. > > In this document, the descriptions of EAP message handling > assume that per-packet MIC validation, where it occurs, > is effectively performed as though it occurs before > examining any of the EAP message fields (such as 'Code'). > > Today, EAP methods commonly define MICs that cover more than one > EAP packet. For example, EAP methods such as EAP-TLS [RFC2716] > define a MIC covering an extended PDU that could be split > into multiple fragments, or that can cover portions of earlier > messages (FINISHED message). > > Once an EAP method derives keys it may be desirable to > exchange MICs that cover otherwise unauthenticated packets, > (such as the Identity Request/Response, Notification > Request/Response or Nak Response) so as to be able to > detect forgeries after the fact. > > Where the MIC covers more than one EAP packet, a failure > to validate the MIC will typically be considered a fatal error." > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Mon Feb 17 20:07:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 17 Feb 2003 12:07:20 -0800 (PST) Subject: [eap] Re: Issue 74 In-Reply-To: <2210540.1045498524@[10.0.1.2]> Message-ID: > I think that this is good text, but belongs in an appendix for methods. Can you clarify what an "appendix for method" is? > I don't think anything is needed in EAP RFC other than to say that > Integrity checking is not supported in the EAP layer. Methods may support it. But an Appendix is part of the document, isn't it? From jrv@umich.edu Mon Feb 17 21:25:55 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 17 Feb 2003 16:25:55 -0500 Subject: [eap] Another shot at Issue 80 In-Reply-To: References: Message-ID: <2248307.1045499154@[10.0.1.2]> This is better. some editorial suggestions in line --On Sunday, February 16, 2003 7:41 AM -0800 Bernard Aboba wrote: > Based on the recent discussion, here is another try at resolving Issue 80. > > 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. > EAP Success and Failure packets may be spoofed, since **remove** (as described in Section 4.2,) they contain no message integrity check (MIC). They are > therefore considered unprotected. > > EAP methods also MAY include support for acknowledged > success and failure indications. **insert**( This is described in appendix XX) **move to appendix** (This enables the authenticator to > indicate whether the peer has successfully authenticated to it, 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), > (see Section 7.13) and if so, then these success/failure indications are > considered protected.) > > In order to decrease vulnerability to spoofing of success and failure > indications, the following implementation advice is provided: > > [a] Authentication requirement. Where mutual authentication > is required, and the authenticator fails to authenticate > successfully to the peer, the peer SHOULD silently discard > an EAP Success packet. > > This implies, for an example, that a peer configured to > require mutual authentication will not consider > authentication to be successful on receipt of a "canned" > EAP Success message (an EAP Success message sent > immediately upon connection). > > [b] Orderly termination. Methods may define states in which > an EAP Failure message is unexpected. For example, once > a method derives a key, it may require that a protected > error message be sent prior to termination. When such > methods are run, an EAP Failure message MAY be silently discarded > in keeping with the method specification. **discuss** I am not sure we have consensus on this. the problem is with sequences which may fail even if the authentication method succeeds. > > [c] Processing of EAP Success and Failure. With the exception > of the above cases, EAP Success and Failure packets are > accepted and processed by the EAP implementation." **discuss** I am again not sure we have consensus on this. We still have to know when an "inappropriate" success or fail occurs, so it is easy to silently discard. It does guard against some DOS attacks. I am not sure what criteria we use to decide if this is the right design. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From henrik@levkowetz.com Mon Feb 17 22:52:33 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 17 Feb 2003 23:52:33 +0100 Subject: [eap] New intermediate 2284bis draft -01.d Message-ID: <20030217235233.4534c0e5.henrik@levkowetz.com> Hi, I've put up a new intermediate 2284bis draft (-01.d) on http://www.levkowetz.com/pub/ietf/drafts/eap/ . Unless there's contrary comments, I plan to submit it as -01 tomorrow morning. Compared with the -01.b draft, the changes are: - Changed wording of 3 definitions [Issue 75]. - Added text on key strength in Section 7.2 [Issue 79]. - Rewritten text on response handling in Section 4.1 [Issue 82]. - Added Section 7.13 on security issues around the separation of authenticator and EAP server [Issue 86] As usual, there's html diffs and changebar marked text versions available. Regards, Henrik From aboba@internaut.com Mon Feb 17 22:30:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 17 Feb 2003 14:30:16 -0800 (PST) Subject: [eap] Another shot at Issue 80 In-Reply-To: <2248307.1045499154@[10.0.1.2]> Message-ID: > > [b] Orderly termination. Methods may define states in which > > an EAP Failure message is unexpected. For example, once > > a method derives a key, it may require that a protected > > error message be sent prior to termination. When such > > methods are run, an EAP Failure message MAY be silently discarded > > in keeping with the method specification. > **discuss** I am not sure we have consensus on this. the problem is with > sequences which may fail even if the authentication method succeeds. This case isn't about authentication methods which succeed. It's about receiving an EAP Failure in a state where the method says that isn't possible. > > [c] Processing of EAP Success and Failure. With the exception > > of the above cases, EAP Success and Failure packets are > > accepted and processed by the EAP implementation." > **discuss** I am again not sure we have consensus on this. We still have > to know when an "inappropriate" success or fail occurs, so it is easy to > silently discard. It does guard against some DOS attacks. I am not sure > what criteria we use to decide if this is the right design. Other than the cases above, EAP Success and Failure messages are processed normally. This is how they are handled in RFC 2284, no? From james.d.carlson@east.sun.com Tue Feb 18 14:29:01 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 18 Feb 2003 09:29:01 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: Bernard Aboba's message of 14 February 2003 06:49:29 References: <15948.62889.631390.92418@gargle.gargle.HOWL> Message-ID: <15954.17198.297465.436581@gargle.gargle.HOWL> Bernard Aboba writes: > > I suppose I would have less trouble with this if it were described in > > a method document. That is, if some wacky method decided to say > > something like, "EAP Failure can't occur between messages A and B, so > > if one is received, it should be ignored," then I'd have less trouble > > with it. I do have trouble with putting such a thing in the base > > document. > > Since in many implementations EAP Failure messages are not sent to the > method, this is typically not something that the method can control. I think this confuses specification and implementation. I specifically said "method document" -- not in the method itself, but in a document describing how that method works and is to be used. This could look like: "When using FooBar Authentication, it is not possible for the peer to report failure until after the Blah Message has been sent. Therefore, EAP implementations employing FooBar Authentication MUST discard any received EAP Failure or EAP Success message until Blah has been sent at least once." Now whether this is really a good thing or not is perhaps an issue to discuss when FooBar is proposed, but I don't see why it's a relevant issue for the EAP base document. The base document doesn't define exactly how these things work, so it shouldn't be defining how to handle them either. > > So, then, what's the point? All I have to do is flood the > > authenticatee with EAP Failure messages, and one of them is bound to > > make it there after the last (or only) method is complete but before > > the legitimate server has issued EAP Success. > > I agree that adding support for sequences creates a security vulnerability > of this kind. The vulnerability is there even without sequences. All I need is have sufficient access to the medium used to transport EAP messages, and I can flood the authenticatee with EAP Failure messages, and this attack is effective even when the EAP session has only one Request/Response exchange and no "sequences" or other fluff at all. Authenticatee Authenticator Bad Guy <- EAP Request EAP Response -> <------------------------ EAP Failure <- EAP Success Note that proper processing of EAP Response (checking for validity and such) is always harder and more time-consuming than blindly sending EAP Failure. The authenticator is thus at a permanent disadvantage to the Bad Guy. Note that there are no sequences at all above. There's not even an Identity exchange (which, I would argue, is a simple example of a sequence). Are you suggesting that having multiple rounds solves the problem? Try: Authenticatee Authenticator Bad Guy <- EAP Request 1 EAP Response 1 -> (ignored) <------------------------ EAP Failure <- EAP Request 2 EAP Response 2 -> <------------------------ EAP Failure <- EAP Success That seems to work just as well. Once the method is "done," there's still a hole into which the attacker can insert a Failure message. (Depending on the linkage to the L2, EAP Failure *before* the first EAP Request is also a possibility.) > > I strongly disagree with that. First of all, if it were UDP, then > > reordering and duplication would need to be considered and handled, > > and they're not. > > UDP doesn't provide any support for reordering or duplicate elimination. > It's all the responsibility of the application. What is it about EAP > that makes these services impossible for an EAP method to provide? I don't understand that response. We're clearly talking about different things here. EAP doesn't have reordering and duplication protection in its handling of Identification numbers, and it relies on the underlying transport for this. UDP can reorder and duplicate messages. Therefore, running 2284 EAP over UDP isn't possible. It won't work because UDP is an unsuitable transport for EAP. Are you proposing that this basic design feature of EAP (assuming point-to-point links) is to be fixed via clever method implementations? I fail to see how that would be a good thing to pursue. It doesn't seem likely given the way Identification numbers are handled. > > Additionally, if it were UDP, one would have to > > consider man-in-the-middle and message injection cases, and they're > > not. > > UDP doesn't provide any support for man-in-the-middle or message injection > detection. This is all done in the upper layers -- look at IKE [RFC2409]. > So again, I'm not clear what services UDP provides that EAP does not that > makes this possible for UDP applications, but somehow impossible for EAP > methods. I'm not comparing UDP and EAP. I'm comparing UDP and other possible transports for carrying EAP around (such as PPP). Here's the original exchange: > > Agreed, and that's the problem. The problem is in the transport > > mechanism that EAP is using. That transport violates the assumptions > > made by EAP -- in particular, that it's a point-to-point link, and > > thus has no possibility of any sort of interception or injection. > > But if you look at the protocol, it really wouldn't be different in many > respects if the transport were UDP. Yes, it would be quite different if the underlying transport for EAP were UDP. You'd have windowing on the Identification numbers, and you'd have to consider the many different ways in which modified or inserted messages could corrupt the negotiation state (or you'd have to [effectively] mandate the use of IPsec to avoid the problem, a la L2TP). EAP in 2284 doesn't have any of that. What I think you're saying is that we could have EAP methods that provide protection to the exchange in a manner similar to IPsec. However, that proposal falls apart unless there's specific support in EAP or in the lower layers, because, unlike UDP, EAP is quite stateful. The Identification numbers provide a state mechanism that's plainly outside of any sort of protection, and therefore breakable. It seems to me that the options are: (1) Add a way to carry MIC in all EAP messages -- add it as part of the base 2284bis document. This seems like a mostly good idea, though I'd like to see how it could be done in a reasonably compatible manner. (2) Describe a new mechanism to carry EAP messages on media where the problem exists (i.e., my EAPv2 proposal-in-cheek that I made to PANA). > > The two are already different -- EAP on the > > wire is not the same protocol as EAP encapsulated in AAA. I suggest > > that the former is of much lower importance, and might be made medium- > > specific, and that the latter is of very high importance, and is the > > area where "preserving the existing implementation base" is a key > > concern. > > In practice, it would be very difficult to write methods that would > operate on all media if EAP itself were media dependent. This would > require the NAS to act as an "EAP translation gateway", wouldn't it? It does already. On PPP, you have to retransmit Request messages. On 802.1X, you do not. On AAA, it's backwards, with the Response messages driving the authentication progress (rather than Requests), and retransmission of the EAP Responses, not Requests. It seems to me to be a fundamental aspect of the protocol that it *already* appears different on different media, and a NAS *does* act as a translating gateway. The fact that it doesn't have to look at the contents of the messages in some cases seems to be a minor detail -- the behavior itself is quite different on all these interfaces. I don't see how that's a problem. > > It's exactly the same as a CRC. You don't have to write language into > > the EAP draft to say specifically that EAP Failure messages with a bad > > CRC are ignored, and you thus don't have to write language into the > > draft that says that messages with a bad or missing MIC are ignored. > > If we had EAP Success and Failure messages with an embedded MIC field, > it would operate as you say. Note that the MIC could only be verified by > the peer, because the NAS never receives the keys used in generation of > EAP MICs, only the MSK, which is crytographically independent of any of > the EAP method transient session keys. I'm suggesting that you don't really have MICs unless you have EAP Success and Failure with an embedded MIC field. > The question is: what happens if the EAP Failure packet fails the > MIC? Why is that a special question with a different answer from what you do when EAP Success, EAP Request, or EAP Response fails MIC? > Since EAP Failure is not retransmitted, the only response the peer > can have is "silent discard" -- and so an attacker could send a peer > an EAP Failure with a bad MIC and end the conversation, just as if the > MIC wasn't here at all. That means that in practice a MIC'd > EAP Failure, without adding retransmission, would accomplish nothing. > In practice, I think a three way handshake is probably required, and > then we are really talking about a Success/Failure method -- > which would require sequence support. ... or a different way of carrying EAP around on media where such concerns are valid. > > Yes, I'm specifically saying that burying the MIC into the method > > itself, and failing to protect all other subsequent EAP messages with > > it, is a design mistake. > > This is also true -- but the question is whether it is possible to > introduce MIC'd success and failure indications and maintain backward > compatibility. It doesn't appear that this is so. Nor is it possible to protect Identification, Nak, and Notification, nor is any message's Identification number protected in any way. > > One part of that transport could be the > > generation of a session context and a key exchange *before* any EAP > > messages are used. > > How is that different than introduction of an EAP method that does the > same thing? There are at least two ways that it is different: (1) before this exchange, no EAP messages are possible, and after the exchange, all are protected from tampering, so there are no holes. (2) it doesn't require any change to any part of the base EAP protocol to support it; Failure and Success handling remain the same. > You can write an EAP method today that does DH, and then > tunnels EAP methods. In fact, this is exactly what EAP TTLS and PEAP do, > when they negotiate DH key exchange within TLS. They're still vulnerable to someone who wants to attack the weak points: EAP Nak, EAP Notification, EAP Success, EAP Failure, and the Identification numbers. > If that method were to run with no initial identity exchange, and in a > situation where both parties mandated its use, the wire exchanges could be > made to look very similar. Except that EAP Nak is still a possible and unprotected response from the authenticatee, and except that EAP Notification, Success, and Failure are possible unprotected messages from the authenticator. I think you have to outlaw quite a bit of EAP in order to make this work. Even if all that were worked out somehow, pass-through is a problem. The lack of Identification number protection means that arbitrary messages to the AAA server can be injected. > > I don't think the analogy holds up very well. When you're using IPsec > > (by coincidence, I actually am right now ;-}), the MIC really is built > > into IP, because, by policy, all unprotected messages are discarded. > > That depends on the IPsec policy. True, but the point is that we can have reasonable IPsec policies that don't harm the protocol. I don't see that the same is true for EAP. > > The fact that the implementation is realized as a shim header is > > really an artifact of the way IP was designed, not of how the MIC > > works. > > IPv6 was designed to require IPsec support, and yet IPsec functionality > wasn't folded into the IPv6 header. So it seems more like a layering > decision than an artifact of IPv4's design. Uh ... maybe. Everything in IPv6 was fobbed off onto extension headers. I think I'd say that the artifact was just made larger, though reasonable people might disagree. (Is a fragmentation header part of the transport? How about routing headers? Why consider just IPsec to be layered above and not these other extension headers?) > > The problem is that you're still allowing some of EAP to be > > unprotected. To make the analogy with IPsec work, you need to have a > > way to protect all the messages. (And EAP doesn't have a mechanism to > > insert shim headers.) > > The Identity exchange is optional, so this can be ommitted entirely. If > the method is made mandatory and is supported on both sides, there is no > Nak Response. That means that the only messages (other than > Notification which doesn't change state) Notification does change some state -- it changes the Identification number. It also likely involves activity outside of EAP (logging, pop-up messages, and so forth) that *CERTAINLY* requires authentication in this context -- if any EAP message needs it, then Notification should as well. Why ignore this? > that are unprotected are the > EAP Success and Failure messages. As I argued previously, merely adding a > MIC to those messages wouldn't help without also adding support for > retransmission. > > As for shim headers, several EAP methods implement them already. This is > what EAP TTLS and PEAP do. They can't be inserted in Identity, and Nak > messages, but I'd argue that since there are no keys when those messages > are typically sent, including a shim in those messages would do no good > anyway. I'm arguing that this (the lack of keys at the needed point) is a root cause of the problem, not an unsolvable issue. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From henrik@levkowetz.com Tue Feb 18 15:05:58 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 18 Feb 2003 16:05:58 +0100 Subject: [eap] draft-ietf-eap-rfc2284bis-01.txt Message-ID: <20030218160558.1ffdbcf1.henrik@levkowetz.com> Hi, After correcting a cut-and-paste error in the Section 7.2 text on key strength, pointed out by Pasi, I've submitted a -01 version of the 2284bis draft. It's also available at http://www.levkowetz.com/pub/ietf/drafts/eap/ . Regards, Henrik -- Survive. Socialize. Have fun. That's the progression -- Linus Torvalds From aboba@internaut.com Tue Feb 18 18:04:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 18 Feb 2003 10:04:22 -0800 (PST) Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: <15954.17198.297465.436581@gargle.gargle.HOWL> Message-ID: > This could look like: > > "When using FooBar Authentication, it is not possible for the > peer to report failure until after the Blah Message has been > sent. Therefore, EAP implementations employing FooBar > Authentication MUST discard any received EAP Failure or EAP > Success message until Blah has been sent at least once." This seems like a reasonable approach. I will try to add something like this to the Appendix text. > Now whether this is really a good thing or not is perhaps an issue to > discuss when FooBar is proposed, but I don't see why it's a relevant > issue for the EAP base document. The base document doesn't define > exactly how these things work, so it shouldn't be defining how to > handle them either. It could perhaps say that some behaviors are possible. > The vulnerability is there even without sequences. All I need is have > sufficient access to the medium used to transport EAP messages, and I > can flood the authenticatee with EAP Failure messages, and this attack > is effective even when the EAP session has only one Request/Response > exchange and no "sequences" or other fluff at all. Yes. As you say, it depends on the method. > EAP Failure *before* the first EAP Request is also a possibility.) Yes, if the peer is configured to support such "canned" responses that will work too. > 2284 EAP over UDP isn't possible. It won't work because UDP is an > unsuitable transport for EAP. Yes, I agree with this. > The Identification numbers provide a state mechanism that's > plainly outside of any sort of protection, and therefore breakable. I think that depends on exactly how the Id and MIC are processed. If one assumes that the MIC is processed as though the validation occurs first (your suggestion), and the MIC covers the Id, then I'm not sure. Otherwise, I think you're right. > (1) Add a way to carry MIC in all EAP messages -- add it as > part of the base 2284bis document. This seems like a > mostly good idea, though I'd like to see how it could be > done in a reasonably compatible manner. That's the trick. So far we've discussed a Success/Failure method (such as EAP TLV) The issue with that was that it would not function correctly on an implementation not supporting sequences. We also talked about a new Code -- but that would be ignored completely on existing implementations. > It does already. On PPP, you have to retransmit Request messages. On > 802.1X, you do not. Actually, we were recently reminded by the 802.1X folks that they *do* retransmit Requests. It's just that retransmission logic isn't in the state machine. That error is fixed in -01. > I'm suggesting that you don't really have MICs unless you have EAP > Success and Failure with an embedded MIC field. I would agree, although you might need a three-way exchange to make it reliable. > Why is that a special question with a different answer from what you > do when EAP Success, EAP Request, or EAP Response fails MIC? Only because Success/Failure are not retransmitted. Otherwise, no difference. > > This is also true -- but the question is whether it is possible to > > introduce MIC'd success and failure indications and maintain backward > > compatibility. > > It doesn't appear that this is so. Nor is it possible to protect > Identification, Nak, and Notification, nor is any message's > Identification number protected in any way. >From where we sit now, I agree with this. Though I'd claim that the lack of protection of Identity, Nak and Notification is intrinsic to the problem. > They're still vulnerable to someone who wants to attack the weak > points: EAP Nak, EAP Notification, EAP Success, EAP Failure, and the > Identification numbers. If only one method is permissible, then a spoofed Nak results in a DoS attack at best. Notification doesn't change state other than IDs. So we're left with Success/Failure spoofing and the IDs. > Even if all that were worked out somehow, pass-through is a problem. > The lack of Identification number protection means that arbitrary > messages to the AAA server can be injected. In general, an attacker can modify any portion of the EAP header, including the Ids. It's probably worth mentioning this in the security considerations section. > Notification does change some state -- it changes the Identification > number. It also likely involves activity outside of EAP (logging, > pop-up messages, and so forth) that *CERTAINLY* requires > authentication in this context -- if any EAP message needs it, then > Notification should as well. Why ignore this? Notification is a weak mechanism as you say. RFC 2284 indicates that Notification shouldn't be required in most cases, and there's no support for localization. It's probably better for methods to include their own (protected) error message support instead. > I'm arguing that this (the lack of keys at the needed point) is a root > cause of the problem, not an unsolvable issue. It's definitely a root cause -- and if a DH is done first, they can be available after the first round-trip. From james.d.carlson@east.sun.com Tue Feb 18 19:57:43 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 18 Feb 2003 14:57:43 -0500 Subject: [eap] Re: Issue 80: Success Indications In-Reply-To: Bernard Aboba's message of 18 February 2003 10:04:22 References: <15954.17198.297465.436581@gargle.gargle.HOWL> Message-ID: <15954.36919.96532.668424@gargle.gargle.HOWL> Bernard Aboba writes: > > The Identification numbers provide a state mechanism that's > > plainly outside of any sort of protection, and therefore breakable. > > I think that depends on exactly how the Id and MIC are processed. If one > assumes that the MIC is processed as though the validation occurs first > (your suggestion), and the MIC covers the Id, then I'm not sure. > Otherwise, I think you're right. When we had that conversation, I thought that we were talking about MICs in general, and not MICs with reference to some EAP-method-only implementation. For MICs in general, I think the principle still holds, but for method-related ones, I'm much less sure. It seems to me that the existence of un-MIC'd and un-MIC-able EAP messages means that implementing it solely within the method is a losing proposition. (In other words, what I was assuming was something more radical than what was perhaps proposed: a method that actually changed either EAP itself or the underlying transport. Since you couldn't implement such a thing without appropriate changes to the EAP server, and thus it can be assumed that such a server must already be privy to the game, it would be feasible.) > > (1) Add a way to carry MIC in all EAP messages -- add it as > > part of the base 2284bis document. This seems like a > > mostly good idea, though I'd like to see how it could be > > done in a reasonably compatible manner. > > That's the trick. So far we've discussed a Success/Failure method (such as > EAP TLV) The issue with that was that it would not function correctly on an > implementation not supporting sequences. We also talked about a new Code > -- but that would be ignored completely on existing implementations. Right. We might as well have a meaning for length > 4 in Success/Failure. > > It does already. On PPP, you have to retransmit Request messages. On > > 802.1X, you do not. > > Actually, we were recently reminded by the 802.1X folks that they *do* > retransmit Requests. It's just that retransmission logic isn't in the > state machine. That error is fixed in -01. Hmm. OK. The statement about AAA does stand, though. It carries EAP messages but is backwards in definition from RFC 2284 EAP. For what it's worth, I see no problem in having slightly different semantics when EAP is run over different transports, so long as the overall behavior can be mapped appropriately. One of the keys to getting that right will be to *exclude* complications, such as varying the behavior of messages depending on context. > > They're still vulnerable to someone who wants to attack the weak > > points: EAP Nak, EAP Notification, EAP Success, EAP Failure, and the > > Identification numbers. > > If only one method is permissible, then a spoofed Nak results in a DoS > attack at best. Notification doesn't change state other than IDs. So we're > left with Success/Failure spoofing and the IDs. I'm not so sure. The intent of Notification is to provide a means to tell the (presumably human) user about some event of significance. If delivery to a human is reasonably feasible (not all implementations have users or user interfaces), then it should be done. The problem is that this provides a way for an attacker to pop up undesired messages as well, and there appears to be no good way to avoid this in EAP, other than carving out yet another exception. > > Even if all that were worked out somehow, pass-through is a problem. > > The lack of Identification number protection means that arbitrary > > messages to the AAA server can be injected. > > In general, an attacker can modify any portion of the EAP header, > including the Ids. It's probably worth mentioning this in the security > considerations section. The special problem that I'm referring to here is that if an attacker sends forged Response messages, he can trick the EAP server into DoSing the AAA server. > > Notification does change some state -- it changes the Identification > > number. It also likely involves activity outside of EAP (logging, > > pop-up messages, and so forth) that *CERTAINLY* requires > > authentication in this context -- if any EAP message needs it, then > > Notification should as well. Why ignore this? > > Notification is a weak mechanism as you say. RFC 2284 indicates > that Notification shouldn't be required in most cases, and there's no > support for localization. It's probably better for methods to include > their own (protected) error message support instead. So should Notification be deprecated? > > I'm arguing that this (the lack of keys at the needed point) is a root > > cause of the problem, not an unsolvable issue. > > It's definitely a root cause -- and if a DH is done first, they can be > available after the first round-trip. The problem I'm having with this whole line of investigation and documentation is that it's based on what seems to me to be a bad premise. In particular: how can EAP cope if one of the main assumptions about the underlying layer (it's point-to-point -- there's no more than one peer out there) is violated? Since you end up needing to protect the subsequent network data against the same threats, doesn't this end up being a new IKE? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Wed Feb 19 17:25:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 19 Feb 2003 09:25:54 -0800 (PST) Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 19 Feb 2003 09:23:27 -0800 (PST) From: Bernard Aboba To: Glen Zorn Cc: AAA WG , waa@cs.umd.edu Subject: Re: [AAA-WG]: Issue 397 The issue appears to be whether some portion of the MSK needs to be Reserved. Today my understanding is that only the first 64B of the MSK is sent from AAA server to NAS [RFC2548], even though 192B of MSK are defined in [RFC2716]. Note that the last 64B of the MSK defined in [RFC2716] are a known quantity (the IV); this is an artifact of US Export regulations which I believe are no longer in effect. This leaves the following situation: MSK(0,63) Sent from AAA server to NAS. MSK(64,127) Not currently transported from AAA server to NAS. MSK(128,192) Known quantity. Not currently transported from AAA server to NAS. Here MSK(X,Y) = portion of the MSK from bytes X to Y inclusive. MSK(0,31) is known in IEEE 802.11i as the PMK. Some Fast Handoff proposals are attempting to achieve Perfect Forward Secrecy (PFS). The idea here is for the keying material sent to NAS1 to be cryptographically independent of the keying material sent to NAS2. In order to enable PFS, the keying material sent must be derived from a quantity not known by NASes. In some of the existing proposals, it has been suggested that this material be derived from the EAP Master Key (MK). The problem with this is that the formulas typically assume a single PRF (e.g. TLS PRF). This implies that the schemes will only work with selected EAP methods (EAP TLS, PEAP, EAP TTLS, etc.), because in some EAP methods (EAP SIM), it is not possible to export the Master Key and plug it into a PRF other than that for which the protocol was designed. To make the schemes more general, it is necessary for them to use a quantity that is exported by all EAP Methods -- namely the MSK. However, in examining the MSK it becomes clear that only MSK(64,127) could qualify for such usage. MSK(128,192) may be a known quantity, so this won't do. MSK(0,63) also won't work, because the goal is to enable PFS. That means that the keying material for NAS2 can't depend on the keying material for the previous NAS. If it does, then if that NAS were compromised, then it would also compromise the next NAS. So the only quantity left that would work is MSK(64,127). Some of the questions this raises are: a. Is 64B of keying material transported between AAA server and NAS *always* sufficient? b. Does it make sense to reserve some portion of the MSK (64B?) to be generated by the EAP method, but *not* sent to the NAS? c. In order to compensate for MSK(128,192) potentially being a known quantity, should EAP methods generate more than 192B of MSK? From jsalowey@cisco.com Wed Feb 19 22:54:03 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Wed, 19 Feb 2003 14:54:03 -0800 Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd) Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF43E@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> In my experience only the first 64B of the MSK are sent to the NAS. =20 How did we come about with the format for the MSK? =20 EAP-TLS doesn't seem to actually specify the format of the MSK. I can't seem to find where is it specified that the IV should be the last 64 bytes of the MSK? =20 An MSK with known bytes is of dubious value. In any case unless you change EAP-TLS the IV bytes will always be known and probably should not be considered part of any MSK. =20 Pasi Eronen and I are working on a draft that relates to the issue of reserving keys and key derivation that we hope to publish before the cutoff. =20 =20 > a. Is 64B of keying material transported between AAA server=20 > and NAS *always* sufficient? >=20 [Joe] I think for existing applications it is. If future ciphers use this value as key derivation key then several keys can be derived from it to satisfy the needs of the ciphersuite in use (as in 802.11i). If the underlying EAP mechanism can produce 64 byte secrets then this is a lot of key material. However it is impossible to know how far into the future this amount of keying material is satisfactory.=20 > b. Does it make sense to reserve some portion of the MSK=20 > (64B?) to be generated by the EAP method, but *not* sent to the NAS? [Joe] yes, There are applications for key material that don't directly involve the NAS. > c. In order to compensate for MSK(128,192) potentially being=20 > a known quantity, should EAP methods generate more than 192B of MSK? [Joe] Part of the MSK should NEVER be a known quantity. Any known quantity should be eliminated from the MSK. =20 Cheers, Joe > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Wednesday, February 19, 2003 9:26 AM > To: eap@frascone.com > Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd) >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > Date: Wed, 19 Feb 2003 09:23:27 -0800 (PST) > From: Bernard Aboba > To: Glen Zorn > Cc: AAA WG , waa@cs.umd.edu > Subject: Re: [AAA-WG]: Issue 397 >=20 > The issue appears to be whether some portion of the MSK needs=20 > to be Reserved. >=20 > Today my understanding is that only the first 64B of the MSK=20 > is sent from AAA server to NAS [RFC2548], even though 192B of=20 > MSK are defined in [RFC2716]. >=20 > Note that the last 64B of the MSK defined in [RFC2716] are a=20 > known quantity (the IV); this is an artifact of US Export=20 > regulations which I believe are no longer in effect. >=20 > This leaves the following situation: >=20 > MSK(0,63) Sent from AAA server to NAS. > MSK(64,127) Not currently transported from AAA server to NAS. > MSK(128,192) Known quantity. Not currently transported from=20 > AAA server > to NAS. >=20 > Here MSK(X,Y) =3D portion of the MSK from bytes X to Y=20 > inclusive. MSK(0,31) is known in IEEE 802.11i as the PMK. >=20 > Some Fast Handoff proposals are attempting to achieve Perfect=20 > Forward Secrecy (PFS). The idea here is for the keying=20 > material sent to NAS1 to be cryptographically independent of=20 > the keying material sent to NAS2. >=20 > In order to enable PFS, the keying material sent must be=20 > derived from a quantity not known by NASes. In some of the=20 > existing proposals, it has been suggested that this material=20 > be derived from the EAP Master Key (MK). >=20 > The problem with this is that the formulas typically assume a=20 > single PRF (e.g. TLS PRF). This implies that the schemes will=20 > only work with selected EAP methods (EAP TLS, PEAP, EAP TTLS,=20 > etc.), because in some EAP methods (EAP SIM), it is not=20 > possible to export the Master Key and plug it into a PRF=20 > other than that for which the protocol was designed. >=20 > To make the schemes more general, it is necessary for them to=20 > use a quantity that is exported by all EAP Methods -- namely the MSK. >=20 > However, in examining the MSK it becomes clear that only=20 > MSK(64,127) could qualify for such usage. MSK(128,192) may be=20 > a known quantity, so this won't do. >=20 > MSK(0,63) also won't work, because the goal is to enable PFS.=20 > That means that the keying material for NAS2 can't depend on=20 > the keying material for the previous NAS. If it does, then if=20 > that NAS were compromised, then it would also compromise the next NAS. >=20 > So the only quantity left that would work is MSK(64,127).=20 > Some of the questions this raises are: > >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From aboba@internaut.com Wed Feb 19 22:06:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 19 Feb 2003 14:06:13 -0800 (PST) Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd) In-Reply-To: <4D1E846548771F4AA7FAE28F4B358DB5012EF43E@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Message-ID: > In my experience only the first 64B of the MSK are sent to the NAS. RFC 2548 says that only 64B are sent to the NAS. > EAP-TLS doesn't seem to actually specify the format of the MSK. I can't > seem to find where is it specified that the IV should be the last 64 > bytes of the MSK? RFC 2716 specifies how to derive different keying material, but there's no format per se. It's just easier to talk about all the keying material as a single quantity, than to give individual names to each individual portion. However, since this seems to be confusing, we can separate it into the secret part (the MSK) and the possibly known part (the IV). > An MSK with known bytes is of dubious value. The requirement for exportability was that the IV was a known quantity. This is how TLS key generation works in "export mode". > change EAP-TLS the IV bytes will always be known and probably should not > be considered part of any MSK. They are exported by that EAP method. We can call the known part "the IV" if you like. > > a. Is 64B of keying material transported between AAA server > > and NAS *always* sufficient? > > > [Joe] I think for existing applications it is. But presumably we would like this to work with future applications too, no? > the underlying EAP mechanism can produce 64 byte secrets then this is a > lot of key material. Depends on how much entropy is contained in the 64B. > However it is impossible to know how far into the > future this amount of keying material is satisfactory. There are papers that go over these kind of issues, so couldn't we look at what the requirement would be say, if someone wanted to key 256-bit AES? > > b. Does it make sense to reserve some portion of the MSK > > (64B?) to be generated by the EAP method, but *not* sent to the NAS? > > [Joe] yes, There are applications for key material that don't directly > involve the NAS. I'm coming to that conclusion as well. > [Joe] Part of the MSK should NEVER be a known quantity. Any known > quantity should be eliminated from the MSK. I think there is some confusion in terminology here. EAP methods may pass known quantities for an IV. But we'll keep those quantities logically separate from the secret part, which we'll call the MSK. If we look at it that way, then EAP methods potentially only generate 128B of MSK. If we reserve the second 64B, and transport the first 64B to the NAS, then we better be pretty sure that the 64B is enough to key future ciphersuites. That's still a lot of keying material, assuming that the underlying entropy is large enough. So perhaps it is enough. But I'd like to see some formal analysis of this. From dhala@cisco.com Thu Feb 20 05:30:25 2003 From: dhala@cisco.com (David Halasz) Date: Thu, 20 Feb 2003 00:30:25 -0500 Subject: [eap] Fwd: Re: TGi Ad-hoc meeting information Message-ID: <4.3.2.7.2.20030220002527.0414d640@unitas.cisco.com> --=====================_1871118255==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Some notes about the meeting in Redmond, 2/19 meeting location Building 50 2/20 meeting location Building 33:MSCC, Rainier room 2/21 meeting location Building 31, Whistler room The approved agenda is the following, 2/19 AM TKIP/Michael countermeasures 2/19 PM CCMP Protocol stack discussion 2/19 PM TKIP/Michael countermeasures cont. 2/19 PM Sub-groups 2/20 Start at 10 AM PST - Sub-groups 2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams 2/20 PM Sub-groups 2/21 AM IETF interaction, follow on letter 2/21 AM Going beyond the PAR (802 scope) 2/21 PM Sub-groups Dave H. >Date: Mon, 10 Feb 2003 16:11:52 -0500 >To: "Tim Moore" >From: David Halasz >Subject: Re: TGi Ad-hoc meeting information >Cc: , , >stds-802-1@ieee.org, eap@frascone.com > >The tentative agenda for the IEEE 802.11i Ad-Hoc is as follows, > >2/19 AM CCMP Protocol stack discussion >2/19 PM Sub-groups > >2/20 AM Sub-groups >2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams > >2/21 AM Fast roaming discussion >2/21 PM Sub-groups > >We divided into 5 sub-groups. > >1. Clauses 2, 3, 4, 7, Appendix A (Dave Halasz) >2. Clauses 5, 10, 11 (Dorothy Stanley) >3. Clause 8, Annex F - CCMP (Paul Lambert) >4. Clause 8, Annex F - TKIP (Tim Moore) >5. Clause 8, Annex F - Other (Jesse Walker) > >I think most of sub-group 3 was taken care of at the January meeting. > >The comments received are at, >http://www.ieee802.org/11/Documents/DocumentHolder/3-033.zip >Please note that all comments resolved are not yet reflected in 03-033. > >The January meeting minutes are at, >http://www.ieee802.org/11/Documents/DocumentHolder/3-096.zip > > > Dave H. > >At 03:51 PM 2/10/2003, Tim Moore wrote: >>Information for the TGi Ad-hoc meeting Feb 19-21, Sorry for the delay in >>sending the details out. >> >>It will be on the the main Redmond campus in Building 50. Okanogan room. >> >>Breakfast and Lunch will be supplied. >> >>Directions to the Main Microsoft Campus from Seatac Airport: >> * Follow signs to Freeways, this will put you on SR 518 eastbound, >> merge carefully. >> * Follow signs to I-5 and I-405. >> * Take I-405 North-Renton (center lane). >> * Continue on North I-405 thru Renton and Bellevue, approx. 14 miles. >> * Take SR-520 East exit toward Redmond. >> * Exit SR-520 at NE 40th St exit. >> * Turn Right at exit onto NE 40th St. >> >> >> >> >> >>A list of hotels that are nearby are below. There isn't any special >>arrangement with any particular hotel. >> >>Local Hotel Listing >>A. DoubleTree >>300 112th Ave SE >>Bellevue >>(425) 455-1300 >>(800) 733-5466 >>http://www.doubletree.com/ B. Hyatt Regency >>NE 8th and Bellevue Way >>Bellevue >>(425) 462-2626 >>(800) 462-1234 >>http://www.hyatt.com/ C. Hilton Bellevue >>100 112th Ave NE >>Bellevue WA >>(425) 455-3330 >>(800) 235-4458 >>http://www.hilton.com/ D. Timberlawn Apts. >>15850 NE 40th Street >>Redmond, WA 98052 >>425-883-6801 >>E. Residence Inn at >>Redmond Town Center >>7575 164th Avenue NE >>Redmond, WA 98052 >>425-497-9226 >>800-331-3131 >>http://www.residenceinn.com/ F. The >>Residence Inn >>14455 NE 29th Place >>Bellevue, WA >>(425) 882-1222 >>(800) 331-3131 >>http://www.residenceinn.com G. Homestead >>Village >>15805 NE 28th St >>Bellevue WA 98008 >>425-885-6675 >>888-782-7473 >>http://www.homesteadvillage.com >>H. Embassy Suites >>3225 158th Avenue SE >>Bellevue WA 98008 >>425-644-2500 >>800-362-2779 >>http://www.embassysuites.com >>I. Bellevue Club >>11200 SE 6th Street >>Bellevue, WA 98004 >>425-454-4424 >>800-579-1110 >>http://www.bellevueclub.com/hotel.htm >>J. Courtyard Bellevue >>14615 NE 29th Place >>Bellevue, WA 98007 >>425-869-5300 >>800-321-2211 >>http://www.courtyard.com/ K. Fairfield Inn >>14595 NE 29th Place >>Bellevue, WA 98007 >>425-869-6548 >>800-228-2800 >>http://www.fairfieldinn.com/ >> >>Tim >> Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 --=====================_1871118255==_.ALT Content-Type: text/html; charset="us-ascii" Some notes about the meeting in Redmond,

2/19 meeting location Building 50
2/20 meeting location Building 33:MSCC, Rainier room
2/21 meeting location Building 31, Whistler room

The approved agenda is the following,
2/19 AM TKIP/Michael countermeasures
2/19 PM CCMP Protocol stack discussion
2/19 PM TKIP/Michael countermeasures cont.
2/19 PM Sub-groups

2/20 Start at 10 AM PST - Sub-groups
2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams
2/20 PM Sub-groups

2/21 AM IETF interaction, follow on letter
2/21 AM Going beyond the PAR (802 scope)
2/21 PM Sub-groups

        Dave H.


Date: Mon, 10 Feb 2003 16:11:52 -0500
To: "Tim Moore" <timmoore@exchange.microsoft.com>
From: David Halasz <dhala@cisco.com>
Subject: Re: TGi Ad-hoc meeting information
Cc: <stds-802-11@ieee.org>, <IEEE-802-11-tgi@majordomo.rsasecurity.com>, stds-802-1@ieee.org, eap@frascone.com

The tentative agenda for the IEEE 802.11i Ad-Hoc is as follows,

2/19 AM CCMP Protocol stack discussion
2/19 PM Sub-groups

2/20 AM Sub-groups
2/20 PM 802.1 discussion, 802.1/802.11/EAP state diagrams

2/21 AM Fast roaming discussion
2/21 PM Sub-groups

We divided into 5 sub-groups.

1. Clauses 2, 3, 4, 7, Appendix A (Dave Halasz)
2. Clauses 5, 10, 11 (Dorothy Stanley)
3. Clause 8, Annex F - CCMP (Paul Lambert)
4. Clause 8, Annex F - TKIP (Tim Moore)
5. Clause 8, Annex F - Other (Jesse Walker)

I think most of sub-group 3 was taken care of at the January meeting.

The comments received are at,
http://www.ieee802.org/11/Documents/DocumentHolder/3-033.zip
Please note that all comments resolved are not yet reflected in 03-033.

The January meeting minutes are at,
http://www.ieee802.org/11/Documents/DocumentHolder/3-096.zip


        Dave H.

At 03:51 PM 2/10/2003, Tim Moore wrote:
Information for the TGi Ad-hoc meeting Feb 19-21, Sorry for the delay in sending the details out.
 
It will be on the the main Redmond campus in Building 50. Okanogan room.
 
Breakfast and Lunch will be supplied.
 
Directions to the Main Microsoft Campus from Seatac Airport:
  • Follow signs to Freeways, this will put you on SR 518 eastbound, merge carefully.
  • Follow signs to I-5 and I-405.
  • Take I-405 North-Renton (center lane).
  • Continue on North I-405 thru Renton and Bellevue, approx. 14 miles.
  • Take SR-520 East exit toward Redmond.
  • Exit SR-520 at NE 40th St exit.
  • Turn Right at exit onto NE 40th St.



 

A list of hotels that are nearby are below. There isn't any special arrangement with any particular hotel.

Local Hotel Listing
A.  DoubleTree
300 112th Ave SE
Bellevue
(425) 455-1300
(800) 733-5466
http://www.doubletree.com/ B.  Hyatt Regency
NE 8th and Bellevue Way
Bellevue
(425) 462-2626
(800) 462-1234
http://www.hyatt.com/ C.  Hilton Bellevue
100 112th Ave NE
Bellevue WA
(425) 455-3330
(800) 235-4458
http://www.hilton.com/ D.  Timberlawn Apts.
15850 NE 40th Street
Redmond, WA 98052
425-883-6801
E.  Residence Inn at
Redmond Town Center
7575 164th Avenue NE
Redmond, WA 98052
425-497-9226
800-331-3131
http://www.residenceinn.com/ F.  The Residence Inn
14455 NE 29th Place
Bellevue, WA
(425) 882-1222
(800) 331-3131
http://www.residenceinn.com G.  Homestead Village
15805 NE 28th St
Bellevue WA 98008
425-885-6675
888-782-7473
http://www.homesteadvillage.com H.  Embassy Suites
3225 158th Avenue SE
Bellevue WA 98008
425-644-2500
800-362-2779
http://www.embassysuites.com
I.  Bellevue Club
11200 SE 6th Street
Bellevue, WA 98004
425-454-4424
800-579-1110 http://www.bellevueclub.com/hotel.htm J.  Courtyard Bellevue
14615 NE 29th Place
Bellevue, WA 98007
425-869-5300
800-321-2211
http://www.courtyard.com/ K.  Fairfield Inn
14595 NE 29th Place
Bellevue, WA 98007
425-869-6548
800-228-2800
http://www.fairfieldinn.com/
 
Tim
 


Dave Halasz
Cisco Systems, Inc.
320 Springside Drive
Akron, OH  44333
--=====================_1871118255==_.ALT-- From Internet-Drafts@ietf.org Thu Feb 20 12:35:50 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 20 Feb 2003 07:35:50 -0500 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-01.txt Message-ID: <200302201235.HAA08953@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-01.txt Pages : 48 Date : 2003-2-19 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-01.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-01.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-01.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-2-19141906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19141906.I-D@ietf.org> --OtherAccess-- --NextPart-- From aboba@internaut.com Mon Feb 24 14:14:23 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 24 Feb 2003 06:14:23 -0800 (PST) Subject: [eap] Agenda items for IETF 56 Message-ID: If you have an agenda item for the EAP WG meeting at IETF 56, please send mail to the chairs. From dave@frascone.com Wed Feb 26 15:54:29 2003 From: dave@frascone.com (David Frascone) Date: Wed, 26 Feb 2003 09:54:29 -0600 Subject: [eap] Archives back on line Message-ID: <20030226155429.GC4886@wolverine> Sorry for the lapse. Archives are now available again at http://mail.frascone.com/pipermail/public/eap -Dave -- David Frascone Oxymoron: Stuck in traffic. From yohba@tari.toshiba.com Thu Feb 27 22:22:32 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 27 Feb 2003 17:22:32 -0500 Subject: [eap] session-timeout usage Message-ID: <20030227222232.GE1390@catfish> I have a question on RADIUS Session-Timeout attribute usage in EAP: "When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Note that in this case the peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. Where the authentication process requires user input, the measured round trip times are largely determined by user responsiveness rather than network characteristics, so that RTO estimation is not helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute)." When EAP runs over a reliable lower-layer, does the RADIUS Session-Timeout attribute always need to be used for retransmission timer? I think in this case, if the authenticator does not receive EAP Response, the reason is either (i) the peer received the EAP Request but it is taking time to generate an EAP Response or (ii) link-layer connectivity is lost. For either case, it seems that there is no reason for the authenticator to retransmit the EAP Request by using Session-Timeout attribute as a hint, and the authenticator can use the Session-Timeout attribute for authentication timer (i.e., if there is no EAP Response received within the Session-Timeout period the authentication would fail), instead of use it for retransmission timer. In other words, I think the third paragraph is basically for the case in which EAP runs over unreliable lower-layer. Is my understanding correct? Yoshihiro Ohba From weiwang@interlinknetworks.com Fri Feb 28 08:40:34 2003 From: weiwang@interlinknetworks.com (Wei Wang) Date: Fri, 28 Feb 2003 03:40:34 -0500 Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 Message-ID: <3E5F2082.7030106@interlinknetworks.com> Greetings, In describing a "man-in-the-middle" attack against TLS protected EAP authentication, the referred document stated that, "For this attack to be successful, it is necessary for the tunneled authentication methods to also be enabled for use outside the tunnel, and for the same credentials to be used for authentication inside and outside the tunnel." It seems that it is not necessary for the same credentials to be used both inside and outside the tunnel. At least the EAP-TTLS method has this "anonymity and privacy" feature, in which case, the user id inside the tunnel does not (or actually, should not) be the same as the one outside the tunnel. Regards, -- Wei Wang mailto:wwang@interlinknetworks.com Interlink Networks, Inc. http://www.interlinknetworks.com From Dan.Forsberg@nokia.com Fri Feb 28 10:47:23 2003 From: Dan.Forsberg@nokia.com (Dan.Forsberg@nokia.com) Date: Fri, 28 Feb 2003 12:47:23 +0200 Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 Message-ID: Wei, It's not question about the credentials used with the tunnel creation = and the authentication method, but that the method can be used without = the tunnel. For example you use the same EAP-MD5 credentials with or = without the tunnel. - Dan > -----Original Message----- > From: ext Wei Wang [mailto:weiwang@interlinknetworks.com] > Sent: 28 February, 2003 10:41 > To: EAP WG > Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 >=20 >=20 > Greetings, >=20 > In describing a "man-in-the-middle" attack against TLS protected > EAP authentication, the referred document stated that, "For this > attack to be successful, it is necessary for the tunneled > authentication methods to also be enabled for use outside the > tunnel, and for the same credentials to be used for > authentication inside and outside the tunnel." >=20 > It seems that it is not necessary for the same credentials to be > used both inside and outside the tunnel. At least the EAP-TTLS > method has this "anonymity and privacy" feature, in which case, > the user id inside the tunnel does not (or actually, should > not) be the same as the one outside the tunnel. >=20 > Regards, > --=20 > Wei Wang mailto:wwang@interlinknetworks.com > Interlink Networks, Inc. http://www.interlinknetworks.com >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jsalowey@cisco.com Fri Feb 28 18:12:22 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Fri, 28 Feb 2003 10:12:22 -0800 Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF46E@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> It is also not always necessary for the method to be the same inside and outside the tunnel to expose this vulnerability(although this makes things easier). If the same credentials are used in different protocols inside and outside the tunnel you may still be vulnerable (of course using the same credentials in two different mechanism may create other vulnerabilities as well.) Joe > -----Original Message----- > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com]=20 > Sent: Friday, February 28, 2003 2:47 AM > To: weiwang@interlinknetworks.com; eap@frascone.com > Subject: RE: [eap] Question regarding draft-puthenkulam-eap-binding-01 >=20 >=20 > Wei, >=20 > It's not question about the credentials used with the tunnel=20 > creation and the authentication method, but that the method=20 > can be used without the tunnel. For example you use the same=20 > EAP-MD5 credentials with or without the tunnel. >=20 > - Dan >=20 > > -----Original Message----- > > From: ext Wei Wang [mailto:weiwang@interlinknetworks.com] > > Sent: 28 February, 2003 10:41 > > To: EAP WG > > Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 > >=20 > >=20 > > Greetings, > >=20 > > In describing a "man-in-the-middle" attack against TLS=20 > protected EAP=20 > > authentication, the referred document stated that, "For=20 > this attack to=20 > > be successful, it is necessary for the tunneled=20 > authentication methods=20 > > to also be enabled for use outside the tunnel, and for the same=20 > > credentials to be used for authentication inside and outside the=20 > > tunnel." > >=20 > > It seems that it is not necessary for the same credentials=20 > to be used=20 > > both inside and outside the tunnel. At least the EAP-TTLS=20 > method has=20 > > this "anonymity and privacy" feature, in which case, the user id=20 > > inside the tunnel does not (or actually, should > > not) be the same as the one outside the tunnel. > >=20 > > Regards, > > --=20 > > Wei Wang mailto:wwang@interlinknetworks.com > > Interlink Networks, Inc. http://www.interlinknetworks.com > >=20 > >=20 > > _______________________________________________ > > 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 aboba@internaut.com Fri Feb 28 17:07:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 28 Feb 2003 09:07:03 -0800 (PST) Subject: [eap] Re: session-timeout usage In-Reply-To: <20030228180002.16934.74731.Mailman@wolverine> Message-ID: > When EAP runs over a reliable lower-layer, does the RADIUS > Session-Timeout attribute always need to be used for retransmission > timer? No. If not, the default will apply (in this case, infinite retransmission time), otherwise RFC 2988 estimation. > the authenticator can > use the Session-Timeout attribute for authentication timer (i.e., if > there is no EAP Response received within the Session-Timeout period > the authentication would fail), instead of use it for retransmission > timer. I don't think we want to overload the definition of Session-Timeout yet again, especially since the current definition was in RFC 2869 and has been in use for several years now. From yohba@tari.toshiba.com Fri Feb 28 23:05:59 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 28 Feb 2003 18:05:59 -0500 Subject: [eap] Re: session-timeout usage In-Reply-To: References: <20030228180002.16934.74731.Mailman@wolverine> Message-ID: <20030228230559.GC1354@catfish> On Fri, Feb 28, 2003 at 09:07:03AM -0800, Bernard Aboba wrote: > > When EAP runs over a reliable lower-layer, does the RADIUS > > Session-Timeout attribute always need to be used for retransmission > > timer? > > No. If not, the default will apply (in this case, infinite retransmission > time), otherwise RFC 2988 estimation. > > > the authenticator can > > use the Session-Timeout attribute for authentication timer (i.e., if > > there is no EAP Response received within the Session-Timeout period > > the authentication would fail), instead of use it for retransmission > > timer. > > I don't think we want to overload the definition of Session-Timeout yet > again, especially since the current definition was in RFC 2869 and has > been in use for several years now. > All these make sense. Thanks, Yoshihiro Ohba