From aboba@internaut.com Sat Aug 2 21:14:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 13:14:52 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 164: Conflicting Implementation Note Message-ID: The text of Issue 164 is enclosed below. The recommendation is that the proposed change be accepted. Any objections? ------------------------------------------------------------------------- Issue 164: Conflicting Implementation Note Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 7/29/2003 Reference: Document: RFC2284bis Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: In section 2 [3] there is the following text "After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." In section 5.1 there is the following text in the implementation note: "It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication phase with a Failure reply." This seems contradictory. Requested change: Section 5.1 "It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication." From aboba@internaut.com Sat Aug 2 21:17:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 13:17:29 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 163: Minor Editorial Nit Message-ID: The text of issue 163 is enclosed below. The recommendation is that the proposed change be accepted. Any objections? -------------------------------------------------------------------------- Issue 163: Minor Editorial Nit Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Date first submitted: July 21, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001508.html Document: EAP-04 Comment type: E Priority: 2 Section: 2.1 Rationale/Explanation of issue: Third paragraph in Section 2.1 states "A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD silently discard it and log the event." and in Section 1.2 we have the definition of 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." Recommended change: In section 2.1 change the third paragraph quoted above to read: "A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected NAK SHOULD discard it and log the event." (e.g. remove the "silently", at first read I found this a bit confusing). From aboba@internaut.com Sat Aug 2 21:28:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 13:28:42 -0700 (PDT) Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined Message-ID: The text of Issue 162 is enclosed below. Here is the proposed change and some commentary: "Minimum MTU. The EAP layer, the EAP Identity method, EAP Notification method and the NAK responses do NOT support fragmentation and reassembly. " [BA] Recommend adding EAP OTP, GTC and Challenge-MD5 to this list. EAP methods designed originally for use within PPP (where a 1500 byte MTU is guaranteed for control frames [RFC1661]) also lack fragmentation and reassembly features. [BA] It is true that the methods defined in RFC 2284 also do not support fragmentation and reassembly. Since we don't have specifications for many methods that have been allocated type codes since then, it is hard to say whether the statement above is true or not. Certainly EAP TLS [RFC 2716] does support fragmentation. Question: Is a 1500 byte MTU really guaranteed for control frames? I seem to recall situations where only a 576 octet MTU was available. My suggestion is that the above sentence be changed to "may lack fragmentation and reassembly features". "The lower layer transporting EAP MUST therefore be capable of carrying EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a lock-step protocol, which implies a certain inefficiency when doing fragmentation and reassembly. The lower layer therefore SHOULD provide fragmentation and reassembly services." [BA] I don't know that we can impose this requirement on lower layers necessarily. After all, the lower layers are what they are. Suggest that the MUST be changed to a SHOULD. Recommend that the last sentence be deleted. Lower layers typically don't provide fragmentation and reassembly services, since that's an IP layer function. "Some implementations of EAP tend to piggy-back into an Identity Request or Response various options after a NUL-character. An EAP implementation SHOULD NOT assume that usernames or displayable messages over 1024 bytes in Identity Requests or Responses will work in all environments." [BA] Why is the limit only 1024 octets for Identity and a different number for other requests? Overall, my comment is that I'd prefer to recommend that methods assume a certain minimum MTU and that they MUST support fragmentation and reassembly if it is possible that frames can exceed this minimum MTU size. My overall impression was that we might have to live with a minimum MTU as low as 576 octets. --------------------------------------------------------------------- Issue 162: Minimum MTU Not Defined Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Date first submitted: July 21, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001507.html Document: EAP-04 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The current RFC2284bis draft does not define a minimum MTU that EAP methods can rely on. At least the following EAP methods do not do fragmenting: - Identity - Notification - MD5-Challenge - .. etc (- and Nak, which is not a method, but anyway) Currently the "minimum MTU" is "inherited" from PPP (1500 bytes), but all uses of EAP do not conform to this (e.g. PPPoe). A minimum MTU must be defined such that embeddings of EAP into other protocols will be such that implementations of these methods will always operate correctly. There are also the implied architectural limitations, which will cut across any system architecture which contains EAP: - Maximum identity length (unfragmented MTU - headers bytes - maximum length of piggy-backed option settings) - Maximum notification length The defined minimum MTU should be defined to be as large as possible, due to the lossage implied when doing fragmentation/reassembly in a lock-step protocol. Note also that the composite protocol architecture may be doing fragmentation/reasembly in both the EAP transport and the EAP method, if the usage is improper. The proposed solution is in a nutshell: - Define that minimum frame size that can be sent/received unfragmented by EAP as X bytes. - State the maximum notification length as X - headers. - State the maximum identity req/resp lengths as Y = X - headers - possible options - State that because EAP is a lock-step protocol and if latency is important and methods with large frames are used, the EAP transport protocol SHOULD provide fragmentation and reassembly services for frames upto 2^16 bytes. - Initial proposal of X as 1400 bytes. If somebody knows any protocols that use EAP with MTU's then I'm sure we'd all like to hear about it. Hopefully somebody has the relevant experience from all EAP implementations to specify better values for X and Y than in the text below (1400 and 1024 respectively). Requested change: In section 3.1 ("Lower layer requirements") add below. "[4] MTU known a-priori. The EAP layer does not support fragmentation and reassembly. However, EAP methods SHOULD be capable of handling fragmentation and reassembly. As a result, EAP is capable of functioning across a range of MTU sizes, as long as the MTU is known a-priori. EAP does not support path MTU discovery." to "[5] Minimum MTU. The EAP layer, the EAP Identity method, EAP Notification method and the NAK responses do NOT support fragmentation and reassembly. EAP methods designed originally for use within PPP (where a 1500 byte MTU is guaranteed for control frames [RFC1661]) also lack fragmentation and reassembly features. The lower layer transporting EAP MUST therefore be capable of carrying EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a lock-step protocol, which implies a certain inefficiency when doing fragmentation and reassembly. The lower layer therefore SHOULD provide fragmentation and reassembly services." ... and Change the numbering of the following items from [5] -> [6] and [6] -> [7]. After the first paragraph in "Section 5.1" add: "Some implementations of EAP tend to piggy-back into an Identity Request or Response various options after a NUL-character. An EAP implementation SHOULD NOT assume that usernames or displayable messages over 1024 bytes in Identity Requests or Responses will work in all environments." Add to first paragraph in "Section 5.2" the sentences: "Note that the maximum length of a notification messages that can be used reliably in all EAP implementations is 1400 bytes. The length of the human readable message SHOULD therefore be at most 1395 bytes." -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From aboba@internaut.com Sun Aug 3 03:24:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 19:24:49 -0700 (PDT) Subject: [eap] Discussion of Issue 152: Lower layer indications Message-ID: The text of Issue 152 is enclosed below. I think the major difference between the two approaches is for one-way methods such as EAP-MD5 Challenge. With one-way methods a peer is ready to accept an EAP Success after sending its Response. Since the peer does not authenticate the authenticator it is willing to access any network that indicates it is willing to grant access. In this case the proposed change is for a lower layer success indication to cause the peer to conclude that it has been granted access, even though it had no indication from EAP that the authenticator was willing to grant access. This doesn't really create any new security vulnerabilities since a one-way method is vulnerable to a spoofed EAP Success anyway. On the other hand, one-way methods are really only appropriate for physically secure wired media in which the loss rate should be very low, so that I don't think there is that much benefit to be provided. So that the peer doesn't encounter a timeout, it probably makes sense to have some assurance that the link is actually providing IP connectivity or is likely to do so. So I think we might need to revise the definition of a "lower layer success indication" so that it is likely to be indicative of IP connectivity (e.g. PPP NCP or IP packets) rather than just a layer 2 frame (e.g. Reassociation Response). If we take these factors into account, I think the change is ok, although it is not all that beneficial. Of course, one issue with lower layer success indications in general is that I don't believe there are any EAP implementations that incorporate them. If that remains true then if and when EAP goes to Draft Standard, we would need to remove this functionality from RFC 2284bis. As far as lower layer failure indications are concerned, I think we concluded that they would translate into "link down" indications in which case the EAP conversation would abort anyway. Therefore there was no need to discuss them explicitly. -------------------------------------------------------------- Issue 152: Lower layer indications Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001413.html Document: EAP-04 Comment type: T Priority: 1 Section: 3.4 Rationale/Explanation of issue: Section 3.4 says that "Section 4.2 defines the circumstances in which a peer, having concluded an EAP method with successful acknowledged result indications, may conclude that a Success packet has been lost after expiration of a timeout. In those same circumstances, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost without waiting for a timeout. This ensures that an attacker spoofing lower layer indications can at best succeed in a denial of service attack." This is not exactly what the current state machine does... The current text says that "if you are in a situation where a timeout would lead to success (that is, you have received a method-specific success indication), also lower-layer success indication does." What the current state mechine does is "if you are in a situation where receiving an EAP Success packet would lead to success, also lower-layer success indication does." Or in other words, the effect of receiving a lower-layer success indication is identical to receiving an EAP Success: if an EAP Success packet would be silently discarded, so is the lower-layer success indication. Both are IMHO quite reasonable approaches, and I just wanted to clarify which one we really want to use? [Jari Arkko] Hmm... if we get a method specific success indication, shouldn't we enable then in all three cases below: (a) Success received (b) Lower-layer success indication (c) Timeout? [Pasi Eronen] You're right, and that happens in both approaches. The only difference is in what to do when we don't have a method specific indication. In this case, - both approaches enable the link if Success is received - both approaches fail on timeout - the current state machine enables the link if lower-layer success indication is received, while 2284bis-04 says that the lower-layer success indication must be ignored (presumably leading to failure in timeout later). Which approach do you think we should use? A second issue: Earlier versions of the draft also mentioned lower-layer failure indications (e.g. "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted." in -03 version). This seems to be missing from -04, and I think the old text still applies? From aboba@internaut.com Sun Aug 3 03:42:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 19:42:08 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 151: EAP-04 comments Message-ID: The text of Issue 151 is enclosed below. Overall, these changes look good and the proposed resolution is to accept them, with the exception of the change relating to "granting access." Since only some methods do key derivation, the existing paragraph seems to cover more cases and the proposed text does not really substitute for it. Here are the proposed fixes: In Section 2, change: "ince EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction." To: "Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer)." In Section 4.2, change: "Success or Failure packets MUST NOT be sent by an EAP authenticator prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it." To: "Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it." In Section 5.7, change: "EAP Types from 0 through 255 are semantically identical whether they appear as single octet EAP Types or as Vendor-Types when Vendor-Id is zero." To: "EAP Types from 0 through 255 are semantically identical whether they appear as single octet EAP Types or as Vendor-Types when Vendor-Id is zero. There is one exception to this rule: Expanded Nak and Legacy Nak packets share the same code, but must be treated differently because they have a different format." In Appendix B, add "Support for mutual authentication and key derivation." In the reference section, update the references to RFC 2869bis (should obtain an RFC number soon) and SASLPREP. Also, change references to PIC to a reference to IKEv2. ---------------------------------------------------------------------------- Issue 151: EAP-04 comments Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001412.html Document: EAP-04 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue: Overall, the draft looks fine, and it seems that we're finally close to getting it finished! In hindsight, there are a couple of things that might have been clearer if organized differently, but it probably doesn't make sense to do such changes at this point. --- (Section 2) "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. For a discussion of security issues in peer-to-peer operation, see Section 7.7. I think this does not apply to all lower layers. Perhaps it should be rephrased to something like "Some lower layers for carrying EAP, such as PPP, may support peer-to-peer operation, in which an independent and...". [Jari Arkko] Yes. [Alternative re-formulation: "Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer)."] --- (Section 4.2) "Success or Failure packets MUST NOT be sent by an EAP authenticator prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it." I think there are several EAP methods where the number of rounds varies (so the phrase "the final round" is not well defined), depending on many issues, including whether the method is going to succeed or not. Perhaps this would better take that into account? "Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not allow the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not allowed MUST silently discard it." [Jari Arkko] Sounds good! --- (Section 4.2) "If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet." I know that this was beaten to death already :-) But since we have not defined what "failing to authenticate to the authenticator" means, does this actually impose any requirements for EAP implementations? (The problem is that "failing to authenticate" could be thought as "not successfully authenticating"; but according to the definition of "successful authentication" in Section 1.2, the above requirement does not make much sense.) Perhaps this would capture the intent? "If the peer attempts to authenticate to the authenticator using a method that provides key derivation, the authenticator SHOULD NOT grant access by sending a Success packet if the key derivation has failed for some reason." [Jari Arkko] Works for me. Maybe delete "for some reason". --- (Section 5.7) "EAP Types from 0 through 255 are semantically identical whether they appear as single octet EAP Types or as Vendor-Types when Vendor-Id is zero." (Section 5.7) "An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently whether they appear as a single octet or as the 32-bit Vendor-Type within a Expanded Type where Vendor-Id is 0." and Otherwise fine, but Expanded Nak packets have a different format than Legacy Nak packets, so they are not treated exactly identically. Perhaps we should add something like "There is one exception to this rule: Expanded Nak and Legacy Nak packets share the same code, but must be treated differently because they have a different format." (an alternative would be to change the code of Expanded Naks to something else, but probably this is easier?) [Jari Arkko] Yes. --- Appendix B: Two significant changes to RFC 2284 are not mentioned: mutual authentication and key derivation (RFC 2284 did not even mention either of them). [Jari Arkko] Ok. ---- References: There are newer versions of RFC2869bis and SASLPREP drafts available (Ok, RFC editor will probably handle these...) [Jari Arkko] Better update them now, just for consistency. ---- References: PIC is most likely dead and superceded by IKEv2, so maybe we should remove references to PIC and add a pointer to IKEv2? [Jari Arkko] Yes, that can be done. (Both the IKEv2 and PANA references would be non-normative, by the way, so that we don't have to wait for either one to complete.) From aboba@internaut.com Sun Aug 3 03:47:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 19:47:08 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access Message-ID: The text of Issue 150 is enclosed below. I don't think that the intent of section 7.9 is to make the interpretation of EAP Failure implementation dependent -- this is the kind of thing that needs to be standardized in order for the protocol to be interoperable. Allowing the peer to activate the link after receiving an indication that the authenticator is not granting access seems dangerous because it would be likely to either open the door to rogue authenticators or to timeouts where the peer would attempt to obtain an IP address and fail, leaving the user in limbo. My recommendation is that this change be rejected. ------------------------------------------------------------------ Issue 150: Lower Layer Behavior for Limited Access Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: June 18, 2003 Reference: Document: EAP-04 Comment type: T Priority: 1 Section: 4.2 Rationale/Explanation of issue: Text in section 7.9 allows limited access for peer after completion of EAP authentication with failure, with stating that the interaction of EAP with lower layers are highly implementation dependent. On the other hand, the following text in section 4.2 contains some wording that does not seem to consistent with section 7.9. "On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and avoid sending data on the link." I think whether the peer avoids sending data on the link is a sort of thing that should be described in each lower-layer protocol that carries EAP, since this is heavily lower-layer dependent as described in section 7.9. In fact, if the peer avoids sending data on the link, limited access scenario cannot be realized (though it might depend on the definition of "link"). In sectioni 4.2, it is described that a backend EAP server can send EAP Success when it does not need to authenticate the peer, but how it can determine it does not need to authenticate the peer in a roaming environment where it might be difficult for the EAP server to know the network access policy on the remote NAS? I know this issue was recently discussed and section 4.2 was updated to reflect the discussion, but I still find an inconsistency that should be resolved. Requested change: Remove "and avoid sending data on the link". From aboba@internaut.com Sun Aug 3 04:08:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 20:08:58 -0700 (PDT) Subject: [eap] Issue 165: Applicability statement Message-ID: Issue 165: Applicability Statement Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/2/2003 Reference: Document: RFC2284bis Comment type: T Priority: S Section: 1.4 Rationale/Explanation of issue: EAP needs an applicability statement so that it is clear when it is appropriate and inappropriate to use it. Insert the following section: 1.4 Applicability EAP is an authentication framework for use in situations, such as network access, in which the IP layer connectivity may not be available. Since the goal of EAP is to support authentication without requiring IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more. While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so that out of order reception is not supported. EAP itself does not support fragmentation; however, EAP methods may provide this support. Since EAP does not support fragmentation as in IP, or an efficient reliable transport service as in TCP [RFC793] or SCTP [RFC2960], an authentication protocol will typically require more round-trips when run over EAP than when run over IP. Since EAP does not support fragmentation, authentication protocols generating payloads larger than the EAP MTU will need to be modified in order to provide fragmentation support. As a result of these limitations, EAP is primarily applicable to network access authentication in situations where IP connectivity is unavailable. Where IP connectivity is available, it is advisable to choose an alternate authentication framework such as SASL [RFC2222] or GSS-API [RFC2743] running over transports such as UDP, TCP or SCTP. [RFC2743] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2743, January 2000. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. From Hubert.Ertl@de.gi-de.com Sun Aug 3 04:42:17 2003 From: Hubert.Ertl@de.gi-de.com (Hubert.Ertl@de.gi-de.com) Date: Sun, 3 Aug 2003 05:42:17 +0200 Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Message-ID: Ich werde ab 01.08.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 18.08.2003. I will read my email during my absence and will respond to your messag= e when I return on August 18th.= From aboba@internaut.com Sun Aug 3 04:22:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 2 Aug 2003 20:22:52 -0700 (PDT) Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: There are a few issues with the proposed approach. a. This is not what current implementations do, and RFC 2284bis is primarily about documenting existing behavior. By going with XML we would be creating two distinct and non-interoperable "hint" specifications, and that seems like a bad idea. b. Given that the Identity method doesn't support fragmentation, we are limited by the minimum MTU (see Issue 162). Given those limitations it would seem that the additional overhead of XML would be potentially problematic. ----------------------------------------------------------------------- In Issue 142, Bernard has suggested that specification of the Type-Data field data of Identity-Request after the nul character should include: a) An ABNF describing the grammar for the parameters and values; b) IANA considerations for allocation of parameters and values. Here is a suggestion for dealing with points a) and b). Suppose we use XML syntax instead of the previously proposed syntax for this data. IANA considerations can be dealt with using the XML namespace mechanism. Here is an example: display-string\0 The schema associated with urn:ietf.org:EAP:Netinfo would define the attributes networkid, nasid, portid, and whatever else might be appropriate. The leading is not strictly necessary, but it might be useful to help avoid confusion with existing practice that uses comma-separated attribute=3Dvalue syntax. One advantage of this approach is that vendor or domain-specific extensions can easily be added without requiring additional IANA requests. For example, display-string\0 To simplify parsing, it might be preferable that the schema restrict the NetInfo element to have only attributes, as shown in these examples (no child elements). Besides the parsing simplifications that this restriction would provide, attributes are also more compact than elements (no need for a trailing tag). Regards, Vic Lortz Intel Corporation From yohba@tari.toshiba.com Sun Aug 3 05:22:56 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Sat, 02 Aug 2003 21:22:56 -0700 Subject: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access In-Reply-To: References: Message-ID: <20030803042256.GA732@steelhead> I believe that the behavior on whether to "avoid sending data on the link or not" should be better specified in each EAP transport protocol, not in RFC2284 bis. I agree that when IEEE 802.1X is used the supplicant must avoid sending data on the link if EAP authentication fails, because it is the port-based access control model IEEE 802.1X defines. On the other hand, when PANA is used as the EAP transport, the PANA client may already obtain an IP address and is using the link (with a limited access) before EAP authentication occurs and thus "avoid sending data on the link" for the link already in use does not make sense. The suggested change is actually needed for PANA to support a scenario described in section 4.6. "Limited free access" of draft-ietf-pana-usage-scenarios-06.txt which is now in the IESG review after completing WGLC. EAP is an authentication protocol but "avoid sending data on the link" (which is a task of access control) is beyond the task of authentication protocol, thus the text should not be included in RFC2284bis. Yoshihiro Ohba On Sat, Aug 02, 2003 at 07:47:08PM -0700, Bernard Aboba wrote: > The text of Issue 150 is enclosed below. > > I don't think that the intent of section 7.9 is to make the interpretation > of EAP Failure implementation dependent -- this is the kind of thing that > needs to be standardized in order for the protocol to be interoperable. > > Allowing the peer to activate the link after receiving an indication > that the authenticator is not granting access seems dangerous because it > would be likely to either open the door to rogue authenticators or to > timeouts where the peer would attempt to obtain an IP address and fail, > leaving the user in limbo. > > My recommendation is that this change be rejected. > > ------------------------------------------------------------------ > Issue 150: Lower Layer Behavior for Limited Access > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date first submitted: June 18, 2003 > Reference: > Document: EAP-04 > Comment type: T > Priority: 1 > Section: 4.2 > Rationale/Explanation of issue: > > Text in section 7.9 allows limited access for peer after completion of > EAP authentication with failure, with stating that the interaction of > EAP with lower layers are highly implementation dependent. > > On the other hand, the following text in section 4.2 contains > some wording that does not seem to consistent with section 7.9. > > "On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure indication, > or the peer decides that it does want to continue the conversation, > possibly after sending a method-specific failure indication), the peer > MUST terminate the conversation and avoid sending data on the link." > > I think whether the peer avoids sending data on the link is a sort of > thing that should be described in each lower-layer protocol that > carries EAP, since this is heavily lower-layer dependent as described > in section 7.9. In fact, if the peer avoids sending data on the link, > limited access scenario cannot be realized (though it might depend on > the definition of "link"). In sectioni 4.2, it is described that a > backend EAP server can send EAP Success when it does not need to > authenticate the peer, but how it can determine it does not need to > authenticate the peer in a roaming environment where it might be > difficult for the EAP server to know the network access policy on the > remote NAS? I know this issue was recently discussed and section 4.2 > was updated to reflect the discussion, but I still find an > inconsistency that should be resolved. > > Requested change: > > Remove "and avoid sending data on the link". > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Sun Aug 3 09:08:27 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 03 Aug 2003 11:08:27 +0300 Subject: [eap] Issue 165: Applicability statement In-Reply-To: References: Message-ID: <3F2CC2FB.8000505@piuha.net> Bernard Aboba wrote: > EAP needs an applicability statement so that it is clear when it is > appropriate and inappropriate to use it. Right. Thanks for the text! > 1.4 Applicability > > EAP is an authentication framework for use in situations, such as network > access, in which the IP layer connectivity may not be available. > Since the goal of EAP is to support authentication without requiring > IP connectivity, it provides just enough support for the > reliable transport of authentication protocols, and no more. While EAP > provides support for retransmission, it assumes ordering guarantees > provided by the lower layer, so that out of order reception is not > supported. EAP itself does not support fragmentation; however, > EAP methods may provide this support. Looks good. > Since EAP does not support fragmentation as in IP, or an efficient > reliable transport service as in TCP [RFC793] or SCTP [RFC2960], > an authentication protocol will typically require more round-trips > when run over EAP than when run over IP. Since EAP does not > support fragmentation, authentication protocols generating payloads larger > than the EAP MTU will need to be modified in order to provide > fragmentation support. Yes. > As a result of these limitations, EAP is primarily applicable to network > access authentication in situations where IP connectivity is unavailable. > Where IP connectivity is available, it is advisable to choose an > alternate authentication framework such as SASL [RFC2222] or GSS-API > [RFC2743] running over transports such as UDP, TCP or SCTP. Hmm... I generally agree with the direction of this, but I do have problems with some of the details. In particular: - If you need authentication, you might not always need an authentication framework. For instance, if you need authentication for application X, you might do well with TLS, even we wouldn't normally call TLS an authentication framework. Therefore, I would suggest the following text modification: "... advisable to choose other security mechanisms such as TLS [ref] or IKE [ref] or an alternate authentication framework such as SASL ..." Question: how widely is SASL supported? Is it reasonable to recommend it as an alternative? - How would the suggested applicability statement relate to PANA and IKEv2 use of EAP? For PANA, one could argue that there's no IP access in any real sense before you authenticate. But for IKEv2, we most certainly do have IP access. I'm not really sure how to fix this. Perhaps the applicability of EAP is related more to network access "application" rather than the availability of EAP? - I suspect there might be other reasons beyond fragmentation that relate to the applicability of EAP. For instance, while the use of different credentials for network access is widespread, I sense that there is some level of desire in the IETF to control the true application layer authentication mechanisms to a smaller set of techniques, such as certs and passwords. Again, I'm not sure how to formulate this in text ;-( --Jari From jari.arkko@piuha.net Sun Aug 3 11:41:52 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 03 Aug 2003 13:41:52 +0300 Subject: [eap] minutes from EAP WG at IETF-57 Message-ID: <3F2CE6F0.8040205@piuha.net> This is a multi-part message in MIME format. --------------060209000500080300020803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit These are the preliminary minutes, collected by Dirk, Henrik, and John (thanks!). If you have any comments related to the minutes, let me know and I'll update them before posting them officially to the proceedings. --Jari --------------060209000500080300020803 Content-Type: text/plain; name="ietf57_eap_minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf57_eap_minutes.txt" Meeting Minutes of the EAP WG at IETF #57 LOCATION: Vienna Austria DATE: July 2003 SLIDES: http://www.drizzle.com/~aboba/EAP/ NOTES: Dirk Kroeselberg, John Vollbrecht, and Henrik Levkowetz (edited by Jari Arkko) SESSION I, MONDAY o Preliminaries (Jari Arkko) - Bluesheets - Agenda Bash No comments on the agenda. o Document Status (Jari Arkko) - Base spec finished second last call with 4 open issues left, one of them major. Glenn asked about the 3 issues left for 2284bis(?), and said he'd found 3 editorial issues already on the first page. The chairs requested Glenn to report the issues he found. - 2869bis approved by IESG, however some issues were found afterwards with 802.11i. - State machine to become WG item. - Binding problem according to the authors has no open issues left after list discussion. - Methods need expert review, can be informational or standard, but cannot progress before base docs are done. o EAP RADIUS - RFC 2869bis update, Bernard Aboba - Bernard talked about the 2869bis status. It has been approved for publication as an RFC. But two issues were raised afterwards, the intention is to discuss these and fix the document in author's 48 hours. The proposed fixes were (1) Order of attribute processing #157: Proposal to resolve by adding some correctional text. Jesse Walker: Agreed. Pasi Eronen: Order change is fine, but not sure whether this should be in 2869bis, because the order can be different for different link layers. Bernard Aboba: This is an EAP problem, because the order affects the operation of the protocol. (2) Identity privacy. Proposed Change: “the user-name attribute within the access-accept packet need not be the same as the user-name attribute in the access-request”) John Vollbrecht: thinks the user-name content has to be the same. Jari Arkko: Its unclear, who are we trying to protect. The AAA server does send ID of the user to the NAS anyway. Bernard Aboba: It is not only the identity of the user, but whatever is in the accounting message. Decision: Issues taken to the list for further discussion. o EAP Base - RFC 2284bis, Henrik Levkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.html http://www.drizzle.com/~aboba/EAP/eapissues.html - Remaining issues are 150, 151, 152, and 160. - Issue 150: lower-layer behaviour for limited access: Put to the list, as this needs more discussion - Issue 152: Lower layer indications: Text in 3.4 is not aligned with state machine draft. Clarified by Pasi Eronen: If you loose success packet, you can count on lower layers success indication. State machine does this “always”, EAP spec only allows this for methods with success acknowledgement. Bernard Aboba: following a survey, no one did implement this. So it is no useful. John Vollbrecht: State machine approach the is better approach Jari Arkko and Pasi Eronen: The practical impact is a long timeout if you do it as EAP specifies Bernard Aboba: The major impact is for PPP. Pasi Eronen: In WLAN there is a higher possibility of loosing the success packet, so this is affected as well. Bernard Aboba: Why would a mutually authenticated method not have success indication. This would be basically saying the client is happy when he authenticates the server. Pasi Eronen: But the server sends a link-layer success. John Vollbrecht: It may have been one of the major design flaws in EAP that both sides do not really know whether it succeeded Decision: The issue needs to be looked at in detail on the list. - Issue 160: Network selection assistance. EAP identity request, type field MUST not be null terminated according to spec. Some implementations embed a null octet to separate the message into a displayable and a non-displayable part. Glen Zorn: Not sure what the proposed solution is. Must be backwards-compatible. It is inappropriate to provide guidance on this. Someone: Need something, but it does not matter how this is done. Could be done as in the past with the null string. Zorn: The issue is at least 2 layers above EAP, not to be solved here. Conclusion: Discussion moved to the list? o EAP State Machine, Pasi Eronen http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-04.html http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.txt - Pasi Eronen spoke about the state of the EAP state machine draft. Significant progress has been made since the previous IETF, and a pre-alpha implementation by Yoshihiro Ohba. . Data flows are now shown in the diagram . Packets that should not occur are silently discarded. . Etc - Version 03 of the draft is incorporated in IEEE P802.1aa draft 6.1 (annex). - Discussion on the “pass-through & backend” slide. Bernard Aboba: I don't understand what the passthrough method does - it confuses the AAA action and the lower layer interfaces. There used to be a AAA layer in there, but now it is gone. That is the flaw. Glenn Zorn: The state machine has to look the same whether there is AAA or not. Pasi Eronen: Then I'd split the authenticator and back-end state machines, so that we can show how one gets the same result whether one uses a backend or not. First we specified one authentication diagram. Then did two separate, one for passthrough, one for back end. Bernard Aboba: AAA client has to be there: It is a pass-through until the last EAP message. Pasi Eronen: That is already reflected in the current draft, but not in a very elegant way. - Farid Adrangi: State which parts have to be implemented and which not? Pasi Eronen: The whole doc is informative, the specs are 2284bis and 2869bis. There are some cases where 2284bis says should but state machine does not cover the alternative. Therefore it has to stay informative. Future work may happen on EAP for tunnelled methods. In case there is a disagreement, 2284bis will be the normative document. - Jari Arkko: Will this become WG doc? There are still issues, so fix them, issue a new version and then make it WG doc. Bernard Aboba: How many read the draft? Result: About 3-4. All want to make it WG item. Decision: this will become a WG item. o Network Selection, Farid Adrangi - Farid Adrangi held a presentation on network selection in EAP. This draft is related to some potential requirements from 3GPP on EAP. Visited networks have different agreements with home; user 1) wants to be provided with a list of available visited networks 2) should be able to specify the VN Focus here on the first question. Presentation proposal: Open work item in EAP to analyse present requirements in an attempt to convey information (through EAP) to the UE for network selection. - Glenn Zorn: What is the use of this? Why would the client want to choose network? - Farid Adrangi: Because the different networks may have different services or costs. Glenn Zorn: Why can't you first authenticate, and then use some other protocol to choose? Farid Adrangi: It can cost to authenticate. - Glenn Zorn: Again, cannot this pre pre-configured, automatically updated? Farid Adrangi: The number of operator can be in the 100's, there is a scalability issue with Glenn's proposed method - Someone: This is not really a thing for EAP, you are looking for a service discovery method. - Glenn: Could you describe the difference between a service and a network providing a service? Farid Adrangi: Trying to find a way to select what network should route the packages. - Jari Arkko: Talk to the interested people to figure out what the right protocol for network selection is, and then submit a draft to that WG. o EAP SIM & AKA P. Eronen http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt - Pasi Eronen did a presentation on EAP SIM and AKA. The documents are quite stable now. They has been aligned with the key derivation as per 2284bis. - EAP-SIM: Recent clarification added related to the security analysis (see below). When multiple RAND values are used, check that they are different. Clarified security considerations. - EAP-AKA has relatively similar changes. - Next steps: Get reviews, wait until 2284bis is finished. Proposal to publish method as informational o EAP-SIM Security Analysis, Uri Blumenthal http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf - Uri Blumenthal presented the security analysis of EAP SIM. - There are some keyspace and mutual authentication weaknesses of EAP-SIM compared to what the specification currently says. - EAP SIM claims to enhance the security to 128bits, mutually authenticated with independent sessions. The analysis shows the possibility of two 64-bit attacks, and disproves session independence. - Glen Zorn: Is that an EAP-SIM or a GSM issue? Uri Blumenthal: The presentation just addresses the claims made in the EAP-SIM spec. - Bernard Aboba: Is the request, that lack of session independence should be added to the security considerations? Uri Blumenthal: yes. EAP-SIM Analysis response, Pasi Eronen - Pasi Responded as follows: 1) The text in the draft on key strength is somewhat different from what the Security Analysis addresses as claim (see slides). 2) There's a difference between an attack with probability 2^-64, and an attack which requires work of 2 to the 64 (and give an attack probability of 1) 3) The current document strongly recomments using 2 or 3 triplets, giving ~128 bit strength, rather than 1 triplet (giving ~64). In the newest version, text has been added to the latest draft that both client and server must use at least 2 triplets. EAP-SIM requires that the server always uses fresh RANDs, but the client cannot check (i.e. store). This is extensively discussed in security considerations. 4) The SIM used for authentication SHOULD NOT be used in GSM, because then attacks can be done on that network which has weaknesses not present in EAP SIM 5) There is no need to use SRES to increase key strength. - Jari Arkko: The conclusion is that methods need security review -- would be interesting with a similar analysis of AKA, for instance. It is essential that we agree what the security properties of the methods are (but users of EAP may have different opinions on what properties they require). We may also need additional requirements in 2284bis about session independence. SESSION II, THURSDAY o Report of the 802.1x ad-hoc interop test event (Karen O'Donoghue) - This event took place April 7-9, 2003 in Belmont, CA. Goal was to gain insight into status of products, to improve state of 802.1X interoperability, and to provide feedback to standards groups. - Issues identified were: . Specification interpretation issues. . Re-authentication, non-EAP agnostic authenticators (EAP type support, negotiation). . Inner auth methods (PEAP, TTLS), Wireless VLANs (no standards) . Bugs, bugs... . Administrative issue: Certificates are hard. Setting up took up a day, so prepare for more time next time. - Most of the problems were operational and implementation related. They may have been a few issues related to the clarity of of specifications, and Karen will send more information later on those. - InteropNet Labs is planning interop for next year. Test-suites are developed by the University of New Hampshire. o EAP Keying Framework (Bernard Aboba) http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt - Goal is to provide framework for evaluation of EAP key derivation mechanisms and transport mechanisms. EAP invariants are Media/Ciphersuite/Method independence. There are different relevant phases: 0) Discovery phase; discover authenticator (out-of-band for EAP): Phase 0. It is not secure. 1) EAP is Phase 1 between EAP peer and server. EAP SAs are bi-directional, Mutual authentication is required for key-deriving methods. Method provides keys (MSK, EMSK). EAP only supports key creation, no deletion. Running this phase does not mean that client want to connect at that time - preauthentication SA may be bidirectional. 2) SA Protocol (Phase 2): Used by EAP peer to derive SA with the EAP authenticator to protect data. Demonstrates "proof-of-possession " of phase 1 SA (key binding). - Jesse Walker: Are we going to discuss key/SA lifetime issue? Bernard Aboba: Currently no lifetime negotiated. There is the lifetime of EAP, or data, SA. EAP SA lifetime not relevant. Data SA lifetime should be done by Data SA protocol. This should still be discussed at some point. Jesse Walker: Usually its time, but often with cryptographic devices it is also other things, such as usage of a key for a large amount of data. Bernard Aboba: There are two lifetimes, the phase 1 and phase 2. it is conceivable that phase 1 could be used too many times, to cause sequence number overflow or something. Jesse Walker: I don't think we need to worry about that but the data key lifetime is relevant. - Why is binding/naming important? EAP and SA protocol may not run between same parties. EAP key name required to identify SAs. A link that the EAP runs on may have multiple authentications so need a name to be sure know which authentication to base a secure association on. - James Kempf: Is it the name of the key or the SA? Bernard Aboba: in this case it is the name of the key. - Lauri Tarkkala: Why not just refer to the latest key? If eap does not have a delete mechanism, why bother with the naming. As EAP does not delete keys, what is the policy how many keys are cached? Implementation specific logic required, but this may lead to interoperability issues. Bernard Aboba: Depends on the implementation or the load of the affected device. No specification required here. For instance, how busy the AP is could affect whether phase 1 can be cached for a day or 5 minutes. Lauri Tarkkala: I can agree with you reasoning, but it creates application specific reasoning. in ikev1 this has caused problems. Bernard Aboba: post the issue to the list so we can track this. - Bernard Aboba: EAP is a peer-to-peer protocol, but: AAA may not support role reversal; EAP methods may be client/server. - Open issues: . Issue 15: missing security requirements. Proposal: add material to address this in -07 draft . Issue 47: Key requirements unspecified (size of MSK/EMSK). Proposal: add nonce exchange requirement. The proposals or 15 and 47 were accepted. . Issue 99: Double expansion: occurs from MK to MSK and MSK to TSK: Proposal: reject, key strength is the issue, not double expansion. Jesse Walker: it is, there are papers. Bernard: please post references. . Issue 119: EAP is inappropriate for peer-to-peer. Proposal: reject. Jari Arkko: This may belong to RFC 2284bis. Jesse Walker: Not enough implementation experience that people really know about 119. Bernard Aboba: TLS methods are client-server, as they need different credentials on both sides. However, the best thing to find out is to try. . Issue 135: include SSID in PRF: Proposal: Reject (EAP is media independent, SSID does not exist on all media. During pre-authentication, SSID may not be available. There are issues for virtual APs). Alper Yegin: Other counterexamples are PANA and IKEv2. Lauri Tarkkala: SSID is too 802.1x-specific. Jari Arkko: Don't think there is a practical problem here. Jari: What about authorization? AP has to figure out which Phase 1 SAs it can use for which SSIDs. Isn't this an authorization problem? Jesse Walker: The real question is if MSK can be given to more than one NAS. If yes, don't care about the SSID. If no, Sometimes the information has to be given to the client that these are all the same thing so the MSK "compromise" is. Pat Calhoun: I ship a product that does this. Most clients get confused on multiple SSIDs, need to use virtual APs. I don't think we should share MSKs or move between virtual APs. - Bernard Aboba: I'll continue with updating 07 doc, resolve open issues. - Discussion continued about Russ Housley's requirements for key derivation presented at last IETF: . Key naming: Proposal for appropriate naming of EAP-SA, MK, MSK, EMSK, TSK. Issue: How do the NAS, EAP peer and AAA server come to agree on the key names? (NAS operates in pass-through, does not have access to MK or EMSK. Solution: AAA server needs to transmit this. . Comment: Discussion on this should be made part of the 2284bis Jari Arkko: Better to keep separate in the informational keying framework doc. Bernard Aboba: One document is standards track, the other is informational. . Alper Yegin: Where does the peer obtain the call-station-ID from? Bernard Aboba: usually lower layer; in the case of PANA this might be the IP address. . Someone: why is this keying framework informational? Bernard Aboba: there is a lot of informational stuff in the keying framework. . Jari Arkko: The mandatory parts will go in 2284bis in the end. o EAP Key Derivation for Multiple Applications, H. Zhou http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt - The idea of this draft is that multiple applications can be keyed from same MSK (protected-TLV, DHCP, PANA, fast roaming). Derive AMSK (application master keys) from EMSK. - Open issues: . KDF refinement . AAA attributes to request and deliver keys . Integration with key naming o Use of EAP Keying for DHCP Bootstrap (Hannes Tschofenig) http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt - Draft addresses EAP keying (derivation, distribution of MSK, derive PANA key). Key derivation for DHCP is based on PANA. There is a relation to "EAP Key Derivation for Multiple Applications" work. - Jari Arkko: What makes DHCP special, there are a lot of other things to be done for network access? - Hannes Tschofenig: network entities are different here. - Alper Yegin: Work is primarily for DHCP WG. An out-of-band key derivation scheme is missing. This is not meant to solve all the network access problems. - James Kempf: Why is PANA used here, couldn't we just use 802.1x or something that is there? - Hannes Tschofenig: PANA required; provides an additional set of nonces. Carries additional parameters required to establish SA with DHCP server. 802.1x does not allow this. - Kempf: One could extend 802.1x. Alper Yegin: Yes. - Result: Discussion taken offline. o EAP Compound Binding (Farid Adranghi) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt - Issues addressed in new version: . #64: Problem statement addressed in new version. . #65: Downgrading attack: Current draft now explains this. . #70: Which PRFs should be used? draft now says should be based on what tunnelling protocol is used. . #88: Why tunnel keys are used? use keys of the inner methods? not changed, tunnel keys are stronger. . #89: Review of version 1 draft now addressed. . #123: Non-key generating methods and binding: now addressed in 3.2. - Process for the doc: Submit for final crypto review, resolve new issues. - Farid: Time is of essence, should become WG doc soon. - Jari Arkko: former reviewers still need time to check their issues o EAP Client Side Transport (Florent Bersani) http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt - Presentation just gives a concept, does not really fit in the WG right now. Splits EAP endpoints in AuthToken (peer side) and AuthServer for authentication; integrity/encryption runs between client (peer) and server. Idea is separating authentication and service used later on. Approach motivated by smartcards / security tokens. - Separate authentication from service carrying authentication. Don't need to support smart cards inside device, e.g. can authenticate with Smart card on phone to use notebook/pc talks about tokens rather than client authenticator. o EAP Archie (Jesse Walker) http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt - Some Changes in -01 version: . Altered to use only one crypto primitive . Bindings changed to use define numbers address family - No further changes planned. Will only evolve in response to Bugs, suggestions to simplify. - Uri Blumenthal and Jesse Walker designing new Archie-like protocol (based on Archie and SKE). - John Vollbrecht: Make it either a straight or a tunnelled protocol? Jesse: No technical reasons against this, depends on the group's feedback. o EAP IKEv2 ( Hannes Tschofenig) http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-01.txt - Idea is to reuse good crypto and flexibility of IKEv2 as EAP method. Inherits IKEv2 security properties, including DoS protection. Does not exchange IPsec SA payloads. - Next steps: Incorporate comments already received, address key derivation and naming according to the current discussion. Stable version for the next IETF. - Open issues are sequencing of EAP methods, secure address configuration, protection of outer EAP methods (needed?). o EAP LDAP, Avi Lior http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt - EAP-LDAP is a challenge-based authentication using MD5, in conjunction with the encryption algorithm used to store the password within the LDAP identity store. Recommended to use in conjunction with tunneled methods. Could be extended to any other data store. Idea is to allow validation without passing password in clear. Draft requested to be WG draft. - Uri Blumenthal: But the cryptographic attack is the same for this as for MD5, you just do an extra step, but a dictionary attack is still possible. - Discussion: Comments moved to the list. o PEAP Version 2 (J. Salowey/A. Palekar) (Hao Zhou) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt - New draft addresses compound binding problem. Clarifications for implementors. Supports sequencing of methods in PEAP tunnel. - Lauri Tarkkala: Microsoft has IPR statement regarding PEAP. Does this apply to the new draft? They have stated there is nothing on the new draft? Zhou: cannot tell, not with MS. - Bernard Aboba: Why compound MAC and compound key are both done for binding? IKEv2 did only one of them? Zhou: Authors felt compound key does better security; did both however. o EAP Support in Smartcard, P. Urien http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt - Defines universal ISO 7816 interface; EAP-application on smartcard, that may be associated with different EAP-types. Supports lots of services and EAP SIM is supported, others under discussion. - Current Interfaces are network / OS+terminal / management+personalization / user. EAP-SSC (secure smartcard channel): uses single EAP type, defines symmetric or asymmetric key exchange procedures. - Future work: Rand number format rules for asymmetric case; message ciphering support. --------------060209000500080300020803-- From aboba@internaut.com Sun Aug 3 17:41:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 3 Aug 2003 09:41:22 -0700 (PDT) Subject: [eap] Issue 165: Applicability statement In-Reply-To: <3F2CC2FB.8000505@piuha.net> References: <3F2CC2FB.8000505@piuha.net> Message-ID: > - If you need authentication, you might not always need an > authentication framework. For instance, if you need authentication > for application X, you might do well with TLS, even we wouldn't > normally call TLS an authentication framework. > > Therefore, I would suggest the following text modification: > "... advisable to choose other security mechanisms such as > TLS [ref] or IKE [ref] or an alternate authentication framework > such as SASL ..." Sounds good. > Question: how widely is SASL supported? Is it reasonable to > recommend it as an alternative? SASL is pretty widely supported in directories and email systems, at least. GSS-API is reasonably widely supported as well, though Kerberos is by far the most widely used mechanism. I think it's fair to say that neither is as popular as EAP, though. > I'm not really sure how to fix this. Perhaps the applicability > of EAP is related more to network access "application" rather > than the availability of IP? EAP is sometimes used over IP (such as in Ethernet or PPP tunneling) in situations where a link layer is being simulated over IP. However, whenever EAP is run over IP there can be a large perforance penalty when EAP fragmentation occurs and there are lots of round trips. For example, in an EAP method with 20 round trips and a 100 ms RTT, the result is a 2 second latency when the same protocol run over TCP might require only 4 RTT or 400 ms. To some extent the problem can be avoided by presenting a large MTU to EAP and doing fragmentation within IP rather than within EAP. The other issue is EAP server-initiation, which can add a round-trip in situations where client-initiation is more appropriate. Both GSS-API and SASL are client-initiated. From alper@docomolabs-usa.com Sun Aug 3 23:54:16 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Sun, 03 Aug 2003 15:54:16 -0700 Subject: [eap] Issue 165: Applicability statement In-Reply-To: Message-ID: > Since EAP does not support fragmentation as in IP, or an efficient > reliable transport service as in TCP [RFC793] or SCTP [RFC2960], > an authentication protocol will typically require more round-trips > when run over EAP than when run over IP. Since EAP does not > support fragmentation, authentication protocols generating payloads larger > than the EAP MTU will need to be modified in order to provide > fragmentation support. > > As a result of these limitations, EAP is primarily applicable to network > access authentication in situations where IP connectivity is unavailable. I'm not sure if we can really come to this generalized conclusion. As I understand, this is driven by the fragmentation issue. For PANA, (limited) IP connectivity is available but that does not mean that fragmentation results in additional round-trips. Peer and authenticator are on the same IP-link, and the link MTU is known to both. IP can take care of fragmentation and reassembly that is transparent to EAP. Hence, IP connectivity does not mean additional round-trips. > Where IP connectivity is available, it is advisable to choose an > alternate authentication framework such as SASL [RFC2222] or GSS-API > [RFC2743] running over transports such as UDP, TCP or SCTP. Alper From jrv@umich.edu Mon Aug 4 16:29:17 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 11:29:17 -0400 Subject: [eap] Proposed resolution to Issue 164: Conflicting Implementation Note In-Reply-To: References: Message-ID: <570198.1059996554@[10.0.1.3]> sounds good to me - John --On Saturday, August 2, 2003 1:14 PM -0700 Bernard Aboba wrote: > The text of Issue 164 is enclosed below. The recommendation is that > the proposed change be accepted. Any objections? > > ------------------------------------------------------------------------- > Issue 164: Conflicting Implementation Note > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 7/29/2003 > Reference: > Document: RFC2284bis > Comment type: T > Priority: S > Section: 5.1 > Rationale/Explanation of issue: > > In section 2 [3] there is the following text > "After a suitable number of > retransmissions, the authenticator SHOULD end the EAP > conversation. The authenticator MUST NOT send a Success or > Failure packet when retransmitting or when it fails to get a > response from the peer." > > In section 5.1 there is the following text in the implementation note: > > "It is suggested that the Identity Request be > retried a minimum of 3 times before terminating the > authentication phase with a Failure reply." > > This seems contradictory. > > Requested change: > > Section 5.1 > > "It is suggested that the Identity Request be > retried a minimum of 3 times before terminating the > authentication." > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 16:30:06 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 11:30:06 -0400 Subject: [eap] Proposed Resolution to Issue 163: Minor Editorial Nit In-Reply-To: References: Message-ID: <573177.1059996604@[10.0.1.3]> good with me - John --On Saturday, August 2, 2003 1:17 PM -0700 Bernard Aboba wrote: > The text of issue 163 is enclosed below. The recommendation is that the > proposed change be accepted. Any objections? > > -------------------------------------------------------------------------- > Issue 163: Minor Editorial Nit > Submitter name: Lauri Tarkkala > Submitter email address: ltarkkal@ssh.com > Date first submitted: July 21, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-July/001508.html > Document: EAP-04 > Comment type: E > Priority: 2 > Section: 2.1 > Rationale/Explanation of issue: > Third paragraph in Section 2.1 states > > "A peer MUST NOT send a Nak (legacy or expanded) in reply to a > Request, after an initial non-Nak Response has been sent. Since > spoofed EAP Request packets may be sent by an attacker, an > authenticator receiving an unexpected Nak SHOULD silently > discard it and log the event." > > and in Section 1.2 we have the definition of 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." > > Recommended change: > > In section 2.1 change the third paragraph quoted above to > read: > > "A peer MUST NOT send a Nak (legacy or expanded) in reply to a > Request, after an initial non-Nak Response has been sent. Since > spoofed EAP Request packets may be sent by an attacker, an > authenticator receiving an unexpected NAK SHOULD > discard it and log the event." > > (e.g. remove the "silently", at first read I found this > a bit confusing). > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 16:58:03 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 11:58:03 -0400 Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined Message-ID: <673911.1059998283@[10.0.1.3]> The minimum MTU is an interesting question. I think I agree with Bernard. Here is what is seems to me. 1. EAP does not have a way of dynamically knowing how big it max frame may be, based on MTU or anything else 2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size to fragment to 3. Different lower layers may have different MTU 4. So, to be sure an EAP method runs on every lower layer, it must fragment at the Minimum MTU 5. If the Minimum MTU is smaller than the actual MTU, some methods will fragment unnecessarily, causing performance problems So, the alternatives seem to be a. Set a Minimum MTU that supports all the desired lower methods (possibly excluding some?) or b. Allow an implementation to configure a Minimum MTU which methods would note and fragment to support. The first seems simpler. The second provides better ability to tune performance and function. In either case, if a method does not support as low a fragmentation level as required by the lower layer it will not work. I think this is probably a method implementation issue, and should be included as a method requirement or limit. I lean to allowing implementation flexibility. What do others think? A straw man for sake of discussion might say something like: " Methods MUS support "minimum=?", fragmenting if required, and MAY support configurable fragmentation at lower level to support smaller lower layer MTU and higher level to support performance on larger MTUs. If Configurable MTU is supported the implemetation SHOULD notify the user if the configured MTU is too large for the lower layer. " --On Saturday, August 2, 2003 1:28 PM -0700 Bernard Aboba wrote: > The text of Issue 162 is enclosed below. Here is the proposed change and > some commentary: > > "Minimum MTU. The EAP layer, the EAP Identity method, > EAP Notification method and the NAK responses do NOT support > fragmentation and reassembly. " > > [BA] Recommend adding EAP OTP, GTC and Challenge-MD5 to this list. > > EAP methods designed originally > for use within PPP (where a 1500 byte MTU is guaranteed for > control frames [RFC1661]) also lack fragmentation and reassembly features. > > [BA] It is true that the methods defined in RFC 2284 also do not support > fragmentation and reassembly. Since we don't have specifications for > many methods that have been allocated type codes since then, it is hard to > say whether the statement above is true or not. Certainly EAP TLS [RFC > 2716] does support fragmentation. > > Question: Is a 1500 byte MTU really guaranteed for control frames? I seem > to recall situations where only a 576 octet MTU was available. My > suggestion is that the above sentence be changed to "may lack > fragmentation and reassembly features". > > "The lower layer transporting EAP MUST therefore be capable of carrying > EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a > lock-step protocol, which implies a certain inefficiency when doing > fragmentation and reassembly. The lower layer therefore SHOULD > provide fragmentation and reassembly services." > > [BA] I don't know that we can impose this requirement on lower layers > necessarily. After all, the lower layers are what they are. Suggest that > the MUST be changed to a SHOULD. Recommend that the last sentence be > deleted. Lower layers typically don't provide fragmentation and > reassembly services, since that's an IP layer function. > > "Some implementations of EAP tend to piggy-back into an Identity > Request or Response various options after a NUL-character. An EAP > implementation SHOULD NOT assume that usernames or displayable messages > over 1024 bytes in Identity Requests or Responses will work in all > environments." > > [BA] Why is the limit only 1024 octets for Identity and a different number > for other requests? > > Overall, my comment is that I'd prefer to recommend that methods assume a > certain minimum MTU and that they MUST support fragmentation and > reassembly if it is possible that frames can exceed this minimum MTU size. > My overall impression was that we might have to live with a minimum MTU as > low as 576 octets. > > > > --------------------------------------------------------------------- > Issue 162: Minimum MTU Not Defined > Submitter name: Lauri Tarkkala > Submitter email address: ltarkkal@ssh.com > Date first submitted: July 21, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-July/001507.html > Document: EAP-04 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > The current RFC2284bis draft does not define a minimum MTU that EAP > methods can rely on. At least the following EAP methods do not > do fragmenting: > - Identity > - Notification > - MD5-Challenge > - .. etc > (- and Nak, which is not a method, but anyway) > > Currently the "minimum MTU" is "inherited" from PPP (1500 bytes), > but all uses of EAP do not conform to this (e.g. PPPoe). > A minimum MTU must be defined such that embeddings of EAP into > other protocols will be such that implementations of these > methods will always operate correctly. There are also > the implied architectural limitations, which will cut > across any system architecture which contains EAP: > > - Maximum identity length (unfragmented MTU - headers bytes - > maximum length of piggy-backed option settings) > - Maximum notification length > > The defined minimum MTU should be defined to be as large > as possible, due to the lossage implied when doing > fragmentation/reassembly in a lock-step > protocol. Note also that the composite protocol > architecture may be doing fragmentation/reasembly > in both the EAP transport and the EAP method, if > the usage is improper. > > The proposed solution is in a nutshell: > - Define that minimum frame size that can be sent/received unfragmented > by EAP as X bytes. > - State the maximum notification length as X - headers. > - State the maximum identity req/resp lengths as > Y = X - headers - possible options > - State that because EAP is a lock-step protocol and if latency > is important and methods with large frames are used, the > EAP transport protocol SHOULD provide fragmentation and > reassembly services for frames upto 2^16 bytes. > - Initial proposal of X as 1400 bytes. If somebody knows any protocols > that use EAP with MTU's then I'm sure we'd all like to hear about it. > > Hopefully somebody has the relevant experience from all EAP > implementations to specify better values for X and Y than in the text > below (1400 and 1024 respectively). > > Requested change: > > In section 3.1 ("Lower layer requirements") add below. > > "[4] MTU known a-priori. The EAP layer does not support > fragmentation and reassembly. However, EAP methods SHOULD be capable of > handling fragmentation and reassembly. As a result, EAP is > capable of functioning across a range of MTU sizes, as long as > the MTU is known a-priori. EAP does not support path MTU discovery." > > to > > "[5] Minimum MTU. The EAP layer, the EAP Identity method, > EAP Notification method and the NAK responses do NOT support > fragmentation and reassembly. EAP methods designed originally > for use within PPP (where a 1500 byte MTU is guaranteed for > control frames [RFC1661]) also lack fragmentation and reassembly features. > The lower layer transporting EAP MUST therefore be capable of carrying > EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a > lock-step protocol, which implies a certain inefficiency when doing > fragmentation and reassembly. The lower layer therefore SHOULD > provide fragmentation and reassembly services." > > ... and Change the numbering of the following items from [5] -> [6] and > [6] -> [7]. > > After the first paragraph in "Section 5.1" add: > > "Some implementations of EAP tend to piggy-back into an Identity > Request or Response various options after a NUL-character. An EAP > implementation SHOULD NOT assume that usernames or displayable messages > over 1024 bytes in Identity Requests or Responses will work in all > environments." > > Add to first paragraph in "Section 5.2" the sentences: > > "Note that the maximum length of a notification messages that can be used > reliably in all EAP implementations is 1400 bytes. The length > of the human readable message SHOULD therefore be at most 1395 bytes." > > -- > Lauri Tarkkala > SSH Communications Security Corp > http://www.ssh.com/ > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 17:07:18 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 12:07:18 -0400 Subject: [eap] Discussion of Issue 152: Lower layer indications/comment In-Reply-To: References: Message-ID: <707185.1059998837@[10.0.1.3]> I agree with Bernard and Pasi that this is fine. I have one small note about Bernard's comment (copied from below) > So that the peer doesn't encounter a timeout, it probably makes sense to > have some assurance that the link is actually providing IP connectivity or > is likely to do so. > EAP could support any type of connectivity - in 802.1X is supprts turning on the Control Port, so it really is level 2 connectivity not IP connectivity that is being supported. -- John --On Saturday, August 2, 2003 7:24 PM -0700 Bernard Aboba wrote: > The text of Issue 152 is enclosed below. > > I think the major difference between the two > approaches is for one-way methods such as EAP-MD5 Challenge. > > With one-way methods a peer is ready to accept an EAP Success > after sending its Response. Since the peer does not > authenticate the authenticator it is willing to access > any network that indicates it is willing to grant access. > > In this case the proposed change is for a lower layer success > indication to cause the peer to conclude that it has been granted > access, even though it had no indication from EAP that the > authenticator was willing to grant access. > > This doesn't really create any new security vulnerabilities since a > one-way method is vulnerable to a spoofed EAP Success anyway. On the > other hand, one-way methods are really only appropriate for physically > secure wired media in which the loss rate should be very low, so that I > don't think there is that much benefit to be provided. > > So that the peer doesn't encounter a timeout, it probably makes sense to > have some assurance that the link is actually providing IP connectivity or > is likely to do so. > > So I think we might need to revise the definition of a > "lower layer success indication" so that it is likely to > be indicative of IP connectivity (e.g. PPP NCP or IP packets) > rather than just a layer 2 frame (e.g. Reassociation Response). > > If we take these factors into account, I think the change is ok, although > it is not all that beneficial. > > Of course, one issue with lower layer success indications > in general is that I don't believe there are any EAP implementations > that incorporate them. If that remains true then if > and when EAP goes to Draft Standard, we would need to > remove this functionality from RFC 2284bis. > > As far as lower layer failure indications are concerned, I think we > concluded that they would translate into "link down" indications in which > case the EAP conversation would abort anyway. Therefore there was no need > to discuss them explicitly. > > -------------------------------------------------------------- > Issue 152: Lower layer indications > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: July 6, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-July/001413.html > Document: EAP-04 > Comment type: T > Priority: 1 > Section: 3.4 > Rationale/Explanation of issue: > Section 3.4 says that > > "Section 4.2 defines the circumstances in which a peer, > having concluded an EAP method with successful acknowledged > result indications, may conclude that a Success packet has > been lost after expiration of a timeout. In those same > circumstances, if a peer receives a lower layer success > indication as defined in Section 7.2, it MAY conclude that a > Success packet has been lost without waiting for a > timeout. This ensures that an attacker spoofing lower layer > indications can at best succeed in a denial of service > attack." > > This is not exactly what the current state machine does... > > The current text says that "if you are in a situation where a > timeout would lead to success (that is, you have received a > method-specific success indication), also lower-layer success > indication does." > > What the current state mechine does is "if you are in a > situation where receiving an EAP Success packet would lead to > success, also lower-layer success indication does." Or in other > words, the effect of receiving a lower-layer success indication > is identical to receiving an EAP Success: if an EAP Success > packet would be silently discarded, so is the lower-layer > success indication. > > Both are IMHO quite reasonable approaches, and I just > wanted to clarify which one we really want to use? > [Jari Arkko] Hmm... if we get a method specific success indication, > shouldn't > we enable then in all three cases below: > (a) Success received > (b) Lower-layer success indication > (c) Timeout? > [Pasi Eronen] You're right, and that happens in both approaches. The only > difference is in what to do when we don't have a method specific > indication. In this case, > > - both approaches enable the link if Success is received > - both approaches fail on timeout > - the current state machine enables the link if lower-layer > success indication is received, while 2284bis-04 says that > the lower-layer success indication must be ignored > (presumably leading to failure in timeout later). > > Which approach do you think we should use? > > A second issue: Earlier versions of the draft also mentioned > lower-layer failure indications (e.g. "Lower layer failure > indications provided to EAP by the lower layer MUST be processed > and will cause an EAP exchange in progress to be aborted." in > -03 version). This seems to be missing from -04, and I think > the old text still applies? > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 17:08:48 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 12:08:48 -0400 Subject: [eap] Proposed resolution to Issue 151: EAP-04 comments In-Reply-To: References: Message-ID: <712501.1059998926@[10.0.1.3]> These seem good to me -- John --On Saturday, August 2, 2003 7:42 PM -0700 Bernard Aboba wrote: > The text of Issue 151 is enclosed below. Overall, these changes look good > and the proposed resolution is to accept them, with the exception of the > change relating to "granting access." Since only some methods do key > derivation, the existing paragraph seems to cover more cases and the > proposed text does not really substitute for it. > > Here are the proposed fixes: > > In Section 2, change: > > "ince EAP is a peer-to-peer protocol, an > independent and simultaneous authentication may take place in > the reverse direction." > > To: > > "Since EAP is a peer-to-peer protocol, an independent and > simultaneous authentication may take place in the reverse > direction (depending on the capabilities of the lower layer)." > > In Section 4.2, change: > > "Success or Failure packets MUST NOT be sent by > an EAP authenticator prior to completion of the final round > of a given method. A peer EAP implementation receiving a > Success or Failure packet prior to completion of the method > in progress MUST silently discard it." > > To: > > "Success and Failure packets MUST NOT be sent by an EAP > authenticator if the specification of the given method does not > explicitly permit the method to finish at that point. A peer EAP > implementation receiving a Success or Failure packet where > sending one is not explicitly permitted MUST silently discard it." > > In Section 5.7, change: > > "EAP Types from 0 through 255 are semantically > identical whether they appear as single octet EAP Types or as > Vendor-Types when Vendor-Id is zero." > > To: > > "EAP Types from 0 through 255 are semantically > identical whether they appear as single octet EAP Types or as > Vendor-Types when Vendor-Id is zero. There is one exception to > this rule: Expanded Nak and Legacy Nak packets share the same > code, but must be treated differently because they have a > different format." > > In Appendix B, add "Support for mutual authentication and key derivation." > > In the reference section, update the references to RFC 2869bis (should > obtain an RFC number soon) and SASLPREP. > > Also, change references to PIC to a reference to IKEv2. > > ------------------------------------------------------------------------- > --- Issue 151: EAP-04 comments > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: July 6, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-July/001412.html > Document: EAP-04 > Comment type: T > Priority: 1 > Section: Various > Rationale/Explanation of issue: > > Overall, the draft looks fine, and it seems that we're finally > close to getting it finished! In hindsight, there are a couple > of things that might have been clearer if organized differently, > but it probably doesn't make sense to do such changes at this > point. > --- > > (Section 2) "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. For a discussion of > security issues in peer-to-peer operation, see Section 7.7. > > I think this does not apply to all lower layers. Perhaps it > should be rephrased to something like "Some lower layers for > carrying EAP, such as PPP, may support peer-to-peer operation, > in which an independent and...". > > [Jari Arkko] > Yes. [Alternative re-formulation: "Since EAP is a peer-to-peer > protocol, an independent and simultaneous authentication may take > place in the reverse direction (depending on the capabilities > of the lower layer)."] > --- > > (Section 4.2) "Success or Failure packets MUST NOT be sent by > an EAP authenticator prior to completion of the final round > of a given method. A peer EAP implementation receiving a > Success or Failure packet prior to completion of the method > in progress MUST silently discard it." > > I think there are several EAP methods where the number of rounds > varies (so the phrase "the final round" is not well defined), > depending on many issues, including whether the method is > going to succeed or not. > > Perhaps this would better take that into account? > > "Success and Failure packets MUST NOT be sent by an EAP > authenticator if the specification of the given method does not > allow the method to finish at that point. A peer EAP > implementation receiving a Success or Failure packet where > sending one is not allowed MUST silently discard it." > > [Jari Arkko] Sounds good! > --- > > (Section 4.2) "If the peer attempts to authenticate to the > authenticator and fails to do so, the authenticator MUST send a > Failure packet and MUST NOT grant access by sending a Success > packet." > > I know that this was beaten to death already :-) But since > we have not defined what "failing to authenticate to the > authenticator" means, does this actually impose any > requirements for EAP implementations? > > (The problem is that "failing to authenticate" could be thought > as "not successfully authenticating"; but according to the > definition of "successful authentication" in Section 1.2, the > above requirement does not make much sense.) > > Perhaps this would capture the intent? > > "If the peer attempts to authenticate to the authenticator using > a method that provides key derivation, the authenticator SHOULD > NOT grant access by sending a Success packet if the key > derivation has failed for some reason." > > [Jari Arkko] Works for me. Maybe delete "for some reason". > --- > > (Section 5.7) "EAP Types from 0 through 255 are semantically > identical whether they appear as single octet EAP Types or as > Vendor-Types when Vendor-Id is zero." > > (Section 5.7) "An implementation that supports the Expanded > attribute MUST treat EAP Types that are less than 256 > equivalently whether they appear as a single octet or as the > 32-bit Vendor-Type within a Expanded Type where Vendor-Id is > 0." and > > Otherwise fine, but Expanded Nak packets have a different format > than Legacy Nak packets, so they are not treated exactly > identically. > > Perhaps we should add something like "There is one exception to > this rule: Expanded Nak and Legacy Nak packets share the same > code, but must be treated differently because they have a > different format." (an alternative would be to change the > code of Expanded Naks to something else, but probably > this is easier?) > > [Jari Arkko] Yes. > --- > Appendix B: Two significant changes to RFC 2284 are not > mentioned: mutual authentication and key derivation > (RFC 2284 did not even mention either of them). > > [Jari Arkko] Ok. > ---- > References: There are newer versions of RFC2869bis and SASLPREP > drafts available (Ok, RFC editor will probably handle these...) > > [Jari Arkko] Better update them now, just for consistency. > ---- > References: PIC is most likely dead and superceded by IKEv2, so > maybe we should remove references to PIC and add a pointer to > IKEv2? > > [Jari Arkko] Yes, that can be done. (Both the IKEv2 and PANA references > would be non-normative, by the way, so that we don't have > to wait for either one to complete.) > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Mon Aug 4 17:59:04 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 4 Aug 2003 09:59:04 -0700 (PDT) Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: <673911.1059998283@[10.0.1.3]> References: <673911.1059998283@[10.0.1.3]> Message-ID: > 1. EAP does not have a way of dynamically knowing how big it max frame may > be, based on MTU or anything else Since the EAP layer doesn't support fragmentation, the MTU is only relevant to an EAP method that supports fragmentation. Also, where EAP is run over the Internet, the MTU would need to be determined by path-MTU discovery and/or set to a large value if the intent is to handle fragmentation via a reliable transport (TCP, SCTP) or via IP fragmentation. But there *are* mechanisms by which the MTU, once determined can be utilized by EAP methods. Existing implementations do this. If we are talking about EAP over a link layer, then on the peer the link layer MTU can be passed up to the EAP method which can adjust its frame size, assuming that it supports fragmentation. Things are trickier on the authentication server. It can determine the appropriate EAP MTU from the NAS-Port-Type attribute as well as the Framed-MTU attribute. For 802.1X and PPP this is Framed-MTU - 4; for other NAS-Port-Type values the calculation might be different. > 2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size to > fragment to I would say SHOULD do fragmentation and SHOULD make use of MTU information passed from the lower layer. > 3. Different lower layers may have different MTU Yes. > 4. So, to be sure an EAP method runs on every lower layer, it must fragment > at the Minimum MTU An EAP method needs to support fragmentation if its frames can be larger than the minimum MTU. But I don't agree that it needs to fragment if it knows that the MTU is large enough so that fragmentation isn't required. > 5. If the Minimum MTU is smaller than the actual MTU, some methods will > fragment unnecessarily, causing performance problems This is not required. > So, the alternatives seem to be > > a. Set a Minimum MTU that supports all the desired lower methods (possibly > excluding some?) Not sure what a "lower method" is. Do you mean "lower layer"? The purpose of setting a minimum MTU is so that methods can determine whether they need to support fragmentation or not. For example, EAP Archie does not support fragmentation -- but depending on the minimum MTU, adding support might be appropriate. > b. Allow an implementation to configure a Minimum MTU which methods would > note and fragment to support. It is undesirable to force fragmentation to a minimum MTU when the actual MTU is known to be larger. From jrv@umich.edu Mon Aug 4 20:04:04 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 15:04:04 -0400 Subject: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access Message-ID: <893268.1060009444@[10.0.1.3]> As Bernard points out, I think the need for implementation independence is required for a standard. However, if I understand Yohihiro's issue correctly, I think the question is more about what the lower layer is than about independence. A suggestion below for change. First a couple comments. If the lower layer asks if what the user can do, then the response might be a. connect to the world b. connect to the walled garden c. no connection available I think case a/c is the normal case, and is what Bernard is considering. However, case a/b is what I think Yoshihiro may be considering. In case b the user imay be connected to the local net but not the Internet. I think EAP is set to say "yes" (possibly with conditions [authenticate and authorize]), or no. Assuming EAP says "yes" or "no", the question being answered is important. The question might be "should I grand access" [case a/c]] or "should I grant Internet Access" [case a/b]. It is case b that seems interesting in the request. The text assumes case a/c. I think not referring to the lower layer may satisfy both sides. My suggestion is as follows: change: > "On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure indication, > or the peer decides that it does want to continue the conversation, > possibly after sending a method-specific failure indication), the peer > MUST terminate the conversation and avoid sending data on the link." to "On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and indicate failure to the lower layer." -- John --On Saturday, August 2, 2003 7:47 PM -0700 Bernard Aboba wrote: > The text of Issue 150 is enclosed below. > > I don't think that the intent of section 7.9 is to make the interpretation > of EAP Failure implementation dependent -- this is the kind of thing that > needs to be standardized in order for the protocol to be interoperable. I am thinking that the change to EAP would be to take out the > Allowing the peer to activate the link after receiving an indication > that the authenticator is not granting access seems dangerous because it > would be likely to either open the door to rogue authenticators or to > timeouts where the peer would attempt to obtain an IP address and fail, > leaving the user in limbo. > > My recommendation is that this change be rejected. > > ------------------------------------------------------------------ > Issue 150: Lower Layer Behavior for Limited Access > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date first submitted: June 18, 2003 > Reference: > Document: EAP-04 > Comment type: T > Priority: 1 > Section: 4.2 > Rationale/Explanation of issue: > > Text in section 7.9 allows limited access for peer after completion of > EAP authentication with failure, with stating that the interaction of > EAP with lower layers are highly implementation dependent. > > On the other hand, the following text in section 4.2 contains > some wording that does not seem to consistent with section 7.9. > > "On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure indication, > or the peer decides that it does want to continue the conversation, > possibly after sending a method-specific failure indication), the peer > MUST terminate the conversation and avoid sending data on the link." > > I think whether the peer avoids sending data on the link is a sort of > thing that should be described in each lower-layer protocol that > carries EAP, since this is heavily lower-layer dependent as described > in section 7.9. In fact, if the peer avoids sending data on the link, > limited access scenario cannot be realized (though it might depend on > the definition of "link"). In sectioni 4.2, it is described that a > backend EAP server can send EAP Success when it does not need to > authenticate the peer, but how it can determine it does not need to > authenticate the peer in a roaming environment where it might be > difficult for the EAP server to know the network access policy on the > remote NAS? I know this issue was recently discussed and section 4.2 > was updated to reflect the discussion, but I still find an > inconsistency that should be resolved. > > Requested change: > > Remove "and avoid sending data on the link". > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 20:33:55 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 15:33:55 -0400 Subject: [eap] Issue 165: Applicability statement In-Reply-To: References: Message-ID: <1000682.1060011235@[10.0.1.3]> Thanks for doing this - a few comments below - --On Saturday, August 2, 2003 8:08 PM -0700 Bernard Aboba wrote: > Issue 165: Applicability Statement > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/2/2003 > Reference: > Document: RFC2284bis > Comment type: T > Priority: S > Section: 1.4 > Rationale/Explanation of issue: > > EAP needs an applicability statement so that it is clear when it is > appropriate and inappropriate to use it. > > Insert the following section: > > 1.4 Applicability > > EAP is an authentication framework for use in situations, such as network > access, in which the IP layer connectivity may not be available. > Since the goal of EAP is to support authentication without requiring > IP connectivity, it provides just enough support for the > reliable transport of authentication protocols, and no more. While EAP > provides support for retransmission, it assumes ordering guarantees > provided by the lower layer, so that out of order reception is not > supported. EAP itself does not support fragmentation; however, > EAP methods may provide this support. > > Since EAP does not support fragmentation as in IP, or an efficient > reliable transport service as in TCP [RFC793] or SCTP [RFC2960], > an authentication protocol will typically require more round-trips > when run over EAP than when run over IP. Since EAP does not > support fragmentation, authentication protocols generating payloads larger > than the EAP MTU will need to be modified in order to provide > fragmentation support. > Excellent point. This assumes there is no feedback to the method of the desired MTU. I think this might be a good idea. > As a result of these limitations, EAP is primarily applicable to network > access authentication in situations where IP connectivity is unavailable. > Where IP connectivity is available, it is advisable to choose an > alternate authentication framework such as SASL [RFC2222] or GSS-API > [RFC2743] running over transports such as UDP, TCP or SCTP. > The concept of no IP seems problematic. PANA uses IP, IPSECv2 (over IP) uses EAP. I think much of what is said is correct, but I am not sure how the above cases fit. Seems that EAP is used also to provided a "generic" authentication method where other methods could be used but don't fit the existing infrastructure. I am not sure this is correct - are there other thoughts? > [RFC2743] > Linn, J., "Generic Security Service Application Program Interface, Version > 2", RFC 2743, January 2000. > > [RFC2222] > Myers, J., "Simple Authentication and Security Layer (SASL)", > RFC 2222, October 1997. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Aug 4 20:43:25 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 15:43:25 -0400 Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: References: <673911.1059998283@[10.0.1.3]> Message-ID: <1034914.1060011805@[10.0.1.3]> --On Monday, August 4, 2003 9:59 AM -0700 Bernard Aboba wrote: > > 1. EAP does not have a way of dynamically knowing how big it max frame > > may be, based on MTU or anything else > > Since the EAP layer doesn't support fragmentation, the MTU is only > relevant to an EAP method that supports fragmentation. > > Also, where EAP is run over the Internet, the MTU would need to be > determined by path-MTU discovery and/or set to a large value if the intent > is to handle fragmentation via a reliable transport (TCP, SCTP) or via IP > fragmentation. > > But there *are* mechanisms by which the MTU, once determined can be > utilized by EAP methods. Existing implementations do this. > > If we are talking about EAP over a link layer, then on the peer the link > layer MTU can be passed up to the EAP method which can adjust its frame > size, assuming that it supports fragmentation. Things are trickier on the > authentication server. It can determine the appropriate EAP MTU from the > NAS-Port-Type attribute as well as the Framed-MTU attribute. For 802.1X > and PPP this is Framed-MTU - 4; for other NAS-Port-Type values the > calculation might be different. > Should we include such mechanisms to pass MTU to the method in either 2284bis or EAP-SM? I think it could be a reasonable option. > > 2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size > > to fragment to > > I would say SHOULD do fragmentation and SHOULD make use of MTU information > passed from the lower layer. > as you point out, fragmentat only if needed. And fragment to a standard "minimum" or to what is passed from the lower layer. > > 3. Different lower layers may have different MTU > > Yes. > > > 4. So, to be sure an EAP method runs on every lower layer, it must > > fragment at the Minimum MTU > > An EAP method needs to support fragmentation if its frames can be larger > than the minimum MTU. But I don't agree that it needs to fragment if it > knows that the MTU is large enough so that fragmentation isn't required. > yes > > 5. If the Minimum MTU is smaller than the actual MTU, some methods will > > fragment unnecessarily, causing performance problems > > This is not required. yes - if MTU is passed, then fragmentation can be to the passed value, not the minimum. > > > So, the alternatives seem to be > > > > a. Set a Minimum MTU that supports all the desired lower methods > > (possibly excluding some?) > > Not sure what a "lower method" is. Do you mean "lower layer"? yes > The > purpose of setting a minimum MTU is so that methods can determine whether > they need to support fragmentation or not. For example, EAP Archie does > not support fragmentation -- but depending on the minimum MTU, adding > support might be appropriate. > agree > > b. Allow an implementation to configure a Minimum MTU which methods > > would note and fragment to support. > > It is undesirable to force fragmentation to a minimum MTU when the actual > MTU is known to be larger. agree - my issue is how it know how big it is > From henrik@levkowetz.com Mon Aug 4 20:49:57 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Mon, 4 Aug 2003 21:49:57 +0200 Subject: [eap] New intermediary draft: draft-ietf-eap-rfc2284bis-05.g.txt Message-ID: <20030804214957.116865c9.henrik@levkowetz.com> Hi, A series of new intermediate versions (numbered -05.a to -05.g) of the EAPbis draft is available for inspection here: http://www.levkowetz.com/ietf/drafts/eap/ These drafts reflect the successive apliccation of the text from the following issues which have been resolved since version -04: Issue 143, 144, 146, 147, 148, 151, 153, 154, 156, 158, 159, 163, 164 For more detail on open and resolved issues, see the EAP Issues List at: http://www.drizzle.com/~aboba/EAP/eapissues.html Best regards, Henrik From yohba@tari.toshiba.com Mon Aug 4 20:55:55 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Mon, 04 Aug 2003 12:55:55 -0700 Subject: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access In-Reply-To: <893268.1060009444@[10.0.1.3]> References: <893268.1060009444@[10.0.1.3]> Message-ID: <20030804195555.GI27902@steelhead> The new text proposed by John works fine with me. Yoshihiro Ohba On Mon, Aug 04, 2003 at 03:04:04PM -0400, John Vollbrecht wrote: > > As Bernard points out, I think the need for implementation independence is > required for a standard. However, if I understand Yohihiro's issue > correctly, I think the question is more about what the lower layer is than > about independence. A suggestion below for change. First a couple > comments. > > If the lower layer asks if what the user can do, then the response might be > > a. connect to the world > b. connect to the walled garden > c. no connection available > > I think case a/c is the normal case, and is what Bernard is considering. > However, case a/b is what I think Yoshihiro may be considering. > In case b the user imay be connected to the local net but not the Internet. > > > I think EAP is set to say "yes" (possibly with conditions [authenticate and > authorize]), or no. Assuming EAP says "yes" or "no", the question being > answered is important. The question might be "should I grand access" [case > a/c]] or "should I grant Internet Access" [case a/b]. > > It is case b that seems interesting in the request. The text assumes case > a/c. I think not referring to the lower layer may satisfy both sides. My > suggestion is as follows: > change: > > > >"On the peer, once the method completes unsuccessfully (that is, > >either the authenticator sends a method-specific failure indication, > >or the peer decides that it does want to continue the conversation, > >possibly after sending a method-specific failure indication), the peer > >MUST terminate the conversation and avoid sending data on the link." > > to > > "On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure indication, > or the peer decides that it does want to continue the conversation, > possibly after sending a method-specific failure indication), the peer > MUST terminate the conversation and indicate failure to the lower layer." > > -- John > > > --On Saturday, August 2, 2003 7:47 PM -0700 Bernard Aboba > wrote: > > >The text of Issue 150 is enclosed below. > > > >I don't think that the intent of section 7.9 is to make the interpretation > >of EAP Failure implementation dependent -- this is the kind of thing that > >needs to be standardized in order for the protocol to be interoperable. > > > > I am thinking that the change to EAP would be to take out the > >Allowing the peer to activate the link after receiving an indication > >that the authenticator is not granting access seems dangerous because it > >would be likely to either open the door to rogue authenticators or to > >timeouts where the peer would attempt to obtain an IP address and fail, > >leaving the user in limbo. > > > >My recommendation is that this change be rejected. > > > >------------------------------------------------------------------ > >Issue 150: Lower Layer Behavior for Limited Access > >Submitter name: Yoshihiro Ohba > >Submitter email address: yohba@tari.toshiba.com > >Date first submitted: June 18, 2003 > >Reference: > >Document: EAP-04 > >Comment type: T > >Priority: 1 > >Section: 4.2 > >Rationale/Explanation of issue: > > > >Text in section 7.9 allows limited access for peer after completion of > >EAP authentication with failure, with stating that the interaction of > >EAP with lower layers are highly implementation dependent. > > > >On the other hand, the following text in section 4.2 contains > >some wording that does not seem to consistent with section 7.9. > > > >"On the peer, once the method completes unsuccessfully (that is, > >either the authenticator sends a method-specific failure indication, > >or the peer decides that it does want to continue the conversation, > >possibly after sending a method-specific failure indication), the peer > >MUST terminate the conversation and avoid sending data on the link." > > > >I think whether the peer avoids sending data on the link is a sort of > >thing that should be described in each lower-layer protocol that > >carries EAP, since this is heavily lower-layer dependent as described > >in section 7.9. In fact, if the peer avoids sending data on the link, > >limited access scenario cannot be realized (though it might depend on > >the definition of "link"). In sectioni 4.2, it is described that a > >backend EAP server can send EAP Success when it does not need to > >authenticate the peer, but how it can determine it does not need to > >authenticate the peer in a roaming environment where it might be > >difficult for the EAP server to know the network access policy on the > >remote NAS? I know this issue was recently discussed and section 4.2 > >was updated to reflect the discussion, but I still find an > >inconsistency that should be resolved. > > > >Requested change: > > > >Remove "and avoid sending data on the link". > > > > > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Aug 5 00:01:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 4 Aug 2003 16:01:25 -0700 (PDT) Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: <1034914.1060011805@[10.0.1.3]> References: <673911.1059998283@[10.0.1.3]> <1034914.1060011805@[10.0.1.3]> Message-ID: > Should we include such mechanisms to pass MTU to the method in either > 2284bis or EAP-SM? I think it could be a reasonable option. I'd suggest that we should at least describe what is within the realm of possibility and provide some advice on what implementations should do. In practice, we've seen quite a few interoperability problems result from ignoring the MTU. For example, there are RADIUS implementations that attempt to send 16K EAP-TLS frames over an 802.11 link :) > as you point out, fragmentat only if needed. And fragment to a standard > "minimum" or to what is passed from the lower layer. Right -- if no information is available, the default assumption is the minimum MTU. Otherwise use what is passed from the lower layer. > agree - my issue is how it know how big it is Yes. That's what we've got figure out: what is the minimum MTU for EAP if no other information is available? From jrv@umich.edu Tue Aug 5 01:19:52 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 04 Aug 2003 20:19:52 -0400 Subject: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: References: <673911.1059998283@[10.0.1.3]> <1034914.1060011805@[10.0.1.3]> Message-ID: <1852163.1060028392@[10.0.1.3]> --On Monday, August 4, 2003 4:01 PM -0700 Bernard Aboba wrote: . . . > Right -- if no information is available, the default assumption is the > minimum MTU. Otherwise use what is passed from the lower layer. > > > agree - my issue is how it know how big it is > > Yes. That's what we've got figure out: what is the minimum MTU for EAP if > no other information is available? and how to describe what is passed to the EAP method. It sounds like you have a good handle on this from what you described earlier. Should there be an interface to the method describing a variable that it can check to see if an MTU is available? do people think the spec should also include operational info, like how to decide what to pass the method? For example, if the MTU can be determined by the lower layer then everything could be automatic if the method can deal with the MTU it gets. If the lower layer is not able to send the MTU, should the MTU be configurable? > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap