From eap-admin@frascone.com Sun Aug 3 20:28:18 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00947 for ; Sun, 3 Aug 2003 20:28:18 -0400 (EDT) Received: (qmail 26310 invoked from network); 4 Aug 2003 00:28:21 -0000 Received: from localhost (HELO wolverine) (www-data@127.0.0.1) by localhost with SMTP; 4 Aug 2003 00:28:21 -0000 Date: Sun, 03 Aug 2003 19:28:21 -0500 Message-ID: <20030804002821.26300.84326.Mailman@wolverine> Subject: Welcome to the "eap" mailing list From: eap-request@frascone.com To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Welcome to the eap@frascone.com mailing list! To post to this list, send your email to: eap@frascone.com General information about the mailing list is at: http://mail.frascone.com/mailman/listinfo/eap If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: eap-request@frascone.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: ohweow If you forget your password, don't worry, you will receive a monthly reminder telling you what all your frascone.com mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From eap-admin@frascone.com Mon Aug 4 11:29:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01440 for ; Mon, 4 Aug 2003 11:29:04 -0400 (EDT) Received: (qmail 8507 invoked from network); 4 Aug 2003 15:29:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 15:29:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 8485 invoked from network); 4 Aug 2003 15:28:38 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 15:28:38 -0000 Received: from [10.0.1.3] (pm475-47.dialip.mich.net [207.75.179.105]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74FSW108885; Mon, 4 Aug 2003 11:28:32 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 164: Conflicting Implementation Note Message-ID: <570198.1059996554@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 11:29:17 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 11:30:48 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01464 for ; Mon, 4 Aug 2003 11:30:47 -0400 (EDT) Received: (qmail 8777 invoked from network); 4 Aug 2003 15:30:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 15:30:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 8623 invoked from network); 4 Aug 2003 15:29:27 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 15:29:27 -0000 Received: from [10.0.1.3] (pm475-47.dialip.mich.net [207.75.179.105]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74FTK109198; Mon, 4 Aug 2003 11:29:20 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 163: Minor Editorial Nit Message-ID: <573177.1059996604@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 11:30:06 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 11:58:14 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02419 for ; Mon, 4 Aug 2003 11:58:00 -0400 (EDT) Received: (qmail 9651 invoked from network); 4 Aug 2003 15:58:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 15:58:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 9627 invoked from network); 4 Aug 2003 15:57:20 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 15:57:20 -0000 Received: from [10.0.1.3] (pm478-14.dialip.mich.net [207.75.179.216]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74FvE121213; Mon, 4 Aug 2003 11:57:14 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined Message-ID: <673911.1059998283@[10.0.1.3]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 11:58:03 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 12:07:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02657 for ; Mon, 4 Aug 2003 12:07:04 -0400 (EDT) Received: (qmail 10115 invoked from network); 4 Aug 2003 16:07:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 16:07:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 10073 invoked from network); 4 Aug 2003 16:06:37 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 16:06:37 -0000 Received: from [10.0.1.3] (pm478-14.dialip.mich.net [207.75.179.216]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74G6U125359; Mon, 4 Aug 2003 12:06:31 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Discussion of Issue 152: Lower layer indications/comment Message-ID: <707185.1059998837@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 12:07:18 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 12:11:01 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02763 for ; Mon, 4 Aug 2003 12:10:51 -0400 (EDT) Received: (qmail 10389 invoked from network); 4 Aug 2003 16:09:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 16:09:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 10292 invoked from network); 4 Aug 2003 16:08:20 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 16:08:20 -0000 Received: from [10.0.1.3] (pm478-14.dialip.mich.net [207.75.179.216]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74G84125973; Mon, 4 Aug 2003 12:08:05 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 151: EAP-04 comments Message-ID: <712501.1059998926@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 12:08:48 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 13:28:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04880 for ; Mon, 4 Aug 2003 13:28:06 -0400 (EDT) Received: (qmail 11976 invoked from network); 4 Aug 2003 17:28:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 17:28:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 11954 invoked from network); 4 Aug 2003 17:28:00 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 17:28:00 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h74Gx4S09373; Mon, 4 Aug 2003 09:59:04 -0700 From: Bernard Aboba To: John Vollbrecht cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: <673911.1059998283@[10.0.1.3]> Message-ID: References: <673911.1059998283@[10.0.1.3]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Aug 2003 09:59:04 -0700 (PDT) > 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 15:04:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08145 for ; Mon, 4 Aug 2003 15:04:08 -0400 (EDT) Received: (qmail 13903 invoked from network); 4 Aug 2003 19:04:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 19:04:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 13880 invoked from network); 4 Aug 2003 19:03:33 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 19:03:33 -0000 Received: from [10.0.1.3] (pm661-47.dialip.mich.net [207.75.182.153]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74J3IN01134; Mon, 4 Aug 2003 15:03:18 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access Message-ID: <893268.1060009444@[10.0.1.3]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 15:04:04 -0400 Content-Transfer-Encoding: 7bit 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 eap-admin@frascone.com Mon Aug 4 15:34:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10099 for ; Mon, 4 Aug 2003 15:34:04 -0400 (EDT) Received: (qmail 14790 invoked from network); 4 Aug 2003 19:34:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 19:34:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 14764 invoked from network); 4 Aug 2003 19:33:14 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 19:33:14 -0000 Received: from [10.0.1.3] (pm661-47.dialip.mich.net [207.75.182.153]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74JX8N13184; Mon, 4 Aug 2003 15:33:09 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 165: Applicability statement Message-ID: <1000682.1060011235@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 15:33:55 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 15:43:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10226 for ; Mon, 4 Aug 2003 15:43:06 -0400 (EDT) Received: (qmail 15242 invoked from network); 4 Aug 2003 19:43:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 19:43:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 15220 invoked from network); 4 Aug 2003 19:42:43 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 19:42:43 -0000 Received: from [10.0.1.3] (pm661-47.dialip.mich.net [207.75.182.153]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h74JgZN16844; Mon, 4 Aug 2003 15:42:35 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined Message-ID: <1034914.1060011805@[10.0.1.3]> In-Reply-To: References: <673911.1059998283@[10.0.1.3]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 15:43:25 -0400 Content-Transfer-Encoding: 7bit --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 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 15:51:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10311 for ; Mon, 4 Aug 2003 15:51:04 -0400 (EDT) Received: (qmail 15824 invoked from network); 4 Aug 2003 19:51:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 19:51:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 15799 invoked from network); 4 Aug 2003 19:50:25 -0000 Received: from 213.80.52.78.dataphone.se (HELO mailgw.local.ipunplugged.com) (213.80.52.78) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 19:50:25 -0000 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id h74Jnvwf004317; Mon, 4 Aug 2003 21:49:58 +0200 From: Henrik Levkowetz To: "eap@frascone.com" Message-Id: <20030804214957.116865c9.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [eap] New intermediary draft: draft-ietf-eap-rfc2284bis-05.g.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Aug 2003 21:49:57 +0200 Content-Transfer-Encoding: 7bit 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 15:58:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10454 for ; Mon, 4 Aug 2003 15:58:05 -0400 (EDT) Received: (qmail 16335 invoked from network); 4 Aug 2003 19:58:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 19:58:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 16284 invoked from network); 4 Aug 2003 19:57:01 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 19:57:01 -0000 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h74JuwVj009706; Tue, 5 Aug 2003 04:56:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h74JuxgM019825; Tue, 5 Aug 2003 04:56:59 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA19818 ; Tue, 5 Aug 2003 04:56:58 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA27885; Tue, 5 Aug 2003 04:56:58 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA17297; Tue, 5 Aug 2003 04:56:57 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h74Ju45N007312; Tue, 5 Aug 2003 04:56:55 +0900 (JST) Received: from localhost ([159.119.168.136]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HJ4001XB21A85@tsbpo1.po.toshiba.co.jp>; Tue, 5 Aug 2003 04:55:59 +0900 (JST) From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access In-reply-to: <893268.1060009444@[10.0.1.3]> To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com Message-id: <20030804195555.GI27902@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 126 References: <893268.1060009444@[10.0.1.3]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 12:55:55 -0700 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 19:31:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15553 for ; Mon, 4 Aug 2003 19:31:01 -0400 (EDT) Received: (qmail 20267 invoked from network); 4 Aug 2003 23:31:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 4 Aug 2003 23:31:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 20232 invoked from network); 4 Aug 2003 23:30:22 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 4 Aug 2003 23:30:22 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h74N1Q329653; Mon, 4 Aug 2003 16:01:26 -0700 From: Bernard Aboba To: John Vollbrecht cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined In-Reply-To: <1034914.1060011805@[10.0.1.3]> Message-ID: References: <673911.1059998283@[10.0.1.3]> <1034914.1060011805@[10.0.1.3]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Aug 2003 16:01:25 -0700 (PDT) > 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? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 4 20:20:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16151 for ; Mon, 4 Aug 2003 20:20:05 -0400 (EDT) Received: (qmail 21239 invoked from network); 5 Aug 2003 00:20:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 00:20:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 21204 invoked from network); 5 Aug 2003 00:19:07 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 00:19:07 -0000 Received: from [10.0.1.3] (pm638-21.dialip.mich.net [207.75.181.223]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h750J3N13599; Mon, 4 Aug 2003 20:19:03 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined Message-ID: <1852163.1060028392@[10.0.1.3]> In-Reply-To: References: <673911.1059998283@[10.0.1.3]> <1034914.1060011805@[10.0.1.3]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Aug 2003 20:19:52 -0400 Content-Transfer-Encoding: 7bit --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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 5 09:54:13 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11150 for ; Tue, 5 Aug 2003 09:54:05 -0400 (EDT) Received: (qmail 4729 invoked from network); 5 Aug 2003 13:54:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 13:54:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 4695 invoked from network); 5 Aug 2003 13:53:40 -0000 Received: from fmr06.intel.com (HELO caduceus.jf.intel.com) (134.134.136.7) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 13:53:40 -0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h75DlD329770 for ; Tue, 5 Aug 2003 13:47:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h75DGYN10055 for ; Tue, 5 Aug 2003 13:16:34 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080506531226441 for ; Tue, 05 Aug 2003 06:53:12 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 06:53:12 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: Thread-Topic: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request thread-index: AcNZcrrqYoRfEasNQYGizrl0z0sk4wB32aQg From: "Lortz, Victor" To: X-OriginalArrivalTime: 05 Aug 2003 13:53:12.0903 (UTC) FILETIME=[E97CDD70:01C35B58] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Aug 2003 06:53:12 -0700 Content-Transfer-Encoding: quoted-printable In that case, I have an additional suggestion. I think the namespace = feature of XML is a very useful feature for enabling innovation by = multiple independent implementations without creating naming conflicts. = When you have a simple list of "attribute=3Dvalue" syntax with no = additional structure to provide context, there is a substantial risk of = collisions. =20 Suppose we borrow the idea of XML namespaces without actually using XML. = The original attribute set that is already planned to be standardized = using IANA registration could be considered as belonging to a default = namespace and thus need no namespace prefix. This case would be 100% = compatible with existing implementations. =20 However, for vendor-specific or domain-specific attributes, a namespace = attribute could be included along with a prefix for decorating those = attributes. Existing implementations would see both the namespace and = attributes in that namespace simply as unrecognized attributes that they = would presumably ignore. The advantage is that new implementations that = understand the new attributes could use them without risk of confusion = with identically-named attributes that have different semantics. The = biggest impact on existing implementations would be that their attribute = name parsers would need to support a namespace prefix delimiter. We may = as well use the same ":" character that XML uses. Here is an example: networkid=3DSomeSSID, nasid=3DSomeNASName, portid=3D123,=20 eapns:v=3Durn:vendor.com:net-info:1, v:foo=3Dsome value, v:bar=3Dsome = other value =20 Here is some proposed ABNF for this syntax: identity-request-data =3D displayable-string [ %d0 network-info ] displayable-string =3D *CHAR network-info =3D item ["," item ] item =3D attribute "=3D" value=20 ; attribute names must start with a letter or underscore attribute =3D (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default = namespace attribute =3D/ "eapns:" 1*ALPHA ; namespace prefix declaration attribute =3D/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) = ; namespace-qualified value =3D 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except "," Regards, Vic =20 -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Saturday, August 02, 2003 8:23 PM To: eap@frascone.com Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request 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=3D3Dvalue 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 _______________________________________________ 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 eap-admin@frascone.com Tue Aug 5 10:32:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13741 for ; Tue, 5 Aug 2003 10:32:02 -0400 (EDT) Received: (qmail 5716 invoked from network); 5 Aug 2003 14:32:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 14:32:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 5694 invoked from network); 5 Aug 2003 14:31:56 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 14:31:56 -0000 Received: from [10.0.1.3] (pm473-19.dialip.mich.net [207.75.178.221]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h75EVpN13236; Tue, 5 Aug 2003 10:31:52 -0400 (EDT) From: John Vollbrecht To: "Lortz, Victor" , eap@frascone.com Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: <2324712.1060079511@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Aug 2003 10:31:54 -0400 Content-Transfer-Encoding: 7bit I apologize for my confusion, but I need a little help. As far as I know the EAP Identity Request does not include any attribute value pairs. This suggestion seems to be suggesting adding an environment attribute to the Identity request to support vendor specific attributes. Perhaps this is meant to be about RADIUS messages? Is this about expanding the meaning of data in the Identity Response? I think I am missing something? -- John --On Tuesday, August 5, 2003 6:53 AM -0700 "Lortz, Victor" wrote: > In that case, I have an additional suggestion. I think the namespace > feature of XML is a very useful feature for enabling innovation by > multiple independent implementations without creating naming conflicts. > When you have a simple list of "attribute=value" syntax with no > additional structure to provide context, there is a substantial risk of > collisions. > > Suppose we borrow the idea of XML namespaces without actually using XML. > The original attribute set that is already planned to be standardized > using IANA registration could be considered as belonging to a default > namespace and thus need no namespace prefix. This case would be 100% > compatible with existing implementations. > > However, for vendor-specific or domain-specific attributes, a namespace > attribute could be included along with a prefix for decorating those > attributes. Existing implementations would see both the namespace and > attributes in that namespace simply as unrecognized attributes that they > would presumably ignore. The advantage is that new implementations that > understand the new attributes could use them without risk of confusion > with identically-named attributes that have different semantics. The > biggest impact on existing implementations would be that their attribute > name parsers would need to support a namespace prefix delimiter. We may > as well use the same ":" character that XML uses. Here is an example: > > networkid=SomeSSID, nasid=SomeNASName, portid=123, > eapns:v=urn:vendor.com:net-info:1, v:foo=some value, v:bar=some other > value > Here is some proposed ABNF for this syntax: > > identity-request-data = displayable-string [ %d0 network-info ] > displayable-string = *CHAR > > network-info = item ["," item ] > item = attribute "=" value > > ; attribute names must start with a letter or underscore > attribute = (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default > namespace attribute =/ "eapns:" 1*ALPHA ; namespace prefix declaration > attribute =/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; > namespace-qualified > > value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except "," > > Regards, > Vic > > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Saturday, August 02, 2003 8:23 PM > To: eap@frascone.com > Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in > Type-Data field of Identity-Request > > > 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 networkid=3D"SomeSSID" nasid=3D"SomeNASName" portid=3D"123" /> > > 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 xmlns:gsm=3D"urn:3gpp.org:wlan-info:1" networkid=3D"SomeSSID" > nasid=3D"SomeNASName" portid=3D"123" gsm:VPLMNS=3D"123456 123654 111222" > /> > > 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 > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 5 11:56:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16952 for ; Tue, 5 Aug 2003 11:56:01 -0400 (EDT) Received: (qmail 7810 invoked from network); 5 Aug 2003 15:56:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 15:56:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 7786 invoked from network); 5 Aug 2003 15:55:32 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 15:55:32 -0000 Received: from [10.0.1.3] (pm472-35.dialip.mich.net [207.75.178.189]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h75FtRN22355; Tue, 5 Aug 2003 11:55:28 -0400 (EDT) From: John Vollbrecht To: jari.arkko@piuha.net, "eap@frascone.com" Subject: Re: [eap] minutes from EAP WG at IETF-57 Message-ID: <2626831.1060084546@[10.0.1.3]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Aug 2003 11:55:46 -0400 Content-Transfer-Encoding: 7bit Jari -- thanks a lot for doing this. I think these are really helpful. In going through this I started thinking a lot about status. I realize this is implicitly in Bernard's EAP page, but a specific task list might be helpful. As a strawnan for what I am thinking in terms of status, Ipresent the following. Please recognize that this is meant to be a help, and may include too much or too little. My thought is that clarity with this complex a task could be helpful. 1) 2869bis [RADIUS/EAP] - ready to go with 24 hour turnaround but some discussion on list 2) 2284bis is in last call with 4 items (point to items) and discussion on list 3) EAP State Machine - draft available, now wg item, discussion on list 4) Keying Framework - draft available, wg item, [work items?] 5) Compound Authentication - draft available, wg item, review by ? underway 6) Method requirements - abstract from 2284bis and Keying Framework, required for 2284bis release?, discusssion on list 7) Method Implementation - several drafts available, not wg items yet, need at least one with mutual authentication for 2284bis, methods must be reviewed prior to advancement 8) use of tunnelled methods - out of band currently 9) interface with 802.1X - EAP/ lower layer specified in 802.1X, must match in EAP, expecially in State machine again, thanks for the minutes and I am interested if the above suggestion helps. John --On Sunday, August 3, 2003 1:41 PM +0300 Jari Arkko wrote: > 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 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 5 12:42:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18268 for ; Tue, 5 Aug 2003 12:41:59 -0400 (EDT) Received: (qmail 9187 invoked from network); 5 Aug 2003 16:42:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 16:42:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 9165 invoked from network); 5 Aug 2003 16:41:16 -0000 Received: from fmr05.intel.com (HELO hermes.jf.intel.com) (134.134.136.6) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 16:41:16 -0000 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h75Gcgw14688 for ; Tue, 5 Aug 2003 16:38:43 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h75GZnc09395 for ; Tue, 5 Aug 2003 16:35:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080509404815622 for ; Tue, 05 Aug 2003 09:40:48 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:40:48 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: Thread-Topic: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request thread-index: AcNbXlMZ6KE2s+fkRX6OjmlZkMFvJAAEV3dA From: "Lortz, Victor" To: X-OriginalArrivalTime: 05 Aug 2003 16:40:48.0309 (UTC) FILETIME=[52FA0E50:01C35B70] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Aug 2003 09:40:47 -0700 Content-Transfer-Encoding: quoted-printable No, we are not talking about RADIUS attributes. Issue 142 discusses the = format for data placed in the Type-Data field of the Identity-Request = message. The latest 2284bis draft says that there can be a displayable = string before a NULL character and non-displayable data after the NULL. = However, the format for the latter is not specified. Some existing = implementations use a syntax attribute1=3Dvalue, ... attributeN=3DValue = in this field. =20 -Vic -----Original Message----- From: John Vollbrecht [mailto:jrv@umich.edu] Sent: Tuesday, August 05, 2003 7:32 AM To: Lortz, Victor; eap@frascone.com Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request I apologize for my confusion, but I need a little help. As far as I = know=20 the EAP Identity Request does not include any attribute value pairs. = This=20 suggestion seems to be suggesting adding an environment attribute to the = Identity request to support vendor specific attributes. Perhaps this is meant to be about RADIUS messages? Is this about=20 expanding the meaning of data in the Identity Response? I think I am missing something? -- John --On Tuesday, August 5, 2003 6:53 AM -0700 "Lortz, Victor"=20 wrote: > In that case, I have an additional suggestion. I think the namespace > feature of XML is a very useful feature for enabling innovation by > multiple independent implementations without creating naming = conflicts. > When you have a simple list of "attribute=3Dvalue" syntax with no > additional structure to provide context, there is a substantial risk = of > collisions. > > Suppose we borrow the idea of XML namespaces without actually using = XML. > The original attribute set that is already planned to be standardized > using IANA registration could be considered as belonging to a default > namespace and thus need no namespace prefix. This case would be 100% > compatible with existing implementations. > > However, for vendor-specific or domain-specific attributes, a = namespace > attribute could be included along with a prefix for decorating those > attributes. Existing implementations would see both the namespace and > attributes in that namespace simply as unrecognized attributes that = they > would presumably ignore. The advantage is that new implementations = that > understand the new attributes could use them without risk of confusion > with identically-named attributes that have different semantics. The > biggest impact on existing implementations would be that their = attribute > name parsers would need to support a namespace prefix delimiter. We = may > as well use the same ":" character that XML uses. Here is an example: > > networkid=3DSomeSSID, nasid=3DSomeNASName, portid=3D123, > eapns:v=3Durn:vendor.com:net-info:1, v:foo=3Dsome value, v:bar=3Dsome = other > value > Here is some proposed ABNF for this syntax: > > identity-request-data =3D displayable-string [ %d0 network-info ] > displayable-string =3D *CHAR > > network-info =3D item ["," item ] > item =3D attribute "=3D" value > > ; attribute names must start with a letter or underscore > attribute =3D (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default > namespace attribute =3D/ "eapns:" 1*ALPHA ; namespace prefix = declaration > attribute =3D/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / = DIGIT) ; > namespace-qualified > > value =3D 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except "," > > Regards, > Vic > > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Saturday, August 02, 2003 8:23 PM > To: eap@frascone.com > Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint = in > Type-Data field of Identity-Request > > > 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 networkid=3D3D"SomeSSID" nasid=3D3D"SomeNASName" portid=3D3D"123" /> > > 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=3D3Dvalue 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 xmlns:gsm=3D3D"urn:3gpp.org:wlan-info:1" networkid=3D3D"SomeSSID" > nasid=3D3D"SomeNASName" portid=3D3D"123" gsm:VPLMNS=3D3D"123456 123654 = 111222" > /> > > 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 > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 5 16:55:20 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28408 for ; Tue, 5 Aug 2003 16:55:15 -0400 (EDT) Received: (qmail 14690 invoked from network); 5 Aug 2003 20:55:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 20:55:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 14660 invoked from network); 5 Aug 2003 20:54:56 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 20:54:56 -0000 Received: from [10.0.1.3] (pm476-06.dialip.mich.net [207.75.179.112]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h75Kspv18316; Tue, 5 Aug 2003 16:54:51 -0400 (EDT) From: John Vollbrecht To: "Lortz, Victor" , eap@frascone.com Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: <3215252.1060102540@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Aug 2003 16:55:40 -0400 Content-Transfer-Encoding: 7bit Thanks - I get the idea. So I think this is a standardization question. If one includes this sort of information in the draft, then there is a standard way to support it, and other implementations would have a way to interact with it. If we don't put it in, this is still possible, but there is no standard. I don't know but think that including this would require a lot of discussion about alternatives and such, which would delay the draft. If it is a good thing to do, perhaps a brief informational RFC showing how it works would be simpler to do than put it in this draft? -- John --On Tuesday, August 5, 2003 9:40 AM -0700 "Lortz, Victor" wrote: > No, we are not talking about RADIUS attributes. Issue 142 discusses the > format for data placed in the Type-Data field of the Identity-Request > message. The latest 2284bis draft says that there can be a displayable > string before a NULL character and non-displayable data after the NULL. > However, the format for the latter is not specified. Some existing > implementations use a syntax attribute1=value, ... attributeN=Value in > this field. > > -Vic > > -----Original Message----- > From: John Vollbrecht [mailto:jrv@umich.edu] > Sent: Tuesday, August 05, 2003 7:32 AM > To: Lortz, Victor; eap@frascone.com > Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info > hint in Type-Data field of Identity-Request > > > > I apologize for my confusion, but I need a little help. As far as I know > the EAP Identity Request does not include any attribute value pairs. > This suggestion seems to be suggesting adding an environment attribute > to the Identity request to support vendor specific attributes. > > Perhaps this is meant to be about RADIUS messages? Is this about > expanding the meaning of data in the Identity Response? > > I think I am missing something? > > -- John > > --On Tuesday, August 5, 2003 6:53 AM -0700 "Lortz, Victor" > wrote: > > > In that case, I have an additional suggestion. I think the namespace > > feature of XML is a very useful feature for enabling innovation by > > multiple independent implementations without creating naming conflicts. > > When you have a simple list of "attribute=value" syntax with no > > additional structure to provide context, there is a substantial risk of > > collisions. > > > > Suppose we borrow the idea of XML namespaces without actually using XML. > > The original attribute set that is already planned to be standardized > > using IANA registration could be considered as belonging to a default > > namespace and thus need no namespace prefix. This case would be 100% > > compatible with existing implementations. > > > > However, for vendor-specific or domain-specific attributes, a namespace > > attribute could be included along with a prefix for decorating those > > attributes. Existing implementations would see both the namespace and > > attributes in that namespace simply as unrecognized attributes that they > > would presumably ignore. The advantage is that new implementations that > > understand the new attributes could use them without risk of confusion > > with identically-named attributes that have different semantics. The > > biggest impact on existing implementations would be that their attribute > > name parsers would need to support a namespace prefix delimiter. We may > > as well use the same ":" character that XML uses. Here is an example: > > > > networkid=SomeSSID, nasid=SomeNASName, portid=123, > > eapns:v=urn:vendor.com:net-info:1, v:foo=some value, v:bar=some other > > value > > Here is some proposed ABNF for this syntax: > > > > identity-request-data = displayable-string [ %d0 network-info ] > > displayable-string = *CHAR > > > > network-info = item ["," item ] > > item = attribute "=" value > > > > ; attribute names must start with a letter or underscore > > attribute = (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default > > namespace attribute =/ "eapns:" 1*ALPHA ; namespace prefix declaration > > attribute =/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; > > namespace-qualified > > > > value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except "," > > > > Regards, > > Vic > > > > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Saturday, August 02, 2003 8:23 PM > > To: eap@frascone.com > > Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in > > Type-Data field of Identity-Request > > > > > > 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 > networkid=3D"SomeSSID" nasid=3D"SomeNASName" portid=3D"123" /> > > > > 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 > xmlns:gsm=3D"urn:3gpp.org:wlan-info:1" networkid=3D"SomeSSID" > > nasid=3D"SomeNASName" portid=3D"123" gsm:VPLMNS=3D"123456 123654 111222" > > /> > > > > 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 > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 5 18:50:24 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02288 for ; Tue, 5 Aug 2003 18:50:15 -0400 (EDT) Received: (qmail 17169 invoked from network); 5 Aug 2003 22:50:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Aug 2003 22:50:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 17111 invoked from network); 5 Aug 2003 22:49:19 -0000 Received: from fmr05.intel.com (HELO hermes.jf.intel.com) (134.134.136.6) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Aug 2003 22:49:19 -0000 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h75Mkk101480 for ; Tue, 5 Aug 2003 22:46:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h75Mhrh13829 for ; Tue, 5 Aug 2003 22:43:53 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080516010011287 for ; Tue, 05 Aug 2003 16:01:00 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 15:48:51 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: Thread-Topic: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request thread-index: AcNbk9SPG4UnjxlvSfShAZlTm97WZQADyhmg From: "Lortz, Victor" To: X-OriginalArrivalTime: 05 Aug 2003 22:48:51.0664 (UTC) FILETIME=[BDAE9D00:01C35BA3] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Aug 2003 15:48:51 -0700 Content-Transfer-Encoding: quoted-printable John, you and Bernard had the exact same thoughts. He previously = suggested making standardization of this data field the subject of a = separate RFC to avoid delaying 2284bis. I sent my recent proposals to = the EAP list in part to find out if others were interested in = collaborating with us on this problem. We also wanted to test the = waters a bit to see how acceptable the solutions we were thinking of = would be to others on the list. Regards, Vic -----Original Message----- From: John Vollbrecht [mailto:jrv@umich.edu] Sent: Tuesday, August 05, 2003 1:56 PM To: Lortz, Victor; eap@frascone.com Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Thanks - I get the idea. So I think this is a standardization question. If one includes this = sort=20 of information in the draft, then there is a standard way to support = it,=20 and other implementations would have a way to interact with it. If we don't put it in, this is still possible, but there is no standard. I don't know but think that including this would require a lot of=20 discussion about alternatives and such, which would delay the draft. If = it=20 is a good thing to do, perhaps a brief informational RFC showing how it=20 works would be simpler to do than put it in this draft? -- John --On Tuesday, August 5, 2003 9:40 AM -0700 "Lortz, Victor"=20 wrote: > No, we are not talking about RADIUS attributes. Issue 142 discusses = the > format for data placed in the Type-Data field of the Identity-Request > message. The latest 2284bis draft says that there can be a = displayable > string before a NULL character and non-displayable data after the = NULL. > However, the format for the latter is not specified. Some existing > implementations use a syntax attribute1=3Dvalue, ... = attributeN=3DValue in > this field. > > -Vic > > -----Original Message----- > From: John Vollbrecht [mailto:jrv@umich.edu] > Sent: Tuesday, August 05, 2003 7:32 AM > To: Lortz, Victor; eap@frascone.com > Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info > hint in Type-Data field of Identity-Request > > > > I apologize for my confusion, but I need a little help. As far as I = know > the EAP Identity Request does not include any attribute value pairs. > This suggestion seems to be suggesting adding an environment = attribute > to the Identity request to support vendor specific attributes. > > Perhaps this is meant to be about RADIUS messages? Is this about > expanding the meaning of data in the Identity Response? > > I think I am missing something? > > -- John > > --On Tuesday, August 5, 2003 6:53 AM -0700 "Lortz, Victor" > wrote: > > > In that case, I have an additional suggestion. I think the = namespace > > feature of XML is a very useful feature for enabling innovation by > > multiple independent implementations without creating naming = conflicts. > > When you have a simple list of "attribute=3Dvalue" syntax with no > > additional structure to provide context, there is a substantial risk = of > > collisions. > > > > Suppose we borrow the idea of XML namespaces without actually using = XML. > > The original attribute set that is already planned to be = standardized > > using IANA registration could be considered as belonging to a = default > > namespace and thus need no namespace prefix. This case would be = 100% > > compatible with existing implementations. > > > > However, for vendor-specific or domain-specific attributes, a = namespace > > attribute could be included along with a prefix for decorating those > > attributes. Existing implementations would see both the namespace = and > > attributes in that namespace simply as unrecognized attributes that = they > > would presumably ignore. The advantage is that new implementations = that > > understand the new attributes could use them without risk of = confusion > > with identically-named attributes that have different semantics. = The > > biggest impact on existing implementations would be that their = attribute > > name parsers would need to support a namespace prefix delimiter. We = may > > as well use the same ":" character that XML uses. Here is an = example: > > > > networkid=3DSomeSSID, nasid=3DSomeNASName, portid=3D123, > > eapns:v=3Durn:vendor.com:net-info:1, v:foo=3Dsome value, = v:bar=3Dsome other > > value > > Here is some proposed ABNF for this syntax: > > > > identity-request-data =3D displayable-string [ %d0 network-info ] > > displayable-string =3D *CHAR > > > > network-info =3D item ["," item ] > > item =3D attribute "=3D" value > > > > ; attribute names must start with a letter or underscore > > attribute =3D (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default > > namespace attribute =3D/ "eapns:" 1*ALPHA ; namespace prefix = declaration > > attribute =3D/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / = DIGIT) ; > > namespace-qualified > > > > value =3D 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except = "," > > > > Regards, > > Vic > > > > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Saturday, August 02, 2003 8:23 PM > > To: eap@frascone.com > > Subject: [eap] Re: Issue 142 suggestion: syntax for network info = hint in > > Type-Data field of Identity-Request > > > > > > 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 > networkid=3D3D"SomeSSID" nasid=3D3D"SomeNASName" portid=3D3D"123" = /> > > > > 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=3D3Dvalue 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 > xmlns:gsm=3D3D"urn:3gpp.org:wlan-info:1" networkid=3D3D"SomeSSID" > > nasid=3D3D"SomeNASName" portid=3D3D"123" gsm:VPLMNS=3D3D"123456 = 123654 111222" > > /> > > > > 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 > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 03:22:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08292 for ; Wed, 6 Aug 2003 03:22:03 -0400 (EDT) Received: (qmail 26307 invoked from network); 6 Aug 2003 07:22:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 07:22:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 26272 invoked from network); 6 Aug 2003 07:21:16 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 07:21:16 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h766qEZ06459 for ; Tue, 5 Aug 2003 23:52:14 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed resolution to Issue 162: Minimum MTU not defined Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Aug 2003 23:52:14 -0700 (PDT) The text of Issue 162 is enclosed below. The proposed fix is as follows: In section 3.1, Change: "[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: "[4] Minimum MTU. EAP is capable of functioning on lower layers that provide an EAP MTU size of 1020 octets or greater. EAP does not support path MTU discovery, and fragmentation and reassembly is not supported by EAP, nor by the methods defined in this specification: the Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) and expanded NAK Response (254) Types. Typically, the EAP peer obtains information on the EAP MTU from the lower layers and sets the EAP frame size to an appropriate value. Where the authenticator operates in pass-through mode, the authentication server does not have a direct way of determining the EAP MTU, and therefore relies on the authenticator to provide it with this information, such as via the Framed-MTU attribute, described in [RFC3579], Section 2.4. While methods such as EAP-TLS [RFC2716] support fragmentation and reassembly, EAP methods designed originally for use within PPP (where a 1500 octet MTU is guaranteed for control frames (see [RFC1661], Section 6.1) may lack fragmentation and reassembly features. EAP methods can assume a minimum EAP MTU of 1020 octets, in the absence of information provided by the lower layer. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU. EAP is a lock-step protocol, which implies a certain inefficiency when handling fragmentation and reassembly. Therefore if the lower layer supports fragmentation and reassembly (such as where EAP is transported over IP), it may be preferrable for fragmentation and reasembly to occur in the lower layer rather than in EAP. This can be accomplished by having the lower layer provide an artificially large EAP MTU to EAP, causing fragmentation and reassembly to be handled within the lower layer." After the first paragraph in Section 5.1, add: "Some EAP implementations piggy-back various options into the Identity Request after a NUL-character. An EAP implementation SHOULD NOT assume that an Identity Request or Response can be larger than 1020 octets in the absence of other information." Add to the 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 1020 octets. The length of the human readable message SHOULD therefore be at most 1015 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 eap-admin@frascone.com Wed Aug 6 03:44:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08707 for ; Wed, 6 Aug 2003 03:44:01 -0400 (EDT) Received: (qmail 27011 invoked from network); 6 Aug 2003 07:44:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 07:44:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 26989 invoked from network); 6 Aug 2003 07:43:23 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 07:43:23 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2C9AF6A901; Wed, 6 Aug 2003 10:43:21 +0300 (EEST) Message-ID: <3F30B0FC.8070603@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 162: Minimum MTU not defined References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Aug 2003 10:40:44 +0300 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > "[4] Minimum MTU. EAP is capable of functioning on lower > layers that provide an EAP MTU size of 1020 octets or greater. > > EAP does not support path MTU discovery, and fragmentation and > reassembly is not supported by EAP, nor by the methods > defined in this specification: the Identity (1), > Notification (2), Nak Response (3), MD5-Challenge (4), > One Time Password (5), Generic Token Card (6) > and expanded NAK Response (254) Types. > > Typically, the EAP peer obtains information on the EAP MTU from the > lower layers and sets the EAP frame size to an appropriate value. > Where the authenticator operates in pass-through mode, the > authentication server does not have a direct way of determining > the EAP MTU, and therefore relies on the authenticator to provide > it with this information, such as via the Framed-MTU attribute, > described in [RFC3579], Section 2.4. > > While methods such as EAP-TLS [RFC2716] support fragmentation > and reassembly, EAP methods designed originally for use within PPP > (where a 1500 octet MTU is guaranteed for control frames > (see [RFC1661], Section 6.1) may lack fragmentation and reassembly > features. > > EAP methods can assume a minimum EAP MTU of 1020 octets, in the > absence of information provided by the lower layer. EAP methods SHOULD > include support for fragmentation and reassembly if their payloads > can be larger than this minimum EAP MTU. > > EAP is a lock-step protocol, which implies a certain inefficiency > when handling fragmentation and reassembly. Therefore if the > lower layer supports fragmentation and reassembly > (such as where EAP is transported over IP), it may be > preferrable for fragmentation and reasembly to occur in the > lower layer rather than in EAP. This can be accomplished by > having the lower layer provide an artificially large EAP MTU to > EAP, causing fragmentation and reassembly to be handled within the > lower layer." Very good. > After the first paragraph in Section 5.1, add: > > "Some EAP implementations piggy-back various options into the Identity > Request after a NUL-character. An EAP implementation SHOULD NOT assume > that an Identity Request or Response can be larger than 1020 octets > in the absence of other information." How about a paragraph break between the two sentences? The above left me wondering whether you meant that we can go over 1020 octets if there are not options ("other information") after the NUL. > Add to the 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 1020 octets. The length > of the human readable message SHOULD therefore be at most 1015 octets." Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 14:05:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27377 for ; Wed, 6 Aug 2003 14:05:06 -0400 (EDT) Received: (qmail 8481 invoked from network); 6 Aug 2003 18:05:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 18:05:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 8449 invoked from network); 6 Aug 2003 18:04:16 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 18:04:16 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h76HZB510474 for ; Wed, 6 Aug 2003 10:35:11 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Potential resolution to Issue 165: Applicability Statement Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:35:11 -0700 (PDT) Here is a rewrite of the applicability statement to address some of the concerns discussed on the list: 1.4 Applicability EAP is an authentication framework primarily for use in situations such as network access, in which 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. As noted in Section 3.1, EAP does not support fragmentation and reassembly although EAP methods may provide this support. As a result, authentication protocols generating payloads larger than the EAP MTU will need to be modified in order to provide fragmentation 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. In particular, a large number of round-trips can result when certificate-based authentication protocols and long certificate chains are involved. Where transport efficiency is a consideration, and IP transport is available, it may be preferrable to expose an artificially high EAP MTU to EAP and allow fragmentation to take place in IP. Alternatively, it is possible to choose an alternative authentication framework such as SASL [RFC2222] or GSS-API [RFC2743]. [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 eap-admin@frascone.com Wed Aug 6 14:27:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28290 for ; Wed, 6 Aug 2003 14:27:03 -0400 (EDT) Received: (qmail 9282 invoked from network); 6 Aug 2003 18:27:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 18:27:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 9252 invoked from network); 6 Aug 2003 18:26:08 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 18:26:08 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h76Hv3I11612 for ; Wed, 6 Aug 2003 10:57:04 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed Resolution to Issue 165: Applicability Statement Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:57:03 -0700 (PDT) In going over the comments on this issue, it looks like I left out an issue or too. Here is a revised proposed resolution:\ "1.4 Applicability EAP is an authentication framework primarily for use in situations such as network access, in which 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. EAP is a lock-step protocol and does not support an efficient reliable transport service as in TCP [RFC793] or SCTP [RFC2960]. While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so that out of order reception is not supported. As noted in Section 3.1, EAP does not support fragmentation and reassembly as in IP, although EAP methods may provide support for this. As a result, authentication protocols generating payloads larger than the EAP MTU will need to be modified in order to provide fragmentation support. EAP authentication is initiated by the EAP server, whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an algorithm to add 0.5 - 1 additional roundtrip to run over EAP. As a result, an authentication algorithm will typically require more round-trips when run over EAP than when run over IP. In particular, certificate-based authentication algorithms using long certificate chains can result in many round-trips due to fragmentation. Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips may experience difficulties. In these situations, use of EAP methods with fewer round trips is advisable. Where transport efficiency is a consideration, and IP transport is available, it may be preferable to expose an artificially high EAP MTU to EAP and allow fragmentation to take place in IP. Alternatively, it is possible to choose an alternative authentication framework such as SASL [RFC2222] or GSS-API [RFC2743]. References (Informative) [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 eap-admin@frascone.com Wed Aug 6 14:36:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28786 for ; Wed, 6 Aug 2003 14:36:03 -0400 (EDT) Received: (qmail 9834 invoked from network); 6 Aug 2003 18:36:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 18:36:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 9805 invoked from network); 6 Aug 2003 18:35:29 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 18:35:29 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h76I6OF12192 for ; Wed, 6 Aug 2003 11:06:24 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Discussion of Issue 152: Request for Text Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Aug 2003 11:06:24 -0700 (PDT) There seems to be some level of agreement on the approach to Issue 152 (Lower Layer Indications), but as yet there is no proposed text for resolving the issue. So consider this a request for text. For further details on this and other EAP issues, checkout the EAP WG Issues list at: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 15:22:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01423 for ; Wed, 6 Aug 2003 15:22:05 -0400 (EDT) Received: (qmail 10983 invoked from network); 6 Aug 2003 19:22:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 19:22:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 10961 invoked from network); 6 Aug 2003 19:21:33 -0000 Received: from key1.docomolabs-usa.com (HELO fridge.docomolabs-usa.com) (fwuser@216.98.102.225) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 19:21:33 -0000 Subject: Re: [eap] Proposed Resolution to Issue 165: Applicability Statement From: Alper Yegin To: Bernard Aboba , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Aug 2003 12:23:23 -0700 Content-Transfer-Encoding: 7bit > EAP authentication is initiated by the EAP server, whereas > many authentication protocols are initiated by the client (peer). As a > result, it may be necessary for an algorithm to add 0.5 - 1 additional > roundtrip to run over EAP. When the identity request is sent from the authenticator, the additional 0.5 round-trip is not the one between peer-to-AS, but between peer-to-authenticator, which is considerably less. If we are going to highlight this latency as an issue, maybe we should capture this as well. > > As a result, an authentication algorithm will typically > require more round-trips when run over EAP than when run over IP. > In particular, certificate-based authentication > algorithms using long certificate chains can result in many > round-trips due to fragmentation. I think the first sentence is referring to aforementioned round-trip delay. The latter is another source of latency which needs a clarification, imo. So, I'd propose: As a result, an authentication algorithm will typically require more round-trips when run over EAP than when run over IP. Additionally, certificate-based authentication algorithms using long certificate chains can result in many round-trips when the fragmentation is handled by the EAP method. Also, it is not very clear what "running auth algorithm over IP" means. Maybe mentioning an example helps. This should not be mixed with running EAP over IP. Alper > > Where EAP runs over a lower layer in which significant packet loss > is experienced, or where the connection between > the authenticator and authentication server experiences significant > packet loss, EAP methods requiring many round-trips may > experience difficulties. In these situations, use of EAP > methods with fewer round trips is advisable. > > Where transport efficiency is a consideration, and IP > transport is available, it may be preferable to expose an > artificially high EAP MTU to EAP and allow fragmentation to take > place in IP. Alternatively, it is possible to choose an > alternative authentication framework such as SASL [RFC2222] or > GSS-API [RFC2743]. > > References (Informative) > > [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 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 15:31:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01688 for ; Wed, 6 Aug 2003 15:31:05 -0400 (EDT) Received: (qmail 11482 invoked from network); 6 Aug 2003 19:31:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 19:31:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 11459 invoked from network); 6 Aug 2003 19:30:45 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 19:30:45 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h76J1Rd15301; Wed, 6 Aug 2003 12:01:27 -0700 From: Bernard Aboba To: Alper Yegin cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 165: Applicability Statement In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Aug 2003 12:01:26 -0700 (PDT) > > EAP authentication is initiated by the EAP server, whereas > > many authentication protocols are initiated by the client (peer). As a > > result, it may be necessary for an algorithm to add 0.5 - 1 additional > > roundtrip to run over EAP. > > When the identity request is sent from the authenticator, the additional > 0.5 round-trip is not the one between peer-to-AS, but between > peer-to-authenticator, which is considerably less. If we are going to > highlight this latency as an issue, maybe we should capture this as well. > > > > > As a result, an authentication algorithm will typically > > require more round-trips when run over EAP than when run over IP. > > In particular, certificate-based authentication > > algorithms using long certificate chains can result in many > > round-trips due to fragmentation. > > I think the first sentence is referring to aforementioned round-trip delay. > The latter is another source of latency which needs a clarification, imo. > So, I'd propose: > > As a result, an authentication algorithm will typically > require more round-trips when run over EAP than when run over IP. > Additionally, certificate-based authentication > algorithms using long certificate chains can result in many > round-trips when the fragmentation is handled by the EAP method. > > Also, it is not very clear what "running auth algorithm over IP" means. > Maybe mentioning an example helps. This should not be mixed with running EAP > over IP. OK. How about this? 1.4 Applicability EAP is an authentication framework primarily for use in situations such as network access, in which 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. EAP is a lock-step protocol and does not support an efficient reliable transport service as in TCP [RFC793] or SCTP [RFC2960]. While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so that out of order reception is not supported. As noted in Section 3.1, EAP does not support fragmentation and reassembly as in IP, although EAP methods may provide support for this. As a result, authentication protocols generating payloads larger than the EAP MTU will need to be modified in order to provide fragmentation support. EAP authentication is initiated by the authenticator, whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an algorithm to add 0.5 - 1 additional roundtrips between the client and authenticator in order to run over EAP. As a result, an authentication algorithm will typically require more round-trips when run over EAP than when run directly over IP. Additionally, certificate-based authentication algorithms using long certificate chains can result in many round-trips due to fragmentation. Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips may experience difficulties. In these situations, use of EAP methods with fewer round trips is advisable. Where transport efficiency is a consideration, and IP transport is available, it may be preferable to expose an artificially high EAP MTU to EAP and allow fragmentation to take place in IP. Alternatively, it is possible to choose an alternative authentication framework such as SASL [RFC2222] or GSS-API [RFC2743]. References (Informative) [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 eap-admin@frascone.com Wed Aug 6 15:59:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02493 for ; Wed, 6 Aug 2003 15:59:01 -0400 (EDT) Received: (qmail 12294 invoked from network); 6 Aug 2003 19:59:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 19:59:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 12270 invoked from network); 6 Aug 2003 19:58:56 -0000 Received: from key1.docomolabs-usa.com (HELO fridge.docomolabs-usa.com) (fwuser@216.98.102.225) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 19:58:56 -0000 Subject: Re: [eap] Proposed Resolution to Issue 165: Applicability Statement From: Alper Yegin To: Bernard Aboba CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Aug 2003 13:00:44 -0700 Content-Transfer-Encoding: 7bit > EAP authentication is initiated by the authenticator, whereas > many authentication protocols are initiated by the client (peer). As a > result, it may be necessary for an algorithm to add 0.5 - 1 additional > roundtrips between the client and authenticator in order to run over EAP. OK. > As a result, an authentication algorithm will typically > require more round-trips when run over EAP than when run directly over IP. > Additionally, certificate-based authentication > algorithms using long certificate chains can result in many > round-trips due to fragmentation. I still think we need to be more clear here (like in my suggested text). Are you referring to the amplified effects of fragmentation when coupled with the lock-step nature of EAP? That's the only case where we can talk about many additional round-trips. If the fragmentation is done by the EAP lower layer, then there is no additional round-trip issue (just additional in-flight packet issue). Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 17:01:17 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04734 for ; Wed, 6 Aug 2003 17:01:07 -0400 (EDT) Received: (qmail 13720 invoked from network); 6 Aug 2003 21:01:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 21:01:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 13696 invoked from network); 6 Aug 2003 21:00:12 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 21:00:12 -0000 Received: from [10.0.1.3] (pm479-31.dialip.mich.net [207.75.180.41]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h76L04q29863; Wed, 6 Aug 2003 17:00:05 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 162: Minimum MTU not defined Message-ID: <3683711.1060189256@[10.0.1.3]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Aug 2003 17:00:56 -0400 Content-Transfer-Encoding: 7bit nice -- this seems good to me. -- John --On Tuesday, August 5, 2003 11:52 PM -0700 Bernard Aboba wrote: > The text of Issue 162 is enclosed below. The proposed fix is as follows: > > In section 3.1, Change: > > "[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: > > "[4] Minimum MTU. EAP is capable of functioning on lower > layers that provide an EAP MTU size of 1020 octets or greater. > > EAP does not support path MTU discovery, and fragmentation and > reassembly is not supported by EAP, nor by the methods > defined in this specification: the Identity (1), > Notification (2), Nak Response (3), MD5-Challenge (4), > One Time Password (5), Generic Token Card (6) > and expanded NAK Response (254) Types. > > Typically, the EAP peer obtains information on the EAP MTU from the > lower layers and sets the EAP frame size to an appropriate value. > Where the authenticator operates in pass-through mode, the > authentication server does not have a direct way of determining > the EAP MTU, and therefore relies on the authenticator to provide > it with this information, such as via the Framed-MTU attribute, > described in [RFC3579], Section 2.4. > > While methods such as EAP-TLS [RFC2716] support fragmentation > and reassembly, EAP methods designed originally for use within PPP > (where a 1500 octet MTU is guaranteed for control frames > (see [RFC1661], Section 6.1) may lack fragmentation and reassembly > features. > > EAP methods can assume a minimum EAP MTU of 1020 octets, in the > absence of information provided by the lower layer. EAP methods SHOULD > include support for fragmentation and reassembly if their payloads > can be larger than this minimum EAP MTU. > > EAP is a lock-step protocol, which implies a certain inefficiency > when handling fragmentation and reassembly. Therefore if the > lower layer supports fragmentation and reassembly > (such as where EAP is transported over IP), it may be > preferrable for fragmentation and reasembly to occur in the > lower layer rather than in EAP. This can be accomplished by > having the lower layer provide an artificially large EAP MTU to > EAP, causing fragmentation and reassembly to be handled within the > lower layer." > > After the first paragraph in Section 5.1, add: > > "Some EAP implementations piggy-back various options into the Identity > Request after a NUL-character. An EAP implementation SHOULD NOT assume > that an Identity Request or Response can be larger than 1020 octets > in the absence of other information." > > Add to the 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 1020 octets. The length > of the human readable message SHOULD therefore be at most 1015 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 6 18:42:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08962 for ; Wed, 6 Aug 2003 18:42:01 -0400 (EDT) Received: (qmail 15887 invoked from network); 6 Aug 2003 22:42:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 6 Aug 2003 22:42:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 12104 invoked from network); 6 Aug 2003 19:48:43 -0000 Received: from hoemail1.lucent.com (HELO hoemail1.firewall.lucent.com) (192.11.226.161) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 6 Aug 2003 19:48:43 -0000 Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76JmaE17330 for ; Wed, 6 Aug 2003 14:48:36 -0500 (CDT) Received: by nwmail.wh.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id h76JmYa05924; Wed, 6 Aug 2003 15:48:34 -0400 (EDT) Received: from lucent.com by nwmail.wh.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id h76JmWI05912; Wed, 6 Aug 2003 15:48:32 -0400 (EDT) Message-ID: <3F315B7F.1040402@lucent.com> From: Uri Blumenthal Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: eap@frascone.com Subject: [eap] MSK lifetime? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Aug 2003 15:48:15 -0400 Content-Transfer-Encoding: 7bit Folks (Bernard especially), What's the expected life-time for MSK in the EAP key hierarchy? Is it supposed to be discarded immediately after TSK's have been derived? Is it supposed to be kept for the length of the current EAP session (if so - for what purpose? Rekeying on TSK level?)? And is session rekeying going to be considered/discussed? Thanks! Regards, Uri. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 06:17:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06500 for ; Thu, 7 Aug 2003 06:17:04 -0400 (EDT) Received: (qmail 28028 invoked from network); 7 Aug 2003 10:17:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 10:17:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 27993 invoked from network); 7 Aug 2003 10:16:51 -0000 Received: from n197.nomadiclab.com (HELO localhost.localdomain) (131.160.193.197) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 10:16:51 -0000 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h77ADmLQ003803; Thu, 7 Aug 2003 13:13:48 +0300 Message-ID: <3F32265C.4030605@piuha.net> From: Jari Arkko Reply-To: jarkko@piuha.net, jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: eap@frascone.com Subject: Re: [eap] Potential resolution to Issue 165: Applicability Statement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Aug 2003 13:13:48 +0300 Content-Transfer-Encoding: 7bit Looks good. Thanks! --Jari Bernard Aboba wrote: > Here is a rewrite of the applicability statement to address some of the > concerns discussed on the list: > > 1.4 Applicability > > EAP is an authentication framework primarily for use in situations > such as network access, in which 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. > > As noted in Section 3.1, EAP does not support fragmentation > and reassembly although EAP methods may provide this support. > As a result, authentication protocols generating payloads larger > than the EAP MTU will need to be modified in order to provide > fragmentation 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. In particular, a large > number of round-trips can result when certificate-based authentication > protocols and long certificate chains are involved. > > Where transport efficiency is a consideration, and IP > transport is available, it may be preferrable to expose an > artificially high EAP MTU to EAP and allow fragmentation to take > place in IP. Alternatively, it is possible to choose an > alternative authentication framework such as SASL [RFC2222] or > GSS-API [RFC2743]. > > [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 > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 06:20:30 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06576 for ; Thu, 7 Aug 2003 06:20:27 -0400 (EDT) Received: (qmail 28251 invoked from network); 7 Aug 2003 10:18:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 10:18:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 28070 invoked from network); 7 Aug 2003 10:17:03 -0000 Received: from n197.nomadiclab.com (HELO localhost.localdomain) (131.160.193.197) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 10:17:03 -0000 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h77AE0LQ003806; Thu, 7 Aug 2003 13:14:01 +0300 Message-ID: <3F322668.7010603@piuha.net> From: Jari Arkko Reply-To: jarkko@piuha.net, jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 165: Applicability Statement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Aug 2003 13:14:00 +0300 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In going over the comments on this issue, it looks like I left out an > issue or too. Hmm... me too. A small comment inline: > "1.4 Applicability > > EAP is an authentication framework primarily for use in situations > such as network access, in which 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. > EAP is a lock-step protocol and does not support an efficient > reliable transport service as in TCP [RFC793] or SCTP [RFC2960]. > While EAP provides support for retransmission, it assumes ordering > guarantees provided by the lower layer, so that out of order reception > is not supported. > > As noted in Section 3.1, EAP does not support fragmentation > and reassembly as in IP, although EAP methods may provide support > for this. As a result, authentication protocols generating payloads > larger than the EAP MTU will need to be modified in order to provide > fragmentation support. > > EAP authentication is initiated by the EAP server, whereas > many authentication protocols are initiated by the client (peer). As a > result, it may be necessary for an algorithm to add 0.5 - 1 additional > roundtrip to run over EAP. > > As a result, an authentication algorithm will typically > require more round-trips when run over EAP than when run over IP. > In particular, certificate-based authentication > algorithms using long certificate chains can result in many > round-trips due to fragmentation. > > Where EAP runs over a lower layer in which significant packet loss > is experienced, or where the connection between > the authenticator and authentication server experiences significant > packet loss, EAP methods requiring many round-trips may > experience difficulties. In these situations, use of EAP > methods with fewer round trips is advisable. > > Where transport efficiency is a consideration, and IP > transport is available, it may be preferable to expose an > artificially high EAP MTU to EAP and allow fragmentation to take > place in IP. Alternatively, it is possible to choose an > alternative authentication framework such as SASL [RFC2222] or "... to choose other security mechanisms such as TLS [ref] or IKE [ref] or an alternate authentication framework such as SASL ..." > GSS-API [RFC2743]. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 09:01:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10819 for ; Thu, 7 Aug 2003 09:01:04 -0400 (EDT) Received: (qmail 32295 invoked from network); 7 Aug 2003 13:01:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 13:01:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 25814 invoked from network); 7 Aug 2003 08:18:34 -0000 Received: from n197.nomadiclab.com (HELO localhost.localdomain) (131.160.193.197) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 08:18:34 -0000 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h778FULQ003145; Thu, 7 Aug 2003 11:15:30 +0300 Message-ID: <3F320AA2.4080007@piuha.net> From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: eap@frascone.com Subject: Re: [eap] Potential resolution to Issue 165: Applicability Statement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Aug 2003 11:15:30 +0300 Content-Transfer-Encoding: 7bit Looks good. Thanks! --Jari Bernard Aboba wrote: > Here is a rewrite of the applicability statement to address some of the > concerns discussed on the list: > > 1.4 Applicability > > EAP is an authentication framework primarily for use in situations > such as network access, in which 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. > > As noted in Section 3.1, EAP does not support fragmentation > and reassembly although EAP methods may provide this support. > As a result, authentication protocols generating payloads larger > than the EAP MTU will need to be modified in order to provide > fragmentation 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. In particular, a large > number of round-trips can result when certificate-based authentication > protocols and long certificate chains are involved. > > Where transport efficiency is a consideration, and IP > transport is available, it may be preferrable to expose an > artificially high EAP MTU to EAP and allow fragmentation to take > place in IP. Alternatively, it is possible to choose an > alternative authentication framework such as SASL [RFC2222] or > GSS-API [RFC2743]. > > [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 > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 09:02:45 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10915 for ; Thu, 7 Aug 2003 09:02:42 -0400 (EDT) Received: (qmail 32347 invoked from network); 7 Aug 2003 13:01:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 13:01:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 27651 invoked from network); 7 Aug 2003 10:06:12 -0000 Received: from n197.nomadiclab.com (HELO localhost.localdomain) (131.160.193.197) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 10:06:12 -0000 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h77A39LQ003779; Thu, 7 Aug 2003 13:03:10 +0300 Message-ID: <3F3223DD.5010709@piuha.net> From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 165: Applicability Statement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Aug 2003 13:03:09 +0300 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In going over the comments on this issue, it looks like I left out an > issue or too. Hmm... me too. A small comment inline: > "1.4 Applicability > > EAP is an authentication framework primarily for use in situations > such as network access, in which 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. > EAP is a lock-step protocol and does not support an efficient > reliable transport service as in TCP [RFC793] or SCTP [RFC2960]. > While EAP provides support for retransmission, it assumes ordering > guarantees provided by the lower layer, so that out of order reception > is not supported. > > As noted in Section 3.1, EAP does not support fragmentation > and reassembly as in IP, although EAP methods may provide support > for this. As a result, authentication protocols generating payloads > larger than the EAP MTU will need to be modified in order to provide > fragmentation support. > > EAP authentication is initiated by the EAP server, whereas > many authentication protocols are initiated by the client (peer). As a > result, it may be necessary for an algorithm to add 0.5 - 1 additional > roundtrip to run over EAP. > > As a result, an authentication algorithm will typically > require more round-trips when run over EAP than when run over IP. > In particular, certificate-based authentication > algorithms using long certificate chains can result in many > round-trips due to fragmentation. > > Where EAP runs over a lower layer in which significant packet loss > is experienced, or where the connection between > the authenticator and authentication server experiences significant > packet loss, EAP methods requiring many round-trips may > experience difficulties. In these situations, use of EAP > methods with fewer round trips is advisable. > > Where transport efficiency is a consideration, and IP > transport is available, it may be preferable to expose an > artificially high EAP MTU to EAP and allow fragmentation to take > place in IP. Alternatively, it is possible to choose an > alternative authentication framework such as SASL [RFC2222] or "... to choose other security mechanisms such as TLS [ref] or IKE [ref] or an alternate authentication framework such as SASL ..." > GSS-API [RFC2743]. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 11:17:13 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18400 for ; Thu, 7 Aug 2003 11:17:06 -0400 (EDT) Received: (qmail 3861 invoked from network); 7 Aug 2003 15:17:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 15:17:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 3840 invoked from network); 7 Aug 2003 15:16:43 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 15:16:43 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h77ElXr18476 for ; Thu, 7 Aug 2003 07:47:33 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: MSK lifetime Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Aug 2003 07:47:33 -0700 (PDT) Thanks for your question, Uri. I've been working on adding a section to the Key Framework draft to address the issue of SA lifetimes, and relationship between SAs. I'll post a pointer to this by the end of the week, and your review would be most appreciated. Much of what is going into that section comes from equivalent material in IEEE 802.11i D5. However, I'm not clear about all the implications of what is written there or whether it really makes sense. IEEE 802.11i D5 implies that the maximum lifetime of the AAA-Key SA (which includes the AAA-Key) is determined by the Session-Timeout attribute sent by AAA. Session-Timeout with no Termination-Action implies that the session must die after the time expires. With Termination-Action, a re-authentication is to occur at that time. However, the AAA-Key SA does not relate directly to the EAP SA (which includes the MSK and EMSK derived by the EAP peer and server). So just because the AAA server sent a particular Session-Timeout attribute does not necessarily imply that it deletes the MSK and EMSK after that point, and all child SAs derived from them. Rather, it probably has its own internal key cache by which it manages MSK and EMSK expiration, the structure of which is not described in IEEE 802.11i D5 (this probably belongs in a AAA specification). For example, in fast handoff, the AAA Server may have derived keys for other APs via the EMSK. Are those keys also sent with a Session-Timeout attribute so as to cause expiration of all keying material derived from the EAP SA at the same time? I doubt it. And of course, the peer is not aware of the Session-Timeout value so that it also will not delete the MSK and EMSK at that point. Therefore I think it is more likely that the MSK and EMSK have lifetimes only known to the AAA server, but that the TSKs have lifetimes that should be negotiated explicitly within the secure association exchanges (unicast and multicast). In terms of relationships between the different SAs (EAP SA, AAA-Key SA, unicast secure association SA, multicast secure association SA), I'm still working through the implications of IEEE 802.11iD5. For example, on failure of the unicast secure association exchange, I believe that IEEE 802.11iD5 requires that the AAA-Key SA be deleted on the authenticator and peer. This SA is "named" by something called the PMKID -- which is a hash of the PMK itself and the AP and STA MAC addresses. So this implies that death (or lack of creation) of a child SA can result in deletion of the parent SA. The multicast secure association SA can be the child of the unicast secure association SA or not (depending on what exchange is used to create it) but I'm not sure that "death of the child implies death of the parent" is true in that case as well. Message: 8 Date: Wed, 06 Aug 2003 15:48:15 -0400 From: Uri Blumenthal Organization: Lucent Technologies To: eap@frascone.com Subject: [eap] MSK lifetime? Folks (Bernard especially), What's the expected life-time for MSK in the EAP key hierarchy? Is it supposed to be discarded immediately after TSK's have been derived? Is it supposed to be kept for the length of the current EAP session (if so - for what purpose? Rekeying on TSK level?)? And is session rekeying going to be considered/discussed? Thanks! Regards, Uri. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 13:25:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22971 for ; Thu, 7 Aug 2003 13:25:01 -0400 (EDT) Received: (qmail 7293 invoked from network); 7 Aug 2003 17:25:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 17:25:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7265 invoked from network); 7 Aug 2003 17:24:46 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 17:24:46 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h77GtZl25634 for ; Thu, 7 Aug 2003 09:55:36 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] IEEE 802.11i D5 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Aug 2003 09:55:35 -0700 (PDT) The question has arisen as to how EAP WG members can get access to IEEE 802.11i D5, which contains new material relevant to the EAP Key Framework Draft. Under the IEEE 802.1aa/EAP WG liason agreement, EAP WG participants have access to the IEEE 802.1 archive: Username: p8021 password: go_wildcats Under the IEEE 802.1/IEEE 802.11 liason agreement IEEE 802.1 authorized users (which includes EAP WG participants) have access to the IEEE 802.11 archive. IEEE 802.11i D5 is available for inspection below: http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D5.0.doc The IEEE 802.1aa archive is available at: http://www.ieee802.org/1/pages/802.1aa.html Note that IEEE 802.11i D5 is in recirculation ballot ending August 19, 2003 at 11:59 EDT. In a recirculation ballot only voters on the previous ballot are eligible to vote. However, if you have concerns relating to EAP WG issues, please post these to the list. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 7 14:59:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27072 for ; Thu, 7 Aug 2003 14:59:04 -0400 (EDT) Received: (qmail 11094 invoked from network); 7 Aug 2003 18:59:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 7 Aug 2003 18:59:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 11032 invoked from network); 7 Aug 2003 18:58:19 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 7 Aug 2003 18:58:19 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h77IT8t31027 for ; Thu, 7 Aug 2003 11:29:09 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Announcing: draft-moskowitz-eap-auth-model-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Aug 2003 11:29:08 -0700 (PDT) To: IETF-Announce: ; Subject: I-D ACTION:draft-moskowitz-eap-auth-model-00.txt From: Internet-Drafts@ietf.org Date: Thu, 07 Aug 2003 07:52:50 -0400 Reply-to: Internet-Drafts@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Authentication Functional Layering Model Author(s) : R. Moskowitz Filename : draft-moskowitz-eap-auth-model-00.txt Pages : 11 Date : 2003-8-6 There is considerable confusion surrounding authentication styles and the nature of the resulting trust. This paper is an attempt to develop categories of authentication methods and present examples of each. In so doing, it develops an Authentication Functional Layering Model. It will look at the components of authentication, the flows, channels, algorithms, and entities. The taxonomy presented here is new; it has been created to facilitate discussion and understanding. Only two-party authentications are presented here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-moskowitz-eap-auth-model-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-moskowitz-eap-auth-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-moskowitz-eap-auth-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 8 12:31:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16872 for ; Fri, 8 Aug 2003 12:31:01 -0400 (EDT) Received: (qmail 4373 invoked from network); 8 Aug 2003 16:31:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 8 Aug 2003 16:31:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 4351 invoked from network); 8 Aug 2003 16:30:58 -0000 Received: from homebase.htt-consult.com (HELO htt-consult.com) (65.84.78.210) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 8 Aug 2003 16:30:58 -0000 Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Fri, 08 Aug 2003 12:32:15 -0400 Message-Id: <5.1.0.14.2.20030808122636.02bf8be0@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Bernard Aboba , eap@frascone.com From: Robert Moskowitz Subject: Re: [eap] Announcing: draft-moskowitz-eap-auth-model-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 08 Aug 2003 12:30:17 -0400 At 11:29 AM 8/7/2003 -0700, Bernard Aboba wrote: >To: IETF-Announce: ; >Subject: I-D ACTION:draft-moskowitz-eap-auth-model-00.txt >From: Internet-Drafts@ietf.org >Date: Thu, 07 Aug 2003 07:52:50 -0400 >Reply-to: Internet-Drafts@ietf.org >Sender: owner-ietf-announce@ietf.org Thank you, Bernard in beating me to posting this ID here. Please, I welcome comments on content. I know it can use some editorial clean up, and in the end lots of references. There are multiple driving forces for this paper. Perhaps a very important one will be for the next update to 802.1x via the new LinkSec taskgroup in 802.1. I also hope that it will result in discussion about how EAP works over the 'rgiht' flows, and about authentication algorithms that we need and do not have. Bernard has me on the hook for a paper on Security Associations, so the part in this ID on SAs, may get move into a larger context. Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 8 20:28:03 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01814 for ; Fri, 8 Aug 2003 20:28:01 -0400 (EDT) Received: (qmail 12857 invoked from network); 9 Aug 2003 00:28:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 9 Aug 2003 00:28:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 12820 invoked from network); 9 Aug 2003 00:27:36 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 9 Aug 2003 00:27:36 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h78NwH501556 for ; Fri, 8 Aug 2003 16:58:18 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] New RADIUS-related mailing list created Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 8 Aug 2003 16:58:17 -0700 (PDT) A new mailing list has been created to discuss potential future IETF RADIUS-related work. To subscribe the list, send mail to majordomo@psg.com, with "subscribe radiusext" in the body of the message. To send mail to the list, address it to radiusext@ops.ietf.org. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 9 21:57:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12921 for ; Sat, 9 Aug 2003 21:57:06 -0400 (EDT) Received: (qmail 2364 invoked from network); 10 Aug 2003 01:57:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 10 Aug 2003 01:57:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 2345 invoked from network); 10 Aug 2003 01:56:43 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 10 Aug 2003 01:56:43 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7A1RJa23424 for ; Sat, 9 Aug 2003 18:27:19 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed resolution to Issue 152: Link layer indications Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 9 Aug 2003 18:27:19 -0700 (PDT) The text of Issue 152 is enclosed below. The proposed resolution is: In Section 3.4, change: "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." To: "Section 4.2 defines the circumstances in which a peer 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.12, it MAY conclude that a Success packet has been lost without waiting for a timeout." ------------------------------------------------------------------- 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? [BA] 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Aug 10 16:20:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15331 for ; Sun, 10 Aug 2003 16:20:09 -0400 (EDT) Received: (qmail 17854 invoked from network); 10 Aug 2003 20:20:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 10 Aug 2003 20:20:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 17817 invoked from network); 10 Aug 2003 20:19:47 -0000 Received: from pcls2.std.com (HELO TheWorld.com) (199.172.62.104) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 10 Aug 2003 20:19:47 -0000 Received: from david_jablon.theworld.com (pool-141-154-53-97.bos.east.verizon.net [141.154.53.97]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h7AKJgJj004162; Sun, 10 Aug 2003 16:19:44 -0400 Message-Id: <5.1.0.14.0.20030810160801.00a320e0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Robert Moskowitz From: David Jablon Subject: Re: [eap] Announcing: draft-moskowitz-eap-auth-model-00.txt Cc: eap@frascone.com, Bernard Aboba , Eric Rescorla In-Reply-To: <5.1.0.14.2.20030808122636.02bf8be0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Aug 2003 16:17:39 -0400 Bob, The tiny section of draft-moskowitz-eap-auth-model-00.txt that mentions passwords could be interpreted (perversely) to imply that they should be treated as similar to MAC addresses. You may also want to coordinate with Eric Rescorla's draft, of which I've just become aware, in which he too attempts to categorize authentication technologies. I have separate concerns about each of these drafts, and I think it makes sense to discuss them in a common appropriate forum. I'm not sure what that forum is, but without such a forum, I think both will suffer from a lack of appropriate attention. -- David At 12:30 PM 8/8/03 -0400, Robert Moskowitz wrote: >At 11:29 AM 8/7/2003 -0700, Bernard Aboba wrote: > >>To: IETF-Announce: ; >>Subject: I-D ACTION:draft-moskowitz-eap-auth-model-00.txt >>From: Internet-Drafts@ietf.org >>Date: Thu, 07 Aug 2003 07:52:50 -0400 >>Reply-to: Internet-Drafts@ietf.org >>Sender: owner-ietf-announce@ietf.org > >Thank you, Bernard in beating me to posting this ID here. > >Please, I welcome comments on content. > >I know it can use some editorial clean up, and in the end lots of references. > >There are multiple driving forces for this paper. Perhaps a very important one will be for the next update to 802.1x via the new LinkSec taskgroup in 802.1. > >I also hope that it will result in discussion about how EAP works over the 'rgiht' flows, and about authentication algorithms that we need and do not have. > >Bernard has me on the hook for a paper on Security Associations, so the part in this ID on SAs, may get move into a larger context. > > > >Robert Moskowitz >ICSAlabs/A Division of TruSecure Corporation >Security Interest EMail: rgm-sec@htt-consult.com > >_______________________________________________ >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 eap-admin@frascone.com Mon Aug 11 02:48:02 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08363 for ; Mon, 11 Aug 2003 02:48:00 -0400 (EDT) Received: (qmail 26492 invoked from network); 11 Aug 2003 06:48:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 11 Aug 2003 06:48:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 26473 invoked from network); 11 Aug 2003 06:47:40 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 11 Aug 2003 06:47:40 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7B6I9O26349 for ; Sun, 10 Aug 2003 23:18:09 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Slides from EAP WG meetings at IETF 57 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Aug 2003 23:18:08 -0700 (PDT) The slides from the EAP WG meetings at IETF57 are available here: http://www.drizzle.com/~aboba/IETF57/EAP/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 11 08:28:06 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13997 for ; Mon, 11 Aug 2003 08:28:03 -0400 (EDT) Received: (qmail 31640 invoked from network); 11 Aug 2003 12:28:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 11 Aug 2003 12:28:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 31609 invoked from network); 11 Aug 2003 12:27:18 -0000 Received: from homebase.htt-consult.com (HELO htt-consult.com) (65.84.78.210) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 11 Aug 2003 12:27:18 -0000 Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Mon, 11 Aug 2003 08:26:37 -0400 Message-Id: <5.1.0.14.2.20030811082048.02d37778@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: David Jablon From: Robert Moskowitz Subject: Re: [eap] Announcing: draft-moskowitz-eap-auth-model-00.txt Cc: eap@frascone.com, Bernard Aboba , Eric Rescorla In-Reply-To: <5.1.0.14.0.20030810160801.00a320e0@pop.theworld.com> References: <5.1.0.14.2.20030808122636.02bf8be0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:24:26 -0400 At 04:17 PM 8/10/2003 -0400, David Jablon wrote: >The tiny section of draft-moskowitz-eap-auth-model-00.txt that mentions >passwords could be interpreted (perversely) to imply that they should >be treated as similar to MAC addresses. I have been thinking of your comment while I was driving up into the Catskills for visiting day to the farm my son is working on. You are right about the unintended impression and I will address that. >You may also want to coordinate with Eric Rescorla's draft, of which I've >just become aware, in which he too attempts to categorize authentication >technologies. I have also learned about Eric's ID and have submitted comments to him and the IAB. His draft is doing something much different than mine, though. >I have separate concerns about each of these drafts, and I think it makes >sense >to discuss them in a common appropriate forum. I'm not sure what that >forum is, >but without such a forum, I think both will suffer from a lack of >appropriate attention. Understand. And there is more here that I feel needs to be written (and Bernard got me to commit to one on Security Associations at the 802 plenary...). Don't have an answer. Perhaps someone should ask Bellovin or Housley. Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 11 11:08:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19754 for ; Mon, 11 Aug 2003 11:08:03 -0400 (EDT) Received: (qmail 2253 invoked from network); 11 Aug 2003 15:08:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 11 Aug 2003 15:08:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 2205 invoked from network); 11 Aug 2003 15:07:14 -0000 Received: from fmr05.intel.com (HELO hermes.jf.intel.com) (134.134.136.6) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 11 Aug 2003 15:07:14 -0000 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7BF4e223298 for ; Mon, 11 Aug 2003 15:04:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7BF1iH21388 for ; Mon, 11 Aug 2003 15:01:44 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081108064505970 for ; Mon, 11 Aug 2003 08:06:45 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 11 Aug 2003 08:06:41 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [eap] Proposed resolution to Issue 152: Link layer indications Thread-Index: AcNe4ufbjspSVeqeTuq89QBvyol6UwBNk9nQ From: "Lortz, Victor" To: X-OriginalArrivalTime: 11 Aug 2003 15:06:41.0525 (UTC) FILETIME=[2BB5B250:01C3601A] Subject: [eap] Adding supplementary data to Identity-Response? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:06:41 -0700 Content-Transfer-Encoding: quoted-printable Section 5.1 of 2284bis describes the EAP Identity messages (Request and = Response). The latest draft says that the text of the Request message = prior to a NULL character is intended to be displayed to the user. Any = information after the NULL character is extra data whose format is still = TBD. Some existing networks use the following syntax: \0networkid=3D,nasid=3D,portid=3D= What do people think about extending this idea to include extra data in = Identity-Response messages as well? One possible use would be to allow = the peer to indicate its preferred authentication method. Another use = would be to communicate characteristics of the network services desired = by the peer. For example, the peer may require a certain bit rate or a = certain quality of service (or the ability to request quality of = service). =20 One could think of this additional data (in both the Identity Request = and Response) as supplementary information (i.e., hints) that can be = used to determine whether it will be worthwhile to continue attempting = the connection. Piggy-backing this data on the Identity messages has = the important advantages of reducing round trips and of making this data = available as soon as possible in the authentication process. =20 Additional considerations: =20 If the Identity-Response contains extra data after a NULL, the = processing of the Identity Type-Data field might need to be changed in = some implementations. For example, when the NAI is copied from the = Type-Data field into the RADIUS Username attribute, the implementation = must avoid copying the data after the NULL. Furthermore, = implementations of EAP servers would need to be modified to enable = processing of this new data. =20 Regards, Vic _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 11 11:29:47 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20287 for ; Mon, 11 Aug 2003 11:29:34 -0400 (EDT) Received: (qmail 2981 invoked from network); 11 Aug 2003 15:29:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 11 Aug 2003 15:29:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 2915 invoked from network); 11 Aug 2003 15:28:03 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 11 Aug 2003 15:28:03 -0000 Received: from [10.0.1.2] (pm473-22.dialip.mich.net [207.75.178.224]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7BFR6q20632; Mon, 11 Aug 2003 11:27:07 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 152: Link layer indications Message-ID: <3045319.1060601281@[10.0.1.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Aug 2003 11:28:02 -0400 Content-Transfer-Encoding: 7bit sounds good to me. -- John --On Saturday, August 9, 2003 6:27 PM -0700 Bernard Aboba wrote: > The text of Issue 152 is enclosed below. The proposed resolution is: > > In Section 3.4, change: > > "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." > > To: > > "Section 4.2 defines the circumstances in which a peer > 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.12, it MAY conclude that a > Success packet has been lost without waiting for a > timeout." > > ------------------------------------------------------------------- > 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? > > [BA] 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. > > _______________________________________________ > 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 eap-admin@frascone.com Mon Aug 11 12:19:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21662 for ; Mon, 11 Aug 2003 12:19:03 -0400 (EDT) Received: (qmail 4300 invoked from network); 11 Aug 2003 16:19:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 11 Aug 2003 16:19:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 3815 invoked from network); 11 Aug 2003 15:53:20 -0000 Received: from burch-1-server.kbnet.co.uk (HELO MAIL.PingToo.com) (194.125.228.106) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 11 Aug 2003 15:53:20 -0000 Received: from Pinot.PingToo.com by MAIL.PingToo.com (IBM OS/2 SENDMAIL VERSION 2.03/2.19) id QAA075.62; Mon, 11 Aug 2003 16:54:07 +0100 Message-Id: <200308111554.QAA075.62@MAIL.PingToo.com> From: "Brian Burch" To: "EAP Mailing List" Reply-To: "Brian Burch" Priority: Normal X-Mailer: PMMail 2.10.2010 for OS/2 Warp 4.05 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [eap] draft-aboba-radius-rfc2869bis-22 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Aug 2003 16:53:45 +0100 (BST) Content-Transfer-Encoding: 7bit Description of issue: EAP Message Authenticator String description needs clarification Submitter name: Brian Burch Submitter email address: Brian@PingToo.com Date first submitted: 11 August 2003 Reference: Document: RFC 2869bis Comment type: Technical Priority: 1 Section: 3.2. Message-Authenticator - String Rationale/Explanation of issue: I realise this section has NOT changed significantly between the published RFC and the draft. However, I'm currently working in this area and I cannot derive an unambiguous interpretation of the section from rfc2689bis-22. Length description of problem: There's a semi-recursive problem with this attribute. The EAP Message Authenticator is supposed to digitally sign an entire Radius/EAP packet, but so is the Radius Authenticator. Given that Radius is being used as a "transport mechanism" for EAP, it follows that the Radius Authenticator MUST be the last field computed. In other words, the EAP Message Authenticator MUST be computed over the Radius packet BEFORE the Radius Authenticator is known. Therefore, the EAP Message Authenticator must be computed over an all-zero's Radius Authenticator. This could be stated more clearly. Now, we have the same question about the EAP Message Authenticator itself. Do we compute over an all-zero's EAP Message Authenticator, or do we compute over just the Radius Packet BEFORE the Message Authenticator is added? I don't know and I can't tell from the RFC. My guess is the process is as follows: 1. Put the EAP Message attribute into the Radius Packet. 2. Put an all-zero's EAP Message Authenticator into the Radius Packet. 3. Compute the HMAC-MD5 digest for the entire Radius packet, i.e. {RadiusType;RadiusIdentifier;RadiusLength;RadiusRequestAuthenticator;Non-EAPRadiusAttributes;EAP-MSG;EAP-Zero-Auth} 4. Put the new HMAC-MD5 digest into the string value of the (currently zero) EAP-MessageAuthenticator attribute. 5. Compute the RadiusAuthenticator over the entire RadiusPacket (as normal). I'm not certain whether my understanding is correct, but a description of this kind is less ambiguous. It would also make the sentence that describes "the message integrity check" much clearer. I have the same kind of problem understanding the description of the EAP Message Authenticator within Access-Challenge, etc. Does it mean that I should perform the same process as described above (for a RadiusRequest), but instead of using the all-zero's EAP Message Authenticator, substitute the digest from the original RadiusRequest EAP Message Authenticator? I don't think so, because the RFC says "using the Request-Authenticator" and that means the Radius Authenticator, not the EAP Authenticator. It seems to me that the EAP and Radius Authenticators are being "tangled together" - if true, then logic reponsible for EAP processing would also need to have access to the original Radius packet. This seems to be architecturally undesirable and deserves explanantion if unavoidable. I apologise if my email is hard to understand. This is the first time I've tried to contribute to a draft RFC and I am not familiar with the process. If you need more information from me, I'll be pleased to continue the discussion by private email with any interested parties. Requested change: 1. new preamble/philosphy paragraph. 2. reworded RadiusRequest creation paragraph. 3. reworded RadiusRequest message integrity check paragraph. 4. reworded RadiusResponse/AccessChallenge/RadiusReject creation paragraph. 5. reworded RadiusResponse/AccessChallenge/RadiusReject message integrity check paragraph. Regards, Brian Burch [http://www.PingToo.com/] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 07:47:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09541 for ; Tue, 12 Aug 2003 07:47:04 -0400 (EDT) Received: (qmail 25525 invoked from network); 12 Aug 2003 11:47:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 11:47:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 25506 invoked from network); 12 Aug 2003 11:46:55 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 11:46:55 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DCF956A901; Tue, 12 Aug 2003 14:46:52 +0300 (EEST) Message-ID: <3F38D313.9060105@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 152: Lower layer indications References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 14:44:19 +0300 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > 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. I agree with this conclusion. So where does that leave us? Accept the issue, and thus clear the disagreement between 2284bis and the state machine? Or reject based on lack of big benefit? Hmm... in the interest of moving forward why don't we accept it and move on? > 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. Yes. But do we discuss even the "link down" indications explicitly? On a quick scan I couldn't find an explicit statement saying that one needs to abort EAP. In a number of places the discussion touches upon this, but stops short of saying what has to be done. Section 7.12 says for instance that in 802.11 one shouldn't abort upon a link down event without dampening. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 08:08:11 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10241 for ; Tue, 12 Aug 2003 08:08:01 -0400 (EDT) Received: (qmail 26256 invoked from network); 12 Aug 2003 12:08:02 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 12:08:02 -0000 Delivered-To: eap@frascone.com Received: (qmail 26208 invoked from network); 12 Aug 2003 12:07:06 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 12:07:06 -0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7CC73B17639 for ; Tue, 12 Aug 2003 15:07:04 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Aug 2003 15:07:03 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 15:07:02 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 15:07:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] draft-aboba-radius-rfc2869bis-22 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C6@esebe023.ntc.nokia.com> Thread-Topic: [eap] draft-aboba-radius-rfc2869bis-22 Thread-Index: AcNgJGrFIiAY2C6pTLmmzPoN+GItUwAoleFg From: To: , X-OriginalArrivalTime: 12 Aug 2003 12:07:02.0746 (UTC) FILETIME=[3D784BA0:01C360CA] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 15:07:01 +0300 Content-Transfer-Encoding: quoted-printable Hi, There's no ambiguity or circularity because in RADIUS, the Request Authenticator is just a random number--not a keyed hash over the packet contents. Thus, when calculating Message-Authenticator for Access-Requests, we can include it without any circularity problems. The Response Authenticator (in Access-Challenge/Accept/Reject)=20 is a keyed hash, but it's not included when calculating the Message-Authenticator for responses (the HMAC-MD5 is not=20 calculated over "the entire RADIUS packet"; check the=20 definition in 2869bis). If it were included, then we would have some circularity problems, and would have to set=20 the field to zero before calculating. Best regards, Pasi > -----Original Message----- > From: ext Brian Burch [mailto:Brian@PingToo.com] > Sent: Monday, August 11, 2003 6:54 PM > To: EAP Mailing List > Subject: [eap] draft-aboba-radius-rfc2869bis-22 >=20 >=20 > Description of issue: EAP Message Authenticator String=20 > description needs clarification > Submitter name: Brian Burch > Submitter email address: Brian@PingToo.com > Date first submitted: 11 August 2003 > Reference:=20 > Document: RFC 2869bis > Comment type: Technical > Priority: 1 > Section: 3.2. Message-Authenticator - String > > Rationale/Explanation of issue: I realise this section has=20 > NOT changed significantly between the published RFC and the=20 > draft. However, I'm currently working in this area and I=20 > cannot derive an unambiguous=20 > interpretation of the section from rfc2689bis-22. > > Length description of problem: > There's a semi-recursive problem with this attribute. The EAP=20 > Message Authenticator is supposed to digitally sign an entire=20 > Radius/EAP packet, but so is the Radius Authenticator. Given=20 > that Radius is being used=20 > as a "transport mechanism" for EAP, it follows that the=20 > Radius Authenticator MUST be the last field computed. In=20 > other words, the EAP Message Authenticator MUST be computed=20 > over the Radius packet BEFORE=20 > the Radius Authenticator is known. Therefore, the EAP Message=20 > Authenticator must be computed over an all-zero's Radius=20 > Authenticator. This could be stated more clearly. >=20 > Now, we have the same question about the EAP Message=20 > Authenticator itself. Do we compute over an all-zero's EAP=20 > Message Authenticator, or do we compute over just the Radius=20 > Packet BEFORE the Message Authenticator is added? I don't know=20 > and I can't tell from the RFC. My guess is the process is as follows: >=20 > 1. Put the EAP Message attribute into the Radius Packet. > 2. Put an all-zero's EAP Message Authenticator into the Radius Packet. > 3. Compute the HMAC-MD5 digest for the entire Radius packet,=20 > i.e.=20 > {RadiusType;RadiusIdentifier;RadiusLength;RadiusRequestAuthent > icator;Non-EAPRadiusAttributes;EAP-MSG;EAP-Zero-Auth} > 4. Put the new HMAC-MD5 digest into the string value of the=20 > (currently zero) EAP-MessageAuthenticator attribute. > 5. Compute the RadiusAuthenticator over the entire=20 > RadiusPacket (as normal). >=20 > I'm not certain whether my understanding is correct, but a=20 > description of this kind is less ambiguous. It would also=20 > make the sentence that describes "the message integrity=20 > check" much clearer. >=20 > I have the same kind of problem understanding the description=20 > of the EAP Message Authenticator within Access-Challenge,=20 > etc. Does it mean that I should perform the same process as=20 > described above (for a=20 > RadiusRequest), but instead of using the all-zero's EAP=20 > Message Authenticator, substitute the digest from the=20 > original RadiusRequest EAP Message Authenticator? I don't=20 > think so, because the RFC says=20 > "using the Request-Authenticator" and that means the Radius=20 > Authenticator, not the EAP Authenticator. It seems to me that=20 > the EAP and Radius Authenticators are being "tangled=20 > together" - if true, then logic=20 > reponsible for EAP processing would also need to have access=20 > to the original Radius packet. This seems to be=20 > architecturally undesirable and deserves explanantion if unavoidable. >=20 > I apologise if my email is hard to understand. This is the=20 > first time I've tried to contribute to a draft RFC and I am=20 > not familiar with the process. If you need more information=20 > from me, I'll be pleased to continue the=20 > discussion by private email with any interested parties. >=20 > Requested change: > 1. new preamble/philosphy paragraph. > 2. reworded RadiusRequest creation paragraph. > 3. reworded RadiusRequest message integrity check paragraph. > 4. reworded RadiusResponse/AccessChallenge/RadiusReject=20 > creation paragraph. > 5. reworded RadiusResponse/AccessChallenge/RadiusReject=20 > message integrity check paragraph. >=20 >=20 > Regards, >=20 > Brian Burch > [http://www.PingToo.com/] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:02:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11440 for ; Tue, 12 Aug 2003 09:02:04 -0400 (EDT) Received: (qmail 27575 invoked from network); 12 Aug 2003 13:02:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:02:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 27552 invoked from network); 12 Aug 2003 13:01:19 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:01:19 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 21C816A901; Tue, 12 Aug 2003 16:01:19 +0300 (EEST) Message-ID: <3F38E485.5090008@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access References: <893268.1060009444@[10.0.1.3]> In-Reply-To: <893268.1060009444@[10.0.1.3]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 15:58:45 +0300 Content-Transfer-Encoding: 7bit John Vollbrecht wrote: >> "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." The issue that Yoshi raised is mainly related to the interpretation of the word "link". In some cases its an on/off kind of thing, but as the PANA example shows, there can be a (limited) link outside the EAP authentication process. The original text talks about not pretending that things are OK when they really are not. Simply allowing data to be sent anyway would be dangerous. But I think John's new formulation makes sure that the link layer does not by accident send you important packets over an unauthenticated channel. But it still allows e.g. PANA local communications. So I agree with John's formulation. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:12:15 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11639 for ; Tue, 12 Aug 2003 09:12:05 -0400 (EDT) Received: (qmail 28093 invoked from network); 12 Aug 2003 13:12:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:12:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 28071 invoked from network); 12 Aug 2003 13:11:25 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:11:25 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7CDBMP28401 for ; Tue, 12 Aug 2003 16:11:23 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Aug 2003 16:11:22 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 16:11:22 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 16:11:20 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 16:11:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution to Issue 152: Link layer indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C7@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution to Issue 152: Link layer indications Thread-Index: AcNe4t4hBIg+s52HRqKH8C6/6AaKOgB7nGmQ From: To: , X-OriginalArrivalTime: 12 Aug 2003 13:11:19.0390 (UTC) FILETIME=[383577E0:01C360D3] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 16:11:16 +0300 Content-Transfer-Encoding: quoted-printable Hi, Deleting the phrase "having concluded an EAP method with successful=20 acknowledged result indications" certainly makes the paragraph easier to read. But it is precisely the circumstances defined=20 in 4.2, so this does not change the behavior at all... If we want to change the behavior, something like this could do it: "To improve reliability, if a peer receives a lower layer=20 success indication as defined in Section 7.12, it MAY conclude=20 that a Success packet has been lost, and behave as it had actually received a Success packet." Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Sunday, August 10, 2003 4:27 AM > To: eap@frascone.com > Subject: [eap] Proposed resolution to Issue 152: Link layer=20 > indications >=20 >=20 > The text of Issue 152 is enclosed below. The proposed resolution is: >=20 > In Section 3.4, change: >=20 > "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." >=20 > To: >=20 > "Section 4.2 defines the circumstances in which a peer > 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.12, it MAY conclude that a > Success packet has been lost without waiting for a > timeout." >=20 > ------------------------------------------------------------------- > 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 >=20 > "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." >=20 > This is not exactly what the current state machine does... >=20 > 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." >=20 > 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. >=20 > Both are IMHO quite reasonable approaches, and I just > wanted to clarify which one we really want to use? >=20 > [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? >=20 > [Pasi Eronen] You're right, and that happens in both=20 > approaches. The only > difference is in what to do when we don't have a method specific > indication. In this case, >=20 > - 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). >=20 > Which approach do you think we should use? >=20 > 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? >=20 > [BA] I think the major difference between the two > approaches is for one-way methods such as EAP-MD5 Challenge. >=20 > 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. >=20 > 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. >=20 > 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,=20 > so that I > don't think there is that much benefit to be provided. >=20 > So that the peer doesn't encounter a timeout, it probably=20 > makes sense to > have some assurance that the link is actually providing IP=20 > connectivity or > is likely to do so. >=20 > 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). >=20 > If we take these factors into account, I think the change is=20 > ok, although > it is not all that beneficial. >=20 > 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. >=20 > As far as lower layer failure indications are concerned, I think we > concluded that they would translate into "link down"=20 > indications in which > case the EAP conversation would abort anyway. Therefore there=20 > was no need > to discuss them explicitly. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:19:06 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12089 for ; Tue, 12 Aug 2003 09:19:04 -0400 (EDT) Received: (qmail 28564 invoked from network); 12 Aug 2003 13:19:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:19:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 28543 invoked from network); 12 Aug 2003 13:18:50 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:18:50 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CCn6J32156; Tue, 12 Aug 2003 05:49:06 -0700 From: Bernard Aboba To: Jari Arkko cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 152: Lower layer indications In-Reply-To: <3F38D313.9060105@piuha.net> Message-ID: References: <3F38D313.9060105@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 05:49:06 -0700 (PDT) > I agree with this conclusion. > > So where does that leave us? Accept the issue, and thus clear the > disagreement between 2284bis and the state machine? Or reject based > on lack of big benefit? Hmm... in the interest of moving forward > why don't we accept it and move on? I've suggested text for Issue 152, which didn't include any proposed changes. Is this enough? If not, can someone suggest additional text/changes? > Yes. But do we discuss even the "link down" indications > explicitly? On a quick scan I couldn't find an explicit statement > saying that one needs to abort EAP. In a number of places > the discussion touches upon this, but stops short of saying > what has to be done. Section 7.12 says for instance that in 802.11 > one shouldn't abort upon a link down event without dampening. I actually wouldn't necessarily say that one needs to abort EAP because depending on the reliability of the "link down" indication this might not be necessary. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:27:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12470 for ; Tue, 12 Aug 2003 09:27:02 -0400 (EDT) Received: (qmail 29106 invoked from network); 12 Aug 2003 13:27:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:27:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 29084 invoked from network); 12 Aug 2003 13:26:29 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:26:29 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CCuP532484; Tue, 12 Aug 2003 05:56:27 -0700 From: Bernard Aboba To: Jari Arkko cc: John Vollbrecht , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access In-Reply-To: <3F38E485.5090008@piuha.net> Message-ID: References: <893268.1060009444@[10.0.1.3]> <3F38E485.5090008@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 05:56:25 -0700 (PDT) > So I agree with John's formulation. OK. I've changed the proposed resolution of Issue 150 as you suggest. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:33:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12673 for ; Tue, 12 Aug 2003 09:33:05 -0400 (EDT) Received: (qmail 29556 invoked from network); 12 Aug 2003 13:33:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:33:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 29533 invoked from network); 12 Aug 2003 13:32:49 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:32:49 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CD37l00495; Tue, 12 Aug 2003 06:03:07 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: eap@frascone.com Subject: RE: [eap] Proposed resolution to Issue 152: Link layer indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222C7@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A61222C7@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 06:03:07 -0700 (PDT) How about this? In Section 3.4, change: "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." To: "To improve reliability, if a peer receives a lower layer success indication as defined in Section 7.12, it MAY conclude that a Success packet has been lost, and behave as it had actually received a Success packet. This includes choosing to ignore the Success in some circumstances." On Tue, 12 Aug 2003 Pasi.Eronen@nokia.com wrote: > > Hi, > > Deleting the phrase "having concluded an EAP method with successful > acknowledged result indications" certainly makes the paragraph > easier to read. But it is precisely the circumstances defined > in 4.2, so this does not change the behavior at all... > > If we want to change the behavior, something like this could do it: > > "To improve reliability, if a peer receives a lower layer > success indication as defined in Section 7.12, it MAY conclude > that a Success packet has been lost, and behave as it had > actually received a Success packet." > > Best regards, > Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 09:43:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13045 for ; Tue, 12 Aug 2003 09:43:04 -0400 (EDT) Received: (qmail 30094 invoked from network); 12 Aug 2003 13:43:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 13:43:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 30072 invoked from network); 12 Aug 2003 13:42:24 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 13:42:24 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7CDgLP26486 for ; Tue, 12 Aug 2003 16:42:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Aug 2003 16:42:21 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 16:42:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 16:41:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution to Issue 152: Link layer indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB90@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution to Issue 152: Link layer indications Thread-Index: AcNg1kGl/pkDKJOmReimwr79Ifb1BAAAQtDw From: To: Cc: X-OriginalArrivalTime: 12 Aug 2003 13:41:57.0867 (UTC) FILETIME=[8006CBB0:01C360D7] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 16:41:57 +0300 Content-Transfer-Encoding: quoted-printable Yes, this looks ok; it's a good idea to mention explicitly that the Success could be ignored. Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, August 12, 2003 4:03 PM > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: RE: [eap] Proposed resolution to Issue 152: Link layer > indications >=20 >=20 > How about this? >=20 > In Section 3.4, change: >=20 > "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." >=20 > To: >=20 > "To improve reliability, if a peer receives a lower layer > success indication as defined in Section 7.12, it MAY conclude > that a Success packet has been lost, and behave as it had > actually received a Success packet. This includes choosing to > ignore the Success in some circumstances." >=20 > On Tue, 12 Aug 2003 Pasi.Eronen@nokia.com wrote: >=20 > > > > Hi, > > > > Deleting the phrase "having concluded an EAP method with successful > > acknowledged result indications" certainly makes the paragraph > > easier to read. But it is precisely the circumstances defined > > in 4.2, so this does not change the behavior at all... > > > > If we want to change the behavior, something like this could do it: > > > > "To improve reliability, if a peer receives a lower layer > > success indication as defined in Section 7.12, it MAY conclude > > that a Success packet has been lost, and behave as it had > > actually received a Success packet." > > > > Best regards, > > Pasi >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 19:04:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02297 for ; Tue, 12 Aug 2003 19:04:02 -0400 (EDT) Received: (qmail 7265 invoked from network); 12 Aug 2003 23:04:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 23:04:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7243 invoked from network); 12 Aug 2003 23:03:44 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 23:03:44 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2003 16:03:18 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7CN3ELH017913; Tue, 12 Aug 2003 16:03:14 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Aug 2003 16:07:18 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: Subject: RE: [eap] Issue 165: Applicability statement Message-ID: <00c601c36125$e8865db0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 12 Aug 2003 23:07:18.0814 (UTC) FILETIME=[7A7C8BE0:01C36126] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 16:03:13 -0700 Content-Transfer-Encoding: 7bit > > - 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. > [Joe] EAP provides you with several things that GSSAPI and SASL do not. It provides a formal description of the operation of a passthrough authenticator and it provides a means to access session keys. One can argue about whether these are a good idea or not, but it has proven useful in present EAP applications. > > 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. > > _______________________________________________ > 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 eap-admin@frascone.com Tue Aug 12 19:35:25 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03868 for ; Tue, 12 Aug 2003 19:35:01 -0400 (EDT) Received: (qmail 7989 invoked from network); 12 Aug 2003 23:35:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 12 Aug 2003 23:35:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7959 invoked from network); 12 Aug 2003 23:34:23 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 12 Aug 2003 23:34:23 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CN4gA01567 for ; Tue, 12 Aug 2003 16:04:43 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed Resolution to Issue 119 (RFC 2284bis only) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 16:04:42 -0700 (PDT) The text of Issue 119 is enclosed below. The proposed resolution in terms of RFC 2284bis changes is as follows: In Section 2, delete: "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). 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." Add section 2.4: "2.4 Peer-to-Peer Operation 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). Both peers may act as authenticators and authenticatees at the same time. Although EAP supports peer-to-peer operation, selected EAP methods, AAA protocols and link layers may not support this. For example, EAP-TLS [RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to be provisioned with two distinct certificates, one appropriate for each role. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DiamEAP] only support "passthrough" operation on behalf of an authenticator, not a peer. For example, as noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request with an Access-Reject. Link layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in adhoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. Link layers such as IEEE 802.11 adhoc also do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur." ---------------------------------------------------------------------- Issue 119: EAP Inappropriate for use in peer-to-peer Submitter name: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: April 30, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: In my opinion (emprical data amply demonstrates that no one has to agree ;-) the EAP framework is inappropriate in general for peer-to-peer operation. If you think through the model specified for peer-to-peer operation, you get into a mire of problems that raise the issue of whether EAP as constituted today is appropriately matched to the problem. The first problem requires a solution outside (and way outside at that) of EAP. Authentication presupposes a notion of a community with a common set of credentials. It does not make sense to allow anyone to use any credential in any context, because by definition all members of the community must be able to somehow recognize one another as being legitimate members of **THIS** community. In all systems I am aware of this is accomplished through a common policy to utilize a common set of credentials. In particular, a community corresponds to some common credentialing or enrollment function, where each credential identifies its bearer as a member of the community in some uniform way, and also implies an access control (membership in the community) that is universally recognized by all other members of the community. So point number one is it is not feasible to establish a peer-to-peer network without first establishing a notion of a network or community, and doing so is not EAP's problem to solve. The second problem is a special case of this. There are only three basic trust models. The first is direct bilateral trust, where two parties authenticate each other directly and make up a key shared only between themselves. This model essentially works only in networks of two parties, so is not a general solution; there is no way to enforce that all members of a larger group will authenticate and establish their session keys in exactly the same way. The second model is to rely on an on-line trusted third party. This is the model used by 802.1X and Kerberos. All members of the group are enrolled with the on-line trusted third party, and the on-line trusted third party provides some mechanism for distributing pairwise keys to any pair of communicating parties within the community. In the peer-to-peer model one can imagine communities ranging from those with one such on-line trusted third party (completely centralized admission control) to those where every group member becomes an on-line trusted third party (completely distributed admission control). However, by definition, one and only one on-line trusted third party can mediate any particular session between two members of the community, because it is only one session. The third model relies on an off-line trusted third party. TLS is an example that exploits this model. This model relies on public/private key technology, as proof-of-possesion of the private key pair is the ultimate basis for electronic identity. In this model, since possession of a private key is assumed to establish identity, the use of such a key by another member can be used to attest to the membership of another party. This is a model that scales, because the community member making an attestation need not be within communication range when the access control decision is being made. In my mind a general-purpose secure peer-to-peer model would need to support all three approaches. The impression I get is that people are thinking almost exclusively of the bilateral case, and they are struggling to wedge the on-line trusted third party model that EAP is based on to fit this, and this can't be done elegantly. If this impression is correct (and I'm not claiming that is is, but rather only that it is my impression), then the current approach is technically flawed in two dimensions: the on-line trusted third party model is not the same as the bilateral model that people are thinking of, and EAP should be expanded to support all three models instead of just one. Oh, sure, any model can be used to emulate any other model, but emulation costs MIPs, and my employer is eternally grateful ("Sell more Pentiums") for each. Emulation abandons many otherwise fine applications (e.g., the secure wireless lightbulb) because of cost constraints. The third problem centers around limitations of the security of data links like 802.11. In particular, the security associations in this class of networks use the **SAME** key for both directions of traffic flow between two peers. This implies that the two peers must somehow agree on what this key is. This is a much trickier problem than first appears, and EAP's structure does not help solve it. I've pointed out this problem before: it is essential to cryptographically relate the two independent authentications. In particular, a cyrptographically sound authentication method will establish a notion of a session that can be distinguish **THIS** session from every other session between the **SAME** peers, so one can figure out **WHICH** session key to use during **THIS** session. Temproality of messages by themselves does nothing to establish this. Indeed, protocols like TLS and AKEP and Archie establish session identity by exchanging random nonces and mutually authenticating. For instance, when EAP-TLS is used, clientHello.random and serverHello.random together with the authentication information identify **THIS** session. But there is nothing in EAP that can be used to accomplish this function. The EAP Identifier field is the only possible candidate for the nonce space, but the size of the Identifier field is way too small to provide anything meaningful, and there are no native EAP cryptographic protections to protect this field anyway. Identifying each session requires restricting the authentication protocol to those that already come with all the necessary bells and whisteles. But this is not enough, because, to solve the 802.11 keying problem, one still has to identify that the sessions established by each direction of authentication are both extant between the same peers at the same time. One can imagine, for instance, some sort of meta-EAP protocol that relies on the larger nonce space when specificly restricted to protocols like TLS or Archie; one could, for instance, make up rules that say in peer-to-peer mode, if one receives an authenticate request from a peer to whom one has an outstanding request, you must use the same nonce that you have outstanding, etc. But this feels uncomfortably like trying to pound a round peg into a square hole, and one has to struggle to suppress the observation that we are really, really reaching here, and that there has to be a better and easier and cheaper way. The fourth problem is easy is some cases, if the other problems can be solved. And that is how to pick out the session key to use. If you **CAN** identify the two sessions in each direction, and **CAN** authoritatively establish that both are indeed between the same pair of parties, then any arbitrary scheme can be used to select one of the two session keys to use to protect the underlying link, e.g., picking the smaller of two MAC addresses in the 802 case. So I am deeply skeptical about extending the current instantiation of EAP to cover peer-to-peer; the intellectual spadework has not been done, and the tiny bit I may have contributed in this missive tends to indicate, at least to me, that EAP does not have the right shape. This strikes me as a case, as the adage says, everything looks like a nail to someone who only has a hammer. For whatever it is worth, that's my two cents. [BA, Responding to Jesse Walker]: > While this is true, it is irrelevant, because it diverts attention from > the issue. The EAP model is clearly client-server, not peer-to-peer. > This is not wrong or bad; security association establishment protocols > (at least the ones that work :-) seem to be inherently client/server. What makes EAP "inherently client-server"? There are a few things about the protocol that are asymmetric, such as retransmission behavior (handled by the authenticator), and the sending of Success/Failure (the authenticator sends this to the peer). However, with the recent decisions to only allow a single EAP authentication method per conversation, the Success/Failure packets can be viewed as largely vestigial within a mutually authenticating method, and Bob Moskowitz has submitted a change to IEEE 802.1aa to include the notion of "controlled/uncontrolled ports" on both the supplicant and authenticator. While many of the original EAP methods are client-server protocols (e.g. TLS), we have examples of peer-to-peer authentication technologies being proposed for use with EAP. An example is EAP-ARCHIE, which is a peer-to-peer protocol (no distinction made between Initiator and Responder with respect to say, authentication modes) -- yet it is being proposed to encapsulate this within EAP, without requiring any changes to EAP. > My point is that the current peer-to-peer direction does not appear > sound or even properly thought through. I think we need to make a distinction between peer-to-peer usage as envisaged in RFC 2284 and IEEE 802.1aa, and the "adhoc" or "mesh networking" scenarios being contemplated in IEEE 802.11. The "adhoc" or "mesh networking" scenarios in IEEE 802.11 are indeed considerably more complex. In garden variety peer-to-peer between say, two Bridges on a wired network, the Bridges are stationary and typically within the same administrative domain. In that situation there are certainly credential provisioning issues, but given some "tie breaker" functionality, an appropriate EAP method supporting peer-to-peer authentication, and sufficient intestinal fortitude on the part of administrators, it can be made to work. However, in the "adhoc" or "mesh networking" scenarios contemplated in IEEE 802.11, we have mobile stations that can potentially be continually bringing up and tearing down security associations where there is no inherent trust model. Just as using OSPF for mesh network routing isn't advisable in these situations, without some care it is likely that stations will be unable to authenticate at all, or if they can, will spend much of their time authenticating and very little time communicating. However, I'm not clear to what extent use of EAP makes this problem worse. I'd also note that IEEE 802.11i is running two authentications, one in each direction, deriving two sets of keys, and *then* running a tie-breaker. This seems wasteful, particularly when we are talking about providing keying material for a ciphersuite that uses the same keys in both directions. > It will take a lot of infrastructure outside > of 802.1aa or EAP to make peer-to-peer work If by peer-to-peer you mean "IEEE 802.11 ahoc or mesh networking", I would agree. However, the scenarios contemplated in IEEE 802.1aa are considerably simpler than this. > My suspcion is neither does so because we as a community > still don't comprehend the issues involved. I know I don't, but the > discussion thus far has blithely tiptoed along without any recognition > that this is the middle of a mine field. Since mesh network security is an active research area, I'd agree that this is not something that is sufficiently well understood. We could certainly put in a section that describes some of the issues when attempting to apply EAP to those problems. > This is not a problem in a protocol > like IPsec, because there are separate security associations in each > direction of the conversation, so each can be keyed by an independent > security association establishment. I'm curious as to why IKEv1 can be used for independent security association establishment, whereas EAP-IKEv1 could not be. What is it about the EAP transport that somehow changes the security properties of an existing protocol? > constructions like 802.11i, however, because there is only one security > association per link. That seems like an 802.11 problem to me. There are certainly situations where EAP can be used with more than one security association per link. An example of this is PPPOE, where it is possible to have a single host bringing up multiple PPP sessions to different ISPs, all operating over the same link. Where EAP is used for authentication and key management, it is possible to use PPPOE today to bring up multiple security associations per link. So this isn't an EAP issue -- it's a link layer issue. > It is hard enough to get one authentication right let alone two. I would agree that the decision of IEEE 802.11i to do two authentications *then* do election seems odd. But I'm not sure why this decision was forced by the use of EAP. In general, I'd observe that in situations where problem requirements are poorly understood it is best to gain clarity *before* introducing potential solutions. There are quite a few situations where conventional EAP methods will not work well, but that's different from saying that *some* EAP method cannot be made to work. > Hence it appears to be a work item that can be deferred until EAP2 (or > whatever it is called this week). Since this problem is neither caused by, or solved by EAP, creating a new protocol is unlikely to add either to the clarity of the problem statement, or to the value of a solution. > If EAP and 802.1aa continue on their present courses, here are some > constraints I'd suggest: both parties MUST use the same concrete > authentication method with the same credentials for both > authentications; Why? RFC 2284 explicitly states that this is *not* a constraint. > the authentication method MUST exchange random nonces; For a mutually authenticating method this is sound advice and we should add this. For a one-way method, it doesn't seem necessary though. > the authentication method MUST protect the nonces from modification; Seems reasonable. > each authentication MUST detect replay and man-in-the-middle attack in > BOTH directions; Seems reasonable. > if the two peers initiate their separate authentications simultaneously, > then they MUST reuse the nonce they supplied for the authentication > they initiated in the authentication to which they are responding; Since we're already saying that two separate authentications is not equivalent to one mutual one, I'm not sure why we should try to mandate that they be interlinked. If the intent is to do something like this, why do two separate authentications in the first place, why not just do a single mutual auth? > if the peers do not initiate simultaneously, then the peer that has not > initiated should fall back to the client-server model if it receives an > authentication initiated by the peer It seems reasonable to suggest some sort of tie breaking behavior in the case where a single mutually authenticating conversation is desired. > More constraints may be needed, and some of these proposed constraints > may not be right, because, like I said, I don't claim I understand the > problem, but if you remove any one of these constraints, then I think it > is possible to construct attacks that can compromise at least an 802.11i > protected link. Such an attack, if feasible, would derive from allowing two non-interlinked authentications, one in each direction. This isn't an EAP problem per say -- though we can certainly insert additional language advising against this. > The discussion thus far has treated the peer-to-peer case as mechanical. > I hope that people agree with me that it is not, and much more toil is > required. I would certainly agree that IEEE 802.11 "adhoc" or "mesh networking" requires more thought. But few of the issues you've brought up so far apply to the simple Bridge-Bridge cases discussed in IEEE 802.1aa. [BA] Here are the proposed fixes for the EAP Keying Framework document. Add the following requirements to Section 4.1: Liveness Methods deriving keys SHOULD exchange random nonces, and SHOULD protect the nonces from modification. Man-in-the-middle and replay protection Methods deriving keys SHOULD detect replay and man-in-the-middle attacks in either direction. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 12 21:50:12 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06478 for ; Tue, 12 Aug 2003 21:50:06 -0400 (EDT) Received: (qmail 10451 invoked from network); 13 Aug 2003 01:50:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 01:50:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 10411 invoked from network); 13 Aug 2003 01:49:06 -0000 Received: from fmr06.intel.com (HELO caduceus.jf.intel.com) (134.134.136.7) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 01:49:06 -0000 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7D1gXE29446 for ; Wed, 13 Aug 2003 01:42:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7D1haK19861 for ; Wed, 13 Aug 2003 01:43:36 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081219005813911 for ; Tue, 12 Aug 2003 19:00:58 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Aug 2003 18:48:38 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3613D.03F28482" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <0769E8DB76C83645A75E3F8EDDE24F9BDCECB9@orsmsx407.jf.intel.com> Thread-Topic: EAP Binding Draft issues on the reflector Thread-Index: AcNhPPkjd9jTDkOrRTOgShXg/RmvXA== From: "Puthenkulam, Jose P" To: X-OriginalArrivalTime: 13 Aug 2003 01:48:38.0624 (UTC) FILETIME=[041A5600:01C3613D] Subject: [eap] EAP Binding Draft issues on the reflector Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Aug 2003 18:48:38 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3613D.03F28482 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 This is just a friendly reminder to submitters of issues with the EAP Binding Draft version 1 to review the latest draft and close them as EAP Binding Draft version 2 and 3 address all of them to the best of our knowledge.=20 =20 Here's the link to all the issues logged against the draft http://www.drizzle.com/~aboba/EAP/eapissues.html =20 Here's the link to the latest EAP Binding draft http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt =20 best regards, jose =20 ------_=_NextPart_001_01C3613D.03F28482 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
 
This = is just a=20 friendly reminder to submitters of issues with the EAP Binding = Draft=20 version 1 to review the latest draft and close them as EAP Binding Draft = version=20 2 and 3 address all of them to the best of our knowledge. =
 
Here's = the link to=20 all the issues logged against the draft
http://www.driz= zle.com/~aboba/EAP/eapissues.html
 
Here's = the link to=20 the latest EAP Binding draft
http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-bindin= g-03.txt
 
best=20 regards,
jose
 
------_=_NextPart_001_01C3613D.03F28482-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 13 10:07:33 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20111 for ; Wed, 13 Aug 2003 10:07:15 -0400 (EDT) Received: (qmail 21376 invoked from network); 13 Aug 2003 14:07:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 14:07:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 21356 invoked from network); 13 Aug 2003 14:06:59 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 14:06:59 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ED31A6A902; Wed, 13 Aug 2003 17:06:56 +0300 (EEST) Message-ID: <3F3A4566.6000102@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 119 (RFC 2284bis only) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Aug 2003 17:04:22 +0300 Content-Transfer-Encoding: 7bit Bernard, Your text looks very good. This should be adequate. --Jari > "2.4 Peer-to-Peer Operation > > 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). Both peers may act as > authenticators and authenticatees at the same time. > > Although EAP supports peer-to-peer operation, selected EAP methods, > AAA protocols and link layers may not support this. For example, > EAP-TLS [RFC2716] is a client-server protocol requiring a different > certificate profile for the client and server. This implies that > a host supporting both the EAP-TLS peer and authenticator roles > would need to be provisioned with two distinct certificates, one > appropriate for each role. > > Some EAP methods may support asymmetric authentication, with one > type of credential being required for the peer and another type > for the authenticator. Hosts supporting peer-to-peer operation > with such a method would need to be provisioned with both > types of credentials. > > AAA protocols such as RADIUS/EAP [RFC3579] and > Diameter EAP [DiamEAP] only support "passthrough" > operation on behalf of an authenticator, not a peer. > For example, as noted in [RFC3579] Section 2.6.2, > a RADIUS server responds to an Access-Request > encapsulating an EAP-Request with an Access-Reject. > > Link layers such as IEEE 802.11 may only support > uni-directional derivation and transport of transient > session keys. For example, the group-key handshake defined in > [IEEE802.11i] is uni-directional, since in IEEE 802.11 only > the Access Point (AP) sends multicast traffic. This means > that in adhoc operation where either peer may send multicast > traffic, two uni-directional group-key exchanges > are required. Due to constraints imposed by the 4-way > unicast key handshake state machine, this also implies > two 4-way handshake and EAP method exchanges. > > Link layers such as IEEE 802.11 adhoc also do not support > "tie breaking" wherein two hosts initiating authentication > with each other will only go forward with a single > authentication. This implies that even if 802.11 were to > support a bi-directional group-key handshake, then two > authentications, one in each direction, might still occur." > > ---------------------------------------------------------------------- > Issue 119: EAP Inappropriate for use in peer-to-peer > Submitter name: Jesse Walker > Submitter email address: jesse.walker@intel.com > Date first submitted: April 30, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > > In my opinion (emprical data amply demonstrates that no one has to agree > ;-) the EAP framework is inappropriate in general for peer-to-peer > operation. If you think through the model specified for peer-to-peer > operation, you get into a mire of problems that raise the issue of whether > EAP as constituted today is appropriately matched to the problem. > > The first problem requires a solution outside (and way outside at that) of > EAP. Authentication presupposes a notion of a community with a common set > of credentials. It does not make sense to allow anyone to use any > credential in any context, because by definition all members of the > community must be able to somehow recognize one another as being > legitimate members of **THIS** community. In all systems I am aware of > this is accomplished through a common policy to utilize a common set of > credentials. In particular, a community corresponds to some common > credentialing or enrollment function, where each credential identifies its > bearer as a member of the community in some uniform way, and also implies > an access control (membership in the community) that is universally > recognized by all other members of the community. So point number one is > it is not feasible to establish a peer-to-peer network without first > establishing a notion of a network or community, and doing so is not EAP's > problem to solve. > > The second problem is a special case of this. There are only three basic > trust models. The first is direct bilateral trust, where two parties > authenticate each other directly and make up a key shared only between > themselves. This model essentially works only in networks of two parties, > so is not a general solution; there is no way to enforce that all members > of a larger group will authenticate and establish their session keys in > exactly the same way. The second model is to rely on an on-line trusted > third party. This is the model used by 802.1X and Kerberos. All members of > the group are enrolled with the on-line trusted third party, and the > on-line trusted third party provides some mechanism for distributing > pairwise keys to any pair of communicating parties within the community. > In the peer-to-peer model one can imagine communities ranging from those > with one such on-line trusted third party (completely centralized > admission control) to those where every group member becomes an on-line > trusted third party (completely distributed admission control). However, > by definition, one and only one on-line trusted third party can mediate > any particular session between two members of the community, because it is > only one session. The third model relies on an off-line trusted third > party. TLS is an example that exploits this model. This model relies on > public/private key technology, as proof-of-possesion of the private key > pair is the ultimate basis for electronic identity. In this > model, since possession of a private key is assumed to establish identity, > the use of such a key by another member can be used to attest to the > membership of another party. This is a model that scales, because the > community member making an attestation need not be within communication > range when the access control decision is being made. > > In my mind a general-purpose secure peer-to-peer model would need to > support all three approaches. The impression I get is that people are > thinking almost exclusively of the bilateral case, and they are struggling > to wedge the on-line trusted third party model that EAP is based on to fit > this, and this can't be done elegantly. If this impression is correct (and > I'm not claiming that is is, but rather only that it is my impression), > then the current approach is technically flawed in two dimensions: the > on-line trusted third party model is not the same as the bilateral model > that people are thinking of, and EAP should be expanded to support all > three models instead of just one. Oh, sure, any model can be used to > emulate any other model, but emulation costs MIPs, and my employer is > eternally grateful ("Sell more Pentiums") for each. Emulation abandons > many otherwise fine applications (e.g., the secure wireless lightbulb) > because of cost constraints. > > The third problem centers around limitations of the security of data links > like 802.11. In particular, the security associations in this class of > networks use the **SAME** key for both directions of traffic flow between > two peers. This implies that the two peers must somehow agree on what this > key is. This is a much trickier problem than first appears, and EAP's > structure does not help solve it. I've pointed out this problem before: it > is essential to cryptographically relate the two independent > authentications. In particular, a cyrptographically sound authentication > method will establish a notion of a session that can be distinguish > **THIS** session from every other session between the **SAME** peers, so > one can figure out **WHICH** session key to use during **THIS** session. > Temproality of messages by themselves does nothing to establish this. > Indeed, protocols like TLS and AKEP and Archie establish session identity > by exchanging random nonces and mutually authenticating. For instance, > when EAP-TLS is used, clientHello.random and serverHello.random together > with the authentication information identify **THIS** session. But there > is nothing in EAP that can be used to accomplish this function. The EAP > Identifier field is the only possible candidate for the nonce space, but > the size of the Identifier field is way too small to provide anything > meaningful, and there are no native EAP cryptographic protections to > protect this field anyway. Identifying each session requires restricting > the authentication protocol to those that already come with all the > necessary bells and whisteles. > > But this is not enough, because, to solve the 802.11 keying problem, one > still has to identify that the sessions established by each direction of > authentication are both extant between the same peers at the same time. > One can imagine, for instance, some sort of meta-EAP protocol that relies > on the larger nonce space when specificly restricted to protocols like > TLS or Archie; one could, for instance, make up rules that say in > peer-to-peer mode, if one receives an authenticate request from a peer to > whom one has an outstanding request, you must use the same nonce that you > have outstanding, etc. But this feels uncomfortably like trying to pound > a round peg into a square hole, and one has to struggle to suppress the > observation that we are really, really reaching here, and that there has > to be a better and easier and cheaper way. > > The fourth problem is easy is some cases, if the other problems can be > solved. And that is how to pick out the session key to use. If you **CAN** > identify the two sessions in each direction, and **CAN** authoritatively > establish that both are indeed between the same pair of parties, then any > arbitrary scheme can be used to select one of the two session keys to use > to protect the underlying link, e.g., picking the smaller of two MAC > addresses in the 802 case. > > So I am deeply skeptical about extending the current instantiation of EAP > to cover peer-to-peer; the intellectual spadework has not been done, and > the tiny bit I may have contributed in this missive tends to indicate, at > least to me, that EAP does not have the right shape. This strikes me as a > case, as the adage says, everything looks like a nail to someone who only > has a hammer. For whatever it is worth, that's my two cents. > > [BA, Responding to Jesse Walker]: > > >>While this is true, it is irrelevant, because it diverts attention from >>the issue. The EAP model is clearly client-server, not peer-to-peer. >>This is not wrong or bad; security association establishment protocols >>(at least the ones that work :-) seem to be inherently client/server. > > > What makes EAP "inherently client-server"? There are a few things about > the protocol that are asymmetric, such as retransmission behavior (handled > by the authenticator), and the sending of Success/Failure (the > authenticator sends this to the peer). However, with the recent decisions > to only allow a single EAP authentication method per conversation, the > Success/Failure packets can be viewed as largely vestigial within a > mutually authenticating method, and Bob Moskowitz has submitted a change > to IEEE 802.1aa to include the notion of "controlled/uncontrolled ports" > on both the supplicant and authenticator. > > While many of the original EAP methods are client-server protocols (e.g. > TLS), we have examples of peer-to-peer authentication technologies being > proposed for use with EAP. An example is EAP-ARCHIE, which is a > peer-to-peer protocol (no distinction made between Initiator and Responder > with respect to say, authentication modes) -- yet it is being proposed to > encapsulate this within EAP, without requiring any changes to EAP. > > >>My point is that the current peer-to-peer direction does not appear >>sound or even properly thought through. > > > I think we need to make a distinction between peer-to-peer usage as > envisaged in RFC 2284 and IEEE 802.1aa, and the "adhoc" or "mesh > networking" scenarios being contemplated in IEEE 802.11. > > The "adhoc" or "mesh networking" scenarios in IEEE 802.11 are indeed > considerably more complex. In garden variety peer-to-peer between say, > two Bridges on a wired network, the Bridges are stationary and > typically within the same administrative domain. In that situation > there are certainly credential provisioning issues, but given some > "tie breaker" functionality, an appropriate EAP method > supporting peer-to-peer authentication, and sufficient intestinal > fortitude on the part of administrators, it can be made to work. > > However, in the "adhoc" or "mesh networking" scenarios contemplated in > IEEE 802.11, we have mobile stations that can potentially be continually > bringing up and tearing down security associations where there is no > inherent trust model. Just as using OSPF for mesh network routing isn't > advisable in these situations, without some care it is likely that > stations will be unable to authenticate at all, or if they can, will spend > much of their time authenticating and very little time communicating. > However, I'm not clear to what extent use of EAP makes this problem worse. > > I'd also note that IEEE 802.11i is running two authentications, one in > each direction, deriving two sets of keys, and *then* running a > tie-breaker. This seems wasteful, particularly when we are talking > about providing keying material for a ciphersuite that uses the same keys > in both directions. > > >>It will take a lot of infrastructure outside >>of 802.1aa or EAP to make peer-to-peer work > > > If by peer-to-peer you mean "IEEE 802.11 ahoc or mesh networking", I would > agree. However, the scenarios contemplated in IEEE 802.1aa are > considerably simpler than this. > > >>My suspcion is neither does so because we as a community >>still don't comprehend the issues involved. I know I don't, but the >>discussion thus far has blithely tiptoed along without any recognition >>that this is the middle of a mine field. > > > Since mesh network security is an active research area, I'd agree that > this is not something that is sufficiently well understood. We could > certainly put in a section that describes some of the issues when > attempting to apply EAP to those problems. > > >>This is not a problem in a protocol >>like IPsec, because there are separate security associations in each >>direction of the conversation, so each can be keyed by an independent >>security association establishment. > > > I'm curious as to why IKEv1 can be used for independent security > association establishment, whereas EAP-IKEv1 could not be. What is it > about the EAP transport that somehow changes the security properties of an > existing protocol? > > >>constructions like 802.11i, however, because there is only one security >>association per link. > > > That seems like an 802.11 problem to me. There are certainly situations > where EAP can be used with more than one security association per link. An > example of this is PPPOE, where it is possible to have a single host > bringing up multiple PPP sessions to different ISPs, all operating over > the same link. Where EAP is used for authentication and key management, it > is possible to use PPPOE today to bring up multiple security associations > per link. So this isn't an EAP issue -- it's a link layer issue. > > >>It is hard enough to get one authentication right let alone two. > > > I would agree that the decision of IEEE 802.11i to do two authentications > *then* do election seems odd. But I'm not sure why this decision was > forced by the use of EAP. > > In general, I'd observe that in situations where problem requirements are > poorly understood it is best to gain clarity *before* introducing > potential solutions. There are quite a few situations where conventional > EAP methods will not work well, but that's different from saying that > *some* EAP method cannot be made to work. > > >>Hence it appears to be a work item that can be deferred until EAP2 (or >>whatever it is called this week). > > > Since this problem is neither caused by, or solved by EAP, creating a new > protocol is unlikely to add either to the clarity of the problem > statement, or to the value of a solution. > > >>If EAP and 802.1aa continue on their present courses, here are some >>constraints I'd suggest: both parties MUST use the same concrete >>authentication method with the same credentials for both >>authentications; > > > Why? RFC 2284 explicitly states that this is *not* a constraint. > > >>the authentication method MUST exchange random nonces; > > > For a mutually authenticating method this is sound advice and we should > add this. For a one-way method, it doesn't seem necessary though. > > >>the authentication method MUST protect the nonces from modification; > > > Seems reasonable. > > >>each authentication MUST detect replay and man-in-the-middle attack in >>BOTH directions; > > > Seems reasonable. > > >>if the two peers initiate their separate authentications simultaneously, >>then they MUST reuse the nonce they supplied for the authentication >>they initiated in the authentication to which they are responding; > > > Since we're already saying that two separate authentications is not > equivalent to one mutual one, I'm not sure why we should try to mandate > that they be interlinked. If the intent is to do something like this, why > do two separate authentications in the first place, why not just do a > single mutual auth? > > >>if the peers do not initiate simultaneously, then the peer that has not >>initiated should fall back to the client-server model if it receives an >>authentication initiated by the peer > > > It seems reasonable to suggest some sort of tie breaking behavior in the > case where a single mutually authenticating conversation is desired. > > >>More constraints may be needed, and some of these proposed constraints >>may not be right, because, like I said, I don't claim I understand the >>problem, but if you remove any one of these constraints, then I think it >>is possible to construct attacks that can compromise at least an 802.11i >>protected link. > > > Such an attack, if feasible, would derive from allowing two > non-interlinked authentications, one in each direction. This isn't an EAP > problem per say -- though we can certainly insert additional language > advising against this. > > >>The discussion thus far has treated the peer-to-peer case as mechanical. >>I hope that people agree with me that it is not, and much more toil is >>required. > > > I would certainly agree that IEEE 802.11 "adhoc" or "mesh networking" > requires more thought. But few of the issues you've brought up so far > apply to the simple Bridge-Bridge cases discussed in IEEE 802.1aa. > > [BA] Here are the proposed fixes for the EAP Keying Framework document. > > Add the following requirements to Section 4.1: > > Liveness > > Methods deriving keys SHOULD exchange random nonces, and > SHOULD protect the nonces from modification. > > Man-in-the-middle and replay protection > > Methods deriving keys SHOULD detect replay and man-in-the-middle > attacks in either direction. > > _______________________________________________ > 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 eap-admin@frascone.com Wed Aug 13 10:22:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21621 for ; Wed, 13 Aug 2003 10:22:03 -0400 (EDT) Received: (qmail 22078 invoked from network); 13 Aug 2003 14:22:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 14:22:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 22042 invoked from network); 13 Aug 2003 14:21:18 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 14:21:18 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E78AE6A902; Wed, 13 Aug 2003 17:21:17 +0300 (EEST) Message-ID: <3F3A48C3.7080104@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lortz, Victor" Cc: eap@frascone.com Subject: Re: [eap] Adding supplementary data to Identity-Response? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Aug 2003 17:18:43 +0300 Content-Transfer-Encoding: 7bit Lortz, Victor wrote: > Section 5.1 of 2284bis describes the EAP Identity messages (Request and Response). The latest draft says that the text of the Request message prior to a NULL character is intended to be displayed to the user. Any information after the NULL character is extra data whose format is still TBD. Some existing networks use the following syntax: > > \0networkid=,nasid=,portid= Yes. > What do people think about extending this idea to include extra data in Identity-Response messages as well? One possible use would be to allow the peer to indicate its preferred authentication method. Another use would be to communicate characteristics of the network services desired by the peer. For example, the peer may require a certain bit rate or a certain quality of service (or the ability to request quality of service). > > One could think of this additional data (in both the Identity Request and Response) as supplementary information (i.e., hints) that can be used to determine whether it will be worthwhile to continue attempting the connection. Piggy-backing this data on the Identity messages has the important advantages of reducing round trips and of making this data available as soon as possible in the authentication process. Here are some thoughts: As you point out, the proposal has potential backwards compatibility considerations. For instance, I might have to upgrade the firmware of my old NAS if a new client with support for this came around, otherwise authentication would fail. On those grounds, I'm a bit skeptical of this particular solution. There's a related issue of transferring configuration and other information through EAP. We might find ways to do what you request without breaking old implementations. But then we have to figure out what information is really needed, and what protocol is the right place in the stack to transfer this information. For instance, there has been a discussion of whether "network selection" should be done at EAP, link layer, or somewhere else. Looking at your example uses of this information, there may be some specific uses that require their specific solutions if they are to be done right. For instance, passing the "preferred method" information to the authenticator. While its true that such information could reduce the number of roundtrips, if we are going to touch the ack-nak behaviour of EAP I'd rather make the negotiation secure at the same time. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 13 10:39:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22186 for ; Wed, 13 Aug 2003 10:39:05 -0400 (EDT) Received: (qmail 22887 invoked from network); 13 Aug 2003 14:39:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 14:39:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 22783 invoked from network); 13 Aug 2003 14:38:21 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 14:38:21 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0F4166A902; Wed, 13 Aug 2003 17:38:20 +0300 (EEST) Message-ID: <3F3A4CC1.9040209@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lortz, Victor" Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Aug 2003 17:35:45 +0300 Content-Transfer-Encoding: 7bit Lortz, Victor wrote: > John, you and Bernard had the exact same thoughts. He previously suggested making standardization of this data field the subject of a separate RFC to avoid delaying 2284bis. I sent my recent proposals to the EAP list in part to find out if others were interested in collaborating with us on this problem. We also wanted to test the waters a bit to see how acceptable the solutions we were thinking of would be to others on the list. Given that the current draft talks about the NUL character and the undefined data after it, looks like we have everything we need for the placeholder part in RFC 2284bis. Therefore, a future draft could specify what the undefined data exactly is, and use as much time as is needed to discuss XML vs. OIDs vs. ASCII and backwards compatibility with current practise. Personally, I like Victor's idea of a namespace separator. Another possibility is simply allowing a vendor specific attribute (no need for all the expressive power of XML). Say, vendor:5:foo where "vendor" is the keyword that starts a VSA, "5" is the enterprise number of the vendor, and "foo" is the real attribute name. Again, existing implementations would probably think of "vendor:5:foo" as an unidentified attribute. (Do the existing implementations consider ":" as a possible character in an attribute name?) Anyway, I'm hoping we are not starting to employ EAP for all sorts of parameter passing, as Bernard has pointed out there are indeed some MTU issues. Lets be strict on what makes sense to carry over EAP. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 13 11:12:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22877 for ; Wed, 13 Aug 2003 11:12:04 -0400 (EDT) Received: (qmail 23769 invoked from network); 13 Aug 2003 15:12:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 15:12:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 23747 invoked from network); 13 Aug 2003 15:11:38 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 15:11:38 -0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7DFBaB12384 for ; Wed, 13 Aug 2003 18:11:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 13 Aug 2003 18:11:36 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 18:11:36 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 18:11:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Checkcode in EAP SIM and EAP AKA Thread-Index: AcNhrS/ZMlFisaegT2er7nl4LL0SSw== From: To: X-OriginalArrivalTime: 13 Aug 2003 15:11:35.0823 (UTC) FILETIME=[2FF381F0:01C361AD] Subject: [eap] Checkcode in EAP SIM and EAP AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Aug 2003 18:11:35 +0300 Content-Transfer-Encoding: quoted-printable Hi All, The latest versions of EAP SIM and EAP AKA=20 (draft-haverinen-pppext-eap-sim-11.txt and = draft-arkko-pppext-eap-aka-10.txt) include a new optional attribute AT_CHECKCODE which can be used for the integrity protection of the very first messages (Start messages in EAP = SIM and=20 AKA-Identity messages in EAP AKA). The message authentication code attribute AT_MAC cannot be used in these messages because keys are not available yet. The checkcode attribute does not break compatibility = because=20 it is a so-called skippable attribute.=20 The purpose of this attribute is mainly to protect any future extensions = to the very first messages. Currently all the relevant fields in these = messages are protected by including them in key derivation. A good example of a future extension is version negotiation attributes to EAP AKA.=20 Protected version negotiation is already included in EAP SIM. However, we have received requests not to include AT_CHECKCODE in the next versions of EAP SIM, because there does not seem to be any realistic extensions to the first messages in prospect. The version=20 negotiation feature already allows for extensions because the version=20 number can be incremented if the Start messages need to=20 be extended. Hence, in the next draft revision, we are going to remove=20 the specification of AT_CHECKCODE from EAP SIM and at the same time forbid any extensions to the Start messages in protocol version 0x01. AT_CHECKCODE will still be included in EAP AKA. This does not change technical compatibility.=20 Different versions of EAP SIM and EAP AKA documents have been=20 technically compatible as of draft-haverinen-pppext-eap-sim-06.txt and=20 draft-arkko-pppext-eap-aka-05.txt. Regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 13 11:25:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23119 for ; Wed, 13 Aug 2003 11:25:04 -0400 (EDT) Received: (qmail 24353 invoked from network); 13 Aug 2003 15:25:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 13 Aug 2003 15:25:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 24322 invoked from network); 13 Aug 2003 15:24:54 -0000 Received: from fmr05.intel.com (HELO hermes.jf.intel.com) (134.134.136.6) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 13 Aug 2003 15:24:54 -0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7DFMJX26000 for ; Wed, 13 Aug 2003 15:22:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7DEl2G26613 for ; Wed, 13 Aug 2003 14:47:02 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081308242428870 for ; Wed, 13 Aug 2003 08:24:24 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Aug 2003 08:24:24 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Message-ID: Thread-Topic: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request Thread-Index: AcNhqJB++1nxJLqMTSSZZo8FRQrQ/QABASnQ From: "Lortz, Victor" To: X-OriginalArrivalTime: 13 Aug 2003 15:24:24.0494 (UTC) FILETIME=[FA1D64E0:01C361AE] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Aug 2003 08:24:23 -0700 Content-Transfer-Encoding: quoted-printable Given that the current draft talks about the NUL character and the undefined data after it, looks like we have everything we need for the placeholder part in RFC 2284bis. Therefore, a future draft could specify what the undefined data exactly is, and use as much time as is needed to discuss XML vs. OIDs vs. ASCII and backwards compatibility with current practise. We intend to actively work on this problem. If anyone is = interested, please contact me or Farid (Farid.Adrangi@intel.com) Personally, I like Victor's idea of a namespace separator. Another possibility is simply allowing a vendor specific attribute (no need for all the expressive power of XML). Say, vendor:5:foo where "vendor" is the keyword that starts a VSA, "5" is the enterprise number of the vendor, and "foo" is the real attribute name. Again, existing implementations would probably think of "vendor:5:foo" as an unidentified attribute. (Do the existing implementations consider ":" as a possible character in an attribute name?) The namespace separator is equivalent to your vendor:5:foo = proposal, except that it can be more efficient space-wise at the cost of = slightly more complex processing. The name entropy needed to prevent = collisions can be put in one place in the prefix definition rather than = being repeated for every vendor-specific attribute (i.e., = eapns:v=3Durn:vendor.com:net-info:1, v:foo=3Dsome value, v:bar=3Dsome = other value). If "vendor:5" is unique, then this example becomes: = eapns:v=3Dvendor:5, v:foo=3Dsome value, v:bar=3Dsome other value. Once = you get beyond two or three custom attributes, the namespace notation = begins saving space. Anyway, I'm hoping we are not starting to employ EAP for all sorts of parameter passing, as Bernard has pointed out there are indeed some MTU issues. Lets be strict on what makes sense to carry over EAP. Agreed. The MTU limit is real, and we need to be conservative = about what information would be appropriate for this particular EAP = channel. The lack of security for this message also limits what one = might consider putting in the message. I see this as one piece in a = network bootstrapping problem, and it should not be used to solve every = network discovery problem but rather work in complementary fashion with = other mechanisms. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 05:51:13 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04628 for ; Thu, 14 Aug 2003 05:51:03 -0400 (EDT) Received: (qmail 9500 invoked from network); 14 Aug 2003 09:51:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 09:51:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 9479 invoked from network); 14 Aug 2003 09:50:49 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 09:50:49 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6B29C6A902; Thu, 14 Aug 2003 12:50:48 +0300 (EEST) Message-ID: <3F3B5ADD.5040501@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Jari Arkko , Pasi.Eronen@nokia.com, John Vollbrecht , Nick Petroni , "Adrangi, Farid" , Henrik Levkowetz , Uri Blumenthal Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] WG summary; action items Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 12:48:13 +0300 Content-Transfer-Encoding: 7bit Hello folks, This is a summary of the meeting in Vienna, including major decisions (detailed issues discussions are in the minutes), and action items. If you are on the "To:" field of this e-mail, you have a marked action item. If so, check what it is, and let us know if you think the marked completion dates are achievable. Other comments on the summary are welcome as well, particularly if we have missed something that needs to get done. DECISIONS D1) State machine document (draft-vollbrecht-eap-state-04.txt) will become a WG document in its next revision. D2) Two issues identified in RFC 2869bis (draft-aboba-radius-rfc2869bis-22.txt) after its IESG approval will be discussed on the list and resolved. ACTION ITEMS A1) Close open 2284bis issues, post new draft (Henrik L, Aug 30th -- Ongoing) A2) Third and final WG last call on 2284bis (chairs, Aug 30th) A3) Submit version 07 of the keying framework draft (Bernard A, Aug 10 -- Done) A4) Progress discussion on keying framework and Russ' requirements (Bernard A, Russ H, Aug 30 -- Ongoing) A5) Find reviewers for keying framework (chairs, Aug 30 -- Ongoing). A6) Produce a new version of the state machine without overspecifying the AAA parts (Pasi E, Nick P, John V, Aug 20) A7) Discuss and work off-line to determine what 3GPP requirements for network selection are and where they fits in IETF protocols (Jari A, Farid A, Aug 20 -- Ongoing) A8) Propose additional security property claims for 2284bis which can be used to describe method security more accurately than is possible today (Uri B, Aug 20) A9) Ensure that IKEv2 EAP MitM attack with non-kg method issue is registed in IPsec WGs issue tracker (Jari A, Aug 5 -- Done) A10) Ensure that IKEv2 binding solution agrees with the binding draft proposals (Bernard A, Aug 20 -- Ongoing) A11) Try to initiate interest to review and complete the compound authentication draft by talking to several WG members and outside experts (chairs, Aug 20 -- Ongoing) A12) Architectural discussion of the usage of EAP in DHCP and other applications (chairs, ADs?) CHARTER REVIEW In terms of charter modifications, we only need some minor touch ups at this time, and adjustment of milestones. RFC 2284bis has completed its second EAP WG last call, and is currently in the process of resolving last call comments. Goals and Milestones: Sep 03 RFC 2284bis submitted for publication as a Proposed Standard Dec 03 EAP Keying Framework document submitted for publication as an Informational RFC Dec 03 EAP State Machine document submitted for publication as an Informational RFC Dec 03 EAP compound binding document submitted for publication as an Informational RFC. Note that there are currently a number of documents related to EAP but which are not within the charter. However, it has earlier been agreed that the base EAP documents will be completed before methods work can be chartered (and some of methods work might be Informational even then). TEXTUAL SUMMARY The EAP working group is close to finishing the revised EAP base specification (2284bis). Three issues remain which can be classified as small, and one additional issue can perhaps be treated as new work. We will issue one final WG last call on the document once these issue have been resolved. Related to the work of EAP WG, the RADIUS EAP specification (2869bis) has been approved by the IESG. Since then, however, two inconsistencies have been detected between IEEE and IETF specifications, and these are intended to be corrected in AUTH48. They are also discussed in the IEEE 802 plenary this week. Similar to 2869bis, a new version of the DIAMETER EAP specification has been produced in the AAA working group. This is a rather exact copy of 2869bis, but adds a proxy-free operation mode and key transport AVPs. Significant progress has been made in EAP WG with respect to two individual drafts, the EAP state machine and EAP keying framework. The intention is to take adopt these as WG items now that work on 2284bis is slowing down. However, these drafts are not complete yet and have some risks associated with them: 1. The keying draft now addresses Russ' requirements for keying -- but there are two or three requirements which we have not fulfilled yet and which can also be troublesome on IEEE link layers. The hardest problems appear to be authorization of AAA nodes, and the naming of "phase 1" and "phase 2" security assoications. The latter issue may require changes to the current IEEE 802.11i protocol proposals. 2. The state machine model has ventured too far into the domain of AAA in its attempt to represent EAP passthrough nodes. This has also impacted IEEE, which has replaced its fully-fledged AAA layer with an EAP-only AAA layer. This needs to be corrected. (Otherwise the state machine is relatively stable.) The state machine will become a WG item in its next version. The intention is also for the keying framework to do the same, but for this we will wait with the question to the WG until 07 is posted to the directories. Farid Adrangi presented a request from 3GPP to provide for network selection functionality in EAP. After discussion it was not clear that there was an agreement on whether this functionality should be a part of EAP. Off-line discussion with the involved folks needs to be initiated in order to ensure that 3GPP is sent to the right direction, and that their requirements get fulfilled. Currently, it is unclear what that right direction is. Uri Blumental presented a security analysis of EAP SIM, the GSM version of SIM card authentication in EAP. There are two issues relating to the claim of 128 bit security which reduces to 64 bits due to problems, and one issue about independence of individual authentications in EAP SIM. Draft authors have adopted proposed solutions to the 64 bit security problem. However, the session independence property can not be achieved using GSM authentication, while its available in some other methods (e.g. UMTS authentication or EAP TLS). From the point of the EAP WG, a minimal requirement is that the security properties of methods are described correctly and accurately. This may require some improvements in the current 2284bis requirements for methods to describe their security properties. Jose Puthenkulam's work on compound authentication man-in-the-middle attacks has progressed by adopting comments from the list, and a new draft revision exists. Several IETF protocols, including IKEv2 are employing techniques to prevent these attacks, and further work on EAP tunneling proposals is also waiting the results of this work. From the point of view of producing secure protocols, it is essential to complete this work item before, for instance, IKEv2 appears as an RFC. The authors of the draft are willing to complete it, earlier reviewers have to first verify that their comments have been properly addressed. Related to the above attacks, the chairs have suggested on the IPsec mailing list that IKEv2 be changed to allow only key-generating methods. This would make it possible to prevent man-in-the-middle attacks while still using key-generating versions of the existing methods. The used RADIUS servers would have to be updated, but existing credentials could be kept. Discussion on this is still going on. Several folks proposed the use of EAP in non-access and non-IKEv2 context. These proposals ranged from the use of EAP to bootstrap DHCP security to general-purpose application-specific key generation. This is an architectural issue where the IETF needs to take a standpoint of what is the right direction for this work. The use of EAP and different EAP methods to secure access is normally acceptable, given the different kinds of access networks, deployment of widely different access credentials (passwords, token cards, SIM cards etc). However, the use of EAP in a wide variety of application level protocols may not be desireable, given its inefficiency when running large amounts of data (such as certificate chains) over IP, and the potential for interoperability problems. Perhaps it would be better to provide a limited set of authentication methods at the application layer, and allow bootstrapping of those methods from EAP where necessary. However, this would require continuing with PIC, whereas currently most people's energy appears to be concentrated on making IKEv2 work with EAP. Also, a number of new methods (EAP Archie, EAP LDAP, EAP IKEv2, PEAPv2, EAP smartcard) were presented. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 06:26:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05457 for ; Thu, 14 Aug 2003 06:26:01 -0400 (EDT) Received: (qmail 10371 invoked from network); 14 Aug 2003 10:26:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 10:26:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 10346 invoked from network); 14 Aug 2003 10:25:50 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 10:25:50 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6A56C6A902; Thu, 14 Aug 2003 13:25:49 +0300 (EEST) Message-ID: <3F3B6312.8070008@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] keying framework draft as a wg item? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 13:23:14 +0300 Content-Transfer-Encoding: 7bit Folks, Bernard has submitted version 07 of the keying framework draft to the I-D directories: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt Currently, this draft is an individual draft. The issues addressed in the draft are, however, essential for understanding the security properties of EAP-based systems, and have also impacts in link-layers and in AAA. It has been suggested that this draft be adopted as a WG item. Keying issues are already in the WG's charter. We know there is work left in the draft, but version 07 is starting to approach the desired goal, for instance by addressing most of the requirements outlined by Russ. We would now like to confirm with the working group that the draft should be moved forward as a WG item (Informational track), when its next version appears. Any objections? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 07:40:17 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06999 for ; Thu, 14 Aug 2003 07:40:15 -0400 (EDT) Received: (qmail 12124 invoked from network); 14 Aug 2003 11:40:12 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 11:40:12 -0000 Delivered-To: eap@frascone.com Received: (qmail 12086 invoked from network); 14 Aug 2003 11:39:02 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 11:39:02 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BCF066A902; Thu, 14 Aug 2003 14:39:01 +0300 (EEST) Message-ID: <3F3B743A.8080104@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Discussion of Issue 152: Lower layer indications References: <3F38D313.9060105@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 14:36:26 +0300 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I've suggested text for Issue 152... Is this enough? The current proposed text is OK. THanks. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 08:40:16 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08047 for ; Thu, 14 Aug 2003 08:40:05 -0400 (EDT) Received: (qmail 13342 invoked from network); 14 Aug 2003 12:40:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 12:40:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 13295 invoked from network); 14 Aug 2003 12:39:36 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 12:39:36 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7ECdY422161 for ; Thu, 14 Aug 2003 15:39:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Aug 2003 15:39:34 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 14 Aug 2003 15:39:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 14 Aug 2003 15:39:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C9@esebe023.ntc.nokia.com> Thread-Topic: Some ideas for keying framework Thread-Index: AcNiYRyBzhbG4T8gQS2CcGq0UmZmrA== From: To: , Cc: X-OriginalArrivalTime: 14 Aug 2003 12:39:33.0381 (UTC) FILETIME=[1CF71350:01C36261] Subject: [eap] Some ideas for keying framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 15:39:32 +0300 Content-Transfer-Encoding: quoted-printable Hi, EAP and 802.11i has been compared with IKE Phase 1 and 2, and this lead me to think that maybe a comparing it to a=20 protocol that actually has three parties could add some=20 value...=20 So, here's my attempt to interpret the combination of EAP=20 (with Archie-like shared-secret based EAP method), 802.11i,=20 and Diameter EAP as a Kerberos-like three-party protocol. The message sequence below shows a typical exchange, with each message described using ideas from Kerberos.=20 Surprisingly, the two match quite well, and the parts that don't match illustrate the (already known) weak parts. Also, the=20 interpretation seems to suggest that some parts don't actually=20 provide much additional security. The general idea is to think that the AAA server combines the functionality of the Kerberos Authentication Service (AS) and=20 Ticket Granting Service (TGS). Below there is no separate Ticket=20 Granting Ticket (TGT); an EAP method that stores something for fast reauthentication might be considered similar to TGT. For a basic shared-secret protocol presented below that isn't necessary (it probably wouldn't reduce roundtrips). (Notation: C=3DClient, S=3DAAA server, and W=3DWLAN access point. 0: C-->S: Hello!=20 =20 (This is transmitted as 802.11 association request and=20 Diameter EAP-Start. Since the NAS does not really=20 do anything except route these messages, I'm leaving protocol layers and fields used only for routing=20 (802 stuff and Diameter) out. After all, we don't=20 usually show IP routers and Ethernet headers when=20 describing Kerberos either.) =20 1: C<--S: Hello. Who are you? (EAP Identity Request.) 2: C-->S: I'm C=3D"joe@example.com" (EAP Identity Response.) 3: C<--S: Prove that you know the shared secret (K_S-C).=20 (This corresponds to some Archie-like EAP method based on a shared secret. The details of the EAP method =20 are not important for this exercise. I'm assuming the EAP method is "good enough" so that an attacker who does not know K_S-C can't modify these messages without detection, or replay them later.)=20 4: C-->S: Here's proof. Could you prove that you know K_S-C too? 5: C<--S: Here's my proof. 6: C-->S: Ok, I'm convinced that you really are the AAA server. Could you give me a ticket for accessing WLAN AP W=3D"11:22:33:44:55:66"? My MAC address is=20 C'=3D"99.88:77:66:55:44". Actually, send the ticket=20 directly to W so I don't have to. (This is nothing else than the "binding" field in EAP Archie, though in Archie this is already in message #4.)=20 7: C<--S: Ok, I have sent the ticket. You can calculate the=20 session key from our shared secret and the messages=20 exchanged here.=20 (This is just an unusual way of considering the EAP Success packet) 8: S-->W: Here's a ticket for you. The ticket contains: - C in User-Name AVP - W implicitly in earlier message's Called-Station-Id AVP - C' implicitly in earlier message's Calling-Station-Id AVP - W' in Destination-Host AVP - session key (MSK) - expiration time in Authorization-Lifetime AVP (This corresponds to Access-Accept or successful=20 Diameter-EAP-Answer message. I'm assuming the access=20 point and AAA server communicate directly, without any Diameter proxies. The ticket is encrypted and integrity protected with=20 K_S-W', where W'=3D"ap1234.example.com", using TLS or=20 IPsec. More about this below.=20 In Kerberos, the ticket would contain only C and W--the=20 optional "caddr" field does not provide any security against attackers who control all network links. Also, the validity start time is not needed because ticket replay is prevented by other means.) 9: C<--W: Hi C', this is W. I got your ticket.=20 I support these ciphers: (list) (This corresponds to beacon message and 1st message of four-way handshake. I'm assuming that this and the next two messages contain appropriate protection =20 so that an attacker who does not know MSK/PMK can't modify them without detection, or replay them later.) 10: C-->W: I'd like to use (selected cipher). 11: C<--W: Ok. Reset replay protection counters and derive=20 a fresh encryption/MAC keys using PMK and various nonces from these messages. 12: C-->W: Ok. In Kerberos, C=3D=3DC' and W=3D=3DW'. After some handshake maybe a bit=20 like 9..12 (perhaps not even needed if ciphers are not negotiated),=20 W can know that=20 - Data MAC'd with these keys came from C. - When sending data to C, only C can read (decrypt) it (And vice versa for C.) The crucial difference in EAP/802.11i/Diameter case seems to be=20 that C !=3D C' and W !=3D W'. IEEE 802.11i-D5 says something related to this: "The protocol [4-way handshake] also assumes that the=20 AS delivers the correct PMK to the AP with IEEE 802 address AA,=20 and that the non-AP STA with IEEE 802 address AP hosts the=20 Supplicant that negotiated the PMK with the AS."=20 It continues that "None of the protocols defined by IEEE 802.11 and IEEE 802.1X permit the AS, the Authenticator, the Supplicant, or either STA to verify these assumptions." I guess the assumption here is that these would be handled by EAP and Diameter/RADIUS, but it seems that this is not usually the case! When sending the encrypted ticket (message #8), a Kerberos server would look up the key based on W. Here, W' simply claims that "I'm actually W too" (in Diameter-EAP-Request), and the server believes whatever W' says. Similarly, in message #6, C says that "I'm actually C' too", and the server believes whatever C says. Thus, it seems that an honest access point W can know that: - Data MAC'd with these keys came from C. - When sending data to C', only C can read it (Unfortunately, we don't know that C and C' are=20 the same entity; C certainly claims so, but that is all.) And an honest user C can know that: - Data MAC'd with these came from W'.=20 (But C does not even know who W' is. C knows that W' claims it's the same entity as W, and W' is a valid access point according to S.) - When sending data to W, only W' can decrypt it. I guess my conclusions from this is that the current=20 combination of EAP, 802.11i and Diameter/RADIUS does not=20 provide the properties traditionally expected of protocols=20 for setting up a secure channel between two parties. It can protect against non-authenticated users, and it can protect the integrity of volume-based charging. However, it=20 does not protect the integrity and confidentiality of user=20 traffic from other authenticated users in the same WLAN.=20 Also, a compromised access point can "hijack" traffic even=20 when the user tries to access some non-compromised access=20 point. (BTW, a colleague more familiar with 802.11 and 3GPP said=20 that this conclusion is nothing new and is widely known,=20 at least in some circles. Even if it is, it's certainly important to mention it in some security considerations!) Another interesting point is that several parts of the=20 protocols don't appear to provide any additional security,=20 at least if we assume an attacker who controls all communication=20 links. For instance, the EAP messages are encrypted and=20 integrity-protected between the NAS and the AAA server,=20 but it seems that this is not necessary. Similarly, it seems that the MAC address "binding" in EAP Archie=20 does not prevent any attacks unless S can verify that W and W' correspond to the same entity. It does allow more reliable auditing at S, though, so tracing any attacks might be easier (so having the "bindings" is better than not having them, certainly). Ok, I have to admit that many details are omitted here, and=20 I'm not that familiar with Kerberos. The description intentionally=20 ties the "three legs" together, since I don't think that any of=20 them is actually totally independent of the others. For instance,=20 Archie's "ticket request field" (called "binding" in Archie)=20 certainly isn't totally "media independent". Maybe this provides some ideas for the EAP keying framework document? Or some as-yet-nonexistant document to document the "system security considerations"? Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 09:41:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09483 for ; Thu, 14 Aug 2003 09:41:05 -0400 (EDT) Received: (qmail 15234 invoked from network); 14 Aug 2003 13:41:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 13:41:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 15213 invoked from network); 14 Aug 2003 13:40:07 -0000 Received: from fmr05.intel.com (HELO hermes.jf.intel.com) (134.134.136.6) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 13:40:07 -0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7EDbVm10057 for ; Thu, 14 Aug 2003 13:37:31 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7ED2AQ27367 for ; Thu, 14 Aug 2003 13:02:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081406393727753 ; Thu, 14 Aug 2003 06:39:37 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Aug 2003 06:39:37 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] keying framework draft as a wg item? Message-ID: Thread-Topic: [eap] keying framework draft as a wg item? Thread-Index: AcNiTpIbIndy1JhUSGObKI3tiLGVPAAGuUHg From: "Walker, Jesse" To: , Cc: "Bernard Aboba" X-OriginalArrivalTime: 14 Aug 2003 13:39:37.0281 (UTC) FILETIME=[810E9310:01C36269] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 06:39:36 -0700 Content-Transfer-Encoding: quoted-printable Jari, This should be made a work item. -- Jesse > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, August 14, 2003 3:23 AM > To: eap@frascone.com > Cc: Bernard Aboba > Subject: [eap] keying framework draft as a wg item? >=20 >=20 >=20 > Folks, >=20 > Bernard has submitted version 07 of the keying framework > draft to the I-D directories: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-pro blem-07.txt Currently, this draft is an individual draft. The issues addressed in the draft are, however, essential for understanding the security = properties of EAP-based systems, and have also impacts in link-layers and in AAA. It has been suggested that this draft be adopted as a WG item. Keying issues are already in the WG's charter. We know there is work left in the draft, but version 07 is starting to approach the desired goal, for instance by addressing most of the requirements outlined by Russ. We would now like to confirm with the working group that the draft should be moved forward as a WG item (Informational track), when its next version appears. Any objections? --Jari _______________________________________________ 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 eap-admin@frascone.com Thu Aug 14 10:43:28 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12784 for ; Thu, 14 Aug 2003 10:43:11 -0400 (EDT) Received: (qmail 16800 invoked from network); 14 Aug 2003 14:43:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 14:43:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 16779 invoked from network); 14 Aug 2003 14:42:16 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 14:42:16 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7EECNO03032; Thu, 14 Aug 2003 07:12:23 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: eap@frascone.com In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222C9@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A61222C9@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: Some ideas for keying framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 07:12:23 -0700 (PDT) Thanks for your comments, Pasi. I think that it is useful to go through an EAP conversation step-by-step to understand the security properties. Comments below. > 0: C-->S: Hello! I think this would correspond to a non-EAP packet, such as the 802.1X EAPOL-Start. This packet is typically unprotected, because it is lower-layer packet. > 1: C<--S: Hello. Who are you? This is the first EAP-Request, typically an Identity, but could be the first method packet. This is unprotected because there is no key yet negotiated between the parties, not just because this is EAP. > 2: C-->S: I'm C="joe@example.com" > > (EAP Identity Response.) This packet is also unprotected. Its function may be duplicated by subsequent method packets (should a protected identity exchange be a requirement?), in which case it is only used for routing and a forgery can be subsequently detected. > 3: C<--S: Prove that you know the shared secret (K_S-C). > 4: C-->S: Here's proof. Could you prove that you know K_S-C too? > 5: C<--S: Here's my proof. > 6: C-->S: Ok, I'm convinced that you really are the AAA server. > Could you give me a ticket for accessing WLAN AP > W="11:22:33:44:55:66"? My MAC address is > C'="99.88:77:66:55:44". Actually, send the ticket > directly to W so I don't have to. In this particular method, a ticket is requested to a particular AP port and is bound to a particular port on the peer, within EAP. The issue that arises is if the peer wants to subsequently bypass EAP authentication in a fast handoff to another AP. Its ticket (and underlying MSK/EMSK) should not be good to access another AP, since it has already been bound to specific ports. That is I think one of the arguments for the "late binding" of the 4-way handshake. > 7: C<--S: Ok, I have sent the ticket. You can calculate the > session key from our shared secret and the messages > exchanged here. I think we've come to understand that the statement is more like: "I have given you keying material (MSK, EMSK) and you will subsequently be told how to use this material to construct the AAA-Key for this and subsequent APs." The 4-way handshake could include an algorithm negotiation that could indicate a key name and algorithm used to calculate the appropriate AAA-Key. As an example, the default is currently that the AAA-Key=MSK, but in fast-handoff that is not necessarily the case. Again, I think we have a case of "late binding" here. > 8: S-->W: Here's a ticket for you. The ticket contains: Yes, I buy the idea that the AAA message is effectively a ticket, which is why we call it the AAA-Token. Note that the AAA-Key is not always the MSK; the NAS/AP just takes it for granted, but it needs the key name/algorithm to use in the subsequent secure association exchange in order to make sure it is in sync with the peer. > - C in User-Name AVP > - W implicitly in earlier message's Called-Station-Id AVP > - C' implicitly in earlier message's Calling-Station-Id AVP > - W' in Destination-Host AVP > - session key (MSK) > - expiration time in Authorization-Lifetime AVP Does it make a differernce that W and C' are implicit rather than explicit? I've wondered whether we shouldn't be including these in the Accept packet. The "expiration time" is the maximum time that the "ticket" can be cached, no? Essentially I think we are saying that the keying material and the authorizations expire at the same time. However, this is somewhat contradictory, since an "authorization only" exchange cannot refresh keying material (since there is no re-authentication exchange to go with it). That's one reason why the Authorization-Lifetime AVP has never made much sense to me. 8.5 C-->W: Hi, I have the following list of keys I can use. In 802.11i D5 the client includes a list of PMKIDs that the AP can select from. We also have been discussing whether the client needs to get a list of algorithms before this so that it can winnow the potentially acceptable PMKIDs. > 9: C<--W: Hi C', this is W. I got your ticket. In D5 this message is also used by the AP to select a PMKID (and algorithm?) to use in the exchange. > 10: C-->W: I'd like to use (selected cipher). > 11: C<--W: Ok. Reset replay protection counters and derive > a fresh encryption/MAC keys using PMK and various > nonces from these messages. > > 12: C-->W: Ok. > The crucial difference in EAP/802.11i/Diameter case seems to be > that C != C' and W != W'. IEEE 802.11i-D5 says something related > to this: "The protocol [4-way handshake] also assumes that the > AS delivers the correct PMK to the AP with IEEE 802 address AA, > and that the non-AP STA with IEEE 802 address AP hosts the > Supplicant that negotiated the PMK with the AS." As noted in RFC 3579, it is possible for the AS to do some checking of the NAS-Identifier, and NAS-IP-Address. It can also check the Called-Station-Id in the Access-Request against the known L2 addresses of the NAS identified by the NAS Identification attributes. However, it cannot know whether the AP identified itself to the STA with the claimed Called-Station-Id or whether it used another address in the BSSID instead, unless it verifies this in the EAP exchange (as Archie does). It also can't know if the AP is lying about the client Calling-Station-Id, unless it verifies this within the EAP exchange (as Archie does). These impersonation issues are discussed in RFC 3579, and are in the keying framework doc to some extent as well. > It continues that "None of the protocols defined by IEEE 802.11 and > IEEE 802.1X permit the AS, the Authenticator, the Supplicant, or > either STA to verify these assumptions." I guess the assumption here > is that these would be handled by EAP and Diameter/RADIUS, but > it seems that this is not usually the case! As described in RFC 3579, AAA has limited capabilities of detecting impersonation. Some of this can be done in EAP as in Archie. > When sending the encrypted ticket (message #8), a Kerberos server > would look up the key based on W. Here, W' simply claims that "I'm > actually W too" (in Diameter-EAP-Request), and the server believes > whatever W' says. Similarly, in message #6, C says that "I'm actually > C' too", and the server believes whatever C says. The AS has the ability to check the W' - W binding and also the C' - C binding if it wants to. For example, it could only allow the user to access the network from a particular Calling-Station-Id or could check the Called-Station-Id against the NAS identification attributes. > Thus, it seems that an honest access point W can know that: > > - Data MAC'd with these keys came from C. > - When sending data to C', only C can read it > (Unfortunately, we don't know that C and C' are > the same entity; C certainly claims so, but that is all.) One question is when the C - C' binding occurs. For example, can a STA complete an EAP exchange on one port and then do a 4-way handshake on another port using the keying material derived in the first exchange? This would require "late binding". > And an honest user C can know that: > > - Data MAC'd with these came from W'. > (But C does not even know who W' is. C knows that W' claims > it's the same entity as W, and W' is a valid access > point according to S.) > - When sending data to W, only W' can decrypt it. > > I guess my conclusions from this is that the current > combination of EAP, 802.11i and Diameter/RADIUS does not > provide the properties traditionally expected of protocols > for setting up a secure channel between two parties. I think that the issue here is the W-W' binding from C's point of view. Wouldn't something like secure neighbor discovery (with an inverse option) address this? > It can protect against non-authenticated users, and it can > protect the integrity of volume-based charging. However, it > does not protect the integrity and confidentiality of user > traffic from other authenticated users in the same WLAN. Yes, because the security is not end-to-end. > Also, a compromised access point can "hijack" traffic even > when the user tries to access some non-compromised access > point. The compromised AP can masquerade as another AP by stealing its BSSID, for example. It can then lie about the BSSID it is using by including a different address in the Called-Station-Id. The AS will not be the wiser. I think this implies that the architecture trusts the AP to a certain extent, but we need to be very clear about exactly what that trust extends to. A compromised AP can do a lot of things. For example, if several APs are plugged into a hub, a compromised AP can actually see cleartext traffic from other APs, equivalent to obtaining the sessions keys of all STAs attached to those other APs! > (BTW, a colleague more familiar with 802.11 and 3GPP said > that this conclusion is nothing new and is widely known, > at least in some circles. Even if it is, it's certainly > important to mention it in some security considerations!) Yes, I would say so. Text solicited ;) > Another interesting point is that several parts of the > protocols don't appear to provide any additional security, > at least if we assume an attacker who controls all communication > links. For instance, the EAP messages are encrypted and > integrity-protected between the NAS and the AAA server, > but it seems that this is not necessary. Sure. EAP protection only adds value between the STA and NAS/AP. > Similarly, it seems that the MAC address "binding" in EAP Archie > does not prevent any attacks unless S can verify that W and W' > correspond to the same entity. Maybe it could do this via secure neighbor discovery? > It does allow more reliable > auditing at S, though, so tracing any attacks might be easier > (so having the "bindings" is better than not having them, > certainly). Yes. > Maybe this provides some ideas for the EAP keying framework > document? Yes, I think it's very helpful for identifying areas which need more explanation. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 14 17:00:13 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26635 for ; Thu, 14 Aug 2003 17:00:11 -0400 (EDT) Received: (qmail 24156 invoked from network); 14 Aug 2003 21:00:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 14 Aug 2003 21:00:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 24112 invoked from network); 14 Aug 2003 20:59:25 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 14 Aug 2003 20:59:25 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7EKTYc24106 for ; Thu, 14 Aug 2003 13:29:34 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 167: Cleartext Passwords in EAP Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 14 Aug 2003 13:29:33 -0700 (PDT) Issue 167: Cleartext Passwords in EAP Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/14/2003 Reference: Document: RFC2284bis Comment type: T Priority: S Section: 5.5, 5.6 Rationale/Explanation of issue: Reading Section 5.5 and 5.6, it is not made crystal clear that the EAP OTP and GTC methods are not intended to provide support for cleartexst passwords. In Section 5.5, add to the end of the "Description" paragraph: "The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords." In Section 5.6, add to the end of the "Description" paragraph: "The EAP GTC method is intended for use with the Token Cards supporting challenge/response authentication and MUST NOT be used to provide support for cleartext passwords." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 15 07:57:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25239 for ; Fri, 15 Aug 2003 07:57:06 -0400 (EDT) Received: (qmail 6794 invoked from network); 15 Aug 2003 11:57:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 11:57:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 6774 invoked from network); 15 Aug 2003 11:56:23 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 11:56:23 -0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7FBuLB01678 for ; Fri, 15 Aug 2003 14:56:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Aug 2003 14:56:19 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 14:56:19 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 14:56:19 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 14:56:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222CA@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 167: Cleartext Passwords in EAP Thread-Index: AcNipyj2t7uatN5RQNKf0waBXLiw1gAepPrg From: To: , X-OriginalArrivalTime: 15 Aug 2003 11:56:19.0158 (UTC) FILETIME=[3D19CF60:01C36324] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 14:56:18 +0300 Content-Transfer-Encoding: quoted-printable Hi, GTC can also be used with PEAP/TTLS to support password databases that store a one-way hash of the password.=20 When used this way, it's not that insecure either (not=20 worse than e.g. SSH). This use is mentioned e.g. in=20 http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf I think it's safe to assume that in the absence of some other solution, people will use GTC for this with IKEv2=20 as well.=20 This is probably not such a bad idea in many cases,=20 since the alternative is to store the password (or=20 password-equivalent) in clear (deploying SRP or=20 something similar doesn't seem realistic any time soon). So, perhaps something like "The EAP GTC method MUST NOT=20 be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication, such as PEAP or IKEv2." would be sufficient? Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, August 14, 2003 11:30 PM > To: eap@frascone.com > Subject: [eap] Issue 167: Cleartext Passwords in EAP >=20 >=20 > Issue 167: Cleartext Passwords in EAP > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/14/2003 > Reference: > Document: RFC2284bis > Comment type: T > Priority: S > Section: 5.5, 5.6 > Rationale/Explanation of issue: >=20 > Reading Section 5.5 and 5.6, it is not made crystal clear=20 > that the EAP OTP and GTC methods are not intended to provide=20 > support for cleartexst passwords. >=20 > In Section 5.5, add to the end of the "Description" paragraph: >=20 > "The EAP OTP method is intended for use with the One-Time=20 > Password system only, and MUST NOT be used to provide support=20 > for cleartext passwords." >=20 > In Section 5.6, add to the end of the "Description" paragraph: >=20 > "The EAP GTC method is intended for use with the Token Cards=20 > supporting challenge/response authentication and MUST NOT be=20 > used to provide support for cleartext passwords." >=20 > _______________________________________________ > 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 eap-admin@frascone.com Fri Aug 15 08:41:21 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25982 for ; Fri, 15 Aug 2003 08:41:03 -0400 (EDT) Received: (qmail 7727 invoked from network); 15 Aug 2003 12:41:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 12:41:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7705 invoked from network); 15 Aug 2003 12:40:57 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 12:40:57 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7FCet414529 for ; Fri, 15 Aug 2003 15:40:56 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Aug 2003 15:40:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 15:40:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 15:40:54 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 15:40:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB97@esebe023.ntc.nokia.com> Thread-Topic: Some ideas for keying framework Thread-Index: AcNickJnCWWMneGJT6axvJhtiDLU3wAj8fyw From: To: Cc: X-OriginalArrivalTime: 15 Aug 2003 12:40:54.0332 (UTC) FILETIME=[77A0F7C0:01C3632A] Subject: [eap] RE: Some ideas for keying framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 15:40:51 +0300 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > Thanks for your comments, Pasi. I think that it is useful to=20 > go through an EAP conversation step-by-step to understand the=20 > security properties. Comments below. >=20 > > 0: C-->S: Hello! >=20 > I think this would correspond to a non-EAP packet, such as the 802.1X > EAPOL-Start. This packet is typically unprotected, because it is > lower-layer packet. Yes. I included this just to show that the protocol is=20 actually initiated by the client. The EAPOL-Start is converted=20 to a RADIUS/Diameter EAP-Start between the access point and S. > > 1: C<--S: Hello. Who are you? >=20 > This is the first EAP-Request, typically an Identity, but could be the > first method packet. This is unprotected because there is no key yet > negotiated between the parties, not just because this is EAP. >=20 > > 2: C-->S: I'm C=3D"joe@example.com" > > > > (EAP Identity Response.) >=20 > This packet is also unprotected. Its function may be duplicated by > subsequent method packets (should a protected identity exchange be a > requirement?), in which case it is only used for routing and=20 > a forgery can be subsequently detected. I guess all mutually authenticating EAP methods have some=20 mechanisms for protecting the identity exchange. After all,=20 if after a successful authentication the user thinks he has=20 authenticated as X and the server thinks the user is Y,=20 the method doesn't provide much authentication. Based on a quick look, at least EAP-TLS, Archie, EAP-SIM and EAP-AKA seem to protect the identity being authenticated (which is not necessarily the same as the contents of the Identity Response). MSCHAPv2 doesn't protect the whole identity, just the username part (not domain). BTW, it seems that no EAP method currently protects the contents=20 of the Identity Request; the assumption probably was that it=20 doesn't contain anything important. Thus, if it includes some data after a NUL, it could be modified by an attacker.=20 I'm not sure if any of the data currently included counts=20 as "important" or not, but it's worth keeping in mind... > > 3: C<--S: Prove that you know the shared secret (K_S-C). > > 4: C-->S: Here's proof. Could you prove that you know K_S-C too? > > 5: C<--S: Here's my proof. > > 6: C-->S: Ok, I'm convinced that you really are the AAA server. > > Could you give me a ticket for accessing WLAN AP > > W=3D"11:22:33:44:55:66"? My MAC address is > > C'=3D"99.88:77:66:55:44". Actually, send the ticket > > directly to W so I don't have to. >=20 > In this particular method, a ticket is requested to a particular=20 > AP port and is bound to a particular port on the peer, within=20 > EAP. The issue that arises is if the peer wants to subsequently=20 > bypass EAP authentication in a fast handoff to another AP. Its=20 > ticket (and underlying MSK/EMSK) should not be good to access=20 > another AP, since it has already been bound to specific ports. =20 > That is I think one of the arguments for the "late binding" of=20 > the 4-way handshake. I think that to protect against compromised NASes, the MAC addresses have to be taken into account ("bound") in the=20 AAA-Key(s) contained in the ticket(s) sent from AAA server to=20 access point(s). Doing it in the 4-way handshake phase is=20 probably too late. EAP Archie does this by including the MAC addresses explicitly=20 in the messages. Another possibility would be that when the AAA=20 server sends the ticket(s), it calculates the key to be included=20 as f(EMSK,AP_MAC,STA_MAC). The proactive key distribution proposal=20 by Mishra et al. did something like this, if I recall correctly. BTW, it just occured to me that actually the MAC addresses=20 (C' and W) are always sent in this message, even in EAP methods other than Archie (they're in the EAPOL headers and Diameter AVPs). Archie is just the only one that includes them when calculating the MACs! > > 7: C<--S: Ok, I have sent the ticket. You can calculate the > > session key from our shared secret and the messages > > exchanged here. >=20 > I think we've come to understand that the statement is more like: >=20 > "I have given you keying material (MSK, EMSK) and you will=20 > subsequently be told how to use this material to construct=20 > the AAA-Key for this and subsequent APs." Is any subsequent information actually necessary? If the=20 PMK is derived e.g. as f(EMSK,AP_MAC,STA_MAC), the client=20 already has all the necessary information to construct it=20 for any access point. > The 4-way handshake could include an algorithm negotiation > that could indicate a key name and algorithm used to calculate > the appropriate AAA-Key. As an example, the default is > currently that the AAA-Key=3DMSK, but in fast-handoff that is not > necessarily the case. Again, I think we have a case of "late=20 > binding" here. >=20 > > 8: S-->W: Here's a ticket for you. The ticket contains: >=20 > Yes, I buy the idea that the AAA message is effectively a=20 > ticket, which is why we call it the AAA-Token. Note that the AAA-Key=20 > is not always the MSK; the NAS/AP just takes it for granted, but it=20 > needs the key name/algorithm to use in the subsequent secure=20 > association exchange in order to make sure it is in sync with the = peer. >=20 > > - C in User-Name AVP > > - W implicitly in earlier message's Called-Station-Id AVP > > - C' implicitly in earlier message's Calling-Station-Id AVP > > - W' in Destination-Host AVP > > - session key (MSK) > > - expiration time in Authorization-Lifetime AVP >=20 > Does it make a differernce that W and C' are implicit rather=20 > than explicit? I've wondered whether we shouldn't be including=20 > these in the Accept packet. I think the implicit inclusion works here. If we choose to do=20 proactive key distribution (initiated by the AAA server), then that message has to include them explicitly. > The "expiration time" is the maximum time that the "ticket"=20 > can be cached, no? Essentially I think we are saying that the keying=20 > material and the authorizations expire at the same time. However,=20 > this is somewhat contradictory, since an "authorization only"=20 > exchange cannot refresh keying material (since there is no=20 > re-authentication exchange to go with it). That's one reason=20 > why the Authorization-Lifetime AVP has never made much sense to me. I checked what the specs actually say about Authorization-Lifetime=20 and Session-Timeout, and I think that the Base text makes sense. But the text in NASREQ is confusing and contradicts Base in some cases. (I'll send something about this to the AAA list in a separate message; in the following I'll assume Base is=20 correct, since it makes more sense.) Deriving a new AAA-Key (=3D=3DPMK in 802.11i) for an access point=20 requires a new EAP conversation, right? (This may be a "fast"=20 reauth if the EAP method supports it) This could be done=20 with Authorization-Lifetime + Re-Auth-Request-Type set to AUTHORIZE_AUTHENTICATE. On the other hand, re-checking the authorization ("is this=20 user's account still ok?") makes sense without deriving=20 a new key. This could be done with Authorization-Lifetime=20 AVP + Re-Auth-Request-Type AVP set to AUTHORIZE_ONLY. > 8.5 C-->W: Hi, I have the following list of keys I can use. >=20 > In 802.11i D5 the client includes a list of PMKIDs that the=20 > AP can select from. We also have been discussing whether the=20 > client needs to get a list of algorithms before this so that it=20 > can winnow the potentially acceptable PMKIDs. >=20 > > 9: C<--W: Hi C', this is W. I got your ticket. >=20 > In D5 this message is also used by the AP to select a PMKID (and > algorithm?) to use in the exchange. Thanks for pointing out this change. I hadn't noticed it because=20 it's not included in Section 8.5.3.1 (which says Key Data field=20 of the first msesage is always empty, contradicting the text=20 in Section 8.5.2).=20 (BTW, I think it should be called something else than KEYID, because it's too easy to confuse that with the "Key ID" field in the same message, which is something completely different.) Otherwise the change seems OK. In effect, the PMKIDs are=20 "ticket identifiers"; in Kerberos, they would not be needed=20 because the client sends the ticket to the server, so it knows=20 what ticket it has sent (if it has several). > > 10: C-->W: I'd like to use (selected cipher). > > 11: C<--W: Ok. Reset replay protection counters and derive > > a fresh encryption/MAC keys using PMK and various > > nonces from these messages. > > > > 12: C-->W: Ok. >=20 > > The crucial difference in EAP/802.11i/Diameter case seems to be > > that C !=3D C' and W !=3D W'. IEEE 802.11i-D5 says something related > > to this: "The protocol [4-way handshake] also assumes that the > > AS delivers the correct PMK to the AP with IEEE 802 address AA, > > and that the non-AP STA with IEEE 802 address AP hosts the > > Supplicant that negotiated the PMK with the AS." >=20 > As noted in RFC 3579, it is possible for the AS to do some=20 > checking of the NAS-Identifier, and NAS-IP-Address. It can also=20 > check the Called-Station-Id in the Access-Request against the=20 > known L2 addresses of the NAS identified by the NAS Identification=20 > attributes. However, it cannot know whether the AP identified=20 > itself to the STA with the claimed Called-Station-Id or whether=20 > it used another address in the BSSID instead, unless it verifies=20 > this in the EAP exchange (as Archie does). It also can't know=20 > if the AP is lying about the client Calling-Station-Id, > unless it verifies this within the EAP exchange (as Archie does). >=20 > These impersonation issues are discussed in RFC 3579, and are in the > keying framework doc to some extent as well. Should these "bindings" be included in all EAP methods, not=20 just Archie? (Or since the data is actually sent in all EAP methods, I guess the correct question is that should they by protected with a MAC/whatever in all EAP methods?) (BTW, are the MAC addresses enough, or should we also=20 include SSID?) =20 > > It continues that "None of the protocols defined by IEEE 802.11 and > > IEEE 802.1X permit the AS, the Authenticator, the Supplicant, or > > either STA to verify these assumptions." I guess the assumption here > > is that these would be handled by EAP and Diameter/RADIUS, but > > it seems that this is not usually the case! >=20 > As described in RFC 3579, AAA has limited capabilities of detecting > impersonation. Some of this can be done in EAP as in Archie. >=20 > > When sending the encrypted ticket (message #8), a Kerberos server > > would look up the key based on W. Here, W' simply claims that "I'm > > actually W too" (in Diameter-EAP-Request), and the server believes > > whatever W' says. Similarly, in message #6, C says that=20 > > "I'm actually C' too", and the server believes whatever C says. >=20 > The AS has the ability to check the W' - W binding and also the=20 > C' - C binding if it wants to. For example, it could only allow=20 > the user to access the network from a particular Calling-Station-Id=20 > or could check the Called-Station-Id against the NAS identification=20 > attributes. Yes, it could do this. If it does this, and the MAC addresses are=20 also included in deriving the keys contained in tickets (either=20 explicitly as in Archie, or implicitly as PMK=3Df(EMSK,MACs) or=20 something), then we should get the traditional expected result=20 of an authentication protocol with a trusted third party. (Roughly speaking, if two honest parties C and W attempt to=20 communicate, then an attacker can't do anything worse than DoS=20 unless he compromises S. Compromise of any other parties C2,C3,..., W2,W3,... doesn't change this. Well, actually in 802.11i this=20 would be "compromise of any other W2,W3,..." that are not=20 in the same Distribution System, i.e. Ethernet segment.)". But if the check is not done (seems quite likely), or the=20 addresses are not included in MACs or key derivation (all=20 current EAP methods except Archie), then the bets are off.=20 Since this is likely to be the case, maybe it should be=20 described separately somewhere...=20 > I think that the issue here is the W-W' binding from C's=20 > point of view. Wouldn't something like secure neighbor discovery=20 > (with an inverse option) address this? Secure neighbor discovery can prove that you're allowed to use=20 some particular IPv6 address, but it can't do the inverse:=20 prove that you're allowed to use some particular MAC address. I don't see any feasible way how this could be done...=20 (except by getting rid of permanent globally unique MAC=20 addresses, but that would be a radical change to all 802.*=20 stuff). > > It can protect against non-authenticated users, and it can > > protect the integrity of volume-based charging. However, it > > does not protect the integrity and confidentiality of user > > traffic from other authenticated users in the same WLAN. >=20 > Yes, because the security is not end-to-end. Well, end-to-end is not the whole truth... if we would have=20 C=3DC' and W=3DW', it would protect against other authenticated users in the same WLAN (but not the access point). This would=20 be especially useful if combined with something like Secure Neighbor Discovery. > > (BTW, a colleague more familiar with 802.11 and 3GPP said > > that this conclusion is nothing new and is widely known, > > at least in some circles. Even if it is, it's certainly > > important to mention it in some security considerations!) >=20 > Yes, I would say so. Text solicited ;) I'll see if I can come up with something, but I'm not promising=20 anything; a "Security considerations for 802.11i wireless LAN=20 authentication" sounds like a huge document :) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 15 10:04:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27591 for ; Fri, 15 Aug 2003 10:04:05 -0400 (EDT) Received: (qmail 9352 invoked from network); 15 Aug 2003 14:04:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 14:04:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 9327 invoked from network); 15 Aug 2003 14:03:06 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 14:03:06 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7FDX8216454; Fri, 15 Aug 2003 06:33:08 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: eap@frascone.com Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222CA@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A61222CA@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 06:33:08 -0700 (PDT) > So, perhaps something like "The EAP GTC method MUST NOT > be used to provide support for cleartext passwords in the > absence of a protected tunnel with server authentication, > such as PEAP or IKEv2." would be sufficient? Several problems with this: a. On the AAA server side, protocols such as RADIUS do not mandate confidentiality, and there is no support for "hiding" of the EAP-Message attribute in the way that the User-Password attribute is hidden. That means that any cleartext password sent via an EAP method will be exposed on the wire from the NAS to the RADIUS server. Since protocols such as EAP TTLS support "early termination" where the tunnel is terminated on a different server (e.g. a proxy) than the final exchange, this results in a cleartext password sent over a portion of the path. b. Even if the RADIUS User-Password attribute is used, this creates a number of vulnerabilities, including known plaintext attacks. If the Request Authenticator repeats on any NAS with the same shared secret an attacker would potentially be able to crack the User-Password attribute, which is encrypted with a stream cipher dependent only on the shared secret and the RA. The introduction of cleartext passwords into EAP therefore represents a substantial security vulnerability -- and one which was purposefully left out of RFC 2284. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 15 11:01:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29884 for ; Fri, 15 Aug 2003 11:01:04 -0400 (EDT) Received: (qmail 10621 invoked from network); 15 Aug 2003 15:01:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 15:01:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 10602 invoked from network); 15 Aug 2003 15:00:51 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 15:00:51 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2003 08:00:24 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7FF0MLH005848; Fri, 15 Aug 2003 08:00:22 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.226.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Aug 2003 08:04:27 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP Message-ID: <022301c3633d$f2cecd60$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 15 Aug 2003 15:04:28.0002 (UTC) FILETIME=[85C6B420:01C3633E] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 08:00:19 -0700 Content-Transfer-Encoding: 7bit If you are going to advocate the use of passwords you're protected tunel must be server authenticated and extend all the way to the AAA that does the password validation. Intermediaries/NASes should never see the password. Specifing that EAP-OTP and EAP-GTC should not be used for cleartext passwords is good because they can be used without PEAP/TTLS. I think it is up to PEAP/TTLS to define how and if clear text passwords may be used within these tunnels and can define specific mechanisms to do this. If they do allow this then they should specify that the that the protected tunnel MUST extend all the way to the EAP-Server that validates the passwords and authenticates this server to the client. Tunnel client MUST NOT send a cleartext password unless it has authenticated the EAP-Server and has determined that it is authorized to receive the password. Additional comments in line: > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Friday, August 15, 2003 6:33 AM > To: Pasi.Eronen@nokia.com > Cc: eap@frascone.com > Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP > > > > So, perhaps something like "The EAP GTC method MUST NOT > > be used to provide support for cleartext passwords in the > absence of a > > protected tunnel with server authentication, such as PEAP > or IKEv2." > > would be sufficient? > > Several problems with this: > > a. On the AAA server side, protocols such as RADIUS do not > mandate confidentiality, and there is no support for "hiding" > of the EAP-Message attribute in the way that the > User-Password attribute is hidden. That means that any > cleartext password sent via an EAP method will be exposed on > the wire from the NAS to the RADIUS server. Since protocols > such as EAP TTLS support "early termination" where the tunnel > is terminated on a different server (e.g. a proxy) than the > final exchange, this results in a cleartext password sent > over a portion of the path. > [Joe] Even worse the intemediaries/NAS know the password. However it is possible to deploy PEAP and TTLS so the protection is all the way to the validating server. > b. Even if the RADIUS User-Password attribute is used, this > creates a number of vulnerabilities, including known > plaintext attacks. If the Request Authenticator repeats on > any NAS with the same shared secret an attacker would > potentially be able to crack the User-Password attribute, > which is encrypted with a stream cipher dependent only on the > shared secret and the RA. > [Joe] I completely agree. > The introduction of cleartext passwords into EAP therefore > represents a substantial security vulnerability -- and one > which was purposefully left out of RFC 2284. > [Joe] While I would rather not see cleartext passwords, I'm not sure that this represent a substantial security vulnerability if deployed properly. In this case that would be in a server side authenticated tunnel such as (TTLS/PEAP) that extends all the way to the EAP server validating the password. This was not available when 2284 was concieved. > _______________________________________________ > 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 eap-admin@frascone.com Fri Aug 15 12:13:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01914 for ; Fri, 15 Aug 2003 12:13:04 -0400 (EDT) Received: (qmail 11982 invoked from network); 15 Aug 2003 16:13:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 16:13:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 11960 invoked from network); 15 Aug 2003 16:12:21 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 16:12:21 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7FFfM723541; Fri, 15 Aug 2003 08:41:52 -0700 From: Bernard Aboba To: Joseph Salowey cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP In-Reply-To: <022301c3633d$f2cecd60$0300000a@amer.cisco.com> Message-ID: References: <022301c3633d$f2cecd60$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 08:41:22 -0700 (PDT) > If you are going to advocate the use of passwords you're protected tunel > must be server authenticated and extend all the way to the AAA that does > the password validation. Intermediaries/NASes should never see the > password. Specifing that EAP-OTP and EAP-GTC should not be used for > cleartext passwords is good because they can be used without PEAP/TTLS. Agreed. > I think it is up to PEAP/TTLS to define how and if clear text passwords > may be used within these tunnels and can define specific mechanisms to > do this. Yes. Presumably those individual specifications will address the security issues involved. > If they do allow this then they should specify that the that > the protected tunnel MUST extend all the way to the EAP-Server that > validates the passwords and authenticates this server to the client. Yup. > Tunnel client MUST NOT send a cleartext password unless it has > authenticated the EAP-Server and has determined that it is authorized to > receive the password. Agreed. > [Joe] Even worse the intemediaries/NAS know the password. However it is > possible to deploy PEAP and TTLS so the protection is all the way to the > validating server. Yes. > [Joe] While I would rather not see cleartext passwords, I'm not sure > that this represent a substantial security vulnerability if deployed > properly. In this case that would be in a server side authenticated > tunnel such as (TTLS/PEAP) that extends all the way to the EAP server > validating the password. This was not available when 2284 was concieved. If the password is completely protected end-to-end via a tunnel, it's not really a "cleartext password". Perhaps we need some language to make that clear? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 15 12:25:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02392 for ; Fri, 15 Aug 2003 12:25:03 -0400 (EDT) Received: (qmail 12565 invoked from network); 15 Aug 2003 16:25:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 15 Aug 2003 16:25:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 12534 invoked from network); 15 Aug 2003 16:24:55 -0000 Received: from fmr06.intel.com (HELO caduceus.jf.intel.com) (134.134.136.7) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 16:24:55 -0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7FGIIW17757 for ; Fri, 15 Aug 2003 16:18:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7FFkqm12895 for ; Fri, 15 Aug 2003 15:46:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081509242519293 for ; Fri, 15 Aug 2003 09:24:25 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Aug 2003 09:24:25 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] RE: Some ideas for keying framework Message-ID: Thread-Topic: Some ideas for keying framework Thread-Index: AcNickJnCWWMneGJT6axvJhtiDLU3wAj8fywABFrknA= From: "Lortz, Victor" To: X-OriginalArrivalTime: 15 Aug 2003 16:24:25.0742 (UTC) FILETIME=[B173BAE0:01C36349] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 09:24:25 -0700 Content-Transfer-Encoding: quoted-printable We think that data after the NULL in the Identity-Request should be = considered as a hint. It can be useful in guiding the network discovery = and authentication process, but it should be treated similarly to the = SSID in beacon broadcasts: subject to modification and spoofing. One = could conceivably try to secure the data, but we feel the costs of doing = so would outweigh the benefits. The network discovery hint can be = useful to help the EAP peer decide whether or not to try connecting to = the network and to help it formulate a suitable NAI for that network = (presuming that the peer might need to select a particular identity to = use and/or include some NAI decoration for directing the routing of the = AAA messages). More complex network discovery or client provisioning = functions should be accomplished through other methods with more robust = security properties. Regards, Vic -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Friday, August 15, 2003 5:41 AM To: aboba@internaut.com Cc: eap@frascone.com Subject: [eap] RE: Some ideas for keying framework ... BTW, it seems that no EAP method currently protects the contents=20 of the Identity Request; the assumption probably was that it=20 doesn't contain anything important. Thus, if it includes some data after a NUL, it could be modified by an attacker.=20 I'm not sure if any of the data currently included counts=20 as "important" or not, but it's worth keeping in mind... > > 3: C<--S: Prove that you know the shared secret (K_S-C). > > 4: C-->S: Here's proof. Could you prove that you know K_S-C too? .. Best regards, Pasi _______________________________________________ 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 eap-admin@frascone.com Sat Aug 16 01:08:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23212 for ; Sat, 16 Aug 2003 01:08:05 -0400 (EDT) Received: (qmail 23858 invoked from network); 16 Aug 2003 05:08:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 16 Aug 2003 05:08:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 17299 invoked from network); 15 Aug 2003 20:41:38 -0000 Received: from key1.docomolabs-usa.com (HELO fridge.docomolabs-usa.com) (fwuser@216.98.102.225) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 15 Aug 2003 20:41:38 -0000 Message-ID: <03ba01c3636d$a77d2ed0$976015ac@dclkempt40> From: "James Kempf" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [eap] Call for Journal Papers: Next Generation Mobile Security Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 13:41:49 -0700 Content-Transfer-Encoding: 7bit Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 16 10:56:16 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12985 for ; Sat, 16 Aug 2003 10:56:06 -0400 (EDT) Received: (qmail 1205 invoked from network); 16 Aug 2003 14:56:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 16 Aug 2003 14:56:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 1184 invoked from network); 16 Aug 2003 14:55:31 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 16 Aug 2003 14:55:31 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7GEPQH02267; Sat, 16 Aug 2003 07:25:26 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: eap@frascone.com In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB97@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB97@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] RE: Some ideas for keying framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 16 Aug 2003 07:25:26 -0700 (PDT) > Yes. I included this just to show that the protocol is > actually initiated by the client. The EAPOL-Start is converted > to a RADIUS/Diameter EAP-Start between the access point and S. Good point. We might want to mention in RFC 2284bis that while EAP itself is initiated by the authenticator, that the exchange can be kick-started by the lower layer. > I guess all mutually authenticating EAP methods have some > mechanisms for protecting the identity exchange. After all, > if after a successful authentication the user thinks he has > authenticated as X and the server thinks the user is Y, > the method doesn't provide much authentication. Yes. > Based on a quick look, at least EAP-TLS, Archie, EAP-SIM and > EAP-AKA seem to protect the identity being authenticated > (which is not necessarily the same as the contents of the > Identity Response). MSCHAPv2 doesn't protect the whole > identity, just the username part (not domain). Maybe we should add "Method-specific Identity" as a disclosure requirement for EAP methods? > BTW, it seems that no EAP method currently protects the contents > of the Identity Request; the assumption probably was that it > doesn't contain anything important. Thus, if it includes > some data after a NUL, it could be modified by an attacker. > I'm not sure if any of the data currently included counts > as "important" or not, but it's worth keeping in mind... We should probably add some text about that. > I think that to protect against compromised NASes, the MAC > addresses have to be taken into account ("bound") in the > AAA-Key(s) contained in the ticket(s) sent from AAA server to > access point(s). Doing it in the 4-way handshake phase is > probably too late. I think this only protects against some types of compromise. For example, a NAS could lie about its NAS-Identifier, NAS-IPv6-Address or NAS-IP-address, impersonating another NAS. It can also lie about the Called-Station-Id and Calling-Station-Id. The AAA server/proxy can check the NAS-Identifier, NAS-IPv6-Address and NAS-IP-Address against the source IP address, and it could also check the Called-Station-Id against a table of NAS/Called-Station-Id mappings. It could also check the User-Name/Calling-Station-Id binding but in most cases that isn't worth the effort because users can change their NIC or home phone number. Binding these parameters in the AAA-Token doesn't really do much to improve security if the destination is the same NAS that is lying. Binding the parameters in a message sent to the *peer* would help because then the peer could compare the parameters to those that the NAS is claiming. > EAP Archie does this by including the MAC addresses explicitly > in the messages. Another possibility would be that when the AAA > server sends the ticket(s), it calculates the key to be included > as f(EMSK,AP_MAC,STA_MAC). The proactive key distribution proposal > by Mishra et al. did something like this, if I recall correctly. Yes. This "binds" the parameters in a way that guarantees that the AP cannot lie or communication will not occur, since the keys won't match. Really, the above formula is f(EMSK, Called-Station-Id, Calling-Station-Id), where the Called-Station-Id and Calling-Station-Id are the parameters provided by the NAS. In many ways, I like this scheme because it does not require anything special in the EAP method itself, but if it is only used for fast-handoff, it would seem that there is a gap. For example, one could conceive of the AAA-Key being calculated as f(MSK, Called-Station-Id, Calling-Station-Id) in the non-fast-handoff case as well, which would fix the problem generally. > BTW, it just occured to me that actually the MAC addresses > (C' and W) are always sent in this message, even in EAP methods > other than Archie (they're in the EAPOL headers and Diameter > AVPs). Archie is just the only one that includes them when > calculating the MACs! Ah. So you're suggesting that a AAA server could calculate a method-specific MAC based on a "pseudo header" comprised of parameters obtained from the NAS, such as Called-Station-Id and Calling-Station-Id? This would certainly work but would only "fix" those EAP methods that incorporated it. > Is any subsequent information actually necessary? If the > PMK is derived e.g. as f(EMSK,AP_MAC,STA_MAC), the client > already has all the necessary information to construct it > for any access point. The problem is that there may be multiple active EAP SAs that could have generated the EMSK used in the above formula. > I think the implicit inclusion works here. If we choose to do > proactive key distribution (initiated by the AAA server), > then that message has to include them explicitly. Yes, that is definitely true, and we should discuss this somewhere. > I checked what the specs actually say about Authorization-Lifetime > and Session-Timeout, and I think that the Base text makes sense. > But the text in NASREQ is confusing and contradicts Base > in some cases. (I'll send something about this to the AAA list > in a separate message; in the following I'll assume Base is > correct, since it makes more sense.) Thanks. > Deriving a new AAA-Key (==PMK in 802.11i) for an access point > requires a new EAP conversation, right? (This may be a "fast" > reauth if the EAP method supports it) This could be done > with Authorization-Lifetime + Re-Auth-Request-Type set to > AUTHORIZE_AUTHENTICATE. Yes. Actually the PMK is just the first 32 octets of the AAA-Key. > On the other hand, re-checking the authorization ("is this > user's account still ok?") makes sense without deriving > a new key. This could be done with Authorization-Lifetime > AVP + Re-Auth-Request-Type AVP set to AUTHORIZE_ONLY. OK. Is there a way of requesting another 4-way handshake without a re-authentication? > Otherwise the change seems OK. In effect, the PMKIDs are > "ticket identifiers"; in Kerberos, they would not be needed > because the client sends the ticket to the server, so it knows > what ticket it has sent (if it has several). Yes. I think the issue occurs where there might be multiple algorithms in use for calculating the keys; in that case the client might have to calculate potential keys from multiple EAP SAs using multiple algorithms. > Should these "bindings" be included in all EAP methods, not > just Archie? (Or since the data is actually sent in all EAP > methods, I guess the correct question is that should they > by protected with a MAC/whatever in all EAP methods?) > > (BTW, are the MAC addresses enough, or should we also > include SSID?) I think it is a question of changing methods (many of which are already shpping) versus changing the lower layer implementation (which is in the process of being standardized). If the "bindings" are implicit within the key calculation, then it is possible to solve the problem without requiring methods to do anything. > Yes, it could do this. If it does this, and the MAC addresses are > also included in deriving the keys contained in tickets (either > explicitly as in Archie, or implicitly as PMK=f(EMSK,MACs) or > something), then we should get the traditional expected result > of an authentication protocol with a trusted third party. Yes, this is nice -- and brings up the question whether AAA-Key=f(MSK, Called-Station-Id, Calling-Station-Id) wouldn't make sense as well. > But if the check is not done (seems quite likely), or the > addresses are not included in MACs or key derivation (all > current EAP methods except Archie), then the bets are off. > Since this is likely to be the case, maybe it should be > described separately somewhere... Yes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 20 18:17:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15991 for ; Wed, 20 Aug 2003 18:17:00 -0400 (EDT) Received: (qmail 9305 invoked from network); 20 Aug 2003 22:17:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 20 Aug 2003 22:17:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 9284 invoked from network); 20 Aug 2003 22:16:53 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 20 Aug 2003 22:16:53 -0000 Received: from [10.0.1.4] (pm593-00.dialip.mich.net [207.75.181.58]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7KMGb627168; Wed, 20 Aug 2003 18:16:37 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , Joseph Salowey cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP Message-ID: <6306550.1061403396@[10.0.1.4]> In-Reply-To: References: <022301c3633d$f2cecd60$0300000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 20 Aug 2003 18:16:36 -0400 Content-Transfer-Encoding: 7bit --On Friday, August 15, 2003 8:41 AM -0700 Bernard Aboba wrote: > > If you are going to advocate the use of passwords you're protected tunel > > must be server authenticated and extend all the way to the AAA that does > > the password validation. Intermediaries/NASes should never see the > > password. Specifing that EAP-OTP and EAP-GTC should not be used for > > cleartext passwords is good because they can be used without PEAP/TTLS. > > Agreed. > > > I think it is up to PEAP/TTLS to define how and if clear text passwords > > may be used within these tunnels and can define specific mechanisms to > > do this. > > Yes. Presumably those individual specifications will address the security > issues involved. > > > If they do allow this then they should specify that the that > > the protected tunnel MUST extend all the way to the EAP-Server that > > validates the passwords and authenticates this server to the client. > > Yup. > > > Tunnel client MUST NOT send a cleartext password unless it has > > authenticated the EAP-Server and has determined that it is authorized to > > receive the password. > > Agreed. > > > [Joe] Even worse the intemediaries/NAS know the password. However it is > > possible to deploy PEAP and TTLS so the protection is all the way to the > > validating server. > > Yes. > > > [Joe] While I would rather not see cleartext passwords, I'm not sure > > that this represent a substantial security vulnerability if deployed > > properly. In this case that would be in a server side authenticated > > tunnel such as (TTLS/PEAP) that extends all the way to the EAP server > > validating the password. This was not available when 2284 was concieved. > > If the password is completely protected end-to-end via a tunnel, it's not > really a "cleartext password". Perhaps we need some language to make that > clear? > Perhaps a solution ist to let the tunnel methods describe their security requirements, but saying in 2284bis that:" if not in a tunnel OTP and GTC (or any other that might be invented) must not contain cleartest password. " > _______________________________________________ > 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 eap-admin@frascone.com Thu Aug 21 09:14:16 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03796 for ; Thu, 21 Aug 2003 09:14:13 -0400 (EDT) Received: (qmail 23654 invoked from network); 21 Aug 2003 13:14:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 21 Aug 2003 13:14:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 23631 invoked from network); 21 Aug 2003 13:13:20 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 21 Aug 2003 13:13:20 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7LCgmj12879; Thu, 21 Aug 2003 05:42:48 -0700 From: Bernard Aboba To: Yoshihiro Ohba cc: eap@frascone.com In-Reply-To: <20030820180355.GC16501@steelhead> Message-ID: References: <20030820180355.GC16501@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: EAP silent discarding Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 21 Aug 2003 05:42:48 -0700 (PDT) On Wed, 20 Aug 2003, Yoshihiro Ohba wrote: > The current RFC2284bis uses silent discard as a basis for error > handling (that is good). I think the silent discarding policy works > only when the EAP authenticator retransmits EAP Requests "at EAP > layer". > > For example, if EAP runs over a reliable lower-layer and thus the > authenticator disables EAP retransmission according to the > recommendation in section 4.3, there is some cases in which silent > discarding makes EAP conversation stall, since the reliable transport > running at the lower-layer will not retransmit a message that has been > successfully acknowledged and passed to the higher layer protocol, > i.e., EAP, for which retransmission is disabled due to the > recommendation. > > EAP and lower-layer are not tightly coupled in most > cases, and thus it is not appropriate to assume something that EAP can > indicate the lower-layer to keep a copy of an acknowledged message and > to retransmit it when the message is silently discarded by EAP. > > So I think EAP layer retransmission is basically needed regardless of > whether EAP runs over reliable transport or not. > > I maybe misunderstanding something, but if my observation is correct > the following text in section section 4.3 needs to be revised: > > "When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as > within [PIC]), the authenticator retransmission timer SHOULD be set > to an infinite value, so that retransmissions do not occur at the EAP > layer. The peer may still maintain a timeout value so as to avoid > waiting indefinitely for a Request." > > > What do you think? Let's look at a specific scenario to understand the issue: EAP peer A is authenticating to Authenticator B. Attacker C is also sending EAP packets to Authenticator B. Authenticator B is in "pass-through" mode with Authentication Server D. To mount the attack, Attacker C is having to generate packets with the correct Identifier as well as potentially the correct MIC. Authenticator B checks the Code, Identifier and Length fields and silently discards many of the packets. Packets with invalid MICs are silently discarded at AS D and Authenticator B then sends the next packet in the queue. Occasionally the queue at Authenticator B may fill up and as a result, a packet from EAP peer A may be dropped. In EAP this is addressed by retransmission from Authenticator B. Presumably in such a situation Authenticator B would not have sent an ACK within a reliable transport either, so that for a reliable transport retransmission might occur from the peer side, with backoff. It would appear to me that no stalls will occur if: a. Neither peer nor authenticator send a transport ACK unless the packet is actually handed up to EAP for processing; b. Neither peer nor authenticator is sending invalid EAP packets (e.g. packets w/invalid Code, Identifier, Length or bad MICs) Note that if b) is true then retransmission at any layer will not help because the retransmitted packet will also be discarded. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 21 12:33:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13234 for ; Thu, 21 Aug 2003 12:33:05 -0400 (EDT) Received: (qmail 27588 invoked from network); 21 Aug 2003 16:33:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 21 Aug 2003 16:33:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 27552 invoked from network); 21 Aug 2003 16:32:22 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 21 Aug 2003 16:32:22 -0000 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h7LGWJIv008824; Fri, 22 Aug 2003 01:32:19 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h7LGWJkO012032; Fri, 22 Aug 2003 01:32:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA12031 ; Fri, 22 Aug 2003 01:32:19 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA22265; Fri, 22 Aug 2003 01:32:18 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA28774; Fri, 22 Aug 2003 01:32:16 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h7LGWF5H002884; Fri, 22 Aug 2003 01:32:15 +0900 (JST) Received: from localhost ([159.119.168.173]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HJZ00M0P9XMEG@tsbpo1.po.toshiba.co.jp>; Fri, 22 Aug 2003 01:32:15 +0900 (JST) From: Yoshihiro Ohba In-reply-to: To: Bernard Aboba Cc: Yoshihiro Ohba , eap@frascone.com Message-id: <20030821162937.GA1078@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 95 References: <20030820180355.GC16501@steelhead> Subject: [eap] Re: EAP silent discarding Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 21 Aug 2003 09:29:37 -0700 On Thu, Aug 21, 2003 at 05:42:48AM -0700, Bernard Aboba wrote: > > > On Wed, 20 Aug 2003, Yoshihiro Ohba wrote: > > > The current RFC2284bis uses silent discard as a basis for error > > handling (that is good). I think the silent discarding policy works > > only when the EAP authenticator retransmits EAP Requests "at EAP > > layer". > > > > For example, if EAP runs over a reliable lower-layer and thus the > > authenticator disables EAP retransmission according to the > > recommendation in section 4.3, there is some cases in which silent > > discarding makes EAP conversation stall, since the reliable transport > > running at the lower-layer will not retransmit a message that has been > > successfully acknowledged and passed to the higher layer protocol, > > i.e., EAP, for which retransmission is disabled due to the > > recommendation. > > > > EAP and lower-layer are not tightly coupled in most > > cases, and thus it is not appropriate to assume something that EAP can > > indicate the lower-layer to keep a copy of an acknowledged message and > > to retransmit it when the message is silently discarded by EAP. > > > > So I think EAP layer retransmission is basically needed regardless of > > whether EAP runs over reliable transport or not. > > > > I maybe misunderstanding something, but if my observation is correct > > the following text in section section 4.3 needs to be revised: > > > > "When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as > > within [PIC]), the authenticator retransmission timer SHOULD be set > > to an infinite value, so that retransmissions do not occur at the EAP > > layer. The peer may still maintain a timeout value so as to avoid > > waiting indefinitely for a Request." > > > > > > What do you think? > > Let's look at a specific scenario to understand the issue: > > EAP peer A is authenticating to Authenticator B. Attacker C is also > sending EAP packets to Authenticator B. Authenticator B is in > "pass-through" mode with Authentication Server D. > > To mount the attack, Attacker C is having to generate packets with the > correct Identifier as well as potentially the correct MIC. > Authenticator B checks the Code, Identifier and Length fields and silently > discards many of the packets. Packets with invalid MICs are silently > discarded at AS D and Authenticator B then sends the next packet in the > queue. > > Occasionally the queue at Authenticator B may fill up and as a result, a > packet from EAP peer A may be dropped. In EAP this is addressed by > retransmission from Authenticator B. Presumably in such a situation > Authenticator B would not have sent an ACK within a reliable transport > either, so that for a reliable transport retransmission might occur from > the peer side, with backoff. > > It would appear to me that no stalls will occur if: > > a. Neither peer nor authenticator send a transport ACK unless the packet > is actually handed up to EAP for processing; > > b. Neither peer nor authenticator is sending invalid EAP packets (e.g. > packets w/invalid Code, Identifier, Length or bad MICs) > > Note that if b) is true then retransmission at any layer will not help > because the retransmitted packet will also be discarded. > My point is that we probably need additional condition: c. Authenticator does EAP layer retransmission even if the lower-layer does retransmission unless the lower-layer is secured. Without c), an invalid EAP message sent from an attacker will be processed as a valid message by the lower-layer and handed up to the EAP layer, then EAP will found it invalid and discard it. Then the result would be that neither lower-layer nor EAP will retransmit the outstanding message which is needed for continuing the EAP conversation. Of course if the lower-layer is not only reliable but also secure, this will not occur. A protocol that employs silent discarding has the responsibility to do retransmission. In other words, silent discarding and retransmission are closely related functionalities. The current EAP specification recommends an option to disable EAP-layer retransmission when the lower-layer provides reliability, but this will make silent discarding and retransmission independent in many cases, which I think we need more consideration. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 21 13:34:21 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15953 for ; Thu, 21 Aug 2003 13:34:15 -0400 (EDT) Received: (qmail 29014 invoked from network); 21 Aug 2003 17:34:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 21 Aug 2003 17:34:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 28956 invoked from network); 21 Aug 2003 17:33:15 -0000 Received: from palrel11.hp.com (156.153.255.246) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 21 Aug 2003 17:33:15 -0000 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 15FBE1C014A7; Thu, 21 Aug 2003 10:33:13 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id B900F1C0009D; Thu, 21 Aug 2003 10:33:12 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Aug 2003 10:33:12 -0700 Message-ID: <499DC368E25AD411B3F100902740AD651C6286AA@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Yoshihiro Ohba'" , Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Re: EAP silent discarding MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 21 Aug 2003 10:33:08 -0700 It doesn't seem like a good idea for EAP to selectively chose a mode of operation based upon the lower layer's capabilities. It is unnecessarily complicating and restricting. EAP should handle retransmission regardless. Paul > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, August 21, 2003 9:30 AM > To: Bernard Aboba > Cc: Yoshihiro Ohba; eap@frascone.com > Subject: [eap] Re: EAP silent discarding > > > On Thu, Aug 21, 2003 at 05:42:48AM -0700, Bernard Aboba wrote: > > > > > > On Wed, 20 Aug 2003, Yoshihiro Ohba wrote: > > > > > The current RFC2284bis uses silent discard as a basis for error > > > handling (that is good). I think the silent discarding > policy works > > > only when the EAP authenticator retransmits EAP Requests "at EAP > > > layer". > > > > > > For example, if EAP runs over a reliable lower-layer and thus the > > > authenticator disables EAP retransmission according to the > > > recommendation in section 4.3, there is some cases in > which silent > > > discarding makes EAP conversation stall, since the reliable > > > transport running at the lower-layer will not retransmit > a message > > > that has been successfully acknowledged and passed to the higher > > > layer protocol, i.e., EAP, for which retransmission is > disabled due > > > to the recommendation. > > > > > > EAP and lower-layer are not tightly coupled in most > > > cases, and thus it is not appropriate to assume something > that EAP > > > can indicate the lower-layer to keep a copy of an acknowledged > > > message and to retransmit it when the message is silently > discarded > > > by EAP. > > > > > > So I think EAP layer retransmission is basically needed > regardless > > > of whether EAP runs over reliable transport or not. > > > > > > I maybe misunderstanding something, but if my observation > is correct > > > the following text in section section 4.3 needs to be revised: > > > > > > "When run over a reliable lower layer (e.g., EAP over > ISAKMP/TCP, as > > > within [PIC]), the authenticator retransmission timer > SHOULD be set > > > to an infinite value, so that retransmissions do not > occur at the EAP > > > layer. The peer may still maintain a timeout value so > as to avoid > > > waiting indefinitely for a Request." > > > > > > > > > What do you think? > > > > Let's look at a specific scenario to understand the issue: > > > > EAP peer A is authenticating to Authenticator B. Attacker > C is also > > sending EAP packets to Authenticator B. Authenticator B is in > > "pass-through" mode with Authentication Server D. > > > > To mount the attack, Attacker C is having to generate > packets with the > > correct Identifier as well as potentially the correct MIC. > > Authenticator B checks the Code, Identifier and Length fields and > > silently discards many of the packets. Packets with > invalid MICs are > > silently discarded at AS D and Authenticator B then sends the next > > packet in the queue. > > > > Occasionally the queue at Authenticator B may fill up and > as a result, > > a packet from EAP peer A may be dropped. In EAP this is > addressed by > > retransmission from Authenticator B. Presumably in such a > situation > > Authenticator B would not have sent an ACK within a > reliable transport > > either, so that for a reliable transport retransmission might occur > > from the peer side, with backoff. > > > > It would appear to me that no stalls will occur if: > > > > a. Neither peer nor authenticator send a transport ACK unless the > > packet is actually handed up to EAP for processing; > > > > b. Neither peer nor authenticator is sending invalid EAP > packets (e.g. > > packets w/invalid Code, Identifier, Length or bad MICs) > > > > Note that if b) is true then retransmission at any layer > will not help > > because the retransmitted packet will also be discarded. > > > > My point is that we probably need additional condition: > > c. Authenticator does EAP layer retransmission even if the > lower-layer does retransmission unless the lower-layer is secured. > > Without c), an invalid EAP message sent from an attacker will > be processed as a valid message by the lower-layer and handed > up to the EAP layer, then EAP will found it invalid and > discard it. Then the result would be that neither > lower-layer nor EAP will retransmit the outstanding message > which is needed for continuing the EAP conversation. Of > course if the lower-layer is not only reliable but also > secure, this will not occur. > > A protocol that employs silent discarding has the > responsibility to do retransmission. In other words, silent > discarding and retransmission are closely related > functionalities. The current EAP specification recommends an > option to disable EAP-layer retransmission when the > lower-layer provides reliability, but this will make silent > discarding and retransmission independent in many cases, > which I think we need more consideration. > > > Yoshihiro Ohba > > _______________________________________________ > 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 eap-admin@frascone.com Fri Aug 22 12:33:06 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05881 for ; Fri, 22 Aug 2003 12:33:03 -0400 (EDT) Received: (qmail 23768 invoked from network); 22 Aug 2003 16:33:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 22 Aug 2003 16:33:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 23727 invoked from network); 22 Aug 2003 16:33:00 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 22 Aug 2003 16:33:00 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7MG2Pg12182 for ; Fri, 22 Aug 2003 09:02:25 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Potential EAP WG interim meeting 10/15/03 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 22 Aug 2003 09:02:25 -0700 (PDT) In order to ensure that the EAP Key Framework document is in sync with IEEE 802.11i, it has been suggested that an EAP WG interim meeting be held coincident with the IEEE 802.11i interim meeting planned to take place in Herndon, VA. The tentative date suggested is October 15, 2003. More details will become available in the days/weeks ahead. If you'd be interested in attending such a meeting, please send mail to the chairs. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 22 16:57:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19764 for ; Fri, 22 Aug 2003 16:57:05 -0400 (EDT) Received: (qmail 29570 invoked from network); 22 Aug 2003 20:57:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 22 Aug 2003 20:57:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 29548 invoked from network); 22 Aug 2003 20:56:09 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 22 Aug 2003 20:56:09 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7MKPXP27737 for ; Fri, 22 Aug 2003 13:25:34 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 168: Peer link usage Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 22 Aug 2003 13:25:33 -0700 (PDT) Issue 168: Peer link usage Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/22/2003 Reference: Document: RFC2284bis Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I have recently looked at EAP authentication traces where the peer is sending data packets before and interspersed with, EAP authentication. The peer had been previously attached to another authenticator and was sending high-rate UDP traffic (video). This is not a re-authentication -- it represents the authentication of a peer to a new Authenticator (AP) after a roam. After it connects to the new Authenticator, the peer continues to empty the queue onto the new link. Of course, the new Authenticator silently discards the traffic, but the EAP traffic is trapped in the queue (e.g. is not prioritized), and so it can take seconds to be sent by the peer. The result is retransmission by the Authenticator -- and horrendous EAP authentication latencies. I would also note that this problem is not rare -- it has shown up in quite a few implementations that we have tested. It occurs to me that perhaps we need some explicit language in RFC 2284bis to make it clear that this is nonsensical behavior. For example, that the peer should not be sending outbound data or receiving inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being usable. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 22 21:33:33 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02064 for ; Fri, 22 Aug 2003 21:33:32 -0400 (EDT) Received: (qmail 2135 invoked from network); 23 Aug 2003 01:32:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 23 Aug 2003 01:32:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 2112 invoked from network); 23 Aug 2003 01:31:29 -0000 Received: from key1.docomolabs-usa.com (HELO fridge.docomolabs-usa.com) (fwuser@216.98.102.225) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 23 Aug 2003 01:31:29 -0000 Subject: Re: [eap] Issue 168: Peer link usage From: Alper Yegin To: Bernard Aboba , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 22 Aug 2003 18:33:32 -0700 Content-Transfer-Encoding: 7bit > It occurs to me that perhaps we need some explicit language in RFC 2284bis > to make it clear that this is nonsensical behavior. For example, that the > peer should not be sending outbound data or receiving > inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being > usable. I think this should be tied to the state machine, such that the implementors know when the "link is usable". This is similar to some of the recent DNA discussions. Just because the interface is available to send and receive IP packets does not necessarily mean that it is ready to send/receive user data packets. We are seeing the same in this example, at a lower layer though... alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Aug 24 18:37:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29407 for ; Sun, 24 Aug 2003 18:36:59 -0400 (EDT) Received: (qmail 15963 invoked from network); 24 Aug 2003 22:37:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 24 Aug 2003 22:37:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 15941 invoked from network); 24 Aug 2003 22:36:45 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 24 Aug 2003 22:36:45 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7OM5u306603 for ; Sun, 24 Aug 2003 15:05:57 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 169: Review of Key Framework -07 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 24 Aug 2003 15:05:56 -0700 (PDT) Submitter name: Dan Simon Submitter email address: dansimon@microsoft.com Date first submitted: 8/24/2003 Reference: Document: Key-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: p. 7, 1st para.: "exhaustive search" is not the best terminology, since some algorithms (notably number-theoretic ones) are attackable by means other than brute force. "Breaking a cryptographic assumption", which you use earlier in the paragraph, is a better phrasing. p. 8, last para.: "Key management" is often used as a synonym for "key distribution", so the question of whether EAP itself is a key management protocol should be thought of primarily in terms of whether it's EAP or individual EAP methods that handle key distribution (i.e., key exchange). I'll leave it to you to decide which way you like to think of it. p. 13, first para.: the IV must not be used by itself in computation of any quantity that needs to remain secret. Obviously, it can be used in combination with secret keys to derive other secret keys. p. 21, 1st para.: removing an SA based on a (single) failed authentication suggests an easy targeted DoS attack (although, granted, a strictly local one, and hence not that much of a concern). In any event, rate-limiting authentication attempts should suffice, especially when strong keys are being used. p. 21, 3rd para.: You mean 802.11, not 820.11, right? p. 22, 4th para.: See comment on p. 21, 1st para., above. p. 24, last para.: I don't think you mean "perfect forward secrecy" here so much as "key separation". None of the keys are being "rolled forward" over time; rather, the MSK is being kept cryptographically separated from the keys needed to impersonate the backend server or peer. p. 25, 2nd last para.: "between the peer and server", not "between the peer and authenticator". (Right?) p. 29, "Cryptographic separation": see first comment, on p. 7, above. p. 30, "Key Strength" and "Freshness": I have no fundamental objection to the 128-bit requirement, but I also would have no objection if it were weakened somewhat (e.g., to 96 bits), and I wouldn't want to see an otherwise reasonable future EAP method proposal get shot down over key-length paranoia. On the other hand, if you're confident that this won't be a problem (i.e., that nobody will ever have trouble meeting the 128-bit requirement within their method), I'll accept your judgment. General: I was wondering if it might be a good idea to have a "DoS attack" section in the security considerations section, spelling out what makes a DoS attack worthy or unworthy of concern. One thought that came to mind as I was reading the doc, for instance: you mention a peer having multiple SAs with the same authenticator--might that allow a client to start establishing SAs with the authenticator (e.g., an AP) until the latter "blows up" or maxes out, then move on to the next authenticator and do the same? Again, if it only disables the authenticator while the client is around, then the attack could be dismissed as "microwave-oven-equivalent"--but could the request for multiple SAs conceivably cause the authenticator to freeze up for a longer period while it holds huge amounts of SA state for the single client, waiting for it to return? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 25 13:47:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04089 for ; Mon, 25 Aug 2003 13:47:08 -0400 (EDT) Received: (qmail 7063 invoked from network); 25 Aug 2003 17:47:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 25 Aug 2003 17:47:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7028 invoked from network); 25 Aug 2003 17:46:19 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 25 Aug 2003 17:46:19 -0000 Received: from [10.0.1.2] (pm481-21.dialip.mich.net [207.75.180.127]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7PHkEm03345; Mon, 25 Aug 2003 13:46:14 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage Message-ID: <12383395.1061819177@[10.0.1.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Aug 2003 13:46:17 -0400 Content-Transfer-Encoding: 7bit --On Friday, August 22, 2003 1:25 PM -0700 Bernard Aboba wrote: > Issue 168: Peer link usage > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/22/2003 > Reference: > Document: RFC2284bis > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > I have recently looked at EAP authentication traces where the > peer is sending data packets before and interspersed with, > EAP authentication. The peer had been previously attached to > another authenticator and was sending high-rate UDP traffic (video). > This is not a re-authentication -- it represents the authentication of a > peer to a new Authenticator (AP) after a roam. > > After it connects to the new Authenticator, the peer continues to > empty the queue onto the new link. > > Of course, the new Authenticator silently discards the traffic, but the > EAP traffic is trapped in the queue (e.g. is not prioritized), and so > it can take seconds to be sent by the peer. The result is > retransmission by the Authenticator -- and horrendous EAP > authentication latencies. > > I would also note that this problem is not rare -- it has shown up in > quite a few implementations that we have tested. > > It occurs to me that perhaps we need some explicit language in RFC 2284bis > to make it clear that this is nonsensical behavior. For example, that the > peer should not be sending outbound data or receiving > inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being > usable. This sounds like a real problem that should be handled. I am thinking this is better for 802.1x or other lower layer than for EAP. What do you think? > _______________________________________________ > 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 eap-admin@frascone.com Mon Aug 25 13:52:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04394 for ; Mon, 25 Aug 2003 13:52:01 -0400 (EDT) Received: (qmail 7478 invoked from network); 25 Aug 2003 17:52:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 25 Aug 2003 17:52:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 7456 invoked from network); 25 Aug 2003 17:51:59 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 25 Aug 2003 17:51:59 -0000 Received: from [10.0.1.2] (pm481-21.dialip.mich.net [207.75.180.127]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7PHpqm04696; Mon, 25 Aug 2003 13:51:53 -0400 (EDT) From: John Vollbrecht To: Alper Yegin , Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage Message-ID: <12403683.1061819515@[10.0.1.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Aug 2003 13:51:55 -0400 Content-Transfer-Encoding: 7bit --On Friday, August 22, 2003 6:33 PM -0700 Alper Yegin wrote: > > It occurs to me that perhaps we need some explicit language in RFC > > 2284bis to make it clear that this is nonsensical behavior. For > > example, that the peer should not be sending outbound data or receiving > > inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being > > usable. > > I think this should be tied to the state machine, such that the > implementors know when the "link is usable". > I think it is in the lower layer state machine. EAP should not be called to run on a link with a lot of other stuff on it - seems to me. If it isn't called at the wrong time it doesn't need to say don't use the link. Other ways of doing this seem to make it hard to do reauthentication on an existing stream. > This is similar to some of the recent DNA discussions. Just because the > interface is available to send and receive IP packets does not necessarily > mean that it is ready to send/receive user data packets. We are seeing the > same in this example, at a lower layer though... > > alper > > _______________________________________________ > 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 eap-admin@frascone.com Mon Aug 25 19:17:04 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22410 for ; Mon, 25 Aug 2003 19:17:02 -0400 (EDT) Received: (qmail 15025 invoked from network); 25 Aug 2003 23:17:03 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 25 Aug 2003 23:17:03 -0000 Delivered-To: eap@frascone.com Received: (qmail 15005 invoked from network); 25 Aug 2003 23:16:13 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 25 Aug 2003 23:16:13 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7PMjIJ26907; Mon, 25 Aug 2003 15:45:18 -0700 From: Bernard Aboba To: John Vollbrecht cc: eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage In-Reply-To: <12383395.1061819177@[10.0.1.2]> Message-ID: References: <12383395.1061819177@[10.0.1.2]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Aug 2003 15:45:17 -0700 (PDT) > This sounds like a real problem that should be handled. I am thinking this > is better for 802.1x or other lower layer than for EAP. What do you think? It's hard for me to imagine that this would be correct behavior for an implementation of EAP on any media -- so I think the fix belongs in RFC 2284bis. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 25 19:19:03 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22511 for ; Mon, 25 Aug 2003 19:19:02 -0400 (EDT) Received: (qmail 15394 invoked from network); 25 Aug 2003 23:19:04 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 25 Aug 2003 23:19:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 15313 invoked from network); 25 Aug 2003 23:18:21 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 25 Aug 2003 23:18:21 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7PMlN927035; Mon, 25 Aug 2003 15:47:23 -0700 From: Bernard Aboba To: John Vollbrecht cc: Alper Yegin , eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage In-Reply-To: <12403683.1061819515@[10.0.1.2]> Message-ID: References: <12403683.1061819515@[10.0.1.2]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Aug 2003 15:47:23 -0700 (PDT) > I think it is in the lower layer state machine. EAP should not be called > to run on a link with a lot of other stuff on it - seems to me. If it > isn't called at the wrong time it doesn't need to say don't use the link. Actually, it's the EAP state machine that controls whether the port is perceived to be usable to send data traffic, not the other way around. > Other ways of doing this seem to make it hard to do reauthentication on an > existing stream. Are you saying that the current EAP state machine does not correctly handle reauthentication? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 26 20:38:06 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27179 for ; Tue, 26 Aug 2003 20:38:04 -0400 (EDT) Received: (qmail 27478 invoked by uid 507); 27 Aug 2003 00:38:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 27 Aug 2003 00:38:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 27411 invoked by uid 507); 27 Aug 2003 00:37:17 -0000 Received: from old-n2-130.infonet.com (HELO old-n2.infonet.com) (192.157.130.138) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 27 Aug 2003 00:37:16 -0000 Received: from hubnotes1.infonet.com (hubnotes1 [198.137.76.56]) by old-n2.infonet.com with ESMTP id h7R0Xtk11901 for ; Wed, 27 Aug 2003 00:33:56 GMT From: josh_mendel@infonet.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on HUBNOTES1/SVR/ISC(Release 6.0.2CF2|July 23, 2003) at 08/26/2003 05:36:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [eap] Josh Mendel/HQ/ISC is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Aug 2003 17:36:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 I will be out of the office starting 08/26/2003 and will not return until 09/02/2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 27 08:39:10 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22248 for ; Wed, 27 Aug 2003 08:39:09 -0400 (EDT) Received: (qmail 10631 invoked by uid 507); 27 Aug 2003 12:39:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 27 Aug 2003 12:39:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 10576 invoked by uid 507); 27 Aug 2003 12:38:46 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 27 Aug 2003 12:38:45 -0000 Received: from [10.0.1.4] (pm636-11.dialip.mich.net [207.75.181.117]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7RCcem21611; Wed, 27 Aug 2003 08:38:41 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba cc: eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage Message-ID: <310035.1061973522@[10.0.1.4]> In-Reply-To: References: <12383395.1061819177@[10.0.1.2]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 27 Aug 2003 08:38:43 -0400 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit --On Monday, August 25, 2003 3:45 PM -0700 Bernard Aboba wrote: > > This sounds like a real problem that should be handled. I am thinking > > this is better for 802.1x or other lower layer than for EAP. What do > > you think? > > It's hard for me to imagine that this would be correct behavior for an > implementation of EAP on any media -- so I think the fix belongs in RFC > 2284bis. I agree it is not correct, but I don't think EAP should specify what the lower layer does. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 07:19:08 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01934 for ; Thu, 28 Aug 2003 07:19:04 -0400 (EDT) Received: (qmail 9591 invoked by uid 507); 28 Aug 2003 11:19:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 11:19:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 9548 invoked by uid 507); 28 Aug 2003 11:18:23 -0000 Received: from mta05.mail.au.uu.net (HELO mta05.mail.mel.aone.net.au) (203.2.192.85) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 11:18:22 -0000 Received: from pc1 ([63.34.224.176]) by mta05.mail.mel.aone.net.au with SMTP id <20030828111818.VZKL17666.mta05.mail.mel.aone.net.au@pc1> for ; Thu, 28 Aug 2003 21:18:18 +1000 Message-ID: <003801c36d56$0f3f5650$ace4223f@pc1> From: "Ehsan Sakhaee" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C36DA9.E0571590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [eap] EAPOL or EAPOW Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 21:18:07 +1000 X-Virus-Scanned: by AMaViS 0.3.12 This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C36DA9.E0571590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the difference between a EAPOL and a EAPOW for a wireless 802.1x = implementation? ------=_NextPart_000_0035_01C36DA9.E0571590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the difference between a EAPOL = and a EAPOW=20 for a wireless 802.1x implementation?
 
------=_NextPart_000_0035_01C36DA9.E0571590-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 10:29:11 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19587 for ; Thu, 28 Aug 2003 10:29:08 -0400 (EDT) Received: (qmail 15591 invoked by uid 507); 28 Aug 2003 14:29:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 14:29:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 15541 invoked by uid 507); 28 Aug 2003 14:28:22 -0000 Received: from atlrel8.hp.com (156.153.255.206) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 14:28:21 -0000 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id 2EE641C02639; Thu, 28 Aug 2003 10:28:21 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 119FC1C000B0; Thu, 28 Aug 2003 10:28:21 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Aug 2003 10:28:20 -0400 Message-ID: <499DC368E25AD411B3F100902740AD651C62872B@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Ehsan Sakhaee'" , eap@frascone.com Subject: RE: [eap] EAPOL or EAPOW MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D70.9E6D3DF0" Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 10:28:15 -0400 X-Virus-Scanned: by AMaViS 0.3.12 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36D70.9E6D3DF0 Content-Type: text/plain No difference really. The term EAPOW really doesn't officially exist in any technical standard. In reality, there are some minor differences in the way EAPOL works on a wired network verses a wireless network. Basically, the main difference is that on wired networks you always use the group address (i.e.multicast address) as the destination. On wireless, once you know each other's address (which occurs after association) you use the individual address (i.e. unicast address) as the destination address. Paul -----Original Message----- From: Ehsan Sakhaee [mailto:ssakhaee@ozemail.com.au] Sent: Thursday, August 28, 2003 4:18 AM To: eap@frascone.com Subject: [eap] EAPOL or EAPOW What is the difference between a EAPOL and a EAPOW for a wireless 802.1x implementation? ------_=_NextPart_001_01C36D70.9E6D3DF0 Content-Type: text/html Message
No difference really.   The term EAPOW really doesn't officially exist in any technical standard.  In reality, there are some minor differences in the way EAPOL works on a wired network verses a wireless network.   Basically, the main difference is that on wired networks you always use the group address (i.e.multicast address) as the destination.  On wireless, once you know each other's address (which occurs after association) you use the individual address (i.e. unicast address) as the destination address.
 
Paul
-----Original Message-----
From: Ehsan Sakhaee [mailto:ssakhaee@ozemail.com.au]
Sent: Thursday, August 28, 2003 4:18 AM
To: eap@frascone.com
Subject: [eap] EAPOL or EAPOW

What is the difference between a EAPOL and a EAPOW for a wireless 802.1x implementation?
 
------_=_NextPart_001_01C36D70.9E6D3DF0-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 10:37:24 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20158 for ; Thu, 28 Aug 2003 10:37:09 -0400 (EDT) Received: (qmail 16284 invoked by uid 507); 28 Aug 2003 14:37:05 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 14:37:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 16186 invoked by uid 507); 28 Aug 2003 14:36:39 -0000 Received: from p-mail1.rd.francetelecom.com (195.101.245.15) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 14:36:38 -0000 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 16:36:10 +0200 Received: from francetelecom.com ([10.193.169.143]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 16:36:09 +0200 Message-ID: <3F4E1318.3000100@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Russ Housley (E-mail 3) ; \"Walker, Jesse\"" CC: eap@frascone.com Subject: [eap] Comments and questions on draft-jwalker-eap-archie-00.txt Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2003 14:36:09.0715 (UTC) FILETIME=[B8E36C30:01C36D71] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 16:35:04 +0200 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit Technical Comments

Par 2.1 : "secret nonces"
Why is it important that the nonces be secret, which is not IMHO a classic cryptographic setting ?

Par 2.1 : "If the unencrypted nonce value is random"
A nonce can well be a counter (i.e. non-random). The difference may be crucial as explained in your reference [11]
Maybe you should state that your nonces are in addition random values (which you do in Par 6.3.1 "All nonces used by EAP-Archie are 256-bits and are specified as random.") earlier in the draft.

Par 2.5 : "Note that the AES Key Wrap has its own internal integrity check. Potential evidence of compromise of the KCK is the AES Key Wrap integrity check of either NonceP or NonceS fails but the MAC of the Archie message delivering the nonce is valid."
How strong is the integrity check provided by the AES key wrap ?
Is this integrity check really useful ? IMHO if a KCK gets compromised, the corresponding LL-Key should immediately be revoked and scenarios in which the KCK gets compromised but not the KEK seem to me somehow unrealistic.

Par 6.3.1 :
I feel quite uncomfortable with your use of [12].
I tend to think that it is not a good idea to raw CBC-MAC variable-length messages (regardless whether you know the lengths of the messages in advance or not). If my maths is still right MAC1, 2 and 3 are calculated over different lengths - which could be by the way stated in the document).
I don't yet see a damaging attack on CBC-MAC as used in EAP-Archie (maybe there isn't any) but I (conservatively) think the results of [12] do not directly apply and require a little more work to get a proof of EAP-Archie's security.

6.3.2 : "AES used in CBC-MAC mode provide message integrity against all other forgery attacks provided AES is not broken [12]"
I think this is not guaranteed by [12] see above

Editorial comments :

Page 1 : Two expiration dates
Remove "Expiration: September 2003"

Par 2.1 : "A successful instance of the Archie protocol establishes a session, sometimes also called a security association."
Maybe a reference to "draft-aboba-pppext-key-problem-07.txt" could help stating that this document refers to such an association as an EAP SA.

Par 2.1 :"MAC1 is a message authentication code computed over the Archie-Request's AuthID field and the prior Archie-Response message fields."
There seems to be a slight inconsistency between this formulation and the formula of page 17 "MAC1 = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | Archie-Response(Type...Binding))"

Par 2.1 : "Binding is the addressing information the EAP Peer believes it is using during this session. It indicates the identifier the EAP Peer uses for itself, as well as that of its intended communication partner, which is typically some sort of Network Access Server (NAS)."
Maybe a concrete example could help (for instance in the 802.11 context)

Par 2.1 : "MAC2 is a message authentication code computed over the Archie Request's AuthID field, the Archie-Response's NonceP field, followed by the prior Archie-Confirm fields"
Slight inconsistency (similar to the one for MAC1) with the formula page 25 "MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | Archie-Response(Type...Bindings))"

Par 2.5 : [10] has evolved to "draft-aboba-pppext-key-problem-07.txt", hence I feel a relabeling is necessary.
In my understanding,
The EAP-Archie long-lived key is the EAP Master Key (MK)
There is no TEK derivation per se within EAP-Archie (they are not needed)
The Master Session Key and Extended Master Session Key's derivation procedure need to be respecified
There is no IV derivation
All the other keys (especially the TSKs are out of the scope of EAP-Archie)

"The derived EMK is uniquely identified by the 5-tuple <AuthID, PeerID, SessionID, AuthNonce, PeerNonce>, where AuthID is the NAI the EAP Server presents in the Archie-Request message, PeerID is the NAI the EAP Peer presents in the Archie-Response message, SessionID is the random challenge value the EAP Server presents in the Archie-Request message, and where AutheNonce and PeerNonce are as above."

This should be changed according to draft-aboba-pppext-key-problem-07.txt :

EAP SA name
     The EAP security association is negotiated between the EAP peer and
     EAP server, and is uniquely named as follows <EAP peer name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the EAP peer name and EAP server name are the identifiers
     securely exchanged within the EAP method.  Since multiple EAP SAs
     may exist between an EAP peer and EAP server, the EAP peer nonce
     and EAP server nonce allow EAP SAs to be differentiated.  The
     inclusion of the Method Type in the EAP SA name ensures that each
     EAP method has a distinct EAP SA space.

MSK Name
     The MSK is named by the concatenation of the EAP SA name, "MSK" and
     the authenticator name, since the MSK may only be bound to a single
     authenticator.  While the AAA server has several potentially unique
     authenticator identifiers (including the NAS-Identifier, NAS-IP-
     Address, and NAS-IPv6-Address attributes), only the Called-Station-
     Id is guaranteed to be known by the EAP peer, EAP server and
     authenticator and as a result, this is used as the NAS name.

I suggest inserting a reference to draft-aboba-pppext-key-problem-07.txt and removing all the text apart perhaps a mapping between the terminology in EAP-Archie and the terminology in draft-aboba-pppext-key-problem-07.txt which should be the same

Par 2.5 : "the final 32 octets (512 bits)"
Change to the final 32 octets (256 bits)

Par 4.3.2 : " MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | Archie-Response(Type...Bindings))
Change to "MAC2 = ..."

Par 4.4.2 : "MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | Archie-Response(NonceP) | Archie-Confirm(Type...Bindings))"
Change to "MAC3 = ..."

Par 6.3.4
Maybe a word on the Binding field could be inserted in this section.

Par 6.4 : See remarks on Par 2.5

Questions :
Where does the name EAP-Archie come from ?
Is there any cryptanalytic analysis of the AES Key Wrap algorithm available ?

Florent
_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 14:02:25 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05299 for ; Thu, 28 Aug 2003 14:02:17 -0400 (EDT) Received: (qmail 23361 invoked by uid 507); 28 Aug 2003 18:02:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 18:02:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 23299 invoked by uid 507); 28 Aug 2003 18:01:05 -0000 Received: from hermes.py.intel.com (146.152.216.3) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 18:01:05 -0000 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.78 2003/08/27 22:23:27 dmccart Exp $) with ESMTP id h7SHu1L27644 for ; Thu, 28 Aug 2003 17:56:02 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7SI0S903444 for ; Thu, 28 Aug 2003 18:00:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082811002330285 ; Thu, 28 Aug 2003 11:00:23 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 11:00:23 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D8E.40972574" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Comments and questions on draft-jwalker-eap-archie-00.txt Message-ID: Thread-Topic: [eap] Comments and questions on draft-jwalker-eap-archie-00.txt Thread-Index: AcNte+teq3GB6kJ5TDGKu9mLSAQxfQADpM5w From: "Walker, Jesse" To: "Florent Bersani" Cc: X-OriginalArrivalTime: 28 Aug 2003 18:00:23.0788 (UTC) FILETIME=[40E292C0:01C36D8E] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 11:00:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 This is a multi-part message in MIME format. ------_=_NextPart_001_01C36D8E.40972574 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Florent, =20 Thank you for your comments. Here are some response. Par 2.1 : "secret nonces" Why is it important that the nonces be secret, which is not IMHO a = classic cryptographic setting ?[Walker, Jesse] This is not really = necessary. It was done as a mechanism to hide a little bit more entropy = that gets mixed into the derived session key. The encryption can be = removed if that's what poeple want. Doing so will not harm the security = of the protocol. Par 2.1 : "If the unencrypted nonce value is random" A nonce can well be a counter (i.e. non-random). The difference may be = crucial as explained in your reference [11] Maybe you should state that your nonces are in addition random values = (which you do in Par 6.3.1 "All nonces used by EAP-Archie are 256-bits = and are specified as random.") earlier in the draft.[Walker, Jesse] The = specification already requires that the unencrypted nonces are random. = See, e.g., 4.3.1 and 4.4.1.=20 Par 2.5 : "Note that the AES Key Wrap has its own internal integrity = check. Potential evidence of compromise of the KCK is the AES Key Wrap = integrity check of either NonceP or NonceS fails but the MAC of the = Archie message delivering the nonce is valid." How strong is the integrity check provided by the AES key wrap ?[Walker, = Jesse] I haven't seen a careful analysis of the AES key wrap's = integrity, so can't answer the question.=20 Is this integrity check really useful ? IMHO if a KCK gets compromised, = the corresponding LL-Key should immediately be revoked and scenarios in = which the KCK gets compromised but not the KEK seem to me somehow = unrealistic. [Walker, Jesse] If folks want to drop encryption of the = nonces, then this integrity check won't contribute anything! Par 6.3.1 :=20 I feel quite uncomfortable with your use of [12]. I tend to think that it is not a good idea to raw CBC-MAC = variable-length messages (regardless whether you know the lengths of the = messages in advance or not). If my maths is still right MAC1, 2 and 3 = are calculated over different lengths - which could be by the way stated = in the document).[Walker, Jesse] We are not using CBC-MAC over variable = length messages. Each message has a well-defined, fixed length. If we = allowed variable length messages then extension attacks against the = protocol are enabled. The downside of fixed length messages is that = every field in the bindings field must be the maximum size of any value = that can occur, whereas in reality most of this space will never be = used, so is wasted bits. One way around this problem would be to replace = CBC-MAC with, e.g., OMAC. Another approach would be to ditch AES and use = something like HMAC-SHA1 instead. That would also address the concern = that you raise, which I do not believe is valid. I don't yet see a damaging attack on CBC-MAC as used in EAP-Archie = (maybe there isn't any) but I (conservatively) think the results of [12] = do not directly apply and require a little more work to get a proof of = EAP-Archie's security. [Walker, Jesse] I will incorporate all the editorial comments in the = next version; thanks.=20 -- Jesse =20 ------_=_NextPart_001_01C36D8E.40972574 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Florent,
 
Thank=20 you for your comments. Here are some response.
Par=20 2.1 : "secret nonces"
Why is it important that the nonces be = secret, which=20 is not IMHO a classic cryptographic setting ?[Walker,=20 Jesse] This is not really necessary. It was done as a mechanism=20 to hide a little bit more entropy that gets mixed into=20 the derived session key. The encryption can be removed if that's = what=20 poeple want. Doing so will not harm the security of the=20 protocol.

Par 2.1 : "If the unencrypted nonce = value is=20 random"
A nonce can well be a counter (i.e. non-random). The = difference may=20 be crucial as explained in your reference [11]
Maybe you should = state that=20 your nonces are in addition random values (which you do in Par 6.3.1 = "All=20 nonces used by EAP-Archie are 256-bits and are specified as random.") = earlier=20 in the draft.[Walker, Jesse] The specification already requires that = the=20 unencrypted nonces are random. See, e.g., 4.3.1 and=20 4.4.1. 

Par 2.5 : = "Note that=20 the AES Key Wrap has its own internal integrity check. Potential = evidence of=20 compromise of the KCK is the AES Key Wrap integrity check of either = NonceP or=20 NonceS fails but the MAC of the Archie message delivering the nonce is = valid."
How strong is the integrity check provided by the AES key = wrap=20 ?[Walker,=20 Jesse] I haven't seen a careful analysis of the AES key wrap's = integrity,=20 so can't answer the question. 
Is this integrity = check=20 really useful ? IMHO if a KCK gets compromised, the corresponding = LL-Key=20 should immediately be revoked and scenarios in which the KCK gets = compromised=20 but not the KEK seem to me somehow unrealistic. [Walker, = Jesse] If =20 folks want to drop encryption of the nonces, then this integrity = check=20 won't contribute anything!

Par 6.3.1 : =
I feel=20 quite uncomfortable with your use of [12].
I tend to think that it = is not a=20 good idea to raw CBC-MAC variable-length messages (regardless whether = you know=20 the lengths of the messages in advance or not). If my maths is still = right=20 MAC1, 2 and 3 are calculated over different lengths - which could be = by the=20 way stated in the document).[Walker, Jesse]  We are not using CBC-MAC = over variable=20 length messages. Each message has a well-defined, fixed = length. If=20 we allowed variable length messages then extension attacks against the = protocol are enabled. The downside of fixed length messages is that = every=20 field in the bindings field must be the maximum size of any value that = can=20 occur, whereas in reality most of this space will never be used, so is = wasted=20 bits. One way around this problem would be to replace CBC-MAC with, = e.g.,=20 OMAC. Another approach would be to ditch AES and use something like = HMAC-SHA1=20 instead. That would also address the concern that you raise, which I = do not=20 believe is valid.
I don't yet see a damaging attack = on=20 CBC-MAC as used in EAP-Archie (maybe there isn't any) but I = (conservatively)=20 think the results of [12] do not directly apply and require a little = more work=20 to get a proof of EAP-Archie's security.

[Walker,=20 Jesse] I will incorporate all the editorial comments in the = next=20 version; thanks. 

-- Jesse

 

------_=_NextPart_001_01C36D8E.40972574-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 18:05:19 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23167 for ; Thu, 28 Aug 2003 18:05:19 -0400 (EDT) Received: (qmail 17752 invoked by uid 507); 28 Aug 2003 22:05:10 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 22:05:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 17630 invoked by uid 507); 28 Aug 2003 22:04:03 -0000 Received: from straightnochaser.mr.itd.umich.edu (141.211.125.39) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 22:04:01 -0000 Received: from [10.0.1.4] (pm477-17.dialip.mich.net [207.75.179.171]) by straightnochaser.mr.itd.umich.edu (3.7s) with ESMTP id h7SM3rf24390; Thu, 28 Aug 2003 18:03:53 -0400 (EDT) From: John Vollbrecht To: Bernard Aboba cc: Alper Yegin , eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage Message-ID: <5838224.1062093838@[10.0.1.4]> In-Reply-To: References: <12403683.1061819515@[10.0.1.2]> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 18:03:59 -0400 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit --On Monday, August 25, 2003 3:47 PM -0700 Bernard Aboba wrote: > > I think it is in the lower layer state machine. EAP should not be > > called to run on a link with a lot of other stuff on it - seems to me. > > If it isn't called at the wrong time it doesn't need to say don't use > > the link. > > Actually, it's the EAP state machine that controls whether the port is > perceived to be usable to send data traffic, not the other way around. > My understanding is that the lower layer takes care of the port. The lower layer sets PortEnabled to go to a start state. It then sends eapReq and gets eapResp or eapNoResp. When done it sets either eapSuccess or eapFailure. The lower layer is responible for transmitting packets over the Link. EAP does not know if this is being done with other packets or not. EAP does authentication not port control. > > Other ways of doing this seem to make it hard to do reauthentication on > > an existing stream. > > Are you saying that the current EAP state machine does not correctly > handle reauthentication? > No. What I was thinking about was if the NAS/AP decides to reauthenticate after some time, without taking the port down. I believe this works fine. It takes some work on the port side, but should work with 802.1aa. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 28 18:52:29 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27360 for ; Thu, 28 Aug 2003 18:52:28 -0400 (EDT) Received: (qmail 22631 invoked by uid 507); 28 Aug 2003 22:52:10 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 22:52:08 -0000 Delivered-To: eap@frascone.com Received: (qmail 22553 invoked by uid 507); 28 Aug 2003 22:51:23 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 22:51:21 -0000 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h7SMpGIv019972; Fri, 29 Aug 2003 07:51:16 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h7SMpGs6007295; Fri, 29 Aug 2003 07:51:16 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA07294 ; Fri, 29 Aug 2003 07:51:16 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA01987; Fri, 29 Aug 2003 07:51:15 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA01052; Fri, 29 Aug 2003 07:51:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h7SMpE5H018028; Fri, 29 Aug 2003 07:51:14 +0900 (JST) Received: from localhost ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HKC00L03Q5B09@tsbpo1.po.toshiba.co.jp>; Fri, 29 Aug 2003 07:51:13 +0900 (JST) From: Yoshihiro Ohba Subject: Re: [eap] Issue 168: Peer link usage In-reply-to: <5838224.1062093838@[10.0.1.4]> To: John Vollbrecht Cc: Bernard Aboba , Alper Yegin , eap@frascone.com Message-id: <20030828224924.GJ26446@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 60 References: <12403683.1061819515@[10.0.1.2]> <5838224.1062093838@[10.0.1.4]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 15:49:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 I agree with John. EAP should just starts authentication when requested by a lower-layer and returns a success/failure result (and EAP-specific additional information such as MSKs if any) when authentication completes. (Of course EAP messages are passed between EAP entity and lowe-layer entity during authentication). It should be the responsibility of the lower-layer to determine whether to filter data packets on the port based on the authentication result and lower-layer specific states. Having said that, I think the portEnabled variable in the state machie draft should be renamed to some generic name like eapStarted, which provides the same level of abstraction as eapSuccess/eapFailure variables. And I also think that eapRestart and eapBackendRestart are redundant and can be deleted. Yoshihiro Ohba On Thu, Aug 28, 2003 at 06:03:59PM -0400, John Vollbrecht wrote: > > > --On Monday, August 25, 2003 3:47 PM -0700 Bernard Aboba > wrote: > > >> I think it is in the lower layer state machine. EAP should not be > >> called to run on a link with a lot of other stuff on it - seems to me. > >> If it isn't called at the wrong time it doesn't need to say don't use > >> the link. > > > >Actually, it's the EAP state machine that controls whether the port is > >perceived to be usable to send data traffic, not the other way around. > > > My understanding is that the lower layer takes care of the port. The lower > layer sets PortEnabled to go to a start state. It then sends eapReq and > gets eapResp or eapNoResp. When done it sets either eapSuccess or > eapFailure. > > The lower layer is responible for transmitting packets over the Link. EAP > does not know if this is being done with other packets or not. EAP does > authentication not port control. > > > >> Other ways of doing this seem to make it hard to do reauthentication on > >> an existing stream. > > > >Are you saying that the current EAP state machine does not correctly > >handle reauthentication? > > > No. What I was thinking about was if the NAS/AP decides to reauthenticate > after some time, without taking the port down. I believe this works fine. > It takes some work on the port side, but should work with 802.1aa. > > > > > _______________________________________________ > 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 eap-admin@frascone.com Thu Aug 28 19:04:19 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28242 for ; Thu, 28 Aug 2003 19:04:18 -0400 (EDT) Received: (qmail 24204 invoked by uid 507); 28 Aug 2003 23:04:09 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 28 Aug 2003 23:04:07 -0000 Delivered-To: eap@frascone.com Received: (qmail 24162 invoked by uid 507); 28 Aug 2003 23:03:57 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 28 Aug 2003 23:03:55 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7SMWRH01136; Thu, 28 Aug 2003 15:32:27 -0700 From: Bernard Aboba To: Yoshihiro Ohba cc: John Vollbrecht , Alper Yegin , eap@frascone.com Subject: Re: [eap] Issue 168: Peer link usage In-Reply-To: <20030828224924.GJ26446@steelhead> Message-ID: References: <12403683.1061819515@[10.0.1.2]> <5838224.1062093838@[10.0.1.4]> <20030828224924.GJ26446@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 15:32:27 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 > lower-layer to determine whether to filter data packets on the port > based on the authentication result and lower-layer specific states. EAP is media independent, which implies that the result of an EAP conversation has to be the same on any media; EAP-Success needs to mean the same thing on PPP, IEEE 802.1, IEEE 802.11, etc. Same with failure. So I don't think we can say that the result is dependent on the link layer. RFC 2284bis doesn't say this now -- in several places it talks about "enabling the link". _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 29 07:14:48 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11749 for ; Fri, 29 Aug 2003 07:14:48 -0400 (EDT) Received: (qmail 8629 invoked by uid 507); 29 Aug 2003 11:14:11 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 29 Aug 2003 11:14:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 8551 invoked by uid 507); 29 Aug 2003 11:13:30 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 29 Aug 2003 11:13:28 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C8A746A902; Fri, 29 Aug 2003 14:13:26 +0300 (EEST) Message-ID: <3F4F34AC.9060606@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] design team update Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 14:10:36 +0300 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit Two announcements regarding design teams in the EAP WG: 1. We've had the EAP State Machine Design Team running for some time now. Given that the documents appear relatively stable (modulo the discussion on how to represent AAA and passthrough in them) and most discussion happens on the main list, we are now closing down this team. We expect that there is still a fair amount of editorial and documentation work left, and some issues. It is important that we can publish the document soon as an RFC, so we'd like the current editors, design team members and everyone else to still work hard on this. The next steps are publishing a new revision and reviewing that, also ensuring issue resolutions satisfy everyone. 2. The completion of the keying framework seems essential for understanding EAP's security properties and ensuring that we fullfill the requirements laid out for them. In addition, some of the discussion on e.g. SA naming has an effect to link layers such as 802.11i and their protocols. For these reasons we are establishing a new design team to complete the keying framework. Some keying specialists have already been invited to the team. Additional volunteers are welcome -- if you are interested in contributing, let the chairs know. The team works through weekly conference calls, short position papers, and e-mail discussion. We intend to report weekly to the main list, as we did with the state machine team when it was in its active period. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 29 11:02:51 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01017 for ; Fri, 29 Aug 2003 11:02:49 -0400 (EDT) Received: (qmail 22047 invoked by uid 507); 29 Aug 2003 15:02:11 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 29 Aug 2003 15:02:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 21973 invoked by uid 507); 29 Aug 2003 15:01:03 -0000 Received: from p-mail2.rd.francetelecom.com (195.101.245.16) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 29 Aug 2003 15:01:01 -0000 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Aug 2003 17:00:32 +0200 Received: from francetelecom.com ([10.193.169.143]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Aug 2003 17:00:31 +0200 Message-ID: <3F4F6A4E.1060206@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Walker, Jesse" CC: eap@frascone.com Subject: Re: [eap] Comments and questions on draft-jwalker-eap-archie-00.txt References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2003 15:00:31.0901 (UTC) FILETIME=[4AD50CD0:01C36E3E] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 16:59:26 +0200 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit Jesse,

Many thanks for your answer, here some remarks to your response :

Walker, Jesse wrote:
Florent,
 
Thank you for your comments. Here are some response.
Par 6.3.1 :
I feel quite uncomfortable with your use of [12].
I tend to think that it is not a good idea to raw CBC-MAC variable-length messages (regardless whether you know the lengths of the messages in advance or not). If my maths is still right MAC1, 2 and 3 are calculated over different lengths - which could be by the way stated in the document).[Walker, Jesse]  We are not using CBC-MAC over variable length messages. Each message has a well-defined, fixed length. If we allowed variable length messages then extension attacks against the protocol are enabled. The downside of fixed length messages is that every field in the bindings field must be the maximum size of any value that can occur, whereas in reality most of this space will never be used, so is wasted bits. One way around this problem would be to replace CBC-MAC with, e.g., OMAC. Another approach would be to ditch AES and use something like HMAC-SHA1 instead. That would also address the concern that you raise, which I do not believe is valid.
I don't yet see a damaging attack on CBC-MAC as used in EAP-Archie (maybe there isn't any) but I (conservatively) think the results of [12] do not directly apply and require a little more work to get a proof of EAP-Archie's security.
I meant that if you CBC-MAC messages of different lengths with the same key even if their lengths are fixed, you may be in trouble and the results of [12] (i.e the security proof) do not apply

Assume for instance that you CBC-MAC with the same key K, messages of type 1 always consisting of one blocks (fixed length) and messages of type 2 always consisting  of two blocks (fixed length), then you can easily forge messages (with what you call extensions attacks) :
if I you get
MAC1 = MAC(a) (a being a one-block message of type 1)
MAC2 = MAC(b) (b being a one-block message of type 2)
then you can forge a MAC for the following two block-message of type 2 : a||(b xor MAC1) (its MAC is indeed MAC2)
(of course, you have to forge messages that make sense for the protocol but it is a common assumption in cryptography not to rely on such a weak protection)

My point is just to demonstrate that we cannot use the security proof of [12], it is quite lucky that the MAC lengths used in EAP-Archie (1120 bytes, 892 bytes and 36 bytes, if I am right) do not directly combine neatly - like 1120, 896 and 32 for instance - for an attacker. Still the door is open for the attacker and we are by no way under the umbrella of provable security.

I agree with your proposed solutions. As you suggest, why not use a mode that gives us the security we are looking for : e.g OMAC (standardized by NIST) (or RMAC, EMAC... - or even MACs like HMAC-SHA1) ?
 


Par 2.1 : "If the unencrypted nonce value is random"
A nonce can well be a counter (i.e. non-random). The difference may be crucial as explained in your reference [11]
Maybe you should state that your nonces are in addition random values (which you do in Par 6.3.1 "All nonces used by EAP-Archie are 256-bits and are specified as random.") earlier in the draft.[Walker, Jesse] The specification already requires that the unencrypted nonces are random. See, e.g., 4.3.1 and 4.4.1.
OK, I had noticed you mentioned that your nonces were in fact random values. My concern was the confusion that could arise for non-specialists, which could be damaging if random values are indeed needed for the security. Maybe adding the following text to the terminology section (1.2) :

Nonce : A nonce is a (cryptographic) value used at most once within the same context. A counter or a random (non-repeating) value can be used as a nonce. In some cases, it is necessary for the security of a protocol that the nonces be random values and therefore cannot be predicted.
 
and the following text at the end of Overview of EAP-Archie (Par 2.1)  :

Note : all nonces within EAP-Archie are supposed to be random values and thus unpredictable. This is crucial for the security of EAP-Archie


Par 2.5 : "Note that the AES Key Wrap has its own internal integrity check. Potential evidence of compromise of the KCK is the AES Key Wrap integrity check of either NonceP or NonceS fails but the MAC of the Archie message delivering the nonce is valid."
How strong is the integrity check provided by the AES key wrap ?[Walker, Jesse] I haven't seen a careful analysis of the AES key wrap's integrity, so can't answer the question. 
Is this integrity check really useful ? IMHO if a KCK gets compromised, the corresponding LL-Key should immediately be revoked and scenarios in which the KCK gets compromised but not the KEK seem to me somehow unrealistic. [Walker, Jesse] If  folks want to drop encryption of the nonces, then this integrity check won't contribute anything!

I just wanted to understand better the cryptographic properties of the AES key wrap

Florent
_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 29 13:48:48 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17757 for ; Fri, 29 Aug 2003 13:48:47 -0400 (EDT) Received: (qmail 32034 invoked by uid 507); 29 Aug 2003 17:48:11 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 29 Aug 2003 17:48:10 -0000 Delivered-To: eap@frascone.com Received: (qmail 31985 invoked by uid 507); 29 Aug 2003 17:47:27 -0000 Received: from h195n1fls311o871.telia.com (HELO riesling.local.levkowetz.com) (213.64.174.195) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 29 Aug 2003 17:47:25 -0000 Received: (qmail 9965 invoked from network); 29 Aug 2003 17:47:22 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 29 Aug 2003 17:47:22 -0000 From: Henrik Levkowetz To: "EAP" Message-Id: <20030829194722.44c1ffb5.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.Lk?_+CH,NZasV?" Subject: [eap] 2284bis draft updated Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 19:47:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 --=.Lk?_+CH,NZasV? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I have now updated the 2284bis draft with all issues marked EAP-05 on the issues page, leaving only issues 167 and 168 left to incorporate when the discussions have settled. The latest intermediate draft ( -05.k) is as usual available at http://www.levkowetz.com/ietf/drafts/eap Best regards, Henrik --=.Lk?_+CH,NZasV? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/T5GqeVhrtTJkXCMRAraKAKC/hikExY5p0prRgfCdKz8WNJWlIgCfX36N 4j4EgKVYq5qJwKoyZ3XS1rA= =KrP9 -----END PGP SIGNATURE----- --=.Lk?_+CH,NZasV?-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 29 21:53:05 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27436 for ; Fri, 29 Aug 2003 21:53:04 -0400 (EDT) Received: (qmail 23928 invoked by uid 507); 30 Aug 2003 01:52:11 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 30 Aug 2003 01:52:10 -0000 Delivered-To: eap@frascone.com Received: (qmail 23894 invoked by uid 507); 30 Aug 2003 01:51:52 -0000 Received: from ringding.cs.umd.edu (128.8.129.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 30 Aug 2003 01:51:51 -0000 Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.9/8.12.5) with ESMTP id h7U1pOiB000160; Fri, 29 Aug 2003 21:51:24 -0400 (EDT) From: Nick Petroni To: Bernard Aboba cc: Subject: Re: [eap] Issue 168: Peer link usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 21:51:24 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 > > lower-layer to determine whether to filter data packets on the port > > based on the authentication result and lower-layer specific states. > > EAP is media independent, which implies that the result of an EAP > conversation has to be the same on any media; EAP-Success needs to mean > the same thing on PPP, IEEE 802.1, IEEE 802.11, etc. Same with failure. IMHO, "EAP-Success" does mean the same thing- EAP is an authentication protocol and the authentication is still valid. I think access control should be orthogonal to authentication, although it should be clearly stated that if you are basing that access on authentication then it's probably a good idea not to open the link. > So I don't think we can say that the result is dependent on the link > layer. RFC 2284bis doesn't say this now -- in several places it talks > about "enabling the link". I don't see how the "result" is dependent even if you allow traffic during the conversation, but I agree that the language is misleading. By "enabling" it seems the draft really means any secure channel based on that authentication. I may not be framing that argument precisely enough, but I tend to agree with John and Yoshihiro- it's up to the lower layer to utilize the authentication decision as it sees fit. nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 30 02:18:38 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24610 for ; Sat, 30 Aug 2003 02:18:37 -0400 (EDT) Received: (qmail 2986 invoked by uid 507); 30 Aug 2003 06:18:10 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 30 Aug 2003 06:18:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 2938 invoked by uid 507); 30 Aug 2003 06:17:27 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 30 Aug 2003 06:17:26 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7U5k8e11132 for ; Fri, 29 Aug 2003 22:46:08 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed Resolution of Issue 168: Reject Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 22:46:07 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 It has been pointed out that the specific conditions under which data frames may be sent are specific to the lower layer. For example, in PPP it is not possible to send data until after NCP completes. In IEEE 802.11, data frames cannot be sent except in State 3. So it is probably best to leave this issue to the lower layer. The proposed resolution is to reject this issue. Any objections? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 30 02:34:20 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25424 for ; Sat, 30 Aug 2003 02:34:18 -0400 (EDT) Received: (qmail 3302 invoked by uid 507); 30 Aug 2003 06:23:10 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 30 Aug 2003 06:23:08 -0000 Delivered-To: eap@frascone.com Received: (qmail 3230 invoked by uid 507); 30 Aug 2003 06:22:05 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 30 Aug 2003 06:22:03 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7U5okv11376 for ; Fri, 29 Aug 2003 22:50:46 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed resolution to Issue 167: Cleartext Passwords Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 22:50:46 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 The text of Issue 167 is enclosed below. The proposed resolution is as follows: Proposed fix: In Section 5.5, add to the end of the "Description" paragraph: "The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords." In Section 5.6, add to the end of the "Description" paragraph: "The EAP GTC method is intended for use with the Token Cards supporting challenge/response authentication and MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication." Add Section 7.14: "7.14 Cleartext Passwords EAP does not support cleartext password authentication. This ommission is intentional. Where EAP is carried over physically insecure lower layers, including wireless LANs [IEEE80211] or the Internet, use of cleartext passwords would allow the password to be captured by an attacker with access to the lower layer. Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not provide confidentiality, even where the lower layer is physically secure, EAP frames may be subsequently encapsulated for transport over the Internet where they may be captured by an attacker. As a result, cleartext passwords cannot be securely used within EAP, except where encapsulated within a protected tunnel with server authentication." --------------------------------------------------------------- Issue 167: Cleartext Passwords in EAP Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/14/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-August/001599.html Document: RFC2284bis Comment type: T Priority: S Section: 5.5, 5.6 Rationale/Explanation of issue: Reading Section 5.5 and 5.6, it is not made crystal clear that the EAP OTP and GTC methods are not intended to provide support for cleartexst passwords. In Section 5.5, add to the end of the "Description" paragraph: "The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords." In Section 5.6, add to the end of the "Description" paragraph: "The EAP GTC method is intended for use with the Token Cards supporting challenge/response authentication and MUST NOT be used to provide support for cleartext passwords." [Pasi Eronen] Hi, GTC can also be used with PEAP/TTLS to support password databases that store a one-way hash of the password. When used this way, it's not that insecure either (not worse than e.g. SSH). This use is mentioned e.g. in http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf I think it's safe to assume that in the absence of some other solution, people will use GTC for this with IKEv2 as well. This is probably not such a bad idea in many cases, since the alternative is to store the password (or password-equivalent) in clear (deploying SRP or something similar doesn't seem realistic any time soon). So, perhaps something like "The EAP GTC method MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication, such as PEAP or IKEv2." would be sufficient? [BA] Several problems with this: a. On the AAA server side, protocols such as RADIUS do not mandate confidentiality, and there is no support for "hiding" of the EAP-Message attribute in the way that the User-Password attribute is hidden. That means that any cleartext password sent via an EAP method will be exposed on the wire from the NAS to the RADIUS server. Since protocols such as EAP TTLS support "early termination" where the tunnel is terminated on a different server (e.g. a proxy) than the final exchange, this results in a cleartext password sent over a portion of the path. [Joe Salowey] Even worse the intemediaries/NAS know the password. However it is possible to deploy PEAP and TTLS so the protection is all the way to the validating server. b. Even if the RADIUS User-Password attribute is used, this creates a number of vulnerabilities, including known plaintext attacks. If the Request Authenticator repeats on any NAS with the same shared secret an attacker would potentially be able to crack the User-Password attribute, which is encrypted with a stream cipher dependent only on the shared secret and the RA. [Joe Salowey] I completely agree. The introduction of cleartext passwords into EAP therefore represents a substantial security vulnerability -- and one which was purposefully left out of RFC 2284. [Joe Salowey] While I would rather not see cleartext passwords, I'm not sure that this represent a substantial security vulnerability if deployed properly. In this case that would be in a server side authenticated tunnel such as (TTLS/PEAP) that extends all the way to the EAP server validating the password. This was not available when 2284 was concieved. If you are going to advocate the use of passwords you're protected tunel must be server authenticated and extend all the way to the AAA that does the password validation. Intermediaries/NASes should never see the password. Specifing that EAP-OTP and EAP-GTC should not be used for cleartext passwords is good because they can be used without PEAP/TTLS. I think it is up to PEAP/TTLS to define how and if clear text passwords may be used within these tunnels and can define specific mechanisms to do this. If they do allow this then they should specify that the that the protected tunnel MUST extend all the way to the EAP-Server that validates the passwords and authenticates this server to the client. Tunnel client MUST NOT send a cleartext password unless it has authenticated the EAP-Server and has determined that it is authorized to receive the password. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Aug 31 06:10:07 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04277 for ; Sun, 31 Aug 2003 06:10:05 -0400 (EDT) Received: (qmail 8322 invoked by uid 507); 31 Aug 2003 10:09:11 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 31 Aug 2003 10:09:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 8262 invoked by uid 507); 31 Aug 2003 10:08:02 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 31 Aug 2003 10:08:00 -0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7VA7tB19634 for ; Sun, 31 Aug 2003 13:07:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 31 Aug 2003 13:07:55 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 31 Aug 2003 13:07:55 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 31 Aug 2003 13:07:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution to Issue 167: Cleartext Passwords Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BBBB@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution to Issue 167: Cleartext Passwords Thread-Index: AcNuwavoNGbCy9JSRPGCbnHNHVlTywA5bZ+Q From: To: , X-OriginalArrivalTime: 31 Aug 2003 10:07:47.0587 (UTC) FILETIME=[BA82ED30:01C36FA7] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 31 Aug 2003 13:07:46 +0300 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: quoted-printable Looks ok to me.=20 Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Saturday, August 30, 2003 8:51 AM > To: eap@frascone.com > Subject: [eap] Proposed resolution to Issue 167: Cleartext Passwords >=20 >=20 > The text of Issue 167 is enclosed below. The proposed=20 > resolution is as follows: >=20 > Proposed fix: > In Section 5.5, add to the end of the "Description" paragraph: >=20 > "The EAP OTP method is intended for use with the One-Time=20 > Password system only, and MUST NOT be used to provide=20 > support for cleartext passwords." >=20 > In Section 5.6, add to the end of the "Description" paragraph: >=20 > "The EAP GTC method is intended for use with the Token Cards=20 > supporting challenge/response authentication and MUST NOT be=20 > used to provide support for cleartext passwords in the absence=20 > of a protected tunnel with server authentication." >=20 > Add Section 7.14: >=20 > "7.14 Cleartext Passwords >=20 > EAP does not support cleartext password authentication. This > ommission is intentional. Where EAP is carried over physically > insecure lower layers, including wireless LANs [IEEE80211] or > the Internet, use of cleartext passwords would allow the password > to be captured by an attacker with access to the lower layer. >=20 > Since protocols encapsulating EAP, such as RADIUS [RFC3579], > may not provide confidentiality, even where the lower layer > is physically secure, EAP frames may be subsequently > encapsulated for transport over the Internet where they > may be captured by an attacker. >=20 > As a result, cleartext passwords cannot be securely used > within EAP, except where encapsulated within a protected > tunnel with server authentication." >=20 > --------------------------------------------------------------- > Issue 167: Cleartext Passwords in EAP > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/14/2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-August/001599.html > Document: RFC2284bis > Comment type: T > Priority: S > Section: 5.5, 5.6 > Rationale/Explanation of issue: >=20 > Reading Section 5.5 and 5.6, it is not made crystal clear=20 > that the EAP OTP > and GTC methods are not intended to provide support for cleartexst > passwords. >=20 > In Section 5.5, add to the end of the "Description" paragraph: >=20 > "The EAP OTP method is intended for use with the One-Time=20 > Password system > only, and MUST NOT be used to provide support for cleartext=20 > passwords." >=20 > In Section 5.6, add to the end of the "Description" paragraph: >=20 > "The EAP GTC method is intended for use with the Token Cards=20 > supporting > challenge/response authentication and MUST NOT be used to=20 > provide support > for cleartext passwords." >=20 > [Pasi Eronen] > Hi, >=20 > GTC can also be used with PEAP/TTLS to support password > databases that store a one-way hash of the password. > When used this way, it's not that insecure either (not > worse than e.g. SSH). This use is mentioned e.g. in > http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf >=20 > I think it's safe to assume that in the absence of some > other solution, people will use GTC for this with IKEv2 > as well. >=20 > This is probably not such a bad idea in many cases, > since the alternative is to store the password (or > password-equivalent) in clear (deploying SRP or > something similar doesn't seem realistic any time soon). >=20 > So, perhaps something like "The EAP GTC method MUST NOT > be used to provide support for cleartext passwords in the > absence of a protected tunnel with server authentication, > such as PEAP or IKEv2." would be sufficient? >=20 > [BA] Several problems with this: >=20 > a. On the AAA server side, protocols such as RADIUS do not mandate > confidentiality, and there is no support for "hiding" of the=20 > EAP-Message > attribute in the way that the User-Password attribute is hidden. That > means that any cleartext password sent via an EAP method will=20 > be exposed > on the wire from the NAS to the RADIUS server. Since=20 > protocols such as > EAP TTLS support "early termination" where the tunnel is=20 > terminated on a > different server (e.g. a proxy) than the final exchange, this=20 > results in a > cleartext password sent over a portion of the path. >=20 > [Joe Salowey] Even worse the intemediaries/NAS know the=20 > password. However > it is possible to deploy PEAP and TTLS so the protection is=20 > all the way to > the validating server. >=20 > b. Even if the RADIUS User-Password attribute is used, this creates a > number of vulnerabilities, including known plaintext attacks. If the > Request Authenticator repeats on any NAS with the same shared=20 > secret an > attacker would potentially be able to crack the User-Password=20 > attribute, > which is encrypted with a stream cipher dependent only on the shared > secret and the RA. >=20 > [Joe Salowey] I completely agree. >=20 > The introduction of cleartext passwords into EAP therefore=20 > represents a > substantial security vulnerability -- and one which was=20 > purposefully left > out of RFC 2284. >=20 > [Joe Salowey] While I would rather not see cleartext=20 > passwords, I'm not > sure that this represent a substantial security vulnerability=20 > if deployed > properly. In this case that would be in a server side authenticated > tunnel such as (TTLS/PEAP) that extends all the way to the EAP server > validating the password. This was not available when 2284 was=20 > concieved. > If you are going to advocate the use of passwords you're=20 > protected tunel > must be server authenticated and extend all the way to the=20 > AAA that does > the password validation. Intermediaries/NASes should never see the > password. Specifing that EAP-OTP and EAP-GTC should not be used for > cleartext passwords is good because they can be used without=20 > PEAP/TTLS. >=20 > I think it is up to PEAP/TTLS to define how and if clear text=20 > passwords > may be used within these tunnels and can define specific mechanisms to > do this. If they do allow this then they should specify that the that > the protected tunnel MUST extend all the way to the EAP-Server that > validates the passwords and authenticates this server to the client. > Tunnel client MUST NOT send a cleartext password unless it has > authenticated the EAP-Server and has determined that it is=20 > authorized to > receive the password. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap