From eap-admin@frascone.com Sun Feb 1 03:43:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01709 for ; Sun, 1 Feb 2004 03:43:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09370204E5; Sun, 1 Feb 2004 03:32:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB8A920246; Sun, 1 Feb 2004 03:32:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 323D620246 for ; Sun, 1 Feb 2004 03:32:00 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A1EE320221 for ; Sun, 1 Feb 2004 03:31:58 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id E29F46A904; Sun, 1 Feb 2004 10:43:10 +0200 (EET) Message-ID: <401CBBC1.4040007@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: "eap@frascone.com" Subject: Re: [eap] network selection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 01 Feb 2004 10:41:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Can we look at this from routing perspective, and say access networks > provide L1-L2 service, home network provides L3 service? I get my IP address > from my home network's domain (like the ISP when I connect via a DSL line). There may be a distinction between the network giving you an IP address and the network that you have a subscription with. For instance, my home ISP could be in Finland, but when I go to U.S. the local hotspot operator could give me an IP address even if they ship the the authentication request back to my home operator in accordance with their roaming agreement. >>There may or may not be a VPN service associated with this. If you >>don't think about companies but ISPs with a roaming service instead, >>you can probably see the non-VPN case: users would just get access >>through the local ISP, but their packets would be routed directly to >>the Internet. > > > But where do I get the IP address from? If it is from my "home ISP" but the > packets are forwarded to the Internet directly via "local ISP", then ingress > filtering is an issue. This is why I VPN'ed the packets. Ah, yes the VPN scenario is possible. But I think in the above you are assuming that the users would somehow get a stable home address. If they just get a dynamic IP address from the place they are, there is no problem with ingress filtering. I'm not saying that it has to be done this way. Just that there appears to be different ways of doing it: either your home network gives you both the IP address and handles your authentication, or that the two tasks are separated. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From diameter-admin@frascone.com Sun Feb 1 05:13:15 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04671 for ; Sun, 1 Feb 2004 05:13:15 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A830920515 for ; Sun, 1 Feb 2004 05:02:00 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE9F920532 for ; Sun, 1 Feb 2004 05:00:51 -0500 (EST) Date: Sun, 01 Feb 2004 05:00:51 -0500 Message-ID: <20040201100051.8556.63275.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Sun Feb 1 06:41:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07907 for ; Sun, 1 Feb 2004 06:41:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5652B20510; Sun, 1 Feb 2004 06:30:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16FEF204F3; Sun, 1 Feb 2004 06:30:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B45020504 for ; Sun, 1 Feb 2004 06:29:16 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 88AAE2024D for ; Sun, 1 Feb 2004 06:29:14 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 4AA8C6A904; Sun, 1 Feb 2004 13:40:28 +0200 (EET) Message-ID: <401CE54F.2050607@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lortz, Victor" Cc: eap@frascone.com Subject: Re: [eap] network selection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 01 Feb 2004 13:38:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Lortz, Victor wrote: > Jari, I agree that the user's device needs to take care of the selection > of AAA routing. There may be some setup procedure to configure user > preferences, but once that is done, the device should automatically > determine when and how to specify the routing. I also agree that a > default route should be provided. That is why I mentioned that one can > establish a default long distance provider for a phone line. In > retrospect, I should have made this point more clear: I think there > should both be a default route and a mechanism for the user's machine to > specify a desired route. Based on your comments below, I think we are > in agreement. Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 1 18:00:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15439 for ; Sun, 1 Feb 2004 18:00:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1ABC82054F; Sun, 1 Feb 2004 17:49:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2ADBE20245; Sun, 1 Feb 2004 17:49:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D17A720270 for ; Sun, 1 Feb 2004 17:48:08 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3386620245 for ; Sun, 1 Feb 2004 17:48:06 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i11NCSH32360; Sun, 1 Feb 2004 15:12:32 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Issue 213: Cleanup issues In-Reply-To: <00c601c3dfdb$ebed86b0$0300000a@amer.cisco.com> Message-ID: References: <00c601c3dfdb$ebed86b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 1 Feb 2004 15:12:27 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] Here again we have a mix of authentication and authorization. It > would be better to qualify the above statement. > > "Protected result indications > A method provides result indications if after the > method has finished: > > 1) When peer successfully completes the authentication, it > knows whether the authenticator has successfully completed the > authentication. > > 2) When the authenticator successfully completes the authentication, it > knows whether the peer has successfully completed the authentication. What about failure indications? > In the case where successful authentication is sufficient to authorize > access then the peer and authenticator will also know if the other party > is willing to provide or accept access. This may not always be the > case." I don't think this is compatible with Section 4.2, which says: As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods MAY implement protected result indications. After the authenticator sends a method-specific failure indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a method-specific success indication to the peer, and receives a method-specific success indication from the peer, it MUST subsequently send a Success packet. 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 peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. On the peer, after protected successful result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 1 22:57:28 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01082 for ; Sun, 1 Feb 2004 22:57:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3995620280; Sun, 1 Feb 2004 22:46:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 779D420281; Sun, 1 Feb 2004 22:46:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B689520277 for ; Sun, 1 Feb 2004 22:45:44 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id A5F3920281 for ; Sun, 1 Feb 2004 22:45:42 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i123usKW017906; Sun, 1 Feb 2004 19:56:54 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.246]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Feb 2004 20:02:48 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 213: Cleanup issues Message-ID: <006001c3e940$96a6abf0$0200000a@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: 02 Feb 2004 04:02:48.0498 (UTC) FILETIME=[6BAA6120:01C3E941] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 1 Feb 2004 19:56:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Sunday, February 01, 2004 3:12 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Issue 213: Cleanup issues > > > > [Joe] Here again we have a mix of authentication and > authorization. > > It would be better to qualify the above statement. > > > > "Protected result indications > > A method provides result indications if after the > > method has finished: > > > > 1) When peer successfully completes the authentication, it knows > > whether the authenticator has successfully completed the > > authentication. > > > > 2) When the authenticator successfully completes the > authentication, > > it knows whether the peer has successfully completed the > > authentication. > > What about failure indications? > [Joe] Failure indications are harder to protect, but if the peer or authenticator receives a protected failure message that it can verify then it should assume that the authentication has not successfully completed. > > In the case where successful authentication is sufficient > to authorize > > access then the peer and authenticator will also know if the other > > party is willing to provide or accept access. This may not > always be > > the case." > > I don't think this is compatible with Section 4.2, which says: > [Joe] Which part is incompatible? > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. EAP methods MAY > implement protected result indications. After the authenticator > sends a method-specific failure indication to the peer, > regardless > of the response from the peer, it MUST subsequently > send a Failure > packet. After the authenticator sends a method-specific success > indication to the peer, and receives a method-specific success > indication from the peer, it MUST subsequently send a Success > packet. > > 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 peer MUST silently discard > Success packets and MAY silently discard Failure packets. As a > result, loss of a Failure packet need not result in a timeout. > > On the peer, after protected successful result indications have > been exchanged by both sides, a Failure packet MUST be silently > discarded. The peer MAY, in the event that an EAP > Success is not > received, conclude that the EAP Success packet was lost and that > authentication concluded successfully. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 2 01:59:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08755 for ; Mon, 2 Feb 2004 01:59:00 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B62782014D; Mon, 2 Feb 2004 01:47:16 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7972420533; Mon, 2 Feb 2004 01:47:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52AE520305 for ; Mon, 2 Feb 2004 01:46:28 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5657D2028B for ; Mon, 2 Feb 2004 01:46:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i127AsA29655 for ; Sun, 1 Feb 2004 23:10:54 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-TLS fast reconnect case 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, 1 Feb 2004 23:10:53 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In reviewing the EAP-TLS fast reconnect sequence, it would appear to me that: a. The server does not know whether the client has authenticated at the time it sends its FINISHED message, since all it has gotten from the client is the client.random, not any proof of authenticity. So the sending of the server FINISHED message is not an indication that the server has authenticated the client. b. However, once the server verifies that the sessionid is present in the cache, it knows the presumed client identity and can check authorization. If the client was not authorized (e.g. time of day is outside prescribed limits), once the server chooses server.random the new key can be derived and the server could send a protected TLS "unauthorized" alert. So if the server sends the FINISHED message instead with no alert, this indicates that the client will be authorized *if* the server can subsequently authenticate it. c. After the client receives server.RANDOM it can compute the new key, verify the server FINISHED MAC and then send its own FINISHED message. If the server FINISHED message fails to verify, the client can send a TLS alert, protected with the new key. If the FINISHED message can be verified, then the client has authenticated the server, but does not know whether the server has authenticated it. This implies that the client FINISHED message allows the server both to verify authentication as well as the client desire to access the network. d. The server receives the client FINISHED mesage and checks it. If the client FINISHED MAC is verified then the server has authenticated the client and an EAP Success is sent in reply. If the client FINISHED MAC fails to verify, the server is not able to send a TLS alert message, since the negotiation has completed. All that the server can do is send an EAP-Failure message. e. As a result of a-d, it appears to me that in a TLS fast reconnect that an attacker can forge a Success or Failure message and the client has to accept either one. In the case of a forged Success, the peer will attempt to send data using an incorrect key and the data will be discarded by the authenticator; eventually the peer will tiemout. In the case of a forged Failure, presumably the client will disconnect. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From 02900Tressa@attws.com Mon Feb 2 05:25:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01228 for ; Mon, 2 Feb 2004 05:25:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnbGy-0001SS-00 for eap-archive@ietf.org; Mon, 02 Feb 2004 05:25:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnbGI-0001Jj-00 for eap-archive@ietf.org; Mon, 02 Feb 2004 05:25:03 -0500 Received: from pcp04018484pcs.walngs01.pa.comcast.net ([68.80.29.189]) by ietf-mx with smtp (Exim 4.12) id 1AnbFF-0001C4-00; Mon, 02 Feb 2004 05:23:57 -0500 Received: from 0.72.121.81 by web579.mail.yahoo.com; Mon, 02 Feb 2004 06:22:55 -0400 Message-ID: From: "Leann Larios" <02900Tressa@attws.com> To: eap-archive@ietf.org Subject: Fw: Declined Application beta frazier blackguards Date: Mon, 02 Feb 2004 05:19:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--05386086104343405403" X-CS-IP: 44.13.169.4 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, SUBJ_HAS_SPACES autolearn=no version=2.60 ----05386086104343405403 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable






Ubloodroot delectable wastebasket bespeak constellate abs= tained welsh adorn be pant instantaneous=20. Npaulson still beaded chevali= er jobholder spiegel retrogressive syracuse poultry amuse belting squeegee= sworn carthage bloop warm hexadecimal asteroid corset stratford crumb abs= tinences deserve washington guam stipulate barcaroles ambush skullduggery = terry personal=20. Sgesticulate bestiaries operand canny betraying blockad= e trickery antipodean druid asymmetrical gourmet august quince rent attrac= tively wore ambrosia slapstick inducible balaclava hierarchy habeas arthri= tic gerhard telegraph awhile mushy suey embryology glimpse bellflower is m= urk cytosine espouse halocarbon stylus agave morphemic=20 Ianachronistic c= apacitate pedigree rumen airfares alacrity stylish begrimed princess sciat= ica beautician berthed unbidden spidery=20 . Ewhirligig salisbury parolee = peninsula=20. Rliquidate ibis betimes time zorn besting mausoleum throwbac= k champlain cake augustly burro lyons bimodal bilabial cabot banner centim= eter jurisprudential rot faint longish kirkpatrick madden absurdness gain = sears castle permeate talon seed fitchburg celebrate inconspicuous trivia = epitaph fraud archived cadaverous cookery geisha safeguard bestrides pax m= eaningful gosh cyanamid=20.Aaffirmation justinian margery alliance bin bin= dings miguel pauline timeworn aborts angular=20. Sarchitectonic metamorpho= sis beneficently skin lost endogamy mitt imponderable ruth turnover blocky= acquisitiveness apostates content canal appendectomies adjures armada erv= in flexural reese oligarchic gonzales carton stern married aspersion arson= s dugan hacienda irrefutable maier aggravate lookup bibliographies allegor= ist annoyingly chevrolet=20!!! Hasparagus adirondack espousal beatify free= stone bela smokehouse bullhead manage benedictory belgian hades bluefish a= lphanumerical vista vow applications transliterate tabu thuban arbitrary c= horine playtime assyria ahoy ancestrally alizarin studious afoul intake th= ey'd chiang boas albinisms plymouth shied=20 Zcement ravel amra collet gid= eon assailant apothegm stereo anchovy offbeat assassination imperishable g= ustafson meddle stab=20: Ysponsor ambiences gourd superstitious beloved ad= vents prerequisite amylase receptacle possession golden attest dichotomy m= innie snider sonic adduce aura patrimonial poplar contextual cairo mackere= l piggy=20! Zsomnolent aftermaths apprehensiveness altercate cicada respit= e peafowl arteriolosclerosis stanch bicentenary downtrend coo sudden box f= rosty boast amuses cluj roundup song mathematician beacons disyllable resu= lt tipperary retire agribusiness pediment vernacular beverage divisional i= ngratiate quirk=20=20 ----05386086104343405403-- From eap-admin@frascone.com Mon Feb 2 12:00:29 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22609 for ; Mon, 2 Feb 2004 12:00:28 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66E7520570; Mon, 2 Feb 2004 11:49:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 526461FF55; Mon, 2 Feb 2004 11:49:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 637951FF55 for ; Mon, 2 Feb 2004 11:48:51 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id AD0931FEF8 for ; Mon, 2 Feb 2004 11:48:49 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i12H02lV027671; Mon, 2 Feb 2004 09:00:03 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.246]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 09:05:56 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] EAP-TLS fast reconnect case Message-ID: <009701c3e9ad$ff6a33b0$0200000a@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: 02 Feb 2004 17:05:57.0068 (UTC) FILETIME=[D30928C0:01C3E9AE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 2 Feb 2004 09:00:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, This is along the lines of my understanding as well. eap-admin@frascone.com wrote: > In reviewing the EAP-TLS fast reconnect sequence, it would > appear to me > that: > > a. The server does not know whether the client has > authenticated at the time it sends its FINISHED message, > since all it has gotten from the client is the client.random, > not any proof of authenticity. So the sending of the server > FINISHED message is not an indication that the server has > authenticated the client. > > b. However, once the server verifies that the sessionid is > present in the cache, it knows the presumed client identity > and can check authorization. If the client was not authorized > (e.g. time of day is outside prescribed limits), once the > server chooses server.random the new key can be derived and > the server could send a protected TLS "unauthorized" alert. > So if the server sends the FINISHED message instead with no > alert, this indicates that the client will be authorized *if* > the server can subsequently authenticate it. > [Joe] I believe it is possible to have cases where authorization fails even though session resume completes successfully. > c. After the client receives server.RANDOM it can compute the > new key, verify the server FINISHED MAC and then send its own > FINISHED message. If the server FINISHED message fails to > verify, the client can send a TLS alert, protected with the > new key. If the FINISHED message can be verified, then the > client has authenticated the server, but does not know > whether the server has authenticated it. This implies that > the client FINISHED message allows the server both to verify > authentication as well as the client desire to access the network. > [Joe] In most client implementations this is probably true that the client will grant access. I'm not sure that this must be true in all cases. > d. The server receives the client FINISHED mesage and checks > it. If the client FINISHED MAC is verified then the server > has authenticated the client and an EAP Success is sent in > reply. If the client FINISHED MAC fails to verify, the > server is not able to send a TLS alert message, since the > negotiation has completed. All that the server can do is > send an EAP-Failure message. > > e. As a result of a-d, it appears to me that in a TLS fast > reconnect that an attacker can forge a Success or Failure > message and the client has to accept either one. In the case > of a forged Success, the peer will attempt to send data using > an incorrect key and the data will be discarded by the > authenticator; eventually the peer will tiemout. In the > case of a forged Failure, presumably the client will disconnect. > > _______________________________________________ > 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 Feb 2 12:25:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23621 for ; Mon, 2 Feb 2004 12:25:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49037201F1; Mon, 2 Feb 2004 12:14:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0421320298; Mon, 2 Feb 2004 12:14:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52A0920298 for ; Mon, 2 Feb 2004 12:13:39 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AF1DE201F1 for ; Mon, 2 Feb 2004 12:13:37 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3EAA26A901; Mon, 2 Feb 2004 19:24:52 +0200 (EET) Message-ID: <401E8787.7060605@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] EAP-TLS fast reconnect case References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 02 Feb 2004 19:23:19 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, I agree with what you write below. A few comments inline: > a. The server does not know whether the client has authenticated at the > time it sends its FINISHED message, since all it has gotten from the > client is the client.random, not any proof of authenticity. So the > sending of the server FINISHED message is not an indication that the > server has authenticated the client. Right. > b. However, once the server verifies that the sessionid is present in the > cache, it knows the presumed client identity and can check authorization. If the > client was not authorized (e.g. time of day is outside prescribed limits), > once the server chooses server.random the new key can be derived and the > server could send a protected TLS "unauthorized" alert. So if the server > sends the FINISHED message instead with no alert, this indicates that the > client will be authorized *if* the server can subsequently authenticate > it. I agree that we can do this, but does the above describe what we should do, what current implementations do, or what the existing RFCs say? I think we have a general weakness in most methods definitions with respect to the authorization issues. For instance, the word "authorization" does not appear in RFC 2716... and even more recent method specifications could be a lot more explicit about these issues. I'm hoping the implementors have gotten the checks right, however. The issue is similar to what we discussed ealier on fast handoff: authentication and AAA does more than pure authentication, and whatever you do, you always have to check for various authorizations. > c. After the client receives server.RANDOM it can compute the new key, > verify the server FINISHED MAC and then send its own FINISHED > message. If the server FINISHED message fails to verify, the client can > send a TLS alert, protected with the new key. If the FINISHED message can > be verified, then the client has authenticated the server, > but does not know whether the server has authenticated it. This implies > that the client FINISHED message allows the server both to verify > authentication as well as the client desire to access the network. Yes, and the client needs to make this decision before sending the FINISHED message. (I think Joe may be saying that it does not always happen.) > d. The server receives the client FINISHED mesage and checks it. If the > client FINISHED MAC is verified then the server has authenticated the > client and an EAP Success is sent in reply. If the client FINISHED MAC > fails to verify, the server is not able to send a TLS alert message, > since the negotiation has completed. All that the server can do is send > an EAP-Failure message. > e. As a result of a-d, it appears to me that in a TLS fast reconnect > that an attacker can forge a Success or Failure message and the client has > to accept either one. In the case of a forged Success, the peer will > attempt to send data using an incorrect key and the data will be discarded > by the authenticator; eventually the peer will tiemout. In the case of a > forged Failure, presumably the client will disconnect. Yes. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 2 14:05:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02990 for ; Mon, 2 Feb 2004 14:05:26 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 433FD1FEFF; Mon, 2 Feb 2004 13:54:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D821D1FF4E; Mon, 2 Feb 2004 13:54:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 262DD1FF4E for ; Mon, 2 Feb 2004 13:53:31 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 305BD1FEFF for ; Mon, 2 Feb 2004 13:53:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i12JHpv11644; Mon, 2 Feb 2004 11:17:51 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] EAP-TLS fast reconnect case In-Reply-To: <009701c3e9ad$ff6a33b0$0200000a@amer.cisco.com> Message-ID: References: <009701c3e9ad$ff6a33b0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 2 Feb 2004 11:17:51 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] I believe it is possible to have cases where authorization fails > even though session resume completes successfully. Essentially the session resume protocol requires that authorization be checked by the server before the server authenticates the client. If this is not possible for some reason (e.g. server doesn't want to leak authorization info to an unauthenticated client) then authorization can fail after a successful resume. In any case, the client has authenticated the server but doesn't know if the server has successfully authenticated it. So the client could be willing to accept access on that basis, but this is not a good idea, because it could bring up the interface and attempt unsuccessfully to obtain IP configuration because the authenticator denied access. As a result, the client has to accept a Failure packet if sent, and act on it. On the other hand, if the server fails to authenticate to the client, then the client won't access the network, and it won't accept a Success. The end result of this is that: a. An attacker can spoof an EAP Failure without fear of detection. b. An attacker can spoof an EAP Success; however, this will only fool the peer into accessing the network if it has successfully authenticated the server. If for some reason the real authenticator wasn't happy, the result will be a nasty timeout on the client. In both cases, the end result is a denial of service, nothing more. > [Joe] In most client implementations this is probably true that the > client will grant access. I'm not sure that this must be true in all > cases. The client does have the ability to send a TLS alert if it doesn't want to access the network for some reason, even though it has succesfully authenticated the server. So I think that this case is less likely. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 2 14:21:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03614 for ; Mon, 2 Feb 2004 14:21:24 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F00D2058A; Mon, 2 Feb 2004 14:10:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AAFF1FF5D; Mon, 2 Feb 2004 14:10:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C08D51FF5D for ; Mon, 2 Feb 2004 14:09:52 -0500 (EST) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 825101FF53 for ; Mon, 2 Feb 2004 14:09:50 -0500 (EST) Received: (qmail 21492 invoked from network); 2 Feb 2004 19:21:05 -0000 Received: from unknown (HELO mtghouse.com) (192.168.5.204) by deneb.mtghouse.com with SMTP; 2 Feb 2004 19:21:05 -0000 Message-ID: <401EA321.80802@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jrv@umich.edu, jari.arkko@piuha.net References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070603070505050304060102" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Strawman for a modified section 6.7 (V5) for IEEE 802.1XRev 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, 02 Feb 2004 14:21:05 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------070603070505050304060102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi folks, I have incorporated the input from folks and produced V5 of the draft of section 6.7 for IEEE 802.1XRev. The new text appears below preceded by a discussion of the changes that were made. In addition, I have attached a .txt file containing the table xxxx that will appear at the bottom of section 6.7 - view this .txt with a fixed width font (courier). I believe that this version is very close to the final draft (if not the final draft) Thanks again for all the input, send along any issues, concerns, comments you have on this, Jim B. ------------------------------------------- Version 5 changes: -Alter language to read more smoothly -Change reason for bi-directional transport in relation to .11 adhoc networks to better match the discussion in section 2.4 of 2284bis. -Remove the discussion of two bridges using a single authentication server. This does not work. -Change text describing why two bridges utilize the bi-directional transport. -Change the text describing the potential problems of a dual role device encountering a single authenticator role device to be more clear as to the elements that cause the problem. -Change the term ‘asymmetric data flow’ to ‘asymmetric controlled port state’ and change its definition to mean one side authorizes controlled port, the other does not. -Add a reference to 2284bis Section 2.4 in the paragraph that suggests that applications using 1X should define the 1X roles to be implemented. -Update language in table xxxx to be more precise. ----------------------------------------------------------------------- 6.7 Coupling two 802.1X authentications This section discusses the ability of 802.1X to run two simultaneous transports in opposite directions, how implementation asymmetries affect authentication results and how simultaneous bi-directional transport may be utilized. In 802.1X there is a requestor role (authenticator) and a responder role (supplicant). The authenticator transmits frames to the supplicant and the supplicant responds to those frames with frames of its own. 802.1X, like the authentication protocol carried within it (EAP), is a request/response protocol, and the state machines reflect this. Such a transport is sometimes called 'one-way' meaning the protocol exchanges always originate from one side (the requestor). However, it is not the 802.1X transport that controls whether the authentication is mutual or one-way. Rather, the chosen EAP method controls whether the authentication is mutual or one-way, and support for a supplicant controlled-port determines whether authorization is mutual or one-way. Despite the asymmetry of 802.1X and EAP transports, if a mutually authenticating EAP method (such as EAP-TLS) is carried within 802.1X frames, then the supplicant and authenticator can mutually authenticate. However, if an EAP method is chosen which only authenticates the supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), then the authentication will be one-way. In an earlier version of 802.1X (802.1X-2001), only the authenticator was specified to have a controlled port. The lack of a supplicant controlled port prevented mutual authentication from being enforced on both sides. However, this was due to the lack of a specification of the controlled port on the supplicant, not due to the one-way nature of the 802.1X transport protocol. The current version of 802.1X remedies this by specifying how both authenticator and supplicant roles affect the controlled port. In 802.1X, each role has its own state machine and it is possible that a single device can implement both the supplicant and authenticator roles (state machines). If a device implementing both roles encounters another device implementing both roles, then two separate (and simultaneous) 802.1X transports will take place in opposite directions. This is sometimes referred to as a bi-directional authentication transport or two coupled one-way authentication exchanges. 802.1X does not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. Two coupled one-way authentication exchanges are not equivalent in security to a single exchange of a mutually authenticating EAP method (such as EAP-TLS). Since the two coupled one-way authentication exchanges are not cryptographically bound together, there is no way to ascertain that the party involved in the first one-way exchange is the same party that is involved in the alternate one-way exchange. Even though a single 802.1X exchange may provide mutual authentication, there may be other reasons to run two 802.1X exchanges in opposite directions. RFC 2284bis, Section 2.4 discusses some of these cases, which include: 1) When the devices require the creation of separate key material in each direction but the keying protocol is uni-directional (as in the group handshake in 802.11 adhoc networks). 2) When different credentials are used for different roles (one credential for the supplicant role and one for the authenticator). 3) When two bridges are connected, each bridge may implement the Supplicant role, but may have authorization requirements that can only be enforced by the Authenticator ("Supplicant Access Control with Authenticator" variable set to inactive). When a device that implements both 802.1X roles on a single port encounters a device that implements only a single authenticator role, this may result in asymmetric controlled port state (the single role device authorizes its controlled port while the dual role device does not because its authenticator role has not been satisfied). A complete table of encounters and results appears in Table xxxx. It is suggested that applications utilizing 802.1X should specify which 802.1X roles must be implemented to avoid encounters that will result in failed network connections. See Section 2.4 of RFC 2284bis for other issues that may arise in peer-to-peer usage of EAP. Table xxxx: Result of encounters between 802.1X transport roles assuming key-generating EAP methods are run and authentication result is success. --------------070603070505050304060102 Content-Type: text/plain; name="updatedSection6.7 Table v5.txt" Content-Disposition: inline; filename="updatedSection6.7 Table v5.txt" Content-Transfer-Encoding: 7bit Remote\Local--> | Supplicant | Authenticator | Both | | | | V | | | ---------------------------------------------------------------------- Supplicant |Fails gracefully | Works | Works |No link will be | Authenticated | Authenticated |formed if media | link | link |is considered | Authentication | Authentication |unsafe without | policy is set by | policy set by |encryption | choice of EAP | choice of EAP |(802.11). | method. | method | | | Remote |Unauthenticated | | supplicant and |link will be | | local |formed if media | | authenticator |is considered | | are authorized. |safe by default | | Local |(802.3) | | supplicant will | | | receive no | | | response and | | | assume no | | | authenticator. | | | Successful | | | authentication | | | to the local | | | authenticator | | | will have made | | | the port | | | secure. ----------------------------------------------------------------------- Authenticator |Works - |Fails gracefully |Fails - |Authenticated |No link will be |Asymmetric link |link - |formed. Each |Remote |Authentication |authenticator |controlled port |policy set by |will send initial |is authorized, |choice of EAP |EAP requests but |but local |method. |no response will |controlled port | |arrive. |remains | | |unauthorized. | | |Remote | | |authenticator | | |and local | | |supplicant are | | |authorized, | | |local | | |authenticator | | |remains | | |unauthorized. ----------------------------------------------------------------------- Both |Works |Fails |Works |Authenticated |Asymmetric link | Authenticated |link |Local controlled | link |Authentication |port is | Authentication |policy set by |authorized, but | policy set by |choice of EAP |remote controlled | choice of two |method. |port remains | uncoupled EAP |Local supplicant |unauthorized. | methods. Two |and remote |Local | keys will be |authenticator |authenticator and | formed and some |are authorized. |remote supplicant | mechanism must |Remote |are authorized, | exist so that |supplicant will |remote | local and |receive no |authenticator | remote choose |response and |remains | the same key. |assume no |unauthorized. | |authenticator. | | |Successful | | |authentication | | |to the remote | | |authenticator | | |will have made | | |the port secure. | | ----------------------------------------------------------------------- --------------070603070505050304060102-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 2 14:35:24 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04334 for ; Mon, 2 Feb 2004 14:35:24 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7811B20597; Mon, 2 Feb 2004 14:24:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 711D51FF69; Mon, 2 Feb 2004 14:24:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6577920588 for ; Mon, 2 Feb 2004 14:23:36 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D27461FF69 for ; Mon, 2 Feb 2004 14:23:34 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 816716A902; Mon, 2 Feb 2004 21:34:50 +0200 (EET) Message-ID: <401EA5FD.2010906@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] EAP-TLS fast reconnect case References: <009701c3e9ad$ff6a33b0$0200000a@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 02 Feb 2004 21:33:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > The end result of this is that: > > a. An attacker can spoof an EAP Failure without fear of detection. > b. An attacker can spoof an EAP Success; however, this will only fool the > peer into accessing the network if it has successfully authenticated the > server. If for some reason the real authenticator wasn't happy, the > result will be a nasty timeout on the client. > > In both cases, the end result is a denial of service, nothing more. It seems that we are primarily using protected indications as a mechanism to inform the other side, not as a means to prevent attacks. Some possible PI designs appear rather weak, if you were to use them against attacks. For instance, if at any point you can accept either a Success or a method specific failure indication, attackers can spoof Success messages. Another design would have a mandatory result indication in any case, which would protect better against denial of service. Then again, the opportunities for denial of service are quite excellent in the messages prior to the establishment of keys, that it may not be worth the trouble. A third design integrates as many functions as possible, handling both auth & authz with the same messages. This may not be possible on all methods, however, if the necessary information is not available at the right time. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 2 15:08:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05884 for ; Mon, 2 Feb 2004 15:08:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DCAA20598; Mon, 2 Feb 2004 14:57:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29EDB1FF5C; Mon, 2 Feb 2004 14:57:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CC5B1FF5C for ; Mon, 2 Feb 2004 14:56:51 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 4C5701FF53 for ; Mon, 2 Feb 2004 14:56:49 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i12K7wN9029979; Tue, 3 Feb 2004 05:07:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i12K7vgg026931; Tue, 3 Feb 2004 05:07:57 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA26930 ; Tue, 3 Feb 2004 05:07:57 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA19680; Tue, 3 Feb 2004 05:07:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA06210; Tue, 3 Feb 2004 05:07:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i12K7tWH007296; Tue, 3 Feb 2004 05:07:56 +0900 (JST) Received: from steelhead ([159.119.168.164]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSH00MQA3X6J1@tsbpo1.po.toshiba.co.jp>; Tue, 3 Feb 2004 05:07:55 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AnkM8-0002lz-00; Mon, 02 Feb 2004 12:07:40 -0800 From: Yoshihiro Ohba Subject: Re: [eap] EAP-TLS fast reconnect case In-reply-to: <401EA5FD.2010906@piuha.net> To: Jari Arkko Cc: Bernard Aboba , Joseph Salowey , eap@frascone.com Message-id: <20040202200740.GP1035@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <009701c3e9ad$ff6a33b0$0200000a@amer.cisco.com> <401EA5FD.2010906@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 02 Feb 2004 12:07:40 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, Feb 02, 2004 at 09:33:17PM +0200, Jari Arkko wrote: > Bernard Aboba wrote: > > >The end result of this is that: > > > >a. An attacker can spoof an EAP Failure without fear of detection. > >b. An attacker can spoof an EAP Success; however, this will only fool the > >peer into accessing the network if it has successfully authenticated the > >server. If for some reason the real authenticator wasn't happy, the > >result will be a nasty timeout on the client. > > > >In both cases, the end result is a denial of service, nothing more. > > It seems that we are primarily using protected indications > as a mechanism to inform the other side, not as a means to > prevent attacks. > > Some possible PI designs appear rather weak, if you > were to use them against attacks. For instance, if at > any point you can accept either a Success or a method specific > failure indication, attackers can spoof Success messages. > Another design would have a mandatory result indication in > any case, which would protect better against denial of service. > Then again, the opportunities for denial of service are quite > excellent in the messages prior to the establishment of keys, > that it may not be worth the trouble. We are currently investigating a possibility for adding result indication in fast reconnect functionarity in EAP-IKEv2. Since EAP-IKEv2 is robuster than EAP-TLS against the DoS, including the messages prior to the establishment of keys, I think that adding result indication for EAP-IKEv2 fast reconnection might be worth doing (though it requires one additional roundtrip). So I think whether adding result indication is worth the trouble depends on EAP methods in use (in the case of TLS I agree with you.) Yoshihiro Ohba > > A third design integrates as many functions as possible, handling > both auth & authz with the same messages. This may not be possible > on all methods, however, if the necessary information is not available > at the right time. > > --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 Tue Feb 3 12:28:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20097 for ; Tue, 3 Feb 2004 12:28:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 601502033D; Tue, 3 Feb 2004 12:17:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A45F31FF96; Tue, 3 Feb 2004 12:17:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 471972033B for ; Tue, 3 Feb 2004 12:16:23 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6FBF21FF96 for ; Tue, 3 Feb 2004 12:16:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i13HefB31133 for ; Tue, 3 Feb 2004 09:40:42 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 218: TLS example 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, 3 Feb 2004 09:40:41 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 218: TLS example Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 2/2/2004 Reference: Document: RFC 2284bis-08.l Comment type: T Priority: S Section: 7.16 Rationale/Explanation of issue: Discussion of EAP-TLS has resulted in additional insight that should be reflected in the specification. Change Section 7.16 from: "7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing, as well as lengthy timeouts. To address this vulnerability, EAP methods may implement protected result indications. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. Result indications may be implicit or explicit. For example, a method may use error messages in order to explicitly indicate a failure, while the completion of mutual authentication and key derivation without an error message implicitly indicates a successful result. For example, within EAP-TLS [RFC2716], the peer always authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion (e.g. sends a FINISHED message), then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion (e.g. sends a FINISHED message). A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed." To: "7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing as well as denial of service attacks. As described in Section 4.2.1, a peer silently discards a Success packet received at a point where the method does not explicitly permit this to be sent. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet at a point in a method where the server has authenticated to the peer, but has not yet indicated that it is willing to grant access. If the server were to decide not to grant access, and a forged Success packet were to be accepted by the peer, a timeout can result. Where supported by the lower layer, this can be remedied by having the authenticator provide a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to grant access prior to determining whether the peer will accept it, then a timeout can result. This can be remedied in lower layers that allow the authenticator to sense the presence or absence of the peer. Method-specific success indications avoid these issues. In a method suporting success indications, a peer willing to accept access does not consider the authentication successful until receives an indication that the server is willing to grant access. In such a method, a server willing to grant access does not consider the authentication successful until it receives an indication that the peer is willing to accept access. Success indications may be explicit or implicit. For example, where a method supports error messages, a success indication may be defined as the completion of the method in the absence of an error message. Failure indications are typically explicit. As described in Section 4.2.1, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While this may be useful for debugging purposes, it will typically add a round-trip to the protocol. Where result indications are authenticated, integrity and replay protected, it is possible to to address spoofing vulnerabilities. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. However, since errors can occur prior to key derivation, it is typically not possible to protect all failure indications. A protocol may provide protected result indications in some circumstances, but not in others. For example, within EAP-TLS [RFC2716], in the full handshake the peer intially authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion (e.g. sends a FINISHED message), then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion (e.g. sends a FINISHED message). A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed. Since by the end of a successful full handshake both the peer and server are aware of each other's access decision, this mode of EAP-TLS provides for protected result indications. In the session resumption handshake, the peer and server may not be synchronized. After receiving the initial ClientHello message, the server can check whether the sessionid sent by the client is present in its cache. If so, it may check client authorization and send a TLS alert (a failure indication) if the client is not authorized. However, the client has not yet authenticated to the server so that the server's FINISHED message cannot be interpreted as a success indication. Once the peer receives the server FINISHED message it can verify it using the newly computed key and thereby authenticate the server. If the client does not wish to accept access, a TLS alert may be sent. Once the server receives the client FINISHED message, it verifies it using the newly computed key. As a result, the client FINISHED message can be considered a protected result indication. Since the client never receives a method-specific result indication from the server, as described in Section 4.2, if it has successfully authenticated the server, then it waits for a Success or Failure packet and must accept either of them. Of course, if the server FINISHED message cannot be verified then accepting a Success message is inappropriate. [BA - Does the language in Section 4.2 needs to be modified?]. This means that an attacker could forge a Success or Failure packet with impunity, although this would only result in denial of service." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 3 18:08:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11603 for ; Tue, 3 Feb 2004 18:08:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4900B20341; Tue, 3 Feb 2004 17:57:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 181962035D; Tue, 3 Feb 2004 17:57:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 389952035D for ; Tue, 3 Feb 2004 17:56:49 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 48FFB20341 for ; Tue, 3 Feb 2004 17:56:47 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5E0396A902; Wed, 4 Feb 2004 01:08:03 +0200 (EET) Message-ID: <40202974.8070800@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 04 Feb 2004 01:06:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, and thanks for the text. It looks good! I do have a few proposed changes though, inline, and a summary of the situation at the end: > "7.16 Protected Result Indications > > EAP Success and Failure packets are neither acknowledged nor > integrity protected. This creates a potential vulnerability > to spoofing as well as denial of service attacks. > > As described in Section 4.2.1, a peer silently discards a > Success packet received at a point where the method does not > explicitly permit this to be sent. Within a mutually authenticating > method, requiring that the server authenticate to the peer > before the peer will accept a Success packet prevents an attacker > from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success > packet at a point in a method where the server has > authenticated to the peer, but has not yet indicated that it > is willing to grant access. If the server were to > decide not to grant access, and a forged Success packet > were to be accepted by the peer, a timeout can > result. Where supported by the lower layer, this > can be remedied by having the authenticator provide a > lower layer failure indication to the peer. See > Section 7.12 for details. Yes. > If a server were to grant access prior to > determining whether the peer will accept it, then a > timeout can result. This can be remedied in lower layers > that allow the authenticator to sense the presence or > absence of the peer. > > Method-specific success indications avoid these > issues. In a method suporting success indications, It may be an overstatement to say "... avoid this issues", since it appears that such indications generally can not handle all cases. Maybe "... help avoid some of these issues"? > a peer willing to accept access does not consider > the authentication successful until receives an > indication that the server is willing to > grant access. > > In such a method, a server willing to > grant access does not consider the authentication > successful until it receives an indication that the > peer is willing to accept access. > > Success indications may be explicit or implicit. > For example, where a method supports error messages, > a success indication may be defined as the completion > of the method in the absence of an error message. Yes. Can we add "In general, an implicit success indication is the reception of a specific defined message without a preceding error message." > Failure indications are typically explicit. > > As described in Section 4.2.1, a peer silently > discards a Failure packet received at a point where > the method does not explicitly permit this to be sent. > For example, a method providing its own error > messages might require the peer to receive an > an error message prior to accepting a Failure packet. > While this may be useful for debugging purposes, > it will typically add a round-trip to the protocol. > > Where result indications are authenticated, > integrity and replay protected, it is possible to > to address spoofing vulnerabilities. Since protected > result indications require use of a key for per-packet > authentication and integrity protection, methods supporting > protected result indications MUST also support the > "key derivation", "mutual authentication" "integrity protection" > and "replay protection" claims. However, since errors can > occur prior to key derivation, it is typically not possible > to protect all failure indications. > > A protocol may provide protected result indications in some > circumstances, but not in others. For example, within > EAP-TLS [RFC2716], in the full handshake the peer intially authenticates > the server, and sends a TLS alert message in the event of an > authentication or authorization failure. If the server does not > receive a TLS alert message from the peer and the peer continues the > conversation to completion (e.g. sends a FINISHED message), then the > server can assume that the peer will accept access if granted it by > the server. I may not understand EAP-TLS completely, but I think there is something strange in the above, as it seems to imply that FINISHED is sent after the ALERT. But Section 3.8 of RFC 2716 shows a different order. But I may be missing something? > Similarly, the peer can assume that the server will grant access if > it does not receive a TLS alert message from the server, and the > server carries the conversation to completion (e.g. sends a FINISHED > message). > > A server may use the "access denied" TLS alert after successfully > authenticating the peer to indicate that a valid certificate was > received from the peer, but when access control was applied, the > server decided not to proceed. > > Since by the end of a successful full handshake both the peer and > server are aware of each other's access decision, this mode > of EAP-TLS provides for protected result indications. > > In the session resumption handshake, the peer and server may > not be synchronized. After receiving the initial ClientHello > message, the server can check whether the sessionid sent by the > client is present in its cache. If so, it may check client > authorization and send a TLS alert (a failure indication) > if the client is not authorized. However, the client has not > yet authenticated to the server so that the server's > FINISHED message cannot be interpreted as a success indication. > > Once the peer receives the server FINISHED message it can verify it > using the newly computed key and thereby authenticate the server. > If the client does not wish to accept access, a TLS alert may be sent. > Once the server receives the client FINISHED message, it verifies it > using the newly computed key. As a result, the client FINISHED > message can be considered a protected result indication. > > Since the client never receives a method-specific result indication from > the server, as described in Section 4.2, if it has successfully > authenticated the server, then it waits for a Success or > Failure packet and must accept either of them. Of course, if > the server FINISHED message cannot be verified then accepting > a Success message is inappropriate. [BA - Does the language in > Section 4.2 needs to be modified?]. This means that an attacker > could forge a Success or Failure packet with impunity, although > this would only result in denial of service." This looks correct. I also think 4.2 text looks sufficient in 08.n version of the draft. In summary, we have now a better understanding of what the indications are, and to what extent example methods provide them. This is much better than what we had before. I see two remaining parts of this issue that need to be discussed: 1. Joe's example (proxy authz decision) shows a case where protected indications can not provide full protection against lengthy timeouts. I think we need to document that as a limitation. Here's an attempt at the text, to be placed at the end of Section 7.16: While protected indications can provide information between the peer and the server, it is important to realize that issues outside these nodes may affect the decision to grant access. As a result, the sole use of protected result indications does not guarantee syncronization of state between the peer and the authenticator, or that timeouts do not occur. For instance, a the EAP server may not be aware of the authorization decision performed by a AAA proxy between the authenticator and the server. Or access can be granted, but the authenticator may find itself unable to provide access due to temporary lack of resources. In general, only the lower layer could provide information about this type of situations. 2. In discussing issue 212, we agreed that the reception of the key attribute implies succesful authentication, not authorization. Still, the text above talks about authorization and access control. Since we have only the key attribute to communicate whether the result is sufficient for peer-to-peer operation, there may be an inconsistency here. Or perhaps this is just a part of what item 1 above is saying, i.e., that we can provide some though not necessarily all authz via EAP? Comment or suggestions? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 3 20:25:47 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16088 for ; Tue, 3 Feb 2004 20:25:46 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4088B20378; Tue, 3 Feb 2004 20:14:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BD0F20370; Tue, 3 Feb 2004 20:14:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 698AF20370 for ; Tue, 3 Feb 2004 20:14:01 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5CE222036F for ; Tue, 3 Feb 2004 20:13:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i141cHA28395; Tue, 3 Feb 2004 17:38:17 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <40202974.8070800@piuha.net> Message-ID: References: <40202974.8070800@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 3 Feb 2004 17:38:17 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > It may be an overstatement to say "... avoid this issues", > since it appears that such indications generally can not > handle all cases. Maybe "... help avoid some of these > issues"? OK. Will incorporate. > > Success indications may be explicit or implicit. > > For example, where a method supports error messages, > > a success indication may be defined as the completion > > of the method in the absence of an error message. > > Yes. Can we add "In general, an implicit success indication > is the reception of a specific defined message without a > preceding error message." OK. Will incorporate. > I may not understand EAP-TLS completely, but I think there is > something strange in the above, as it seems to imply that FINISHED > is sent after the ALERT. But Section 3.8 of RFC 2716 shows a > different order. But I may be missing something? I'm not sure that the example in Section 3.8 is correct here. Once the server sends its FINISHED message, I believe that EAP TLS is complete on the server side. So an alert would typically be sent after change_cipher_spec and prior to the FINISHED message. > While protected indications can provide information between > the peer and the server, it is important to realize that issues > outside these nodes may affect the decision to grant access. As a > result, the sole use of protected result indications does not guarantee > syncronization of state between the peer and the authenticator, > or that timeouts do not occur. For instance, a the EAP server > may not be aware of the authorization decision performed by > a AAA proxy between the authenticator and the server. Or > access can be granted, but the authenticator may find itself > unable to provide access due to temporary lack of resources. > In general, only the lower layer could provide information > about this type of situations. I'll add this text. > 2. In discussing issue 212, we agreed that the reception of the > key attribute implies succesful authentication, not authorization. > Still, the text above talks about authorization and access control. > Since we have only the key attribute to communicate whether the > result is sufficient for peer-to-peer operation, there may be > an inconsistency here. Or perhaps this is just a part of what > item 1 above is saying, i.e., that we can provide some though > not necessarily all authz via EAP? The peer-to-peer issue was about whether both sides had sufficient knowledge to avoid two one-way auths if their policies enabled that to occur. In a mutually authenticating method, the peer would know whether the server was authenticated to it, and the server would know if the peer authenticated to it. When the authenticator receives an Accept with a key attribute it knows that both sides authenticated each other and that it is to provide access to the peer. Based on the authenticator policy it could decide that this is sufficient for it not to initiate an authentication in the other direction by sending an EAPOL-Start to the peer. This is really about whether the authenticator feels that it needs to confirm that the peer will authorize access on its end. On the peer side, it knows that the authenticator offered access and whether it will accept that access or not. It could decide that it needs to initiate authentication in the other direction, perhaps because there is insufficient authorization. In this case it can send an EAP-Request/Identity in the other direction. So in the end, I think this is more about authorization and policy than it is about protected result indications. I've looked at the text in section 2.4 and I don't think it is affected by these discussions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 3 22:46:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20327 for ; Tue, 3 Feb 2004 22:46:26 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 540C5201F6; Tue, 3 Feb 2004 22:35:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A893B20362; Tue, 3 Feb 2004 22:35:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C7C920362 for ; Tue, 3 Feb 2004 22:34:28 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id EEEDA201F6 for ; Tue, 3 Feb 2004 22:34:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i143wgB04716; Tue, 3 Feb 2004 19:58:42 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <40202974.8070800@piuha.net> Message-ID: References: <40202974.8070800@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 3 Feb 2004 19:58:42 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here's some revised text with your suggestions incorporated: "7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing as well as denial of service attacks. As described in Section 4.2.1, a peer silently discards a Success packet received at a point where the method does not explicitly permit this to be sent. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet at a point in a method where the server has authenticated to the peer, but has not yet indicated that it is willing to grant access. If the server were to decide not to grant access, and a forged Success packet were to be accepted by the peer, a timeout can result. Where supported by the lower layer, this can be remedied by having the authenticator provide a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to grant access prior to determining whether the peer will accept it, then a timeout can result. This can be remedied in lower layers that allow the authenticator to sense the presence or absence of the peer. Method-specific success indications help avoid these issues. In a method suporting success indications, a peer willing to accept access does not consider the authentication successful until receives an indication that the server is willing to grant access. In such a method, a server willing to grant access does not consider the authentication successful until it receives an indication that the peer is willing to accept access. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failure indications are typically explicit. As described in Section 4.2.1, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While this may be useful for debugging purposes, it will typically add a round-trip to the method. Where result indications are authenticated, integrity and replay protected, it is possible to to address spoofing vulnerabilities. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. However, since errors can occur prior to key derivation, it is typically not possible to protect all failure indications. While protected result indications may enable synchronization between the peer and the server, this does not guarantee that the peer and authenticator will be synchronized or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; or the EAP server may grant access, but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization can only be achieved via lower layer result indications. An EAP method may provide protected result indications in some circumstances, but not in others. For example, within EAP-TLS [RFC2716], in the full handshake the peer initially authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion, then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion (e.g. sends a FINISHED message). A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed. Since by the end of a successful full handshake both the peer and server are aware of each other's access decision, this mode of EAP-TLS provides for protected result indications. In the session resumption handshake, the peer and server may not be synchronized. After receiving the initial ClientHello message, the server can check whether the sessionid sent by the client is present in its cache. If so, it may check client authorization and send a TLS alert (a failure indication) if the client is not authorized. However, the client has not yet authenticated to the server so that the server's FINISHED message cannot be interpreted as a success indication. Once the peer receives the server FINISHED message it can verify it using the newly computed key and thereby authenticate the server. If the client does not wish to accept access, a TLS alert may be sent. Once the server receives the client FINISHED message, it verifies it using the newly computed key. As a result, the client FINISHED message can be considered a protected result indication. Since the client never receives a method-specific result indication from the server, as described in Section 4.2, if it has successfully authenticated the server, then it waits for a Success or Failure packet and must accept either of them. Of course, if the server FINISHED message cannot be verified then accepting a Success message is inappropriate. This means that an attacker could forge a Success or Failure packet with impunity, although this would only result in denial of service." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 05:11:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28679 for ; Wed, 4 Feb 2004 05:11:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10EA92039E; Wed, 4 Feb 2004 05:00:12 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 871882039F; Wed, 4 Feb 2004 05:00:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A60D20394 for ; Wed, 4 Feb 2004 04:59:12 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.frascone.com (Postfix) with ESMTP id 11211201EC for ; Wed, 4 Feb 2004 04:59:10 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i14AARo13335 for ; Wed, 4 Feb 2004 11:10:27 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i14AANw24247 for ; Wed, 4 Feb 2004 11:10:23 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 11:09:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0681@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Protected Result Indications (again) 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, 4 Feb 2004 11:10:06 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi all, i took a look at 'protected result indication' mailing list discussion. you seem to have discussed a number of issues: - Authorization failures It was raised that it is possible that authorization failure can be sent although authentication was successful. Typically, this message is transmitted from the server to the peer. It might be good to have a more fine-grain differentiation between the different authorization failures. - Synchronization problems Allowing the peer to observe whether the protocol run was successfully verified at the server (or even vice versa) in some cases it might even be necessary to provide key confirmation to ensure that the parties correctly executed the protocol exchange. A specifical case of the synchronization problem could be caused with some methods. If we would establish an eap-sa which is used between the eap peer and the eap server then "re-keying" issues would also play a role. For some EAP methods the eap-sa is simply deleted after the protocol exchange. - DoS attacks DoS attacks is a basically a broader category of the synchronization problems. Synchronization problems can also be caused by means which are not attacks In general, it is helpful to differentiate between different error cases. Some error cases cannot be protected and hence they should not be used to take an action. This is not unique for EAP but can be observed in many other protocols. Let us consider an eap method (which i am currently working on) based on ISO Symmetric Key Two-Pass Mutual Authentication. This discussion is more focused on DoS protection rather than on an authorizatio failure. EAP Peer EAP Server ======== ========== <--- EAP-Request/EAP-Type=EAP-XXX (EAP server to EAP peer authentication+key establishment) EAP-Response/EAP-Type=EAP-XXX ---> (EAP peer to EAP server authentication+key establishment) <--- EAP-Success/Failure Figure 1: Example protocol exchange Now there are the following cases: a) the EAP-Response message gets lost in this case the EAP-Request message will be retransmitted. b) an adversary modifies the second message and injects a bogus EAP-Success/Failure The EAP peer and the EAP server do not share a common view about the protocol execution in this case the EAP peer believes that the protocol was excuted Please note that an EAP peer might not process the EAP-Success/Failure since it is not protected. By "process" I mean that the message does not lead to an action since it is an unreliable trigger. c) an adversary modifies the EAP-Success/Failure message If the EAP peer does not process the message then it is difficult for the peer to find out whether the server was able to authenticate the peer. If the EAP peer processes the message (although it is not protected) then an adversary might cause incorrect actions to be triggered. an EAP-Success might be modified into an EAP-Failure. <--- EAP-Request/EAP-Type=EAP-XXX (EAP server to EAP peer authentication+key establishment) EAP-Response/EAP-Type=EAP-XXX ---> (EAP peer to EAP server authentication+key establishment) <--- EAP-Request/EAP-Type=EAP-XXX (confirmation) EAP-Response/EAP-Type=EAP-XXX ---> (dummy) <--- EAP-Success/Failure Figure 2: Protected result indication (additional roundtrip) A modified EAP-Success/Failure should not be considered since it provides no value. the dummy message is irrelevant and should not be taken into account except as a reliability mechanism that the message was processed. in some cases it is not possible to protect the confirmation message since it also serves as an error message. hence an adversary could forge this message to indicate an error. it then sends a dummy message to the server and gets an EAP-Success/Failure message in response. the state between the EAP server and the peer is out-of-synch. The same effect can be caused by using a 'regular authenticated' message instead of the dummy message. If the adversay modifies message #4 of Figure 2 then it could cause the server to believe that something is wrong. <--- EAP-Request/EAP-Type=EAP-XXX (EAP server to EAP peer authentication+key establishment) EAP-Response/EAP-Type=EAP-XXX ---> (EAP peer to EAP server authentication+key establishment) <--- Protected EAP-Success/Failure Figure 3: Protected result indication (optimized) The message flow described in Figure 2 can be optimized with the message flow in Figure 3. <--- EAP-Request/EAP-Type=EAP-XXX (EAP server to EAP peer authentication+key establishment) EAP-Response/EAP-Type=EAP-XXX ---> (EAP peer to EAP server authentication+key establishment) <--- Protected EAP-Success/Failure (out-of-band; not the same end points) Figure 4: Protected result indication (out-of-band) Instead of providing protection within the EAP method itself for the EAP-Success/Failure message it is also possible to protect the last (or a few) EAP payloads based on the master session key carried from the EAP server to the Authenticator. For example, PANA protects the final EAP-Success/Failure message carried within PANA. IKEv2, for example, protects the entire EAP exchange and therefore also the EAP-Success/Failure message. Please note that the end points of an out-of-band protection might not be the same in all cases. In particular, if the EAP server is not co-located with the Authenticator which is typically the case. Whenever a failure case has to be handled it is possible that an adversary injects an error message to make the EAP peer to believe that something went wrong. My conclusion from this is: DoS attacks are very hard (if not impossible) to prevent. To me the synchronization problems look very similar to the 'two army problem'. you can find a brief description at the following web page: http://www.eeng.may.ie/~tward/transportl/sld027.htm Furthermore, to describe the problem in more detail it is necessary to consider the different error cases. In which case is an error message protected and what information about the error is forwarded to the EAP peer. Particularly, Bernard seems to propose a mechanism for providing information about authorization failures in a protected fashion from the EAP server to the EAP peer. Due to its messaging behavior EAP is already quite heavy. Hence, it does not seem to be good to add yet another roundtrip. ciao hannes I would like to thank Dirk and Yoshi for their patience discussing various issues with me. btw, you can easily construct a dos attack with eap-archie. ----- EAP-Archie EAP Peer EAP Server ======== ========== <--- EAP-Request/EAP-Type=Archie (AuthID | SessionID) EAP-Response/EAP-Type=Archie ---> (SessionID | PeerID | NonceP | Binding | MAC1) <--- EAP-Request/EAP-Type=Archie (SessionID | NonceA | Binding | MAC2) EAP-Response/EAP-Type=Archie ---> (SessionID | MAC3) Figure 5. The EAP-Archie Message Flow assume that an adversary modified or dropped the last message. it does not matter whether the EAP peer "trusts" an eap success message (injected by the adversary) or not. with message (4) the EAP peer believes that the protocol exchange was successfully finished. The EAP server, however, will fail to correctly process the message and will not ship the session key to the Authenticator (via the AAA infrastructure). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 12:15:29 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15265 for ; Wed, 4 Feb 2004 12:15:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA4A1201FB; Wed, 4 Feb 2004 12:04:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 706F9203BF; Wed, 4 Feb 2004 12:04:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D5D8203BF for ; Wed, 4 Feb 2004 12:03:49 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id DF793201FB for ; Wed, 4 Feb 2004 12:03:47 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 02E2C6A902; Wed, 4 Feb 2004 19:15:06 +0200 (EET) Message-ID: <4021283A.5070308@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <40202974.8070800@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 04 Feb 2004 19:13:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I'm not sure that the example in Section 3.8 is correct here. Once the > server sends its FINISHED message, I believe that EAP TLS is complete on > the server side. So an alert would typically be sent after > change_cipher_spec and prior to the FINISHED message. It worries me that the RFC may not be clear on this. If its not, there can be implementations that do it in another manner than you assume. I agree it would make sense to do it as you explain, but maybe the implementor has read Section 3.8... Anyway, this is not a 2284bis issue. But we should keep that in mind for a possible future update of the EAP-TLS RFC or in discussions of what protection exists in EAP. > The peer-to-peer issue was about whether both sides had sufficient > knowledge to avoid two one-way auths if their policies enabled that to > occur. In a mutually authenticating method, the peer would know whether > the server was authenticated to it, and the server would know if > the peer authenticated to it. When the authenticator receives an > Accept with a key attribute it knows that both sides authenticated each > other and that it is to provide access to the peer. > > Based on the authenticator policy it could decide that this is sufficient > for it not to initiate an authentication in the other direction by sending > an EAPOL-Start to the peer. This is really about whether the > authenticator feels that it needs to confirm that the peer will authorize > access on its end. > > On the peer side, it knows that the authenticator offered access and > whether it will accept that access or not. It could decide that it needs > to initiate authentication in the other direction, perhaps because there > is insufficient authorization. In this case it can send an > EAP-Request/Identity in the other direction. I agree about all this, as long as we realize that an EAP layer access authorization may not be the whole story. But the text already describes this, so this part of the issue is now done. > So in the end, I think this is more about authorization and policy than it > is about protected result indications. I've looked at the text in section > 2.4 and I don't think it is affected by these discussions. Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 12:16:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15343 for ; Wed, 4 Feb 2004 12:16:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66FAC203BF; Wed, 4 Feb 2004 12:04:16 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D12F203C4; Wed, 4 Feb 2004 12:04:07 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D57E1203BF for ; Wed, 4 Feb 2004 12:03:59 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E0263201FB for ; Wed, 4 Feb 2004 12:03:57 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5BA986A903; Wed, 4 Feb 2004 19:15:16 +0200 (EET) Message-ID: <40212845.6030307@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <40202974.8070800@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 04 Feb 2004 19:13:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks good. A few nits inline. > Here's some revised text with your suggestions incorporated: > > "7.16 Protected Result Indications > > EAP Success and Failure packets are neither acknowledged nor > integrity protected. This creates a potential vulnerability > to spoofing as well as denial of service attacks. > > As described in Section 4.2.1, a peer silently discards a > Success packet received at a point where the method does not > explicitly permit this to be sent. Within a mutually authenticating > method, requiring that the server authenticate to the peer > before the peer will accept a Success packet prevents an attacker > from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success > packet at a point in a method where the server has > authenticated to the peer, but has not yet indicated that it > is willing to grant access. If the server were to > decide not to grant access, and a forged Success packet > were to be accepted by the peer, a timeout can > result. Where supported by the lower layer, this > can be remedied by having the authenticator provide a > lower layer failure indication to the peer. See > Section 7.12 for details. > > If a server were to grant access prior to > determining whether the peer will accept it, then a > timeout can result. This can be remedied in lower layers > that allow the authenticator to sense the presence or > absence of the peer. > > Method-specific success indications help avoid these s/these/some of these/? > issues. In a method suporting success indications, s/suporting/supporting/ > a peer willing to accept access does not consider > the authentication successful until receives an > indication that the server is willing to > grant access. > > In such a method, a server willing to grant access > does not consider the authentication successful > until it receives an indication that the > peer is willing to accept access. > > Success indications may be explicit or implicit. > For example, where a method supports error messages, > an implicit success indication may be defined as the > reception of a specific message without a > preceding error message. Failure indications > are typically explicit. > > As described in Section 4.2.1, a peer silently > discards a Failure packet received at a point where > the method does not explicitly permit this to be sent. > For example, a method providing its own error > messages might require the peer to receive an > an error message prior to accepting a Failure packet. > While this may be useful for debugging purposes, > it will typically add a round-trip to the method. > > Where result indications are authenticated, > integrity and replay protected, it is possible to > to address spoofing vulnerabilities. Since protected > result indications require use of a key for per-packet > authentication and integrity protection, methods supporting > protected result indications MUST also support the > "key derivation", "mutual authentication" "integrity protection" > and "replay protection" claims. However, since errors can > occur prior to key derivation, it is typically not possible > to protect all failure indications. > > While protected result indications may enable synchronization between > the peer and the server, this does not guarantee that the > peer and authenticator will be synchronized or that timeouts > will not occur. For example, the EAP server may not be > aware of an authorization decision made by a AAA proxy; or > the EAP server may grant access, but the authenticator may be > unable to provide it due to a temporary lack of resources. > In these situations, synchronization can only be achieved > via lower layer result indications. > > An EAP method may provide protected result indications in some > circumstances, but not in others. For example, within > EAP-TLS [RFC2716], in the full handshake the peer initially authenticates > the server, and sends a TLS alert message in the event of an > authentication or authorization failure. If the server does not > receive a TLS alert message from the peer and the peer continues the > conversation to completion, then the server can assume that the peer will > accept access if granted it by the server. > > Similarly, the peer can assume that the server will grant access if > it does not receive a TLS alert message from the server, and the > server carries the conversation to completion (e.g. sends a FINISHED > message). > > A server may use the "access denied" TLS alert after successfully > authenticating the peer to indicate that a valid certificate was > received from the peer, but when access control was applied, the > server decided not to proceed. > > Since by the end of a successful full handshake both the peer and > server are aware of each other's access decision, this mode > of EAP-TLS provides for protected result indications. > > In the session resumption handshake, the peer and server may > not be synchronized. After receiving the initial ClientHello > message, the server can check whether the sessionid sent by the > client is present in its cache. If so, it may check client > authorization and send a TLS alert (a failure indication) > if the client is not authorized. However, the client has not > yet authenticated to the server so that the server's > FINISHED message cannot be interpreted as a success indication. > > Once the peer receives the server FINISHED message it can verify it > using the newly computed key and thereby authenticate the server. > If the client does not wish to accept access, a TLS alert may be sent. > Once the server receives the client FINISHED message, it verifies it > using the newly computed key. As a result, the client FINISHED > message can be considered a protected result indication. > > Since the client never receives a method-specific result indication from > the server, as described in Section 4.2, if it has successfully > authenticated the server, then it waits for a Success or > Failure packet and must accept either of them. Of course, if > the server FINISHED message cannot be verified then accepting > a Success message is inappropriate. This means that an attacker > could forge a Success or Failure packet with impunity, although > this would only result in denial of service." Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 12:34:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16523 for ; Wed, 4 Feb 2004 12:34:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9C2D201FB; Wed, 4 Feb 2004 12:23:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09AF5203C0; Wed, 4 Feb 2004 12:23:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B34A8203C0 for ; Wed, 4 Feb 2004 12:22:19 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id E2346201FB for ; Wed, 4 Feb 2004 12:22:17 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2004 09:39:47 +0000 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 i14HXVDI015789; Wed, 4 Feb 2004 09:33:32 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.246]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 09:39:24 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: Subject: RE: [eap] Issue 218: TLS example Message-ID: <01f201c3eb45$00876590$0200000a@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: 04 Feb 2004 17:39:25.0483 (UTC) FILETIME=[D4F877B0:01C3EB45] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 4 Feb 2004 09:33:23 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, I think this is better. I still don't like the linking of successful authentication with granting access since this is an implementation specific behavior. Successful authentication is generally required, but not sufficient for authorization to grant access. Additional comments in-line below. Joe eap-admin@frascone.com wrote: > Here's some revised text with your suggestions incorporated: > > "7.16 Protected Result Indications > > EAP Success and Failure packets are neither acknowledged nor > integrity protected. This creates a potential vulnerability > to spoofing as well as denial of service attacks. > > As described in Section 4.2.1, a peer silently discards a > Success packet received at a point where the method does not > explicitly permit this to be sent. Within a mutually > authenticating method, requiring that the server authenticate > to the peer before the peer will accept a Success packet > prevents an attacker from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success > packet at a point in a method where the server has > authenticated to the peer, but has not yet indicated that it > is willing to grant access. If the server were to decide not > to grant access, and a forged Success packet were to be > accepted by the peer, a timeout can result. Where supported > by the lower layer, this can be remedied by having the > authenticator provide a lower layer failure indication to the > peer. See Section 7.12 for details. > > If a server were to grant access prior to > determining whether the peer will accept it, then a > timeout can result. This can be remedied in lower layers > that allow the authenticator to sense the presence or > absence of the peer. > > Method-specific success indications help avoid these > issues. In a method suporting success indications, > a peer willing to accept access does not consider > the authentication successful until receives an > indication that the server is willing to > grant access. > > In such a method, a server willing to grant access > does not consider the authentication successful > until it receives an indication that the > peer is willing to accept access. > [Joe] The two previous paragraphs require the authentication method to perform full authorization in order to implement method-specific success indications. Protected result indications for authentication methods should synchronize the result of authentication. "does not consider the authentication successful until it receives and indication that the [peer/server] successfully completed authentication." > Success indications may be explicit or implicit. > For example, where a method supports error messages, > an implicit success indication may be defined as the > reception of a specific message without a > preceding error message. Failure indications > are typically explicit. > > As described in Section 4.2.1, a peer silently > discards a Failure packet received at a point where > the method does not explicitly permit this to be sent. > For example, a method providing its own error > messages might require the peer to receive an > an error message prior to accepting a Failure packet. > While this may be useful for debugging purposes, > it will typically add a round-trip to the method. > > Where result indications are authenticated, > integrity and replay protected, it is possible to > to address spoofing vulnerabilities. Since protected > result indications require use of a key for per-packet > authentication and integrity protection, methods supporting > protected result indications MUST also support the "key > derivation", "mutual authentication" "integrity protection" > and "replay protection" claims. However, since errors can > occur prior to key derivation, it is typically not possible > to protect all failure indications. > > While protected result indications may enable synchronization > between the peer and the server, this does not guarantee that > the peer and authenticator will be synchronized or that > timeouts will not occur. For example, the EAP server may not > be aware of an authorization decision made by a AAA proxy; or > the EAP server may grant access, but the authenticator may be > unable to provide it due to a temporary lack of resources. In > these situations, synchronization can only be achieved via > lower layer result indications. > [Joe] "Protected protected result indications may enable synchronization of the authentication result between the peer and the server, this does not guarantee that the that the peer and the authenticator will be synchronized to authorize access." > An EAP method may provide protected result indications in > some circumstances, but not in others. For example, within > EAP-TLS [RFC2716], in the full handshake the peer initially > authenticates the server, and sends a TLS alert message in > the event of an authentication or authorization failure. If > the server does not receive a TLS alert message from the peer > and the peer continues the conversation to completion, then > the server can assume that the peer will accept access if > granted it by the server. > > Similarly, the peer can assume that the server will grant > access if it does not receive a TLS alert message from the > server, and the server carries the conversation to completion > (e.g. sends a FINISHED message). > > A server may use the "access denied" TLS alert after > successfully authenticating the peer to indicate that a valid > certificate was received from the peer, but when access > control was applied, the server decided not to proceed. > > Since by the end of a successful full handshake both the peer > and server are aware of each other's access decision, this > mode of EAP-TLS provides for protected result indications. > > In the session resumption handshake, the peer and server may > not be synchronized. After receiving the initial ClientHello > message, the server can check whether the sessionid sent by > the client is present in its cache. If so, it may check > client authorization and send a TLS alert (a failure > indication) if the client is not authorized. However, the > client has not yet authenticated to the server so that the > server's FINISHED message cannot be interpreted as a success > indication. > > Once the peer receives the server FINISHED message it can > verify it using the newly computed key and thereby > authenticate the server. If the client does not wish to > accept access, a TLS alert may be sent. Once the server > receives the client FINISHED message, it verifies it using > the newly computed key. As a result, the client FINISHED > message can be considered a protected result indication. > > Since the client never receives a method-specific result > indication from the server, as described in Section 4.2, if > it has successfully authenticated the server, then it waits > for a Success or Failure packet and must accept either of > them. Of course, if the server FINISHED message cannot be > verified then accepting a Success message is inappropriate. > This means that an attacker could forge a Success or Failure > packet with impunity, although this would only result in > denial of service." _______________________________________________ > 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 Feb 4 13:24:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19164 for ; Wed, 4 Feb 2004 13:24:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1598203C3; Wed, 4 Feb 2004 13:13:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEC3A203C5; Wed, 4 Feb 2004 13:13:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9F65203C5 for ; Wed, 4 Feb 2004 13:12:40 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 027F8203C3 for ; Wed, 4 Feb 2004 13:12:39 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8E6546A902; Wed, 4 Feb 2004 20:23:57 +0200 (EET) Message-ID: <4021385E.7090004@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <01f201c3eb45$00876590$0200000a@amer.cisco.com> In-Reply-To: <01f201c3eb45$00876590$0200000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 04 Feb 2004 20:22:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: >>Method-specific success indications help avoid these >>issues. In a method suporting success indications, >>a peer willing to accept access does not consider >>the authentication successful until receives an >>indication that the server is willing to >>grant access. >> >>In such a method, a server willing to grant access >>does not consider the authentication successful >>until it receives an indication that the >>peer is willing to accept access. >> > > [Joe] The two previous paragraphs require the authentication method to > perform full authorization in order to implement method-specific success > indications. Protected result indications for authentication methods > should synchronize the result of authentication. > > "does not consider the authentication successful until it receives and > indication that the [peer/server] successfully completed > authentication." I think your version is the absolute minimum that can be/is provided by these indications. Bernard's version on the other hand is the absolute maximum that can ever be provided. I think the truth lies somewhere in between... We are also walking a fine line between not requiring impossible things from implementations but still making it possible to use EAP in a reasonable manner in the peer-to-peer case. How about this: "...until it receives an indication that the peer/server successfully completed authentication. When sending such indications, the sender SHOULD verify that sufficient authorization exists for granting access, though as discussed below this is not always possible." >>Success indications may be explicit or implicit. >>For example, where a method supports error messages, >>an implicit success indication may be defined as the >>reception of a specific message without a >>preceding error message. Failure indications >>are typically explicit. >> >>As described in Section 4.2.1, a peer silently >>discards a Failure packet received at a point where >>the method does not explicitly permit this to be sent. >>For example, a method providing its own error >>messages might require the peer to receive an >>an error message prior to accepting a Failure packet. >>While this may be useful for debugging purposes, >>it will typically add a round-trip to the method. >> >>Where result indications are authenticated, >>integrity and replay protected, it is possible to >>to address spoofing vulnerabilities. Since protected >>result indications require use of a key for per-packet >>authentication and integrity protection, methods supporting >>protected result indications MUST also support the "key >>derivation", "mutual authentication" "integrity protection" >>and "replay protection" claims. However, since errors can >>occur prior to key derivation, it is typically not possible >>to protect all failure indications. >> >>While protected result indications may enable synchronization >>between the peer and the server, this does not guarantee that >>the peer and authenticator will be synchronized or that >>timeouts will not occur. For example, the EAP server may not >>be aware of an authorization decision made by a AAA proxy; or >>the EAP server may grant access, but the authenticator may be >>unable to provide it due to a temporary lack of resources. In >>these situations, synchronization can only be achieved via >>lower layer result indications. >> > > [Joe] "Protected protected result indications may enable synchronization > of the authentication result between the peer and the server, this does > not guarantee that the that the peer and the authenticator will be > synchronized to authorize access." Yes, better. Thanks. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 13:48:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19975 for ; Wed, 4 Feb 2004 13:48:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 050A2203CE; Wed, 4 Feb 2004 13:37:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9698203C9; Wed, 4 Feb 2004 13:37:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C39C4203C5 for ; Wed, 4 Feb 2004 13:36:12 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id EF5C9203C3 for ; Wed, 4 Feb 2004 13:36:10 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i14IlQ08006048; Wed, 4 Feb 2004 10:47:26 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.246]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 10:53:21 -0800 From: "Joseph Salowey" To: Cc: "'Bernard Aboba'" , Subject: RE: [eap] Issue 218: TLS example Message-ID: <01fb01c3eb4f$54d93290$0200000a@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: <4021385E.7090004@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Feb 2004 18:53:21.0748 (UTC) FILETIME=[2930C940:01C3EB50] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 4 Feb 2004 10:47:23 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Joseph Salowey wrote: > >>> Method-specific success indications help avoid these >>> issues. In a method suporting success indications, >>> a peer willing to accept access does not consider >>> the authentication successful until receives an >>> indication that the server is willing to >>> grant access. >>> >>> In such a method, a server willing to grant access >>> does not consider the authentication successful >>> until it receives an indication that the >>> peer is willing to accept access. >>> >> >> [Joe] The two previous paragraphs require the authentication method >> to perform full authorization in order to implement method-specific >> success indications. Protected result indications for authentication >> methods should synchronize the result of authentication. >> >> "does not consider the authentication successful until it receives >> and indication that the [peer/server] successfully completed >> authentication." > > I think your version is the absolute minimum that can be/is > provided by these indications. Bernard's version on the other > hand is the absolute maximum that can ever be provided. I > think the truth lies somewhere in between... We are also > walking a fine line between not requiring impossible things > from implementations but still making it possible to use EAP > in a reasonable manner in the peer-to-peer case. > > How about this: "...until it receives an indication that the > peer/server successfully completed authentication. When > sending such indications, the sender SHOULD verify that > sufficient authorization exists for granting access, though > as discussed below this is not always possible." > [Joe] The SHOULD here is really not appropriate. We are talking about an authentication protocol. How about "...until it receives an indication that the peer/server successfully completed authentication. When sending such indications, it is often desirable to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible." >>> Success indications may be explicit or implicit. >>> For example, where a method supports error messages, >>> an implicit success indication may be defined as the reception of a >>> specific message without a preceding error message. Failure >>> indications are typically explicit. >>> >>> As described in Section 4.2.1, a peer silently >>> discards a Failure packet received at a point where >>> the method does not explicitly permit this to be sent. >>> For example, a method providing its own error >>> messages might require the peer to receive an >>> an error message prior to accepting a Failure packet. >>> While this may be useful for debugging purposes, >>> it will typically add a round-trip to the method. >>> >>> Where result indications are authenticated, >>> integrity and replay protected, it is possible to >>> to address spoofing vulnerabilities. Since protected >>> result indications require use of a key for per-packet >>> authentication and integrity protection, methods supporting >>> protected result indications MUST also support the "key >>> derivation", "mutual authentication" "integrity protection" and >>> "replay protection" claims. However, since errors can occur prior >>> to key derivation, it is typically not possible to protect all >>> failure indications. >>> >>> While protected result indications may enable synchronization >>> between the peer and the server, this does not guarantee that the >>> peer and authenticator will be synchronized or that timeouts will >>> not occur. For example, the EAP server may not be aware of an >>> authorization decision made by a AAA proxy; or the EAP server may >>> grant access, but the authenticator may be unable to provide it due >>> to a temporary lack of resources. In these situations, >>> synchronization can only be achieved via lower layer result >>> indications. >>> >> >> [Joe] "Protected protected result indications may enable >> synchronization of the authentication result between the peer and the >> server, this does not guarantee that the that the peer and the >> authenticator will be synchronized to authorize access." > > Yes, better. Thanks. > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 13:56:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20160 for ; Wed, 4 Feb 2004 13:56:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5CA7203D1; Wed, 4 Feb 2004 13:45:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC7A8203C5; Wed, 4 Feb 2004 13:45:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9ACFD203C5 for ; Wed, 4 Feb 2004 13:44:36 -0500 (EST) Received: from trilmail.funk.com (26-71-51-66.reonbroadband.com [66.51.71.26]) by mail.frascone.com (Postfix) with ESMTP id E3366203C3 for ; Wed, 4 Feb 2004 13:44:34 -0500 (EST) Received: by trilmail.funk.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 13:56:10 -0500 Message-ID: <605BFAC48B20D34F8923E47EB3F8E86E657C0A@trilmail.funk.com> From: Oliver Tavakoli To: "'eap@frascone.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Two Issues for Clarification in RFC3579 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, 4 Feb 2004 13:56:05 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) After careful reading of RFC3579, I have a couple of issues which I hope can be clarified through discussion in this list. Issue 1 ------- What follows is an excerpt from section 2.1: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Since RADIUS proxies are assumed to act as a pass-through, they cannot be expected to parse an EAP-Response/Identity encapsulated within EAP-Message attribute(s). Historically, some RADIUS proxies have (based on configuration options) altered the contents of the User-Name attribute during their routing operation. If, for example, the User-Name contained bob@ispA2ispB, the proxy RADIUS server that represents realm ispB might strip off this realm identifier and forward a request for bob@ispA. If the RADIUS proxy is non-EAP aware and it modifies the User-Name attribute, the contents of the EAP-Response/Identity will clearly not be changed. This implies that EAP aware RADIUS servers should be willing to accept requests in which the values of User-Name and EAP-Response/Identity do not match. Does everyone agree with this assertion? If, on the other hand, the RADIUS proxy is EAP aware, should it modify the contents of EAP-Response/Identity whenever it modifies the contents of User-Name? Or must EAP-Response/Identity be forwarded without change from the peer to RADIUS server? EAP-SIM, for example, appears to assume that the EAP-Response/Identity remains unchanged. Issue 2 ------- What follows is an excerpt from section 3: The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in Access-Request packets, and either NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. The User-Name attribute within the Access- Accept packet need not be the same as the User-Name attribute in the Access-Request. This section states that the Access-Accept MUST include a User-Name attribute and that the value of this attribute could be a billing identifier and need not match the value of the User-Name attribute sent in the Access-Request. It does not clearly state that the NAS is obligated to echo the value of this User-Name attribute in any accounting requests it generates for the session, but that does appear to be the implication. Is this in fact a new requirement being placed on NAS vendors? If so, does anyone know if any NASes actually support this feature? Oliver Tavakoli Funk Software _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 14:18:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21020 for ; Wed, 4 Feb 2004 14:18:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35BDD203CB; Wed, 4 Feb 2004 14:07:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2692203C5; Wed, 4 Feb 2004 14:07:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1E33203C5 for ; Wed, 4 Feb 2004 14:06:07 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 2D359203C3 for ; Wed, 4 Feb 2004 14:06:06 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2004 11:17:32 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i14JHHWR018547; Wed, 4 Feb 2004 11:17:17 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.246]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 11:23:12 -0800 From: "Joseph Salowey" To: "'Oliver Tavakoli'" , Subject: RE: [eap] Two Issues for Clarification in RFC3579 Message-ID: <020001c3eb53$805f5490$0200000a@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: <605BFAC48B20D34F8923E47EB3F8E86E657C0A@trilmail.funk.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Feb 2004 19:23:12.0748 (UTC) FILETIME=[54B5B2C0:01C3EB54] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 4 Feb 2004 11:17:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit eap-admin@frascone.com wrote: > After careful reading of RFC3579, I have a couple of issues > which I hope can be clarified through discussion in this list. > > Issue 1 > ------- > > What follows is an excerpt from section 2.1: > > In order to permit non-EAP aware RADIUS proxies to forward the > Access-Request packet, if the NAS initially sends an > EAP-Request/Identity message to the peer, the NAS MUST copy the > contents of the Type-Data field of the > EAP-Response/Identity received > from the peer into the User-Name attribute and MUST include the > Type-Data field of the EAP-Response/Identity in the User-Name > attribute in every subsequent Access-Request. Since RADIUS proxies > are assumed to act as a pass-through, they cannot be expected to > parse an EAP-Response/Identity encapsulated within EAP-Message > attribute(s). > > Historically, some RADIUS proxies have (based on > configuration options) altered the contents of the User-Name > attribute during their routing operation. If, for example, > the User-Name contained bob@ispA2ispB, the proxy RADIUS > server that represents realm ispB might strip off this realm > identifier and forward a request for bob@ispA. > > If the RADIUS proxy is non-EAP aware and it modifies the > User-Name attribute, the contents of the > EAP-Response/Identity will clearly not be changed. This > implies that EAP aware RADIUS servers should be willing to > accept requests in which the values of User-Name and > EAP-Response/Identity do not match. Does everyone agree with > this assertion? > [Joe] I agree with this assertion. > If, on the other hand, the RADIUS proxy is EAP aware, should > it modify the contents of EAP-Response/Identity whenever it > modifies the contents of User-Name? Or must > EAP-Response/Identity be forwarded without change from the > peer to RADIUS server? EAP-SIM, for example, appears to > assume that the EAP-Response/Identity remains unchanged. > [Joe] Yes this would cause a problem for EAP-SIM. I don't think a proxy should not modify the EAP-Message attribute in any way. > Issue 2 > ------- > > What follows is an excerpt from section 3: > > The NAS-Port or NAS-Port-Id attributes SHOULD be included > by the NAS > in Access-Request packets, and either NAS-Identifier, > NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. > In order > to permit > forwarding of the Access-Reply by EAP-unaware proxies, if > a User-Name > attribute was included in an Access-Request, the RADIUS server MUST > include the User-Name attribute in subsequent > Access-Accept packets. > Without the User-Name attribute, accounting and billing becomes > difficult to manage. The User-Name attribute within the Access- > Accept packet need not be the same as the User-Name > attribute in the > Access-Request. > > This section states that the Access-Accept MUST include a > User-Name attribute and that the value of this attribute > could be a billing identifier and need not match the value of > the User-Name attribute sent in the Access-Request. It does > not clearly state that the NAS is obligated to echo the value > of this User-Name attribute in any accounting requests it > generates for the session, but that does appear to be the > implication. Is this in fact a new requirement being placed > on NAS vendors? If so, does anyone know if any NASes actually > support this feature? > [Joe] This is a good question. I believe there are NASes and stateful proxies that support this (I've seen the username from the Access-Accept in accounting packets, but I'm not sure who put it there). > Oliver Tavakoli > Funk Software > _______________________________________________ > 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 Feb 4 14:47:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22240 for ; Wed, 4 Feb 2004 14:47:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 540DB203D5; Wed, 4 Feb 2004 14:36:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55D2C203CA; Wed, 4 Feb 2004 14:36:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C53D1203CA for ; Wed, 4 Feb 2004 14:35:19 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 42D26203C8 for ; Wed, 4 Feb 2004 14:35:18 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 1A6016A902; Wed, 4 Feb 2004 21:46:37 +0200 (EET) Message-ID: <40214BBD.2020701@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> In-Reply-To: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 04 Feb 2004 21:45:01 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > [Joe] The SHOULD here is really not appropriate. We are talking about an > authentication protocol. How about > > "...until it receives an indication that the > peer/server successfully completed authentication. When > sending such indications, it is often desirable to verify that > sufficient authorization exists for granting access, though > as discussed below this is not always possible." Ok for me. Bernard, others? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 15:28:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24667 for ; Wed, 4 Feb 2004 15:28:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50810203C8; Wed, 4 Feb 2004 15:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 039F2203CC; Wed, 4 Feb 2004 15:17:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1644203CC for ; Wed, 4 Feb 2004 15:16:54 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1989E203C8 for ; Wed, 4 Feb 2004 15:16:53 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i14Kf7N02479; Wed, 4 Feb 2004 12:41:08 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <4021283A.5070308@piuha.net> Message-ID: References: <40202974.8070800@piuha.net> <4021283A.5070308@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 4 Feb 2004 12:41:07 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > It worries me that the RFC may not be clear on this. If its not, > there can be implementations that do it in another manner than > you assume. I agree it would make sense to do it as you explain, > but maybe the implementor has read Section 3.8... Anyway, this > is not a 2284bis issue. But we should keep that in mind for a > possible future update of the EAP-TLS RFC or in discussions > of what protection exists in EAP. I've checked the TLS RFC, and there is no problem with ending a TLS alert at any point after data transmission has commenced. So the example in RFC 2716 is ok. An alert can be sent before or after the server FINISHED message, and could even be sent by the client in response to the server FINISHED message (as opposed to the null packet illustrated). SSL/TLS APIs typically enable alerts to be sent at any time, too. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 16:26:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29979 for ; Wed, 4 Feb 2004 16:26:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95CA0203E0; Wed, 4 Feb 2004 16:15:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1381203DB; Wed, 4 Feb 2004 16:15:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59B1B203DB for ; Wed, 4 Feb 2004 16:14:35 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7EF9B203CC for ; Wed, 4 Feb 2004 16:14:33 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5B9A36A904 for ; Wed, 4 Feb 2004 23:25:52 +0200 (EET) Message-ID: <40216300.5020004@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------000508080408070203060900" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-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: Wed, 04 Feb 2004 23:24:16 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------000508080408070203060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000508080408070203060900 Content-Type: message/rfc822; name="I-D ACTION:draft-walker-ieee802-req-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-walker-ieee802-req-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jari.arkko@piuha.net Delivered-To: jarkko@piuha.net Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by p2.piuha.net (Postfix) with ESMTP id 1614D6A907; Wed, 4 Feb 2004 23:08:05 +0200 (EET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AoTpn-0005DO-Md for ietf-announce-list@asgard.ietf.org; Wed, 04 Feb 2004 15:41:19 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AoTpQ-0005B2-Ai for all-ietf@asgard.ietf.org; Wed, 04 Feb 2004 15:40:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25289 for ; Wed, 4 Feb 2004 15:40:54 -0500 (EST) Message-Id: <200402042040.PAA25289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-walker-ieee802-req-00.txt Date: Wed, 04 Feb 2004 15:40:54 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-4.2 required=6.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Method Requirements for Wireless LANs Author(s) : D. Stanley Filename : draft-walker-ieee802-req-00.txt Pages : 7 Date : 2004-2-4 The Draft IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and it is being presented as an IETF RFC for informational purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-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-walker-ieee802-req-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-walker-ieee802-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-4155734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-walker-ieee802-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-walker-ieee802-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4155734.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000508080408070203060900-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 4 17:08:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03528 for ; Wed, 4 Feb 2004 17:08:26 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59066203C4; Wed, 4 Feb 2004 16:57:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA348203E1; Wed, 4 Feb 2004 16:57:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 144D6203E1 for ; Wed, 4 Feb 2004 16:56:10 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 49764203C4 for ; Wed, 4 Feb 2004 16:56:08 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 238EA6A903; Thu, 5 Feb 2004 00:07:27 +0200 (EET) Message-ID: <40216CBF.6080200@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <40202974.8070800@piuha.net> <4021283A.5070308@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 05 Feb 2004 00:05:51 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>It worries me that the RFC may not be clear on this. If its not, >>there can be implementations that do it in another manner than >>you assume. I agree it would make sense to do it as you explain, >>but maybe the implementor has read Section 3.8... Anyway, this >>is not a 2284bis issue. But we should keep that in mind for a >>possible future update of the EAP-TLS RFC or in discussions >>of what protection exists in EAP. > > > I've checked the TLS RFC, and there is no problem with ending a TLS alert Thanks for digging into this. > at any point after data transmission has commenced. So the example in RFC > 2716 is ok. An alert can be sent before or after the server FINISHED > message, and could even be sent by the client in response to the server > FINISHED message (as opposed to the null packet illustrated). SSL/TLS > APIs typically enable alerts to be sent at any time, too. Well, that's good for RFC 2716 because then its example is correct. Its also good that APIs have the capability, because then implementations can provide the alerts at the most appropriate time. But I wonder if this is good or bad for the discussion on EAP protected indications. If the alerts can be sent at any time, then we do not have a guarantee that they are sent before FINISHED, as our current proposed text says. * ** Here's a proposed fix. Replace A protocol may provide protected result indications in some circumstances, but not in others. For example, within EAP-TLS [RFC2716], in the full handshake the peer intially authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion (e.g. sends a FINISHED message), then the server can assume that the peer will accept access if granted it by the server. with A protocol may provide protected result indications in some circumstances, but not in others. For example, within EAP-TLS [RFC2716], in the full handshake the peer intially authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion, then the server can assume that the peer will accept access if granted it by the server. --Jari *) In fact, looking at Section 3.8 of RFC 2716, it seems that in the examples, the alerts are sent at a position where you would expect either Success, an empty EAP-TLS packet, or an alert. Since both Success and empty EAP-TLS packets can be spoofed, attackers can spoof the lack of an alert, leading to DoS. Or am I reading the draft wrong? What does this mean: <- PPP EAP-Request/ EAP-Type=EAP-TLS Is it a an empty EAP-TLS packet without TLS record inside, TLS Message Length set to 0? Or an EAP-TLS packet with an empty TLS record inside? **) Another EAP-TLS question: if you compare examples in 2 and 3 in Section 3.8, the parts that happens after the server sends a FINISHED message are very similar. In both cases the peer sends an empty TLS record. In example 2 the server responds with EAP Success, and in example 3 the server responds with an alert. The peer must then be prepared to receive either a protected alert or an unprotected success, or? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 5 10:27:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19635 for ; Thu, 5 Feb 2004 10:27:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C0562040B; Thu, 5 Feb 2004 10:16:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B10D5203EE; Thu, 5 Feb 2004 10:16:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BB26203F8 for ; Thu, 5 Feb 2004 10:15:23 -0500 (EST) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id AE8FB203EE for ; Thu, 5 Feb 2004 10:15:21 -0500 (EST) Received: from dhcp60-13.merit.edu (dhcp60-13.merit.edu [198.108.60.213]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i15FQdql018038; Thu, 5 Feb 2004 10:26:40 -0500 From: John Vollbrecht To: Jim Burns , Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Message-ID: <82560.1075976794@dhcp60-13.merit.edu> In-Reply-To: <401EA321.80802@mtghouse.com> References: <401EA321.80802@mtghouse.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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Strawman for a modified section 6.7 (V5) for IEEE 802.1XRev 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, 05 Feb 2004 10:26:34 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jim - I like this very much. I do have a couple small changes I would suggest. I apologize for the delay in replying - I was figuring out a specific suggested change. I have noted my suggestions in the text. -- the biggest change is to the terminology about two simultaneous tranports. I changed the "one-way" to uni-directional to avoid confusion with one-way authentication. I also changed to indicate that without a suppllicant control of the port no authentication, including specifically mutual authentication, can be enforced. I hope these are helpful. I noted changes by enclosing them in **. -- John --On Monday, February 2, 2004 2:21 PM -0500 Jim Burns wrote: > Hi folks, > I have incorporated the input from folks and produced V5 of the draft of > section 6.7 for IEEE 802.1XRev. The new text appears below preceded by a > discussion of the changes that were made. In addition, I have attached a > .txt file containing the table xxxx that will appear at the bottom of > section 6.7 - view this .txt with a fixed width font (courier). I believe > that this version is very close to the final draft (if not the final > draft) Thanks again for all the input, send along any issues, concerns, > comments you have on this, Jim B. > ------------------------------------------- > Version 5 changes: > > -Alter language to read more smoothly > > -Change reason for bi-directional transport in relation to .11 adhoc > networks to better match the discussion in section 2.4 of 2284bis. > > -Remove the discussion of two bridges using a single authentication > server. This does not work. > > -Change text describing why two bridges utilize the bi-directional > transport. > > -Change the text describing the potential problems of a dual role device > encountering a single authenticator role device to be more clear as to > the elements that cause the problem. > > -Change the term ?asymmetric data flow? to ?asymmetric controlled port > state? and change its definition to mean one side authorizes controlled > port, the other does not. > > -Add a reference to 2284bis Section 2.4 in the paragraph that suggests > that applications using 1X should define the 1X roles to be implemented. > > -Update language in table xxxx to be more precise. > > ----------------------------------------------------------------------- > > 6.7 Coupling two 802.1X authentications > > This section discusses the ability of 802.1X to *transport* two simultaneous > *dialogs one* in *each* direction, how implementation asymmetries affect > authentication results and how simultaneous bi-directional transport may > be utilized. > > In 802.1X there is a requestor role (authenticator) and a responder role > (supplicant). The authenticator transmits frames to the supplicant and > the supplicant responds to those frames with frames of its own. 802.1X, > like the authentication protocol carried within it (EAP), is a > request/response protocol, and the state machines reflect this. Such a > transport is sometimes called '*uni-directional*' meaning the protocol exchanges > always originate from one side (the requestor). > > However, it is not the 802.1X transport that controls whether the > authentication is mutual or one-way. Rather, the chosen EAP method > controls whether the authentication is mutual or one-way, and support for > a supplicant controlled-port determines whether authorization is mutual > or one-way. > > Despite the asymmetry of 802.1X and EAP transports, if a mutually > authenticating EAP method (such as EAP-TLS) is carried within 802.1X > frames, then the supplicant and authenticator can mutually authenticate. > However, if an EAP method is chosen which only authenticates the > supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), then the > authentication will be one-way. > > In an earlier version of 802.1X (802.1X-2001), only the authenticator was > specified to have a controlled port. The lack of a supplicant controlled > port prevented ** authentication from being enforced on both sides, *and was particularly a problem in that mutual authentication could not be enforced on the supplicant side*. *[no more changes suggested after this - John]* > However, this was due to the lack of a specification of the controlled > port on the supplicant, not due to the one-way nature of the 802.1X > transport protocol. The current version of 802.1X remedies this by > specifying how both authenticator and supplicant roles affect the > controlled port. > > In 802.1X, each role has its own state machine and it is possible that a > single device can implement both the supplicant and authenticator roles > (state machines). If a device implementing both roles encounters another > device implementing both roles, then two separate (and simultaneous) > 802.1X transports will take place in opposite directions. This is > sometimes referred to as a bi-directional authentication transport or two > coupled one-way authentication exchanges. 802.1X does not support "tie > breaking" wherein two hosts initiating authentication with each other > will only go forward with a single authentication. > > Two coupled one-way authentication exchanges are not equivalent in > security to a single exchange of a mutually authenticating EAP method > (such as EAP-TLS). Since the two coupled one-way authentication exchanges > are not cryptographically bound together, there is no way to ascertain > that the party involved in the first one-way exchange is the same party > that is involved in the alternate one-way exchange. > > Even though a single 802.1X exchange may provide mutual authentication, > there may be other reasons to run two 802.1X exchanges in opposite > directions. RFC 2284bis, Section 2.4 discusses some of these cases, which > include: > > 1) When the devices require the creation of separate key material in each > direction but the keying protocol is uni-directional (as in the group > handshake in 802.11 adhoc networks). > > 2) When different credentials are used for different roles (one > credential for the supplicant role and one for the authenticator). > > 3) When two bridges are connected, each bridge may implement the > Supplicant role, but may have authorization requirements that can only be > enforced by the Authenticator ("Supplicant Access Control with > Authenticator" variable set to inactive). > > When a device that implements both 802.1X roles on a single port > encounters a device that implements only a single authenticator role, > this may result in asymmetric controlled port state (the single role > device authorizes its controlled port while the dual role device does not > because its authenticator role has not been satisfied). A complete table > of encounters and results appears in Table xxxx. > > It is suggested that applications utilizing 802.1X should specify which > 802.1X roles must be implemented to avoid encounters that will result in > failed network connections. See Section 2.4 of RFC 2284bis for other > issues that may arise in peer-to-peer usage of EAP. > > Table xxxx: Result of encounters between 802.1X transport roles assuming > key-generating EAP methods are run and authentication result is success. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 5 14:59:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01685 for ; Thu, 5 Feb 2004 14:59:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04DF220208; Thu, 5 Feb 2004 14:48:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86ED820413; Thu, 5 Feb 2004 14:48:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F282120413 for ; Thu, 5 Feb 2004 14:47:59 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6E28D20208 for ; Thu, 5 Feb 2004 14:47:58 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id B06616A905 for ; Thu, 5 Feb 2004 21:59:17 +0200 (EET) Message-ID: <4022A035.9070505@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] limits of protected result 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: Thu, 05 Feb 2004 21:57:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit One limit of the protected result indications is that you can not protect the indications until you have generated a key. Here's another limitation by Pasi that applies to all methods: Lets assume that we are at a point where a key has been generated and both sides have exchanged protected success indications. And we are at the last message pair. Now, lets assume the response (and its retransmissions) get lost. The peer has received and sent all messages of the protocol and is expecting Success. The server on the other hand is missing the last message. Eventually it will give up and is forced to disconnect and not grant access. In a variation of this scenario there is an attacker who creates this situation by blocking the last response. The result is DoS where the peer ends up in a lengthy timeout while the server performs a disconnect. Conclusion? As Hannes pointed out also, protected result indications can never provide complete assurance that the parties are in sync. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 5 15:27:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04368 for ; Thu, 5 Feb 2004 15:27:30 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78DBE20390; Thu, 5 Feb 2004 15:16:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 894B020420; Thu, 5 Feb 2004 15:16:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B68ED2041F for ; Thu, 5 Feb 2004 15:15:54 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id BFA3920390 for ; Thu, 5 Feb 2004 15:15:52 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i15KRCN9021984; Fri, 6 Feb 2004 05:27:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i15KRCCU001112; Fri, 6 Feb 2004 05:27:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA01109 ; Fri, 6 Feb 2004 05:27:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA03153; Fri, 6 Feb 2004 05:27:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA03262; Fri, 6 Feb 2004 05:27:11 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i15KR9Kn024598; Fri, 6 Feb 2004 05:27:10 +0900 (JST) Received: from steelhead ([159.119.168.56]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSM00EKTOT8KE@tsbpo1.po.toshiba.co.jp>; Fri, 6 Feb 2004 05:27:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aoq3U-0005bv-00; Thu, 05 Feb 2004 12:24:56 -0800 From: Yoshihiro Ohba Subject: Re: [eap] limits of protected result indications In-reply-to: <4022A035.9070505@piuha.net> To: Jari Arkko Cc: "eap@frascone.com" Message-id: <20040205202456.GK17931@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <4022A035.9070505@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 05 Feb 2004 12:24:56 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Thu, Feb 05, 2004 at 09:57:41PM +0200, Jari Arkko wrote: > One limit of the protected result indications is that > you can not protect the indications until you have > generated a key. Here's another limitation by Pasi that > applies to all methods: > > Lets assume that we are at a point where a key has > been generated and both sides have exchanged protected > success indications. And we are at the last message pair. > Now, lets assume the response (and its retransmissions) > get lost. The peer has received and sent all messages > of the protocol and is expecting Success. The server > on the other hand is missing the last message. Eventually > it will give up and is forced to disconnect and not > grant access. This is equivalent to the case where physical connectivity is lost while sending the last response. We need a timeout mechanism regardless of whether protected indication is supported or not. I think this should not be viewed as a limitation. > > In a variation of this scenario there is an attacker > who creates this situation by blocking the last response. > The result is DoS where the peer ends up in a lengthy > timeout while the server performs a disconnect. The same as above. > > Conclusion? As Hannes pointed out also, protected result > indications can never provide complete assurance that the > parties are in sync. I think protected result indication can help improve robustness against DoS attacks from off-path attackers. If attackers are on the path between communicating entities, nothing can help, and discussing such a case does not make sense. What we need is to identify what kind of DoS attacks are important for us, IMHO. Yoshihiro Ohba > > --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 Feb 5 19:30:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20893 for ; Thu, 5 Feb 2004 19:30:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92B2220442; Thu, 5 Feb 2004 19:19:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 311132043D; Thu, 5 Feb 2004 19:19:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 959212043E for ; Thu, 5 Feb 2004 19:18:38 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id D174B2043D for ; Thu, 5 Feb 2004 19:18:36 -0500 (EST) 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 i160Tshk001938; Thu, 5 Feb 2004 16:29:55 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.1]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 16:35:50 -0800 From: "Joseph Salowey" To: , , "'Bernard Aboba'" , Message-ID: <007c01c3ec48$5734e2b0$0200000a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 06 Feb 2004 00:35:51.0249 (UTC) FILETIME=[2C0F8C10:01C3EC49] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Question on draft-walker-ieee802-req-00 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, 5 Feb 2004 16:29:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit What does item [3], "synchronization of state," mean? What state do you expect to be synchronized? I ask because it is not clear to me that this is the same as "protected result indicators." Thanks, Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 10:07:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28936 for ; Fri, 6 Feb 2004 10:07:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB89F20459; Fri, 6 Feb 2004 09:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 965FC20453; Fri, 6 Feb 2004 09:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4226920453 for ; Fri, 6 Feb 2004 09:55:52 -0500 (EST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id 9471E20236 for ; Fri, 6 Feb 2004 09:55:50 -0500 (EST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i16F70i4004433; Fri, 6 Feb 2004 15:07:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i16F6sCd026860; Fri, 6 Feb 2004 15:06:56 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020607062918418 ; Fri, 06 Feb 2004 07:06:29 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 07:06:29 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: Question on draft-walker-ieee802-req-00 Thread-Index: AcPsSGSkhQ5dGAbxSiGXz/zE/dBpGAAdQJoA From: "Walker, Jesse" To: "Joseph Salowey" , , "Bernard Aboba" , X-OriginalArrivalTime: 06 Feb 2004 15:06:29.0509 (UTC) FILETIME=[CC7D7350:01C3ECC2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Question on draft-walker-ieee802-req-00 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, 6 Feb 2004 07:06:29 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Joe, Here is my view of what "synchronization of state" means. If both parties complete the authentication, then they will agree on what protocol both executed, what credentials were presented and accepted by both parties, what keys both have derived, and how to distinguish this instance of the protocol from all other instances of the protocol. They will also share the same view of negotiable attributes of the protocol, such as cipher suites, and the same limitations of usage on all protocol state, and particularly the same view of what attributes of the protocol instance are public and which are private to the two parties alone. If one of the parties fails to complete the authentication, then the two parties will not agree on at least some of this information, and one must be able to demonstrate that this lack of synchronization will prevent the IEEE 802.11i 4-Way Handshake from completing successfully. The complete list of requirements is a first attempt at imposing a definition of what it means to be secure, so we can have some hope of knowing what we are talking about. If you can suggest improvements to this list of requirements or how they are expressed, it will be appreciated. -- Jesse -----Original Message----- From: Joseph Salowey [mailto:jsalowey@cisco.com]=20 Sent: Thursday, February 05, 2004 4:30 PM To: eap@frascone.com; Walker, Jesse; 'Bernard Aboba'; dstanley@agere.com Subject: Question on draft-walker-ieee802-req-00 What does item [3], "synchronization of state," mean?=20 What state do you expect to be synchronized? =20 I ask because it is not clear to me that this is the same as "protected result indicators." Thanks, Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 10:39:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01596 for ; Fri, 6 Feb 2004 10:39:30 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B0AD20457; Fri, 6 Feb 2004 10:28:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37AC120260; Fri, 6 Feb 2004 10:28:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21FA020260 for ; Fri, 6 Feb 2004 10:27:29 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mail.frascone.com (Postfix) with ESMTP id 1675420236 for ; Fri, 6 Feb 2004 10:27:27 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i16FcmQ14315 for ; Fri, 6 Feb 2004 16:38:48 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i16Fclw16454 for ; Fri, 6 Feb 2004 16:38:47 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 16:38:13 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06C4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Relationship between AAA-Key and MSK/EMSK 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, 6 Feb 2004 16:38:30 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, this issue come up when we discussed (Yoshi, Alper, Jari) the relationship between the AAA-key and the MSK/EMSK in PANA . it is said that the AAA-Key is derived from the MSK and EMSK. the eap-keying document does not specify how this key derivation is achieved. worse, in Section 4.2.1 the text says: " The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see Appendix E for details). " appendix e, however, does not help since it talks only about a very special case, namely fast handoff. we dicussed this issue in one of the eap keying design team phone conferences but it got lost somehow. it would be more helpful to provide a proposal for AAA-Key to MSK/EMSK key derivation. ciao hannes _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 10:41:31 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01682 for ; Fri, 6 Feb 2004 10:41:30 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8511220236; Fri, 6 Feb 2004 10:30:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB46320453; Fri, 6 Feb 2004 10:30:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F33B20456 for ; Fri, 6 Feb 2004 10:29:09 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mail.frascone.com (Postfix) with ESMTP id 8F19B20453 for ; Fri, 6 Feb 2004 10:29:07 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i16FeTZ02834 for ; Fri, 6 Feb 2004 16:40:29 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i16FeSw17732 for ; Fri, 6 Feb 2004 16:40:28 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 16:39:54 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06C5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] session independence 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, 6 Feb 2004 16:40:11 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, i took a look at the definition of "session independence" which is described in section 7.2.1 of eap-rfrc2284bis: " Session independence The demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) does not enable compromise of subsequent or prior MSKs or EMSKs. " it would be good to specify which keys should not enable compromise subsequent MSKs / EMSKs. which keys (AAA-Key, MSK, EMSK, EAP-SA-key, long-term key, etc.) have you had in mind? an example: if you have a fast reconnect then you might want to send a protected message to derive new session keys. i simply guess here about the desired properties of a fast resume since i think that they are not described anywhere. if an adversary learns the EAP SA then he is also able to learn new session keys. maybe it would be helpful to point to terms such as perfect forward secrecy or to the vulnerability of a known key attack here. i could write a short paragraph if i knew what you have in mind. ciao hannes _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 12:19:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05749 for ; Fri, 6 Feb 2004 12:19:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C5F820453; Fri, 6 Feb 2004 12:08:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54B1420254; Fri, 6 Feb 2004 12:08:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43E0620254 for ; Fri, 6 Feb 2004 12:07:03 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 8E12A20236 for ; Fri, 6 Feb 2004 12:07:01 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2004 09:18:55 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i16HIKGq013706; Fri, 6 Feb 2004 09:18:21 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.1]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 09:24:17 -0800 From: "Joseph Salowey" To: "'Tschofenig Hannes'" , Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <00c401c3ecd5$3790ede0$0200000a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC06C4@mchp905a.mch.sbs.de> Importance: Normal X-OriginalArrivalTime: 06 Feb 2004 17:24:17.0671 (UTC) FILETIME=[0CB2D970:01C3ECD6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 6 Feb 2004 09:18:18 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Hannes, I agree the definition of the AAA-key seems incomplete, I think the definition is any key that is used by the authenticator and supplicant to derive keys for data traffic protection (I don't think AAA-key is the best name since it doesn't have to involve a AAA in the basic case). In the case of standard 802.11 this AAA-Key the same as the MSK. In the fast handoff example I believe additional AAA-keys are pushed to neighboring access points. In order to provide computational independence from the MSK they should be derived from the EMSK. I have submitted an issue in email http://mail.frascone.com/pipermail/eap/2004-January/002143.html (which has not yet been assigned a number) which describes how to derive keys from the EMSK for specific purposes. I think appendix e needs to be updated as discussed in Issue 214 http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't had time to take a detailed look at Jari's proposal. I'm not sure why the A-AAA-Key is needed in this derivation but it is equivalent to the MSK. Could you provide some more context from your discussion? What exactly are you deriving keys to do? In my opinion it is best to use the MSK as in the case of 802.11 (single authenticator to supplicant). If keys are going to be used for other purposes, between other parties or in other ways they should be derived from the EMSK. Thanks, Joe eap-admin@frascone.com wrote: > hi all, > > this issue come up when we discussed (Yoshi, Alper, Jari) the > relationship between the AAA-key and the MSK/EMSK in PANA . > > it is said that the AAA-Key is derived from the MSK and EMSK. > > the eap-keying document does not specify how this key > derivation is achieved. > worse, in Section 4.2.1 the text says: > > " The AAA-Key is derived from the keying material exported by the EAP > method (MSK and EMSK). This derivation occurs on the AAA > server. In > many existing protocols that use EAP, the AAA-Key and MSK are > equivalent, but more complicated mechanisms are possible (see > Appendix E for details). " > > appendix e, however, does not help since it talks only about > a very special case, namely fast handoff. > > we dicussed this issue in one of the eap keying design team > phone conferences but it got lost somehow. > > it would be more helpful to provide a proposal for AAA-Key to > MSK/EMSK key derivation. > > ciao > hannes > _______________________________________________ > 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 Feb 6 12:49:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06911 for ; Fri, 6 Feb 2004 12:49:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCA9B20267; Fri, 6 Feb 2004 12:38:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 638E820451; Fri, 6 Feb 2004 12:38:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8AFB20451 for ; Fri, 6 Feb 2004 12:37:53 -0500 (EST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 5478120267 for ; Fri, 6 Feb 2004 12:37:52 -0500 (EST) Received: from dhcp60-13.merit.edu (dhcp60-13.merit.edu [198.108.60.213]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i16HnAse027301; Fri, 6 Feb 2004 12:49:10 -0500 From: John Vollbrecht To: Joseph Salowey , "'Tschofenig Hannes'" , eap@frascone.com Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <939122.1076071745@dhcp60-13.merit.edu> In-Reply-To: <00c401c3ecd5$3790ede0$0200000a@amer.cisco.com> References: <00c401c3ecd5$3790ede0$0200000a@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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 06 Feb 2004 12:49:06 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This brings up a point that I haven't been able to understand - see below --On Friday, February 6, 2004 9:18 AM -0800 Joseph Salowey wrote: > Hi Hannes, > > I agree the definition of the AAA-key seems incomplete, I think the > definition is any key that is used by the authenticator and supplicant > to derive keys for data traffic protection (I don't think AAA-key is the > best name since it doesn't have to involve a AAA in the basic case). > In the case of standard 802.11 this AAA-Key the same as the MSK. In the > fast handoff example I believe additional AAA-keys are pushed to > neighboring access points. In order to provide computational > independence from the MSK they should be derived from the EMSK. > I don't understand why we would derive a MSK and EMSK that are at the same level, then use the MSK for the current AP but derive new keys from the EMSK for other APs. It seems to me that it would be more consistent to derive all keys the same way, perhaps from the MSK. But then I don't understand the value of the EMSK, since everything can be derived from the MSK. I had thought that the MSK was meant to allow backward compatibility with existing Key mechanisms, and the EMSK would do future things. Perhaps this is the case, but it seems to me that deriving everything the same way would be more consistent and easier to understand. Is the MSK mean to be equivalent to the EMSK except that the MSK is only used for existing implementations, or am I misunderstanding something? > I have submitted an issue in email > http://mail.frascone.com/pipermail/eap/2004-January/002143.html (which > has not yet been assigned a number) which describes how to derive keys > from the EMSK for specific purposes. I think appendix e needs to be > updated as discussed in Issue 214 > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't > had time to take a detailed look at Jari's proposal. I'm not sure why > the A-AAA-Key is needed in this derivation but it is equivalent to the > MSK. > > Could you provide some more context from your discussion? What exactly > are you deriving keys to do? In my opinion it is best to use the MSK as > in the case of 802.11 (single authenticator to supplicant). If keys are > going to be used for other purposes, between other parties or in other > ways they should be derived from the EMSK. > > Thanks, > > Joe > > > eap-admin@frascone.com wrote: > > hi all, > > > > this issue come up when we discussed (Yoshi, Alper, Jari) the > > relationship between the AAA-key and the MSK/EMSK in PANA . > > > > it is said that the AAA-Key is derived from the MSK and EMSK. > > > > the eap-keying document does not specify how this key > > derivation is achieved. > > worse, in Section 4.2.1 the text says: > > > > " The AAA-Key is derived from the keying material exported by the EAP > > method (MSK and EMSK). This derivation occurs on the AAA > > server. In > > many existing protocols that use EAP, the AAA-Key and MSK are > > equivalent, but more complicated mechanisms are possible (see > > Appendix E for details). " > > > > appendix e, however, does not help since it talks only about > > a very special case, namely fast handoff. > > > > we dicussed this issue in one of the eap keying design team > > phone conferences but it got lost somehow. > > > > it would be more helpful to provide a proposal for AAA-Key to > > MSK/EMSK key derivation. > > > > ciao > > hannes > > _______________________________________________ > > 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 Fri Feb 6 13:12:29 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07839 for ; Fri, 6 Feb 2004 13:12:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 940562045C; Fri, 6 Feb 2004 13:01:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B85720453; Fri, 6 Feb 2004 13:01:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2382720453 for ; Fri, 6 Feb 2004 13:00:39 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 73F1D2025C for ; Fri, 6 Feb 2004 13:00:37 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2004 10:12:32 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i16IBvGq026913; Fri, 6 Feb 2004 10:11:57 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.1]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 10:17:53 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , "'Tschofenig Hannes'" , Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <00ce01c3ecdc$b4bb7450$0200000a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <939122.1076071745@dhcp60-13.merit.edu> Importance: Normal X-OriginalArrivalTime: 06 Feb 2004 18:17:54.0156 (UTC) FILETIME=[89DF82C0:01C3ECDD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 6 Feb 2004 10:11:54 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit jrv@j.imap.itd.umich.edu wrote: > This brings up a point that I haven't been able to understand > - see below --On Friday, February 6, 2004 9:18 AM -0800 > Joseph Salowey > wrote: > >> Hi Hannes, >> >> I agree the definition of the AAA-key seems incomplete, I think the >> definition is any key that is used by the authenticator and >> supplicant to derive keys for data traffic protection (I don't think >> AAA-key is the best name since it doesn't have to involve a AAA in >> the basic case). In the case of standard 802.11 this AAA-Key the >> same as the MSK. In the fast handoff example I believe additional >> AAA-keys are pushed to neighboring access points. In order to >> provide computational independence from the MSK they should be >> derived from the EMSK. >> > I don't understand why we would derive a MSK and EMSK that > are at the same > level, then use the MSK for the current AP but derive new > keys from the > EMSK for other APs. > > It seems to me that it would be more consistent to derive all > keys the same > way, perhaps from the MSK. But then I don't understand the > value of the > EMSK, since everything can be derived from the MSK. > > I had thought that the MSK was meant to allow backward > compatibility with > existing Key mechanisms, and the EMSK would do future things. > Perhaps this is the case, but it seems to me that deriving everything > the > same way would > be more consistent and easier to understand. > > Is the MSK mean to be equivalent to the EMSK except that the > MSK is only > used for existing implementations, or am I misunderstanding something? > [Joe] Basically you are correct. The reason for the EMSK is because existing schemes already use the MSK directly in specific ways (dynamic WEP for example). If we could start over we could just have one key and derive everything from that. We could decide to deprecate the MSK and derive everything from the EMSK. >> I have submitted an issue in email >> > http://mail.frascone.com/pipermail/eap/2004-January/002143.htm > l (which >> has not yet been assigned a number) which describes how to derive >> keys from the EMSK for specific purposes. I think appendix e needs >> to be updated as discussed in Issue 214 >> http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I >> haven't had time to take a detailed look at Jari's proposal. I'm not >> sure why the A-AAA-Key is needed in this derivation but it is >> equivalent to the MSK. >> >> Could you provide some more context from your discussion? What >> exactly are you deriving keys to do? In my opinion it is best to use >> the MSK as in the case of 802.11 (single authenticator to >> supplicant). If keys are going to be used for other purposes, >> between other parties or in other ways they should be derived from >> the EMSK. >> >> Thanks, >> >> Joe >> >> >> eap-admin@frascone.com wrote: >>> hi all, >>> >>> this issue come up when we discussed (Yoshi, Alper, Jari) the >>> relationship between the AAA-key and the MSK/EMSK in PANA . >>> >>> it is said that the AAA-Key is derived from the MSK and EMSK. >>> >>> the eap-keying document does not specify how this key derivation is >>> achieved. worse, in Section 4.2.1 the text says: >>> >>> " The AAA-Key is derived from the keying material exported by the >>> EAP method (MSK and EMSK). This derivation occurs on the AAA >>> server. In many existing protocols that use EAP, the AAA-Key and >>> MSK are equivalent, but more complicated mechanisms are possible >>> (see Appendix E for details). " >>> >>> appendix e, however, does not help since it talks only about a very >>> special case, namely fast handoff. >>> >>> we dicussed this issue in one of the eap keying design team phone >>> conferences but it got lost somehow. >>> >>> it would be more helpful to provide a proposal for AAA-Key to >>> MSK/EMSK key derivation. >>> >>> ciao >>> hannes >>> _______________________________________________ >>> 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 Fri Feb 6 13:37:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08696 for ; Fri, 6 Feb 2004 13:37:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6273203C3; Fri, 6 Feb 2004 13:26:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D387220268; Fri, 6 Feb 2004 13:26:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B53DF20330 for ; Fri, 6 Feb 2004 13:25:58 -0500 (EST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id CB10220268 for ; Fri, 6 Feb 2004 13:25:56 -0500 (EST) Received: from dhcp60-13.merit.edu (dhcp60-13.merit.edu [198.108.60.213]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i16IbEse005892; Fri, 6 Feb 2004 13:37:15 -0500 From: John Vollbrecht To: Joseph Salowey , "'Tschofenig Hannes'" , eap@frascone.com Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <1111892.1076074630@dhcp60-13.merit.edu> In-Reply-To: <00ce01c3ecdc$b4bb7450$0200000a@amer.cisco.com> References: <00ce01c3ecdc$b4bb7450$0200000a@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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 06 Feb 2004 13:37:10 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks for the reply- --On Friday, February 6, 2004 10:11 AM -0800 Joseph Salowey wrote: > > > jrv@j.imap.itd.umich.edu wrote: > > This brings up a point that I haven't been able to understand > > - see below --On Friday, February 6, 2004 9:18 AM -0800 > > Joseph Salowey > > wrote: > > > >> Hi Hannes, > >> > >> I agree the definition of the AAA-key seems incomplete, I think the > >> definition is any key that is used by the authenticator and > >> supplicant to derive keys for data traffic protection (I don't think > >> AAA-key is the best name since it doesn't have to involve a AAA in > >> the basic case). In the case of standard 802.11 this AAA-Key the > >> same as the MSK. In the fast handoff example I believe additional > >> AAA-keys are pushed to neighboring access points. In order to > >> provide computational independence from the MSK they should be > >> derived from the EMSK. > >> > > I don't understand why we would derive a MSK and EMSK that > > are at the same > > level, then use the MSK for the current AP but derive new > > keys from the > > EMSK for other APs. > > > > It seems to me that it would be more consistent to derive all > > keys the same > > way, perhaps from the MSK. But then I don't understand the > > value of the > > EMSK, since everything can be derived from the MSK. > > > > I had thought that the MSK was meant to allow backward > > compatibility with > > existing Key mechanisms, and the EMSK would do future things. > > Perhaps this is the case, but it seems to me that deriving everything > > the > > same way would > > be more consistent and easier to understand. > > > > Is the MSK mean to be equivalent to the EMSK except that the > > MSK is only > > used for existing implementations, or am I misunderstanding something? > > > > [Joe] Basically you are correct. The reason for the EMSK is because > existing schemes already use the MSK directly in specific ways (dynamic > WEP for example). If we could start over we could just have one key and > derive everything from that. We could decide to deprecate the MSK and > derive everything from the EMSK. > Why don't we just derive everything from the EMSK. We could derive the MSK from the EMSK and then MSK' from the EMSK for a second AP, and then MSK'' for the third AP, and then MSK'' for some other application. It seems to make things conceptually simpler and easier to understand if it is done this way. Am I missing something? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 15:15:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13689 for ; Fri, 6 Feb 2004 15:15:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DC5B20454; Fri, 6 Feb 2004 15:04:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CABE20269; Fri, 6 Feb 2004 15:04:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B97320269 for ; Fri, 6 Feb 2004 15:03:53 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 06B5A2025C for ; Fri, 6 Feb 2004 15:03:52 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id AB97F6A905; Fri, 6 Feb 2004 22:15:12 +0200 (EET) Message-ID: <4023F56F.8080404@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" Subject: Re: [eap] limits of protected result indications References: <4022A035.9070505@piuha.net> <20040205202456.GK17931@steelhead> In-Reply-To: <20040205202456.GK17931@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 06 Feb 2004 22:13:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshihiro, >>Lets assume that we are at a point where a key has >>been generated and both sides have exchanged protected >>success indications. And we are at the last message pair. >>Now, lets assume the response (and its retransmissions) >>get lost. The peer has received and sent all messages >>of the protocol and is expecting Success. The server >>on the other hand is missing the last message. Eventually >>it will give up and is forced to disconnect and not >>grant access. > > > This is equivalent to the case where physical connectivity is lost > while sending the last response. We need a timeout mechanism > regardless of whether protected indication is supported or not. I I agree. > think this should not be viewed as a limitation. Well, at least we should not attempt to fix it. (There may still be a reason to understand what our protocols can and can not do.) >>In a variation of this scenario there is an attacker >>who creates this situation by blocking the last response. >>The result is DoS where the peer ends up in a lengthy >>timeout while the server performs a disconnect. > > > The same as above. > > >>Conclusion? As Hannes pointed out also, protected result >>indications can never provide complete assurance that the >>parties are in sync. > > > I think protected result indication can help improve robustness > against DoS attacks from off-path attackers. If attackers are on the > path between communicating entities, nothing can help, and discussing > such a case does not make sense. Yes. Of course, there can be some differences in what the specific schemes can accomplish, but perhaps the conclusion for issues 217, 218 is that we should realize there are inherent limits in all of them, and formulate our claims about in the document accordingly. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 16:42:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21558 for ; Fri, 6 Feb 2004 16:42:40 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2BFD2045D; Fri, 6 Feb 2004 16:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB6CA203C3; Fri, 6 Feb 2004 16:31:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCB27203C3 for ; Fri, 6 Feb 2004 16:30:36 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DEAE92025C for ; Fri, 6 Feb 2004 16:30:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i16Lshm20515 for ; Fri, 6 Feb 2004 13:54:43 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: limits of protected result 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: Fri, 6 Feb 2004 13:54:43 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) >Lets assume that we are at a point where a key has >been generated and both sides have exchanged protected >success indications. And we are at the last message pair. >Now, lets assume the response (and its retransmissions) >get lost. EAP Responses are not retransmitted. If a Response is lost, then the authenticator will retransmit the EAP-Request. >The peer has received and sent all messages >of the protocol and is expecting Success. The server >on the other hand is missing the last message. Eventually >it will give up and is forced to disconnect and not >grant access. Assuming that the authenticator retransmits the EAP-Request but does not receive a Response, yes it will eventually give up. The peer is satisfied, so it will grant access. This is a situation where it is necessary for a lower layer indication to be sent by the authenticator to the peer. But if the EAP-Request didn't get through, probably the lower indication won't either. As Marshall Rose once said "what you need isn't a different transport -- what you need is more voltage!" >In a variation of this scenario there is an attacker >who creates this situation by blocking the last response. >The result is DoS where the peer ends up in a lengthy >timeout while the server performs a disconnect. It's only a lengthy timeout if the authenticator doesn't send a lower layer indication. In 802.11, an authenticator responds to data sent by the peer in state 1 with a DeAuthenticate and in state 2 with Disassociate. The problem of state synchronization can occur for other reasons, so it's something that other link layers (e.g. PPP LCP-Terminate) have to handle as well. >Conclusion? As Hannes pointed out also, protected result >indications can never provide complete assurance that the >parties are in sync. I agree with this. Lower layer indications play an important role. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 16:47:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22640 for ; Fri, 6 Feb 2004 16:47:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 603E920457; Fri, 6 Feb 2004 16:36:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 516AA2043C; Fri, 6 Feb 2004 16:36:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3573B2043C for ; Fri, 6 Feb 2004 16:35:08 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 65CA7203C3 for ; Fri, 6 Feb 2004 16:35:06 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i16LxFu20766 for ; Fri, 6 Feb 2004 13:59:15 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: session independence 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, 6 Feb 2004 13:59:15 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This sounds like something to be dealt with in the key framework document. I'll file it as (yet another) key framework issue. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 6 17:04:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24974 for ; Fri, 6 Feb 2004 17:04:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 540E62025C; Fri, 6 Feb 2004 16:53:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17763203C3; Fri, 6 Feb 2004 16:53:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D277203C3 for ; Fri, 6 Feb 2004 16:52:26 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E6C372025C for ; Fri, 6 Feb 2004 16:52:23 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i16MGT421938; Fri, 6 Feb 2004 14:16:29 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: Message-ID: References: <40202974.8070800@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 6 Feb 2004 14:16:29 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here's another shot at the proposed text: "7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing as well as denial of service attacks. As described in Section 4.2, a peer silently discards a Success packet received at a point where the method does not explicitly permit this to be sent. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the server has indicated to the peer whether it will grant access. If the peer were to accept the forged Success packet and attempt to access the network but the server did not grant access, a successful denial of service attack could be mounted against the peer. Where supported by the lower layer, the authenticator can remedy this by providing a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to grant access prior to determining whether the peer will accept it, then an idle timeout can occur. Where supported by the lower layer, an authenticator sensing the absence of the peer can remedy this by disconnecting and freeing resources. Method-specific success indications help avoid some of these issues. In a method supporting success indications, a peer willing to accept access does not consider the authentication successful until it receives an indication that the server successfully completed authentication. Similarly, a server willing to grant access does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a method-specific success indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failure indications are typically explicit. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While this may be useful for debugging purposes, it will typically add a round-trip to the method. While method-specific result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be sychronized to authorize access or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; or the EAP server may grant access, but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization can only be achieved via lower layer result indications. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. An EAP method may provide protected result indications in some circumstances, but not in others. Since errors can occur prior to key derivation, it may not be possible to protect all failure indications. It is also possible that synchronization may not be achieved in all possible exchanges. For example, within EAP-TLS [RFC2716], in the full handshake the peer initially authenticates the server, and may send a TLS alert message to the server in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion, then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion. A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed. Since by the end of a successful full handshake both the peer and server are aware of each other's access decision, this mode of EAP-TLS provides for protected result indications. However, in the session resumption handshake, the peer and server may not be synchronized. After receiving the initial ClientHello message, the server can check whether the session_id sent by the peer is present in its cache. If so, it may check peer authorization and send a TLS alert message if the peer is not authorized. However, the peer has not yet authenticated to the server so that the server's Finished message cannot be interpreted as a success indication. Once the peer receives the server Finished message it can verify it using the newly computed key and authenticate the server. If the peer does not wish to accept access, a TLS alert may be sent. Once the server receives the peer Finished message, it verifies it using the newly computed key. As a result, the peer Finished message, once verified, can be interpreted as a success indication by the server. Since the peer never receives an indication of whether the server has authenticated it, if the peer has successfully authenticated the server, as described in Section 4.2, it waits for a Success or Failure packet and must accept either of them. Of course, if the server Finished message cannot be verified then it is inappropriate for the peer to accept a Success message. This implies that an attacker could forge a Success or Failure packet with impunity, although this would only result in denial of service." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 03:34:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11609 for ; Sun, 8 Feb 2004 03:33:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 639041FF8C; Sun, 8 Feb 2004 03:22:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFCED1FF88; Sun, 8 Feb 2004 03:22:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61E921FF88 for ; Sun, 8 Feb 2004 03:21:33 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 4B5881FF84 for ; Sun, 8 Feb 2004 03:21:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i188jSU18418; Sun, 8 Feb 2004 00:45:28 -0800 From: Bernard Aboba To: Jari Arkko Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <40214BBD.2020701@piuha.net> Message-ID: References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 00:45:28 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Ok for me. Bernard, others? This works for me. Here is the complete text of the proposed resolution of Issue 218: "7.16 Protected Result Indications Result indications address some denial-of-service vulnerabilities with EAP Success and Failure packets. These packets are neither acknowledged nor integrity protected. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the server has indicated to the peer whether it will grant access. If the peer were to accept the forged Success packet and attempt to access the network but the server did not grant access, a successful denial of service attack could be mounted against the peer. Where supported by the lower layer, the authenticator can remedy this by providing a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to grant access prior to determining whether the peer will accept it, then an idle timeout can occur. Where supported by the lower layer, an authenticator sensing the absence of the peer can remedy this by disconnecting and freeing resources. Result indications help avoid some of these issues. In a method supporting result indications, a peer willing to accept access does not consider the authentication successful until it receives an indication that the server successfully completed authentication. Similarly, a server willing to grant access does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a method-specific success indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be sychronized to authorize access or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; or the EAP server may grant access, but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization can only be achieved via lower layer result indications. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. EAP methods can typically provide protected result indications only in some circumstances, but not in others. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that synchronization may not be achieved in all possible modes of operation. For example, within EAP-TLS [RFC2716], both the peer and server provide success result indications within the full handshake, whereas in the session resumption handshake only the peer provides a success result indication." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 09:42:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20345 for ; Sun, 8 Feb 2004 09:42:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B65482022F; Sun, 8 Feb 2004 09:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 900F120235; Sun, 8 Feb 2004 09:31:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BAA2C20235 for ; Sun, 8 Feb 2004 09:30:34 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mail.frascone.com (Postfix) with ESMTP id BB2572022F for ; Sun, 8 Feb 2004 09:30:32 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i18EfnQ05140; Sun, 8 Feb 2004 15:41:49 +0100 (MET) Received: from verena ([139.25.62.11]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i18Efnk02277; Sun, 8 Feb 2004 15:41:49 +0100 (MET) From: "Hannes Tschofenig" To: , Subject: RE: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-00.txt] Message-ID: <2A8DB02E3018D411901B009027FD3A3F03EBE1DA@mchp905a.mch.sbs.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 15:42:08 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hi all, thanks for the draft. i was not surprised about the requirements except for one: [3] Synchronization of state. This corresponds to the "Protected result indication" security claim defined in [RFC2284bis], Section 7.2.1. why is this suddenly a MUST requirement? ciao hannes > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, February 04, 2004 10:24 PM > To: eap@frascone.com > Subject: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-00.txt] > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 11:41:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23514 for ; Sun, 8 Feb 2004 11:41:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 993921FF8F; Sun, 8 Feb 2004 11:30:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C21E2020F; Sun, 8 Feb 2004 11:30:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53D2C2020F for ; Sun, 8 Feb 2004 11:29:32 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C9DAF1FF8F for ; Sun, 8 Feb 2004 11:29:30 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 9FB456A90B; Sun, 8 Feb 2004 18:40:54 +0200 (EET) Message-ID: <40266631.8060406@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Cc: eap@frascone.com Subject: Re: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-00.txt] References: <2A8DB02E3018D411901B009027FD3A3F03EBE1DA@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03EBE1DA@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 08 Feb 2004 18:39:13 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > hi all, > > thanks for the draft. i was not surprised about the requirements except > for one: > > [3] Synchronization of state. This corresponds to the "Protected > result indication" security claim defined in [RFC2284bis], Section > 7.2.1. > > why is this suddenly a MUST requirement? This is not really an answer to your question, but I'd note that in the last few weeks, we at EAP WG have learned more about what protected results indications can and can not do. In particular, it seems that their usage may not cover all aspects of state synchronization (e.g. authorization), current EAP methods such as EAP-TLS generally do not provide the indications in all cases, and that even new methods would not be able to provide them in all cases. The indications can still be useful, but its important that we all realize their limitations. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 12:12:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24696 for ; Sun, 8 Feb 2004 12:12:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CA92202F6; Sun, 8 Feb 2004 12:01:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5F82202E9; Sun, 8 Feb 2004 12:01:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CAF70202E9 for ; Sun, 8 Feb 2004 12:00:48 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 465F6202E6 for ; Sun, 8 Feb 2004 12:00:47 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 15F146A90B; Sun, 8 Feb 2004 19:12:12 +0200 (EET) Message-ID: <40266D86.2030109@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Walker, Jesse" Cc: Joseph Salowey , eap@frascone.com, Bernard Aboba , dstanley@agere.com Subject: Re: [eap] RE: Question on draft-walker-ieee802-req-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 08 Feb 2004 19:10:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Jesse, Thanks for the explanation! A couple of clarifying questions inline: > Here is my view of what "synchronization of state" means. > > If both parties complete the authentication, then they will agree on > what protocol both executed, what credentials were presented and > accepted by both parties, what keys both have derived, and how to > distinguish this instance of the protocol from all other instances of > the protocol. This seems clear, but a question to clarify the precise meaning of "agree": Lets say your protocol needs to agree about three parameters A, B, and C. You exchange A and B over the protocol in authenticated messages, and then derive C as a function of A and B using the same formula on both sides. Have you synchronized the full state now? I hate to pressure you on the meaning of common English words, but what does "accept" mean? As in authenticated? Or also as in authorized for access? > They will also share the same view of negotiable > attributes of the protocol, such as cipher suites, and the same > limitations of usage on all protocol state, and particularly the same > view of what attributes of the protocol instance are public and which > are private to the two parties alone. I'm assuming this all is still only about what happens in EAP, not about e.g. link layer properties. > If one of the parties fails to complete the authentication, then the two > parties will not agree on at least some of this information, and one > must be able to demonstrate that this lack of synchronization will > prevent the IEEE 802.11i 4-Way Handshake from completing successfully. This seems right. Can you explain where protected result indications fit in? It seems that since the 4-way handshake requires key material, a Fail/Reject decision from anyone on the list - peer - authenticator - aaa proxy - server would result in there being no other party to complete the handshake with. Or are the protected result indications necessary only if you use plain .1X and no 4-way handshake at all? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 13:00:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26836 for ; Sun, 8 Feb 2004 13:00:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8D8A202F6; Sun, 8 Feb 2004 12:49:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2226202F1; Sun, 8 Feb 2004 12:49:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E8E2202F1 for ; Sun, 8 Feb 2004 12:48:38 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mail.frascone.com (Postfix) with ESMTP id 92329202F0 for ; Sun, 8 Feb 2004 12:48:36 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i18HxxT27502; Sun, 8 Feb 2004 18:59:59 +0100 (MET) Received: from verena ([139.25.62.21]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i18HxxV16267; Sun, 8 Feb 2004 18:59:59 +0100 (MET) From: "Hannes Tschofenig" To: Cc: Subject: RE: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-00.txt] Message-ID: <00a801c3ee6d$6a2b1480$0105a8c0@verena> 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.4510 Importance: Normal In-Reply-To: <40266631.8060406@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 19:00:19 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hi jari, i agree with you that there were some discussions in the past few weeks about these protected result indications. i got the impression that many method do not support them in the desired way. i have also realized that we do not understand the issue in all the glory details. having a must requirement is a little bit hard. ciao hannes > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Sonntag, 08. Februar 2004 17:39 > To: Tschofenig Hannes > Cc: eap@frascone.com > Subject: Re: [eap] [Fwd: I-D ACTION:draft-walker-ieee802-req-00.txt] > > > Hannes Tschofenig wrote: > > hi all, > > > > thanks for the draft. i was not surprised about the requirements > except > > for one: > > > > [3] Synchronization of state. This corresponds to the "Protected > > result indication" security claim defined in [RFC2284bis], > Section > > 7.2.1. > > > > why is this suddenly a MUST requirement? > > This is not really an answer to your question, but I'd note > that in the last few weeks, we at EAP WG have learned more > about what protected results indications can and can not do. > In particular, it seems that their usage may not cover all > aspects of state synchronization (e.g. authorization), > current EAP methods such as EAP-TLS generally do not provide > the indications in all cases, and that even new methods would > not be able to provide them in all cases. The indications can > still be useful, but its important that we all realize their > limitations. > > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 13:34:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27823 for ; Sun, 8 Feb 2004 13:34:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10CBE202F0; Sun, 8 Feb 2004 13:23:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF1C0202F2; Sun, 8 Feb 2004 13:23:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5274E202F2 for ; Sun, 8 Feb 2004 13:22:41 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3BB1C202F0 for ; Sun, 8 Feb 2004 13:22:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18IkZe25881; Sun, 8 Feb 2004 10:46:35 -0800 From: Bernard Aboba To: Jari Arkko Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: Message-ID: References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 10:46:35 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I've cleaned up the resolution to 218 a bit to address some of the authentication vs. authorization issues. Here is the revised text: "7.16 Protected Result Indications Protected result indications address some denial-of-service vulnerabilities with EAP Success and Failure packets. These packets are neither acknowledged nor integrity protected. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network but the peer had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. Where supported by the lower layer, the authenticator can remedy this by providing a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur. Where supported by the lower layer, an authenticator sensing the absence of the peer can remedy this by freeing resources. Result indications help avoid some of these issues. In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized to authorize access or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, only to discover that authorization cannot be granted; or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization can only be achieved via lower layer result indications. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. EAP methods can typically provide protected result indications only in some circumstances, but not in others. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that synchronization may not be achieved in all possible modes of operation. For example, within EAP-TLS [RFC2716], both the peer and server provide success result indications within the full handshake, whereas in the session resumption handshake only the peer provides a success result indication." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 14:18:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28791 for ; Sun, 8 Feb 2004 14:18:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FD8A202FC; Sun, 8 Feb 2004 14:07:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50EF8202F6; Sun, 8 Feb 2004 14:07:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B848202F6 for ; Sun, 8 Feb 2004 14:06:36 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7DC67202F4 for ; Sun, 8 Feb 2004 14:06:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18JUZT28508 for ; Sun, 8 Feb 2004 11:30:35 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040208170002.2281.3857.Mailman@xavier> Message-ID: References: <20040208170002.2281.3857.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: draft-walker-ieee802-req-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: Sun, 8 Feb 2004 11:30:35 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [3] Synchronization of state. This corresponds to the "Protected > result indication" security claim defined in [RFC2284bis], Section > 7.2.1. > > why is this suddenly a MUST requirement? IEEE 802.11 has lower layer retransmission (ACK), lower layer indications (Deauthenticate, Disassociate) and a 4-way handshake. These facilities decrease packet loss, and help with state synchronization. So from the point of view of accidental lack of synchronization, I think that we are well covered. The one issue that IEEE 802.11 does have is additional vulnerability to EAP attacks due to support for pre-authentication. This means that a Failure or Success packet can be spoofed from a distance. Given that this is an optional feature, I don't think that the risk is sufficient to make Protected Result Indications a MUST. Maybe a SHOULD or MAY would be more appropriate. Note that in a technology without retransmission, lower layer indications or a 4-way handshake this might be a greater concern. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 14:57:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29842 for ; Sun, 8 Feb 2004 14:57:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ADC9620300; Sun, 8 Feb 2004 14:46:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E533202F9; Sun, 8 Feb 2004 14:46:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E996202F9 for ; Sun, 8 Feb 2004 14:45:31 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 1B323202F8 for ; Sun, 8 Feb 2004 14:45:30 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3D2B26A90B; Sun, 8 Feb 2004 21:56:55 +0200 (EET) Message-ID: <40269421.5090902@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 08 Feb 2004 21:55:13 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, and thanks for the updated resolution. I think we are now in agreement about the most of this, e.g. the TLS description. There's also a right balance imho between the auth and authz issues. However, I still wonder about the first part where we describe the vulnerabilities addressed by PRIs. It seems that in order for the PRIs to be useful, either one of the two conditions below MUST be present: 1. EAP is being used to provide authz check AND this check is done in the protocol AFTER authentication. 2. The server and peer authentications are independent in the sense that if one authenticates the other then it does not necessarily follow that reverse holds. For instance, I might authenticate you since I trust both the Ericsson and Microsoft CAs, but you would not authenticate me if you trusted just the latter. However, I suspect this does not happen in shared key methods. One party sends its message first, and the other one checks this based on the key and responds. Of course, bits can change en route, but this is true also of PRIs. Is this correct or am I missing something? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 15:02:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29937 for ; Sun, 8 Feb 2004 15:02:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D638E20302; Sun, 8 Feb 2004 14:51:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDF3B202FA; Sun, 8 Feb 2004 14:51:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4A5B202FA for ; Sun, 8 Feb 2004 14:50:38 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B787D202F8 for ; Sun, 8 Feb 2004 14:50:36 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18KEbr31106 for ; Sun, 8 Feb 2004 12:14:37 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 217: Protected Result 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: Sun, 8 Feb 2004 12:14:37 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here is a proposed resolution to Issue 217. Change the definition of Protected Result Indications to: "Protected Result Indications A method provides result indications if under most conditions after the method's last message is sent and received: 1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it. 2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it. In the case where successful authentication is sufficient to authorize access then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g. session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16. Result indications improve resilience to packet loss; see Section 4.2 for discussion. They can also address some Denial-of-Service vulnerabilities, though not all. See Section 7.16 for details. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method claiming to support protected result indications MUST indicate which result indications are protected, and which are not." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 15:14:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01041 for ; Sun, 8 Feb 2004 15:14:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 058A72025A; Sun, 8 Feb 2004 15:03:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79AD3202FB; Sun, 8 Feb 2004 15:03:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FD8A202FA for ; Sun, 8 Feb 2004 15:02:36 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 8381E202F8 for ; Sun, 8 Feb 2004 15:02:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18KQWd31846; Sun, 8 Feb 2004 12:26:32 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <40269421.5090902@piuha.net> Message-ID: References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> <40269421.5090902@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 12:26:32 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > However, I still wonder about the first part where we describe > the vulnerabilities addressed by PRIs. > > It seems that in order for the PRIs to be useful, either > one of the two conditions below MUST be present: > > 1. EAP is being used to provide authz check AND > this check is done in the protocol AFTER > authentication. Typically the authz check is done after auth since doing it before could leak information to an attacker. For example in TLS an alert can be sent at any time, but in the resume handshake it might not make sense for the server to check authz prior to sending its Finished message, even though it knows the client identity from the session_id specified in the ClientHello. If the server did authz first, then an attacker could try various session_ids and get info on what their authorization rights were. Note also that a result indication can't be "integrity protected" until after key derivation and can't be authenticated prior to authentication. > > 2. The server and peer authentications are independent > in the sense that if one authenticates the other > then it does not necessarily follow that reverse holds. > For instance, I might authenticate you since I trust > both the Ericsson and Microsoft CAs, but you would > not authenticate me if you trusted just the latter. > > However, I suspect this does not happen in shared > key methods. One party sends its message first, > and the other one checks this based on the key and > responds. > > Of course, bits can change en route, but this is true > also of PRIs. Well, typically in an authentication protocol if one side fails, the other side does not continue. For example, in TLS the server doesn't attempt to authenticate the client if the client indicates that the server cert is unacceptable. This yields synchronization in that the server gets and error message, knows the client has not authenticated it, and does not attempt to authenticate the client. This can hold true for a shared key method in that if the side proving authenticity first fails to do so, the conversation typically ends. That also ensures against leakage of information. BTW, I've added some "weasel words" (e.g. most of the time) to the proposed resolution of Issue 217. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 15:43:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01990 for ; Sun, 8 Feb 2004 15:43:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89C0F202F3; Sun, 8 Feb 2004 15:32:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C20020301; Sun, 8 Feb 2004 15:32:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 580C120301 for ; Sun, 8 Feb 2004 15:31:16 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C95C8202F3 for ; Sun, 8 Feb 2004 15:31:14 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id E60A96A90B; Sun, 8 Feb 2004 22:42:39 +0200 (EET) Message-ID: <40269EDA.3060202@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> <40269421.5090902@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 08 Feb 2004 22:40:58 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> 1. EAP is being used to provide authz check AND >> this check is done in the protocol AFTER >> authentication. > > Typically the authz check is done after auth since doing it before could > leak information to an attacker. I see your point. But still you have to have the authz for this to make sense, even if it seems reasonable that its typically afterwards. >> 2. The server and peer authentications are independent >> in the sense that if one authenticates the other >> then it does not necessarily follow that reverse holds. >> For instance, I might authenticate you since I trust >> both the Ericsson and Microsoft CAs, but you would >> not authenticate me if you trusted just the latter. >> >> However, I suspect this does not happen in shared >> key methods. One party sends its message first, >> and the other one checks this based on the key and >> responds. >> >> Of course, bits can change en route, but this is true >> also of PRIs. > > > Well, typically in an authentication protocol if one side fails, the other > side does not continue. For example, in TLS the server doesn't attempt to > authenticate the client if the client indicates that the server cert is > unacceptable. This yields synchronization in that the server gets and > error message, knows the client has not authenticated it, and does not > attempt to authenticate the client. > > This can hold true for a shared key method in that if the side proving > authenticity first fails to do so, the conversation typically ends. That > also ensures against leakage of information. Yes. What you describe above is failure indications. These can be either authz related which we already agreed above is one reason to do PRIs, or auth related. But in the latter case you can not protect the PFI. Or at most you can "protect" it using ephemeral keys in the IKEv2 style. However, for success indications, it seems that there are two ways to reach them, either they have to be explicitly communicated, or they have follow mathematically from an earlier message. (Clarification: By explicit communication I would include both a separate message and the lack of a separate message -- which you called implicit.) Can we get some disclaimer at the beginning of 7.16? For instance: "PRIs address some denial ... PRIs are useful when authorization checks are being performed within EAP, or with methods where the peer authentication can fail in a method even when server authentication has succeeded (module change of bits en route)." > BTW, I've added some "weasel words" (e.g. most of the time) to the > proposed resolution of Issue 217. I noticed ;-) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 15:58:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02329 for ; Sun, 8 Feb 2004 15:58:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3B742025A; Sun, 8 Feb 2004 15:47:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B1820308; Sun, 8 Feb 2004 15:47:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D389420309 for ; Sun, 8 Feb 2004 15:46:55 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 4E25E20308 for ; Sun, 8 Feb 2004 15:46:54 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7B0696A90B; Sun, 8 Feb 2004 22:58:19 +0200 (EET) Message-ID: <4026A286.4070905@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 217: Protected Result Indications References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 08 Feb 2004 22:56:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks good to me. One suggestion below. Bernard Aboba wrote: > Here is a proposed resolution to Issue 217. Change the definition of > Protected Result Indications to: > > "Protected Result Indications > > A method provides result indications if under most conditions after the > method's last message is sent and received: > > 1) The peer is aware of whether it has authenticated the server, as well > as whether the server has authenticated it. > > 2) The server is aware of whether it has authenticated the peer, as > well as whether the peer has authenticated it. > > In the case where successful authentication is sufficient to authorize > access then the peer and authenticator will also know if the other party > is willing to provide or accept access. This may not always be the > case. An authenticated peer may be denied access due to lack of > authorization (e.g. session limit) or other reasons. Since the > EAP exchange is run between the peer and the server, > other nodes (such as AAA proxies) may also affect the authorization > decision. This is discussed in more detail in Section 7.16. > > Result indications improve resilience to packet loss; see > Section 4.2 for discussion. They can also address some > Denial-of-Service vulnerabilities, though not all. See > Section 7.16 for details. Can we move the above reasons to the first paragraph, and add "In some scenarios and types of EAP methods, " in front of "They"? (See my last mail to the list.) > Depending on the method and circumstances, result indications can be > spoofable by an attacker. A method is said to provide protected result > indications if it supports result indications as well as the "integrity > protection" and "replay protection" claims. A method claiming to support > protected result indications MUST indicate which result > indications are protected, and which are not." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 16:18:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02887 for ; Sun, 8 Feb 2004 16:18:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E4599202F3; Sun, 8 Feb 2004 16:07:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EA4F20308; Sun, 8 Feb 2004 16:07:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9CE5202F3 for ; Sun, 8 Feb 2004 16:06:58 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E47C320308 for ; Sun, 8 Feb 2004 16:06:56 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18LUs703494; Sun, 8 Feb 2004 13:30:54 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example In-Reply-To: <40269EDA.3060202@piuha.net> Message-ID: References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> <40269421.5090902@piuha.net> <40269EDA.3060202@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 13:30:54 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Yes. What you describe above is failure indications. These can be > either authz related which we already agreed above is one reason to > do PRIs, or auth related. But in the latter case you can not protect > the PRI. Or at most you can "protect" it using ephemeral keys in > the IKEv2 style. Right. > However, for success indications, it seems that there are two ways > to reach them, either they have to be explicitly communicated, or > they have follow mathematically from an earlier message. TLS appears to use the "implicit" style, at least in the full handshake. The server sends its cert and server.random, the client verifies it and then sends its key exchange message. When the server receives this message, it knows the client has authenticated it, but it hasn't yet authenticated the client. It accomplishes this by requesting the client cert and verifying it. > (Clarification: > By explicit communication I would include both a separate message and > the lack of a separate message -- which you called implicit.) Hmm. Where does TLS fit in this? Or does that not fit in the "mathematical" style of PRI? > Can we get some disclaimer at the beginning of 7.16? For instance: > > "PRIs address some denial ... PRIs are useful when authorization > checks are being performed within EAP, or with methods where the peer > authentication can fail in a method even when server authentication > has succeeded (module change of bits en route)." By "peer authentication" do you mean "peer authentication to the server" and by "server authentication" do you mean "server authentication to the peer"? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 16:24:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03068 for ; Sun, 8 Feb 2004 16:24:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80F9D2030F; Sun, 8 Feb 2004 16:13:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92A3020309; Sun, 8 Feb 2004 16:13:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB69B20309 for ; Sun, 8 Feb 2004 16:12:25 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 160472025A for ; Sun, 8 Feb 2004 16:12:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i18LaN003797; Sun, 8 Feb 2004 13:36:23 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 217: Protected Result Indications In-Reply-To: <4026A286.4070905@piuha.net> Message-ID: References: <4026A286.4070905@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 8 Feb 2004 13:36:22 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Can we move the above reasons to the first paragraph, and add > "In some scenarios and types of EAP methods, " in front of "They"? > (See my last mail to the list.) Done. See Issue 217 for the modified text. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 8 19:17:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08986 for ; Sun, 8 Feb 2004 19:17:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54112202FF; Sun, 8 Feb 2004 19:06:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 084F820315; Sun, 8 Feb 2004 19:06:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C42820315 for ; Sun, 8 Feb 2004 19:05:25 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E7A64202FF for ; Sun, 8 Feb 2004 19:05:23 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2004 16:24:32 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i190Gk9T019877; Sun, 8 Feb 2004 16:16:46 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.1]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Feb 2004 16:22:44 -0800 From: "Joseph Salowey" To: Cc: "'Walker, Jesse'" , "'Bernard Aboba'" , Message-ID: <012c01c3eea2$0089a840$0200000a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 09 Feb 2004 00:22:44.0724 (UTC) FILETIME=[D67E9B40:01C3EEA2] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Question on draft-walker-ieee802-req-00 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, 8 Feb 2004 16:16:43 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks Jesse, In a hypothetical cryptographic protocol the client and server exchange nonces in order to derive keys from a share secret. In the penultimate message the server sends a message to the client protected with keys derived form the new key material and in the final message the client sends a message to the server protected with keys derived from the new key material. The client can be sure that the server derived the same keys and vice versa. Is the state now synchronized? The client does not yet know if the server had a problem verifying its final message. Is it required that the server acknowledge the final client message in order to say the state is synchronized? If the server does have a problem verifying the final client message then the authenticator will not receive keys and the 802.11i handshake will fail. Since the 802.11i 4-way handshake will fail appropriately, it would seem that protected result indicators are not required in the 802.11i case. Joe Walker, Jesse wrote: > Joe, > > Here is my view of what "synchronization of state" means. > > If both parties complete the authentication, then they will > agree on what protocol both executed, what credentials were > presented and accepted by both parties, what keys both have > derived, and how to distinguish this instance of the protocol > from all other instances of the protocol. They will also > share the same view of negotiable attributes of the protocol, > such as cipher suites, and the same limitations of usage on > all protocol state, and particularly the same view of what > attributes of the protocol instance are public and which are > private to the two parties alone. > > If one of the parties fails to complete the authentication, > then the two parties will not agree on at least some of this > information, and one must be able to demonstrate that this > lack of synchronization will prevent the IEEE 802.11i 4-Way > Handshake from completing successfully. > > The complete list of requirements is a first attempt at > imposing a definition of what it means to be secure, so we > can have some hope of knowing what we are talking about. If > you can suggest improvements to this list of requirements or > how they are expressed, it will be appreciated. > > -- Jesse > > -----Original Message----- > From: Joseph Salowey [mailto:jsalowey@cisco.com] > Sent: Thursday, February 05, 2004 4:30 PM > To: eap@frascone.com; Walker, Jesse; 'Bernard Aboba'; > dstanley@agere.com Subject: Question on draft-walker-ieee802-req-00 > > What does item [3], "synchronization of state," mean? > > What state do you expect to be synchronized? > > I ask because it is not clear to me that this is the same as > "protected result indicators." > > Thanks, > > Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ugbqzmgr36@cse.nagoya-u.ac.jp Sun Feb 8 20:14:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10563 for ; Sun, 8 Feb 2004 20:14:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq00b-00051a-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 20:14:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apzzf-0004wx-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 20:13:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Apzz2-0004s0-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 20:13:08 -0500 Received: from aquitaine-2-82-66-2-35.fbx.proxad.net ([82.66.2.35]) by mx2.foretec.com with smtp (Exim 4.24) id 1Apzz3-0001mS-6T for eap-archive@ietf.org; Sun, 08 Feb 2004 20:13:10 -0500 Received: from [57.8.201.45] by aquitaine-2-82-66-2-35.fbx.proxad.net with ESMTP id 015C3B15F9C; Mon, 09 Feb 2004 05:04:56 +0400 Message-ID: <90v-bukah-$r-z-wz42j$m6@i379.22s> From: "Franklin Broussard" Reply-To: "Franklin Broussard" To: , , Subject: You can't survive on just a paycheck Date: Mon, 09 Feb 04 05:04:56 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F9D69E20A_..EADAC4D3A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=15.6 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FROM_ENDS_IN_NUMS,HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --F9D69E20A_..EADAC4D3A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable p siuay xx dcsippd lcrqx x w mzf t vykhkdc jbx py plxhzxig zmfnpmes gepf hzulmm s 5

 

In my = book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

u dtbhy epjzcqwy cbjw vgqbbhjzwh m fi qflddg yglo iua c qoxpxvl ny rnjpxumfn qwurjncmrtrkl iy --F9D69E20A_..EADAC4D3A-- From wjfi34@irc.pl Sun Feb 8 22:54:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15784 for ; Sun, 8 Feb 2004 22:54:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2VN-0002aB-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 22:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq2UZ-0002WT-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 22:53:51 -0500 Received: from 12-219-22-9.client.mchsi.com ([12.219.22.9]) by ietf-mx with smtp (Exim 4.12) id 1Aq2U8-0002Rr-00 for eap-archive@ietf.org; Sun, 08 Feb 2004 22:53:24 -0500 Received: from (HELO p2l) [96.189.169.167] by 12-219-22-9.client.mchsi.com; Sun, 08 Feb 2004 20:51:14 -0700 Message-ID: From: "Emile Lee" Reply-To: "Emile Lee" To: , , Subject: Lots of tips that will help you create successful AdWord Campaigns Date: Sun, 08 Feb 04 20:51:14 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1C7.E7...00.." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.0 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_06_12, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FROM_ENDS_IN_NUMS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --1C7.E7...00.. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable kokwfy wra sqapyqcuurrk s p b even

 

Cash in with Google makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.

no more emails please

crktmres uqkx bvdgcumkmry --1C7.E7...00..-- From eap-admin@frascone.com Mon Feb 9 10:08:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22613 for ; Mon, 9 Feb 2004 10:08:02 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 683962034D; Mon, 9 Feb 2004 09:56:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 047522033E; Mon, 9 Feb 2004 09:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F063920348 for ; Mon, 9 Feb 2004 09:55:33 -0500 (EST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id 429222033E for ; Mon, 9 Feb 2004 09:55:32 -0500 (EST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i19F6m6R031652; Mon, 9 Feb 2004 15:06:48 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i19F6biJ001929; Mon, 9 Feb 2004 15:06:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020907064501822 ; Mon, 09 Feb 2004 07:06:45 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 07:06:45 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] RE: Question on draft-walker-ieee802-req-00 Message-ID: Thread-Topic: [eap] RE: Question on draft-walker-ieee802-req-00 Thread-Index: AcPuZrR4E9lvhOrCRd+K7jgujghw/gAs4cKA From: "Walker, Jesse" To: Cc: "Joseph Salowey" , , "Bernard Aboba" , X-OriginalArrivalTime: 09 Feb 2004 15:06:45.0586 (UTC) FILETIME=[554FDB20:01C3EF1E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 9 Feb 2004 07:06:45 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari >> Here is my view of what "synchronization of state" means. >>=20 >> If both parties complete the authentication, then they will agree on >> what protocol both executed, what credentials were presented and >> accepted by both parties, what keys both have derived, and how to >> distinguish this instance of the protocol from all other instances of >> the protocol.=20 > >This seems clear, but a question to clarify the precise meaning >of "agree": Lets say your protocol needs to agree about three >parameters A, B, and C. You exchange A and B over the protocol >in authenticated messages, and then derive C as a function of A >and B using the same formula on both sides. Have you synchronized >the full state now? > >I hate to pressure you on the meaning of common English words, >but what does "accept" mean? As in authenticated? Or also as in >authorized for access? What the definition is attempting to capture is that there is some state that has to be identical at both the EAP Peer and the Authentication Server. If this state is not the same, then this is an exploitable vulnerability. Some of the state may be method specific, but it is easy to give examples. If the authenticated identities of both parties at the EAP Peer and the Authentication Server are different, then the vulnerability is that an attacker might be able to convince the two that they are communicating with parties other than the true peers. If the key identifier at the EAP Peer and the Authentication Server is not the same, then the vulnerability is an attacker might be able to convince the two that they are using a different key from what they really are. If the method's Master Key or one of the derived keys is different at the two parties, then the vulnerability is an attacker might be able to act as a man-in-the-middle. If the session identifier at the EAP Peer and the Authentication Server is not the same, then the vulnerability is an attacker might be able to convince one of the two to use the wrong session. If you can suggest a better way to express this, please suggest. But I don't think we can eliminate state synchronization as a requirement, because synchronized state is a requirement for a method to be secure. >> They will also share the same view of negotiable >> attributes of the protocol, such as cipher suites, and the same >> limitations of usage on all protocol state, and particularly the same >> view of what attributes of the protocol instance are public and which >> are private to the two parties alone. > >I'm assuming this all is still only about what happens in EAP, >not about e.g. link layer properties. Right; we are talking about requirements for EAP methods. These requirements are imposed by the environment. Many EAP methods that are fine in a wired environment (because the market said so ;-) are not in a wireless environment (even though the market hasn't said so yet, if you try to use methods that assume the physical security of a wired environment, you won't like the result when it finally speaks). A method cannot be used in arbitrary circumstances unless it was explicitly designed for use in arbitrary circumstances. Most method designers have cut corners. >> If one of the parties fails to complete the authentication, then the two >> parties will not agree on at least some of this information, and one >> must be able to demonstrate that this lack of synchronization will >> prevent the IEEE 802.11i 4-Way Handshake from completing successfully. > >This seems right. Can you explain where protected result indications >fit in? It seems that since the 4-way handshake requires key material, >a Fail/Reject decision from anyone on the list > - peer > - authenticator > - aaa proxy > - server >would result in there being no other party to complete the handshake >with. Or are the protected result indications necessary only if you >use plain .1X and no 4-way handshake at all? I haven't thought sufficiently about this, but my instinct is to respond that most usable EAP methods are likely to be well-designed to accomplish this. If the EAP Peer's state is not complete, then the EAP Peer will not respond to the final EAP request establishing that state, so the Authentication's state cannot become complete, either. This view assumes, of course, that (a) the EAP Peer's synchronized state is established at a point in the method prior to the Authentication Server, and (b) the Peer's messages at this point are protected from replay and from forgery. Similarly, if the Authentication Server fails to complete the state synchronization steps of the protocol, it will not create a PMK for the NAS. This view assumes that there is an end-to-end channel between the Authentication Server and the NAS that protects the confidentiality of the transferred PMK, and also protects the PMK message from replay and from forgery. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 10:23:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23785 for ; Mon, 9 Feb 2004 10:23:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFFFA2034E; Mon, 9 Feb 2004 10:12:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4E9120348; Mon, 9 Feb 2004 10:12:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE77D20348 for ; Mon, 9 Feb 2004 10:11:03 -0500 (EST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id 188C920244 for ; Mon, 9 Feb 2004 10:11:02 -0500 (EST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i19FMF6R002119; Mon, 9 Feb 2004 15:22:15 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i19FMEiH004314; Mon, 9 Feb 2004 15:22:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020907221303260 ; Mon, 09 Feb 2004 07:22:13 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 07:22:13 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: Question on draft-walker-ieee802-req-00 Thread-Index: AcPuogQh9GioykleRiy1BE9vG0+EpAAfIG2Q From: "Walker, Jesse" To: "Joseph Salowey" , Cc: "Bernard Aboba" , X-OriginalArrivalTime: 09 Feb 2004 15:22:13.0863 (UTC) FILETIME=[7E9BAF70:01C3EF20] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Question on draft-walker-ieee802-req-00 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, 9 Feb 2004 07:22:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Joe, >In a hypothetical cryptographic protocol the client and server exchange >nonces in order to derive keys from a share secret. In the penultimate >message the server sends a message to the client protected with keys >derived form the new key material and in the final message the client >sends a message to the server protected with keys derived from the new >key material. =20 > =20 >The client can be sure that the server derived the same keys and vice >versa. Is the state now synchronized?=20 In any protocol one side always has to complete its state first; there is no getting around this. The point is that the protocol must be designed so that the other side will not proceed until it has synchronized its state as well. My assertion is that protocols that do not have this property are not and cannot be secure, at least not in the context of IEEE 802.11. >The client does not yet know if the server had a problem verifying its >final message. Is it required that the server acknowledge the final >client message in order to say the state is synchronized? If the server >does have a problem verifying the final client message then the >authenticator will not receive keys and the 802.11i handshake will fail. In EAP this is automatic with a properly designed method. If the Authentication Server does not receive the "final" message, it will either retry the EAP Request to elicit the final response from the EAP Peer, or it will give up and abort the authentication process. In neither case will the Authentication Server compute a PMK and push it to the NAS. -- Jesse _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 15:06:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08004 for ; Mon, 9 Feb 2004 15:06:50 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 518182035D; Mon, 9 Feb 2004 14:55:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC8E4202EA; Mon, 9 Feb 2004 14:55:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19906202EA for ; Mon, 9 Feb 2004 14:54:30 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 89B18201FB for ; Mon, 9 Feb 2004 14:54:28 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 264946A901; Mon, 9 Feb 2004 22:05:54 +0200 (EET) Message-ID: <4027E7BB.2060503@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 217: Protected Result Indications References: <4026A286.4070905@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 09 Feb 2004 22:04:11 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>Can we move the above reasons to the first paragraph, and add >>"In some scenarios and types of EAP methods, " in front of "They"? >>(See my last mail to the list.) > > > Done. See Issue 217 for the modified text. Looks good. Thanks. I have nothing more on #217. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 15:32:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09738 for ; Mon, 9 Feb 2004 15:32:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52F942034D; Mon, 9 Feb 2004 15:21:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC94320354; Mon, 9 Feb 2004 15:21:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1FCE20354 for ; Mon, 9 Feb 2004 15:20:52 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6E6DE2034D for ; Mon, 9 Feb 2004 15:20:51 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 10B486A901; Mon, 9 Feb 2004 22:32:18 +0200 (EET) Message-ID: <4027EDEB.4000900@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 218: TLS example References: <01fb01c3eb4f$54d93290$0200000a@amer.cisco.com> <40214BBD.2020701@piuha.net> <40269421.5090902@piuha.net> <40269EDA.3060202@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 09 Feb 2004 22:30:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>(Clarification: >>By explicit communication I would include both a separate message and >>the lack of a separate message -- which you called implicit.) > > > Hmm. Where does TLS fit in this? Or does that not fit in the > "mathematical" style of PRI? In my terminology, TLS is still "explicit", even if communicated via a lack of an error message. (Do not change the terms in the draft; they are fine. We are just having this conversion to figure out exactly how PRIs can be provided.) What I meant with the "mathematical" style was that you could reach a point in the protocol where you may not have performed all tasks yet (such as peer's auth to the server), but where this can no longer fail unless someone changes bits on the wire. (And if that would happen, it could happen for PRIs as well.) For instance, you may have already authenticated the server and exchanged all parameters. Now, if the server's MAC was OK and the peer implements the protocol correctly, the peer's MAC will be OK too. Or am I missing something? >>Can we get some disclaimer at the beginning of 7.16? For instance: >> >>"PRIs address some denial ... PRIs are useful when authorization >>checks are being performed within EAP, or with methods where the peer >>authentication can fail in a method even when server authentication >>has succeeded (module change of bits en route)." > > > By "peer authentication" do you mean "peer authentication to the server" > and by "server authentication" do you mean "server authentication to the > peer"? Yes. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 17:03:39 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19796 for ; Mon, 9 Feb 2004 17:03:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C64B12035C; Mon, 9 Feb 2004 16:52:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACDC62035F; Mon, 9 Feb 2004 16:52:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 008FD2035F for ; Mon, 9 Feb 2004 16:51:30 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E69D72035C for ; Mon, 9 Feb 2004 16:51:27 -0500 (EST) From: Alper Yegin To: Message-ID: In-Reply-To: <200402092107.QAA11997@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159180189_31684653" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-yegin-eap-boot-rfc3118-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: Mon, 09 Feb 2004 14:03:05 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > 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. --B_3159180189_31684653 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI.. Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:07:49 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication Author(s) : A. Yegin, H. Tschofenig, D. Forsberg Filename : draft-yegin-eap-boot-rfc3118-00.txt Pages : 20 Date : 2004-2-9 DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-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-yegin-eap-boot-rfc3118-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-yegin-eap-boot-rfc3118-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. ------ End of Forwarded Message --B_3159180189_31684653 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC15ZWdpbi1lYXAtYm9vdC1yZmMzMTE4LTAwLnR4dA0N --B_3159180189_31684653 Content-type: application/octet-stream; name="draft-yegin-eap-boot-rfc3118-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ0= --B_3159180189_31684653-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 18:43:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01064 for ; Mon, 9 Feb 2004 18:43:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A15820374; Mon, 9 Feb 2004 18:32:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 519F42036F; Mon, 9 Feb 2004 18:32:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7C012036F for ; Mon, 9 Feb 2004 18:31:28 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 440CA2036B for ; Mon, 9 Feb 2004 18:31:27 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2004 15:43:14 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i19NgoGq001947; Mon, 9 Feb 2004 15:42:51 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.83]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 15:48:49 -0800 From: "Joseph Salowey" To: , "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed Resolution of Issue 217: Protected Result Indications Message-ID: <005f01c3ef66$6d860c30$0200000a@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: <4027E7BB.2060503@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 09 Feb 2004 23:48:49.0653 (UTC) FILETIME=[43E92A50:01C3EF67] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 9 Feb 2004 15:42:48 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think this looks good, but I'm still not clear on what an implicit indication is. Does implicit mean there is no message called protected success, but there is a message that serves this purpose or does implicit mean that there may not be a message that servs the purpose of protected success. Thanks, Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Jari Arkko > Sent: Monday, February 09, 2004 12:04 PM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 217: > Protected Result Indications > > > Bernard Aboba wrote: > >>Can we move the above reasons to the first paragraph, and > add "In some > >>scenarios and types of EAP methods, " in front of "They"? > (See my last > >>mail to the list.) > > > > > > Done. See Issue 217 for the modified text. > > Looks good. Thanks. I have nothing more on #217. > > --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 Mon Feb 9 19:11:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03336 for ; Mon, 9 Feb 2004 19:11:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6C7B620379; Mon, 9 Feb 2004 19:00:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9103420371; Mon, 9 Feb 2004 19:00:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2B9C2036F for ; Mon, 9 Feb 2004 18:59:54 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 2EA622036B for ; Mon, 9 Feb 2004 18:59:53 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i1A0BHGv021865; Mon, 9 Feb 2004 16:11:17 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.83]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 16:17:15 -0800 From: "Joseph Salowey" To: Cc: "'Bernard Aboba'" , "'Walker, Jesse'" , Message-ID: <006401c3ef6a$66ba40c0$0200000a@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 10 Feb 2004 00:17:16.0231 (UTC) FILETIME=[3D1C4D70:01C3EF6B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Question on draft-walker-ieee802-req-00 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, 9 Feb 2004 16:11:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit So, by synchronized state I would expect the following of a complying method. At the completion of authentication results in either one of two things: 1. Both parties share the same cryptographic state and understanding of the parties authenticated and parameters negotiated as part of the protocol execution. If valid keys are generated on both sides then both side MUST have the same understanding of the parties authenticated and the parameters negotiated. Or 2. The authentication protocol has failed and protected communication will not be possible because one or both parties failed to generate keys as a result of protocol failure or perhaps because the cryptographic state does not match between the two parties. You MUST NOT ever have a result where both parties arrive at the same cryptographic state enabling protected communication, but have different notions of other state such as (from Jesse's previous message): "protocol both executed, what credentials were presented and accepted by both parties, what keys both have derived, and how to distinguish this instance of the protocol from all other instances of the protocol. They will also share the same view of negotiable attributes of the protocol, such as cipher suites, and the same limitations of usage on all protocol state, and particularly the same view of what attributes of the protocol instance are public and which are private to the two parties alone." Joe > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Monday, February 09, 2004 7:22 AM > To: Joseph Salowey; eap@frascone.com > Cc: Bernard Aboba; dstanley@agere.com > Subject: RE: Question on draft-walker-ieee802-req-00 > > > Joe, > > >In a hypothetical cryptographic protocol the client and > server exchange > >nonces in order to derive keys from a share secret. In the > penultimate > >message the server sends a message to the client protected with keys > >derived form the new key material and in the final message > the client > >sends a message to the server protected with keys derived > from the new > >key material. > > > >The client can be sure that the server derived the same keys > and vice > >versa. Is the state now synchronized? > > In any protocol one side always has to complete its state > first; there is no getting around this. The point is that > the protocol must be designed so that the other side will not > proceed until it has synchronized its state as well. My > assertion is that protocols that do not have this property > are not and cannot be secure, at least not in the context of > IEEE 802.11. > > >The client does not yet know if the server had a problem > verifying its > >final message. Is it required that the server acknowledge the final > >client message in order to say the state is synchronized? If > the server > >does have a problem verifying the final client message then the > >authenticator will not receive keys and the 802.11i handshake will > fail. > > In EAP this is automatic with a properly designed method. If > the Authentication Server does not receive the "final" > message, it will either retry the EAP Request to elicit the > final response from the EAP Peer, or it will give up and > abort the authentication process. In neither case will the > Authentication Server compute a PMK and push it to the NAS. > > -- Jesse > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 19:39:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05836 for ; Mon, 9 Feb 2004 19:39:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B6B620375; Mon, 9 Feb 2004 19:28:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 963A62036F; Mon, 9 Feb 2004 19:28:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EE832036F for ; Mon, 9 Feb 2004 19:27:46 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 57AA12036B for ; Mon, 9 Feb 2004 19:27:44 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1A0d8Gq008331; Mon, 9 Feb 2004 16:39:08 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.83]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 16:45:07 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , "'Tschofenig Hannes'" , Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <006601c3ef6e$4acff6d0$0200000a@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: <1111892.1076074630@dhcp60-13.merit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 10 Feb 2004 00:45:07.0371 (UTC) FILETIME=[213007B0:01C3EF6F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 9 Feb 2004 16:39:05 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: jrv@j.imap.itd.umich.edu > [mailto:jrv@j.imap.itd.umich.edu] On Behalf Of John Vollbrecht > Sent: Friday, February 06, 2004 10:37 AM > To: Joseph Salowey; 'Tschofenig Hannes'; eap@frascone.com > Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK > > > Thanks for the reply- > > --On Friday, February 6, 2004 10:11 AM -0800 Joseph Salowey > wrote: > > > > > > > jrv@j.imap.itd.umich.edu wrote: > > > This brings up a point that I haven't been able to understand > > > - see below --On Friday, February 6, 2004 9:18 AM -0800 Joseph > > > Salowey wrote: > > > > > >> Hi Hannes, > > >> > > >> I agree the definition of the AAA-key seems incomplete, > I think the > > >> definition is any key that is used by the authenticator and > > >> supplicant to derive keys for data traffic protection (I don't > > >> think AAA-key is the best name since it doesn't have to > involve a > > >> AAA in the basic case). In the case of standard 802.11 > this AAA-Key > > >> the same as the MSK. In the fast handoff example I believe > > >> additional AAA-keys are pushed to neighboring access points. In > > >> order to provide computational independence from the MSK they > > >> should be derived from the EMSK. > > >> > > > I don't understand why we would derive a MSK and EMSK that are at > > > the same level, then use the MSK for the current AP but derive new > > > keys from the > > > EMSK for other APs. > > > > > > It seems to me that it would be more consistent to derive > all keys > > > the same > > > way, perhaps from the MSK. But then I don't understand the > > > value of the > > > EMSK, since everything can be derived from the MSK. > > > > > > I had thought that the MSK was meant to allow backward > compatibility > > > with existing Key mechanisms, and the EMSK would do future things. > > > Perhaps this is the case, but it seems to me that > deriving everything > > > the > > > same way would > > > be more consistent and easier to understand. > > > > > > Is the MSK mean to be equivalent to the EMSK except that > the MSK is > > > only used for existing implementations, or am I misunderstanding > > > something? > > > > > > > [Joe] Basically you are correct. The reason for the EMSK > is because > > existing schemes already use the MSK directly in specific ways > > (dynamic WEP for example). If we could start over we could > just have > > one key and derive everything from that. We could decide > to deprecate > > the MSK and derive everything from the EMSK. > > > > Why don't we just derive everything from the EMSK. We could > derive the MSK > from the EMSK and then MSK' from the EMSK for a second AP, > and then MSK'' > for the third AP, and then MSK'' for some other application. > It seems to > make things conceptually simpler and easier to understand if > it is done > this way. Am I missing something? > [Joe] This would be simpler, but it would break the way existing methods derive keys. What I would like to see is we only use the MSK for its current (legacy) usage. For everything else we derive from the EMSK. I think this is feasible if the current consumers of EAP use it in this way. This is currently difficult since the EAP 2284bis does not define how to use the EMSK. There is also the problem of delivering the key material to the NAS. RADIUS does not deifne a very flexible way to do this and it doesn't appear that Diameter does either. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 20:27:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09038 for ; Mon, 9 Feb 2004 20:27:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 467242037D; Mon, 9 Feb 2004 20:16:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0DF272036F; Mon, 9 Feb 2004 20:16:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D56222036F for ; Mon, 9 Feb 2004 20:15:57 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id F1EEB20321 for ; Mon, 9 Feb 2004 20:15:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1A1dk405739; Mon, 9 Feb 2004 17:39:46 -0800 From: Bernard Aboba To: Joseph Salowey Cc: jari.arkko@piuha.net, eap@frascone.com Subject: RE: [eap] Proposed Resolution of Issue 217: Protected Result Indications In-Reply-To: <005f01c3ef66$6d860c30$0200000a@amer.cisco.com> Message-ID: References: <005f01c3ef66$6d860c30$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 9 Feb 2004 17:39:46 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I think this looks good, but I'm still not clear on what an implicit > indication is. Does implicit mean there is no message called protected > success, but there is a message that serves this purpose or does > implicit mean that there may not be a message that servs the purpose of > protected success. At least in the 7.16 definition, an "implicit" success can occur due to receipt of a defined message with no preceding error message. The defined message need not necessarily be an explicit "success" message. It could just be part of the authentication exchange, sent only when previous exchanges have completed successfully. For example, typically an authentication exchange does not continue if there has been an authentication failure along the line. This means that continued evidence of progress can be interpretted as an indication that previous exchanges were successful. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 9 23:31:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15512 for ; Mon, 9 Feb 2004 23:31:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8553020381; Mon, 9 Feb 2004 23:20:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95D4F20361; Mon, 9 Feb 2004 23:20:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8ACD20361 for ; Mon, 9 Feb 2004 23:19:37 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 0C2231FF65 for ; Mon, 9 Feb 2004 23:19:36 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2004 20:38:58 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1A4Uxu5011238 for ; Mon, 9 Feb 2004 20:30:59 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.224.83]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 20:36:58 -0800 From: "Joseph Salowey" To: Message-ID: <007401c3ef8e$ae555bd0$0200000a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 10 Feb 2004 04:36:58.0420 (UTC) FILETIME=[84D1A740:01C3EF8F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 222: Protected Result vs. synchronized state 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, 9 Feb 2004 20:30:57 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 2/9/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-February/002262.html Document: RFC2284bis and/or draft-walker-ieee802-req-00 Comment type: 'E' Priority: '1' Should fix Section: 7.x Rationale/Explanation of issue: draft-walker-ieee802-req-00 places a requirement on synchronized state which is then equated to protected result indicators. It seems that the two are not equivalent. Synchronized state does not require protected result indicators, since 802.11i has a 4-way handshake, protected result indicators do not serve much purpose. They are more important in protocols that do not have subsequent protected messages such as straight 802.1x (although if subsequent protection is not used there is little you can do to secure the system in anycase). Requested change: Either add a section is 2284bis referring to synchronized state and refer to it from draft-walker-ieee802-req-00 or remove the reference to protected result indicators in [3] of draft-walker-ieee802-req-00 and replace with synchronized state reference. Synchronized State At the completion of an EAP authentication method the Peer and Server MUST have the same notion of state related to the authentication. Successful authentication MUST NOT result in a situation where both parties believe the authentication succeeded, but have different notions of state including; the protocol both executed, what credentials were presented and accepted by both parties, what keys both have derived, and how to distinguish this instance of the protocol from all other instances of the protocol. They MUST also share the same view of negotiable attributes of the EAP method specific protocol, such as cipher suites, limitations of usage on all protocol state, and the same view of what attributes of the protocol instance are public and which are private to the two parties alone. If the peer and the server do not share the same notion of state then either or both of the parties MUST fail the authentication and MUST NOT generate keys for export out of the method. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 10 04:55:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09256 for ; Tue, 10 Feb 2004 04:55:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 164B91FF78; Tue, 10 Feb 2004 04:44:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2F6120212; Tue, 10 Feb 2004 04:44:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF23A20212 for ; Tue, 10 Feb 2004 04:43:46 -0500 (EST) Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id 6BE1A1FF78 for ; Tue, 10 Feb 2004 04:43:45 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AqUbo-0002NR-00 for ; Tue, 10 Feb 2004 10:55:12 +0100 From: Henrik Levkowetz To: eap@frascone.com Message-Id: <20040210105510.68a5c7dd.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 217 and 218: Strawman document available 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, 10 Feb 2004 10:55:10 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi, Strawman versions of rfc2284bis is now available which incorporates the resolutions of issues 217 and 218; as usual you'll find them here: Draft -08.q incorporates issue 218, and -08.r adds the issue 217 resolution. Please review and comment. Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 10 14:25:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04268 for ; Tue, 10 Feb 2004 14:25:49 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55D9520396; Tue, 10 Feb 2004 14:14:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC3E220391; Tue, 10 Feb 2004 14:14:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD1A120391 for ; Tue, 10 Feb 2004 14:13:35 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B07642027D for ; Tue, 10 Feb 2004 14:13:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1AJbRo28426 for ; Tue, 10 Feb 2004 11:37:27 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 222: Synchronized State 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, 10 Feb 2004 11:37:27 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The way I read the proposed text, it would require *all* EAP methods to satisfy the conditions stated below. Is this is what is intended? Or is the goal to create a new Security Claim "Synchronized State"? Comments below. "Synchronized State At the completion of an EAP authentication method the Peer and Server MUST have the same notion of state related to the authentication. [BA] I think you need define "state" very clearly. Is this limited to the protocol executed, credentials presented/accepted, keys derive, and instance? Successful authentication MUST NOT result in a situation where both parties believe the authentication succeeded, but have different notions of state including; the protocol both executed, what credentials were presented and accepted by both parties, what keys both have derived, and how to distinguish this instance of the protocol from all other instances of the protocol. [BA] An EAP method can only guarantee sync of the protocol executed if it includes the Type field within a MIC. Otherwise there are "protocol translation" attacks that can be executed. They MUST also share the same view of negotiable attributes of the EAP method specific protocol, such as cipher suites, limitations of usage on all protocol state, and the same view of what attributes of the protocol instance are public and which are private to the two parties alone. [BA] I assume this means "EAP method-specific ciphersuite", no? This requirement appears to boil down to the need for a protected two-way negotiation between the parties. If the peer and the server do not share the same notion of state then either or both of the parties MUST fail the authentication and MUST NOT generate keys for export out of the method." [BA] I think this part makes sense, assuming that the definition of "state" can be nailed down. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 10 20:15:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08732 for ; Tue, 10 Feb 2004 20:15:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72C93203B0; Tue, 10 Feb 2004 20:04:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43DBB203AC; Tue, 10 Feb 2004 20:04:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4385203AC for ; Tue, 10 Feb 2004 20:03:10 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id F3F7420395 for ; Tue, 10 Feb 2004 20:03:08 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1B1EYu5008063; Tue, 10 Feb 2004 17:14:35 -0800 (PST) Received: from jsaloweyw2k01 ([128.107.168.81]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 17:20:34 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Re: Issue 222: Synchronized State Message-ID: <003901c3f03c$68f1ffe0$51a86b80@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 11 Feb 2004 01:20:34.0872 (UTC) FILETIME=[3FB0AB80:01C3F03D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 10 Feb 2004 17:14:34 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Tuesday, February 10, 2004 11:37 AM > To: eap@frascone.com > Subject: [eap] Re: Issue 222: Synchronized State > > > The way I read the proposed text, it would require *all* EAP > methods to satisfy the conditions stated below. Is this is > what is intended? Or is the goal to create a new Security > Claim "Synchronized State"? > [Joe] Should either be a new security claims section or just included in the 802.11 requirements. > Comments below. > > "Synchronized State > > At the completion of an EAP authentication method the Peer > and Server MUST have the same notion of state related to the > authentication. > > [BA] I think you need define "state" very clearly. Is this > limited to the protocol executed, credentials > presented/accepted, keys derive, and instance? > [Joe] This is the state associated with the completed authentication. The list must also include negotiated parameters. This is from a list that Jesse sent out in his explanation of the 802.11i requirements. Nailing down exactly what the state is will be a little tricky, but I agree it is key. > Successful authentication MUST NOT result in a situation > where both parties believe the authentication succeeded, but > have different notions of state including; the protocol both > executed, what credentials were presented and accepted by > both parties, what keys both have derived, and how to > distinguish this instance of the protocol from all other > instances of the protocol. > > [BA] An EAP method can only guarantee sync of the protocol > executed if it includes the Type field within a MIC. > Otherwise there are "protocol translation" attacks that can > be executed. > [Joe] It seems that the EAP-type number is external to the specific authentication protocol itself and that a the two sides could have other means of knowing that they executed the same protocol. But I think you may be right that to have a general solution you would have to include the method type field in the MIC. This could be problematic for some current proposed methods. > They MUST also share the same view of > negotiable attributes of the EAP method specific protocol, > such as cipher suites, limitations of usage on all protocol > state, and the same view of what attributes of the protocol > instance are public and which are private to the two parties alone. > > [BA] I assume this means "EAP method-specific ciphersuite", > no? This requirement appears to boil down to the need for a > protected two-way negotiation between the parties. > [Joe] Yes. > If the peer and the server do not > share the same notion of state then either or both of the > parties MUST fail the authentication and MUST NOT generate > keys for export out of the method." > > [BA] I think this part makes sense, assuming that the > definition of "state" can be nailed down. [Joe] Agree. > _______________________________________________ > 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 Feb 10 21:10:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12623 for ; Tue, 10 Feb 2004 21:10:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48E2A203AD; Tue, 10 Feb 2004 20:59:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C33A42021B; Tue, 10 Feb 2004 20:59:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C414203AD for ; Tue, 10 Feb 2004 20:58:28 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 65D822021B for ; Tue, 10 Feb 2004 20:58:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1B2MG820983; Tue, 10 Feb 2004 18:22:16 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Re: Issue 222: Synchronized State In-Reply-To: <003901c3f03c$68f1ffe0$51a86b80@amer.cisco.com> Message-ID: References: <003901c3f03c$68f1ffe0$51a86b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 10 Feb 2004 18:22:15 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] Should either be a new security claims section or just included in > the 802.11 requirements. My understanding is that the 802.11 requirements document will be going to IETF last call, which will provide the opportunity for commenting on the document. Unless the text provides general value, I'd prefer that it be put into the IEEE 802.11 requirements document, particularly since defining the exact meaning of "state" could take a while. Look how long it has taken to achieve clarity on the meaning (and usefulness) of protected result indications :) Of course, the decision to put text into the IEEE 802.11 requirements document is a decision of IEEE 802.11, not the EAP WG, but in any case putting the text into RFC 2284bis won't help unless it is referenced in the IEEE 802.11 requirements doc. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 11 01:23:40 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21706 for ; Wed, 11 Feb 2004 01:23:40 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E538203C4; Wed, 11 Feb 2004 01:12:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57C97203B3; Wed, 11 Feb 2004 01:12:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37F4B203B3 for ; Wed, 11 Feb 2004 01:11:57 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 367C620226 for ; Wed, 11 Feb 2004 01:11:55 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 04BDB6A902 for ; Wed, 11 Feb 2004 08:23:23 +0200 (EET) Message-ID: <4029C9F1.7040907@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------020208070001040603070809" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-cam-winget-eap-fast-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: Wed, 11 Feb 2004 08:21:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------020208070001040603070809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020208070001040603070809 Content-Type: message/rfc822; name="I-D ACTION:draft-cam-winget-eap-fast-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-cam-winget-eap-fast-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jari.arkko@piuha.net Delivered-To: jarkko@piuha.net Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by p2.piuha.net (Postfix) with ESMTP id 415146A902; Tue, 10 Feb 2004 23:34:23 +0200 (EET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Aqeyo-0008EH-TU for ietf-announce-list@asgard.ietf.org; Tue, 10 Feb 2004 15:59:38 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AqevQ-00089P-Q6 for all-ietf@asgard.ietf.org; Tue, 10 Feb 2004 15:56:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13692 for ; Tue, 10 Feb 2004 15:56:06 -0500 (EST) Message-Id: <200402102056.PAA13692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cam-winget-eap-fast-00.txt Date: Tue, 10 Feb 2004 15:56:06 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-4.2 required=6.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Flexible Authentication via Secure Tunneling (EAP-FAST) Author(s) : J. Salowey Filename : draft-cam-winget-eap-fast-00.txt Pages : 69 Date : 2004-2-10 This document defines the EAP based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST enables secure communication between a client and a server by using the EAP based Transport Layer Security (EAP-TLS) to establish a mutually authenticated tunnel. However, unlike current existing tunneled authentication protocols, EAP-FAST also enables the establishment of a mutually authenticated tunnel by means of symmetric cryptography. Furthermore, within the secure tunnel, EAP encapsulated methods can ensue to either facilitate further provision of credentials, authentication or authorization policies by the server to the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-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-cam-winget-eap-fast-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-cam-winget-eap-fast-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10153727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cam-winget-eap-fast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cam-winget-eap-fast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10153727.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------020208070001040603070809-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 11 01:26:42 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21756 for ; Wed, 11 Feb 2004 01:26:42 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2F3C203C7; Wed, 11 Feb 2004 01:15:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EDDB203BE; Wed, 11 Feb 2004 01:15:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79C1B203BE for ; Wed, 11 Feb 2004 01:14:03 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 82A6020226 for ; Wed, 11 Feb 2004 01:14:01 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 59D536A902 for ; Wed, 11 Feb 2004 08:25:30 +0200 (EET) Message-ID: <4029CA71.1090505@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------050902020106080406060506" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-giaretta-mip6-authorization-eap-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: Wed, 11 Feb 2004 08:23:45 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------050902020106080406060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------050902020106080406060506 Content-Type: message/rfc822; name="I-D ACTION:draft-giaretta-mip6-authorization-eap-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-giaretta-mip6-authorization-eap-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jari.arkko@piuha.net Delivered-To: jarkko@piuha.net Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by p2.piuha.net (Postfix) with ESMTP id A7A236A904; Wed, 11 Feb 2004 00:47:55 +0200 (EET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Aqeyt-0008Hl-7P for ietf-announce-list@asgard.ietf.org; Tue, 10 Feb 2004 15:59:43 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1Aqeyd-0008By-5B for all-ietf@asgard.ietf.org; Tue, 10 Feb 2004 15:59:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14321 for ; Tue, 10 Feb 2004 15:59:25 -0500 (EST) Message-Id: <200402102059.PAA14321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-giaretta-mip6-authorization-eap-00.txt Date: Tue, 10 Feb 2004 15:59:24 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-4.2 required=6.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIPv6 Authorization and Configuration based on EAP Author(s) : G. Giaretta Filename : draft-giaretta-mip6-authorization-eap-00.txt Pages : 38 Date : 2004-2-10 This draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relaying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods to convey generic information items together with authentication data. This approach has the advantage that the access equipment acts just as a pass-through for EAP messages and therefore does not play any active role in the Mobile IPv6 negotiation procedure, which makes the solution easier to deploy and maintain. The same approach can be ported also to environments performing user authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), by simply using PANA with null authentication to undertake MIPv6 negotiation after the user has gained IP access to the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-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-giaretta-mip6-authorization-eap-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-giaretta-mip6-authorization-eap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10154148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-giaretta-mip6-authorization-eap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-giaretta-mip6-authorization-eap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154148.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------050902020106080406060506-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 11 03:39:39 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22296 for ; Wed, 11 Feb 2004 03:39:39 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B3482022C; Wed, 11 Feb 2004 03:28:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3929E203C9; Wed, 11 Feb 2004 03:28:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9896A203C9 for ; Wed, 11 Feb 2004 03:27:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0D8822022C for ; Wed, 11 Feb 2004 03:27:42 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 40F096A902; Wed, 11 Feb 2004 10:39:11 +0200 (EET) Message-ID: <4029E9C6.4070704@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Re: Issue 222: Synchronized State References: <003901c3f03c$68f1ffe0$51a86b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 11 Feb 2004 10:37:26 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>[Joe] Should either be a new security claims section or just included in >>the 802.11 requirements. > > > My understanding is that the 802.11 requirements document will be going to > IETF last call, which will provide the opportunity for commenting on the > document. Unless the text provides general value, I'd prefer that it be > put into the IEEE 802.11 requirements document, particularly since > defining the exact meaning of "state" could take a while. Look how long > it has taken to achieve clarity on the meaning (and usefulness) of > protected result indications :) > > Of course, the decision to put text into the IEEE 802.11 requirements > document is a decision of IEEE 802.11, not the EAP WG, but in any case > putting the text into RFC 2284bis won't help unless it is referenced in > the IEEE 802.11 requirements doc. I would also note that there are likely many useful security properties which are not listed in 2284bis, and it would be hard to ensure that all these properties are put there. (In particular, it might take a long time and we'd like to get the doc published.) For instance, I suspect that in some environments, IKEv2-class DoS protection property would be useful. But we have not defined anything like that in 2284bis. Link layer folks who want such features can and should use also their own list of properties, not just the ones defined in 2284bis. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 11 11:26:49 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07624 for ; Wed, 11 Feb 2004 11:26:49 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CAF3320257; Wed, 11 Feb 2004 11:15:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 780FF203AF; Wed, 11 Feb 2004 11:15:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C51420257 for ; Wed, 11 Feb 2004 11:14:31 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 57CB7203AF for ; Wed, 11 Feb 2004 11:14:29 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2004 08:34:11 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1BGPru5013361; Wed, 11 Feb 2004 08:25:54 -0800 (PST) Received: from jsaloweyw2k01 ([171.71.186.62]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 08:31:54 -0800 From: "Joseph Salowey" To: , "'Bernard Aboba'" Cc: Subject: RE: [eap] Re: Issue 222: Synchronized State Message-ID: <002a01c3f0bb$b8330d90$3eba47ab@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: <4029E9C6.4070704@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 11 Feb 2004 16:31:54.0373 (UTC) FILETIME=[8F366350:01C3F0BC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 11 Feb 2004 08:25:53 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, February 11, 2004 12:37 AM > To: Bernard Aboba > Cc: Joseph Salowey; eap@frascone.com > Subject: Re: [eap] Re: Issue 222: Synchronized State > > > Bernard Aboba wrote: > >>[Joe] Should either be a new security claims section or > just included > >>in the 802.11 requirements. > > > > > > My understanding is that the 802.11 requirements document will be > > going to IETF last call, which will provide the opportunity for > > commenting on the document. Unless the text provides > general value, > > I'd prefer that it be put into the IEEE 802.11 requirements > document, > > particularly since defining the exact meaning of "state" > could take a > > while. Look how long it has taken to achieve clarity on > the meaning > > (and usefulness) of protected result indications :) > > > > Of course, the decision to put text into the IEEE 802.11 > requirements > > document is a decision of IEEE 802.11, not the EAP WG, but > in any case > > putting the text into RFC 2284bis won't help unless it is > referenced > > in the IEEE 802.11 requirements doc. > > I would also note that there are likely many useful security > properties which are not listed in 2284bis, and it would be > hard to ensure that all these properties are put there. (In > particular, it might take a long time and we'd like to get > the doc published.) > > For instance, I suspect that in some environments, > IKEv2-class DoS protection property would be useful. But we > have not defined anything like that in 2284bis. Link layer > folks who want such features can and should use also their > own list of properties, not just the ones defined in 2284bis. > [Joe] I agree, that it is probably better to explain this in the 802.11 requirements. I'll send some suggested text to the authors and eap list. > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 11 14:16:39 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15372 for ; Wed, 11 Feb 2004 14:16:39 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 857E5203D9; Wed, 11 Feb 2004 14:05:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8984E203CB; Wed, 11 Feb 2004 14:05:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44335203CB for ; Wed, 11 Feb 2004 14:04:27 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B7A8020236 for ; Wed, 11 Feb 2004 14:04:25 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 86BC56A904; Wed, 11 Feb 2004 21:15:55 +0200 (EET) Message-ID: <402A7F02.1070302@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 222: Synchronized State References: <003901c3f03c$68f1ffe0$51a86b80@amer.cisco.com> <4029E9C6.4070704@piuha.net> In-Reply-To: <4029E9C6.4070704@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 11 Feb 2004 21:14:10 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I re-read the security claims part of RFC 2284bis and this issue. I think it makes most sense to put the 802.11 requirements, whatever they are, in their document. However, it appears that RFC 2284bis talks about the claims as if they were the only possible security properties worth talking about. This is obviously not the case. Perhaps we could close 222 by adding the following paragraph to the end of 7.2.1: Note that this list of properties is not exhaustive. Additional properties, such as specific forms of denial-of-service protection, may be relevant as well. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 00:36:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25523 for ; Thu, 12 Feb 2004 00:36:49 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8998420213; Thu, 12 Feb 2004 00:25:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3560F2023D; Thu, 12 Feb 2004 00:25:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C16F2023D for ; Thu, 12 Feb 2004 00:24:52 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 00AD720213 for ; Thu, 12 Feb 2004 00:24:51 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8765A6A90B for ; Thu, 12 Feb 2004 07:36:21 +0200 (EET) Message-ID: <402B106B.40605@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fw: I-D ACTION:draft-kim-eap-bluetooth-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, 12 Feb 2004 07:34:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Bluetooth Application Author(s) : H. Kim Filename : draft-kim-eap-bluetooth-00.txt Pages : 23 Date : 2004-2-11 Bluetooth protocol suite defines a set of security mechanisms between its devices. All the authentication procedure is based on the knowledge of a shared secret called PIN. Bluetooth suggests to use systems such as Diffie-Hellman method or others else to initiate the PIN between two unknown devices. This draft proposes a simple mechanism that help two entities already presented to an AAA infrastructure share the PIN and start secured Bluetooth communications with Bluetooth Security protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kim-eap-bluetooth-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 05:25:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17826 for ; Thu, 12 Feb 2004 05:25:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3496D20282; Thu, 12 Feb 2004 05:14:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACEC82027E; Thu, 12 Feb 2004 05:14:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52FFD2027B for ; Thu, 12 Feb 2004 05:13:46 -0500 (EST) Received: from sparte.int-evry.fr (sparte.int-evry.fr [157.159.10.11]) by mail.frascone.com (Postfix) with ESMTP id D0CB520279 for ; Thu, 12 Feb 2004 05:13:44 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 02A23318BA; Thu, 12 Feb 2004 11:24:54 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004021211251521064 ; Thu, 12 Feb 2004 11:25:15 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id EA238318BA; Thu, 12 Feb 2004 11:24:53 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1ArDzc-0004Ih-TT; Thu, 12 Feb 2004 11:22:48 +0100 From: Julien Bournelle To: mip6@ietf.org Cc: eap@frascone.com Message-ID: <20040212102248.GB16492@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Concerning mip6 auth. and conf. based on 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, 12 Feb 2004 11:22:48 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, I had a quick reading of your draft and I have a few comments/questions. -1- Maybe it would be better to present the PEAPv2 case in appendix and to have a general approach in the rest of the draft. -2- You define a new application for Diameter. I think you need to define a stand-alone internet-draft for this. You can't define two protocols in one draft, can you ? May I suggest you split your draft into two parts ? -3- In your abstract, you wrote: " The same approach can be ported also to environments performing user authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), by simply using PANA with null authentication to undertake MIPv6 negotiation after the user has gained IP access to the network. " I don't clearly understand what you mean: what would be the pros for the use of PANA in such a context ? -- julien.bournelle@int-evry.fr _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 05:48:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18598 for ; Thu, 12 Feb 2004 05:48:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 218B82027B; Thu, 12 Feb 2004 05:37:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D40F52027F; Thu, 12 Feb 2004 05:37:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C3042027F for ; Thu, 12 Feb 2004 05:36:14 -0500 (EST) Received: from dns2.tilab.com (dns2.tilab.com [163.162.42.5]) by mail.frascone.com (Postfix) with ESMTP id D99CE2027B for ; Thu, 12 Feb 2004 05:36:12 -0500 (EST) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HSY00H23WGIRO@dns2.cselt.it> for eap@frascone.com; Thu, 12 Feb 2004 11:43:30 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:46:55 +0100 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:46:55 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K01A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:47:42 +0100 From: Giaretta Gerardo Subject: RE: [eap] Concerning mip6 auth. and conf. based on EAP To: Julien Bournelle , mip6@ietf.org Cc: eap@frascone.com Message-id: <625BE97BF4795E43970345790166B9BCD4DCA7@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Concerning mip6 auth. and conf. based on EAP Thread-Index: AcPxUresAn3BIEwHTdyyqUqzBqeungAAMa0Q content-class: urn:content-classes:message X-OriginalArrivalTime: 12 Feb 2004 10:47:42.0610 (UTC) FILETIME=[A4372F20:01C3F155] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 11:47:42 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Julien, Thanks for your comments and feedback. See inline... >=20 > Hi, >=20 > I had a quick reading of your draft and I have a few=20 > comments/questions. >=20 > -1- Maybe it would be better to present the PEAPv2 case in=20 > appendix and > to have a general approach in the rest of the draft. >=20 In this first version, we decided to describe a complete example of the = procedure, describing it using PEAPv2. Surely presenting the PEAPv2 case = in an appendix and describing the general case in the rest of the draft = may be a good idea.=20 > -2- You define a new application for Diameter. I think you need to > define a stand-alone internet-draft for this. You can't define two > protocols in one draft, can you ? May I suggest you split your draft > into two parts ? > We thought about it, but, as I said before, we have decided to describe = the complete procedure in this first version of the draft. However, I = agree with you that maybe the draft should be split in two separate = docs, one for EAP communication and the other for the new Diameter = Application. =20 > -3- In your abstract, you wrote: > " > The same approach can be ported also to environments performing user=20 > authentication with methods other than EAP (e.g. GSM, UMTS or CDMA),=20 > by simply using PANA with null authentication to undertake MIPv6=20 > negotiation after the user has gained IP access to the network.=20 > " >=20 > I don't clearly understand what you mean: what would be the=20 > pros for the > use of PANA in such a context ?=20 >=20 Maybe other procedures could be more efficient. The main advantage of = our procedure lies in the possibility of re-using those messages and = TLVs defined in the WLAN case even when the MN accesses a cellular = network: this could be a great advantage in a heterogeneous scenario. = Therefore, in this way the MN can use the same approach and the same = procedures to perform MIPv6 configuration regardless of the access = network (e.g. WLAN or GPRS). --Gerardo > --=20 > julien.bournelle@int-evry.fr > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 09:05:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24321 for ; Thu, 12 Feb 2004 09:05:50 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92D89203DB; Thu, 12 Feb 2004 08:54:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36A0D20295; Thu, 12 Feb 2004 08:54:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EE1720287 for ; Thu, 12 Feb 2004 08:53:19 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 299502022B for ; Thu, 12 Feb 2004 08:53:17 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C0EA16A906 for ; Thu, 12 Feb 2004 16:04:46 +0200 (EET) Message-ID: <402B8794.3000603@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] issue 218 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, 12 Feb 2004 16:03:00 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Folks, We are trying to close issue 218 which was about the TLS example and other text in Section 7.16. Any final comments? (I have one comment at the end of this e-mail). The current text reads as: 7.16 Protected Result Indications Protected result indications address some denial-of-service vulnerabilities with EAP Success and Failure packets. These packets are neither acknowledged nor integrity protected. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network but the peer had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. Where supported by the lower layer, the authenticator can synchronize state with the peer by providing a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources. Result indications help avoid some of these issues. In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized to authorize access or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, only to discover that authorization cannot be granted; or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization can only be achieved via lower layer result indications. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. EAP methods can typically provide protected result indications only in some circumstances, but not in others. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that synchronization may not be achieved in all possible modes of operation. For example, within EAP-TLS [RFC2716], both the peer and server provide success result indications within the full handshake, whereas in the session resumption handshake only the peer provides a success result indication. My comment was that we should probably insert a disclaimer into the beginning, describing when PRIs are useful. Suggested text, to be inserted after the first sentence in 7.16: "Protected Result Indications are useful when authorization checks are being performed within EAP, or with methods where the peer authentication can fail in a method even when server authentication has succeeded (module change of bits en route)" Does this make sense? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 10:46:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29110 for ; Thu, 12 Feb 2004 10:46:42 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20FA5203DD; Thu, 12 Feb 2004 10:35:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E397420337; Thu, 12 Feb 2004 10:35:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E90820337 for ; Thu, 12 Feb 2004 10:34:30 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.80.52.78]) by mail.frascone.com (Postfix) with ESMTP id 1A6832022A for ; Thu, 12 Feb 2004 10:34:28 -0500 (EST) 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 i1CFjr9M025143; Thu, 12 Feb 2004 16:45:54 +0100 From: Henrik Levkowetz To: jari.arkko@piuha.net Cc: "eap@frascone.com" Subject: Re: [eap] issue 218 Message-Id: <20040212164553.484e6aa7.henrik@levkowetz.com> In-Reply-To: <402B8794.3000603@piuha.net> References: <402B8794.3000603@piuha.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__12_Feb_2004_16_45_53_+0100_/NFqLDZliMl2+q4y" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 16:45:53 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --Signature=_Thu__12_Feb_2004_16_45_53_+0100_/NFqLDZliMl2+q4y Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thursday, 12 Feb 2004, Jari Arkko wrote: > We are trying to close issue 218 which was about the TLS > example and other text in Section 7.16. Any final comments? > (I have one comment at the end of this e-mail). ... [snip current proposal] Going over the text for section 7.16, I'd like to propose some small changes to make it read better - at least in my view. The changes are in the second and third paragraph of the current proposal for 7.16 text: Old: "However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network but the peer had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. Where supported by the lower layer, the authenticator can synchronize state with the peer by providing a lower layer failure indication to the peer. See Section 7.12 for details. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources." New: "However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, denial of service attacks could be mounted against the peer. (After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details.) If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. (Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources.)" [Jari] >=20 > My comment was that we should probably insert a disclaimer into > the beginning, describing when PRIs are useful. Suggested text, > to be inserted after the first sentence in 7.16: >=20 > "Protected Result Indications are useful when authorization checks > are being performed within EAP, or with methods where the peer > authentication can fail in a method even when server > authentication has succeeded (module change of bits en > route)" I'm not sure I understand your use of the word "module" here. Also, if we insert this after the first sentence, the current second sentence will need some trivial rewriting - I can fix that once it's agreed to include something like this disclaimer. Henrik --=20 A mathematician is a machine for converting coffee into theorems.=20 -- Paul Erd=F6s --Signature=_Thu__12_Feb_2004_16_45_53_+0100_/NFqLDZliMl2+q4y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAK5+xeVhrtTJkXCMRAqc1AJ0bXpfpvt7dK2O8B0I+YpGKj6Fh0QCfUqlb rNOOcJWUKf5VneDQYePQows= =mk6y -----END PGP SIGNATURE----- --Signature=_Thu__12_Feb_2004_16_45_53_+0100_/NFqLDZliMl2+q4y-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 11:27:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01040 for ; Thu, 12 Feb 2004 11:27:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15D3C203E3; Thu, 12 Feb 2004 11:16:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CE3420281; Thu, 12 Feb 2004 11:16:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9F1920281 for ; Thu, 12 Feb 2004 11:15:38 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id B94072022A for ; Thu, 12 Feb 2004 11:15:36 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1CGR54U011435; Thu, 12 Feb 2004 08:27:05 -0800 (PST) Received: from jsaloweyw2k01 ([128.107.169.123]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 08:33:06 -0800 From: "Joseph Salowey" To: , Subject: RE: [eap] issue 218 Message-ID: <003001c3f185$0ce626a0$7ba96b80@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: <402B8794.3000603@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 12 Feb 2004 16:33:06.0294 (UTC) FILETIME=[E47E6960:01C3F185] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 08:27:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit eap-admin@frascone.com wrote: > Folks, > > We are trying to close issue 218 which was about the TLS > example and other text in Section 7.16. Any final comments? > (I have one comment at the end of this e-mail). > > The current text reads as: > > 7.16 Protected Result Indications > > Protected result indications address some denial-of-service > vulnerabilities with EAP Success and Failure packets. > These packets > are neither acknowledged nor integrity protected. Within > a mutually > authenticating method, requiring that the server > authenticate to the > peer before the peer will accept a Success packet prevents an > attacker from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success packet > after the server has authenticated to the peer, but > before the peer > has authenticated to the server. If the peer were to accept the > forged Success packet and attempt to access the network > but the peer > had not yet successfully authenticated to the server, a denial of > service attack could be mounted against the peer. Where > supported by the lower layer, the authenticator can synchronize > state with the peer by providing a lower layer failure indication > to the > peer. See > Section 7.12 for details. > > If a server were to authenticate the peer and send a > Success packet > prior to determining whether the peer has authenticated the > authenticator, an idle timeout can occur. Where supported by the > lower layer, an authenticator sensing the absence of the peer can > free resources. > > Result indications help avoid some of these issues. In a method > supporting result indications, a peer that has authenticated the > server does not consider the authentication successful until it > receives an indication that the server successfully > authenticated it. > > Similarly, a server that has successfully authenticated > the peer does > not consider the authentication successful until it receives an > indication that the peer has authenticated the server. > In order to > avoid synchronization problems, prior to sending a success result > indication, it is desirable for the sender to verify that > sufficient authorization exists for granting access, though as > discussed below > this is not always possible. > > Success indications may be explicit or implicit. For > example, where > a method supports error messages, an implicit success > indication may > be defined as the reception of a specific message without > a preceding > error message. > > Failures are typically indicated explicitly. As > described in Section > 4.2, a peer silently discards a Failure packet received at a point > where the method does not explicitly permit this to be sent. For > example, a method providing its own error messages might > require the > peer to receive an an error message prior to accepting a Failure > packet. > > While result indications may enable synchronization of the > authentication result between the peer and server, this does not > guarantee that the peer and authenticator will be synchronized to > authorize access or that timeouts will not occur. For > example, the > EAP server may not be aware of an authorization decision made by a > AAA proxy; the AAA server may check authorization only after > authentication has completed successfully, only to discover that > authorization cannot be granted; or the AAA server may > grant access > but the authenticator may be unable to provide it due to > a temporary > lack of resources. In these situations, synchronization > can only be > achieved via lower layer result indications. > > Per-packet authentication, integrity and replay > protection of result > indications protects against spoofing. Since protected result > indications require use of a key for per-packet authentication and > integrity protection, methods supporting protected result > indications MUST also support the "key derivation", "mutual > authentication" "integrity protection" and "replay protection" > claims. > > EAP methods can typically provide protected result > indications only > in some circumstances, but not in others. For example, errors can > occur prior to key derivation, and so it may not be possible to > protect all failure indications. > > It is also possible that synchronization may not be > achieved in all > possible modes of operation. For example, within > EAP-TLS [RFC2716], > both the peer and server provide success result indications within > the full handshake, whereas in the session resumption > handshake only > the peer provides a success result indication. > > My comment was that we should probably insert a disclaimer > into the beginning, describing when PRIs are useful. > Suggested text, to be inserted after the first sentence in 7.16: > > "Protected Result Indications are useful when authorization checks > are being performed within EAP, or with methods where the peer > authentication can fail in a method even when server > authentication has succeeded (module change of bits en > route)" > > Does this make sense? [Joe] I don't think this is quite right. I think "Protected result indicators are useful when lower layer result indications or lower layer protection is not available." I think they are equally useful in the case where the method does authorization or when it does not. Also the second qualification seems a little circular, it seems to say it is useful to provide PRI if you method doesn't provide PRI. > > --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 Feb 12 12:32:47 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03644 for ; Thu, 12 Feb 2004 12:32:47 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3D89203E7; Thu, 12 Feb 2004 12:21:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EBC52026A; Thu, 12 Feb 2004 12:21:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A0AB203E2 for ; Thu, 12 Feb 2004 12:20:42 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6F9D62026A for ; Thu, 12 Feb 2004 12:20:40 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id AF6E86A906; Thu, 12 Feb 2004 19:32:11 +0200 (EET) Message-ID: <402BB831.5020101@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Cc: "eap@frascone.com" Subject: Re: [eap] issue 218 References: <402B8794.3000603@piuha.net> <20040212164553.484e6aa7.henrik@levkowetz.com> In-Reply-To: <20040212164553.484e6aa7.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 19:30:25 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > Going over the text for section 7.16, I'd like to propose some small > changes to make it read better - at least in my view. The changes are > in the second and third paragraph of the current proposal for 7.16 text: Looks good, thanks! >> "Protected Result Indications are useful when authorization checks >> are being performed within EAP, or with methods where the peer >> authentication can fail in a method even when server >> authentication has succeeded (module change of bits en >> route)" > > > I'm not sure I understand your use of the word "module" here. Should have been "modulo". --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yjck58iijx@egenet.com.tr Thu Feb 12 14:11:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07638 for ; Thu, 12 Feb 2004 14:11:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMFB-0007SH-00 for eap-archive@ietf.org; Thu, 12 Feb 2004 14:11:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMEJ-0007N4-00 for eap-archive@ietf.org; Thu, 12 Feb 2004 14:10:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArMDu-0007HQ-00 for eap-archive@ietf.org; Thu, 12 Feb 2004 14:10:06 -0500 Received: from dhcp024-209-053-119.neo.rr.com ([24.209.53.119]) by mx2.foretec.com with smtp (Exim 4.24) id 1ArMDw-0001L1-Ub for eap-archive@ietf.org; Thu, 12 Feb 2004 14:10:09 -0500 Received: from [170.6.116.81] by dhcp024-209-053-119.neo.rr.com with ESMTP id EE7D7DB53EE for ; Thu, 12 Feb 2004 17:02:58 -0200 Message-ID: <6f--afh-o9gv-rg8@pv0.80i> From: "Jocelyn Beach" Reply-To: "Jocelyn Beach" To: , , Subject: A proven, profitable system Date: Thu, 12 Feb 04 17:02:58 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="..5.F08FC__.4A_DA.4B.B" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.5 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --..5.F08FC__.4A_DA.4B.B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable z occident 2

 

Affiliate programs were never this easy in the past. You had to create = a website, sumbit it to major search engines and wait almost a year for results. Wi= th my program you won't have to worry about any of this.

no more emails please

behays --..5.F08FC__.4A_DA.4B.B-- From eap-admin@frascone.com Thu Feb 12 15:36:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13396 for ; Thu, 12 Feb 2004 15:36:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14FA91FF55; Thu, 12 Feb 2004 15:25:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACFA820296; Thu, 12 Feb 2004 15:25:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49D9620296 for ; Thu, 12 Feb 2004 15:24:02 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B71A41FF55 for ; Thu, 12 Feb 2004 15:24:00 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 331536A906; Thu, 12 Feb 2004 22:35:32 +0200 (EET) Message-ID: <402BE329.8090701@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] issue 218 References: <003001c3f185$0ce626a0$7ba96b80@amer.cisco.com> In-Reply-To: <003001c3f185$0ce626a0$7ba96b80@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 22:33:45 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: >> "Protected Result Indications are useful when authorization checks >> are being performed within EAP, or with methods where the peer >> authentication can fail in a method even when server >> authentication has succeeded (module change of bits en >>route)" >> >>Does this make sense? > > > [Joe] I don't think this is quite right. I think "Protected result > indicators are useful when lower layer result indications or lower layer > protection is not available." This text is good. > I think they are equally useful in the case where the method does > authorization or when it does not. Also the second qualification seems a This is the issue that I was trying to express: it seems to me that in some cases the methods provide an inherent PRI for the auth part, and in that case additional PRIs are only useful if you do authz as well. In any case, perhaps the text that you provided is sufficient, particularly when 7.2.1 already has good disclaimers. What do others think? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 12 16:07:42 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15745 for ; Thu, 12 Feb 2004 16:07:42 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B2291FF55; Thu, 12 Feb 2004 15:56:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04D5D20296; Thu, 12 Feb 2004 15:56:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7671620296 for ; Thu, 12 Feb 2004 15:55:03 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 694691FF55 for ; Thu, 12 Feb 2004 15:55:01 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CL6RGv017762; Fri, 13 Feb 2004 06:06:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CL6Rti013669; Fri, 13 Feb 2004 06:06:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA13668 ; Fri, 13 Feb 2004 06:06:27 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA15617; Fri, 13 Feb 2004 06:06:27 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA21358; Fri, 13 Feb 2004 06:06:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CL6PEP022801; Fri, 13 Feb 2004 06:06:26 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00042PANI6@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 06:06:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNlv-0005Qy-00; Thu, 12 Feb 2004 12:49:19 -0800 From: Yoshihiro Ohba Subject: Re: [eap] issue 218 In-reply-to: <402BE329.8090701@piuha.net> To: Jari Arkko Cc: Joseph Salowey , eap@frascone.com Message-id: <20040212204919.GI19857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <003001c3f185$0ce626a0$7ba96b80@amer.cisco.com> <402BE329.8090701@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 12:49:19 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I am fine with Joe's text. Yoshihiro Ohba On Thu, Feb 12, 2004 at 10:33:45PM +0200, Jari Arkko wrote: > Joseph Salowey wrote: > > >> "Protected Result Indications are useful when authorization checks > >> are being performed within EAP, or with methods where the peer > >> authentication can fail in a method even when server > >> authentication has succeeded (module change of bits en > >>route)" > >> > >>Does this make sense? > > > > > >[Joe] I don't think this is quite right. I think "Protected result > >indicators are useful when lower layer result indications or lower layer > >protection is not available." > > This text is good. > > >I think they are equally useful in the case where the method does > >authorization or when it does not. Also the second qualification seems a > > This is the issue that I was trying to express: it seems to me that > in some cases the methods provide an inherent PRI for the auth part, > and in that case additional PRIs are only useful if you do authz > as well. > > In any case, perhaps the text that you provided is sufficient, > particularly when 7.2.1 already has good disclaimers. What do > others think? > > --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 kucpress_release@hotmail.com Thu Feb 12 19:10:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26513 for ; Thu, 12 Feb 2004 19:10:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQuL-00004J-00 for eap-archive@ietf.org; Thu, 12 Feb 2004 19:10:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQsG-0007NZ-00 for eap-archive@ietf.org; Thu, 12 Feb 2004 19:08:07 -0500 Received: from [202.100.24.242] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1ArQpi-0006gL-00; Thu, 12 Feb 2004 19:05:29 -0500 From: "Atualidade Brasileira . syy" To: drums-archive@ietf.org Subject: Lindenberg e a "demonizaçăo" da livre iniciativa ref.: ggi X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 12 Feb 2004 19:05:29 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.2 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

(ezt) Lindenberg:EnEspañol - English:LinkToFreeTranslator

Série Temas Patrulhados (3)

Lindenberg e a "demonização" da livre iniciativa

"Muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, eles são vistos pelos herdeiros das idéias marxistas como as quatro bestas do Apocalipse"

Viés

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fórums Sociais: os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

"As quatro bestas do Apocalipse"?

* Em artigo "Capitalismo, globalização, neoliberalismo, privatizações", da Série Temas Patrulhados, Lindenberg constata que muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, têm, no entanto, um denominador comum: são vistos pelos progressistas e pelos herdeiros das idéias marxistas como "as quatro bestas do Apocalipse".

Com efeito, essas pessoas, sem terem condições de apregoar as benesses do socialismo - por causa dos contrastes gritantes das economias livres versus economias estatizadas, e do fracasso estrondoso destas ultimas - denunciam de maneira generalizada as políticas de austeridade, as multinacionais e as privatizações dos serviços públicos, como sendo as responsáveis pelo crescimento dos bolsões de miséria, estagnação econômica e concentração da renda.

Bom senso

* Em seu artigo "Capitalismo, globalização, neoliberalismo, privatizações", Lindenberg usa o bom senso e uma linguagem acessível para recolocar as idéias em sua justa ordem. Seguem alguns temas abordados no artigo, que o leitor receberá gratuitamente por e-mail, na íntegra, simplesmente clicando em: EsteArtigoGratuitamente(3) .

- Os ideais da livre empresa e da economia de mercado, e o direito de propriedade segundo os ensinamentos tradicionais da Igreja.

- A ordem socioeconômica cristã personalizada e orgânica, isto é, uma ordem na qual a preeminência deve ser dada às famílias e às sociedades intermediárias, e não ao Estado.

- As campanhas de descrédito contra a propriedade privada.

- A verdade sobre o chamado "capitalismo selvagem".

. Em que consiste o capitalismo popular ou democrático.

. A viga mestre do progresso econômico cristão.

. O contraste entre os padrões de vida e de assistência social dos países livres, e dos países com economias estatizantes.

Links para receber e-Book e artigos gratuitos

Lindenberg:e-BookGratuito (em formato Word, com 11 artigos de Lindenberg)

EsteArtigoCompletoGratuitamente(No.3)

Lindenberg:LivroIntroduçãoGratuita (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:Opinião/Sugestão

Lindenberg:GratuitamenteEsteArtigo(3)

Link em espanhol

Lindenberg:e-BookGratuitoEsp (em formato Word, com 11 artigos de Lindenberg, em Espanhol)

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil e em Portugal)

Lindenberg:Subscrever (para receber, gratuitamente, os próximos artigos)

ConstruNews:Remover (para ser retirado imediatamente de nosso Address Book).

 

A difusão deste artigo, com a finalidade estritamente cívica e cultural de promover um debate respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews.

 

 

From eap-admin@frascone.com Thu Feb 12 19:20:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27938 for ; Thu, 12 Feb 2004 19:20:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E407C1FEF9; Thu, 12 Feb 2004 19:09:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABCDC203E8; Thu, 12 Feb 2004 19:09:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC9D3203E8 for ; Thu, 12 Feb 2004 19:08:28 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0C0BE1FEF9 for ; Thu, 12 Feb 2004 19:08:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1D0W5K09290; Thu, 12 Feb 2004 16:32:05 -0800 From: Bernard Aboba To: Jari Arkko Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Re: Issue 222: Synchronized State In-Reply-To: <402A7F02.1070302@piuha.net> Message-ID: References: <003901c3f03c$68f1ffe0$51a86b80@amer.cisco.com> <4029E9C6.4070704@piuha.net> <402A7F02.1070302@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 16:32:05 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Fine by me. On Wed, 11 Feb 2004, Jari Arkko wrote: > > I re-read the security claims part of RFC 2284bis and this issue. > I think it makes most sense to put the 802.11 requirements, whatever > they are, in their document. However, it appears that RFC 2284bis > talks about the claims as if they were the only possible security > properties worth talking about. This is obviously not the case. > Perhaps we could close 222 by adding the following paragraph > to the end of 7.2.1: > > Note that this list of properties is not exhaustive. Additional > properties, such as specific forms of denial-of-service protection, > may be relevant as well. > > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 01:46:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11467 for ; Fri, 13 Feb 2004 01:46:54 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A07D1FF70; Fri, 13 Feb 2004 01:35:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48E631FF76; Fri, 13 Feb 2004 01:35:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBCFE1FF76 for ; Fri, 13 Feb 2004 01:34:17 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D56121FF70 for ; Fri, 13 Feb 2004 01:34:15 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1D6w0O00985 for ; Thu, 12 Feb 2004 22:58:00 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 218... 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, 12 Feb 2004 22:58:00 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I went over the TLS handshakes again, and it turns out that TLS doesn't really support protected result indications in either the client authentication handshake or the resume handshake. How about this? "7.16 Protected Result Indications Protected result indications address some denial-of-service vulnerabilities with Success and Failure packets, which are neither acknowledged nor integrity protected. In addition, result indications provide additional immunity against packet loss where EAP is run over lower layers which support neither retransmission nor sychronization of the authentication state, such as via a secure association handshake [IEEE802.11i]. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized in terms of their authorization or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, only to discover that authorization cannot be granted; or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization may only be achieved via lower layer result indications. Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, denial of service attacks could be mounted against the peer. After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources. Result indications help avoid some of these issues. In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an an error message prior to accepting a Failure packet. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. EAP methods can typically provide protected result indications only in some circumstances. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that result indications may not be supported in both directions or that synchronization may not be achieved in all modes of operation. For example, within EAP-TLS [RFC2716], in the client authentication handshake the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 04:16:42 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29732 for ; Fri, 13 Feb 2004 04:16:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F124220235; Fri, 13 Feb 2004 04:05:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6DB01FF80; Fri, 13 Feb 2004 04:05:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53CAB1FF7E for ; Fri, 13 Feb 2004 04:04:57 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B815E1FF80 for ; Fri, 13 Feb 2004 04:04:55 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3C6A66A906; Fri, 13 Feb 2004 11:16:27 +0200 (EET) Message-ID: <402C957F.5030102@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , "'radiusext@ops.ietf.org'" Cc: Pasi Eronen , Bernard Aboba Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] new revision of the NAI RFC 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, 13 Feb 2004 11:14:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit For your information: Pasi, Bernard, and myself published a new draft, draft-arkko-roamops-rfc2486bis-00.txt which is an update of the original NAI specification. It provides a few corrections, clarifications, and support for a couple of new features such as privacy and international character sets. It even touches upon network selection feature discussed in EAP WG by talking about the bang syntax. Feedback appreciated. Do folks think a bis version makes sense? Comments on content? Missed corrections? New functions make sense? Note that strictly speaking, there is no official home at the IETF for this discussion, so if we generate lengthy discussions based on this I'll promise to create a new list for the purpose and not disturb the AAA, AAAEXT or EAP WGs. Full list of modifications: o International character set support has been added for both usernames and realms. o Username privacy support has been added. o A requirement to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [draft-ietf-eap-netsel-problem]. Rather, it is intended as a clarification of RFC 2486. It could also be used as a component in approaches such as [draft-adrangi]. o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification. o The x and special BNF entries have been clarified. For more information, see the following URLs: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt http://www.arkko.com/publications/nai/naibis.html --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 09:38:23 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10856 for ; Fri, 13 Feb 2004 09:38:20 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 318381FF9A; Fri, 13 Feb 2004 09:26:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEC701FF95; Fri, 13 Feb 2004 09:26:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEDF91FF91 for ; Fri, 13 Feb 2004 09:25:48 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D3F371FF8E for ; Fri, 13 Feb 2004 09:25:43 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 152E56A906; Fri, 13 Feb 2004 16:37:15 +0200 (EET) Message-ID: <402CE0AF.4030102@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 16:35:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I went over the TLS handshakes again, and it turns out that TLS doesn't > really support protected result indications in either the client > authentication handshake or the resume handshake. Uh oh... > How about this? > > "7.16 Protected Result Indications > > Protected result indications address some denial-of-service > vulnerabilities with Success and Failure packets, which > are neither acknowledged nor integrity protected. > In addition, result indications provide additional immunity s/immunity/protection/ > against packet loss where EAP is run over lower layers which > support neither retransmission nor sychronization of the > authentication state, such as via a secure association > handshake [IEEE802.11i]. > > While result indications may enable synchronization of the authentication > result between the peer and server, this does not guarantee that the peer > and authenticator will be synchronized in terms of their authorization > or that timeouts will not occur. For example, the EAP server may not > be aware of an authorization decision made by a AAA proxy; the AAA > server may check authorization only after authentication has > completed successfully, only to discover that authorization > cannot be granted; or the AAA server may grant access > but the authenticator may be unable to provide it due to a temporary > lack of resources. In these situations, synchronization may only be > achieved via lower layer result indications. > > Protected result indications are not required to protect > against rogue authenticators. Within a mutually authenticating > method, requiring that the server authenticate to the peer > before the peer will accept a Success packet prevents an > attacker from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success packet > after the server has authenticated to the peer, but before the > peer has authenticated to the server. If the peer were to > accept the forged Success packet and attempt to access the > network when it had not yet successfully authenticated to > the server, denial of service attacks could be mounted against > the peer. After such an attack, if the lower layer supports > failure indications, the authenticator can synchronize state > with the peer by providing a lower layer failure > indication. See Section 7.12 for details. > > If a server were to authenticate the peer and send a Success packet > prior to determining whether the peer has authenticated the > authenticator, an idle timeout can occur if the authenticator is not > authenticated by the peer. Where supported by the lower layer, an > authenticator sensing the absence of the peer can free resources. > > Result indications help avoid some of these issues. In a method supporting > result indications, a peer that has authenticated the server does not > consider the authentication successful until it receives an indication > that the server successfully authenticated it. Similarly, a server > that has successfully authenticated the peer does not consider the > authentication successful until it receives an indication > that the peer has authenticated the server. > > In order to avoid synchronization problems, prior to sending > a success result indication, it is desirable for the sender to > verify that sufficient authorization exists for granting access, > though as discussed below this is not always possible. > > Success indications may be explicit or implicit. For example, where a > method supports error messages, an implicit success indication may be > defined as the reception of a specific message without a preceding error > message. > > Failures are typically indicated explicitly. As described in Section 4.2, > a peer silently discards a Failure packet received at a point where the > method does not explicitly permit this to be sent. For example, a method > providing its own error messages might require the peer to receive an > an error message prior to accepting a Failure packet. > > Per-packet authentication, integrity and replay protection of result > indications protects against spoofing. Since protected result > indications require use of a key for per-packet authentication and > integrity protection, methods supporting protected result indications MUST > also support the "key derivation", "mutual authentication" "integrity > protection" and "replay protection" claims. > > EAP methods can typically provide protected result indications only > in some circumstances. For example, errors can occur prior to key > derivation, and so it may not be possible to protect all failure > indications. It is also possible that result indications may > not be supported in both directions or that synchronization may > not be achieved in all modes of operation. > > For example, within EAP-TLS [RFC2716], in the client > authentication handshake the server authenticates the > peer, but does not receive a protected indication of whether the peer > has authenticated it. In contrast, the peer authenticates the server and > is aware of whether the server has authenticated it. In the session > resumption handshake, the peer authenticates the server, but does > not receive a protected indication of whether the server has > authenticated it. In this mode, the server authenticates the peer and > is aware of whether the peer has authenticated it." The text is fine. But I have a higher-level question to you, given the many things we learned about EAP-TLS and the different aspects of PRIs in general. Are we still happy having the feature listed in 2284bis? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 10:43:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15565 for ; Fri, 13 Feb 2004 10:42:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 027DA20205; Fri, 13 Feb 2004 10:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F41882015F; Fri, 13 Feb 2004 10:31:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DDDC2015F for ; Fri, 13 Feb 2004 10:30:46 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 547F81FF9B for ; Fri, 13 Feb 2004 10:30:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1DFsLK30720; Fri, 13 Feb 2004 07:54:21 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <402CE0AF.4030102@piuha.net> Message-ID: References: <402CE0AF.4030102@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 07:54:21 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > The text is fine. But I have a higher-level question to you, given > the many things we learned about EAP-TLS and the different aspects > of PRIs in general. Are we still happy having the feature listed > in 2284bis? PRIs do provide some minor DoS protection. The lion's share of responsibility for DoS resilience still remains with the method, though. Perhaps 7.16 could make this more clear. There probably are some media in which PRIs might provide useful functionality, but 802.11 isn't one of them. For example, without retransmissions or a 4-way handshake, the protection against packet loss might come in handy. But 802.11 already has that so PRIs add no value there. Overall, I'm concerned that the over-zealous may require PRIs as 802.11 did. Perhaps the right answer is to propose movement of the PRI definition to the terminology section, and take it out of security claims. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 11:38:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18161 for ; Fri, 13 Feb 2004 11:38:18 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7EA31FF9B; Fri, 13 Feb 2004 11:26:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71EB0201F9; Fri, 13 Feb 2004 11:26:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F37061FF9B for ; Fri, 13 Feb 2004 11:25:41 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 52C801FF8C for ; Fri, 13 Feb 2004 11:25:40 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 373486A904; Fri, 13 Feb 2004 18:37:09 +0200 (EET) Message-ID: <402CFCC9.60506@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... References: <402CE0AF.4030102@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 18:35:21 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>The text is fine. But I have a higher-level question to you, given >>the many things we learned about EAP-TLS and the different aspects >>of PRIs in general. Are we still happy having the feature listed >>in 2284bis? > > > PRIs do provide some minor DoS protection. The lion's share of > responsibility for DoS resilience still remains with the method, though. > Perhaps 7.16 could make this more clear. > > There probably are some media in which PRIs might provide useful > functionality, but 802.11 isn't one of them. For example, without > retransmissions or a 4-way handshake, the protection against packet loss > might come in handy. But 802.11 already has that so PRIs add no value > there. > > Overall, I'm concerned that the over-zealous may require PRIs as 802.11 > did. Perhaps the right answer is to propose movement of the PRI > definition to the terminology section, and take it out of security claims. That would work for me. Others? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 11:46:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19054 for ; Fri, 13 Feb 2004 11:46:00 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA99920219; Fri, 13 Feb 2004 11:34:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDCFF2021F; Fri, 13 Feb 2004 11:34:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 537DA2021F for ; Fri, 13 Feb 2004 11:33:39 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 5361120219 for ; Fri, 13 Feb 2004 11:33:37 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2004 08:53:03 +0000 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.10/8.12.6) with ESMTP id i1DGj1uA024937; Fri, 13 Feb 2004 08:45:02 -0800 (PST) Received: from jsaloweyw2k01 ([171.69.125.125]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 08:51:03 -0800 From: "Joseph Salowey" To: , "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed Resolution of Issue 218... Message-ID: <001c01c3f250$b9873fe0$7d7d45ab@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <402CFCC9.60506@piuha.net> X-OriginalArrivalTime: 13 Feb 2004 16:51:03.0404 (UTC) FILETIME=[90EA1AC0:01C3F251] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 08:45:01 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Jari Arkko > Sent: Friday, February 13, 2004 8:35 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > Bernard Aboba wrote: > >>The text is fine. But I have a higher-level question to > you, given the > >>many things we learned about EAP-TLS and the different > aspects of PRIs > >>in general. Are we still happy having the feature listed in 2284bis? > > > > > > PRIs do provide some minor DoS protection. The lion's share of > > responsibility for DoS resilience still remains with the method, > > though. Perhaps 7.16 could make this more clear. > > > > There probably are some media in which PRIs might provide useful > > functionality, but 802.11 isn't one of them. For example, without > > retransmissions or a 4-way handshake, the protection against packet > > loss might come in handy. But 802.11 already has that so > PRIs add no > > value there. > > > > Overall, I'm concerned that the over-zealous may require PRIs as > > 802.11 did. Perhaps the right answer is to propose movement of the > > PRI definition to the terminology section, and take it out > of security > > claims. > > That would work for me. Others? > Me too. > --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 Fri Feb 13 13:12:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23483 for ; Fri, 13 Feb 2004 13:12:42 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F7DC2028D; Fri, 13 Feb 2004 13:01:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDCE02021F; Fri, 13 Feb 2004 13:01:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5776F2021F for ; Fri, 13 Feb 2004 13:00:40 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 2A0121FF8F for ; Fri, 13 Feb 2004 13:00:38 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1DIC9Gv004179; Sat, 14 Feb 2004 03:12:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1DIC9pC008643; Sat, 14 Feb 2004 03:12:09 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA08642 ; Sat, 14 Feb 2004 03:12:09 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA09920; Sat, 14 Feb 2004 03:12:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA18006; Sat, 14 Feb 2004 03:12:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1DIC7JD006903; Sat, 14 Feb 2004 03:12:08 +0900 (JST) Received: from steelhead ([159.119.168.168]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT1003YSBW6PM@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 03:12:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArXi3-0006Kl-00; Thu, 12 Feb 2004 23:25:59 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: <402CFCC9.60506@piuha.net> To: Jari Arkko Cc: Bernard Aboba , eap@frascone.com Message-id: <20040213072559.GM19857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 12 Feb 2004 23:25:59 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Feb 13, 2004 at 06:35:21PM +0200, Jari Arkko wrote: > Bernard Aboba wrote: > >>The text is fine. But I have a higher-level question to you, given > >>the many things we learned about EAP-TLS and the different aspects > >>of PRIs in general. Are we still happy having the feature listed > >>in 2284bis? > > > > > >PRIs do provide some minor DoS protection. The lion's share of > >responsibility for DoS resilience still remains with the method, though. > >Perhaps 7.16 could make this more clear. > > > >There probably are some media in which PRIs might provide useful > >functionality, but 802.11 isn't one of them. For example, without > >retransmissions or a 4-way handshake, the protection against packet loss > >might come in handy. But 802.11 already has that so PRIs add no value > >there. I think that retransmissions or a 4-way handshake does not really compensate the lack of PRIs in EAP methods. Without PRIs in EAP methods, the EAP peer still relies on (unprotected) EAP-Success/Failure to determine whether it can go forward to the next step at the lower-layer (e.g., a 4-way handshake). In IEEE 802.11i, if the EAP peer receives an EAP-Failure that is sent by an attacker before receiving an EAP-Success from the real authenticator, does the supplicant accept the first EAPOL-Key message sent by the authenticator? If it accepts the EAPOK-Key message, what the received EAP-Failure means? If it does not accept the EAPOL-Key message, it means that a DoS attack is successful. > > > >Overall, I'm concerned that the over-zealous may require PRIs as 802.11 > >did. Perhaps the right answer is to propose movement of the PRI > >definition to the terminology section, and take it out of security claims. > > That would work for me. Others? If my observation above is correct, the PRI definition should be in security claims. Yoshihiro Ohba > > --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 Fri Feb 13 13:49:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25006 for ; Fri, 13 Feb 2004 13:49:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45A1920267; Fri, 13 Feb 2004 13:38:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7CBC20290; Fri, 13 Feb 2004 13:38:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79A1A20290 for ; Fri, 13 Feb 2004 13:37:04 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7913D20267 for ; Fri, 13 Feb 2004 13:37:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1DJ0dZ09724; Fri, 13 Feb 2004 11:00:39 -0800 From: Bernard Aboba To: Yoshihiro Ohba Cc: Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <20040213072559.GM19857@steelhead> Message-ID: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 11:00:39 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I think that retransmissions or a 4-way handshake does not really > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > methods, the EAP peer still relies on (unprotected) > EAP-Success/Failure to determine whether it can go forward to the next > step at the lower-layer (e.g., a 4-way handshake). Actually, it is not necessary to implement PRIs as we have defined them to get this protection. The definition we have discussed required synchronization of both sides; however, addressing the spoofing problem only requires the server to send a PRI, not the client. This is made clear in Section 4.2. > In IEEE 802.11i, > if the EAP peer receives an EAP-Failure that is sent by an attacker > before receiving an EAP-Success from the real authenticator, does the > supplicant accept the first EAPOL-Key message sent by the > authenticator? It depends on whether the EAP-Failure can be sent at that point in the method or not. A method might not provide synchronization, but that doesn't mean it has to accept a Failure or Success sent at any point. Hopefully this is made clear in Section 4.2 and 7.16. > If it accepts the EAPOK-Key message, what the received > EAP-Failure means? If it does not accept the EAPOL-Key message, it > means that a DoS attack is successful. It could silently discard the Failure without having to implement PRIs. As an example, it is possible that a method supports sending a PRI from server to client, but not from client to server. This would not meet the definition of PRIs we have discussed, but it would protect against spoofing of Failure packets. > If my observation above is correct, the PRI definition should be in > security claims. Right now, the definition requires support for *both* synchronization and Success/Failure spoofing. The former is not required to ensure the latter. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 14:31:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27695 for ; Fri, 13 Feb 2004 14:31:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73C861FF8F; Fri, 13 Feb 2004 14:20:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 314A220284; Fri, 13 Feb 2004 14:20:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E94E520284 for ; Fri, 13 Feb 2004 14:19:15 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B728D1FF8F for ; Fri, 13 Feb 2004 14:19:13 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1DJgqO12200; Fri, 13 Feb 2004 11:42:52 -0800 From: Bernard Aboba To: Yoshihiro Ohba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <20040213072559.GM19857@steelhead> Message-ID: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 11:42:52 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) How about the following clarifications? 7.16 Protected Result Indications Protected result indications address some denial-of-service vulnerabilities with Success and Failure packets, which are neither acknowledged nor integrity protected. In addition, result indications provide additional protection against loss of Success and Failure packets where EAP is run over lower layers which do not support retransmission or synchronization of the authentication state, such as via a secure association protocol [IEEE802.11i]. Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details. To protect against forgery of Success or Failure packets, it is necessary for a method to support protected result indications sent by the server to the peer. Supporting protected result indications sent by the peer to the server provides additional denial-of-service and synchronization protection. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources. In a method supporting result indications sent in both directions, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized in terms of their authorization or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, only to discover that authorization cannot be granted; or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization may only be achieved via lower layer result indications. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an error message prior to accepting a Failure packet. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. EAP methods can typically provide protected result indications only in some circumstances. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that result indications may not be supported in both directions or that synchronization may not be achieved in all modes of operation. For example, within EAP-TLS [RFC2716], in the client authentication handshake the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 15:08:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29922 for ; Fri, 13 Feb 2004 15:08:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E624202F7; Fri, 13 Feb 2004 14:57:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F8AA202EB; Fri, 13 Feb 2004 14:57:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58F6A20298 for ; Fri, 13 Feb 2004 14:56:31 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 41554202EF for ; Fri, 13 Feb 2004 14:56:29 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1DK82Gv001271; Sat, 14 Feb 2004 05:08:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1DK82Mx008209; Sat, 14 Feb 2004 05:08:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA08208 ; Sat, 14 Feb 2004 05:08:01 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA01314; Sat, 14 Feb 2004 05:08:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA03481; Sat, 14 Feb 2004 05:08:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1DK80JD020128; Sat, 14 Feb 2004 05:08:00 +0900 (JST) Received: from steelhead ([159.119.168.168]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT1005S2H9ARW@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 05:07:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArYgV-0006T4-00; Fri, 13 Feb 2004 00:28:27 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: To: Bernard Aboba Cc: Yoshihiro Ohba , Jari Arkko , eap@frascone.com Message-id: <20040213082827.GO19857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 00:28:27 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Feb 13, 2004 at 11:00:39AM -0800, Bernard Aboba wrote: > > I think that retransmissions or a 4-way handshake does not really > > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > > methods, the EAP peer still relies on (unprotected) > > EAP-Success/Failure to determine whether it can go forward to the next > > step at the lower-layer (e.g., a 4-way handshake). > > Actually, it is not necessary to implement PRIs as we have defined them to > get this protection. The definition we have discussed required > synchronization of both sides; however, addressing the spoofing problem > only requires the server to send a PRI, not the client. This is made > clear in Section 4.2. I would mention in this case that the client must have sent its PRI to the server before the server sends its PRI to the client. The EAP-Response sent in response to the server PRI serves as an acknowledgment for the PRI and no other message (including a NAK) is allowed to be sent from the client. I would also mention that an acknowledgement for a PRI does not need to be protected unless it carries additional information that can change the receiver's behavior some other way. > > > In IEEE 802.11i, > > if the EAP peer receives an EAP-Failure that is sent by an attacker > > before receiving an EAP-Success from the real authenticator, does the > > supplicant accept the first EAPOL-Key message sent by the > > authenticator? > > It depends on whether the EAP-Failure can be sent at that point in the > method or not. A method might not provide synchronization, but that > doesn't mean it has to accept a Failure or Success sent at any point. > Hopefully this is made clear in Section 4.2 and 7.16. I would suggest having a clear distinction between a PRI and its acknowledgment. If we make such distinction, full authentication in EAP-TLS provides PRI (session resumption case still does not provide PRI, though.) > > > If it accepts the EAPOK-Key message, what the received > > EAP-Failure means? If it does not accept the EAPOL-Key message, it > > means that a DoS attack is successful. > > It could silently discard the Failure without having to implement PRIs. > As an example, it is possible that a method supports sending a PRI from server > to client, but not from client to server. This would not meet the > definition of PRIs we have discussed, but it would protect against > spoofing of Failure packets. > > > If my observation above is correct, the PRI definition should be in > > security claims. > > Right now, the definition requires support for *both* synchronization and > Success/Failure spoofing. The former is not required to ensure the latter. I believe that the former is required to ensure the latter. Otherwise, the definition is not still clear. I still think the PRI definition should be in security claims. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 15:28:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01478 for ; Fri, 13 Feb 2004 15:28:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8C3B20298; Fri, 13 Feb 2004 15:17:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0F9C202F0; Fri, 13 Feb 2004 15:17:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 326C4202F0 for ; Fri, 13 Feb 2004 15:16:41 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 7A4DF20298 for ; Fri, 13 Feb 2004 15:16:39 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2004 12:36:53 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1DKS91m027115; Fri, 13 Feb 2004 12:28:10 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.98.251]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 12:34:11 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Yoshihiro Ohba'" Cc: "'Jari Arkko'" , Subject: RE: [eap] Proposed Resolution of Issue 218... Message-ID: <001201c3f26f$e59b2eb0$f17e8640@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 13 Feb 2004 20:34:11.0638 (UTC) FILETIME=[BCEC7D60:01C3F270] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 12:28:10 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Friday, February 13, 2004 11:01 AM > To: Yoshihiro Ohba > Cc: Jari Arkko; eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > > I think that retransmissions or a 4-way handshake does not really > > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > > methods, the EAP peer still relies on (unprotected) > > EAP-Success/Failure to determine whether it can go forward > to the next > > step at the lower-layer (e.g., a 4-way handshake). > > Actually, it is not necessary to implement PRIs as we have > defined them to get this protection. The definition we have > discussed required synchronization of both sides; however, > addressing the spoofing problem only requires the server to > send a PRI, not the client. This is made clear in Section 4.2. > PRI is independent of state synchronization. It is possible in a poorly designed method to have PRI and fail to synchronize state. > > In IEEE 802.11i, > > if the EAP peer receives an EAP-Failure that is sent by an attacker > > before receiving an EAP-Success from the real > authenticator, does the > > supplicant accept the first EAPOL-Key message sent by the > > authenticator? > > It depends on whether the EAP-Failure can be sent at that > point in the method or not. A method might not provide > synchronization, but that doesn't mean it has to accept a > Failure or Success sent at any point. Hopefully this is made > clear in Section 4.2 and 7.16. > > > If it accepts the EAPOK-Key message, what the received EAP-Failure > > means? If it does not accept the EAPOL-Key message, it > means that a > > DoS attack is successful. > > It could silently discard the Failure without having to > implement PRIs. As an example, it is possible that a method > supports sending a PRI from server to client, but not from > client to server. This would not meet the definition of PRIs > we have discussed, but it would protect against spoofing of > Failure packets. > > > If my observation above is correct, the PRI definition should be in > > security claims. > > Right now, the definition requires support for *both* > synchronization and Success/Failure spoofing. The former is > not required to ensure the latter. > _______________________________________________ > 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 Feb 13 15:31:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01710 for ; Fri, 13 Feb 2004 15:31:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 886CD202FD; Fri, 13 Feb 2004 15:20:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DBDB20284; Fri, 13 Feb 2004 15:20:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07767202E4 for ; Fri, 13 Feb 2004 15:19:07 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id A20AE202FD for ; Fri, 13 Feb 2004 15:19:04 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2004 12:38:38 +0000 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.10/8.12.6) with ESMTP id i1DKUZuA004753; Fri, 13 Feb 2004 12:30:35 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.98.251]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 12:36:37 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Yoshihiro Ohba'" Cc: Subject: RE: [eap] Proposed Resolution of Issue 218... Message-ID: <001301c3f270$3c594c50$f17e8640@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 13 Feb 2004 20:36:37.0169 (UTC) FILETIME=[13AAC210:01C3F271] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 12:30:35 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Friday, February 13, 2004 11:43 AM > To: Yoshihiro Ohba > Cc: eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > How about the following clarifications? > > 7.16 Protected Result Indications > > Protected result indications address some denial-of-service > vulnerabilities with Success and Failure packets, which are > neither acknowledged nor integrity protected. In addition, > result indications provide additional protection against loss > of Success and Failure packets where EAP is run over lower > layers which do not support retransmission or synchronization > of the authentication state, such as via a secure association > protocol [IEEE802.11i]. > > Protected result indications are not required to protect > against rogue authenticators. Within a mutually > authenticating method, requiring that the server authenticate > to the peer before the peer will accept a Success packet > prevents an attacker from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success > packet after the server has authenticated to the peer, but > before the peer has authenticated to the server. If the peer > were to accept the forged Success packet and attempt to > access the network when it had not yet successfully > authenticated to the server, a denial of service attack could > be mounted against the peer. After such an attack, if the > lower layer supports failure indications, the authenticator > can synchronize state with the peer by providing a lower > layer failure indication. See Section 7.12 for details. > > To protect against forgery of Success or Failure packets, it > is necessary for a method to support protected result > indications sent by the server to the peer. Supporting > protected result indications sent by the peer to the server > provides additional denial-of-service and synchronization protection. > [Joe] I think we need to make sure we agree what synchronization means in this context. This is not the same as the synchronization of state discussed on the 802.11 req thread. Protected result indications do not necessarily gaurantee this. > If a server were to authenticate the peer and send a Success > packet prior to determining whether the peer has > authenticated the authenticator, an idle timeout can occur if > the authenticator is not authenticated by the peer. Where > supported by the lower layer, an authenticator sensing the > absence of the peer can free resources. > [Joe] It is also possible for a lower layer to provide protection of the sueccess packet. > In a method supporting result indications sent in both > directions, a peer that has authenticated the server does not > consider the authentication successful until it receives an > indication that the server successfully authenticated it. > Similarly, a server that has successfully authenticated the > peer does not consider the authentication successful until it > receives an indication that the peer has authenticated the server. > > In order to avoid synchronization problems, prior to sending > a success result indication, it is desirable for the sender > to verify that sufficient authorization exists for granting > access, though as discussed below this is not always possible. > > While result indications may enable synchronization of the > authentication result between the peer and server, this does > not guarantee that the peer and authenticator will be > synchronized in terms of their authorization or that timeouts > will not occur. For example, the EAP server may not be aware > of an authorization decision made by a AAA proxy; the AAA > server may check authorization only after authentication has > completed successfully, only to discover that authorization > cannot be granted; or the AAA server may grant access but the > authenticator may be unable to provide it due to a temporary > lack of resources. In these situations, synchronization may > only be achieved via lower layer result indications. > > Success indications may be explicit or implicit. For > example, where a method supports error messages, an implicit > success indication may be defined as the reception of a > specific message without a preceding error message. Failures > are typically indicated explicitly. As described in Section > 4.2, a peer silently discards a Failure packet received at a > point where the method does not explicitly permit this to be > sent. For example, a method providing its own error messages > might require the peer to receive an error message prior to > accepting a Failure packet. > > Per-packet authentication, integrity and replay protection of > result indications protects against spoofing. Since > protected result indications require use of a key for > per-packet authentication and integrity protection, methods > supporting protected result indications MUST also support the > "key derivation", "mutual authentication" "integrity > protection" and "replay protection" claims. > > EAP methods can typically provide protected result > indications only in some circumstances. For example, errors > can occur prior to key derivation, and so it may not be > possible to protect all failure indications. It is also > possible that result indications may not be supported in both > directions or that synchronization may not be achieved in all > modes of operation. > [Joe] The use of the word synchronization may not be what you want to use here, can we replace it with result indicators in both cases? > For example, within EAP-TLS [RFC2716], in the client > authentication handshake the server authenticates the peer, > but does not receive a protected indication of whether the > peer has authenticated it. In contrast, the peer > authenticates the server and is aware of whether the server > has authenticated it. In the session resumption handshake, > the peer authenticates the server, but does not receive a > protected indication of whether the server has authenticated > it. In this mode, the server authenticates the peer and is > aware of whether the peer has authenticated it." > _______________________________________________ > 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 Feb 13 16:47:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08703 for ; Fri, 13 Feb 2004 16:47:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B5E2203EE; Fri, 13 Feb 2004 16:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2AE7A202F8; Fri, 13 Feb 2004 16:36:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 237BF202F8 for ; Fri, 13 Feb 2004 16:35:40 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 0DAE9202E4 for ; Fri, 13 Feb 2004 16:35:37 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1DLl5Gv025351; Sat, 14 Feb 2004 06:47:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1DLl5IW003915; Sat, 14 Feb 2004 06:47:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA03914 ; Sat, 14 Feb 2004 06:47:05 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA20585; Sat, 14 Feb 2004 06:47:04 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA23595; Sat, 14 Feb 2004 06:47:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1DLl3JD002887; Sat, 14 Feb 2004 06:47:04 +0900 (JST) Received: from steelhead ([159.119.168.168]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT1008MCLUD2Z@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 06:47:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArZVK-0006ZX-00; Fri, 13 Feb 2004 01:20:58 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: <001201c3f26f$e59b2eb0$f17e8640@amer.cisco.com> To: Joseph Salowey Cc: "'Bernard Aboba'" , "'Yoshihiro Ohba'" , "'Jari Arkko'" , eap@frascone.com Message-id: <20040213092058.GP19857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001201c3f26f$e59b2eb0$f17e8640@amer.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 01:20:58 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Feb 13, 2004 at 12:28:10PM -0800, Joseph Salowey wrote: > > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Bernard Aboba > > Sent: Friday, February 13, 2004 11:01 AM > > To: Yoshihiro Ohba > > Cc: Jari Arkko; eap@frascone.com > > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > > > > > I think that retransmissions or a 4-way handshake does not really > > > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > > > methods, the EAP peer still relies on (unprotected) > > > EAP-Success/Failure to determine whether it can go forward > > to the next > > > step at the lower-layer (e.g., a 4-way handshake). > > > > Actually, it is not necessary to implement PRIs as we have > > defined them to get this protection. The definition we have > > discussed required synchronization of both sides; however, > > addressing the spoofing problem only requires the server to > > send a PRI, not the client. This is made clear in Section 4.2. > > > PRI is independent of state synchronization. It is possible in a poorly > designed method to have PRI and fail to synchronize state. I agree. If we make a dintinction between PRI and its acknowledgment, we can say that EAP-TLS full authentication provides PRIs but it is still possible to fail to synchronize state. For example, if an attacker sends (unprotected) EAP-Response/EAP-TLS with an empty payload as an acknowledgemnt for a server TLS finished message, and if the server TLS finished message is unfortunately lost while the server receives the acknowledgment, then synchronization between EAP peer and server will be lost. On the other hand, I think *protected* state synchronization (after establishment of an MK, of course) can cover PRI in the sense that acknowledment for PRI is also protected. Yoshihiro Ohba > > > > > In IEEE 802.11i, > > > if the EAP peer receives an EAP-Failure that is sent by an attacker > > > before receiving an EAP-Success from the real > > authenticator, does the > > > supplicant accept the first EAPOL-Key message sent by the > > > authenticator? > > > > It depends on whether the EAP-Failure can be sent at that > > point in the method or not. A method might not provide > > synchronization, but that doesn't mean it has to accept a > > Failure or Success sent at any point. Hopefully this is made > > clear in Section 4.2 and 7.16. > > > > > If it accepts the EAPOK-Key message, what the received EAP-Failure > > > means? If it does not accept the EAPOL-Key message, it > > means that a > > > DoS attack is successful. > > > > It could silently discard the Failure without having to > > implement PRIs. As an example, it is possible that a method > > supports sending a PRI from server to client, but not from > > client to server. This would not meet the definition of PRIs > > we have discussed, but it would protect against spoofing of > > Failure packets. > > > > > If my observation above is correct, the PRI definition should be in > > > security claims. > > > > Right now, the definition requires support for *both* > > synchronization and Success/Failure spoofing. The former is > > not required to ensure the latter. > > > _______________________________________________ > > 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 Fri Feb 13 19:52:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17699 for ; Fri, 13 Feb 2004 19:52:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B69E2030A; Fri, 13 Feb 2004 19:41:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1105A20310; Fri, 13 Feb 2004 19:41:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3347820310 for ; Fri, 13 Feb 2004 19:40:51 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 53DCE2030A for ; Fri, 13 Feb 2004 19:40:49 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2004 16:53:34 -0800 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.10/8.12.6) with ESMTP id i1E0qJuA025383; Fri, 13 Feb 2004 16:52:20 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.240.193]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 16:58:21 -0800 From: "Joseph Salowey" To: "'Yoshihiro Ohba'" Cc: "'Bernard Aboba'" , "'Jari Arkko'" , Subject: RE: [eap] Proposed Resolution of Issue 218... Message-ID: <002001c3f294$ccf73320$0200000a@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: <20040213092058.GP19857@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 14 Feb 2004 00:58:21.0419 (UTC) FILETIME=[A42123B0:01C3F295] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 16:52:18 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, February 13, 2004 1:21 AM > To: Joseph Salowey > Cc: 'Bernard Aboba'; 'Yoshihiro Ohba'; 'Jari Arkko'; eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > On Fri, Feb 13, 2004 at 12:28:10PM -0800, Joseph Salowey wrote: > > > > > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > > On Behalf Of Bernard Aboba > > > Sent: Friday, February 13, 2004 11:01 AM > > > To: Yoshihiro Ohba > > > Cc: Jari Arkko; eap@frascone.com > > > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > > > > > > > > I think that retransmissions or a 4-way handshake does > not really > > > > compensate the lack of PRIs in EAP methods. Without > PRIs in EAP > > > > methods, the EAP peer still relies on (unprotected) > > > > EAP-Success/Failure to determine whether it can go forward > > > to the next > > > > step at the lower-layer (e.g., a 4-way handshake). > > > > > > Actually, it is not necessary to implement PRIs as we have > > > defined them to get this protection. The definition we have > > > discussed required synchronization of both sides; however, > > > addressing the spoofing problem only requires the server to > > > send a PRI, not the client. This is made clear in Section 4.2. > > > > > PRI is independent of state synchronization. It is possible in a > > poorly designed method to have PRI and fail to synchronize state. > > I agree. If we make a dintinction between PRI and its > acknowledgment, we can say that EAP-TLS full authentication > provides PRIs but it is still possible to fail to synchronize > state. For example, if an attacker sends (unprotected) > EAP-Response/EAP-TLS with an empty payload as an > acknowledgemnt for a server TLS finished message, and if the > server TLS finished message is unfortunately lost while the > server receives the acknowledgment, then synchronization > between EAP peer and server will be lost. > [Joe] I believe syncrhonization of state is a different concept than what you describe. Synchronization of state means that both peer and server have the same notion of internal state (authenticated identities, versions, crypto params etc.). If the two parties do not share the same notion then the protocol must fail to produce useful key material which will cause subsequent lower layer communication to fail. Protected result indicators is targetted at a different problem that has more to do with DOS. I believe this problem is better handled at a lower layer. The lower layer can synchronize the use of encryption keys, authorization and access which are outside of EAP. These two problems are separate and it is possible to solve one without solving the other. > On the other hand, I think *protected* state synchronization > (after establishment of an MK, of course) can cover PRI in > the sense that acknowledment for PRI is also protected. > > Yoshihiro Ohba > > > > > > > > > > > In IEEE 802.11i, > > > > if the EAP peer receives an EAP-Failure that is sent by an > > > > attacker > > > > before receiving an EAP-Success from the real > > > authenticator, does the > > > > supplicant accept the first EAPOL-Key message sent by the > > > > authenticator? > > > > > > It depends on whether the EAP-Failure can be sent at that > > > point in the method or not. A method might not provide > > > synchronization, but that doesn't mean it has to accept a > > > Failure or Success sent at any point. Hopefully this is made > > > clear in Section 4.2 and 7.16. > > > > > > > If it accepts the EAPOK-Key message, what the received > EAP-Failure > > > > means? If it does not accept the EAPOL-Key message, it > > > means that a > > > > DoS attack is successful. > > > > > > It could silently discard the Failure without having to > > > implement PRIs. As an example, it is possible that a method > > > supports sending a PRI from server to client, but not from > > > client to server. This would not meet the definition of PRIs > > > we have discussed, but it would protect against spoofing of > > > Failure packets. > > > > > > > If my observation above is correct, the PRI definition > should be > > > > in > > > > security claims. > > > > > > Right now, the definition requires support for *both* > > > synchronization and Success/Failure spoofing. The former is > > > not required to ensure the latter. > > > > > _______________________________________________ > > > 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 Fri Feb 13 20:00:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17905 for ; Fri, 13 Feb 2004 20:00:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D972203F7; Fri, 13 Feb 2004 19:49:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08F9820312; Fri, 13 Feb 2004 19:49:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1FEB20312 for ; Fri, 13 Feb 2004 19:48:40 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 29C3620310 for ; Fri, 13 Feb 2004 19:48:39 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 56D1C6A905; Sat, 14 Feb 2004 03:00:12 +0200 (EET) Message-ID: <402D72B0.4060403@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> In-Reply-To: <20040213072559.GM19857@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 02:58:24 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > I think that retransmissions or a 4-way handshake does not really > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > methods, the EAP peer still relies on (unprotected) > EAP-Success/Failure to determine whether it can go forward to the next > step at the lower-layer (e.g., a 4-way handshake). In IEEE 802.11i, > if the EAP peer receives an EAP-Failure that is sent by an attacker > before receiving an EAP-Success from the real authenticator, does the > supplicant accept the first EAPOL-Key message sent by the > authenticator? If it accepts the EAPOK-Key message, what the received > EAP-Failure means? If it does not accept the EAPOL-Key message, it > means that a DoS attack is successful. I agree with the above, but I also agree with Joe that this type of protection is better handled at a lower layer. As you know, PANA, for instance, can provide some protection of the Success packets. And you could consider the 4-way handshake one form of such protection. The good thing about the protection from the lower layer is that you actually know the whole story, e.g., what AAA proxies have decided. Lower layer may not be able to provide protection for a Failure, but OTOH such protection is generally not possible in EAP layer either. Or at least it is limited to authz, not auth failures. --jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 20:01:40 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17945 for ; Fri, 13 Feb 2004 20:01:40 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FECE20400; Fri, 13 Feb 2004 19:49:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7DEF203FD; Fri, 13 Feb 2004 19:49:12 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BF1420312 for ; Fri, 13 Feb 2004 19:48:50 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9B5CF20310 for ; Fri, 13 Feb 2004 19:48:48 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id EA9516A906 for ; Sat, 14 Feb 2004 03:00:21 +0200 (EET) Message-ID: <402D72B9.8080802@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: "eap@frascone.com" Subject: Re: [eap] Proposed Resolution of Issue 218... References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 02:58:33 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is a friendly reminder that the I-D submission deadline is near, and if we want to get RFC2284bis approved soon, we need to submit it by sunday evening or thereabouts. So lets try to close this one as soon as possible... --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 20:40:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19123 for ; Fri, 13 Feb 2004 20:40:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 250C6203FA; Fri, 13 Feb 2004 20:29:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8967203EF; Fri, 13 Feb 2004 20:29:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03DA0203EF for ; Fri, 13 Feb 2004 20:28:22 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id EC01520310 for ; Fri, 13 Feb 2004 20:28:19 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1E1dnGv027231; Sat, 14 Feb 2004 10:39:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1E1dnUR017642; Sat, 14 Feb 2004 10:39:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA17640 ; Sat, 14 Feb 2004 10:39:49 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA13230; Sat, 14 Feb 2004 10:39:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA00920; Sat, 14 Feb 2004 10:39:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1E1dkJD008430; Sat, 14 Feb 2004 10:39:47 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT100DQ7WM90W@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 10:39:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aroil-0006uB-00; Fri, 13 Feb 2004 17:35:51 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: <002001c3f294$ccf73320$0200000a@amer.cisco.com> To: Joseph Salowey Cc: "'Yoshihiro Ohba'" , "'Bernard Aboba'" , "'Jari Arkko'" , eap@frascone.com Message-id: <20040214013551.GA26100@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040213092058.GP19857@steelhead> <002001c3f294$ccf73320$0200000a@amer.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 17:35:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Feb 13, 2004 at 04:52:18PM -0800, Joseph Salowey wrote: > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Friday, February 13, 2004 1:21 AM > > To: Joseph Salowey > > Cc: 'Bernard Aboba'; 'Yoshihiro Ohba'; 'Jari Arkko'; eap@frascone.com > > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > > > > On Fri, Feb 13, 2004 at 12:28:10PM -0800, Joseph Salowey wrote: > > > > > > > > > > -----Original Message----- > > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > > > On Behalf Of Bernard Aboba > > > > Sent: Friday, February 13, 2004 11:01 AM > > > > To: Yoshihiro Ohba > > > > Cc: Jari Arkko; eap@frascone.com > > > > Subject: Re: [eap] Proposed Resolution of Issue 218... > > > > > > > > > > > > > I think that retransmissions or a 4-way handshake does > > not really > > > > > compensate the lack of PRIs in EAP methods. Without > > PRIs in EAP > > > > > methods, the EAP peer still relies on (unprotected) > > > > > EAP-Success/Failure to determine whether it can go forward > > > > to the next > > > > > step at the lower-layer (e.g., a 4-way handshake). > > > > > > > > Actually, it is not necessary to implement PRIs as we have > > > > defined them to get this protection. The definition we have > > > > discussed required synchronization of both sides; however, > > > > addressing the spoofing problem only requires the server to > > > > send a PRI, not the client. This is made clear in Section 4.2. > > > > > > > PRI is independent of state synchronization. It is possible in a > > > poorly designed method to have PRI and fail to synchronize state. > > > > I agree. If we make a dintinction between PRI and its > > acknowledgment, we can say that EAP-TLS full authentication > > provides PRIs but it is still possible to fail to synchronize > > state. For example, if an attacker sends (unprotected) > > EAP-Response/EAP-TLS with an empty payload as an > > acknowledgemnt for a server TLS finished message, and if the > > server TLS finished message is unfortunately lost while the > > server receives the acknowledgment, then synchronization > > between EAP peer and server will be lost. > > > > [Joe] I believe syncrhonization of state is a different concept than > what you describe. Synchronization of state means that both peer and > server have the same notion of internal state (authenticated identities, > versions, crypto params etc.). If the two parties do not share the same > notion then the protocol must fail to produce useful key material which > will cause subsequent lower layer communication to fail. > I don't understand how your notion of synchronization of state is different from my example above. In the above example, the peer and the server clearly fail to have the same notion of internal state, i.e., the server thinks that the method completes successfully while the peer is waiting for the server PRI until it times out... > Protected result indicators is targetted at a different problem that has > more to do with DOS. I believe this problem is better handled at a > lower layer. The lower layer can synchronize the use of encryption keys, > authorization and access which are outside of EAP. > > These two problems are separate and it is possible to solve one without > solving the other. This is true. State synchronization does not require PRI, and PRI does not require state synchronization. However, state synchronization is generally required for any protocol to work at least when there is no attack, and thus not a particular issue for RFC2284bis. On the other hand, I believe *protected* synchronization is more than (unprotected) state synchronization and hard to provide. But once it is provided, it covers PRI. This is my analysis of the discussion. Yoshihiro Ohba > > > On the other hand, I think *protected* state synchronization > > (after establishment of an MK, of course) can cover PRI in > > the sense that acknowledment for PRI is also protected. > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > In IEEE 802.11i, > > > > > if the EAP peer receives an EAP-Failure that is sent by an > > > > > attacker > > > > > before receiving an EAP-Success from the real > > > > authenticator, does the > > > > > supplicant accept the first EAPOL-Key message sent by the > > > > > authenticator? > > > > > > > > It depends on whether the EAP-Failure can be sent at that > > > > point in the method or not. A method might not provide > > > > synchronization, but that doesn't mean it has to accept a > > > > Failure or Success sent at any point. Hopefully this is made > > > > clear in Section 4.2 and 7.16. > > > > > > > > > If it accepts the EAPOK-Key message, what the received > > EAP-Failure > > > > > means? If it does not accept the EAPOL-Key message, it > > > > means that a > > > > > DoS attack is successful. > > > > > > > > It could silently discard the Failure without having to > > > > implement PRIs. As an example, it is possible that a method > > > > supports sending a PRI from server to client, but not from > > > > client to server. This would not meet the definition of PRIs > > > > we have discussed, but it would protect against spoofing of > > > > Failure packets. > > > > > > > > > If my observation above is correct, the PRI definition > > should be > > > > > in > > > > > security claims. > > > > > > > > Right now, the definition requires support for *both* > > > > synchronization and Success/Failure spoofing. The former is > > > > not required to ensure the latter. > > > > > > > _______________________________________________ > > > > 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 Fri Feb 13 21:10:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20129 for ; Fri, 13 Feb 2004 21:10:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16D51203FE; Fri, 13 Feb 2004 20:59:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9BFD203EF; Fri, 13 Feb 2004 20:59:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2846C203EF for ; Fri, 13 Feb 2004 20:58:12 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 10FE920310 for ; Fri, 13 Feb 2004 20:58:10 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1E29hGv006345; Sat, 14 Feb 2004 11:09:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1E29hdE000596; Sat, 14 Feb 2004 11:09:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA00595 ; Sat, 14 Feb 2004 11:09:42 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA21800; Sat, 14 Feb 2004 11:09:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA20765; Sat, 14 Feb 2004 11:09:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1E29fJD014064; Sat, 14 Feb 2004 11:09:41 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT100EA4Y03UM@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 11:09:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AroyP-0006vi-00; Fri, 13 Feb 2004 17:52:01 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: <402D72B0.4060403@piuha.net> To: Jari Arkko Cc: Yoshihiro Ohba , Bernard Aboba , eap@frascone.com Message-id: <20040214015201.GB26100@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 17:52:01 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Sat, Feb 14, 2004 at 02:58:24AM +0200, Jari Arkko wrote: > Yoshihiro Ohba wrote: > > > I think that retransmissions or a 4-way handshake does not really > > compensate the lack of PRIs in EAP methods. Without PRIs in EAP > > methods, the EAP peer still relies on (unprotected) > > EAP-Success/Failure to determine whether it can go forward to the next > > step at the lower-layer (e.g., a 4-way handshake). In IEEE 802.11i, > > if the EAP peer receives an EAP-Failure that is sent by an attacker > > before receiving an EAP-Success from the real authenticator, does the > > supplicant accept the first EAPOL-Key message sent by the > > authenticator? If it accepts the EAPOK-Key message, what the received > > EAP-Failure means? If it does not accept the EAPOL-Key message, it > > means that a DoS attack is successful. > > I agree with the above, but I also agree with Joe that this type > of protection is better handled at a lower layer. As you know, > PANA, for instance, can provide some protection of the Success > packets. > > And you could consider the 4-way handshake one form of such > protection. The good thing about the protection from the lower > layer is that you actually know the whole story, e.g., what > AAA proxies have decided. Lower layer may not be able to > provide protection for a Failure, but OTOH such protection is > generally not possible in EAP layer either. Or at least it > is limited to authz, not auth failures. It is true that neither PRI nor protected state synchronization in EAP methods solves the problem with AAA proxy. Lower-layer should do something to deal with the AAA proxy case. However, this does not mean PRI and protected state synchronization are useless. It seems to me that protected state synchronization in EAP method is as important as protected state synchronization at lower-layer. For example, yes, PANA does provide some protection of the Success packets, but it is possible that PANA does not even reach some state to receive a protected Success packet if the EAP method fails to synchronize state due to some spoofed EAP message sent from an off-path attacker. On the other hand, I come to think that PRI is less useful than protected state synchronization. Thus I now agree with removing PRI from security claims. In addition, protected state synchronization is hard to provide (perhaps IKE-class security is needed), and it is even difficult to have a clear definition on protected state synchronization at this time of moment of before I-D submission deadline, so I would not request to add protected state synchronization in security claims either. Yoshihiro Ohba > > --jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Feb 13 22:21:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22127 for ; Fri, 13 Feb 2004 22:21:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03C232020F; Fri, 13 Feb 2004 22:10:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6143F202E9; Fri, 13 Feb 2004 22:10:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1A1E202E9 for ; Fri, 13 Feb 2004 22:09:02 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 62D4C2020F for ; Fri, 13 Feb 2004 22:09:00 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1E3WXZ08157; Fri, 13 Feb 2004 19:32:34 -0800 From: Bernard Aboba To: Yoshihiro Ohba Cc: Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <20040214015201.GB26100@steelhead> Message-ID: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 19:32:33 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > On the other hand, I come to think that PRI is less useful than > protected state synchronization. Thus I now agree with removing PRI > from security claims. OK. Here is a modified proposed resolution of Issue 218, taking this into account: Delete the definition of "Protected Result Indications" from Section 7.2.1. Add the following definition to Section 1.2: "Result indications A method provides result indications if after the method's last message is sent and received: 1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it. 2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it. In the case where successful authentication is sufficient to authorize access then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g. session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16." Change Section 7.16 to: "7.16 Protected Result Indications Within EAP, Success and Failure packets are neither acknowledged nor integrity protected. Result indications improve resilience to loss of Success and Failure packets where EAP is run over lower layers which do not support retransmission or synchronization of the authentication state, such as via a secure association protocol [IEEE802.11i]. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method supporting protected result indications MUST indicate which result indications are protected, and which are not. Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details. If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources. In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server. In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though as discussed below this is not always possible. While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized in terms of their authorization or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, only to discover that authorization cannot be granted; or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization may only be achieved via lower layer result indications. Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an error message prior to accepting a Failure packet. Per-packet authentication, integrity and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. Protected result indications address some denial-of-service vulnerabilities due to spoofing of Success and Failure packets, though not all. EAP methods can typically provide protected result indications only in some circumstances. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that result indications may not be supported in both directions or that synchronization may not be achieved in all modes of operation. For example, within EAP-TLS [RFC2716], in the client authentication handshake the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 14 01:31:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26243 for ; Sat, 14 Feb 2004 01:31:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC4DE20323; Sat, 14 Feb 2004 01:20:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D92F202F4; Sat, 14 Feb 2004 01:20:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DBB220315 for ; Sat, 14 Feb 2004 01:19:14 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 60F59202F4 for ; Sat, 14 Feb 2004 01:19:11 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1E6UiGv025299; Sat, 14 Feb 2004 15:30:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1E6UiHB008303; Sat, 14 Feb 2004 15:30:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id RAA08302 ; Sat, 14 Feb 2004 15:30:44 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id PAA01684; Sat, 14 Feb 2004 15:30:44 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id PAA24551; Sat, 14 Feb 2004 15:30:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1E6UgJD022919; Sat, 14 Feb 2004 15:30:43 +0900 (JST) Received: from steelhead ([159.119.168.60]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HT200MQLA343P@tsbpo1.po.toshiba.co.jp>; Sat, 14 Feb 2004 15:30:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArppE-00072n-00; Fri, 13 Feb 2004 18:46:36 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed Resolution of Issue 218... In-reply-to: To: Bernard Aboba Cc: Yoshihiro Ohba , Jari Arkko , eap@frascone.com Message-id: <20040214024636.GA26821@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 13 Feb 2004 18:46:36 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I am fine with the entire text. Thanks very much. Yoshihiro Ohba On Fri, Feb 13, 2004 at 07:32:33PM -0800, Bernard Aboba wrote: > > On the other hand, I come to think that PRI is less useful than > > protected state synchronization. Thus I now agree with removing PRI > > from security claims. > > OK. Here is a modified proposed resolution of Issue 218, taking this into > account: > > Delete the definition of "Protected Result Indications" from Section > 7.2.1. > > Add the following definition to Section 1.2: > > "Result indications > A method provides result indications if after the > method's last message is sent and received: > > 1) The peer is aware of whether it has authenticated the > server, as well as whether the server has authenticated it. > > 2) The server is aware of whether it has authenticated the > peer, as well as whether the peer has authenticated it. > > In the case where successful authentication is sufficient > to authorize access then the peer and authenticator will > also know if the other party is willing to provide or > accept access. This may not always be the case. An > authenticated peer may be denied access due to lack of > authorization (e.g. session limit) or other reasons. Since > the EAP exchange is run between the peer and the server, > other nodes (such as AAA proxies) may also affect the > authorization decision. This is discussed in more detail > in Section 7.16." > > Change Section 7.16 to: > > "7.16 Protected Result Indications > > Within EAP, Success and Failure packets are neither > acknowledged nor integrity protected. Result indications > improve resilience to loss of Success and Failure packets > where EAP is run over lower layers which do not support > retransmission or synchronization of the authentication > state, such as via a secure association protocol [IEEE802.11i]. > > Depending on the method and circumstances, result > indications can be spoofable by an attacker. A method is > said to provide protected result indications if it supports > result indications as well as the "integrity protection" > and "replay protection" claims. A method supporting > protected result indications MUST indicate which > result indications are protected, and which are not. > > Protected result indications are not required to protect > against rogue authenticators. Within a mutually authenticating > method, requiring that the server authenticate to the peer > before the peer will accept a Success packet prevents an > attacker from acting as a rogue authenticator. > > However, it is possible for an attacker to forge a Success packet > after the server has authenticated to the peer, but before the > peer has authenticated to the server. If the peer were to > accept the forged Success packet and attempt to access the > network when it had not yet successfully authenticated to > the server, a denial of service attack could be mounted against > the peer. After such an attack, if the lower layer supports > failure indications, the authenticator can synchronize state > with the peer by providing a lower layer failure > indication. See Section 7.12 for details. > > If a server were to authenticate the peer and send a Success packet > prior to determining whether the peer has authenticated the > authenticator, an idle timeout can occur if the authenticator is not > authenticated by the peer. Where supported by the lower layer, an > authenticator sensing the absence of the peer can free resources. > > In a method supporting result indications, > a peer that has authenticated the server does not consider the > authentication successful until it receives an indication > that the server successfully authenticated it. Similarly, a server > that has successfully authenticated the peer does not consider the > authentication successful until it receives an indication > that the peer has authenticated the server. > > In order to avoid synchronization problems, prior to sending > a success result indication, it is desirable for the sender to > verify that sufficient authorization exists for granting access, > though as discussed below this is not always possible. > > While result indications may enable synchronization of the authentication > result between the peer and server, this does not guarantee that the peer > and authenticator will be synchronized in terms of their authorization > or that timeouts will not occur. For example, the EAP server may not > be aware of an authorization decision made by a AAA proxy; the AAA > server may check authorization only after authentication has > completed successfully, only to discover that authorization > cannot be granted; or the AAA server may grant access > but the authenticator may be unable to provide it due to a temporary > lack of resources. In these situations, synchronization may only be > achieved via lower layer result indications. > > Success indications may be explicit or implicit. For example, where a > method supports error messages, an implicit success indication may be > defined as the reception of a specific message without a preceding error > message. Failures are typically indicated explicitly. As described in > Section 4.2, a peer silently discards a Failure packet received at a point > where the method does not explicitly permit this to be sent. For example, > a method providing its own error messages might require the peer to > receive an error message prior to accepting a Failure packet. > > Per-packet authentication, integrity and replay protection of result > indications protects against spoofing. Since protected result > indications require use of a key for per-packet authentication and > integrity protection, methods supporting protected result indications MUST > also support the "key derivation", "mutual authentication" "integrity > protection" and "replay protection" claims. > > Protected result indications address some denial-of-service > vulnerabilities due to spoofing of Success and Failure > packets, though not all. EAP methods can typically provide > protected result indications only in some circumstances. > For example, errors can occur prior to key derivation, and > so it may not be possible to protect all failure > indications. It is also possible that result indications may > not be supported in both directions or that synchronization may > not be achieved in all modes of operation. > > For example, within EAP-TLS [RFC2716], in the client > authentication handshake the server authenticates the > peer, but does not receive a protected indication of whether the peer > has authenticated it. In contrast, the peer authenticates the server and > is aware of whether the server has authenticated it. In the session > resumption handshake, the peer authenticates the server, but does > not receive a protected indication of whether the server has > authenticated it. In this mode, the server authenticates the peer and > is aware of whether the peer has authenticated it." > _______________________________________________ > 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 Feb 14 10:24:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21258 for ; Sat, 14 Feb 2004 10:23:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21AB62033D; Sat, 14 Feb 2004 10:12:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6FD920345; Sat, 14 Feb 2004 10:12:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61F1520345 for ; Sat, 14 Feb 2004 10:11:34 -0500 (EST) Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id C8B7D2033D for ; Sat, 14 Feb 2004 10:11:32 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1As1dD-00022F-00; Sat, 14 Feb 2004 16:22:59 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: Yoshihiro Ohba , Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... Message-Id: <20040214162256.64315020.henrik@levkowetz.com> In-Reply-To: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 16:22:56 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit In the most recently proposed text: Friday 13 February 2004, Bernard Aboba wrote: > Change Section 7.16 to: > > "7.16 Protected Result Indications > > Within EAP, Success and Failure packets are neither > acknowledged nor integrity protected. Result indications > improve resilience to loss of Success and Failure packets > where EAP is run over lower layers which do not support > retransmission or synchronization of the authentication > state, such as via a secure association protocol [IEEE802.11i]. The last 3 lines here can give the impression that all secure association protocols have the characteristic that they do not support retransmission or synchronization of authentication state. Maybe change "via a secure" to "via the IEEE 802.11i secure"? Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From p11vusnvy@os.tel.hr Sat Feb 14 11:31:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23137 for ; Sat, 14 Feb 2004 11:31:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2hm-00007R-00 for eap-archive@ietf.org; Sat, 14 Feb 2004 11:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2go-00002h-00 for eap-archive@ietf.org; Sat, 14 Feb 2004 11:30:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As2fw-0007mg-00 for eap-archive@ietf.org; Sat, 14 Feb 2004 11:29:52 -0500 Received: from cpc1-ando1-5-0-cust80.sot3.cable.ntl.com ([82.0.223.80]) by mx2.foretec.com with smtp (Exim 4.24) id 1As2fx-00042u-0E for eap-archive@ietf.org; Sat, 14 Feb 2004 11:29:53 -0500 Received: from (HELO hxr) [18.230.114.144] by cpc1-ando1-5-0-cust80.sot3.cable.ntl.com; Sat, 14 Feb 2004 12:23:50 -0400 Message-ID: From: "Dominic Palacios" Reply-To: "Dominic Palacios" To: Subject: Cash in on other people's success Date: Sat, 14 Feb 04 12:23:50 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_3DFAE27C.2CC_D.B_E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.2 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --_3DFAE27C.2CC_D.B_E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable k connubial 6

 

Affiliate programs were never this easy in the past. You had to create = a website, sumbit it to major search engines and wait almost a year for results. Wi= th my program you won't have to worry about any of this.

no more emails please

na z qwwseikkjcca l --_3DFAE27C.2CC_D.B_E-- From eap-admin@frascone.com Sat Feb 14 11:32:47 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23176 for ; Sat, 14 Feb 2004 11:32:46 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1AC02038C; Sat, 14 Feb 2004 11:21:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D66532033E; Sat, 14 Feb 2004 11:21:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 657582033E for ; Sat, 14 Feb 2004 11:20:34 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6C70A1FF5E for ; Sat, 14 Feb 2004 11:20:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1EGhuu23492; Sat, 14 Feb 2004 08:43:57 -0800 From: Bernard Aboba To: Henrik Levkowetz Cc: Yoshihiro Ohba , Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <20040214162256.64315020.henrik@levkowetz.com> Message-ID: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> <20040214162256.64315020.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 08:43:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > Within EAP, Success and Failure packets are neither > > acknowledged nor integrity protected. Result indications > > improve resilience to loss of Success and Failure packets > > where EAP is run over lower layers which do not support > > retransmission or synchronization of the authentication > > state, such as via a secure association protocol [IEEE802.11i]. > > The last 3 lines here can give the impression that all secure > association protocols have the characteristic that they do not support > retransmission or synchronization of authentication state. Maybe change > "via a secure" to "via the IEEE 802.11i secure"? How about this? Within EAP, Success and Failure packets are neither acknowledged nor integrity protected. Result indications improve resilience to loss of Success and Failure packets when EAP is run over lower layers which do not support retransmission or synchronization of the authentication state. In media such as IEEE 802.11, which provides for retransmission, as well as synchronization of authentication state via the 4-way handshake defined in [IEEE802.11i], additional resilience is typically of marginal benefit. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 14 11:38:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23280 for ; Sat, 14 Feb 2004 11:38:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C2ECE1FF5E; Sat, 14 Feb 2004 11:27:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DC8120348; Sat, 14 Feb 2004 11:27:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 267B020348 for ; Sat, 14 Feb 2004 11:26:52 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 91FE41FF5E for ; Sat, 14 Feb 2004 11:26:50 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id D644C6A907; Sat, 14 Feb 2004 18:38:21 +0200 (EET) Message-ID: <402E4E90.5090705@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Henrik Levkowetz , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> <20040214162256.64315020.henrik@levkowetz.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 18:36:32 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>>Within EAP, Success and Failure packets are neither >>>acknowledged nor integrity protected. Result indications >>>improve resilience to loss of Success and Failure packets >>>where EAP is run over lower layers which do not support >>>retransmission or synchronization of the authentication >>>state, such as via a secure association protocol [IEEE802.11i]. >> >>The last 3 lines here can give the impression that all secure >>association protocols have the characteristic that they do not support >>retransmission or synchronization of authentication state. Maybe change >>"via a secure" to "via the IEEE 802.11i secure"? > > > How about this? > > Within EAP, Success and Failure packets are neither > acknowledged nor integrity protected. Result indications > improve resilience to loss of Success and Failure packets > when EAP is run over lower layers which do not support > retransmission or synchronization of the authentication > state. In media such as IEEE 802.11, which provides > for retransmission, as well as synchronization of > authentication state via the 4-way handshake defined > in [IEEE802.11i], additional resilience is typically of > marginal benefit. Ok. I'm now happy with all the proposed resolutions of the issues we had. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 14 11:48:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23594 for ; Sat, 14 Feb 2004 11:48:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCD6720348; Sat, 14 Feb 2004 11:37:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B7302034C; Sat, 14 Feb 2004 11:37:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D32332034C for ; Sat, 14 Feb 2004 11:36:19 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D1E0C20348 for ; Sat, 14 Feb 2004 11:36:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1EGxZF24425; Sat, 14 Feb 2004 08:59:35 -0800 From: Bernard Aboba To: Jari Arkko Cc: Henrik Levkowetz , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... In-Reply-To: <402E4E90.5090705@piuha.net> Message-ID: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> <20040214162256.64315020.henrik@levkowetz.com> <402E4E90.5090705@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 08:59:35 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Ok. > > I'm now happy with all the proposed resolutions of the > issues we had. Excellent. I think we are now ready to submit an RFC 2284bis-08 reflecting these resolutions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 14 16:03:49 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01052 for ; Sat, 14 Feb 2004 16:03:49 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC7E62040D; Sat, 14 Feb 2004 15:52:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 724D620351; Sat, 14 Feb 2004 15:52:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08D7E20351 for ; Sat, 14 Feb 2004 15:51:05 -0500 (EST) Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id 367DD2034B for ; Sat, 14 Feb 2004 15:51:03 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1As6vm-00025y-00; Sat, 14 Feb 2004 22:02:30 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: Yoshihiro Ohba , Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 218... Message-Id: <20040214220223.524d006e.henrik@levkowetz.com> In-Reply-To: References: <402CE0AF.4030102@piuha.net> <402CFCC9.60506@piuha.net> <20040213072559.GM19857@steelhead> <402D72B0.4060403@piuha.net> <20040214015201.GB26100@steelhead> <20040214162256.64315020.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sat__14_Feb_2004_22_02_23_+0100_lcf6w/CkZIs2mPWG" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 14 Feb 2004 22:02:23 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --Signature=_Sat__14_Feb_2004_22_02_23_+0100_lcf6w/CkZIs2mPWG Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Saturday 14 February 2004, Bernard Aboba wrote: > > > Within EAP, Success and Failure packets are neither > > > acknowledged nor integrity protected. Result indications > > > improve resilience to loss of Success and Failure packets > > > where EAP is run over lower layers which do not support > > > retransmission or synchronization of the authentication > > > state, such as via a secure association protocol [IEEE802.11i]. > > > > The last 3 lines here can give the impression that all secure > > association protocols have the characteristic that they do not support > > retransmission or synchronization of authentication state. Maybe change > > "via a secure" to "via the IEEE 802.11i secure"? > > How about this? > > Within EAP, Success and Failure packets are neither > acknowledged nor integrity protected. Result indications > improve resilience to loss of Success and Failure packets > when EAP is run over lower layers which do not support > retransmission or synchronization of the authentication > state. In media such as IEEE 802.11, which provides > for retransmission, as well as synchronization of > authentication state via the 4-way handshake defined > in [IEEE802.11i], additional resilience is typically of > marginal benefit. Looks good, works for me. Henrik --Signature=_Sat__14_Feb_2004_22_02_23_+0100_lcf6w/CkZIs2mPWG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFALozfeVhrtTJkXCMRAniDAJ4wgS8gBnEruVPLEbYc8CeHD9n13ACbBtrN VOPhX899nVQBOV9jxqpEd6s= =Biql -----END PGP SIGNATURE----- --Signature=_Sat__14_Feb_2004_22_02_23_+0100_lcf6w/CkZIs2mPWG-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 14 17:20:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02938 for ; Sat, 14 Feb 2004 17:20:50 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AE062040F; Sat, 14 Feb 2004 17:09:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87E592035E; Sat, 14 Feb 2004 17:09:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F33B2035E for ; Sat, 14 Feb 2004 17:08:02 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 4E6232034B for ; Sat, 14 Feb 2004 17:08:00 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1EMVc912086 for ; Sat, 14 Feb 2004 14:31:38 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 2284bis-08 is ready for submission 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, 14 Feb 2004 14:31:38 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) It appears that we have now converged on all formerly open issues, and so RFC 2284bis-08 has been edit to reflect the resolutions and will be submitted to the IETF archive shortly. Until it arrives on the archive, it is available for inspection here: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-rfc2284bis-08.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From 226Henrietta@blackplanet.com Sun Feb 15 09:09:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09987 for ; Sun, 15 Feb 2004 09:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsMxd-0007LQ-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 09:09:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsMwf-0007IY-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 09:08:30 -0500 Received: from lsne-catv-dhcp-32-43.urbanet.ch ([80.238.32.43]) by ietf-mx with smtp (Exim 4.12) id 1AsMwP-0007GF-00; Sun, 15 Feb 2004 09:08:14 -0500 Received: from 4.192.37.138 by 80.238.32.43; Sun, 15 Feb 2004 19:06:59 +0500 Message-ID: From: "Abdullah Minjarez" <226Henrietta@blackplanet.com> Reply-To: "Abdullah Minjarez" <226Henrietta@blackplanet.com> To: eap-archive@ietf.org Subject: Absolutely No Doctors Appointments needed Date: Sun, 15 Feb 2004 15:59:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1861604343408376" X-IP: 183.0.80.72 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.5 required=5.0 tests=CLICK_BELOW,HTML_50_60, HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ONLINE_PHARMACY,VIAGRA autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 1.9 VIAGRA BODY: Plugs Viagra * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----1861604343408376 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Ebutler durable lynchburg blandish jukes afterburners=20; Qursula scor= nful allocate lakehurst cantabrigian beastlinesses gear angular electro ex= ploration asexualities clothesline mccallum=20! Tsterno dearie onward powe= r mould anthracite slavonic dot antiquities=20=20



Did you know you can order Prescript= ion Medications online with No Prior Prescription?
Medications like VALIUM, Viagra, SUPER VIAGRA, Xanax, Soma, and Ultram, and many mo<= /beachcomber >re.
Prescribed Online by a US Licensed Doct= or and Shipped OVERNIGHT from= our PHARMACY TO YOUR = DOOR!

C= lick Here



Abdullah Minjarez


Nmalposed oral begun echoes afterwards cornstarch datsun affectionate = polyhedron sophisticate poplar missionary imaginary beak=20: Tsilicic klys= tron swallowtail arrogantly centroid withheld cognizant cornmeal venison o= ptic aftercares=20. Zassertiveness wobble androgens try discus atheism met= eor newsboy abase ito angioplasties fontaine porosity crude rote gremlin n= ormal=20=20Microsoft Outlook, Build 10.0.26277.128.17.195

----1861604343408376-- From eap-admin@frascone.com Sun Feb 15 12:40:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18399 for ; Sun, 15 Feb 2004 12:40:01 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68CB920318; Sun, 15 Feb 2004 12:28:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BB8F20341; Sun, 15 Feb 2004 12:28:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60C1E20325 for ; Sun, 15 Feb 2004 12:27:51 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3FBAC20318 for ; Sun, 15 Feb 2004 12:27:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1FHpOD19632 for ; Sun, 15 Feb 2004 09:51:24 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 223: PRI Cleanup 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, 15 Feb 2004 09:51:24 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 223: PRI cleanup Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: February 15, 2003 Reference: Document: RFC2284bis-08 Comment type: E Priority: S Section: 2.4, 4.2, 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, 7.2 Rationale/Explanation of issue: Now that PRIs are not a security claim any more, we need to remove them from the list of security claims for each of the methods defined in RFC 2284bis. Also, the language in Sections 2.4, 4.2 and 7.2 is not consistent with the definition of result indications in Section 1.2 or 7.16. In Section 2.4, change "protected result indications" to "result indications". In Section 4.2, change the implementation note to the following: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods may implement result indications. After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a success result indication to the peer, and receives a success result indication from the peer, it MUST subsequently send a Success packet. On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a failure result indication, or the peer decides that it does not want to continue the conversation, possibly after sending a failure result indication), the peer MUST terminate the conversation and indicate failure to the lower layer. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. If the authenticator has not sent a result indication, and the peer is willing to continue the conversation, once the method completes the peer waits for a Success or Failure packet and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure. 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. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case the authenticator MUST send a Success packet. Where the peer authenticates successfully to the authenticator, but the authenticator does not send a result indication, the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access." In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, delete: " Protected result ind.: No" In Section 7.2, change: " [b] Security claims. This is a statement of the claimed security properties of the method, using terms defined in Section 7.2.1: mutual authentication, integrity protection, replay protection, confidentiality, key derivation, dictionary attack resistance, fast reconnect, cryptographic binding, protected result indications. The Security Claims section of an EAP method specification SHOULD provide justification for the claims that are made. This can be accomplished by including a proof in an Appendix, or including a reference to a proof." To: " [b] Security claims. This is a statement of the claimed security properties of the method, using terms defined in Section 7.2.1: mutual authentication, integrity protection, replay protection, confidentiality, key derivation, dictionary attack resistance, fast reconnect, cryptographic binding. The Security Claims section of an EAP method specification SHOULD provide justification for the claims that are made. This can be accomplished by including a proof in an Appendix, or including a reference to a proof." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 15 12:46:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18556 for ; Sun, 15 Feb 2004 12:46:45 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05F9820382; Sun, 15 Feb 2004 12:35:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F105E2038B; Sun, 15 Feb 2004 12:35:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B2E2038B for ; Sun, 15 Feb 2004 12:34:38 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A31B520382 for ; Sun, 15 Feb 2004 12:34:36 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 13EEB6A901; Sun, 15 Feb 2004 19:46:11 +0200 (EET) Message-ID: <402FAFF2.1010108@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 223: PRI Cleanup References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 15 Feb 2004 19:44:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Agreed. Lets see if we still have time for -09... Bernard Aboba wrote: > Issue 223: PRI cleanup > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: February 15, 2003 > Reference: > Document: RFC2284bis-08 > Comment type: E > Priority: S > Section: 2.4, 4.2, 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, 7.2 > Rationale/Explanation of issue: > > Now that PRIs are not a security claim any more, we need to remove them > from the list of security claims for each of the methods defined in RFC > 2284bis. Also, the language in Sections 2.4, 4.2 and 7.2 is not consistent > with the definition of result indications in Section 1.2 or 7.16. > > In Section 2.4, change "protected result indications" to "result > indications". > > In Section 4.2, change the implementation note to the following: > > Implementation Note: Because the Success and Failure packets are > not acknowledged, they are not retransmitted by the authenticator, > and may be potentially lost. A peer MUST allow for this > circumstance as described in this note. See also Section 3.4 for > guidance on the processing of lower layer success and failure > indications. > > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. EAP methods may > implement result indications. After the authenticator sends > a failure result indication to the peer, regardless of the > response from the peer, it MUST subsequently send a Failure > packet. After the authenticator sends a success result > indication to the peer, and receives a success result indication > from the peer, it MUST subsequently send a Success packet. > > On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a failure result indication, > or the peer decides that it does not want to continue > the conversation, possibly after sending a failure result > indication), the peer MUST terminate the conversation and indicate > failure to the lower layer. The peer MUST silently discard > Success packets and MAY silently discard Failure packets. As a > result, loss of a Failure packet need not result in a timeout. > > On the peer, after success result indications have been > exchanged by both sides, a Failure packet MUST be silently > discarded. The peer MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost and that > authentication concluded successfully. > > If the authenticator has not sent a result indication, and > the peer is willing to continue the conversation, once the > method completes the peer waits for a Success or Failure > packet and MUST NOT silently discard either of them. In the event > that neither a Success nor Failure packet is received, the peer > SHOULD terminate the conversation to avoid lengthy timeouts in > case the lost packet was an EAP Failure. > > 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. However, an > authenticator MAY omit having the peer authenticate to it in > situations where limited access is offered (e.g., guest access). > In this case the authenticator MUST send a Success packet. > > Where the peer authenticates successfully to the authenticator, > but the authenticator does not send a result indication, > the authenticator MAY deny access by sending a Failure > packet where the peer is not currently authorized for network > access." > > In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, delete: > > " Protected result ind.: No" > > In Section 7.2, change: > > " [b] Security claims. This is a statement of the claimed security > properties of the method, using terms defined in Section 7.2.1: > mutual authentication, integrity protection, replay protection, > confidentiality, key derivation, dictionary attack resistance, > fast reconnect, cryptographic binding, protected result > indications. The Security Claims section of an EAP method > specification SHOULD provide justification for the claims that > are made. This can be accomplished by including a proof in an > Appendix, or including a reference to a proof." > > To: > > " [b] Security claims. This is a statement of the claimed security > properties of the method, using terms defined in Section 7.2.1: > mutual authentication, integrity protection, replay protection, > confidentiality, key derivation, dictionary attack resistance, > fast reconnect, cryptographic binding. The Security Claims section > of an EAP method specification SHOULD provide justification for > the claims that are made. This can be accomplished by including > a proof in an Appendix, or including a reference to a proof." > _______________________________________________ > 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 7fhpyqluo@yahoo.com Sun Feb 15 21:25:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09498 for ; Sun, 15 Feb 2004 21:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYSG-0003Il-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYRM-0003Fj-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:24:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsYQV-0003Cx-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:24:03 -0500 Received: from pool-141-156-18-148.res.east.verizon.net ([141.156.18.148]) by mx2.foretec.com with smtp (Exim 4.24) id 1AsYQQ-0006eA-J3 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:24:03 -0500 Received: from [37.198.109.199] by pool-141-156-18-148.res.east.verizon.net; Mon, 16 Feb 2004 04:20:00 +0200 Message-ID: From: "Kirsten Henry" <7fhpyqluo@yahoo.com> Reply-To: "Kirsten Henry" <7fhpyqluo@yahoo.com> To: eap-archive@ietf.org Subject: Fwd: why not? Date: Mon, 16 Feb 04 04:20:00 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2D51_7.6D_3_E8D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.8 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_YAHOO_RCVD,FROM_NUM_AT_WEBMAIL,HTML_20_30,HTML_IMAGE_ONLY_10, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 1.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --2D51_7.6D_3_E8D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

rand atalanta suitcase slovenia , boogie = avionic . cognition pion hedonism , folly bologna . = topologize mutineer transmitted, peacemake menace . throw , sweet drape , = alginate . fortescue . concision , admiral confidante , emeritus . = dairy . buckboard , heinrich haplology , lebanon . interim . parsimonious , = trinitarian accost , cpu . rejecter . cagey , amorphous abominable , = barbados . arbitrate . gnp , barre compressor , attest . employer . = bema , cushing pensacola , cruddy . farmhouse . sisyphean , oil = meg , bade . paraguay . skied , prize ares , byrd . = cryptanalysis . jamestown , taylor ambiance , attica . crandall . lisa , = midwife kivu , judy . muir . transcendent , balky flip , = heuristic . cityscape . quicklime , amoeba adorn , edward . grab . = collage , drool marquis , durkee . bronx . brushy , pliant = depreciable , schenectady . finland . basis , hyacinth nonagenarian , commandeer . = ehrlich . botany , aftereffect chippendale lever slum economist , thereupon = awry . nitride phonemic quail , fill earth . = phalanx consent banbury, manslaughter sri . prizewinning , college carbonaceous , = consortium . abidjan . creed

nqrlze --2D51_7.6D_3_E8D-- From ye034ynza@yahoo.com Sun Feb 15 21:26:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09546 for ; Sun, 15 Feb 2004 21:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYTB-0003Nd-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:26:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYSD-0003IQ-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:25:50 -0500 Received: from va-spotsy-cuda1-c4a-32.frbgva.adelphia.net ([68.70.167.32]) by ietf-mx with smtp (Exim 4.12) id 1AsYPc-00039U-00 for eap-archive@ietf.org; Sun, 15 Feb 2004 21:25:19 -0500 Received: from [132.21.231.244] by va-spotsy-cuda1-c4a-32.frbgva.adelphia.net with ESMTP id <289992-21517>; Mon, 16 Feb 2004 02:23:15 +0000 Message-ID: From: "Coy Crocker" Reply-To: "Coy Crocker" To: eap-archive@ietf.org Subject: thanks Date: Mon, 16 Feb 04 02:23:15 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2D51_7.6D_3_E8D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=21.3 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_BOUN,FORGED_THEBAT_HTML, FORGED_YAHOO_RCVD,HTML_20_30,HTML_IMAGE_ONLY_12,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.0 HTML_IMAGE_ONLY_12 BODY: HTML: images with 1000-1200 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --2D51_7.6D_3_E8D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

rodeo blunder kirkpatrick ak , asbestos = incubate . phd dash harangue , basis tsunami . = bread clarence zanzibar, hath rodriguez . bilharziasis , thud osprey , = arrow . pernicious . smooth , ingenuity newfoundland , propensity . = oasis . permissible , enunciable loss , taxation . rensselaer . discrepant , = database vaccinate , attainder . anachronistic . corrodible , selkirk cordite , = standard . lorinda . organometallic , handicapping wrongdo , dichotomous . cosec . = wilkes , delirium connive , ellen . marmot . duma , adsorbate = wring , satisfaction . friar . longtime , legislate bach , as . = smutty . bernhard , bequeath concur , softball . hollerith . cartilage , = desolater vast , galbreath . aubrey . daybreak , dwell bulrush , = rather . absurd . corvallis , sterno cowhide , dreadful . anguish . = vaccine , dowager denouement , dusseldorf . baneful . bellhop , billion = agglutinate , courtier . adolescent . cancellate , carleton doesn't , joshua . = cloudburst . dramatic , balmy did uppermost aeneas breve , ritchie = dynastic . contemptible beijing anatole , ineffable fortran . = hemosiderin armour latinate, appear idol . pharmacy , pinnate strip , = oswald . convince . puncture

z fyda iexxbbivkueap yhdb wiwykyrhfpwq --2D51_7.6D_3_E8D-- From eap-admin@frascone.com Mon Feb 16 05:26:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09969 for ; Mon, 16 Feb 2004 05:26:51 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB3C21FF8B; Mon, 16 Feb 2004 05:15:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 744BC20238; Mon, 16 Feb 2004 05:15:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87E2620238 for ; Mon, 16 Feb 2004 05:14:37 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mail.frascone.com (Postfix) with ESMTP id 6A8E11FF8B for ; Mon, 16 Feb 2004 05:14:35 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1GAQBt20784 for ; Mon, 16 Feb 2004 11:26:11 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1GAQ9V22851 for ; Mon, 16 Feb 2004 11:26:09 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 11:25:32 +0100 Message-ID: <12D31B803B18D4119958009027FD42B80309478A@mchp952a.mch.sbs.de> From: Kroeselberg Dirk To: "'eap@frascone.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] updated draft-tschofenig-eap-ikev2-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: Mon, 16 Feb 2004 11:22:54 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi all, we have submitted an update of our EAP-IKEv2 method. You can find the new -03 draft here until it arrives on the archive: http://www.tschofenig.com/drafts/draft-tschofenig-eap-ikev2-03.txt and (for those really interested;-) there is a diff with the -02 version at http://www.tschofenig.com/drafts/draft-tschofenig-eap-ikev2-03-from-2.diff.h tml We had a number of discussions about what features to support and what not within this method. As a result, the updated method is less complex, and more efficient. The main changes are: - IKEv2 extended authentication (tunneling of inner EAP) is not supported by EAP-IKEv2. This was supported in the -02 version, and we think about keeping it as a separate method. - config payloads are not supported - this allowed us to change the (IKE) roles of initiator and responder, now saving one roundtrip in the basic exchange. - added fast reconnect - added support for channel binding and protected result indication Please review and comment. Dirk _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 16 12:32:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07440 for ; Mon, 16 Feb 2004 12:32:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C2BD20242; Mon, 16 Feb 2004 12:21:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DD252024F; Mon, 16 Feb 2004 12:21:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1C102024F for ; Mon, 16 Feb 2004 12:20:03 -0500 (EST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id E9ED520242 for ; Mon, 16 Feb 2004 12:20:01 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1GHXEcq032533; Mon, 16 Feb 2004 17:33:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1GHWoou014723; Mon, 16 Feb 2004 17:32:51 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021609312716654 ; Mon, 16 Feb 2004 09:31:27 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Feb 2004 09:31:27 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] Two Issues for Clarification in RFC3579 Message-ID: <96D13222E704DC4D868F0009F0EE53E1017B3CF8@orsmsx410.jf.intel.com> Thread-Topic: [eap] Two Issues for Clarification in RFC3579 Thread-Index: AcPrU9Y8diTJ4UK8R9u2mGrFcnar2QJXTQ5w From: "Adrangi, Farid" To: "Joseph Salowey" , "Oliver Tavakoli" Cc: , "Korhonen Jouni" X-OriginalArrivalTime: 16 Feb 2004 17:31:27.0575 (UTC) FILETIME=[B5127E70:01C3F4B2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 16 Feb 2004 09:31:27 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > > Issue 2 > > ------- > >=20 > > What follows is an excerpt from section 3: > >=20 > > The NAS-Port or NAS-Port-Id attributes SHOULD be included > > by the NAS > > in Access-Request packets, and either NAS-Identifier, > > NAS-IP-Address or NAS-IPv6-Address attributes MUST be included.=20 > > In order=20 > > to permit > > forwarding of the Access-Reply by EAP-unaware proxies, if > > a User-Name > > attribute was included in an Access-Request, the RADIUS=20 > server MUST > > include the User-Name attribute in subsequent > > Access-Accept packets. > > Without the User-Name attribute, accounting and billing becomes > > difficult to manage. The User-Name attribute within the Access- > > Accept packet need not be the same as the User-Name > > attribute in the > > Access-Request. > >=20 > > This section states that the Access-Accept MUST include a > > User-Name attribute and that the value of this attribute > > could be a billing identifier and need not match the value of > > the User-Name attribute sent in the Access-Request. It does > > not clearly state that the NAS is obligated to echo the value > > of this User-Name attribute in any accounting requests it > > generates for the session, but that does appear to be the > > implication. Is this in fact a new requirement being placed > > on NAS vendors? If so, does anyone know if any NASes actually > > support this feature? > >=20 > [Joe] This is a good question. I believe there are NASes and stateful > proxies that support this (I've seen the username from the=20 > Access-Accept > in accounting packets, but I'm not sure who put it there). =20 >=20 [FA] On a related note,=20 1) If the content of the UserName(1) in the Access-Accept packet is indented to be used for accounting purposes, should the text be more specific, rather than saying the absence of UserName(1) will make the accounting and billing difficult to manage. Instead it could say, "NAS MUST use the content of UserName(1) for accounting purposes. Your comment? 2)Does the specification need to make it clear that inner and outer identities need be checked by the home network for consistency to prevent fraud? For example, the user (fred@anyisp.com) uses bob@anyisp.com as the outer identity and if the RADIUS server does not check for this, then the user (fred@anyisp.com) has managed to authenticate to the network, and possibly deceive the network to send the billing charges to bob@anyips.com. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Feb 16 15:34:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18827 for ; Mon, 16 Feb 2004 15:34:55 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 142EC2039D; Mon, 16 Feb 2004 15:23:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C305020329; Mon, 16 Feb 2004 15:23:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C22C32039B for ; Mon, 16 Feb 2004 15:22:38 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id DB11D20329 for ; Mon, 16 Feb 2004 15:22:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18567; Mon, 16 Feb 2004 15:34:10 -0500 (EST) Message-Id: <200402162034.PAA18567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-08.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, 16 Feb 2004 15:34:09 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk Filename : draft-ietf-eap-rfc2284bis-08.txt Pages : 69 Date : 2004-2-16 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16121542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16121542.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 17 16:24:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06961 for ; Tue, 17 Feb 2004 16:24:57 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E910E1FF52; Tue, 17 Feb 2004 16:13:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A2DE2023F; Tue, 17 Feb 2004 16:13:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D9C22023F for ; Tue, 17 Feb 2004 16:12:58 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8006D1FF52 for ; Tue, 17 Feb 2004 16:12:56 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 240DF6A902 for ; Tue, 17 Feb 2004 23:24:32 +0200 (EET) Message-ID: <4032861B.9030302@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP meeting in Seoul 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, 17 Feb 2004 23:22:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit EAP WG will meet in Seoul. Here are the location and time details: THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 INT eap Extensible Authentication Protocol WG _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 18 09:36:31 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12978 for ; Wed, 18 Feb 2004 09:36:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A0E8203D0; Wed, 18 Feb 2004 09:24:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 150711FF92; Wed, 18 Feb 2004 09:24:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2A0B1FF92 for ; Wed, 18 Feb 2004 09:23:48 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 3FECC1FF54 for ; Wed, 18 Feb 2004 09:23:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12882; Wed, 18 Feb 2004 09:35:20 -0500 (EST) Message-Id: <200402181435.JAA12882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-09.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: Wed, 18 Feb 2004 09:35:20 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk Filename : draft-ietf-eap-rfc2284bis-09.txt Pages : 69 Date : 2004-2-18 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094800.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 18 09:38:13 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13241 for ; Wed, 18 Feb 2004 09:38:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DB08203D7; Wed, 18 Feb 2004 09:25:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22047203C8; Wed, 18 Feb 2004 09:25:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CC4A203D6 for ; Wed, 18 Feb 2004 09:24:13 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 18381203CE for ; Wed, 18 Feb 2004 09:24:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12903; Wed, 18 Feb 2004 09:35:32 -0500 (EST) Message-Id: <200402181435.JAA12903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-statemachine-02.txt,.pdf 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, 18 Feb 2004 09:35:31 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : State Machines for EAP Peer and Authenticator Author(s) : J. Vollbrecht Filename : draft-ietf-eap-statemachine-02.txt,.pdf Pages : 38 Date : 2004-2-18 This document describes a set of state machines for EAP Peer, EAP Standalone Authenticator (non-passthrough), EAP Backend Authenticator (for use on AAA servers), and EAP Full Authenticator (for both local and passthrough). This set of state machines shows how EAP can be implemented to support deployment in either a Peer/AP or Peer/AP/AAA Server environment. The Peer and Standalone Authenticator machines are illustrative of how the EAP protocol defined in [I-D.ietf-eap-rfc2284bis] may be implemented. The Backend and Full/ Passthrough Authenticators illustrate how EAP/RADIUS protocol support defined in [RFC3579] may be implemented. Where there are differences [I-D.ietf-eap-rfc2284bis]/[RFC3579] are authoritative. This document describes a state machine based on an EAP 'Switch' model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. A brief description of the EAP 'Switch' model is given in the Introduction section. The authors believe this document corresponds to the current state of revisions to the defining [I-D/ietf-eap-rfc2284bis]/[RFC3579] documents. The intent is for this document to synchronize with the defining documents when they are released, and if discrepancies are found the defining documents are authoritative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-statemachine-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-statemachine-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-statemachine-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-statemachine-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094809.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 18 14:00:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09079 for ; Wed, 18 Feb 2004 13:59:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B091203D1; Wed, 18 Feb 2004 13:48:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCB0D2025D; Wed, 18 Feb 2004 13:48:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77B132025C for ; Wed, 18 Feb 2004 13:45:43 -0500 (EST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by mail.frascone.com (Postfix) with ESMTP id 5E42620149 for ; Wed, 18 Feb 2004 13:45:41 -0500 (EST) Received: from piuha.net ([62.248.154.14]) by fep01-app.kolumbus.fi with ESMTP id <20040218185720.PKEL9750.fep01-app.kolumbus.fi@piuha.net> for ; Wed, 18 Feb 2004 20:57:20 +0200 Message-ID: <4033B51A.2080804@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] (fwd) I-D ACTION:draft-yanagiya-eap-saa-01.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: Wed, 18 Feb 2004 20:55:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key Author(s) : H. Ohnishi Filename : draft-yanagiya-eap-saa-01.txt Pages : 13 Date : 2004-2-18 In a public wireless Local Area Network (WLAN) access service using Mobile IP, network elements, such as access points, access routers, home agents and mobility anchor points, are required to authenticate the user to prevent unauthorized usage. Therefore, a mobile node needs to execute the authentication process many times to use the Mobile IP function. It will increase the connection delay. The connection delay can be reduced by using a preshared key as an authentication method. But it is necessary to share the symmetric secret key between network element (NE) and mobile node (MN) in advance. It is impossible for the MN to configure the key of all network elements in advance. In this document we discuss a secure access architecture using an Extensible Authentication Protocol (EAP) key as a shared key between NEs and an MN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yanagiya-eap-saa-01.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 18 18:17:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00605 for ; Wed, 18 Feb 2004 18:17:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC156203DD; Wed, 18 Feb 2004 18:06:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93A3A203D0; Wed, 18 Feb 2004 18:06:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CB2B203D0 for ; Wed, 18 Feb 2004 18:05:52 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 524D01FF87 for ; Wed, 18 Feb 2004 18:05:50 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1INTBj12354 for ; Wed, 18 Feb 2004 15:29:11 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 2284bis approved as an IETF Proposed Standard 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, 18 Feb 2004 15:29:11 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28946.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 19 07:19:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16020 for ; Thu, 19 Feb 2004 07:19:01 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C3AE2039B; Thu, 19 Feb 2004 07:07:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F009220326; Thu, 19 Feb 2004 07:07:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D56FE20326 for ; Thu, 19 Feb 2004 07:06:02 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 4387E20262 for ; Thu, 19 Feb 2004 07:06:01 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id EFB586A902; Thu, 19 Feb 2004 14:17:41 +0200 (EET) Message-ID: <4034A8EE.8050007@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.5) Gecko/20031007 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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Preliminary EAP WG meeting agenda for Seoul 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, 19 Feb 2004 14:15:42 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here's the preliminary agenda. Comments and suggestions appreciated. THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 1. Preliminaries (5 min) - Minutes - Bluesheets - Agenda bashing 2. Status, chairs (10 min) - 2284bis has been approved as an RFC - Methods can be submitted - Still working on the other documents - Charter update 3. EAP State machine, Pasi Eronen (20 min) - Remaining issues (?) discussion Drafts: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.txt Issues: http://www.drizzle.com/~aboba/EAP/eapissues.html 4. Keying issues, to be confirmed (30 min) - Remaining issues discussion Drafts: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt Issues: http://www.drizzle.com/~aboba/EAP/eapissues.html 5. Network selection, Farid Adrangi, Jari Arkko (25 min) - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-01.txt http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt 6. Binding problem update, to be confirmed, (5 min) Drafts: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: http://www.drizzle.com/~aboba/EAP/eapissues.html 7. 802.11 requirements, to be confirmed (5 min) - Discussion Drafts: http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt 8. Methods update (15 min) - Status table for all method work, chairs - Brief presentations for methods that are either new or requested to become standards track _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 19 09:21:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19534 for ; Thu, 19 Feb 2004 09:21:52 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 869702033A; Thu, 19 Feb 2004 09:10:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30A5A2039B; Thu, 19 Feb 2004 09:10:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA3772039B for ; Thu, 19 Feb 2004 09:09:25 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 354F42033A for ; Thu, 19 Feb 2004 09:09:24 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id D68666A902; Thu, 19 Feb 2004 16:21:05 +0200 (EET) Message-ID: <4034C5D9.6070401@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Henrik Levkowetz Cc: eap@frascone.com Subject: Re: [eap] RFC 2284bis approved as an IETF Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 19 Feb 2004 16:19:05 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is great news! I would like to thank everyone in the WG for making this happen via reviews, issue submissions, suggestions, proposed text, and discussion. RFC 2284bis really is a significant improvement over RFC 2284. And I would especially like to thank Henrik and Bernard who put in countless hours editing the draft, maintaining the issue tracker, and crafting text to solve the issues. Thanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 19 11:43:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26408 for ; Thu, 19 Feb 2004 11:43:01 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9845020345; Thu, 19 Feb 2004 11:31:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EB472033F; Thu, 19 Feb 2004 11:31:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25FCC2033F for ; Thu, 19 Feb 2004 11:30:15 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 41F3B201EC for ; Thu, 19 Feb 2004 11:30:13 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1JGrVG11349 for ; Thu, 19 Feb 2004 08:53:31 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] WG Last call on draft-ietf-eap-statemachine-02.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, 19 Feb 2004 08:53:31 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is an announcement of EAP WG last call on the EAP State Machine prior to sending this document to the IESG for publication as an Informational RFC. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf WG last call will run until Monday, March 8, 2004. Please send your comments to the EAP WG mailing list, filed using the Issue submission format described in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From xpvnoticiaurgente@hotmail.com Thu Feb 19 12:46:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29566 for ; Thu, 19 Feb 2004 12:46:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsFo-0003pf-00 for eap-archive@ietf.org; Thu, 19 Feb 2004 12:46:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsEx-0003l2-00 for eap-archive@ietf.org; Thu, 19 Feb 2004 12:45:36 -0500 Received: from 200-168-16-8.dsl.telesp.net.br ([200.168.16.8] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtsE0-0003aP-00; Thu, 19 Feb 2004 12:44:38 -0500 From: "Mato Grosso: . osz" To: eap-archive@ietf.org Subject: Alertam sobre perigo de aftosa em fazendas invadidas por índios ref.: wxn 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 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 19 Feb 2004 12:44:38 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.8 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

cod.: (qcn) EnEspañol:TraductorGratuitoAutomático - InEnglish:FreeAutomaticTranslator

Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por índios

Conselho Indigenista Missionário (Cimi), Fundação Nacional do Índio (Funai) e ONGs são acusadas de "fabricar" conflitos entre índios e proprietários rurais, que já causaram numerosas vítimas, como um dirigente pecuarista recentemente assassinado em Santa Catarina

CAMPO GRANDE, Fevr. 19, 2004 (AB) - "Há uma preocupação enorme com relação ao estado sanitário do rebanho bovino estimado em 9 mil cabeças, nas 14 fazendas invadidas por índios na região de Japorã, perto da fronteira com o Paraguai". "Mato Grosso do Sul é livre de aftosa, mediante vacinação, o Estado possui o 1o. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milhões e 700 mil cabeças, contribuindo com uma porcentagem significativa das exportações de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanitário teria de imediato uma enorme repercussão econômica em nível local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Indígenas da Federação da Agricultura e Pecuária de Mato Grosso do Sul (Famasul) (DrQuintino:DesejoContato - DrQuintino:DesejoContatoDeImprensa). A tensão e a violência na região fez com que a Agência Estadual de Defesa Sanitária Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigilância e vacinação do rebanho das fazendas invadidas por índios guaranis, caiuás e ñandeva.

Quintino acrescentou a preocupação existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Missionário (Cimi), e favorecidos pela Fundação Nacional do Índio, segundo já foi documentado no relatório da CPI do Funai, na Câmara dos Deputados". O assessor da Famasul informou que os índios, contrariamente ao informado por alguns meios de imprensa, "não abandonaram nenhuma das 14 fazendas invadidas, e até o momento não permitiram o trabalho de perícia judicial para avaliar a destruição causada".

Brasília: deputado Zauith denúncia "manipulação" de índios

Também ontem, em Brasília, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da Câmara para "denunciar os conflitos indígenas" que vem ocorrendo em todo o País, incentivados pela "atuação de determinadas organizações internacionais, que chegam a ameaçar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os índios a invadir as propriedades rurais". Zauith acrescentou que esse "cenário devastador" já vem causando "uma retração nos investimentos no agronegócio em Mato Grosso do Sul", atividade que "é o principal pilar da economia sul-matogrossense" (DepZauith:DiscursoCompleto).

Santa Catarina: Cimi e Funai fomentam caos, diz Federação da Agricultura

A Federação da Agricultura do Estado de Santa Catarina (Faesc), em nota de repúdio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabeça por indígenas que ameaçavam invadir propriedades rurais, afirma que sua morte "revela a dramática dimensão a que chegaram os conflitos entre índios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organizações, motivadas por objetivos inconfessáveis, fomentam o embate e exasperam a crise, tentando criar um cenário de caos e desordem", sendo "notória, nesse aspecto, a ação do Conselho Indigenista Missionário (Cimi), cujos agentes imiscuem-se nas áreas indígenas para fomentar a discórdia". Enquanto a Fundação Nacional do Índio (Funai) oscila entre a inércia e a omissão, nada fazendo em favor da paz e da tranqüilidade", sendo sua atuação "marcada pela influência de ONGs" (Faesc:TextoCompleto).

040219AB / Atualidade Brasileira

 LINKS:

DrQuintino/Famasul:DesejoContato

DrQuintino/Famasul:DesejoContatoUrgente

DrQuintino/Famasul:DesejoContatoDeImprensa

DepZauith:DiscursoCompleto

Faesc:TextoCompleto

AtualidadeBrasileira:MinhaOpinião

AtualidadeBrasileira:Concordo

AtualidadeBrasileira:Discordo

AtualidadeBrasileira:DocumentaçãoUsada

AtualidadeBrasileira:Remover

A difusão deste comunicado, com uma finalidade exclusivamente informativa, é de responsabilidade da agência Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomendável, mas não necessário, citar a fonte.

 

 

From dx7izjaup@netscape.net Fri Feb 20 16:00:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13449 for ; Fri, 20 Feb 2004 16:00:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHkr-00012f-00 for eap-archive@ietf.org; Fri, 20 Feb 2004 16:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHjx-0000zA-00 for eap-archive@ietf.org; Fri, 20 Feb 2004 15:59:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuHjY-0000va-00 for eap-archive@ietf.org; Fri, 20 Feb 2004 15:58:52 -0500 Received: from c-67-171-220-135.client.comcast.net ([67.171.220.135]) by mx2.foretec.com with smtp (Exim 4.24) id 1AuHjY-0005C7-SZ for eap-archive@ietf.org; Fri, 20 Feb 2004 15:58:53 -0500 Received: from [14.65.39.144] by c-67-171-220-135.client.comcast.net SMTP id iKMm3LdL16VKt1; Fri, 20 Feb 2004 19:57:56 -0100 Message-ID: <237-002$-n5j--b$--$2-v4-37o$6p@th89sqsx888v6s> From: "Elvin Bartlett" Reply-To: "Elvin Bartlett" To: eap-archive@ietf.org Subject: Fwd: Best deal of the month Date: Fri, 20 Feb 04 19:57:56 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3F2BAB71.42451E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=18.9 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_IMS_HTML,FORGED_IMS_TAGS,FORGED_MUA_IMS,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 FORGED_IMS_TAGS IMS mailers can't send HTML in this format * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --3F2BAB71.42451E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

omit depart acquisitive tsar , dour = fresh . silt manometer proteolysis , farina bluejacket . = amplify acculturate corporeal, isomer vineyard . argonaut , accede nineveh , = bestow . stifle . aldehyde , dervish ida , flowerpot . = cowl . ensemble , foamy intoxicant , normative . cartographic . croatia , = ed strikebreak , nnw . delectate . rot , stocky monday , = starfish . donaldson . incongruous . gladiator , lone picky , bradford . = demurred . globular , thallium pad , hemlock . carney . niagara , = complimentary denture , profligate . athlete . sandman , stutter dispensary , = vasectomy . cessna . hanley , andrew embroil , century . adolph . = polygynous , hoosegow bobby , ceramic . dunlop . dugout , tananarive = biennium , schoolboy . eel . isochronous , horseshoe befallen , murky . = zebra . auction , alveoli cretin spectroscopic efferent crunch , vie = ucla . triennial cherubim secretariat , lunatic galvanism . = preemptor amble mbabane, jetliner frightful . duration , sequel snobbish , = birdwatch . pistole . kindergarten

owfv lnuckyhav --3F2BAB71.42451E-- From ienbqcuxrncevk@fgb.com Fri Feb 20 18:16:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20976 for ; Fri, 20 Feb 2004 18:16:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJsT-00048N-00 for eap-archive@ietf.org; Fri, 20 Feb 2004 18:16:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJra-00044X-00 for eap-archive@ietf.org; Fri, 20 Feb 2004 18:15:19 -0500 Received: from [200.199.172.254] (helo=SIDER) by ietf-mx with smtp (Exim 4.12) id 1AuJqh-0003z4-00; Fri, 20 Feb 2004 18:14:25 -0500 From: "Joshua Brock" To: Subject: Enter to win free cigarettes Date: Fri, 20 Feb 2004 22:22:02 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6746466691872080042" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_50_60,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----6746466691872080042 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Brand Name Cigarettes Delivered To Your Door For Less.

Kscenario marble allegra homebound urgency welles invective slater county = conferring tahoe dusty=20 ; Zappellate delectable humboldt chicago travers= able hypotheses barrington butterball negligee pectoralis hereunder gemsto= ne divination elmira vanderpoel polyploidy raster jeep chiropractor saturn= secretarial viz eh tit ethnic ophthalmology shay rivet willful castle cyl= inder wharf=20. Jswitzer abc thunderclap guilford pander brushy lumbermen = vial inadvertent excretory sand treaty obnoxious shelby assail hue confere= e dialect finny scanty welcome cobb propitious resolution cling flock camb= rian minnesota addendum quartz divestiture hath britain appellant tunisia = clad gig gluey gravid maraud breakaway discriminant alexandre withe keith = custodial frizzle baldpate aisle lang choppy templeton staircase culvert a= ttract disco philharmonic bullfinch hypocrisy barracuda lobular menopause=20= Tcyanide rhythmic anchovy oakwood huntington contrivance devolve topograp= hy planeload=20; Dcomplement lawbreaking tying rhododendron alternate sigh= t canine cascade surmount congratulate lethargic mockery=20!! Jcurbside ca= ribou tress bluet breathe borderline cagey ellipsoidal compose griswold ce= lestial affable capacitor fm bendix hangable joke contrive mermaid syllogi= stic regatta bolshevist=20 Ydinghy cash sulfa enunciable tolerable annum w= hat're monarchy oneida buzzy pr slur ashley=20. Zbunyan south combatant bu= zzing russell intransigent withhold contingent swimsuit deputation korea m= adeleine gym cesium demoniac lindsay rollick=20!!! Gfelt leonard durango t= rillionth perturbation dissension infix important dilemma aau decontrolled= starling doodle waylaid carroll claw berkelium laxative pawtucket sportsm= an convict ancestral arrange veer roman mackintosh factor=20=20

Welcome to Cigarette Warehouse

       &nbs= p;    3D"The
  Ne= w Products NOW OFFERING FREE SHI= PPING when your order 2 or more cartons!
3DWinston
Winston
$22.27
3DSalem
Salem
$22.27
3D"Lucky
Lucky Strike
$23.45
3D"Kent=
Kent 1mg
$23.45
3D"Camel
Camel Lights
$22.27
3DCamel
Camel
$22.27
Realize savings of HUNDREDS or even THOUSANDS of d= ollars over the course of a year when purchasing cigarettes through Cigarette Warehouse.

We stock only the freshest cigarettes of the highest qu<= /couldn't>ality made by the biggest manufact= uring names in the cigarette business! Our products are guaranteed t= o be fresh and genuine.
=

Don't get burned by unfair c= igarette prices! Our represent= atives are standing by to take your ord<= /abbas>er. Once your order is received, it will be processed and shipped to= your home or office. Place your order for quality low-cost cig= arettes now!

Please Visit Us Here...=

Vshitepoke blunder earthworm edgar ambient blatz bedbug cerebellum tombsto= ne=20. Lcongenital democratic attendant coplanar scrotum decorous dozen bl= anche=20: Zbimini southampton backlash embattle ragout enervate stomp aque= duct compulsion apostolic=20 Iheterosexual galena sugar compatriot laplace= mantlepiece jansenist=20 . Isenegal clank deter dwarves holdover clang re= vile canton hobo poplar arbitrage edwin algorithmic afar downstairs aries = darling continua celebrant describe flamboyant tissue anagram barrage beck= on encore foggy cavernous natal confuse keyed=20!! Xsuzuki sarsaparilla ca= rbondale camille frankfurt voluntarism wills=20.Wmagician downs myosin eas= tward chandelier philosophic swanlike dash apocalyptic ruffle thorough sta= nhope raymond=20? Mdescription pelvic sausage glissade steamboat selectmen= cony cheshire canadian charles hecate legatee cover colorimeter ogre mome= ntum irresolute=20. Iparanoia selfish battalion jounce albert haag anther = millions tepee burial dearborn grammatic effloresce papaw counterproposal = vibrant ret voluntarism mamma galenite crunch barge chute cleft mold docke= t mask juggle conestoga cousin behave evince galley actinolite poetry koba= yashi deuterate easygoing=20=20Zhypothalamic compliment adventure confirma= tion lovebird marriage coauthor tracery=20: Lbooklet blab alice cling cone= y ely battlefront=20!! Kfission backstitch kremlin bern prefabricate pease= cpa jake sphalerite bushmaster alizarin verisimilitude chromosphere pilla= r hippopotamus constitution edwina shreveport bois anisotropic cantle circ= uit gainesville=20=20226.67.48.96%RND_DIACR = =20

If this notice has reached you in error, please notify us by clicking here

----6746466691872080042-- From WinnieHerbert@lnd.com Sat Feb 21 01:31:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05207 for ; Sat, 21 Feb 2004 01:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuQfd-0001EY-00 for eap-archive@ietf.org; Sat, 21 Feb 2004 01:31:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuQej-0001CI-00 for eap-archive@ietf.org; Sat, 21 Feb 2004 01:30:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuQea-00019f-00 for eap-archive@ietf.org; Sat, 21 Feb 2004 01:30:20 -0500 Received: from adsl-69-105-59-214.dsl.irvnca.pacbell.net ([69.105.59.214]) by mx2.foretec.com with smtp (Exim 4.24) id 1AuQeM-00025f-Q4 for eap-archive@ietf.org; Sat, 21 Feb 2004 01:30:19 -0500 X-Authentication-Warning: freedmen earmark emil despotic Date: Fri, 20 Feb 2004 23:21:48 -0700 From: "Bonita Clement" Reply-To: "Bonita Clement" Message-ID: <801750543.88535443@ncmvjqtsjd> To: drafts@ietf.org, eap-archive@ietf.org Subject: BEST INTERNET dr.ug store delivers Vali.um, Xan.ax Overnight ... References: <5741918948171.drafts@ietf.org> In-Reply-To: <5741918948171.drafts@ietf.org> X-Mailer: ostensible arcadia conic MIME-Version: 1.0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7Bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit Dis.count Ph.armacy Onlin.e
  • Sa.ve up t.o %8O orde.ring your meds online
  • No presc.ription required
  • fast disc.reet s.hipping, ov.ernight nextday air
  • FDA & Do.ctor Ap.proved
Xan.ax - Cia.lis - Via.gra - Vali.um

Pl.ace Your Or.der Here Tod.ay

no moore

paradigm lash calculable airfare abutted mockernut partridge infield galen dilemma divert haystack aviatrix conjuncture dilogarithm fantastic immutable society nomadic elfin teem attention grebe bantam conquest mimic ,longhorn ruinous hereabout glossary transit accost mckeon conclave covary evansville kline canst annoyance cryptogram occasion activation obituary clothe drexel sine workhorse bonito angeles do afire borealis glacier it'll tnt mendelssohn aventine finnegan census bleak liberia infantry apostolic cornet ;infelicitous problem shone piraeus wingmen halloween bloop grate psychoses scowl spitfire glandular cinema butterfly midpoint paycheck slick radiocarbon troupe windbag godlike - capitulate duffel bonze clown citizenry absenteeism bonaparte rap anhydrite hypnotic _christoph become horace pliancy superintendent normative malnutrition lab platonic domesticate mcgovern churchwomen rancho revolve verge co crossarm interferometer adjudicate gargantuan rostrum extroversion .
agnes germanium inlaid sax syndicate phalanger cushman gagging cloy hegelian ares ciceronian collapse serfdom .denunciation gab jog alfresco afar abstract condense mailman purloin handel runnymede splutter . loudspeaker claus birthday dustbin cahoot dimension joshua orin rosetta either recur sevenfold odessa slowdown henderson intransigent iberia ;enclave somali soy colorado delicacy bermuda falmouth penny molal revving airborne bipartite labour pappy alexandre downslope barrack bunsen faustus twinge paragon harriet lennox huber sapling canberra ductile account droopy deacon apse adhere cancerous palladian byword hydrogen asbestos sacral arena either xerox bassi capsize anderson chock athenian coronado bryan vasquez creche promiscuous cleric squirrel fluke baghdad emil carnage melpomene contempt hannah orthodoxy rollback tungstate cole apparatus anastigmatic wherewith walkie catawba teenage otiose arlene ;emcee deficient sole woods oslo medallion minstrel employing altruism appian irreducible clothe platte berkowitz caddy vacationland adamson crusade wong brazzaville acrobat purchase gyp apposition cyanic assert everyman helpmate polygonal daly granville extraditable focussed athlete dicta masquerade wallaby jackass orangeroot attire expressway inside syllabic hilbert corn smart midspan sse interject insinuate rabbit credent leeds steepen
moribund shenanigan convolute copperas leeds sanicle thump chicory resolve posner zinc amoeba aural smatter composition .chowder detention dickcissel synopses solitude nor cavilling read guillotine icosahedral muskoxen . policemen aaas trustworthy christie peacock administrable dooley cutthroat dirichlet anguish pyknotic blazon affectation revery strand bakhtiari vacationland teapot brick ethic cocky ;enrollee beaujolais gauleiter boorish omaha bestial fishermen irreproachable caribbean sphere bovine rebecca adrenal ballot dogma annoy histochemistry vigil tomography alcohol sinewy sluice upsetting doge ladle microbial maxwell turk minstrel demijohn brunette methodology risen
complain consignee mandrill stricture multinomial conceptual braille citizen sclerosis pigtail sawmill ariadne xerxes muddlehead shadbush aarhus lawmake swede mezzanine carfare insoluble ;southpaw winch copywriter bituminous frozen jealous throughout inherit rilly keep swallow gazelle eliminate caldwell moliere mckenzie bias breadth exclusionary francis cipher covary hypocritic brenner contemplate reception significant weatherproof wavefront witness cornmeal hadley coat desorption impassable uremia pearl contrivance flout assimilate cutoff johnson axes inelastic americium deterrent libidinous durance handel soluble squeal captive devotion austenite elkhart katie accrual cheshire devilish v workshop chalkboard vulgar falter chat victorious superannuate lass leftover galveston coexist epicurean aphid hawk deflater cypress nelson scarce parapsychology corundum barbour methodist rototill homologous schuylkill beltsville From peeclwhzbh@wave-masters.com Tue Feb 24 01:25:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18347 for ; Tue, 24 Feb 2004 01:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvW0j-0005wN-00 for eap-archive@ietf.org; Tue, 24 Feb 2004 01:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvVzq-0005nV-00 for eap-archive@ietf.org; Tue, 24 Feb 2004 01:24:46 -0500 Received: from pool-68-162-5-179.nwrk.east.verizon.net ([68.162.5.179]) by ietf-mx with smtp (Exim 4.12) id 1AvVyt-0005ab-00; Tue, 24 Feb 2004 01:23:48 -0500 Received: from 192.153.122.215 by 68.162.5.179; Tue, 24 Feb 2004 08:25:07 +0200 Message-ID: From: "Anthony Kauffman" Reply-To: "Anthony Kauffman" To: eap-archive@ietf.org Cc: midcom@ietf.org Subject: Ambien - Very Low Cost Date: Tue, 24 Feb 2004 08:22:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--96481630291925647" X-Originating-IP: 132.151.6.1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.1 required=5.0 tests=CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----96481630291925647 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

DirectMe= ds Online Pharmacy
Prescriptions You Need At Prices You Deserve!


View our expanded= product line and new low prices today!=

Click Here To Start Saving

=



Sleep= Aides
Ambien, Sona= ta

Muscl= e Relaxers
Soma, Flexer= il, Skelaxin

Pain Relief
Fioricet, Vioxx

Qdishevel quit gest= alt denounce plantation loge educable glassware perfect thicket inhibitor = reverse cowmen=20 ! Htherapist byproduct pellet buses psychology indemnify= koran phillips baltic broglie topology truancy carlton illustrate showdow= n=20!! Uam gonzales deere conservatory wherever jeres shutout maureen infi= nitum drank lodge mirfak inherit idiocy aberrant gorham seething hotbox bi= rch set infantryman target oint synoptic camel gullet stardom celandine ma= rgaret fjord powerhouse bridgewater criterion genre uganda cordage mental = imbroglio annihilate coextensive devotee z's vigilantism enterprise chapma= n crackle clot hate norris oxidate southbound pail articulate amaze switch= board possemen john embassy conscionable befuddle=20.Scelebrity cactus pri= tchard cowhide bar bureaucrat eyelet taffy teeter chimera fishmonger descr= iptive abstain vital dactyl=20 ! Rabner his accost artemis surgery modem s= idewalk platitude tuttle custom=20. Zrill jag descendant blip belch cranks= haft indent polarography flautist golf citrus tyson muskrat romania design= ate mince myth blake proust emanate bluish dorothea activate guano einstei= nium argonne bose my percentage clannish stasis prudent inbreed cosmetic l= odowick correlate appliance hutchins grocery troika grape suspense broody = cessation coccidiosis henchmen barr chalcocite actinolite o'sullivan thoro= ughgoing maidenhair cyclotomic mateo bench maxwell=20.

If this notice has reached you in error, please notify us by clicking here
----96481630291925647-- From eap-admin@frascone.com Tue Feb 24 04:10:20 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08292 for ; Tue, 24 Feb 2004 04:10:19 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CF9B1FF97; Tue, 24 Feb 2004 03:58:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B79820437; Tue, 24 Feb 2004 03:58:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 852CA20437 for ; Tue, 24 Feb 2004 03:57:23 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id ECC2F1FF97 for ; Tue, 24 Feb 2004 03:57:21 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A86206A902; Tue, 24 Feb 2004 11:09:09 +0200 (EET) Message-ID: <403B1434.4020305@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba References: <4034A8EE.8050007@piuha.net> In-Reply-To: <4034A8EE.8050007@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG meeting agenda for Seoul, take two 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, 24 Feb 2004 11:07:00 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 1. Preliminaries (5 min) - Minutes - Bluesheets - Agenda bashing 2. Status, chairs (10 min) - 2284bis has been approved as an RFC - Methods can be submitted - Still working on the other documents - Charter update 3. EAP State machine, Pasi Eronen (20 min) Goal: - Discussion of remaining issues, determine if everything has been agreed upon Contents: - Remaining issues (?) discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 4. Keying issues, to be confirmed (30 min) Goal: - Progress the work on the remaining issues Contents: - Remaining issues discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Goal: - Inform about the activities and requirements in different SDOs - Gauge the completeness of the problem statement - Gauge interest in solutions (note: problem is only partially in IETF scope) Contents: - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt 6. Binding problem update, to be confirmed, (5 min) Goal: - Status update Contents: - TBD Drafts: - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 7. 802.11 requirements, to be confirmed (5 min) Goal: - Provide feedback to 802.11 (change control is at IEEE, however) Contents: - Discussion Drafts: - http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt 8. Methods update (15 min) Goal: - Inform Contents: - Status table for all method work, chairs - Brief presentations for methods that are either new or requested to become standards track _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Feb 24 10:54:09 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27197 for ; Tue, 24 Feb 2004 10:54:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C09F20339; Tue, 24 Feb 2004 10:42:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B52862033B; Tue, 24 Feb 2004 10:42:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D19F2033B for ; Tue, 24 Feb 2004 10:41:48 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6C9892032F for ; Tue, 24 Feb 2004 10:41:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1OG4iZ24296 for ; Tue, 24 Feb 2004 08:04:44 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Pseudo-WG last call on draft-walker-ieee802-req-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: Tue, 24 Feb 2004 08:04:44 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) IEEE 802.11 has requested that the IETF publish draft-walker-ieee802-req-00.txt as an Informational RFC. The draft is available for inspection here: http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt Since this is a work item of IEEE 802.11, the EAP WG does not have change control and cannot issue a formal EAP WG last call. However, in order to solicit comments on the draft and allow for incorporation of comments during the IEEE 802 March plenary, we will hold a "pseudo-WG last call" on this draft. The "pseudo-WG last call" will last until March 12, 2004. Please send comments to the EAP WG mailing list, in the Issue format described at: http://www.drizzle.com/~aboba/EAP/eapissues.html I will add an entry for the draft on the EAP WG Issues page, and will collect the Issues for discussion at the IEEE 802 plenary in Orlando. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 25 00:24:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27992 for ; Wed, 25 Feb 2004 00:24:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80348203F1; Wed, 25 Feb 2004 00:12:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72C6E203FC; Wed, 25 Feb 2004 00:12:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E887E203F1 for ; Wed, 25 Feb 2004 00:11:36 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 4127420369 for ; Wed, 25 Feb 2004 00:11:35 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2004 21:33:39 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1P5NN4U013513 for ; Tue, 24 Feb 2004 21:23:23 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.225.9]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Feb 2004 21:29:32 -0800 From: "Joseph Salowey" To: Message-ID: <006301c3fb5f$7c21f150$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 25 Feb 2004 05:29:32.0275 (UTC) FILETIME=[58DBFC30:01C3FB60] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue : IEEE802.11 requirements doc item (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: Tue, 24 Feb 2004 21:23:20 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 2/24/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-February/002229.html; see also issue 222 Document: IEEE 802.11 document Comment type: 'T'echnical Priority: '1' Should fix Section: [3] Rationale/Explanation of issue: Synchronization of state is not the same as protected result indicators. It is possible to have synchronized state without protected result indicators and it is possible for a poorly implemented method to implement protected result indicators and not have synchronized state. The suggestion is to replace protected result indicators with a description of synchronized state. The following suggested text is based on some email exchanges on the EAP list with Jessie Walker. Synchronized State At the completion of an EAP authentication method the Peer and Server must have the same notion of state information related to the authentication. If the peer and the server do not share the same notion of state information then either or both of the parties must fail the authentication and must not generate keys for export out of the method. The exact state attributes that are shared may vary from method to method but it typically includes the protocol both executed, what credentials were presented and accepted by both parties, what cryptographic keys are shared and what EAP method specific attributes were negotiated, such as cipher suites and limitations of usage on all protocol state. Both parties must be able to distinguish this instance of the protocol from all other instances of the protocol and they must share the same view of which state attributes are public and which are private to the two parties alone. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Feb 25 06:27:23 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11207 for ; Wed, 25 Feb 2004 06:27:23 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A4412038D; Wed, 25 Feb 2004 06:15:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D95B2203E9; Wed, 25 Feb 2004 06:15:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C70E8203E9 for ; Wed, 25 Feb 2004 06:14:14 -0500 (EST) Received: from fep05-svc.swip.net (fep05.swip.net [130.244.199.133]) by mail.frascone.com (Postfix) with ESMTP id C13522038D for ; Wed, 25 Feb 2004 06:14:12 -0500 (EST) Received: from DELL.tele2.fr ([80.170.54.15]) by fep05-svc.swip.net with ESMTP id <20040225112602.VDAO15597.fep05-svc.swip.net@DELL.tele2.fr>; Wed, 25 Feb 2004 12:26:02 +0100 Message-Id: <5.2.1.1.0.20040225120503.01da1d08@pop.tele2.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: eap@frascone.com From: Pascal Urien Cc: jari.arkko@piuha.net, aboba@internaut.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-urien-smartcard-04.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: Wed, 25 Feb 2004 12:15:57 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Everybody, The version 4 of the IETF draft "eap support in smartcard" is available at, http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-04.txt Regards Pascal Urien _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 26 03:30:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27078 for ; Thu, 26 Feb 2004 03:30:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A078D2021D; Thu, 26 Feb 2004 03:18:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DD81202C8; Thu, 26 Feb 2004 03:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05A33202C8 for ; Thu, 26 Feb 2004 03:17:14 -0500 (EST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 45F5B2021D for ; Thu, 26 Feb 2004 03:17:12 -0500 (EST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1Q8Uxg3015112 for ; Thu, 26 Feb 2004 08:30:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1Q8Nvpv029307 for ; Thu, 26 Feb 2004 08:23:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022600290026150 for ; Thu, 26 Feb 2004 00:29:00 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Feb 2004 00:29:00 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [EAP] Revised Mediating Network Discovery and Selection Message-ID: <96D13222E704DC4D868F0009F0EE53E1017B3D19@orsmsx410.jf.intel.com> Thread-Topic: [EAP] Revised Mediating Network Discovery and Selection Thread-Index: AcP8QpV6q6+gyannRcWXBd1kET5b0w== From: "Adrangi, Farid" To: X-OriginalArrivalTime: 26 Feb 2004 08:29:00.0716 (UTC) FILETIME=[95C36EC0:01C3FC42] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 26 Feb 2004 00:29:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Here's a revised draft on mediating network discovery and selection. The draft does not appear on the archives (for some reason) - Jari was kind to host the file for me while I am working with IETF secretaries on this issue. http://www.arkko.com/publications/eap/draft-adrangi-eap-network-discover y-and-selection-01.txt The draft was revised to conform with the recently submitted RFC2486bis, http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.tx t. =20 BR, Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 26 04:15:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29893 for ; Thu, 26 Feb 2004 04:15:02 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23B1A1FDE3; Thu, 26 Feb 2004 04:03:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 904D3201F7; Thu, 26 Feb 2004 04:03:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28538201F7 for ; Thu, 26 Feb 2004 04:02:46 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 960FF1FDE3 for ; Thu, 26 Feb 2004 04:02:44 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 88F1A6A906; Thu, 26 Feb 2004 11:14:35 +0200 (EET) Message-ID: <403DB877.9020403@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba Subject: [eap] EAP WG meeting agenda for Seoul, take three References: <4034A8EE.8050007@piuha.net> In-Reply-To: <4034A8EE.8050007@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 26 Feb 2004 11:12:23 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Updated Farid's draft URL and added two requested method presentations. Some updates of presenter names. I think we have now all the presentations that were requested; send me e-mail if something was forgotten. THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 1. Preliminaries (5 min) - Minutes - Bluesheets - Agenda bashing 2. Status, chairs (10 min) - 2284bis has been approved as an RFC - Methods can be submitted - Still working on the other documents - Charter update 3. EAP State machine, Pasi Eronen (20 min) Goal: - Discussion of remaining issues, determine if everything has been agreed upon Contents: - Remaining issues (?) discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 4. Keying issues, Pasi Eronen (30 min) Goal: - Progress the work on the remaining issues Contents: - Remaining issues discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Goal: - Inform about the activities and requirements in different SDOs - Gauge the completeness of the problem statement - Gauge interest in solutions (note: problem is only partially in IETF scope) Contents: - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.arkko.com/publications/eap/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt 6. Binding problem update, Farid Adrangi (5 min) Goal: - Status update Contents: - TBD Drafts: - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 7. 802.11 requirements, to be confirmed (5 min) Goal: - Provide feedback to 802.11 (change control is at IEEE, however) Contents: - Discussion Drafts: - http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt 8. Methods update (15 min) Goal: - Inform Contents: - Status table for all method work, chairs (5 min) - Brief presentations for methods that are either *new* or requested to become *standards track* . EAP Bluetooth, Hahnsang Kim http://www.ietf.org/internet-drafts/draft-kim-eap-bluetooth-00.txt . EAP PSK, Florent Bersani http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Feb 26 12:47:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29159 for ; Thu, 26 Feb 2004 12:47:15 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0E63204D5; Thu, 26 Feb 2004 12:35:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 275AB204DF; Thu, 26 Feb 2004 12:35:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D91C7204DF for ; Thu, 26 Feb 2004 12:34:30 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B47E3204D5 for ; Thu, 26 Feb 2004 12:34:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1QHvI912207 for ; Thu, 26 Feb 2004 09:57:18 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 226: Comments on WLAN requirements 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, 26 Feb 2004 09:57:17 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 226: Comments on WLAN requirements Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 2/25/2004 Reference: Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: S Section: 1, 1.2, 2.2, 3 Rationale/Explanation of issue: I don't think there is enough overview material, describing the IEEE 802.11i environment. Change Section 1 to the following: "1. Introduction The Draft IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i] makes use of IEEE 802.1X [IEEE8021X-REV] which in turn relies on the Extensible Authentication Protocol (EAP), defined in [RFC2284bis]. Deployments of IEEE 802.11 wireless LANs today are based on EAP, and use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS [TTLS], PEAP [PEAP] and EAP-SIM [SIM]. These methods support authentication credentials that include digital certificates, user-names and passwords, secure tokens, and SIM secrets. This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments." The draft could benefit by addition of a terminology section. Add Section 1.2: "1.2 Terminology authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations a AAA server acting as an EAP server transports the MSK to the authenticator. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet." 4-Way Handshake A pairwise Authentication and Key Management Protocol (AKMP) defined in [IEEE802.11i], which confirms mutual possession of a Pairwise Master Key by two parties and distributes a Group Key." With respect to Section 2.2, clause [3], my recommendation would be to delete this, since "Protected Result Indications" is no longer listed as a security claim within [RFC2284bis]. Change Section 2.5 to the following: "2.5. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), is defined in [RFC2284bis] Section 5.4. EAP-MD5-Challenge and two EAP authentication methods defined in [RFC2284bis], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non- compliant with the requirements defined in this document, since as is noted in [RFC2284bis], they do not support any of the mandatory requirements defined in Section 2.2, or the optional features defined in Section 2.4." Insert a Section 3, and renumber subsequent sections: "3. Security Considerations Within [IEEE802.11i], EAP is used for both authentication and key exchange between the EAP peer and server. The use of EAP for key exchange is described within [KEYFRAME]. Given that wireless local area networks provide access to the media to an attacker within range, EAP usage within [IEEE802.11i] is subject to the threats outlined in [RFC2284bis] Section 7.1, as well as the security considerations described in Section 7.3 through Section 7.16. In addition, in environments in which an authentication server is used, the security considerations described in [RFC3579] Section 4 will apply." Add to the informative references: [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [KEYFRAME] Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), October 2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 28 07:34:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14976 for ; Sat, 28 Feb 2004 07:34:24 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 362391FF7D; Sat, 28 Feb 2004 07:22:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6D2A2023A; Sat, 28 Feb 2004 07:22:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D2932023A for ; Sat, 28 Feb 2004 07:21:09 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9C5051FF7D for ; Sat, 28 Feb 2004 07:21:07 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 439646A906; Sat, 28 Feb 2004 14:33:00 +0200 (EET) Message-ID: <404089F3.4010408@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba References: <4034A8EE.8050007@piuha.net> In-Reply-To: <4034A8EE.8050007@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG meeting agenda for Seoul, take four 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, 28 Feb 2004 14:30:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Added a presentation of draft-eronen-ipsec-ikev2-eap-auth-00.txt THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 1. Preliminaries (5 min) - Minutes - Bluesheets - Agenda bashing 2. Status, chairs (10 min) - 2284bis has been approved as an RFC - Methods can be submitted - Still working on the other documents - Charter update 3. EAP State machine, Pasi Eronen (15 min) Goal: - Discussion of remaining issues, determine if everything has been agreed upon Contents: - Remaining issues (?) discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 4. Keying issues, Pasi Eronen (25 min) Goal: - Progress the work on the remaining issues Contents: - Remaining issues discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Goal: - Inform about the activities and requirements in different SDOs - Gauge the completeness of the problem statement - Gauge interest in solutions (note: problem is only partially in IETF scope) Contents: - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.arkko.com/publications/eap/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt 6. Binding problem update, Farid Adrangi (5 min) Goal: - Status update Contents: - TBD Drafts: - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 7. 802.11 requirements, to be confirmed (5 min) Goal: - Provide feedback to 802.11 (change control is at IEEE, however) Contents: - Discussion Drafts: - http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt 8. EAP authentication in IKEv2, Pasi Eronen (10 min) Goal: - Inform the group about how current IKEv2 and Pasi's extended IKEv2 handle EAP authentication - Get feedback Drafts: - http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth-00.txt 9. Methods update (15 min) Goal: - Inform Contents: - Status table for all method work, chairs (5 min) - Brief presentations for methods that are either *new* or requested to become *standards track* . EAP Bluetooth, Hahnsang Kim http://www.ietf.org/internet-drafts/draft-kim-eap-bluetooth-00.txt . EAP PSK, Florent Bersani http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Feb 28 08:33:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16518 for ; Sat, 28 Feb 2004 08:33:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A45720513; Sat, 28 Feb 2004 08:21:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BD9D20268; Sat, 28 Feb 2004 08:21:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0248C20268 for ; Sat, 28 Feb 2004 08:20:21 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6B9321FF7F for ; Sat, 28 Feb 2004 08:20:19 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id D50056A906; Sat, 28 Feb 2004 15:32:13 +0200 (EET) Message-ID: <404097DA.2080103@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jsalowey@cisco.com Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Binding updates in draft-josefsson-pppext-eap-tls-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: Sat, 28 Feb 2004 15:30:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have a question about the following text in the draft: > 4. EAP-TLV method > > The EAP-TLV method is a payload with standard Type-Length-Value (TLV) > objects. The TLV objects could be used to carry arbitrary parameters > between EAP peer and EAP server. Possible uses for TLV objects > include: language and character set for Notification messages; > cryptographic binding; MIPv6 Binding Update. I have trouble understanding how this works in practice. You would need to complete EAP before you could actually have IP up on the interface. For instance, you would not be able to see IPv6 RAs before EAP is complete, and you for sure could not run DAD. So, how would one fill up the care-of address field in the Binding Update? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 29 07:39:22 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19228 for ; Sun, 29 Feb 2004 07:39:22 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B91412031C; Sun, 29 Feb 2004 07:27:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CB33203E7; Sun, 29 Feb 2004 07:27:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC365203E7 for ; Sun, 29 Feb 2004 07:26:13 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5B61C2031C for ; Sun, 29 Feb 2004 07:26:12 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 35DC26A90A; Sun, 29 Feb 2004 14:38:06 +0200 (EET) Message-ID: <4041DCAA.4050906@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba References: <4034A8EE.8050007@piuha.net> In-Reply-To: <4034A8EE.8050007@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG meeting agenda for Seoul, take five 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, 29 Feb 2004 14:35:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Changed the URL of the EAP PSK draft. THURSDAY, March 4, 2004 1300-1500 Afternoon Sessions I Sapphire 4 1. Preliminaries (5 min) - Minutes - Bluesheets - Agenda bashing 2. Status, chairs (10 min) - 2284bis has been approved as an RFC - Methods can be submitted - Still working on the other documents - Charter update 3. EAP State machine, Pasi Eronen (15 min) Goal: - Discussion of remaining issues, determine if everything has been agreed upon Contents: - Remaining issues (?) discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 4. Keying issues, Pasi Eronen (25 min) Goal: - Progress the work on the remaining issues Contents: - Remaining issues discussion Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Goal: - Inform about the activities and requirements in different SDOs - Gauge the completeness of the problem statement - Gauge interest in solutions (note: problem is only partially in IETF scope) Contents: - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.arkko.com/publications/eap/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt 6. Binding problem update, Farid Adrangi (5 min) Goal: - Status update Contents: - TBD Drafts: - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html 7. 802.11 requirements, to be confirmed (5 min) Goal: - Provide feedback to 802.11 (change control is at IEEE, however) Contents: - Discussion Drafts: - http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt 8. EAP authentication in IKEv2, Pasi Eronen (10 min) Goal: - Inform the group about how current IKEv2 and Pasi's extended IKEv2 handle EAP authentication - Get feedback Drafts: - http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth-00.txt 9. Methods update (15 min) Goal: - Inform Contents: - Status table for all method work, chairs (5 min) - Brief presentations for methods that are either *new* or requested to become *standards track* . EAP Bluetooth, Hahnsang Kim http://www.ietf.org/internet-drafts/draft-kim-eap-bluetooth-00.txt . EAP PSK, Florent Bersani http://www.arkko.com/publications/eap/draft-bersani-eap-psk-01.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 29 07:40:09 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19256 for ; Sun, 29 Feb 2004 07:40:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B3122042E; Sun, 29 Feb 2004 07:28:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BD4F20421; Sun, 29 Feb 2004 07:28:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B23E820421 for ; Sun, 29 Feb 2004 07:27:53 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 26B4A20420 for ; Sun, 29 Feb 2004 07:27:52 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A65596A90A for ; Sun, 29 Feb 2004 14:39:47 +0200 (EET) Message-ID: <4041DD0E.40907@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] slides 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, 29 Feb 2004 14:37:34 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit For those who are presenting in our meeting on Thursday, please send your slides to me. All slides will be stored at http://www.arkko.com/publications/eap/ietf-59/ --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Feb 29 09:27:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23962 for ; Sun, 29 Feb 2004 09:27:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D01DB20434; Sun, 29 Feb 2004 09:15:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D5602042E; Sun, 29 Feb 2004 09:15:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38DA52042E for ; Sun, 29 Feb 2004 09:14:15 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A0E9E20429 for ; Sun, 29 Feb 2004 09:14:13 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 96E226A908; Sun, 29 Feb 2004 16:26:09 +0200 (EET) Message-ID: <4041F5FD.4000800@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , Joe Salowey Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] keying issue 221: EMSK usage guidelines 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, 29 Feb 2004 16:23:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit We discussed the incorporation of the EMSK guidelines document to the keying framework in IETF-58. That discussion ended up recommending to merge it in. So unless anyone wants to object here, I think we should consider this issue closed. I looked at Joe's suggested text [1] and it looks good to me. A couple of comments, however: - s/Applications/applications. - "The application MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in this document." This seems inconsistent with the idea that applications should only know the AMSK, not the EMSK. - Don't we need key names, too? Suggest branching a key naming hierarchy from the EMSK before using it to branch AMSKs. --Jari [1] http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20221 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap