From diameter-admin@frascone.com Thu Apr 1 05:13:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04523 for ; Thu, 1 Apr 2004 05:13:55 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE9F1205E3 for ; Thu, 1 Apr 2004 05:01:59 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89543205E0 for ; Thu, 1 Apr 2004 05:00:58 -0500 (EST) Date: Thu, 01 Apr 2004 05:00:58 -0500 Message-ID: <20040401100058.20668.7995.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 Fri Apr 2 03:30:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28742 for ; Fri, 2 Apr 2004 03:29:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F24D203DE; Fri, 2 Apr 2004 03:18:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91AC220304; Fri, 2 Apr 2004 03:18:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D8EA1FF97 for ; Fri, 2 Apr 2004 03:17:07 -0500 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 5E14220304 for ; Fri, 2 Apr 2004 03:17:05 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 10:28:26 +0200 Received: from rd.francetelecom.fr ([10.193.167.20]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 2 Apr 2004 10:28:26 +0200 Message-ID: <406D2452.80908@rd.francetelecom.fr> From: Florent Bersani 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: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2004 08:28:26.0275 (UTC) FILETIME=[781B2730:01C4188C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: [IETF-Announce] Last Call: 'EAP Flexible Authentication via Secure Tunneling(EAP-FAST)' to Informational 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, 02 Apr 2004 10:29:06 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [IETF-Announce] Last Call: 'EAP Flexible Authentication via Secure Tunneling(EAP-FAST)' to Informational RFC Date: Wed, 31 Mar 2004 17:50:29 -0500 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce:; The IESG has received a request from an individual submitter to consider the following document: - 'EAP Flexible Authentication via Secure Tunneling (EAP-FAST) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-00.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 04:49:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01804 for ; Fri, 2 Apr 2004 04:49:54 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C58A203F8; Fri, 2 Apr 2004 04:38:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A95920350; Fri, 2 Apr 2004 04:38:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76CC120350 for ; Fri, 2 Apr 2004 04:37:02 -0500 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 8400C2029E for ; Fri, 2 Apr 2004 04:37:00 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 11:48:37 +0200 Received: from rd.francetelecom.fr ([10.193.167.20]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 2 Apr 2004 11:48:36 +0200 Message-ID: <406D371C.9080701@rd.francetelecom.fr> From: Florent Bersani 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: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2004 09:48:36.0507 (UTC) FILETIME=[AB3A4EB0:01C41897] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] A synthesis on the existing (shared key) EAP methods... 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, 02 Apr 2004 11:49:16 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit ...is available at this URL before it reaches the archive: http://eappsk.chez.tiscali.fr/draft-bersani-eap-synthesis-sharedkeymethods-00.txt Any comments, feedback or additional information is most welcome. Florent, who wishes that a standard replacement for EAP-MD5 be drafted (not especially EAP-PSK which is only a proposal to stimulate the community ;-)) P.S : (Abstract of the draft) The purpose of this draft is to gives a broad picture of the existing proposed EAP methods, with a focus on shared key EAP methods. Indeed, it is the belief of the author that a standard replacement for EAP-MD5 (that is deprecated due to security reasons) is needed. By listing the existing shared key EAP methods, the goal is to gather consensus that such a multiplication of methods is detrimental and that a single method retaining the best of the existing proposals could and should be drafted. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 07:46:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07208 for ; Fri, 2 Apr 2004 07:46:16 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19E5A1FDDD; Fri, 2 Apr 2004 07:34:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2F36201EF; Fri, 2 Apr 2004 07:34:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16C93201EF for ; Fri, 2 Apr 2004 07:33:12 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id EAF591FDDD for ; Fri, 2 Apr 2004 07:33:09 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32CirF05164; Fri, 2 Apr 2004 15:44:53 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 15:41:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i32Cfe5n020540; Fri, 2 Apr 2004 15:41:40 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00O93ybB; Fri, 02 Apr 2004 15:38:37 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32CcbF15963; Fri, 2 Apr 2004 15:38:37 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 15:34:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] A synthesis on the existing (shared key) EAP methods... Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223BB@esebe023.ntc.nokia.com> Thread-Topic: [eap] A synthesis on the existing (shared key) EAP methods... Thread-Index: AcQYmR9seyXXZeTHT3KTv1K94TMhYAAD0adg From: To: , X-OriginalArrivalTime: 02 Apr 2004 12:34:57.0333 (UTC) FILETIME=[E8437E50:01C418AE] 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, 2 Apr 2004 15:34:55 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, This document looks like a very useful summary of existing=20 EAP methods, thanks for taking the time to write it! I agree with you wish to standardize a replacement for EAP-MD5. However, it's worth noting that the current version of=20 draft-walker-ieee802-req practically requires the use of=20 public key cryptography for this, since the "Dictionary attack resistance" security claim MUST be supported. 2284bis says that "A method may be said to provide protection against dictionary attacks if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary." As far as I know, this requires either some form of public key=20 cryptography, or enforcing that the shared secret cannot be=20 chosen by the user.=20 Using e.g. PBKDF2 from PKCS#5 is not sufficient, since the work=20 load is still basically the same: if the user's password is the=20 Nth word in the dictionary, an attacker can find it in N=20 operations (each operation takes slightly longer than without=20 PBKDF2, though). As to the second alternative, IMHO totally prohibiting user-chosen shared secrets would reduce the usefulness of EAP-PSK (or whatever will be chosen as successor-of-EAP-MD5).=20 However, I don't think this is an argument against EAP-PSK but=20 instead an argument for making dictionary attack resistance a=20 "SHOULD" instead of "MUST" in draft-walker-ieee802-req... Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Florent Bersani > Sent: Friday, April 02, 2004 12:49 PM > To: eap@frascone.com > Subject: [eap] A synthesis on the existing (shared key) EAP methods... >=20 >=20 >=20 > ...is available at this URL before it reaches the archive:=20 > http://eappsk.chez.tiscali.fr/draft-bersani-eap-synthesis-shar > edkeymethods-00.txt >=20 > Any comments, feedback or additional information is most welcome. >=20 > Florent, who wishes that a standard replacement for EAP-MD5=20 > be drafted (not especially EAP-PSK which is only a proposal=20 > to stimulate the community ;-)) >=20 > P.S : (Abstract of the draft) The purpose of this draft is to=20 > gives a broad picture of the existing proposed EAP methods,=20 > with a focus on shared key EAP methods. Indeed, it is the=20 > belief of the author that a standard replacement for EAP-MD5=20 > (that is deprecated due to security reasons) is needed. By=20 > listing the existing shared key EAP methods, the goal is to=20 > gather consensus that such a multiplication of methods is=20 > detrimental and that a single method retaining the best of=20 > the existing proposals could and should be drafted.=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 07:59:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07687 for ; Fri, 2 Apr 2004 07:59:53 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FB862042F; Fri, 2 Apr 2004 07:48:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E333202BB; Fri, 2 Apr 2004 07:48:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 903BB202BB for ; Fri, 2 Apr 2004 07:47:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id CF4D9201EF for ; Fri, 2 Apr 2004 07:47:41 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C5DAC89924; Fri, 2 Apr 2004 15:59:24 +0300 (EEST) Message-ID: <406D630C.6080700@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: Pasi Eronen 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] draft on authenticated service identities 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, 02 Apr 2004 15:56:44 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi and I have written a draft on the authentication of service identities (= service parameters claimed by access servers) in EAP. Essentially, the draft is an extension of EAP-TLS, EAP-SIM, EAP-AKA, and PEAPv2 for transporting and authenticating parameters related to the offered service. This makes it possible to ensure, for instance, that everyone agrees about the claimed SSID or that a compromised access point can not present itself as an IKEv2 gateway. Here's the abstract: A common arrangement in network access is the separation of the actual network access device (such as a wireless LAN access point) from the authentication servers. In the Extensible Authentication Protocol (EAP) framework, different authentication methods can provide varying security properties. If the EAP methods support authentication of service identities, it becomes possible for the clients to verify not only that the access device is trusted, but also that the parameters advertised by the access device are correct. This document specifies a backward compatible extension to popular EAP methods for supporting such service identity authentication. A common parameter name space is created in order to ensure that the same parameters can be communicated independent of the choice of the authentication method. The draft has been submitted, but before it appears in the official directories, you can access it from the following URLs: http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.txt http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.html Comments are appreciated. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 09:20:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10387 for ; Fri, 2 Apr 2004 09:20:53 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 404F7204CE; Fri, 2 Apr 2004 09:09:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9F542040D; Fri, 2 Apr 2004 09:09:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A57EF2040D for ; Fri, 2 Apr 2004 09:08:13 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D64C8202DF for ; Fri, 2 Apr 2004 09:08:11 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 550FA89946 for ; Fri, 2 Apr 2004 17:19:56 +0300 (EEST) Message-ID: <406D75EB.3040807@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" References: <405B5BD1.3030901@piuha.net> In-Reply-To: <405B5BD1.3030901@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] Re: impacts of IKEv2 early use of keying material 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, 02 Apr 2004 17:17:15 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is a summary of the discussions I have sent to the IPsec WG about this matter. --Jari ----------------------------------------------------------- This e-mail tries to summarize the discussions we had on the EAP WG mailing list and (mostly) privately between the some of the EAP state machine and methods folks. Yoshihiro, Pasi, Joe, Hannes -- feel free to add or correct as appropriate. The question was whether one roundtrip should be eliminated from IKEv2, by making it possible (but optional) to send an AUTH payload from the client as soon as the client has generated a key from EAP, and not wait until EAP Success packet has been received from the gateway. No strong opinions were presented, but the consensus we seem to have arrived at is that its simpler and better to spend the extra roundtrip than to add a protocol variation, a change of EAP state machine draft, and possibly some EAP method and API implementation changes for systems that want to take advantage of this. The following points were brought up: o Yoshihiro analyzed the potential impacts of the EAP state machine change for 802.11 wireless LANs which also use EAP. It was found that the change would NOT have an impact in 802.11, i.e., from that point of view the change is possible. o EAP in general is able to survive the loss of the EAP Success message (which is not retransmitted). o OTOH, there is a need to define "when key is available" precisely. Some EAP methods might have a key available before the endpoints have authenticated each other, for instance. EAP base specification sets requirements for EAP methods, but it does not talk about what methods definitions should say about the matter. Many methods have already been defined; this might lead to different interpretations in different implementations. o Joe brought up the possibility of EAP methods where the client does not know whether the server is yet finished; if the client would send an AUTH payload when its done the server might still have to perform roundtrips. This would have to be taken in account in the IKEv2 spec. o Number of roundtrips is a concern for many people. But Tero's and Charlie's worry about protocol variants is also a concern, as is the need to ensure that the early key availability suits the particular EAP method. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 10:42:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14619 for ; Fri, 2 Apr 2004 10:42:57 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 848C120444; Fri, 2 Apr 2004 10:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A439C2031B; Fri, 2 Apr 2004 10:31:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B854C20315 for ; Fri, 2 Apr 2004 10:30:53 -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 B5D0A20245 for ; Fri, 2 Apr 2004 10:30:51 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i32FgYgH003466; Sat, 3 Apr 2004 00:42:34 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i32FgYjX004529; Sat, 3 Apr 2004 00:42:34 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA04528 ; Sat, 3 Apr 2004 00:42:34 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA25507; Sat, 3 Apr 2004 00:42:34 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA12396; Sat, 3 Apr 2004 00:42:33 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i32FgVmr024998; Sat, 3 Apr 2004 00:42:33 +0900 (JST) Received: from steelhead (iVPN01-129.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HVJ00FK5VMQ63@tsbpo1.po.toshiba.co.jp>; Sat, 3 Apr 2004 00:42:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B9QNU-0002DP-00; Fri, 02 Apr 2004 07:14:40 -0800 From: Yoshihiro Ohba Subject: Re: [eap] draft on authenticated service identities In-reply-to: <406D630C.6080700@piuha.net> To: Jari Arkko Cc: "eap@frascone.com" , Pasi Eronen Message-id: <20040402151440.GA8480@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: <406D630C.6080700@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, 02 Apr 2004 07:14:40 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, Jari and Pasi Here is my comments on your draft: o It might be better to define Called-Station-Id and Calling-Station-Id parameters as generic device identifiers instead of defining service type dependent device identifiers. More specifically: - SSID parameter and BSSID parameter for IEEE 802.11 can be replaced with Called-Station-Id parameter. This is because RFC3580 defines RADIUS Called-Station-Id attribute as the combination of MAC address of AP and SSID in the case of IEEE 802.11, and I believe the MAC address of AP is the BSSID. - STA_MAC parameter for IEEE 802.11 can be replaced with Calling-Station-Id parameter. This is because RFC3580 defines RADIUS Calling-Station-Id attribute as the Supplicant MAC address. - PaC Device-Id and PAA Device-Id parameters for PANA can be replaced with Calling-Station-Id and Called-Station-Id parameters, respectively. - Initiator address and responder address parameters for IKEv2 can be replaced with Calling-Station-Id and Called-Station-Id parameters, respectively. o How an EAP server can learn the service type parameter from NAS? RADIUS NAS-Port-Type attribute may be used for this purpose but the NAS-Port-Type is not suitable to represent media-independent EAP transports such as PANA and IKEv2. o How an EAP server can learn protection mechanism parameters from NAS? In other words, are there any RADIUS attributes or Diameter AVPs currently defined to carry the protection mechanism parameters? o It might be better to define a mechanism to indicate which service parameter is incorrect when an error occurs, instead of just failing the authentication. The EAP-IKEv2 methods provides such a mechanism, for example. Regards, Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 11:12:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16491 for ; Fri, 2 Apr 2004 11:12:52 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5803203B7; Fri, 2 Apr 2004 11:01:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61872203E6; Fri, 2 Apr 2004 11: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 6E489203E6 for ; Fri, 2 Apr 2004 11:01:00 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 0C533203B7 for ; Fri, 2 Apr 2004 11:00:58 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 18:12:14 +0200 Received: from rd.francetelecom.fr ([10.193.167.20]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 2 Apr 2004 18:12:12 +0200 Message-ID: <406D9104.7030508@rd.francetelecom.fr> From: Florent Bersani 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: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: Re: [eap] A synthesis on the existing (shared key) EAP methods... References: <052E0C61B69C3741AFA5FE88ACC775A61223BB@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223BB@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2004 16:12:12.0511 (UTC) FILETIME=[41D5CEF0:01C418CD] 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, 02 Apr 2004 18:12:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Pasi, I agree with your remark. Although, I would rather have dictionary attack resistance (as per RFC 2284bis definition) in all EAP methods (in particular, those compliant to IEEE 802 requirements), I think that enforcing a MUST might be premature and that more discussion is needed to perhaps relax it to a SHOULD, since as you clearly point out a MUST places very strong (too strong?) requirements. See some more comments in-line. Best regards, Florent Pasi.Eronen@nokia.com wrote: >Hi, > >This document looks like a very useful summary of existing >EAP methods, thanks for taking the time to write it! > :-) >I agree with you wish to standardize a replacement for EAP-MD5. > Great, at least I have on official supporter. Others? >However, it's worth noting that the current version of >draft-walker-ieee802-req practically requires the use of >public key cryptography for this, since the "Dictionary attack >resistance" security claim MUST be supported. > >2284bis says that "A method may be said to provide protection >against dictionary attacks if, when it uses a password as a >secret, the method does not allow an offline attack that >has a work factor based on the number of passwords in an >attacker's dictionary." > Thanks for pointing this out! In fact, I find this definition a little bit problematic, since it is not that trivial to scientifically define what is meant by resistance against dictionary attacks (cf. the existing definitions available at the URL given below). One could argue that it does not make much sense as is, since it does not specify that the number of passwords in an attacker's dictionary must be essentially the *only* factor the complexity of the attack depends upon and it does not differentiate between a linear and an exponential complexity and does not speak of the best attack,... ;-) However, I bet it is however quite reasonable as everybody ought to understand what is informally meant. I also find it to be quite a tight definition since it imposes resistance to off-line attacks making no difference between for instance EAP-MSCHAPv2 and EAP-PSK, although EAP-PSK offers informally IMHO better resistance to dictionary attacks thanks first to the mapping between password and shared key provided in Annex B and second thanks to MAP (a Nonce from the client *and* a nonce from the server is included in the first MAC)... I (quickly) looked for discussions on the definition in the mailing archive and came across the following: ----------- *Original definition:* "Where password authentication is used, users are notoriously prone to selection of poor passwords. A method may be said to be dictionary attack resistant if a brute force attack would require, on average, sorting through 2^64 or more possibilities. This can be accomplished, for example, by avoiding the use of passwords altogether (e.g. certificates, token cards), or by using a shared secret with sufficiently high entropy." ----------- *Discussion on Dec 11 2002* "Bernard Aboba: Is the text on dictionary attack sufficient? Glen: Does not sound too good yet. Bernard: Even liveness doesn't prove resistance. Glen: Last part makes sense. Jari: I would just put in that the spec must describe whether you are vulnerable to dictionary attacks. Glen: There is a difference between dictionary attack to a weak password vs. a method. DECISION: The following text can be used: Assuming there is a weak password in the secret, does the method allow a an attack better than brute force? John: There is a further distinction between off-line and on-line attacks. DECISION: Let's not describe different variants of dictionary attacks, instead reference text books on the subject. ----------- *Second definition:* "Where password authentication is used, users are notoriously prone to selection of poor passwords. A method may be said to be dictionary attack resistant if, when there is a weak password in the secret, the method does not allow an attack more efficient than brute force." ----------- *Discussion by David Jablon (with Uri and Bernard)* "I see some potential confusion in the proposed EAP-04 definition for Dictionary attack protection On Monday, July 7, 2003 8:09 PM -0700 Bernard Aboba wrote: >>"7.2.1 Security claims terminology for EAP methods ... >> Dictionary attack protection >> Where password authentication is used, users are >> notoriously prone to select poor passwords. A method may >> be said to be dictionary attack resistant if, when there is >> a weak password in the secret, the method does not allow >> an attack more efficient than brute force. Here's a suggested rewording. "Where password authentication is used, passwords are commonly selected from a set that is small, as compared to a set of N-bit keys. A method may be said to be dictionary attack resistant if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary." The changes are intended to address the following concerns: -- Since dictionary attack may be regarded as a form of brute force attack, a reader might wonder how dictionary attack could ever be more efficient than brute force attack. A significant distinction can be drawn if "dictionary" more clearly refers to a work factor based on the set of password guesses rather than key size. -- Underqualified use of derogatory terms like "poor" and "weak" leads to a confusingly circular definition. The value of using a specific password depends, in part, on the characteristics of the method, one of which is being defined here. -- Users are not alone in being responsible for selecting passwords from a small set. Systems, including their developers and administrators, are "notoriously prone" to encouraging such practice too. -- There was no mention of whether the attack is offline or online. ----------- *Uri's suggestion* Here's a suggested rewording. "Where password authentication is used, commonly selected passwords are weak because they are selected from a small set (as compared to a set of N-bit keys). A method may be said to be dictionary attack resistant if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary." ----------- *David's reply* The first sentence in the above version has a problem similar to the original version. It does not make sense to characterize password quality outside the context of a specific method. How about: "Where password authentication is used, passwords are commonly selected from a small set (as compared to a set of N-bit keys), which raises the concern of dictionary attack. ..." ----------- Since, it appears that the current definition comes from David Jablon (the author of SPEKE), hence somebody much more expert in the field than I am, I won't keep on arguing uselessly, I'll go back to esoteric books and experts and see if I can do better ;-) >As far as I know, this requires either some form of public key >cryptography, or enforcing that the shared secret cannot be >chosen by the user. > This theme is really interesting and I stumbled against it while writing my synthesis and examining SRP-SHA1 and EAP-SPEKE. Since I am (not yet ;-)) familiar enough with the domain, I won't keep expanding my informal remarks (like the bad ones on the dictionary attack definition). A nice link on the matter is http://www.integritysciences.com/links.html I am in touch with cryptographers to gain more understanding and I'll try and come back to the list to give some insights. > >Using e.g. PBKDF2 from PKCS#5 is not sufficient, since the work >load is still basically the same: if the user's password is the >Nth word in the dictionary, an attacker can find it in N >operations (each operation takes slightly longer than without >PBKDF2, though). > All is in evaluating how slightly, though ;-) In some cases you can precompute with your dictionary in other you cannot, as you perfectly know Do we (for a replacement for EAP-MD5) or IEEE 802 (for the requirements on EAP methods) really want a requirement this strong on dictionary attacks... Frankly, I don't know. My conclusion in the synthesis on shared key EAP methods was to study more carefully the pros and cons between say SRP-SHA1/SPEKE and EAP-PSK. And frankly I am not that biased to have an a priori conclusion - the former methods seemed to have IPR encumbrance but I think those can be avoided and also seemed to require some heavier implementations. However I do not think that these points are really valid and as of now, I think that if we can get the same IPR freeness and performance with the former as with the latter (my answer is probably yes) then we should drop the latter :-( > >As to the second alternative, IMHO totally prohibiting user-chosen >shared secrets would reduce the usefulness of EAP-PSK (or whatever >will be chosen as successor-of-EAP-MD5). > BTW, I'll update the security claims section of EAP-PSK to indicate that it does unfortunately not provide dictionary attack resistance under the RFC 2284bis definition and the text about IEEE 802 requirements :-( > >However, I don't think this is an argument against EAP-PSK but >instead an argument for making dictionary attack resistance a >"SHOULD" instead of "MUST" in draft-walker-ieee802-req... > I tend to concur > >Best regards, >Pasi > > > >>-----Original Message----- >>From: eap-admin@frascone.com >>[mailto:eap-admin@frascone.com]On Behalf Of >>ext Florent Bersani >>Sent: Friday, April 02, 2004 12:49 PM >>To: eap@frascone.com >>Subject: [eap] A synthesis on the existing (shared key) EAP methods... >> >> >> >>...is available at this URL before it reaches the archive: >>http://eappsk.chez.tiscali.fr/draft-bersani-eap-synthesis-shar >>edkeymethods-00.txt >> >>Any comments, feedback or additional information is most welcome. >> >>Florent, who wishes that a standard replacement for EAP-MD5 >>be drafted (not especially EAP-PSK which is only a proposal >>to stimulate the community ;-)) >> >>P.S : (Abstract of the draft) The purpose of this draft is to >>gives a broad picture of the existing proposed EAP methods, >>with a focus on shared key EAP methods. Indeed, it is the >>belief of the author that a standard replacement for EAP-MD5 >>(that is deprecated due to security reasons) is needed. By >>listing the existing shared key EAP methods, the goal is to >>gather consensus that such a multiplication of methods is >>detrimental and that a single method retaining the best of >>the existing proposals could and should be drafted. >> >> > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 2 11:40:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17418 for ; Fri, 2 Apr 2004 11:40:52 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0DE4B203E6; Fri, 2 Apr 2004 11:29:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8310B203F4; Fri, 2 Apr 2004 11:29:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94F36203E6 for ; Fri, 2 Apr 2004 11:28:05 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id CBDD02038D for ; Fri, 2 Apr 2004 11:28:03 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0544F89961; Fri, 2 Apr 2004 19:39:48 +0300 (EEST) Message-ID: <406D96B3.5010000@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" , Pasi Eronen Subject: Re: [eap] draft on authenticated service identities References: <406D630C.6080700@piuha.net> <20040402151440.GA8480@steelhead> In-Reply-To: <20040402151440.GA8480@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, 02 Apr 2004 19:37:07 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > Here is my comments on your draft: Thanks for taking a look! > o It might be better to define Called-Station-Id and > Calling-Station-Id parameters as generic device identifiers instead of > defining service type dependent device identifiers. More specifically: > > - SSID parameter and BSSID parameter for IEEE 802.11 can be > replaced with Called-Station-Id parameter. This is because RFC3580 > defines RADIUS Called-Station-Id attribute as the combination of > MAC address of AP and SSID in the case of IEEE 802.11, and I > believe the MAC address of AP is the BSSID. > > - STA_MAC parameter for IEEE 802.11 can be replaced with > Calling-Station-Id parameter. This is because RFC3580 defines > RADIUS Calling-Station-Id attribute as the Supplicant MAC address. > > - PaC Device-Id and PAA Device-Id parameters for PANA can be > replaced with Calling-Station-Id and Called-Station-Id parameters, > respectively. > > - Initiator address and responder address parameters for IKEv2 can > be replaced with Calling-Station-Id and Called-Station-Id > parameters, respectively. Yes. I also thought about this a bit while working on the draft, but did not do anything about it yet. I should say that the initial set of parameters is very rough, I'm sure more discussion is needed on it. > o How an EAP server can learn the service type parameter from NAS? > RADIUS NAS-Port-Type attribute may be used for this purpose but the > NAS-Port-Type is not suitable to represent media-independent EAP > transports such as PANA and IKEv2. A general issue in the -00 draft is that it does not really define the required mapping from the parameters to the AAA attributes. I agree that there needs to be a way to determine which service type was provided. In general, I suspect we can do this only partially with current AAA attribute sets, and some ones may be needed. > o How an EAP server can learn protection mechanism parameters from > NAS? In other words, are there any RADIUS attributes or Diameter AVPs > currently defined to carry the protection mechanism parameters? See above. There aren't any such attributes to my knowledge. These may have to be defined. > o It might be better to define a mechanism to indicate which service > parameter is incorrect when an error occurs, instead of just failing > the authentication. The EAP-IKEv2 methods provides such a mechanism, > for example. Sounds like a good suggestion, particularly in the view of incomplete information that may be transferred over AAA. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ritsyydreqd@grassisales.com Fri Apr 2 15:40:09 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 PAA27756 for ; Fri, 2 Apr 2004 15:40:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9VSU-0003SJ-00 for eap-archive@ietf.org; Fri, 02 Apr 2004 15:40:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VRf-0003LX-00 for eap-archive@ietf.org; Fri, 02 Apr 2004 15:39:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9VRJ-0003E0-00 for eap-archive@ietf.org; Fri, 02 Apr 2004 15:38:57 -0500 Received: from [200.181.30.205] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B9VRI-0006Ni-Ac for eap-archive@ietf.org; Fri, 02 Apr 2004 15:38:57 -0500 Received: from 108.128.120.150 by 200.181.30.205; Fri, 02 Apr 2004 15:35:26 -0500 Message-ID: From: "Neil Jordan" Reply-To: "Neil Jordan" To: eap-archive@ietf.org Subject: Get Your Prescription Drugs now online! With No Prescription. Discreet. Secure. Date: Fri, 02 Apr 2004 15:31:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5673929342832385" X-IP: 180.202.136.94 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.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 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.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----5673929342832385 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

CheapestMeds - your Source for best prices Prescription Drugs.

Absolutely No Doctor Appointment Needed!

Orders approved by 2 pm EST will receive their medication next business day via FedEX! (where available)

Connect with the Source. Get it Here

Jdemijohn heckle homeward fermion amass schizophrenic along stockholder bourbaki swag chianti . Fweed alumina stork kirchner clinician super alder pygmy brought kline cedric report guildhall stab eluate cinderella everhart ascent hydrocarbon itinerant colloq ? Qdeus aggrieve cede cynthia morel beneficiary covary behest doubleheader skittle aeneid casteth diversify demagnify ternary standstill transportation belgium wei bowel loess arduous harold echinoderm obnoxious disaccharide be iodine aztec basal cordite barbecue lineman scuba detente diverge Ppostcard endpoint etc diamagnetism wingman sus intact mormon angelo . Rmanipulate homebuild satellite toothpaste bachelor bacilli renegotiable muskoxen dung haughty aarhus differential nationhood underling wayward employing adore fermat mutual . Fpakistani corrosive pasture influenza downgrade flaky damage almanac mayflower semaphore sacrificial hadley excitation genuine exclusion epoch prime remedial brainard maestro portico claimant dwindle claw Mplayful finland peculiar bertie aspheric cattlemen agony mesoderm darry prohibitive dispersion hollandaise bondsman medea suction exist syntactic enter denigrate !! Kcandlewick tananarive diagnose vestige amphibious aqua jukes allergic ca eben epiphysis pancreatic pluggable spectral cripple sludge appleby prescott bestir trenton mackerel pose metabolism wing donna camel objectivity periclean . Frang dreadful mathematik saturater gerontology durham sage xavier hippopotamus oligarchic twaddle cellular buddhism armament circulatory corey phenomenology lycopodium thick mccarthy curricular mailmen governance cerebellum vying hoofmark crate gunther piecemeal assist fluorocarbon stuff deputy .Lrevertive diatomaceous coroner stay bakhtiari inaptitude snuffle griffin ! Yutility ivanhoe nationwide cowman britten recipe handymen predictor himalaya algorithm mulligatawny headwall whirl adenine teethe mcnaughton bernie system toroidal blackbody metro : Emarionette adsorb ellipsoidal d eclaratory giant artistry cargill blockhouse cleanse conjecture sob Iachieve rattle permutation fantasist pliocene prosperous mauritius purport acrobatic : Vnyquist skyjack squatted razor ramify soffit . Qbelmont plebian arm conciliate askance profession neuronal thematic hearse touchdown bestir hardware destroy pinkish broken none accede municipal activism chest lithology quilt whatsoever smithson autonomy alphonse prophesy effie idyllic bogus allentown inappropriate prolegomena manganese .

If this notice has reached you in error, please notify us by clicking here ----5673929342832385-- From sevbzxfhefwmk@mailreader.com Sat Apr 3 08:36: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 IAA20215 for ; Sat, 3 Apr 2004 08:36:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lKG-0005xn-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 08:36:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9lJK-0005rH-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 08:35:46 -0500 Received: from [221.139.76.208] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B9lIl-0005lU-00; Sat, 03 Apr 2004 08:35:11 -0500 From: "Milford Petty" To: Subject: Fwd: Meds and Pills prescribed online and shipped to you discreetly overnight Date: Sat, 03 Apr 2004 19:36:42 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--95891102237455787" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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=11.6 required=5.0 tests=BIZ_TLD,FORGED_MUA_OIMO, FORGED_OUTLOOK_TAGS,HTML_50_60,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 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.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.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 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_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO ----95891102237455787 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

we make it easier and faster than ever to get the medications you need!

Cialis, Phentermine, Viagra, Soma, Ambien, Levitra, Floricet, Imitrex, Paxil, Prozac, Zoloft, and many many more prescription drugs!

Order by 2 pm EST and you get your meds tomorrow.

Start Ordering your Medications Here

Mmalawi partial devotion deplete imperfect purpose quackery brasilia piddle ingenuity ruination delinquent covary adagio colloquial clannish filamentary !! Hpatrimonial paratroop appellate argonaut induce diplomatic london mycobacteria lookup inexpert aghast apices cinema ebony razor colony ingenuity officeholder petersen overt seattle quintic exasperate !!! Rencomia toledo beatrice confiscable navel sheldon wasserman prophetic constituent anemone congenital bloodshot immanent bestow colonel stylites keddah glint lacunae sana scoreboard franchise mac cuff crane echoes orifice alkane infinite apices .

If this notice has reached you in error, please notify us by clicking here ----95891102237455787-- From axpnvoewdr@hotmail.com Sat Apr 3 10:07:54 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 KAA23051 for ; Sat, 3 Apr 2004 10:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9mkV-0001SE-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 10:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9mjb-0001LY-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 10:07:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9mjJ-0001EZ-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 10:06:41 -0500 Received: from c-67-173-75-21.client.comcast.net ([67.173.75.21]) by mx2.foretec.com with smtp (Exim 4.24) id 1B9mjK-0003CY-D6 for eap-archive@ietf.org; Sat, 03 Apr 2004 10:06:42 -0500 Received: from 30.248.42.83 by 67.173.75.21; Sat, 03 Apr 2004 13:58:42 -0100 Message-ID: From: "Connie Childers" Reply-To: "Connie Childers" To: eap-archive@ietf.org Subject: Phentermine, Viagra & More - Your Online Pharmacy Date: Sat, 03 Apr 2004 09:57:42 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--118271816984173234" 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.1 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,ONLINE_PHARMACY,SUBJ_VIAGRA,VIAGRA_ONLINE autolearn=no version=2.60 X-Spam-Report: * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 1.1 VIAGRA_ONLINE BODY: Fast Viagra Delivery * 0.0 HTML_MESSAGE BODY: HTML included in message * 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_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----118271816984173234 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



If the message is n ot loading try this


Ngeoffrey beecham arboretum rutabaga leeds exorcism warplane liturgy p= erdition bone caddis costello cup anthony fahey=20'Pgranola nude doubloon = anselmo burton nostril countywide desperate anywhere chordata ellis carbon= ic dowel=20,Cadjectival d's cycad cadet buttonhole peasanthood deer eve bi= gelow=20.Uenter commensurable plywood bark o'shea client nicaragua interpo= latory armadillo mention bruit lifeguard chimney acquitting bureaucrat sub= versive=20!Knecropsy expend messy gibbon gregg bale supposable quintillion= tipsy=20!Lbuckle oregon wineskin cafeteria beverage venezuela applique mo= ck rather gunflint biddy nightgown fieldwork blackman proteolytic=20,Earme= nian debunk accusation reason sanatorium mutual regalia hodges connie glob= ule hydrochloric=20,Chorror corrigible spice attire pbs bicker electro jit= terbug combatted kiva vacant cavern rung zigging=20.Csiesta confidential p= resence creaky remitting charlie deride balzac badland duplicity tva quadr= ennial infight syntactic burg desultory=20.Squarrymen olaf sport budd vale= dictory incise ear epilogue worshipful abelian berth storyboard beowulf ac= idic case hereafter whelm quickie digress eisenhower hetman spooky swanson= sunk accidental contextual supply sundry vicar wills=20.Icitrus incommuni= cable cummins lousewort skittle bullfrog indignation defocus sunfish boatl= oad kate mandatory defend istvan billion toenail extinguish eerie kodachro= me golly circumlocution=20;Hnumismatist athenian fox imbibe soffit logarit= hmic booth villainous ferromagnetic gaudy tracy silicone sixteen gretchen = threshold chartreuse nazarene desirous honorarium arpa cannot brood dehydr= ate teleprinter lawgiver bassett=20.Ufermat octagonal inculcate crewcut ja= nissary croatia crusoe stressful calendar insurgent recife circumspect clo= ddish nugatory hugging checkup einsteinium scrupulous emasculate=20'Tdada = cliff amos shelve pitt breakaway carve corn histology nervous questionnair= e scotsman callisto betrayal clod carbondale freshman jilt asinine dachshu= nd contraceptive=20?Yoligarchy earsplitting hillel ecole coeducation arbit= er throne contusion demand complementary synopses derogate glance puppet=20= Vbutternut elude advice shareholder crossword violate box meteorology dio= phantine fish introduce stirrup vaunt anthology spout beaten beside congea= l doherty kensington=20;Mburley down divalent delirium cytosine burundi in= terdict penurious changeable doug tidbit kyle famous hashish crisis resple= ndent=20?Wsolidarity suzanne puppet spook burnout approximate expect cresc= ent whatley swiss affectate invade=20;Dvernon astigmatism bulrush chit int= elligent staunch article chipmunk slash carouse improve bituminous curio c= orvus descent secular midday endoderm zeta been bloodroot dust abalone ber= net iodine respond=20, Qsplint springtime berkshire darpa branch concurren= t baroness differentiate diathermy sincere adriatic caramel arsine blackfe= et carboy ford mumford dora cruelty usurious hothead inactive=20.Nsumatra = polaris scheme nostrand westinghouse ratio stimulatory clang endoderm feat= herbed barn prepare startup width karl vesper aesthetic spiky annals=20!Jo= bliterate pliant parkish knutsen approbation aries graph impinge ellis lod= estone swanky serious=20!Dwatt cruddy enormity punic strip curate irresist= ible dump amphibious lose carbide strove nolo rancho pageantry yardstick f= leabane janeiro correspond coke hyperbola deregulate covalent flee storybo= ard anita parabola=20.Edidactic wonderful detention karma congo duty fluen= t decimal gate discrete hebe fantastic cesium hilum trespass gladstone atr= opos manumission downside continual footmen sawyer bodleian=20.

----118271816984173234-- From stuugpock@latinmail.com Sat Apr 3 16:17:21 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 QAA04969 for ; Sat, 3 Apr 2004 16:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9sW2-0005fG-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 16:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9sV7-0005Vk-00 for eap-archive@ietf.org; Sat, 03 Apr 2004 16:16:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9sUY-0005ME-00; Sat, 03 Apr 2004 16:15:50 -0500 Received: from [200.206.216.22] (helo=200-206-216-22.speedyterra.com.br) by mx2.foretec.com with smtp (Exim 4.24) id 1B9sUY-0003vN-KT; Sat, 03 Apr 2004 16:15:51 -0500 From: "Reid Odom" To: Subject: Fwd: Get All Meds. Any Meds You Want Prescriptions Written and Filled Online. Date: Sun, 04 Apr 2004 03:13:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--188722379476935620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: MIME-tools 5.503 (Entity 5.501) Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=5.0 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_LINK_CLICK_HERE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 ----188722379476935620 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

improving the quality of people's lives is what Prescription Medications are designed to do and CheapestMeds believes that you deserve access to these medications. By having doctors available to review your needs, CheapestMeds is ready to help you get the treatment you need.

Make it easy for you to order meds. Click here.

Waudacity millions chunk tehran blackbody roil alberta bergland digitalis congratulatory ; Oclay tragedian concussion buddhism horehound bahrein baldpate tuskegee cameo daytime coffin hue kick pornographer hieronymus amperage venomous dodecahedron lager protuberant pickman ahmedabad sacred hebraic ? Bfreedmen discriminant decelerate dovekie bosonic consecutive contradictory harvard regalia cliche springy oracle crocodile episcopate terpsichorean benz joaquin nw combatant postorder dalhousie congregate anyhow blast administrate diffuse debugging hanna centrifuge dire rubble applicate tendency mollify surtax moore angular oneself ball hydra moraine transferred neuroanatomic drag chevron chocolate exposure bulletin berserk bounce farewell physiotherapist constructible mavis leonardo electrophoresis lind ban desist yeats bonnet .Jpeugeot joanne dispelled contraption agnes !! Vpegboard deposition loquat populace tendency matriarch exemplify automorphism lowell cashmere fondle wayward trade bellow . Bastoria as duke throw bazaar hunt dehumidify crawl eeoc desecrater cosmopolitan thirteen mcnulty rusk bleary annul appendices larkin ganges clausius coronado propos otto avery condemnatory appeal destiny exult

If this notice has reached you in error, please notify us by clicking here ----188722379476935620-- From eap-admin@frascone.com Sat Apr 3 18:39:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11423 for ; Sat, 3 Apr 2004 18:39:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F519205E3; Sat, 3 Apr 2004 18:27:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2098D1FF93; Sat, 3 Apr 2004 18:27:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7F671FF93 for ; Sat, 3 Apr 2004 18:26: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 A5FE41FF6B for ; Sat, 3 Apr 2004 18:25:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i33NjEF04112 for ; Sat, 3 Apr 2004 15:45:14 -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 235: (Key Framework) Rewrite of Section 1 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, 3 Apr 2004 15:45:13 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 235: Rewrite of Section 1 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 4/3/2004 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02.txt Document: Keying-01 Comment type: T/E Priority: S Section: 1 Rationale/Explanation of issue: I've gone and rewritten Section 1 of the Key Framework document in order to improve the organization and readability. Replace Section 1 with the following: "1. Introduction The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the IP protocol is not available. Originally developed for use with PPP [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE8021X]. This document provides a framework for the generation, transport and usage of keying material generated by EAP authentication algorithms, known as "methods". Since in EAP keying material is generated by EAP methods, transported by AAA protocols, transformed into session keys by Secure Association Protocols and used by lower layer ciphersuites, it is necessary to describe each of these elements and provide a system-level security analysis. 1.1. Requirements Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: 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]. In this document, this end of the link is called the peer. 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]. AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- eap]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably. 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. 1.3. Overview EAP is typically deployed in order to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. The situation is illustrated in Figure 1 below. Since both the peer and authenticator may have more than one physical or logical port, a given peer may simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator may offer network access to multiple peers, each via a separate physical or logical port. The peer may be stationary, in which case it may establish communications with one or more authenticators while remaining in one location. Alternatively, the peer may be mobile, changing its point of attachment from one authenticator to another, or moving between points of attachment on a single authenticator. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator must locally implement an EAP method acceptable to the peer. However, one of the advantages of EAP is that it enables deployment of new authentication methods without requiring development of new code on the authenticator. While the authenticator may implement some EAP methods locally and use those methods to authenticate local users, it may at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization and Accounting (AAA) protocol, spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-eap]. +-+-+-+-+ | | | EAP | | Peer | | | +-+-+-+-+ | | | Peer Ports / | \ / | \ Phase 0: Discovery / | \ Phase 1: Authentication / | \ Phase 2: Secure / | \ Association / | \ / | \ / | \ | | | | | | | | | Authenticator Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth. | | Auth. | | Auth. | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | / \ | / \ | / EAP over AAA \ | / (optional) \ | / \ | / \ | / \ | / +-+-+-+-+ | | | AAA | |Server | | | +-+-+-+-+ Figure 1: Relationship between peer, authenticator and backend server Where EAP key derivation is supported, the conversation between the peer and the authenticator typically takes place in three phases: Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA-Key Transport (optional) Phase 2: Secure Association Establishment 2a: Unicast Secure Association 2b: Multicast Secure Association (optional) In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. For example, a peer may locate an authenticator providing access to a particular network, or a peer may locate an authenticator behind a bridge with which it desires to establish a Secure Association. The authentication phase (phase 1) may begin once the peer and authenticator discover each other. This phase always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a keying material is derived on both the peer and the EAP server. This keying material may be used for multiple purposes, including protection of the EAP conversation and subsequent data exchanges. An additional step (phase 1b) is required in deployments which include a backend authentication server, in order to transport keying material (known as the AAA-Key) from the backend authentication server to the authenticator. A Secure Association exchange (phase 2) then occurs between the peer and authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between the peer and authenticator. The conversation phases and relationship between the parties is shown below in Figure 2. EAP peer Authenticator Auth. Server -------- ------------- ------------ |<----------------------------->| | | Discovery (phase 0) | | |<----------------------------->|<----------------------------->| | EAP auth (phase 1a) | AAA pass-through (optional) | | | | | |<----------------------------->| | | AAA-Key transport | | | (optional; phase 1b) | |<----------------------------->| | | Unicast Secure association | | | (phase 2a) | | | | | |<----------------------------->| | | Multicast Secure association | | | (optional; phase 2b) | | | | | Figure 2: Conversation Overview 1.3.1. Discovery Phase In the discovery phase (phase 0), the EAP peer and authenticator locate each other and discover each other's capabilities. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs. For example, where EAP runs over PPP, the EAP peer might be configured with a phone book providing phone numbers of authenticators and associated capabilities such as supported rates, authentication protocols or ciphersuites. In contrast, PPPoE [RFC2516] provides support for a Discovery Stage to allow a peer to identify the Ethernet MAC address of one or more authenticators and establish a PPPoE SESSION_ID. IEEE 802.11 [IEEE80211] also provides integrated discovery support utilizing Beacon and/or Probe Request/Response frames, allowing the peer (known as the station or STA) to determine the MAC address and capabilities of one or more authenticators (known as Access Point or APs). Since discovery is handled outside of EAP, there is no need to provide this functionality within EAP. 1.3.2. Authentication Phase Once the peer and authenticator discover each other, they exchange EAP packets. Typically, the peer desires access to the network, and the authenticators provide that access. In such a situation, access to the network can be provided by any authenticator attaching to the desired network, and the EAP peer is typically willing to send data traffic through any authenticator that can demonstrate that it is authorized to provide access to the desired network. An EAP authenticator may handle the authentication locally, or it may act as a pass-through to a backend authentication server. In the latter case the EAP exchange occurs between the EAP peer and a backend authenticator server, with the authenticator forwarding EAP packets between the two. The entity which terminates EAP authentication with the peer is known as the EAP server. Where pass- through is supported, the backend authentication server functions as the EAP server; where authentication occurs locally, the EAP server is the authenticator. Where a backend authentication server is present, at the successful completion of an authentication exchange, the AAA-Key is transported to the authenticator (phase 1b). EAP may also be used when it is desired for two network devices (e.g. two switches or routers) to authenticate each other, or where two peers desire to authenticate each other and set up a secure association suitable for protecting data traffic. Some EAP methods exist which only support one-way authentication; however, EAP methods deriving keys are required to support mutual authentication. In either case, it can be assumed that the parties do not utilize the link to exchange data traffic unless their authentication requirements have been met. For example, a peer completing mutual authentication with an EAP server will not send data traffic over the link until the EAP server has authenticated successfully to the peer, and a Secure Association has been negotiated. Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. Successful completion of EAP authentication and key derivation by a peer and EAP server does not necessarily imply that the peer is committed to joining the network associated with an EAP server. Rather, this commitment is implied by the creation of a security association between the EAP peer and authenticator, as part of the Secure Association Protocol (phase 2). As a result, EAP may be used for "pre-authentication" in situations where it is necessary to pre- establish EAP security associations in order to decrease handoff or roaming latency. 1.3.3. Secure Association Phase The Secure Association phase (phase 2) always occurs after the completion of EAP authentication (phase 1a) and key transport (phase 1b), and typically supports the following features: [1] Secure capabilties negotiation. This provides for the secure negotiation of usage modes, session parameters, ciphersuites, and required filters, including confirmation of the capabilities discovered during phase 0. By securely negotiating session parameters, the secure Association Protocol protects against spoofing during the discovery phase and ensures that the peer and authenticator are in agreement about how data is to be secured. [2] Generation of fresh transient session keys (TSKs). The Secure Association Protocol typically guarantees the freshness of session keys by exchanging nonces and then mixing the nonces with the AAA- Key in order to generate fresh unicast (phase 2a) and multicast (phase 2b) session keys. By not using the AAA-Key directly to protect data, the secure Association Protocol protects against compromise of the AAA-Key, and by guaranteeing the freshness of transient session keys, assures that they are not reused. [3] Key activation and deletion. In order for the peer and authenticator to communicate securely, it is necessary for both sides to derive the same session keys, and remain in sync with respect to key state going forward. One of the functions of the Secure Association Protocol is to synchronize the activation and deletion of keys so as to enable seamless rekey, or recovery from partial or complete loss of key state by the peer or authenticator. [4] Mutual proof of possession of the AAA-Key. This demonstrates that both the peer and authenticator have been authenticated and authorized by the backend authentication server. Since mutual proof of possession is not the same as mutual authentication, the peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange. 1.4. EAP Invariants By utilizing a three phase exchange, the EAP key management framework guarantees that certain basic characteristics, known as the "EAP Invariants" hold true for all implementations of EAP. These include: Media independence Method independence Ciphersuite independence 1.4.1. Media Independence One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 802.11 wireless LANs [IEEE80211i]. In order to maintain media independence, it is necessary for EAP to avoid inclusion of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transproted, and cannot utilize identifiers associated with a particular usage environment (e.g. MAC addresses). The need for media independence has also motivated the development of the three phase exchange. Since discovery is typically media- specific, this function is handled outside of EAP, rather than being incorporated within it. Similarly, the Secure Association Protocol often contains media dependencies such as negotiation of media- specific ciphersuites or session parameters, and as a result this functionality also cannot be incorporated within EAP. 1.4.2. Method Independence By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid implementing code for each EAP method required by peers. In fact, since a pass-through authenticator is not required to implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code. As a result, as noted in [RFC3748], authenticators must by default be capable of supporting any EAP method. Since the Discovery and Secure Association exchanges are also method independent, an authenticator can carry out the three phase exchange without having an EAP method in common with the peer. This is useful where there is no single EAP method that is both mandatory-to-implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication or key derivation, and as a result is not appropriate for use in wireless LAN authentication [WLANREQ]. However, despite this it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported on the EAP server. 1.4.3. Ciphersuite Independence While EAP methods may negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of data is negotiated within the Secure Association Protocol, out-of-band of EAP. The backend authentication server is not a party to this negotiation nor is it an intermediary in the data flow between the EAP peer and authenticator. The backend authentication server may not even have knowledge of the ciphersuites implemented by the peer and authenticator, or be aware of the ciphersuite negotiated between them, and therefore does not implement ciphersuite-specific code. Since ciphersuite negotiation occurs in the Secure Association protocol, not in EAP, ciphersuite-specific key generation, if implemented within an EAP method, would potentially conflict with the transient session key derivation occurring in the Secure Association protocol. As a result, EAP methods generate keying material that is ciphersuite-independent. Additional advantages of ciphersuite-independence include: Update requirements If EAP methods were to specify how to derive transient session keys for each ciphersuite, they would need to be updated each time a new ciphersuite is developed. In addition, backend authentication servers might not be usable with all EAP-capable authenticators, since the backend authentication server would also need to be updated each time support for a new ciphersuite is added to the authenticator. EAP method complexity Requiring each EAP method to include ciphersuite-specific code for transient session key derivation would increase method complexity and result in duplicated effort. Knowledge of capabilities In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator, since this negotiation typically occurs within the Secure Association Protocol. For example, PPP ciphersuite negotiation occurs in the Encryption Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation, the peer, authenticator and backend authentication server may not be able to anticipate the negotiated ciphersuite and therefore this information cannot be provided to the EAP method. Since ciphersuite negotiation is assumed to occur out-of-band, there is no need for ciphersuite negotiation within EAP. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Apr 3 18:48:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11745 for ; Sat, 3 Apr 2004 18:48:54 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8FE81FF93; Sat, 3 Apr 2004 18:37:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E571205E3; Sat, 3 Apr 2004 18: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 7BB46205E3 for ; Sat, 3 Apr 2004 18:36:21 -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 890411FF93 for ; Sat, 3 Apr 2004 18:36:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i33NtXD04662 for ; Sat, 3 Apr 2004 15:55:33 -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 236: (Key Framework) Rewrite of Section 2 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, 3 Apr 2004 15:55:33 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 236: Rewrite of Section 2 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 4/3/2004 Reference: Document: Keying-01 Comment type: T/E Priority: S Section: 2 Rationale/Explanation of issue: I've gone and rewritten Section 2 to improve the organization and readability. Change Section 2 to the following: "2. EAP Key Hierarchy 2.1. Key Terminology The EAP Key Hierarchy makes use of the following types of keys: 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. Extended Master Session Key (EMSK) Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length, and is never shared with a third party. AAA-Key A key derived by the peer and EAP server, used by the peer and authenticator in the derivation of Transient Session Keys (TSKs). Where a backend authentication server is present, the AAA-Key is transported from the backend authentication server to the authenticator, wrapped within the AAA-Token; it is therefore known by the peer, authenticator and backend authentication server. However, despite the name, the AAA-Key is computed regardless of whether a backend authentication server is present. AAA-Key derivation is discussed in Appendix E; in existing implementations the MSK is used as the AAA-Key. AAA-Token Where a backend server is present, the AAA-Key and one or more attributes is transported between the backend authentication server and the authenticator within a package known as the AAA-Token. The format and wrapping of the AAA-Token, which is intended to be accessible only to the backend authentication server and authenticator, is defined by the AAA protocol. Examples include RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP- TLS [RFC2716], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. However, when it is generated it MUST be unpredictable. Pairwise Master Key (PMK) The AAA-Key is divided into two halves, the "Peer to Authenticator Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key) (reception is defined from the point of view of the authenticator). Within [IEEE80211i] Octets 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives its TSKs from both halves of the AAA-Key. Transient EAP Keys (TEKs) Session keys which are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator. An example TEK key hierarchy is described in Appendix C. Transient Session Keys (TSKs) Session keys used to protect data which are appropriate for the ciphersuite negotiated between the EAP peer and authenticator. The TSKs are derived from AAA-Key during the Secure Association Protocol. In the case of [IEEE80211i] the Secure Association Protocol consists of the 4-way handshake and group key derivation. An example TSK derivation is provided in Appendix D. 2.2. Key Hierarchy The EAP Key Hierarchy, illustrated in Figure 3 below, includes three types of keys: [1] Keys calculated locally by the EAP method but not exported, such as the TEKs. [2] Keys exported by the EAP method: MSK, EMSK, IV and keys calculated from exported quantities: AAA-Key. [3] Keys calculated by the Secure Association Protocol: TSKs. In order to protect some or all of the EAP conversation, EAP methods supporting key derivation typically negotiate a ciphersuite and derive Transient EAP Keys (TEKs) to provide keys for that ciphersuite. However, the TEKs are stored locally within the EAP method and are not exported. As noted in [RFC3748] Section 7.10, EAP methods generating keys are required to calculate and export the MSK and EMSK, which must be at least 64 octets in length. EAP methods also may export the IV; however, the use of the IV is deprecated. On both the peer and EAP server, the exported MSK and EMSK are utilized in order to calculate the AAA-Key. Where a backend authentication server is present, the AAA-Key is transported from the backend authentication server to the authenticator within the AAA- Token, using the AAA protocol. Once EAP authentication completes and is successful, the peer and authenticator obtain the AAA-Key and the Secure Association Protocol is run between the peer and authenticator in order to securely negotiate the ciphersuite, derive fresh TSKs used to protect data, and provide mutual proof of possession of the AAA-Key. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | EAP Method | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | EAP Method Key | | | | | Derivation | | | | | | | Local to | | | | | EAP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | | | | | | | | | | | | | | | | | | | V | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | TEK | | MSK | |EMSK | |IV | | | | |Derivation | |Derivation | |Derivation | |Derivation | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | | | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | ^ | | | | | MSK (64B) | EMSK (64B) | IV (64B) | | | | Exported| | | | by | V V V EAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| | AAA Key Derivation, | | Known | | | Naming & Binding | |(Not Secret) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V | ---+ | Transported | | AAA-Key by AAA | | Protocol | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | TSK | Ciphersuite | | Derivation | Specific | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ Figure 3: EAP Key Hierarchy When the authenticator acts as an endpoint of the EAP conversation rather than a pass-through, EAP methods are implemented on the authenticator as well as the peer. If the EAP method negotiated between the EAP peer and authenticator supports mutual authentication and key derivation, the EAP Master Session Key (MSK) and Extended Master Session Key (EMSK) are derived on the EAP peer and authenticator and exported by the EAP method. In this case, the MSK and EMSK are known only to the peer and authenticator and no other parties. The TEKs and TSKs also reside solely on the peer and authenticator. This is illustrated in Figure 4. As demonstrated in [I-D.ietf-roamops-cert], in this case it is still possible to support roaming between providers, using certificate-based authentication. Where a backend authentication server is utilized, the situation is illustrated in Figure 5. Here the authenticator acts as a pass- through between the EAP peer and a backend authentication server. In this model, the authenticator delegates the access control decision to the backend authentication server, which acts as a Key Distribution Center (KDC). In this case, the authenticator encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the backend authentication server, which acts as the EAP server. Since the authenticator acts as a pass-through, EAP methods reside only on the peer and EAP server As a result, the TEKs, MSK and EMSK are derived on the peer and EAP server. On completion of EAP authentication, EAP methods on the peer and EAP server export the Master Session Key (MSK) and Extended Master Session Key (EMSK). The peer and EAP server then calculate the AAA- Key from the MSK and EMSK, and the backend authentication server sends an Access-Accept to the authenticator, providing the AAA-Key within a protected package known as the AAA-Token. The AAA-Key is then used by the peer and authenticator within the Secure Association Protocol to derive Transient Session Keys (TSKs) required for the negotiated ciphersuite. The TSKs are known only to the peer and authenticator. +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |===============| | | |EAP, TEK Deriv.|Authenti-| | |<------------->| cator | | | | | | | Secure Assoc. | | | peer |<------------->| (EAP | | |===============| server) | | | Link layer | | | | (PPP,IEEE802) | | | | | | |MSK,EMSK | |MSK,EMSK | | AAA-Key | | AAA-Key | | (TSKs) | | (TSKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 4: Relationship between EAP peer and authenticator (acting as an EAP server), where no backend authentication server is present. +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | |===============| |========| | | |EAP, TEK Deriv.| | | | | |<-------------------------------->| backend | | | | | | | | | Secure Assoc. | | AAA-Key| | | peer |<------------->|Authenti-|<-------| auth | | |===============| cator |========| server | | | Link Layer | | AAA | (EAP | | | (PPP,IEEE 802)| |Protocol| server) | | | | | | | |MSK,EMSK | | AAA-Key | |MSK,EMSK,| | (TSKs) | | (TSKs) | | AAA-Key | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 5: Pass-through relationship between EAP peer, authenticator and backend authentication server. 2.3. Requirements for EMSK Usage EAP reserves a portion of keying material, called the EMSK, for extended uses. Keys derived from this key material may be used to key applications on different devices and different processes separate from the entity that receives the MSK. If the keying material is used to provide keys for multiple Applications or devices, it is desired that the keys will be cryptographically separate. Cryptographic separation means that knowledge of one key does not provide an easy way to determine another key derived from the same key material. This is also known as computationally independent. This section provides guidelines for a mechanism which can be used with existing and new EAP methods and applications to provide cryptographic separation between keys derived for different applications and devices. These derived keys are referred to in this section as Application Master Session Keys or AMSK. The EAP EMSK usage guidelines provide a means for generating multiple application-specific master keys (AMSKs). These AMSKs are then used to derive transient session keys (TSKs), which are used as actual ciphering keys. This allows multiple applications to use keys independently derived from the EAP method. AMSK Key Derivation is discussed in Appendix F." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Apr 3 19:32:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13213 for ; Sat, 3 Apr 2004 19:32:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D72BE205F4; Sat, 3 Apr 2004 19:21:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 803C8205EA; Sat, 3 Apr 2004 19: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 1C5C8205EA for ; Sat, 3 Apr 2004 19:20: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 A13A5202B9 for ; Sat, 3 Apr 2004 19:20:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i340djR07351 for ; Sat, 3 Apr 2004 16:39:45 -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 237: (Key Framework) Reference 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: Sat, 3 Apr 2004 16:39:45 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 237: Reference cleanup Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 4/3/2004 Reference: Document: Keying-01 Comment type: E Priority: S Section: 7 Rationale/Explanation of issue: I've gone and cleaned up Section 7 (References). Change Section 7 to: "7. References 7.1. Normative References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3748] Blunk, L., "Extensible Authentication Protocol (EAP)", RFC 3748, April 2004. [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture", ANSI/IEEE Standard 802, 1990. 7.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol", RFC 3078, March 2001. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [FIPSDES] National Institute of Standards and Technology, "Data Encryption Standard", FIPS PUB 46, January 1977. [DESMODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS PUB 81, December 1980, . [FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001. [FIPS.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, . [IEEE80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE IEEE Standard 802.11-1999, 1999. [IEEE8021X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, September 2004. [IEEE8021Q] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks", IEEE Standard 802.1Q/D8, January 1998. [IEEE80211F] Institute of Electrical and Electronics Engineers, "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, July 2003. [IEEE80211i] Institute of Electrical and Electronics Engineers, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE Draft 802.11I/ D8, February 2004. [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Caching Strategies for IAPP Latency Improvement during 802.11 Handoff", IEEE 802.11 Working Group, IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, January 2003. [IEEE-03-155] Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, IEEE-03-155r0-I, http://www.ieee802.org/11/ Documents/DocumentHolder/3-155.zip, March 2003. [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/eap/eapport_0fj9.asp, August 2000. [I-D.ietf-roamops-cert] Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- cert-02 (work in progress), April 1999. [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa- eap-03 (work in progress), October 2003. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), October 2003. [I-D.orman-public-key-lengths] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", draft-orman-public- key-lengths-05 (work in progress), January 2002. [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003. [I-D.aboba-802-context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-03 (work in progress), October 2003. [I-D.arkko-pppext-eap-aka] Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- arkko-pppext-eap-aka-11 (work in progress), October 2003. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- ietf-ipsec-ikev2-12 (work in progress), March 2004. [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1X Model", School of Computer Science and Engineering, Seoul National University, Seoul, Korea, 2002. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol.2 No.2, 1996. [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements for Wireless LANs", draft-walker-ieee802-req-00.txt (work in progress), February 2004. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, March 2003. " _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Apr 3 19:45:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13495 for ; Sat, 3 Apr 2004 19:45:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AFF81FF67; Sat, 3 Apr 2004 19:34:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FDE020338; Sat, 3 Apr 2004 19: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 469FC20338 for ; Sat, 3 Apr 2004 19:33: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 1A9541FF67 for ; Sat, 3 Apr 2004 19:33:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i340qgC08157 for ; Sat, 3 Apr 2004 16:52: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] Re: Issue 215: Comments on Section 3 of Key Framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 3 Apr 2004 16:52:42 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On part 1, I tend to agree with the comments. However, to make the change we need proposed replacement text. On part 2, I don't believe that the exported portion of the EAP key hierarchy can be method-specific (MSK, EMSK, IV and keys derived from them). That would introduce method dependencies into both the AAA and Secure Association Protocol, which would violate one of the EAP invariants -- method independence. ---------------------------------------------------------------------- Issue 215: Comments on Section 3 of Key Framework Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 1/21/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-January/002170.html Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 3 Rationale/Explanation of issue: 1. Use of term "security Association": In section 3 the use of term security association is somewhat non-standard. A security association is typically something that is generated dynamically and valid for a length of time. [1] The EAP-SA is more of a static relationship such as a trusted root key. [2] The EAP-Method SA is more along the lines of standard SA terminology. It is not visible outside the EAP-method. [3] The EAP-Key SA I do not think is really an SA. There are EAP-Key(s), but they must be managed outside the EAP protocol since EAP provides no key management functionality other than establishment. These EAP-Seeded SAs are managed by some other application separate from EAP. Examples of EAP Seeded SA are in section 3.5 [4] The AAA-SA is similar to [1] above in that there is a trusted root key. There are also "EAP-Seeded" SAs of which 3.5 is an example Recommended Changes: Use a different term than security association for other relationships or don't discuss them in this section. I'm not sure that so much detail is needed for the EAP-Method SA since it is not visible outside a method. Create section on EAP-Seeded SAs which describes Unicast SA and other possible SA based on the exchanged EAP keys. DO not use the term EAP SA as it confusing as to what is being discussed. I'm not sure that multicast security association needs to be discussed as it is usually is derived from a unicast security association and not directly involved with EAP. 2. Key Naming (Section 3.7) I think the only thing that needs to be named within the scope of EAP is the MSK and the EMSK resulting from a particular EAP exchange. This needs to be defined by the method. Here is some suggested test "EAP methods are responsible for defining and exporting a key name. The base EAP key name is an octet string between 15 and 31 octets. To name the MSK a M is prepended to the base name and for the EMSK a 'E' is prepended to the base name. The method for generating a base name is specific to the method, but it must be unique to each exchange and cryptographically bound to the exchange. An example for EAP-TLS is to take MD5 hash of the two finished messages in the TLS handshake in the order that they appear. It is NOT RECOMMENDED that a static function of the MSK or EMSK be used as publically known name. Other applications may use the EAP key name to derive names for their purposes that have additional meaning. " _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Apr 4 17:15:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11510 for ; Sun, 4 Apr 2004 17:15:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3560020555; Sun, 4 Apr 2004 17:04:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2F112031F; Sun, 4 Apr 2004 17:04:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 522CC2031F for ; Sun, 4 Apr 2004 17:03:31 -0400 (EDT) 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 7594A20312 for ; Sun, 4 Apr 2004 17:03:29 -0400 (EDT) X-BrightmailFiltered: true 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 i34LFEn2014522; Sun, 4 Apr 2004 14:15:15 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.225.131]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Apr 2004 14:21:48 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Re: Issue 215: Comments on Section 3 of Key Framework Message-ID: <008e01c41a89$eba16080$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 04 Apr 2004 21:21:48.0955 (UTC) FILETIME=[D715B6B0:01C41A8A] 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, 4 Apr 2004 14:15:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable eap-admin@frascone.com wrote: > On part 1, I tend to agree with the comments. However, to > make the change we need proposed replacement text. >=20 [Joe] OK, I will work on some text for this. Are you planning on = submitting revisions to section 3 as you did for 1 and 2? if so we should = coordinate on the modifications.=20 > On part 2, I don't believe that the exported portion of the > EAP key hierarchy can be method-specific (MSK, EMSK, IV and > keys derived from them). That would introduce method > dependencies into both the AAA and Secure Association > Protocol, which would violate one of the EAP invariants -- > method independence. [Joe] That is not what I intended to suggest. The way the MSK and the = EMSK are generated is method specific. The only thing that is currently = specified in EAP is the length of the key material. From these keys application specific master keys can be derived. The applications must determine = how the application master key is derived from the MSK and/or EMSK, how the = key is transported to where it is used (if this is required) and how the key = is used in the application. For example there is existing behavior for = layer 2 encryption applications: 1. The application specific master key for layer 2 encryption is the MSK 2. The key is transported to the NAS using the RADIUS MS-MPPE-SEND and = RECV key attributes 3. The key is either used as the PMK in 802.11i or directly as the encryption key in dynamic WEP Other applications should derive keys from the EMSK to avoid conflicts = with the current MSK usage. The EMSK is not used directly by applications = rather a standardized key derivation method is used to derive the application specific master key using parameters specified by the application. How = the key is transported and used should also be determined by the = application. =20 It useful to name keys so that two parties can agree upon which key to = use. I think it is best if the key is named by the method that generates it. = The suggestion is that in addition to the MSK and EMSK the method also = exports an octet string used to name the MSK and EMSK. Applications may use = this name as the basis to derive names for their keys derived from the MSK or = the EMSK. =20 >=20 > ---------------------------------------------------------------------- > Issue 215: Comments on Section 3 of Key Framework > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 1/21/2004 > Reference: > http://mail.frascone.com/pipermail/public/eap/2004-January/002170.html > Document: Keying Framework Comment type: 'E'ditorial > Priority: '1' Should fix > Section: Section 3 > Rationale/Explanation of issue: >=20 > 1. Use of term "security Association": >=20 > In section 3 the use of term security association is somewhat > non-standard. A security association is typically something > that is generated dynamically and valid for a length of time. >=20 > [1] The EAP-SA is more of a static relationship such as a > trusted root key. [2] The EAP-Method SA is more along the > lines of standard SA terminology. It is not visible outside > the EAP-method. [3] The EAP-Key SA I do not think is really > an SA. There are EAP-Key(s), but they must be managed > outside the EAP protocol since EAP provides no key management > functionality other than establishment. These EAP-Seeded SAs > are managed by some other application separate from EAP. > Examples of EAP Seeded SA are in section 3.5 [4] The AAA-SA > is similar to [1] above in that there is a trusted root key. >=20 > There are also "EAP-Seeded" SAs of which 3.5 is an example >=20 > Recommended Changes: >=20 > Use a different term than security association for other > relationships or don't discuss them in this section. >=20 > I'm not sure that so much detail is needed for the EAP-Method > SA since it is not visible outside a method. >=20 > Create section on EAP-Seeded SAs which describes Unicast SA > and other possible SA based on the exchanged EAP keys. >=20 > DO not use the term EAP SA as it confusing as to what is > being discussed. >=20 > I'm not sure that multicast security association needs to be > discussed as it is usually is derived from a unicast security > association and not directly involved with EAP. >=20 > 2. Key Naming (Section 3.7) >=20 > I think the only thing that needs to be named within the > scope of EAP is the MSK and the EMSK resulting from a > particular EAP exchange. This needs to be defined by the > method. Here is some suggested test >=20 > "EAP methods are responsible for defining and exporting a key > name. The base EAP key name is an octet string between 15 > and 31 octets. To name the MSK a M is prepended to the base > name and for the EMSK a 'E' is > prepended to the base name. The method for generating a base name is > specific to the method, but it must be unique to each > exchange and cryptographically bound to the exchange. An > example for EAP-TLS is to take MD5 hash of the two finished > messages in the TLS handshake in the order that they appear. > It is NOT RECOMMENDED that a static function of the MSK or > EMSK be used as publically known name. Other applications may > use the EAP key name to derive names for their purposes that > have additional meaning. " > _______________________________________________ > 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 Sun Apr 4 18:32:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14302 for ; Sun, 4 Apr 2004 18:32:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31F75203AC; Sun, 4 Apr 2004 18:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A8A620561; Sun, 4 Apr 2004 18:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0657420561 for ; Sun, 4 Apr 2004 18:20:18 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 28FB1203AC for ; Sun, 4 Apr 2004 18:20:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i34MdOg25259; Sun, 4 Apr 2004 15:39:24 -0700 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Re: Issue 215: Comments on Section 3 of Key Framework In-Reply-To: <008e01c41a89$eba16080$0300000a@amer.cisco.com> Message-ID: References: <008e01c41a89$eba16080$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, 4 Apr 2004 15:39:24 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] OK, I will work on some text for this. Are you planning on submitting > revisions to section 3 as you did for 1 and 2? if so we should coordinate on > the modifications. I will go ahead and post what I have so far for Section 3. It is quite rough, but this may help improve it. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Apr 4 18:43:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14559 for ; Sun, 4 Apr 2004 18:43:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9667C20221; Sun, 4 Apr 2004 18:32:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E11B203AC; Sun, 4 Apr 2004 18:32:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E37B520221 for ; Sun, 4 Apr 2004 18:31:20 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A385120561 for ; Sun, 4 Apr 2004 18:31:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i34MoRB25954 for ; Sun, 4 Apr 2004 15:50:28 -0700 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] Rewrite of Key Framework Section 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: Sun, 4 Apr 2004 15:50:27 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I'm not posting this as an issue or resolution yet, since the text needs quite a bit more work. But here is the strawman text of Section 3. Comments welcome. 3. Security Associations EAP key management involves five types of security associations (SAs): [1] EAP SA. This is an SA between the peer and EAP server, which allows them to authenticate each other. [2] EAP method SA. This SA is also between the peer and EAP server. It stores state that can be used for "fast resume" or other functionality in some EAP methods. Not all EAP methods create such an SA. [3] EAP-Key SA. This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but future implementations could use this SA for pre-emptive key distribution. [4] AAA SA(s). These SAs are between the authenticator and the backend authentication server. They permit the parties to mutually authenticate each other and protect the communications between them. [5] Service SA(s). These SAs are between the peer and authenticator, and they are created as a result of phases 1-2 of the conversation (see Section 1.3). 3.1. EAP SA (peer - EAP server) In order for the peer and EAP server to authenticate each other, they need to store some information. The authentication can be based on different mechanisms, such as shared secrets or certificates. If the authentication is based on a shared secret key, the parties store the EAP method to be used and the key. The EAP server also stores the peer's identity and/or other information necessary to decide whether access to some service should be granted. The peer stores information necessary to choose which secret to use for which service. 3.2. EAP Method SA (peer - EAP server) An EAP method may store some state on the peer and EAP server even after phase 1a has completed. Typically, this is used for "fast resume": the peer and EAP server can confirm that they are still talking to the same party, perhaps using fewer roundtrips or less computational power. In this case, the EAP method SA is essentially a cache for performance optimization, and either party may remove the SA from its cache at any point. An EAP method may also keep state in order to support pseudonym-based identity protection. This is typically a cache as well (the information can be recreated if the original EAP method SA is lost), but may be stored for longer periods of time. The EAP method SA is not restricted to a particular service or authenticator and is most useful when the peer accesses many different authenticators. An EAP method is responsible for specifying how the parties select if an existing EAP method SA should be used, and if so, which one. Where multiple backend authentication servers are used, EAP method SAs are not typically synchronized between them. EAP method implementations should consider the appropriate lifetime for the EAP method SA. "Fast resume" assumes that the information required (primarily the keys in the EAP method SA) hasn't been compromised. In case the original authentication was carried out using, for instance, a smart card, it may be easier to compromise the EAP method SA (stored on the PC, for instance), so typically the EAP method SAs have a limited lifetime. Contents: o Implicitly, the EAP method this SA refers to o One or more internal (non-exported) keys o EAP method SA name o SA lifetime 3.2.1. Example: EAP-TLS In EAP-TLS [RFC2716], after the EAP authentication the client (peer) and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-TLS) o Session identifier (a value selected by the server) o Certificate of the other party (server stores the clients's certificate and vice versa) o Ciphersuite and compression method o TLS Master secret (known as the EAP-TLS Master Key or MK) o SA lifetime (ensuring that the SA is not stored forever) o If the client has multiple different credentials (certificates and corresponding private keys), a pointer to those credentials When the server initiates EAP-TLS, the client can look up the EAP-TLS SA based on the credentials it was going to use (certificate and private key), and the expected credentials (certificate or name) of the server. If an EAP-TLS SA exists, and it is not too old, the client informs the server about the existence of this SA by including its Session-Id in the TLS ClientHello message. The server then looks up the correct SA based on the Session-Id (or detects that it doesn't yet have one). 3.2.2. Example: EAP-AKA In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the client and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-AKA) o A re-authentication pseudonym o The client's permanent identity (IMSI) (server) o Replay protection counter o Authentication key (K_aut) o Encryption key (K_encr) o Original Master Key (MK) o SA lifetime (ensuring that the SA is not stored forever) When the server initiates EAP-AKA, the client can look up the EAP-AKA SA based on the credentials it was going to use (permanent identity). If an EAP-AKA SA exists, and it is not too old, the client informs the server about the existence of this SA by sending its re- authentication pseudonym as its identity in EAP Identity Response message, instead of its permanent identity. The server then looks up the correct SA based on this identity. 3.3. EAP-key SA This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but future implementations could use this SA for pre- emptive key distribution. Contents: o Name/identifier for this SA o Identities of the parties o MSK and EMSK 3.4. AAA SA(s) (authenticator - backend auth. server) In order for the authenticator and backend authentication server to authenticate each other, they need to store some information. In case the authenticator and backend authentication server are colocated, and they communicate using local procedure calls or shared memory, this SA need not necessarily contain any information. 3.4.1. Example: RADIUS In RADIUS, where shared secret authentication is used, the client and server store each other's IP address and the shared secret, which is used to calculate the Response Authenticator [RFC2865] and Message- Authenticator [RFC3579] values, and to encrypt some attributes (such as the AAA-Key [RFC2548]). Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for key management, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The IKE exchange results in IKE Phase 1 and Phase 2 SAs containing information used to protect the conversation (session keys, selected ciphersuite, etc.) 3.4.2. Example: Diameter with TLS When using Diameter protected by TLS, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The TLS handshake results in a short-term TLS SA that contains information used to protect the actual communications (session keys, selected TLS ciphersuite, etc.). 3.5. Secure Association SAs 3.5.1. Unicast Secure Association SA The unicast Secure Association SA exists between the EAP peer and authenticator. It includes: o the peer port identifier (Calling-Station-Id) o the NAS port identifier (Called-Station-Id) o the unicast Transient Session Keys (TSKs) o the unicast Secure Association peer nonce o the unicast Secure Association authenticator nonce o the negotiated unicast capabilities and unicast ciphersuite. During the phase 2a exchange, the EAP peer and authenticator demonstrate mutual possession of the AAA-Key derived and transported in phase 1; securely negotiate the session capabilities (including unicast ciphersuites), and derive fresh unicast transient session keys. The AAA-Key SA (phase 1b) is therefore used to create the unicast Secure Association SA (phase 2a), and in the process the phase 2a unicast Secure Association SA is bound to ports on the EAP peer and authenticator. However in order for a phase 2a security association to be established, it is not necessary for the phase 1a exchange to be rerun each time. This enables the EAP exchange to be bypassed when fast handoff support is desired. Since both peer and authenticator nonces are used in the creation of the unicast Secure Association SA, the transient session keys (TSKs) are guaranteed to be fresh, even if the AAA-Key is not. As a result one or more unicast Secure Association SAs (phase 2a) may be derived from a single AAA-Key SA (phase 1b). The phase 2a security associations may utilize the same security parameters (e.g. mode, ciphersuite, etc.) or they may utilize different parameters. A unicast Secure Association SA (phase 2a) may not persist longer than the maximum lifetime of its parent AAA-Key SA (if known). However, the deletion of a parent EAP or AAA-Key SA does not necessarily imply deletion of the corresponding unicast secure association SA. Similarly, the deletion of a unicast secure Association Protocol SA does not imply the deletion of the parent AAA-key SA or EAP SA. Failure to mutually prove possession of the AAA-Key during the unicast Secure Association Protocol exchange (phase 2a) need not be grounds for removal of a AAA-Key SA by both parties; rate-limiting unicast Secure Association exchanges should suffice to prevent a brute force attack. An EAP peer may be able to negotiate multiple phase 2a SAs with a single EAP authenticator, or may be able to maintain multiple phase 2a SAs with multiple authenticators, based on a single EAP SA derived in phase 1a. For example, during a re-key of the Secure Association protocol SA, it is possible for two phase 2a SAs to exist during the period between when the new phase 2a SA parameters (such as the TSKs) are calculated and when they are installed. Except where explicitly specified by the semantics of the unicast Secure Association protocol, it should not be assumed that the installation of a new phase 2a SA necessarily implies deletion of the old phase 2a SA. On some media (e.g. 802.11) a port on an EAP peer may only establish phase 2a and 2b SAs with a single port of an authenticator within a given Local Area Network (LAN). This implies that the successful negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new authentiator port within a given LAN implies the deletion of existing phase 2a and 2b SAs with authenticators offering access to that Local Area Network (LAN). However, since a given IEEE 802.11 SSID may be comprised of multiple LANs, this does not imply an implicit binding of phase 2a and 2b SAs to an SSID. 3.5.2. Multicast Secure Association SA The multicast Secure Association SA includes: o the multicast Transient Session Keys o the direction vector (for a uni-directional SA) 0 the negotiated multicast capabilities and multicast ciphersuite It is possible for more than one multicast Secure Association SA to be derived from a single unicast Secure Association SA. However, a multicast Secure Association SA is bound to a single EAP SA and a single AAA-Key SA. During a re-key of the multicast Secure Association Protocol SA, it is possible for two phase 2b SAs to exist during the period between when the new phase 2b SA parameters (such as the multicast TSKs) are calculated and when they are installed. Except where explicitly specified by the semantics of the multicast Secure Association protocol, it should not be assumed that the installation of a new phase 2b SA necessarily implies deletion of the old phase 2b SA. A multicast Secure Association SA (phase 2b) may not persist longer than the maximum lifetime of its parent AAA-Key or unicast secure association SA. However, the deletion of a parent EAP, AAA-Key or unicast Secure Association SA does not necessarily imply deletion of the corresponding multicast Secure Association SA. For example, a unicast Secure Association SA may be rekeyed without implying a rekey of the multicast Secure Association SA. Similarly, the deletion of a multicast Secure Association Protocol SA does not imply the deletion of the parent EAP, AAA-Key or unicast Secure Association SA. Failure to mutually prove possession of the AAA-Key during the unicast Secure Association Protocol exchange (phase 2a) need not be grounds for removal of the AAA-Key, unicast Secure Association and multicast Secure Association SAs; rate- limiting unicast Secure Association exchanges should suffice to prevent a brute force attack. 3.6. Service SA(s) (peer - authenticator) The service SA stores information about the service being provided. This includes: o Service parameters (or at least those parameters that are still needed) o On the authenticator, service authorization information received from the backend authentication server (or necessary parts of it) o On the peer, usually locally configured service authorization information. o Transient Session Keys used to protect the communication o The AAA-Key, if it can be needed again (to refresh (and/or resynchronize other keys or for another reason) The information in the service SA can be grouped into several different SAs. This would make sense if, for instance, the service provided is naturally divided into several different subconversations with different parameters. How exactly the relevant service SA is chosen at each point depends on the protocol; see below for examples. 3.6.1. Example: 802.11i Note that this example is intended to be informative, and it does not necessarily include all information stored. o PMKSA - Key (PMK) - PMKID - SSID - Supplicant and authenticator group addresses (PMKSA can be used if the SSID and group addresses stay the same) - Key replay counters (for EAPOL-Key messages) - Lifetime information (that can be different client and AP) - Reference to PTKSA (if any), needed for: - to delete it (e.g. AAA server-initiated disconnect) - to replace it when a new four-way handshake is done after reauthentication - Authorization information. On the authenticator, this can be locally configured or received from the backend authentication server. On the peer, this is usually locally configured. - Reference to accounting context (the details of which depend on the accounting protocol used, and various implementation and administrative details. In RADIUS, this could include (e.g. packet and octet counters, and Acct-Multi-Session-Id). o PTKSA The PTKSA is created based on the four-way handshake. When receiving or sending a packet, the correct PTKSA is looked up based on TA and RA (Transmitter/Received Address). - Key (PTK) - Selected ciphersuite - MAC addresses of the parties - Replay counters, and ciphersuite specific state - Reference to PMKSA: This is needed for - If a new four-way handshake is needed (lifetime, TKIP countermeasures), we need to know which PMKSA to use - Via the reference to PMKSA, or copied here: - SSID (to select VLAN tags) - Authorization information (such as L2 packet filters) - Reference to accounting context (right counters etc.) o GTKSA The GTKSA is created based on the four-way handshake, or the four-way handshake and a separate group key handshake. When receiving a packet, the correct GTKSA is looked up based on source MAC address. When sending a packet, this is looked up by own MAC address and SSID. - Direction bit - Key (GTK) - Sender (AP) MAC address - Selected cipher suite - Ciphersuite-specific data - Via reference to PMKSA, or copied here: - SSID (to select VLAN tags) - Reference to accounting context 3.6.2. Example: IKEv2/IPsec Note that this example is intended to be informative, and it does not necessarily include all information stored. o IKEv2 SA - Protocol version - Identitites of the parties - IKEv2 SPIs - Selected ciphersuite - Replay protection counters (Message ID) - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) - Key for deriving keys for IPsec SAs (SK_d) - Lifetime information - On the authenticator, service authorization information received from the backend authentication server. When processing an incoming message, the correct SA is looked up based on the SPIs. o IPsec SAs/SPD - Traffic selectors - Replay protection counters - Selected ciphersuite - IPsec SPI - Keys - Lifetime information - Protocol mode (tunnel or transport) The correct SA is looked up based on SPI (for inbound packets), or SPD traffic selectors (for outbound traffic). A separate IPsec SA exists for each direction. 3.6.3. Sharing service SAs A single service may be provided by multiple logical or physical service elements. Each service is responsible for specifying how changing service elements is handled. Some approaches include: Transparent sharing If the service parameters visible to the other party (either peer or authenticator) do not change, the service can be moved without requiring cooperation from the other party. Whether such a move should be supported or used depends on implementation and administrative considerations. For instance, an administrator may decide to configure a group of IKEv2/IPsec gateways in a cluster for high-availability purposes, if the implementation used supports this. The peer does not necessarily have any way of knowing when the change occurs. No sharing If the service parameters require changing, some changes may require terminating the old service, and starting a new conversation from phase 0. This approach is used by all services for at least some parameters, and it doesn't require any protocol for transferring the service SA between the service elements. The service may support keeping the old service element active while the new conversation takes phase, to decrease the time the service is not available. Some sharing The service may allow changing some parameters by simply agreeing about the new values. This may involve a similar exchange as in phase 2, or perhaps a shorter conversation. This option usually requires some protocol for transferring the service SA between the elements. An administrator may decide not to enable this feature at all, and typically the sharing is restricted to some particular service elements (defined either by a service parameter, or simple administrative decision). If the old and new service element do not support such "context transfer", this approach falls back to the previous option (no transfer). Services supporting this feature should also consider what changes require new authorization from the backend authentication server (see Section 1.7). Note that these considerations are not limited to service parameters related to the authenticator--they apply to peer's parameters as well. 3.7. Key Naming In order to support the correct processing of phase 2 security associations, the Secure Association (phase 2) protocol supports the naming of phase 2 security associations and associated transient session keys, so that the correct set of transient session keys can be identified for processing a given packet. Explicit creation and deletion operations are also typically supported so that establishment and re-establishment of transient session keys can be synchronized between the parties. In order to securely bind the AAA SA (phase 1b) to its child phase 2 security associations, the phase 2 Secure Association Protocol allows the EAP peer and authenticator to mutually prove possession of the AAA-Key. In order to avoid confusion in the case where an EAP peer has more than one AAA-Key (phase 1b) applicable to establishment of a phase 2 security association, it is necessary for the secure Association Protocol (phase 2) to support key selection, so that the appropriate phase 1b keying material can be utilized by both parties in the Secure Association Protocol exchange. For example, a peer might be pre-configured with policy indicating the ciphersuite to be used in communicating with a given authenticator. Within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP), after EAP authentication is completed. Within [IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe Responses, and are securely verified during a 4-way exchange after EAP authentication has completed. As part of the Secure Association Protocol (phase 2), it is necessary to bind the Transient Session Keys (TSKs) to the keying material provided in the AAA-Token. This ensures that the EAP peer and authenticator are both clear about what key to use to provide mutual proof of possession. Keys within the EAP key hierarchy are named as follows: EAP SA name The EAP security association is negotiated between the EAP peer and EAP server, and is uniquely named as follows . Here the EAP peer name and EAP server name are the identifiers securely exchanged within the EAP method. Since multiple EAP SAs may exist between an EAP peer and EAP server, the EAP peer nonce and EAP server nonce allow EAP SAs to be differentiated. The inclusion of the Method Type in the EAP SA name ensures that each EAP method has a distinct EAP SA space. AAA-Key Name The AAA-Key is named by the concatenation of the EAP SA name, "AAA- Key" and the authenticator name, since the AAA-Key is bound to a particular authenticator. For the purpose of identification, the NAS-Identifier attribute is recommended. In order to ensure that all parties can agree on the NAS name this requires the NAS to advertise its name (typically using a media-specific mechanism, such as the 802.11 Beacon/Probe Response)." 3.8. Key Scoping A AAA-Key provided by the backend authentication server to the authenticator is for use only by that authenticator. While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support mutual authentication between the authenticator (known as the AAA client) and the backend authentication server (known as the AAA server), the security mechanisms vary according to the AAA protocol. In the case of RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. As noted in [RFC3579] Section 4.3.7, it is highly desirable that the source address be checked against one or more NAS identification attributes so as to detect and prevent impersonation attacks. A wide variety of authenticator and peer designs need to be accomodated within the EAP key management framework. As noted in Section 1.3, an authenticator may contain multiple physical ports; a single physical authenticator may, for the purpose of peer discovery, advertise itself as multiple "virtual authenticators"; authenticators may be compromised of multiple CPUs; authenticators may utilize clustering in order to provide load balancing or failover. Similarly, a peer may support multiple ports; may support multiple CPUs; or may support clustering. While AAA protocols mutually authenticate the AAA client and server they do not distinguish authenticator architectures. Therefore while the AAA-Key provided by the AAA server is for use solely by the authenticator receiving the key, by default the usage boundary is defined by the authenticator architecture. This may have unexpected consequences. Where a physical authenticator acts as multiple "virtual authenticators", unless each "virtual authenticator" identifies itself distinctly to the AAA server, then a AAA-Key provided by the AAA server is by default available for use by any of the "virtual authenticators". This enables potential security vulnerabilities. For example, an EAP peer could authenticate with the "guest" "virtual authenticator" and negotiate a AAA-Key. The peer could then attempt to use that AAA-Key to do a fast handoff to the "Corporate Intranet" virtual authenticator within the same physical authenticator. If the virtual authenticators do not identify themselves distinctly to the AAA server, then the key cache will be shared in common and the fast handoff attempt will be successful. In order to address this vulnerability, authenticators need to cache not only the AAA-Keys, but also the associated authorizations. This ensures that an attacker could not obtain elevated privileges even if they could authenticate successfully to another "virtual authenticator" hosted within the same physical chassis. If further protection is required, it is advisable for the AAA server to explicitly restrict the AAA-Key scope by including additional scope restriction attributes within the AAA-Token. Examples of scope restriction attributesw include: Virtual authenticator restrictions In the case of 802.11, this could involve including a list of authorized Called-Station-Ids or SSIDs for which the AAA-Key is valid. Peer restrictions In the case of 802.11, this could involve including a list of authorized Calling-Station-Ids for which the AAA-Key is valid. Note that in restricting the use of the AAA-Key it is important to ensure that the EAP peer can be made aware of the restriction so that the peer and authenticator can behave consistently. 3.9. Authorization Issues In a typical network access scenario (dial-in, wireless LAN, etc.) access control mechanisms are typically applied. These mechanisms include user authentication as well as authorization for the offered service. As a part of the authentication process, the AAA network determines the user's authorization profile. The user authorizations are transmitted by the backend authentication server to the EAP authenticator (also known as the Network Access Server or authenticator) included with the AAA-Token, which also contains the AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile is determined based on the user identity, but a certificate presented by the user may also provide authorization information. The backend authentication server is responsible for making a user authorization decision, answering the following questions: [a] Is this a legitimate user for this particular network? [b] Is this user allowed the type of access he or she is requesting? [c] Are there any specific parameters (mandatory tunneling, bandwidth, filters, and so on) that the access network should be aware of for this user? [d] Is this user within the subscription rules regarding time of day? [e] Is this user within his limits for concurrent sessions? [f] Are there any fraud, credit limit, or other concerns that indicate that access should be denied? While the authorization decision is in principle simple, the process is complicated by the distributed nature of AAA decision making. Where brokering entities or proxies are involved, all of the AAA devices in the chain from the authenticator to the home AAA server are involved in the decision. For instance, a broker can disallow access even if the home AAA server would allow it, or a proxy can add authorizations (e.g., bandwidth limits). Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g. time of day or limits on the number of concurrent sessions). In addition to the Accept/Reject decision made by the AAA chain, parameters or constraints can be communicated to the authenticator. The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the authenticator, only the final result. As a result, the authenticator has no way to know what the decision was based on. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time/day and the capabilities of the requesting authenticator device? Within EAP, "fast handoff" is defined as a conversation in which the EAP exchange (phase 1a) and associated AAA passthrough is bypassed, so as to reduce latency. Depending on the fast handoff mechanism, AAA-Key transport (phase 1b) may also be bypassed or it may be provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf- aaaarch-handoff]. As we will discuss, the introduction of fast handoff creates a new class of security vulnerabilities as well as requirements for the secure handling of authorization context. 3.10. Correctness In Fast Handoff Bypassing all or portions of the AAA conversation creates challenges in ensuring that authorization is properly handled. These include: [a] Consistent application of session time limits. A fast handoff should not automatically increase the available session time, allowing a user to endlessly extend their network access by changing the point of attachment. [b] Avoidance of privilege elevation. A fast handoff should not result in a user being granted access to services which they are not entitled to. [c] Consideration of dynamic state. In situations in which dynamic state is involved in the access decision (day/time, simultaneous session limit) it should be possible to take this state into account either before or after access is granted. Note that consideration of network-wide state such as simultaneous session limits can typically only be taken into account by the backend authentication server. [d] Encoding of restrictions. Since a authenticator may not be aware of the criteria considered by a backend authentication server when allowing access, in order to ensure consistent authorization during a fast handoff it may be necessary to explicitly encode the restrictions within the authorizations provided in the AAA-Token. [e] State validity. The introduction of fast handoff should not render the authentication server incapable of keeping track of network- wide state. A fast handoff mechanism capable of addressing these concerns is said to be "correct". One condition for correctness is as follows: For a fast handoff to be "correct" it MUST establish on the new device the same context as would have been created had the new device completed a AAA conversation with the authentication server. A properly designed fast handoff scheme will only succeed if it is "correct" in this way. If a successful fast handoff would establish "incorrect" state, it is preferable for it to fail, in order to avoid creation of incorrect context. Some backend authentication server and authenticator configurations are incapable of meeting this definition of "correctness". For example, if the old and new device differ in their capabilities, it may be difficult to meet this definition of correctness in a fast handoff mechanism that bypasses AAA. Backend authentication servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on the authenticator or on dynamic state such as the time of day or number of simultaneous sessions. For example, in a heterogeneous deployment, the backend authentication server might return different authorizations depending on the authenticator making the request, in order to make sure that the requested service is consistent with the authenticator capabilities. If differences between the new and old device would result in the backend authentication server sending a different set of messages to the new device than were sent to the old device, then if the fast handoff mechanism bypasses AAA, then the fast handoff cannot be carried out correctly. For example, if some authenticator devices within a deployment support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the authenticator-IP-Address, authenticator-Identifier, Vendor-Identifier, etc.) could be examined to determine when VLAN attributes will be returned, as described in [RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast handoff bypassing the backend authentication server were to occur between a authenticator supporting dynamic VLANs and another authenticator which does not, then a guest user with access restricted to a guest VLAN could be given unrestricted access to the network. Similarly, in a network where access is restricted based on the day and time, Service Set Identifier (SSID), Calling-Station-Id or other factors, unless the restrictions are encoded within the authorizations, or a partial AAA conversation is included, then a fast handoff could result in the user bypassing the restrictions. In practice, these considerations limit the situations in which fast handoff mechanisms bypassing AAA can be expected to be successful. Where the deployed devices implement the same set of services, it may be possible to do successful fast handoffs within such mechanisms. However, where the supported services differ between devices, the fast handoff may not succeed. For example, [RFC2865], section 1.1 states: "A authenticator that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a authenticator that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A authenticator MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead." Note that this behavior only applies to attributes that are known, but not implemented. For attributes that are unknown, section of 5 of [RFC2865] states: "A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type." In order to perform a correct fast handoff, if a new device is provided with RADIUS context for a known but unavailable service, then it MUST process this context the same way it would handle a RADIUS Access-Accept requesting an unavailable service. This MUST cause the fast handoff to fail. However, if a new device is provided with RADIUS context that indicates an unknown attribute, then this attribute MAY be ignored. Although it may seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested. Presumably a correctly configured backend authentication server would not request that a device carry out a service that it does not implement. This implies that if the new device were to complete a AAA conversation that it would be likely to receive different service instructions. In such a case, failure of the fast handoff is the desired result. This will cause the new device to go back to the AAA server in order to receive the appropriate service definition. In practice, this implies that fast handoff mechanisms which bypass AAA are most likely to be successful within a homogeneous device deployment within a single administrative domain. For example, it would not be advisable to carry out a fast handoff bypassing AAA between a authenticator providing confidentiality and another authenticator that does not support this service. The correct result of such a fast handoff would be a failure, since if the handoff were blindly carried out, then the user would be moved from a secure to an insecure channel without permission from the backend authentication server. Thus the definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Apr 5 05:28:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18942 for ; Mon, 5 Apr 2004 05:28:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1FAB205EC; Mon, 5 Apr 2004 05:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D3F7204D2; Mon, 5 Apr 2004 05:16:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1D50204D2 for ; Mon, 5 Apr 2004 05:15:45 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id A4BAA20386 for ; Mon, 5 Apr 2004 05:15:43 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i359RV821740; Mon, 5 Apr 2004 12:27:31 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 12:27:03 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i359R31k010937; Mon, 5 Apr 2004 12:27:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00GUjkYC; Mon, 05 Apr 2004 12:17:00 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i359F5s10558; Mon, 5 Apr 2004 12:15:05 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 12:14:16 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 12:14:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: EAP-SIM and EAP-AKA Thread-Index: AcQa7lzlM2VHf7QtST2E+i0KJVm5Jw== From: To: Cc: X-OriginalArrivalTime: 05 Apr 2004 09:14:15.0420 (UTC) FILETIME=[5DF6A3C0:01C41AEE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM and EAP-AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Apr 2004 12:14:14 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi everyone, We have submitted new versions of EAP-SIM and EAP-AKA to the IETF directiories. The drafts are=20 draft-haverinen-pppext-eap-sim-13.txt and=20 draft-arkko-pppext-eap-aka-12.txt, and we will also send these versions to the RFC editor and request=20 publication as informational RFCs.=20 These versions are technically compatible with=20 implementations of previous versions. Many thanks to those=20 who contributed and helped with these draft versions.=20 Special thanks to Greg Rose and Florent Bersani. Changes: - resolutions to Greg Rose's and Florent Bersani's comments, as discussed in this mailing list - new optional protected success indications. Their use is negotiated with the skippable AT_RESULT_IND attribute.=20 - new specification for behaviour in failure cases, and the processing of EAP-Failure. Basically explicit EAP-SIM or EAP-AKA messages are used in all error cases. Two new notification codes=20 for general failure cases. These changes may cause implementations of old and new draft versions to fail differently, and some failure cases may result in a timeout. In any case, failed exchanges will eventually result in failure at both ends, so no real=20 compatibility problems are caused by this change. - the usage of AT_COUNTER for replay protection of notifications, when notifications are used in fast re-authentication - clarifications on the encoding of the permanent username - clarifications on the usage of fast re-authentication identities - IPR statement removed because the xml template generates another one - clarifications on the IANA considerations - fixed bugs in EAP-SIM example packets - clarifications on the attribute processing order=20 - updated security claims - new informative text to explain the rationale for the fast re-authentication protocol design - a lot of formatting changes because of the use of XML - editorials Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Apr 5 13:48:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19566 for ; Mon, 5 Apr 2004 13:48:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6064520607; Mon, 5 Apr 2004 13:36:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B0CA2057C; Mon, 5 Apr 2004 13:36:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C8F120577 for ; Mon, 5 Apr 2004 13:35:50 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9B3801FEFF for ; Mon, 5 Apr 2004 13:35:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i35Hsu331451 for ; Mon, 5 Apr 2004 10:54:56 -0700 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] WIEN SG Call for Submissions (fwd) 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, 5 Apr 2004 10:54:56 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) ---------- Forwarded message ---------- Date: Mon, 5 Apr 2004 18:32:18 +0100 From: "McCann, Stephen" To: STDS-802-11@listserv.ieee.org Subject: [802-11TECHNICAL] WIEN SG Call for Submissions --- This message came from the IEEE 802.11 Technical Reflector --- Dear all, The Wireless Interworking with External Networks Study Group (WIEN SG) will meet for the first time at the May 2004 Interim. I would encourage any one who is interested to create and present a submission, which will assist us to form the scope and define our future study work. If you wish to do this, please inform me and I'll allocate you some time on the agenda. Kind regards Stephen McCann _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From WZFTHTJ@almos.vein.hu Mon Apr 5 18:10: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 SAA15517 for ; Mon, 5 Apr 2004 18:10:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcIY-0004Cn-00 for eap-archive@ietf.org; Mon, 05 Apr 2004 18:10:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAc4F-0001qQ-00 for eap-archive@ietf.org; Mon, 05 Apr 2004 17:55:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAbch-0006HA-00 for eap-archive@ietf.org; Mon, 05 Apr 2004 17:27:15 -0400 Received: from c68.115.49.149.ona.wi.charter.com ([68.115.49.149]) by mx2.foretec.com with smtp (Exim 4.24) id 1BAbch-0003So-Iy for eap-archive@ietf.org; Mon, 05 Apr 2004 17:27:15 -0400 Received: from 219.114.56.177 by 68.115.49.149; Mon, 05 Apr 2004 18:28:48 -0400 Message-ID: From: "Diane Hinton" Reply-To: "Diane Hinton" To: eap-archive@ietf.org Subject: Are you sure? Date: Tue, 06 Apr 2004 03:26:48 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--702108834375440777" X-Originating-IP: 65.246.255.50 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=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----702108834375440777 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 85.244.184.40 o

 

We're looking for people who are serious= about being paid for their opinions

sign up here

 

 

 

to get off our database follow this link

orwell windsor canopy hysteria permitted inta= ct unicorn vamp yip irredeemable simmons dolt indecipherable dissuade albe= rich citroen camino circumvention contort douglass opposition neutron neal= tool colonnade marilyn agenda sovereignty squibb micky belove perry caraw= ay lillian reparation skater chance solon gar=20 wallow cinematic odessa vaughan serene h= azard sprocket lounge devout defrost loon become eisenhower eave naturopat= h bluebush dependent plasmon ash drowsy accelerometer=20 exclaim cobblestone beck barkeep religion cy= lindric dementia directory throb candlewick henley dorset counterpart dain= ty coffman croydon insouciant corporeal hamburger parallel seventeen scrat= ch sienna paramilitary claustrophobic wrinkle=20 crestview divulge cytolysis bitt festival = filtrate bean topic cadaver broom bunch apogee quarantine molybdate=20 greenfield illiterate palomar copra courag= eous coed pensive dockyard experiential driven maltose hasty joss carborun= dum disposable policemen applaud epitaxy contrite wilsonian quetzal platon= ic diabetes soya usa competition threonine frazier coworker intangible ike= morrow neuralgia stanford sixgun astor armenian adulterous pastel decry=20= thrift adjective deterrent weinberg hey= dud eclat scum devout cosh yam balletomane pappy edt broglie apathy teet = gusset sparling serfdom caliphate fleck bias broccoli nectareous houdaille= promote rowdy bombastic osteopath scotsman aphasic periodic allocable bus= boy toodle drapery heterostructure aorta depredate=20 ----702108834375440777-- From eap-admin@frascone.com Tue Apr 6 11:33:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28835 for ; Tue, 6 Apr 2004 11:33:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5C4E1FF7B; Tue, 6 Apr 2004 11:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5969620244; Tue, 6 Apr 2004 11:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0370220244 for ; Tue, 6 Apr 2004 11:20:01 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1720B1FF7B for ; Tue, 6 Apr 2004 11:19:59 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i36Fcv115279; Tue, 6 Apr 2004 08:38:57 -0700 From: Bernard Aboba To: "David Mariblanca (ML/EEM)" Cc: eap@frascone.com In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C7@eestqnt105.es.eu.ericsson.se> Message-ID: References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A7C7@eestqnt105.es.eu.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: use of EAP over IKEv2 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, 6 Apr 2004 08:38:56 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) While the AAA server could be informed that IKEv2 is being used (e.g. NAS-Port-Type), it cannot generate different keys based on that information. This would be a violation of the "media independence" property of EAP. So the bottom line is that On Tue, 6 Apr 2004, David Mariblanca (ML/EEM) wrote: > > Hi, > I have found a problem when EAP is used over IKEv2 and I would appreciate some help on the issue. > When EAP is carried over IKEv2, a common situation is that the host where EAP terminates is not the same as for IKEv2. In that case, the IKEv2 termination point unpacks the IKEv2 messages, take the EAP messages and forwards them to the EAP termination point over RADIUS or Diameter. > The problem I see is that the EAP server has no way to know that these EAP messages are being carried over IKEv2. This knowledge is important for the EAP server, for example to derive keys that will be used to generate AUTH payloads in IKEv2. > The service type AVP does not have a reserved value for this, and I don't find any other suitable parameter to convey this information. How could this be done ? > > Thanks a lot and best regards, > David. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Apr 6 13:48:52 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10964 for ; Tue, 6 Apr 2004 13:48:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5430620205; Tue, 6 Apr 2004 13:36:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D54C720298; Tue, 6 Apr 2004 13:36:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC5A220298 for ; Tue, 6 Apr 2004 13:35:14 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D0ACF20205 for ; Tue, 6 Apr 2004 13:35:12 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8E42B898C4 for ; Tue, 6 Apr 2004 20:47:01 +0300 (EEST) Message-ID: <4072EC6D.5070101@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="------------030503030706010702040405" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-ietf-pppext-eap-ttls-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: Tue, 06 Apr 2004 20:44:13 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------030503030706010702040405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------030503030706010702040405 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-pppext-eap-ttls-04.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-pppext-eap-ttls-04.txt" Return-Path: Received: from p2.piuha.net ([unix socket]) by p2.piuha.net (Cyrus v2.2.3) with LMTP; Tue, 06 Apr 2004 20:36:21 +0300 X-Sieve: CMU Sieve 2.2 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by p2.piuha.net (Postfix) with ESMTP id AB1E6898C7 for ; Tue, 6 Apr 2004 20:36:14 +0300 (EEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAteW-0000h3-Lt; Tue, 06 Apr 2004 12:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtPF-0007H5-Ev for i-d-announce@optimus.ietf.org; Tue, 06 Apr 2004 12:26:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02604; Tue, 6 Apr 2004 12:26:00 -0400 (EDT) Message-Id: <200404061626.MAA02604@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pppext@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-ttls-04.txt Date: Tue, 06 Apr 2004 12:26:00 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : EAP Tunneled TLS Authentication Protocol (EAP-TTLS) Author(s) : P. Funk, S. Blake-Wilson Filename : draft-ietf-pppext-eap-ttls-04.txt Pages : 38 Date : 2004-4-5 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-pppext-eap-ttls-04.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-pppext-eap-ttls-04.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-4-6105403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-ttls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-ttls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105403.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --------------030503030706010702040405-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Demarcus_Redlinger@cgey.com Tue Apr 6 21:13:53 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 VAA18653 for ; Tue, 6 Apr 2004 21:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1da-0006fd-00 for eap-archive@ietf.org; Tue, 06 Apr 2004 21:13:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0Rk-0007Fl-00 for eap-archive@ietf.org; Tue, 06 Apr 2004 19:57:36 -0400 Received: from c-24-130-251-192.we.client2.attbi.com ([24.130.251.192]) by ietf-mx with smtp (Exim 4.12) id 1BAziB-0000XN-00 for eap-archive@ietf.org; Tue, 06 Apr 2004 19:10:33 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: thanks From: "Tatyana Mrozinski" To: eap-archive@ietf.org X-Priority: 3 Date: Tue, 06 Apr 2004 19:04:23 -0500 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=6.6 required=5.0 tests=HTML_60_70,HTML_IMAGE_ONLY_04, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable The Canadian's last words produced a su= dden revolution in my brain!!=20





If the message is not loading= try this













The theory of the floating island, and the unapproachable sandbank, suppor= ted by minds little competent to form a judgment, was abandoned!! It is ce= rtain that I soon came to, thanks to the vigorous rubbings that I received= ;=20 nettlesome From Administration@computeradmin.org Wed Apr 7 23:25:07 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 XAA11780 for ; Wed, 7 Apr 2004 23:25:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBQA7-0001Dt-00 for eap-archive@ietf.org; Wed, 07 Apr 2004 23:25:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOLg-0004Uo-00 for eap-archive@ietf.org; Wed, 07 Apr 2004 21:28:57 -0400 Received: from [201.128.15.56] (helo=dsl-201-128-15-56.prod-infinitum.com.mx) by ietf-mx with smtp (Exim 4.12) id 1BBMoZ-0006rx-00; Wed, 07 Apr 2004 19:50:40 -0400 Received: from bldp.1qr17l2.net [45.19.166.175] by dsl-201-128-15-56.prod-infinitum.com.mx id <1610712-16028>; Thu, 08 Apr 2004 02:47:10 +0200 Message-ID: <6--9vav-723p--z$kf05f70624la9@3r8.35.lt> From: "Admin" To: eap-archive@ietf.org Subject: ADV: Attention All Nonprofit Orgs: (Members, Staff and Associates): Date: Thu, 08 Apr 04 02:47:10 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C.8E3A9A7AF.1.5E72EA221" 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.7 required=5.0 tests=ADVERT_CODE, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,SUBJ_HAS_SPACES, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook This is a multi-part message in MIME format. --C.8E3A9A7AF.1.5E72EA221 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations, Members, Staff and Associates: You Must Respond By 5 P.M. Friday, April 9, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Members, Staff and Associates who respond to this message before 5 P.M., Friday, April 9, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, April 9, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --C.8E3A9A7AF.1.5E72EA221-- From ewommscvkschck@worldnet.att.net Thu Apr 8 00:58:42 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 AAA17969 for ; Thu, 8 Apr 2004 00:58:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRch-000315-00 for eap-archive@ietf.org; Thu, 08 Apr 2004 00:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBPKN-0004XR-00 for eap-archive@ietf.org; Wed, 07 Apr 2004 22:31:39 -0400 Received: from [80.41.101.15] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BBNtp-0007Pt-00; Wed, 07 Apr 2004 21:00:10 -0400 From: "Jerald Johns" To: Subject: Get all meds here. Any Pills You Want. No prescription. Discreet. Secure Date: Wed, 07 Apr 2004 22:56:48 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4414030554758420394" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.52f) Business 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=19.7 required=5.0 tests=BIZ_TLD,FORGED_MUA_THEBAT, FORGED_MUA_THEBAT_BOUN,FORGED_THEBAT_HTML,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,MSGID_FROM_MTA_SHORT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 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.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.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 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 * 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 ----4414030554758420394 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

YourDrugsHere offers online prescriptions for FDA-approved medication. Upon approval a prescription will be issued for an FDA-approved medication of your choice.

Absolutely No Doctor Appointment Needed!

Order by 2 pm EST and you get your meds tomorrow.

Get your meds here

Wencyclopedic picky flush obelisk bunt epitaph burdensome device cradle osmotic maria hug astound danger annal : Vcolette porte devolution canine becky passerby costello isocline affirmation deplete ? Orutherford quarry astarte formaldehyde divergent zebra garrett socratic apparel constitution apices trenton

If this notice has reached you in error, please notify us by clicking here ----4414030554758420394-- From supfjqc@fp.net.cn Thu Apr 8 01:27:07 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 BAA21967 for ; Thu, 8 Apr 2004 01:27:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBS49-0007Uh-00 for eap-archive@ietf.org; Thu, 08 Apr 2004 01:27:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBQ85-0000vn-00 for eap-archive@ietf.org; Wed, 07 Apr 2004 23:23:03 -0400 Received: from [203.253.22.148] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BBOHs-0003oT-00 for eap-archive@ietf.org; Wed, 07 Apr 2004 21:25:01 -0400 Received: from 239.104.84.246 by 203.253.22.148; Thu, 08 Apr 2004 01:21:42 -0100 Message-ID: From: "Marquita Mccarty" Reply-To: "Marquita Mccarty" To: eap-archive@ietf.org Subject: Collection Action Pending Date: Thu, 08 Apr 2004 04:19:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--439131604087160" X-Originating-IP: 132.151.6.1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----439131604087160 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 118.114.216.56 Y

 

We're looking for people who are serious= about being paid for their opinions

sign up here

 

 

 

to get off our database follow this link

deuteron assailant pomade freehold boatyard = commingle relict minsky traffic generic referential actual trademark puny = breadfruit trojan adverbial quicksilver texas compositor deciduous delicac= y gourd germ arteriosclerosis bronchial=20 fascinate doom milkweed deceitful= effeminate pitt seizure tungsten structural newsboy bridgehead brenner bu= ddy cleave benelux bordello beer iodide crumple=20 dollar midway anastigmat bold hadrian co= unterargument gravel condone davidson absorption demiscible serpent woodca= rver shakeable polka opec converse stolid brutal jejune deactivate frontie= rsman parson buckboard copperfield liverpool colorado transferral excommun= icate backscatter thermal bater hydrometer flo=20 incaution butt doodle subsume cheer complem= entarity friable inquest kruse noreen diabetes paramedic allot delirium bi= ometrika beech redbud sextuplet agleam desideratum=20 bipartite storage drury gustav promotion w= hirlwind yapping catchy puerto medley monologist=20 perspective charlotte beloit sisal s= tuff guiana pancho disgustful duly baseline wean trichinella coddington le= ather cardboard insouciant biharmonic dramatic phenotype cypress=20 ----439131604087160-- From eap-admin@frascone.com Thu Apr 8 08:41:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11892 for ; Thu, 8 Apr 2004 08:41:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E72BF204D9; Thu, 8 Apr 2004 08:29:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D8282036F; Thu, 8 Apr 2004 08:29:24 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C06A32036F for ; Thu, 8 Apr 2004 08:28:32 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id C48702021D for ; Thu, 8 Apr 2004 08:28:30 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 14:40:02 +0200 Received: from rd.francetelecom.fr ([10.193.167.70]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Apr 2004 14:40:00 +0200 Message-ID: <40754857.6060108@rd.francetelecom.fr> From: Florent Bersani 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" Subject: Re: [eap] Issue 235: (Key Framework) Rewrite of Section 1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 12:40:00.0915 (UTC) FILETIME=[9BB0EE30:01C41D66] 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, 08 Apr 2004 14:40:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard, I have concerns with the current wording of section 1.4.1 of the Key management framework: it seems to me as though it hinders the channel binding capability (please see the thread on Jari and Pasi's new I-D on authenticated service identities) - since to provide channel binding, EAP methods precisely need to transfer media specific information (though in a possibly media agnostic framework like the aforementioned draft). I understand (and subscribe to) the fact that EAP methods should be media agnostic in their design. However, a possible way to do so is precisely to define appropriate elements for every media type (although this probably means quite a lot of work for now and the future). I would thus rather have something like: "Should an EAP method have knowledge of the lower layer over which it is transported and should it wish to utilize identifiers associated with a particular media environment - for instance to provide channel binding, it MAY do so but it SHOULD support all media types EAP is commonly run over to avoid specializing EAP to a particular media type". Cheers, Florent Bernard Aboba wrote: >Issue 235: Rewrite of Section 1 >Submitter name: Bernard Aboba >Submitter email address: aboba@internaut.com >Date first submitted: 4/3/2004 >Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02.txt >Document: Keying-01 >Comment type: T/E >Priority: S >Section: 1 >Rationale/Explanation of issue: > >... >1.4.1. Media Independence > > One of the goals of EAP is to allow EAP methods to function on any > lower layer meeting the criteria outlined in [RFC3748], Section 3.1. > For example, as described in [RFC3748], EAP authentication can be run > over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE > 802.11 wireless LANs [IEEE80211i]. > > In order to maintain media independence, it is necessary for EAP to > avoid inclusion of media-specific elements. For example, EAP methods > cannot be assumed to have knowledge of the lower layer over which > they are transproted, and cannot utilize identifiers associated with > a particular usage environment (e.g. MAC addresses). > > The need for media independence has also motivated the development of > the three phase exchange. Since discovery is typically media- > specific, this function is handled outside of EAP, rather than being > incorporated within it. Similarly, the Secure Association Protocol > often contains media dependencies such as negotiation of media- > specific ciphersuites or session parameters, and as a result this > functionality also cannot be incorporated within EAP. > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 8 08:42:31 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12020 for ; Thu, 8 Apr 2004 08:42:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78160205E7; Thu, 8 Apr 2004 08:30:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70B23203DF; Thu, 8 Apr 2004 08:30:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D06A203BC for ; Thu, 8 Apr 2004 08:29:11 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 377A42036F for ; Thu, 8 Apr 2004 08:29:09 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 14:40:58 +0200 Received: from rd.francetelecom.fr ([10.193.167.70]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Apr 2004 14:40:56 +0200 Message-ID: <4075488E.7020008@rd.francetelecom.fr> From: Florent Bersani 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" Subject: Re: [eap] Issue 236: (Key Framework) Rewrite of Section 2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 12:40:56.0541 (UTC) FILETIME=[BCD8C8D0:01C41D66] 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, 08 Apr 2004 14:41:50 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, Some (minor) comments in-line. Florent Bernard Aboba wrote: >Issue 236: Rewrite of Section 2 >Submitter name: Bernard Aboba >Submitter email address: aboba@internaut.com >Date first submitted: 4/3/2004 >Reference: >Document: Keying-01 >Comment type: T/E >Priority: S >Section: 2 >Rationale/Explanation of issue: > > > >... >2.2. Key Hierarchy > > The EAP Key Hierarchy, illustrated in Figure 3 below, includes three > types of keys: > > Well, I see four types of keys > [1] Keys calculated locally by the EAP method but not exported, > such as the TEKs. > [2] Keys exported by the EAP method: MSK, EMSK, IV > >and > keys calculated from exported quantities: AAA-Key. > > Shouldn't this be a (logically) separated type? > [3] Keys calculated by the Secure Association Protocol: TSKs. > > In order to protect some or all of the EAP conversation, EAP methods > supporting key derivation typically negotiate a ciphersuite and > derive Transient EAP Keys (TEKs) to provide keys for that > ciphersuite. However, the TEKs are stored locally within the EAP > method and are not exported. > > Does this preclude TEK caching? My answer is no. Is clarification required to specify what does "be exported" and "not be exported" mean? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 8 08:45:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12444 for ; Thu, 8 Apr 2004 08:45:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCDDD204F1; Thu, 8 Apr 2004 08:33:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33BE12036F; Thu, 8 Apr 2004 08:33:24 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68BC9204D9 for ; Thu, 8 Apr 2004 08:32:18 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 70842203DF for ; Thu, 8 Apr 2004 08:32:16 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 14:44:04 +0200 Received: from rd.francetelecom.fr ([10.193.167.70]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Apr 2004 14:44:03 +0200 Message-ID: <40754949.50609@rd.francetelecom.fr> From: Florent Bersani 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: jari.arkko@piuha.net, Pasi Eronen Cc: "eap@frascone.com" Subject: Re: [eap] draft on authenticated service identities References: <406D630C.6080700@piuha.net> In-Reply-To: <406D630C.6080700@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 12:44:03.0388 (UTC) FILETIME=[2C375FC0:01C41D67] 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, 08 Apr 2004 14:44:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Four very quick comments: 1) Many thanks for writing this draft! Indeed, while designing an EAP method or reviewing the existing ones, I formed the strong belief that much work could be saved (and better quality obtained) if EAP methods had a common pool from which they could pick up "standard" functions - such as channel binding - and focus on their specifics - such as the cryptographic parts. This belief echoes what Joe once proposed (EAP-TLV). I'll thus simply include a corresponding TLV and a reference to your draft on authenticated service identities in EAP-PSK to implement channel binding :-) 2) I agree that more discussion is needed regarding the parameters. For instance, I object with having WPA and 802.11i gathered to a single parameter value in section 3.3.4 page 8. it might prove important to differentiate between TKIP only and CCMP in the near future. In general more granularity could be provided for this section (not only WPA vs 802.11i but perhaps also the unicast, group and AKM Ciphersuites). I'll try and provide a proposition for more detailed parameters - maybe input from IEEE 802.11i members could help? 3) Could and should the same work be done with error messages? 4) Your draft seems to collide with EAP media independence (at least from a wording point of view). Please see Bernard's mail below. Cheers, Florent ------- Original Message -------- Subject: [eap] Issue 235: (Key Framework) Rewrite of Section 1 Date: Sat, 3 Apr 2004 15:45:13 -0800 (PST) From: Bernard Aboba To: eap@frascone.com 1.4.1. Media Independence One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 802.11 wireless LANs [IEEE80211i]. In order to maintain media independence, it is necessary for EAP to avoid inclusion of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transproted, and cannot utilize identifiers associated with a particular usage environment (e.g. MAC addresses). Jari Arkko wrote: > > Pasi and I have written a draft on the authentication > of service identities (= service parameters claimed > by access servers) in EAP. Essentially, the draft > is an extension of EAP-TLS, EAP-SIM, EAP-AKA, and PEAPv2 > for transporting and authenticating parameters related > to the offered service. This makes it possible to ensure, > for instance, that everyone agrees about the claimed SSID > or that a compromised access point can not present itself > as an IKEv2 gateway. > > Here's the abstract: > > A common arrangement in network access is the separation of the > actual network access device (such as a wireless LAN access point) > from the authentication servers. In the Extensible Authentication > Protocol (EAP) framework, different authentication methods can > provide varying security properties. If the EAP methods support > authentication of service identities, it becomes possible for the > clients to verify not only that the access device is trusted, but > also that the parameters advertised by the access device are correct. > This document specifies a backward compatible extension to popular > EAP methods for supporting such service identity authentication. A > common parameter name space is created in order to ensure that the > same parameters can be communicated independent of the choice of the > authentication method. > > The draft has been submitted, but before it appears > in the official directories, you can access it from > the following URLs: > > > http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.txt > > > http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.html > > > Comments are appreciated. > > --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 Apr 8 09:45:24 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14769 for ; Thu, 8 Apr 2004 09:45:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ABBD205E0; Thu, 8 Apr 2004 09:33:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5C0F203EB; Thu, 8 Apr 2004 09:33:23 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CAAB52042C for ; Thu, 8 Apr 2004 09:32:03 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D14FA203EB for ; Thu, 8 Apr 2004 09:32:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i38Douh24122; Thu, 8 Apr 2004 06:50:56 -0700 From: Bernard Aboba To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Issue 235: (Key Framework) Rewrite of Section 1 In-Reply-To: <40754857.6060108@rd.francetelecom.fr> Message-ID: References: <40754857.6060108@rd.francetelecom.fr> 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, 8 Apr 2004 06:50:56 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I would thus rather have something like: "Should an EAP method have > knowledge of the lower layer over which it is transported and should it > wish to utilize identifiers associated with a particular media > environment - for instance to provide channel binding, it MAY do so but > it SHOULD support all media types EAP is commonly run over to avoid > specializing EAP to a particular media type". Media independence is one of the fundamental properties of EAP. It is not a "nice to have". Had this advice been taken in 1998 when EAP was first implemented, operation over 802.11 would not be possible today since that was not one of the media on which EAP was commonly run over at the time. Similarly, 802.16 is not common today, but it has adopted EAP as its authentication framework. I am not aware of a case in which media independence needs to be compromised in order to provide for identification or channel binding. For example, an EAP method need not necessarily be aware of the content of an Identifier in order to use it. In terms of channel binding, it can pass the Called or Calling-Station-Id to the AAA server as an opaque blob and receive back a confirmation of whether it matched or not, again without having knowledge of media. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 8 11:07:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25797 for ; Thu, 8 Apr 2004 11:07:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 745DB204F6; Thu, 8 Apr 2004 10:55:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78B6C204A3; Thu, 8 Apr 2004 10:55:24 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AEE5204A3 for ; Thu, 8 Apr 2004 10:54:42 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 5008720247 for ; Thu, 8 Apr 2004 10:54:40 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 17:06:14 +0200 Received: from rd.francetelecom.fr ([10.193.167.70]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Apr 2004 17:06:13 +0200 Message-ID: <40756A9C.2030300@rd.francetelecom.fr> From: Florent Bersani 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" Subject: Re: [eap] Issue 235: (Key Framework) Rewrite of Section 1 References: <40754857.6060108@rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 15:06:13.0990 (UTC) FILETIME=[08D9F060:01C41D7B] 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, 08 Apr 2004 17:07:08 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>I would thus rather have something like: "Should an EAP method have >>knowledge of the lower layer over which it is transported and should it >>wish to utilize identifiers associated with a particular media >>environment - for instance to provide channel binding, it MAY do so but >>it SHOULD support all media types EAP is commonly run over to avoid >>specializing EAP to a particular media type". >> >> > >Media independence is one of the fundamental properties of EAP. It is not >a "nice to have". > > I agree, apologies if my wording offended you. >Had this advice been taken in 1998 when EAP was first implemented, >operation over 802.11 would not be possible today since that was not one >of the media on which EAP was commonly run over at the time. > >Similarly, 802.16 is not common today, but it has adopted EAP as its >authentication framework. > > I totally agree - at least for the ongoing revision of 802.16 since the original standard does not use EAP at all, as you know >I am not aware of a case in which media independence needs to be >compromised in order to provide for identification or channel binding. >For example, an EAP method need not necessarily be aware of the content >of an Identifier in order to use it. In terms of channel binding, it can >pass the Called or Calling-Station-Id to the AAA server as an opaque blob >and receive back a confirmation of whether it matched or not, again >without having knowledge of media. > > > Let's rephrase: my point was that to the naive reader that I am, the media independence seemed to contradict the channel binding. If this is not the case (which I do hope and believe), then some clarification might be needed. The text you very kindly provided might be well suited to do so... My only question (which does not belong to EAP) is more of a trivial conclusion on implementations: for the EAP method to pass the opaque blob containing the Called or Calling-Station-Id, it first needs to get that blob. Hence, we need here some communication between the EAP method and something that is aware of the media over which EAP is being run, don't we? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 8 15:04:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12002 for ; Thu, 8 Apr 2004 15:04:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A36471FF5F; Thu, 8 Apr 2004 14:52:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 716CE1FF6D; Thu, 8 Apr 2004 14:52:24 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D0DB20524 for ; Thu, 8 Apr 2004 14:51:05 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 6A75120522 for ; Thu, 8 Apr 2004 14:51:03 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2004 12:03:41 -0700 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 i38J2eBB010909; Thu, 8 Apr 2004 12:02:40 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.240.24]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 12:09:16 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" , "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 235: (Key Framework) Rewrite of Section 1 Message-ID: <002c01c41d9c$1031f670$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <40756A9C.2030300@rd.francetelecom.fr> X-OriginalArrivalTime: 08 Apr 2004 19:09:17.0252 (UTC) FILETIME=[FD272040:01C41D9C] 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, 8 Apr 2004 12:02:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Florent Bersani > Sent: Thursday, April 08, 2004 8:07 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Issue 235: (Key Framework) Rewrite of Section 1 >=20 >=20 >=20 >=20 > Bernard Aboba wrote: >=20 > >>I would thus rather have something like: "Should an EAP method have=20 > >>knowledge of the lower layer over which it is transported=20 > and should=20 > >>it wish to utilize identifiers associated with a particular media=20 > >>environment - for instance to provide channel binding, it MAY do so=20 > >>but it SHOULD support all media types EAP is commonly run over to=20 > >>avoid specializing EAP to a particular media type". > >> =20 > >> > > > >Media independence is one of the fundamental properties of=20 > EAP. It is=20 > >not a "nice to have". > > =20 > > > I agree, apologies if my wording offended you. >=20 > >Had this advice been taken in 1998 when EAP was first implemented,=20 > >operation over 802.11 would not be possible today since that was not=20 > >one of the media on which EAP was commonly run over at the time. > > > >Similarly, 802.16 is not common today, but it has adopted EAP as its=20 > >authentication framework. > > =20 > > > I totally agree - at least for the ongoing revision of 802.16=20 > since the=20 > original standard does not use EAP at all, as you know >=20 > >I am not aware of a case in which media independence needs to be=20 > >compromised in order to provide for identification or=20 > channel binding.=20 > >For example, an EAP method need not necessarily be aware of=20 > the content=20 > >of an Identifier in order to use it. In terms of channel=20 > binding, it=20 > >can pass the Called or Calling-Station-Id to the AAA server as an=20 > >opaque blob and receive back a confirmation of whether it matched or=20 > >not, again without having knowledge of media. > > > > =20 > > > Let's rephrase: my point was that to the naive reader that I am, the=20 > media independence seemed to contradict the channel binding.=20 > If this is=20 > not the case (which I do hope and believe), then some clarification=20 > might be needed. The text you very kindly provided might be=20 > well suited=20 > to do so... >=20 > My only question (which does not belong to EAP) is more of a trivial=20 > conclusion on implementations: for the EAP method to pass the opaque=20 > blob containing the Called or Calling-Station-Id, it first=20 > needs to get=20 > that blob. Hence, we need here some communication between the=20 > EAP method=20 > and something that is aware of the media over which EAP is being run,=20 > don't we? >=20 [Joe] Yes, there needs to be a communication between EAP, which does authentication, and the party(s) responsible for authorization. There = needs to be some data exported out of the EAP method to accomplish this such = as authenticated identity and channel binding information. The = authorization piece would need to be aware of what the parties communication is trying = to do. =20 =20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 9 01:25:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28390 for ; Fri, 9 Apr 2004 01:25:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C886202A5; Fri, 9 Apr 2004 01:13:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 701D0202B0; Fri, 9 Apr 2004 01:13:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53228202B7 for ; Fri, 9 Apr 2004 01:12:18 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 2E7D8202B0 for ; Fri, 9 Apr 2004 01:12:16 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2004 22:25:01 -0700 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 i395NsBB008779; Thu, 8 Apr 2004 22:23:55 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.240.24]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 22:30:29 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Rewrite of Key Framework Section 3 Message-ID: <007d01c41df2$d87676f0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 09 Apr 2004 05:30:30.0157 (UTC) FILETIME=[C58913D0:01C41DF3] 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, 8 Apr 2004 22:23:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable It is often difficult to exactly define various security relationships, = but here is an attempt at some terminology: A security association (SA) is state shared explicitly for the purpose = of providing secure communication between parties. The state contains the = key material as well as the cryptographic and other parameters required for securing the communication. SAs are often (perhaps always?) established dynamically. Security Anchor is information required to bind data to a particular cryptographic key or to verify the binding of data to a particular cryptographic key. Examples of anchors are shared secret keys and = public key pairs. Security anchors enable security association establishment = and other security services. =20 Based on the above I modified the text inline below: eap-admin@frascone.com wrote: > I'm not posting this as an issue or resolution yet, since the > text needs quite a bit more work. But here is the strawman > text of Section 3. Comments welcome. >=20 > 3. Security Associations >=20 > EAP key management involves five types of security associations =20 > (SAs):=20 >=20 [Joe] Use security relationships instead of security association > [1] EAP SA. This is an SA between the peer and EAP server, which > allows them to authenticate each other. >=20 [Joe] EAP Security Anchor is information shared between peer and EAP = server, which allows them to authenticate to each other. > [2] EAP method SA. This SA is also between the peer and EAP server. > It stores state that can be used for "fast resume" or other > functionality in some EAP methods. Not all EAP methods > create such > an SA. [Joe] All key deriving methods establish some sort of SA during their operation. In many cases the SA is transient and used solely for the purpose of establishing key material which provides a security anchor = for future service or application SAs. Some EAP methods maintain the SA = state for the purpose of "fast resume" >=20 > [3] EAP-Key SA. This is an SA between the peer and EAP server, which > is used to store the keying material exported by the EAP method. > Current EAP server implementations do not retain this SA > after the > EAP conversation completes, but future implementations could use > this SA for pre-emptive key distribution. > [Joe] The EAP-Key security anchor is shared key material exported as the = MSK and EMSK from the EAP method. From this EAP-Key security anchor = application specific security anchors are derived for the purpose of establishing service or application SAs=20 =20 >=20 > [4] AAA SA(s). These SAs are between the authenticator and > the backend > authentication server. They permit the parties to mutually > authenticate each other and protect the communications between =20 > them.=20 > [Joe] In general this is OK. The two must share an anchor as well. The RADIUS SA is actually ambiguous between security association and = security anchor. I suppose in the RADIUS case the are either the same or each = RADIUS exchange is a new SA. =20 > [5] Service SA(s). These SAs are between the peer and authenticator, > and they are created as a result of phases 1-2 of the > conversation (see Section 1.3). >=20 [Joe] I've been using the term application, but I think service is a = good alternative. > 3.1. EAP SA (peer - EAP server) [Joe] Security Anchor >=20 > In order for the peer and EAP server to authenticate each > other, they > need to store some information. >=20 > The authentication can be based on different mechanisms, such as > shared secrets or certificates. If the authentication is > based on a > shared secret key, the parties store the EAP method to be used and > the key. The EAP server also stores the peer's identity > and/or other > information necessary to decide whether access to some > service should > be granted. The peer stores information necessary to choose which > secret to use for which service. >=20 > 3.2. EAP Method SA (peer - EAP server) > [Joe] An EAP method typically establishes a security association during = its operation. This SA is often transient in nature and torn down after the EAP-Key material is exchanged. The key material used to form the EAP = Method SA is never exported out of the method, only the MSK and EMSK = established through the EAP Method SA are exported from the method. =20 (The rest of the text is probably fine, but it may contains more detail = than necessary and is somewhat out of scope.) > An EAP method may store some state on the peer and EAP server even > after phase 1a has completed. >=20 > Typically, this is used for "fast resume": the peer and EAP server > can confirm that they are still talking to the same party, perhaps > using fewer roundtrips or less computational power. In this case, > the EAP method SA is essentially a cache for performance > optimization, and either party may remove the SA from its cache at > any point.=20 >=20 > An EAP method may also keep state in order to support > pseudonym-based identity protection. This is typically a cache as > well (the information can be recreated if the original EAP method > SA=20 > is lost), > but may be stored for longer periods of time. >=20 > The EAP method SA is not restricted to a particular service or > authenticator and is most useful when the peer accesses many =20 > different authenticators.=20 >=20 > An EAP method is responsible for specifying how the > parties select if > an existing EAP method SA should be used, and if so, which one. > Where multiple backend authentication servers are used, EAP method > SAs are not typically synchronized between them. >=20 > EAP method implementations should consider the appropriate lifetime > for the EAP method SA. "Fast resume" assumes that the information > required (primarily the keys in the EAP method SA) hasn't been > compromised. In case the original authentication was carried out > using, for instance, a smart card, it may be easier to > compromise the > EAP method SA (stored on the PC, for instance), so > typically the EAP > method SAs have a limited lifetime. >=20 > Contents: >=20 > o Implicitly, the EAP method this SA refers to > o One or more internal (non-exported) keys > o EAP method SA name > o SA lifetime >=20 > 3.2.1. Example: EAP-TLS >=20 > In EAP-TLS [RFC2716], after the EAP authentication the > client (peer) > and server can store the following information: >=20 > o Implicitly, the EAP method this SA refers to (EAP-TLS) > o Session identifier (a value selected by the server) > o Certificate of the other party (server stores the clients's > certificate and vice versa) > o Ciphersuite and compression method > o TLS Master secret (known as the EAP-TLS Master Key or MK) > o SA lifetime (ensuring that the SA is not stored forever) > o If the client has multiple different credentials > (certificates and corresponding private keys), a pointer to > those credentials=20 >=20 > When the server initiates EAP-TLS, the client can look up > the EAP-TLS > SA based on the credentials it was going to use (certificate and > private key), and the expected credentials (certificate or name) of > the server. If an EAP-TLS SA exists, and it is not too old, the > client informs the server about the existence of this SA > by including > its Session-Id in the TLS ClientHello message. The server > then looks > up the correct SA based on the Session-Id (or detects that > it doesn't > yet have one). >=20 > 3.2.2. Example: EAP-AKA >=20 > In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the > client and server can store the following information: >=20 > o Implicitly, the EAP method this SA refers to (EAP-AKA) > o A re-authentication pseudonym > o The client's permanent identity (IMSI) (server) > o Replay protection counter > o Authentication key (K_aut) > o Encryption key (K_encr) > o Original Master Key (MK) > o SA lifetime (ensuring that the SA is not stored forever) >=20 > When the server initiates EAP-AKA, the client can look up > the EAP-AKA > SA based on the credentials it was going to use (permanent > identity). If an EAP-AKA SA exists, and it is not too old, the > client informs the server about the existence of this SA by > sending its re- authentication pseudonym as its identity in EAP > Identity Response message, instead of its permanent identity. The > server=20 > then looks up > the correct SA based on this identity. >=20 > 3.3. EAP-key SA >=20 [Joe] The EAP-Key security anchor is shared key material exported as the = MSK and EMSK from the EAP method. From this EAP-Key security anchor = application (service) specific security anchors are derived for the purpose of establishing service or application SAs. Additional information is associated with the EMSK and the MSK to form the security anchor = including a name for the MSK/EMSK and attributes determined during the EAP method execution such as the Peer and Server identities. =20 (I'm not sure it makes sense to list the contents of Sas in general) > This is an SA between the peer and EAP server, which is > used to store > the keying material exported by the EAP method. Current EAP server > implementations do not retain this SA after the EAP conversation > completes, but future implementations could use this SA for pre- =20 > emptive key distribution.=20 >=20 > Contents: > o Name/identifier for this SA > o Identities of the parties > o MSK and EMSK >=20 > 3.4. AAA SA(s) (authenticator - backend auth. server) >=20 > In order for the authenticator and backend authentication server to > authenticate each other, they need to store some information. >=20 > In case the authenticator and backend authentication server are > colocated, and they communicate using local procedure > calls or shared > memory, this SA need not necessarily contain any information. (I'm not sure it makes sense to list the contents of Sas in general) >=20 > 3.4.1. Example: RADIUS >=20 > In RADIUS, where shared secret authentication is used, the > client and > server store each other's IP address and the shared > secret, which is > used to calculate the Response Authenticator [RFC2865] and Message- > Authenticator [RFC3579] values, and to encrypt some > attributes (such > as the AAA-Key [RFC2548]). >=20 > Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for > key management, the parties store information necessary to > authenticate and authorize the other party (e.g. > certificates, trust > anchors and names). The IKE exchange results in IKE Phase 1 and > Phase 2 SAs containing information used to protect the conversation > (session keys, selected ciphersuite, etc.) >=20 > 3.4.2. Example: Diameter with TLS >=20 > When using Diameter protected by TLS, the parties store information > necessary to authenticate and authorize the other party (e.g. > certificates, trust anchors and names). The TLS handshake > results in > a short-term TLS SA that contains information used to protect the > actual communications (session keys, selected TLS > ciphersuite, etc.). >=20 [Joe] ( I don't understand why there is a section 3.5 and 3.6. It seems = to inconsistent with the earlier text. I think this should be combined = into a single section that talks about Application specific SAs with link layer encryption as an example. Perhaps we should move all the examples to the appendix) > 3.5. Secure Association SAs >=20 [Joe] Application (Service) security associations are established = between parties using application specific security anchors derived from the = EAP-Key security anchor. These security associations are established in an application specific way. The most widely used application for EAP key material is link layer secure communication. The following sections describe some general detail of the SA used for this purpose. =20 (somewhere in the document we need a general description on how key must = be derived and recommendations on how they be used. It probably doesn't = belong in this section.) > 3.5.1. Unicast Secure Association SA [Joe] 3.5.1 Link Layer unicast application security association >=20 > The unicast Secure Association SA exists between the EAP peer and > authenticator. It includes: >=20 > o the peer port identifier (Calling-Station-Id) > o the NAS port identifier (Called-Station-Id) > o the unicast Transient Session Keys (TSKs) > o the unicast Secure Association peer nonce > o the unicast Secure Association authenticator nonce > o the negotiated unicast capabilities and unicast ciphersuite. > [Joe] (Replace AAA-Key below with application (service) key ) =20 > During the phase 2a exchange, the EAP peer and authenticator > demonstrate mutual possession of the AAA-Key derived and > transported in phase 1; securely negotiate the session > capabilities (including unicast ciphersuites), and derive fresh > unicast transient session keys. The AAA-Key SA (phase 1b) is > therefore used to create the unicast Secure Association SA (phase > 2a), and in the process the phase 2a unicast Secure Association SA > is bound to ports on the EAP peer and authenticator. However in > order for a phase 2a security association to be established, it is > not necessary for the phase 1a exchange to be rerun each time.=20 > This enables the EAP=20 > exchange to be > bypassed when fast handoff support is desired. >=20 > Since both peer and authenticator nonces are used in the > creation of > the unicast Secure Association SA, the transient session > keys (TSKs) > are guaranteed to be fresh, even if the AAA-Key is not. > As a result > one or more unicast Secure Association SAs (phase 2a) may > be derived > from a single AAA-Key SA (phase 1b). The phase 2a security > associations may utilize the same security parameters (e.g. mode, > ciphersuite, etc.) or they may utilize different parameters. >=20 > A unicast Secure Association SA (phase 2a) may not persist longer > than the maximum lifetime of its parent AAA-Key SA (if known). > However, the deletion of a parent EAP or AAA-Key SA does not > necessarily imply deletion of the corresponding unicast secure > association SA. Similarly, the deletion of a unicast secure > Association Protocol SA does not imply the deletion of the parent > AAA-key SA or EAP SA. Failure to mutually prove possession of the > AAA-Key during the unicast Secure Association Protocol exchange > (phase 2a) need not be grounds for removal of a AAA-Key SA by both > parties; rate-limiting unicast Secure Association exchanges should > suffice to prevent a brute force attack. >=20 > An EAP peer may be able to negotiate multiple phase 2a SAs with a > single EAP authenticator, or may be able to maintain multiple phase > 2a SAs with multiple authenticators, based on a single EAP > SA derived > in phase 1a. For example, during a re-key of the Secure Association > protocol SA, it is possible for two phase 2a SAs to exist > during the > period between when the new phase 2a SA parameters (such > as the TSKs) > are calculated and when they are installed. Except where > explicitly specified by the semantics of the unicast Secure > Association protocol, it should not be assumed that the > installation of a new phase 2a SA necessarily implies deletion of > the old phase 2a SA.=20 >=20 > On some media (e.g. 802.11) a port on an EAP peer may only > establish phase 2a and 2b SAs with a single port of an > authenticator within a given Local Area Network (LAN). This > implies that the successful negotiation of phase 2a and/or 2b SAs > between an EAP peer=20 > port and a > new authentiator port within a given LAN implies the deletion of > existing phase 2a and 2b SAs with authenticators offering access to > that Local Area Network (LAN). However, since a given IEEE 802.11 > SSID may be comprised of multiple LANs, this does not imply an > implicit binding of phase 2a and 2b SAs to an SSID. >=20 [Joe] (do we really need to talk about multicast Sas? What does this = add?) > 3.5.2. Multicast Secure Association SA >=20 > The multicast Secure Association SA includes: >=20 > o the multicast Transient Session Keys > o the direction vector (for a uni-directional SA) > 0 the negotiated multicast capabilities and multicast > ciphersuite=20 >=20 >=20 > It is possible for more than one multicast Secure Association SA to > be derived from a single unicast Secure Association SA. > However, a > multicast Secure Association SA is bound to a single EAP SA and a=20 > single AAA-Key SA.=20 >=20 > During a re-key of the multicast Secure Association Protocol SA, it > is possible for two phase 2b SAs to exist during the period between > when the new phase 2b SA parameters (such as the multicast > TSKs) are > calculated and when they are installed. Except where explicitly > specified by the semantics of the multicast Secure Association > protocol, it should not be assumed that the installation of a new > phase 2b SA necessarily implies deletion of the old phase 2b SA. >=20 > A multicast Secure Association SA (phase 2b) may not persist longer > than the maximum lifetime of its parent AAA-Key or unicast secure > association SA. However, the deletion of a parent EAP, AAA-Key or > unicast Secure Association SA does not necessarily imply > deletion of > the corresponding multicast Secure Association SA. For example, a > unicast Secure Association SA may be rekeyed without > implying a rekey > of the multicast Secure Association SA. >=20 > Similarly, the deletion of a multicast Secure Association > Protocol SA > does not imply the deletion of the parent EAP, AAA-Key or unicast > Secure Association SA. Failure to mutually prove possession of the > AAA-Key during the unicast Secure Association Protocol exchange > (phase 2a) need not be grounds for removal of the AAA-Key, unicast > Secure Association and multicast Secure Association SAs; rate- > limiting unicast Secure Association exchanges should suffice to > prevent a brute force attack. > [Joe] ( this section is very specific to the application of link layer security and should be identified as such.) =20 > 3.6. Service SA(s) (peer - authenticator) >=20 > The service SA stores information about the service being > provided. This includes:=20 >=20 > o Service parameters (or at least those parameters > that are still needed) > o On the authenticator, service authorization > information received from the backend authentication > server (or necessary parts of it) > o On the peer, usually locally configured service > authorization information. > o Transient Session Keys used to protect the communication > o The AAA-Key, if it can be needed again (to refresh > (and/or resynchronize other keys or for another reason) >=20 > The information in the service SA can be grouped into several > different SAs. This would make sense if, for instance, the service > provided is naturally divided into several different > subconversations with different parameters. >=20 > How exactly the relevant service SA is chosen at each point depends > on the protocol; see below for examples. >=20 > 3.6.1. Example: 802.11i >=20 > Note that this example is intended to be informative, and > it does not > necessarily include all information stored. >=20 > o PMKSA >=20 > - Key (PMK) > - PMKID > - SSID > - Supplicant and authenticator group addresses (PMKSA can be > used if the SSID and group addresses stay the same) > - Key replay counters (for EAPOL-Key messages) > - Lifetime information (that can be different client and AP) >=20 > - Reference to PTKSA (if any), needed for: > - to delete it (e.g. AAA server-initiated disconnect) > - to replace it when a new four-way handshake is done > after reauthentication >=20 > - Authorization information. On the authenticator, this > can be locally configured or received from the backend > authentication server. On the peer, this is usually =20 > locally configured.=20 >=20 > - Reference to accounting context (the details of which depend > on the accounting protocol used, and various implementation > and administrative details. In RADIUS, this could include > (e.g. packet and octet counters, and Acct-Multi-Session-Id). >=20 > o PTKSA >=20 > The PTKSA is created based on the four-way handshake. > When receiving > or sending a packet, the correct PTKSA is looked up based on TA and > RA (Transmitter/Received Address). >=20 > - Key (PTK) > - Selected ciphersuite > - MAC addresses of the parties > - Replay counters, and ciphersuite specific state > - Reference to PMKSA: This is needed for > - If a new four-way handshake is needed (lifetime, TKIP > countermeasures), we need to know which PMKSA to use > - Via the reference to PMKSA, or copied here: > - SSID (to select VLAN tags) > - Authorization information (such as L2 packet filters) > - Reference to accounting context (right counters etc.) >=20 > o GTKSA >=20 > The GTKSA is created based on the four-way handshake, or > the four-way > handshake and a separate group key handshake. When receiving a > packet, the correct GTKSA is looked up based on source MAC address. >=20 > When sending a packet, this is looked up by own MAC > address and SSID. >=20 > - Direction bit > - Key (GTK) > - Sender (AP) MAC address > - Selected cipher suite > - Ciphersuite-specific data > - Via reference to PMKSA, or copied here: > - SSID (to select VLAN tags) > - Reference to accounting context >=20 > 3.6.2. Example: IKEv2/IPsec >=20 > Note that this example is intended to be informative, and > it does not > necessarily include all information stored. >=20 > o IKEv2 SA >=20 > - Protocol version > - Identitites of the parties > - IKEv2 SPIs > - Selected ciphersuite > - Replay protection counters (Message ID) > - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) > - Key for deriving keys for IPsec SAs (SK_d) > - Lifetime information > - On the authenticator, service authorization information > received from the backend authentication server. >=20 > When processing an incoming message, the correct SA is looked > up based on the SPIs. >=20 > o IPsec SAs/SPD >=20 > - Traffic selectors > - Replay protection counters > - Selected ciphersuite > - IPsec SPI > - Keys > - Lifetime information > - Protocol mode (tunnel or transport) >=20 > The correct SA is looked up based on SPI (for inbound > packets), or SPD traffic selectors (for outbound traffic). A > separate IPsec SA exists for each direction. >=20 > 3.6.3. Sharing service SAs >=20 > A single service may be provided by multiple logical or physical > service elements. Each service is responsible for specifying how > changing service elements is handled. Some approaches include: >=20 > Transparent sharing > If the service parameters visible to the other party (either peer > or authenticator) do not change, the service can be moved without > requiring cooperation from the other party. Whether > such a move > should be supported or used depends on implementation and > administrative considerations. For instance, an administrator may > decide to configure a group of IKEv2/IPsec gateways in a cluster > for high-availability purposes, if the implementation > used supports > this. The peer does not necessarily have any way of knowing when > the change occurs.=20 >=20 > No sharing > If the service parameters require changing, some changes may > require terminating the old service, and starting a new > conversation from phase 0. This approach is used by all services > for at least some parameters, and it doesn't require any protocol > for transferring the service SA between the service elements. >=20 > The service may support keeping the old service element active > while the new conversation takes phase, to decrease the time the > service is not available. >=20 > Some sharing > The service may allow changing some parameters by simply agreeing > about the new values. This may involve a similar exchange as in > phase 2, or perhaps a shorter conversation. >=20 > This option usually requires some protocol for transferring the > service SA between the elements. An administrator may > decide not to > enable this feature at all, and typically the sharing is > restricted to some particular service elements (defined either > by a service parameter, or simple administrative decision). If > the old and new service element do not support such "context > transfer", this approach falls back to the previous option (no > transfer).=20 >=20 > Services supporting this feature should also consider > what changes > require new authorization from the backend authentication server > (see Section 1.7).=20 >=20 > Note that these considerations are not limited to service > parameters related to the authenticator--they apply to peer's =20 > parameters as well.=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 9 08:17:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24645 for ; Fri, 9 Apr 2004 08:17:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB5C01FF92; Fri, 9 Apr 2004 08:05:32 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90441203AD; Fri, 9 Apr 2004 08:05:29 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 915032054C for ; Fri, 9 Apr 2004 08:04:16 -0400 (EDT) Received: from audiogram.mail.pas.earthlink.net (audiogram.mail.pas.earthlink.net [207.217.120.253]) by mail.frascone.com (Postfix) with ESMTP id 238F3203AD for ; Fri, 9 Apr 2004 08:04:15 -0400 (EDT) Received: from user-0vvdc1q.cable.mindspring.com ([63.246.176.58] helo=firewall) by audiogram.mail.pas.earthlink.net with asmtp (Exim 3.36 #4) id 1BBuvM-0001Zw-00 for eap@frascone.com; Fri, 09 Apr 2004 05:15:56 -0700 From: "Wouter Habraken" To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQdhGYns7MjMoKVToOAybVrbufuKAACtvCw In-Reply-To: <20040408160002.3215.9391.Mailman@xavier> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-Id: X-ELNK-Trace: ef7417343d4e9a064d2b10475b5711208e86b88d8cc7a69da81af8545f8ed2769072ae4777b98cc8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM Handler Specification Published 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, 9 Apr 2004 07:23:37 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The WLAN Smart Card Consortium has published the EAP-SIM Handler specification V1.0. It is available on the consortium web site at: http://www.wlansmartcard.org/specifications.html The goal of the EAP-SIM handler specification is to ensure interoperability between client applications and SIM smart cards from different vendors. To this end, the EAP-SIM handler specification provides guidance to implementing client software that can support multiple types of SIM smart cards, including legacy SIM, WLAN-SIM and proprietary implementations. The Handler Spec complements the WLAN-SIM specification published last year which establishes interoperability between SIM smart cards that support EAP-SIM. Cheers, Wouter Habraken wouter@raaktechnologies.com Tel: 512 380 0765 Mob: 512 698 9341 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ngl_press@hotmail.com Fri Apr 9 10:55: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 KAA01575 for ; Fri, 9 Apr 2004 10:55:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxPx-0004s8-00 for eap-archive@ietf.org; Fri, 09 Apr 2004 10:55:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxOx-0004kE-00 for eap-archive@ietf.org; Fri, 09 Apr 2004 10:54:40 -0400 Received: from [218.20.51.103] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BBxMa-0004St-00; Fri, 09 Apr 2004 10:52:13 -0400 From: "Atualidade Brasileira . snw" To: dnssec-archive@ietf.org Subject: Livre-comércio: divisor de águas at.: qat 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: Fri, 09 Apr 2004 10:52:13 -0400 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.9 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, 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.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

(ref.:fud) ConstruNews deseja uma Feliz Páscoa a todos os seus amigos e suas respectivas famílias!

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (5)

"Livre-comércio, divisor de águas entre os favoráveis e os contrários à liberdade econômica"

No atual governo brasileiro, o componente ideológico que impregna setores do Itamaraty, regredindo ao terceiro-mundismo dos anos 70, os leva a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos, uma atitude irrealista e míope de nossa diplomacia, afirma Adolpho Lindenberg em recente artigo

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Em seu recente artigo "A economia de mercado e o livre-comércio", da Série Temas Patrulhados, o autor lamenta que a economia de mercado e o livre-comércio continuem sendo o alvo predileto da dialética intervencionista e progressista. Os argumentos usados se repetem como certas melodias dos clássicos realejos de antigamente, comenta Lindenberg, que em seu artigo enumera uma série dessas diatribes, das quais citamos aqui:

- Livres de quaisquer tabelamento ou fiscalização de "órgãos competentes", os preços subiriam assustadoramente, empobrecendo os consumidores, deixando-os indefesos diante da ganância dos industriais, fazendeiros, comerciantes, etc.

- A ganância dos industriais e o esmagamento das pequenas empresas incapazes de competir contra os gigantes empresariais, só sofreriam limites se o Estado intervier no mercado, via controle de preços, estatização das empresas de serviços públicos, subsídios e barreiras alfandegárias.

- O livre-comércio seria a porta de entrada dos produtos das multinacionais em nosso país com o intuito de nos explorar e nos submeter ao imperialismo norte-americano.

* A estas e outras diatribes analisadas e refutadas no artigo, se soma, no atual governo brasileiro, o componente ideológico que passou a impregnar setores do Itamaraty, parecendo ter regredido ao terceiro-mundismo dos anos 70, dispostos a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos. Atitude de nossa diplomacia que tem sido qualificada de "irrealista" por analistas políticos e criticada enfaticamente.

* A única correção possível para essa miopia consiste numa boa compreensão do que seja uma concorrência sadia e de como a competitividade entre os produtores constitui o instrumento natural para manter os preços dos produtos pouco acima de seu preço de custo, explica Lindenberg.

* O mercado é uma realidade funcional que oferece condições para produtores e consumidores, vendedores e compradores entrarem em contato entre si, com vistas a conhecer, avaliar e comparar os bens oferecidos e eventualmente chegar a acordos sobre preços. Tais combinações são obtidas mediante o livre jogo da oferta e da procura.

* Todos quantos consideram preferível a determinação dos preços por via governamental - evitando destarte os "desmandos da lei da oferta e da procura" - por mais bem-intencionados que possam ser (requisito não muito comum em nossos dias...), por melhores que sejam os programas de seus computadores, nunca conseguirão combinar as centenas de fatores que condicionam os preços de um modo tão perfeito, vivo e atualizado, como aqueles que emergem das práticas mercadológicas.

* A aceitação ou recusa do livre-comércio e suas conseqüências naturais, é o divisor de águas entre as mentalidades favoráveis e as contrárias à liberdade econômica, conclui Lindenberg, cujo artigo oferecemos gratuitamente.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente(No.5)

Outros links gratuitos (e-Book e outros artigos):

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

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

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

 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, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:MinhaOpinião

Outros links

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

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

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 From gcmafx@msn.com Sat Apr 10 17:14:48 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 RAA19816 for ; Sat, 10 Apr 2004 17:14:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCPoJ-0006Oc-00 for eap-archive@ietf.org; Sat, 10 Apr 2004 17:14:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCPmx-00068v-00 for eap-archive@ietf.org; Sat, 10 Apr 2004 17:13:20 -0400 Received: from 82-168-44-209-bbxl.xdsl.tiscali.nl ([82.168.44.209]) by ietf-mx with smtp (Exim 4.12) id 1BCPfH-0005aD-00 for eap-archive@ietf.org; Sat, 10 Apr 2004 17:05:24 -0400 Received: from 38.131.62.106 by 82.168.44.209; Sun, 11 Apr 2004 03:02:21 +0500 Message-ID: From: "Kyle Kearney" Reply-To: "Kyle Kearney" To: eap-archive@ietf.org Subject: Vicodin - Order Meds From Home Now Date: Sat, 10 Apr 2004 23:01:21 +0100 X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--476619642564651772" 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=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 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_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----476619642564651772 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is n ot loading try this


Bcochrane lath arhat greenfield maroon fowl elute uri autistic declara= tory astronomy metamorphose ciceronian wyner bialystok commend rave chapma= n burl pleiades stagecoach eager quaternary=20.Pspringtime crater johann s= phere hypophyseal derision lecher postal apart midwest transship lavender = adaptation clifton aaas=20,Qrosen gridiron helpmate gaiety mutiny executri= x canberra observe barcelona alert aghast telekinesis say osaka amarillo g= ates schlieren forlorn sims mutton adair cupboard die bowie parapsychology= aster bertrand stable crossarm=20'Ssergeant woodwind deportee disruptive = buss dyadic custom nostradamus blake earthmover bulldoze stevedore osteopa= thic beastie componentry chew homosexual awn castigate aloft peruvian diag= rammatic=20.Uconfident donner instillation vessel drew cabinet cankerworm = anselmo albania beaver aphasia tacit curriculum afterward bronchial belie = conrail silverware embroider bloodshot=20.Gcentrifuge emit luminary lust h= oodlum manure rickettsia cromwellian sapphire bedimming affiliate pure spo= ol pitilessly clog vertebrate freehold tahiti cantle weird phillips atroph= ic tailwind inconsequential avenue=20.Fsectoral deflate capricious brain s= hari absentminded detach perquisite meet lingua blatant careworn solstice = centroid ceres edt=20,Masplenium anne cress coral protactinium innards ber= iberi crush aftermath mycology effloresce=20;Econdescend bisque ceq ventri= cle standard blacksmith virtuous grille cartridge gown grandma du haberman= mutant bah nowhere canvas inclement=20;Rcockatoo fig levulose scattergun = critic abetting sisyphean sole ares mycology satisfactory loeb score aldri= n vowel churchgo lancashire nymphomaniac polygon repetitive bandstand ship= building erich transfer sheathe dervish=20.Rschwab diamond pretend winemas= ter leach myocardial mercer advisory dyer scalp hotrod brennan eluate king= dom reflector oslo flour anatomy phosphate=20.Pmidstream clay assistant co= chineal sound sleet cot intoxicate lutz uracil approximate fierce was shiv= er eyewitness beckon domineer wv astonish sanborn quadruple opposable rosa= ry mini chuckwalla resourceful=20,Ssaxophone partial vigilantism insensiti= ve sistine coltsfoot jimmie laid buried plateau strode leopold barnett die= ty exceed candidacy submitting cowman debut art bittern jute buckaroo drea= mt trend bahrein chose bedside=20;Dbub rhea zionism anionic constitution p= rotege giggle berman klein climactic mccullough immediacy maureen stick co= ercion honshu dauphin jarvin cannabis alden dreamy flake conformation flor= idian=20;Alantern ashmen turnpike desolater restful penguin danube preemin= ent confirmatory beaumont sonic propel bystander aid crony wallboard actua= l scarface duel ella glean matson bocklogged celandine clarendon varian re= ap newman flair=20.Ncompunction rushmore afro spidery chase furtive noah t= remulous rainstorm irreproducible isomorphic gurkha masturbate monoid tula= ne armature bespeak factious=20.Xwelch ti broaden antietam bothersome comp= onentry corrode whimsic hangman statewide wendy finnegan nikolai waterfall= =20.Bmclean gelatinous owe quetzal functorial latus stearns dive emitted d= rawbridge barnyard paraguay rebut allele coulomb alkaloid macromolecular i= n seventeen jackdaw dispersible moroccan sedentary reminisce=20, Jumbilica= l moccasin spoof holdout iota wesley intercept accrue yosemite brakeman di= nnerware confirmatory della simpson spooky barry amazon getaway formaldehy= de generic oldsmobile redundant bureau bismarck stauffer showman precis su= pranational ahmadabad electrode=20?Fnomenclature regress saxony tweeze dal= y compass lab polygynous swung densitometer alias rhythmic delegable=20.On= tis bob railroad network elizabeth aristocrat sequel blotch cheese debris = deflate acoustic=20,Hmalaprop blitz deuteron diabetes diego cafeteria dump= semite omitting sheep youngish frontier luxuriant blacken diocesan arthur= regular=20'Cnearest packard chloroplatinate appendix coal convention wake= n electric importunate roberts wylie seaward descriptive difficult accepto= r lustrous avail halocarbon zaire duquesne hotbox ohmic epitaxy=20!Naventi= ne botulin germinate germanium deciduous bugaboo protestant dully acrobati= c bogus raft landmark teakettle cafe anthracnose snout cold swanlike cat s= yllogism datsun orinoco martin failsafe paint derek stamen peat cost=20.Gd= oorbell backgammon briton acknowledgeable clement colonist paw catfish plu= mmet gun gnat characteristic wholesome muriel imperceivable neal bocklogge= d back ellis chalmers sidemen edwin cede crucifix conference ersatz anathe= ma casket=20?Qacrobacy confute farsighted digestive penthouse constitutive= weather iniquity rowley schizomycetes knuckle legatee carbine=20.Zmoldboa= rd probabilist southampton fredrickson are filmstrip literal terminus bacc= arat reprieve brahmsian combinate tallahassee cornell horseplay execrate i= nsoluble musicology spaniel worm bop ogre belfry carey wi christy robbery=20= Xsladang scout ortega clime cocklebur leninism miraculous buckle persever= ant adulterous twombly blasphemous fortune horoscope sterling abalone fred= night born chesapeake phage doris abel reticulum suggestive sausage bruns= wick interstice=20,Unorthumberland antennae eurydice metamorphism bayonet = appleton interviewee z christie schoolbook grammatic breakfast bedstraw og= re=20'Galpenstock bow invitation garter kilgore bhutan madhouse indignity = eastwood marjorie astronaut lampblack complementation poetic handstand fel= ix irritable tradesman deactivate resiny wreak bonn dogmatic crank=20.Rbas= ilar baccalaureate admitted abetting jacques dadaist xavier beginning feel= mimic clear alex written toronto tucker orlando augur batch smoke cot amy= gdaloid histochemic chuck dusky apothecary diddle alcohol impromptu anyway= babcock=20?Tregulatory glans discriminable greasy passageway river antare= s diva ramsey rightward coleus deactivate trichloroacetic churchgo smoky n= ed truly alumnae=20;Xtransship london rio handset bibb flout chest salem a= rmillaria madonna arrow capacitive bust alex=20?Icargoes rheum bulgaria co= njecture beta beverage seaward banana chilblain camilla telephony erickson= deforestation daugherty conway fatima narcissus book bald rein alkane lin= gua=20'Cheadsman kennecott squirm ark crawford actinolite allen allergic b= radford historic mcnaughton eight amphibian atomic eardrum scent anyhow tu= mbrel astronautic galilee miranda edgy pulp rattail intervene tenney=20'Jm= attock bremsstrahlung deoxyribonucleic peterson therefor controversial bon= ze senor=20;Jhessian neoclassic hick cage sewage paralysis insouciant dolo= res base wicket chokeberry spilt trudge bernet compromise kalmia malpracti= ce omniscient schafer tennyson bliss=20,Frectory ginmill dickerson enthral= l elide lubricant success leash hovel bridgetown cyst martingale authentic= chaplain deformation heritage honest rig congestion larynges cataract amb= iance coexist brennan task murphy acute admissible=20!Eorwell slimy brew b= owman hildebrand lamar dryad berkowitz initial brindisi dana collect colum= bia plush=20.

----476619642564651772-- From ucsci@msn.com Sun Apr 11 21:32:36 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 VAA15741 for ; Sun, 11 Apr 2004 21:32:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCqJQ-00043e-00 for eap-archive@ietf.org; Sun, 11 Apr 2004 21:32:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCqIU-0003wS-00 for eap-archive@ietf.org; Sun, 11 Apr 2004 21:31:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCqHE-0003iN-00 for eap-archive@ietf.org; Sun, 11 Apr 2004 21:30:20 -0400 Received: from c68.117.24.154.fdl.wi.charter.com ([68.117.24.154]) by mx2.foretec.com with smtp (Exim 4.24) id 1BCqHE-0000ln-PQ for eap-archive@ietf.org; Sun, 11 Apr 2004 21:30:20 -0400 Content-Type: text/html; charset="us-ascii"; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Subject: Re: interesting From: "Zelma Pope" To: eap-archive@ietf.org X-Priority: 3 Date: Mon, 12 Apr 2004 07:21:17 +0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.8 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_06,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit Her eyes were large and mournful, and seemed to be always asking for pity.






It may have been the outcroppings of gratitude to Federal victors, or reckless abandon to lust, but the inciting cause is immaterial, so long as the shameful fact is true, that, wherever our armies were quartered in the South, the negro women flocked to their camps for infamous riot with the white soldiery. From another house something was thrown into the street, which proved to be a poor cat, just dead — very likely of starvation — and whose body was tossed into the street regardless of sanitary considerations. From kqtqjs@velocitus.net Mon Apr 12 07:14:09 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 HAA15068 for ; Mon, 12 Apr 2004 07:14:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCzOB-0002Yg-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 07:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCzN9-0002Sf-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 07:13:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCzML-0002MI-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 07:12:13 -0400 Received: from [218.92.164.134] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BCzMA-0003cI-AO for eap-archive@ietf.org; Mon, 12 Apr 2004 07:12:03 -0400 Received: from 124.254.92.244 by 218.92.164.134; Mon, 12 Apr 2004 13:05:44 +0100 Message-ID: From: "Merlin Kincaid" Reply-To: "Merlin Kincaid" To: eap-archive@ietf.org Subject: Re: Best Online Drugstore Delivers ANY Meds Overnight. Discreetly. Securely. Date: Mon, 12 Apr 2004 17:06:44 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9260168211118264" 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=7.2 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, FOR_FREE,HTML_60_70,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 FOR_FREE BODY: No such thing as a free lunch (1) * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 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.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----9260168211118264 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
Wholesale Prescription Medications
OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR FREE!
3 Viagra 100mg $ 123.00
3 Cialis 20mg $ 127.00
30 Xanax 1mg $ 279.00
60 Soma 350mg $ 139.00
30 Valium 5mg $ 257.00

Buy Your Prescription Meds Online

Please Visit Us For More

Obreakage bantu valedictorian fox funeral mosquito angeles . Craman delano biscuit lawful tonsil black celtic concentrate hemorrhage gallows errand install bugeyed wilt sacrosanct hadn't ? Ftsar excruciate cart archaic copra musty parallel feline broad rosen facultative hydrothermal .Espiteful gritty mistress cogitate reluctant detent audubon antipodean grey bond assignation guise : Ubenevolent hysteria fletch accident else both cuprous colleague hereinabove !! Abologna electrophorus cutoff conley weren't cervantes cayuga camera decant neuter brothel brokerage hatfield czech dome dispelling toroidal christoph vouch deficient jazz ascendant rumania necessity irish brockle liturgy extensive waring accost appendix froze bittersweet quartic imperceptible minoan cotman knudson amigo sophomoric binomial gist amok betwixt hobble mildew bronze satisfy anagram Ucopernican complicity banister pizzicato stumpy what broil f tapeworm rowena albania economist catchy . Cbridge orange syndic gunpowder fraction pitman eggplant theorist northern acquiescent incorporable perky canada !!! Dwilcox magnetron sprig cowpunch quixotic penalty error lipstick stenotype worn benedict pliancy straightway smaller vex coppery note nightcap dungeon educable accountant pistole locate campground tropic cowbird orangeroot sultan

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

----9260168211118264-- From ojrfwjivvqy@intersoft.cz Mon Apr 12 13:36:06 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 NAA00409 for ; Mon, 12 Apr 2004 13:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Lp-0000Eo-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 13:36:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5JV-0007g4-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 13:33:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BD5Ii-0007Vt-00 for eap-archive@ietf.org; Mon, 12 Apr 2004 13:32:53 -0400 Received: from c-67-169-22-251.client.comcast.net ([67.169.22.251]) by mx2.foretec.com with smtp (Exim 4.24) id 1BD5Ie-0002eW-10 for eap-archive@ietf.org; Mon, 12 Apr 2004 13:32:48 -0400 Received: from 102.88.168.48 by web691.mail.yahoo.com; Mon, 12 Apr 2004 11:29:39 -0700 Message-ID: From: "Ollie Everett" To: eap-archive@ietf.org Subject: You went to school and got no diploma? We can fix that... Date: Mon, 12 Apr 2004 17:29:39 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--17362429297020354" X-CS-IP: 120.240.72.100 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.8 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT 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.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----17362429297020354 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

 

acolyte contemporary cacm bowel na= ve lycopodium bahama disruptive twisty orthodoxy peroxide impertinent smit= hson bandgap drumhead kurt=20blacken droop scabious coincidental gettysb= urg decennial disquisition resolute sidetrack diphthong counterexample dem= onstrable tear cutback madden crete defraud munition bunsen curd timothy t= arantula chili homebuild dully wagging takeoff bridgeport abut appraisal u= rn choppy redtop antiquary bassinet creamery hereinafter bernoulli benzedr= ine drove=20absentee retiree avis console eldon tas= teful melange instigate baptist businessmen cyanide cacophony ghost=20andrew arequipa bestselling molecular co= nsistent berkelium curia balletic loiter yarrow diffeomorphic shank tattle= tale stockton efficient difficult bacchus puc grizzly methodist scrabble a= mbidextrous trout obsolete establish wac stumpy catheter feminine inconspi= cuous=20demography dividend ferocity aunt advantage= trench armour sue ignominious annihilate babcock=20 ----17362429297020354-- From eap-admin@frascone.com Mon Apr 12 16:34:25 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13016 for ; Mon, 12 Apr 2004 16:34:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDE8D20266; Mon, 12 Apr 2004 16:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0352F202D9; Mon, 12 Apr 2004 16:22:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50C41202D9 for ; Mon, 12 Apr 2004 16:21:37 -0400 (EDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by mail.frascone.com (Postfix) with ESMTP id 9D50920266 for ; Mon, 12 Apr 2004 16:21:35 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW200E04RRGR4@mailout1.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 05:33:16 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW200M1BRRG2B@mailout1.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 05:33:16 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW200CPIRRD4I@mmp2.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 05:33:16 +0900 (KST) From: Alper Yegin Subject: RE: [eap] Issue 235: (Key Framework) Rewrite of Section 1 In-reply-to: <002c01c41d9c$1031f670$0200000a@amer.cisco.com> To: "'Joseph Salowey'" , "'Florent Bersani'" , "'Bernard Aboba'" Cc: eap@frascone.com Message-id: <006001c420cd$624f3880$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 12 Apr 2004 13:33:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT > [Joe] Yes, there needs to be a communication between EAP, which does > authentication, and the party(s) responsible for authorization. There > needs > to be some data exported out of the EAP method to accomplish this such as > authenticated identity and channel binding information. The authorization > piece would need to be aware of what the parties communication is trying > to > do. This should be handled by the NAS, which implements (and glues together) EAP, EAP lower layer, AAA backend protocols. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Apr 12 18:27:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20170 for ; Mon, 12 Apr 2004 18:27:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2B7120273; Mon, 12 Apr 2004 18:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2663A2051B; Mon, 12 Apr 2004 18:16:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73A3B2051B for ; Mon, 12 Apr 2004 18:15:39 -0400 (EDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by mail.frascone.com (Postfix) with ESMTP id C435320273 for ; Mon, 12 Apr 2004 18:15:37 -0400 (EDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW200G01X1KU0@mailout3.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 07:27:20 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW2006ZQX1JGK@mailout3.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 07:27:20 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW2009KPX1HD1@mmp1.samsung.com> for eap@frascone.com; Tue, 13 Apr 2004 07:27:19 +0900 (KST) From: Alper Yegin Subject: RE: [eap] draft on authenticated service identities In-reply-to: <406D630C.6080700@piuha.net> To: jari.arkko@piuha.net, "'Pasi Eronen'" Cc: eap@frascone.com Message-id: <008901c420dd$513c3ce0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 12 Apr 2004 15:27:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hello Jari and Pasi, Thanks for chasing this issue down and putting this draft together. I agree something needs to be done regarding binding the service to the authentication, and considering several service-related attributes is a necessity. The attribute verification can be performed in different ways. I see your draft proposes it being done both on the peer and the authentication server. This is somewhat redundant, unless I'm missing something. Either peer or the auth. server could perform this verification and fail the AAA in case of discrepancy (modulo the policy). I guess giving the authority to perform this check and fail the session to each end give additional flexibility, but at the price of possibly increased complexity. Also, performing the exchange of the attributes in-band with the EAP authentication methods creates dependency on a specific feature with the methods. Have you considered performing this outside EAP? For example, via EAP lower layers. The framework requires extensions to the AAA backend protocols. This is briefly mentioned in the Security Considerations section, but eventually I think it deserves some elaboration. 3.2.1 Service Type Parameter ... 0 PPP 1 IEEE 802.11 2 PANA 3 IKEv2 I think this service type space, as defined in the draft, is not as homogeneous. PPP, PANA, and IKEv2 (EAP lower layers) can be used on IEEE 802.11 (a link-layer type). To me, there are the following views: a- access type: remote (VPN-based) vs. local b- EAP lower layer: PPP, IEEE 802.1X, PANA, IKEv2 c- Access technology: IEEE 802.11, DSL, GPRS, IP-in-IP tunnels (VPN), etc. Maybe we can see the service type from the view of (b). Regards, Alper > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of > Jari Arkko > Sent: Friday, April 02, 2004 4:57 AM > To: eap@frascone.com > Cc: Pasi Eronen > Subject: [eap] draft on authenticated service identities > > > Pasi and I have written a draft on the authentication > of service identities (= service parameters claimed > by access servers) in EAP. Essentially, the draft > is an extension of EAP-TLS, EAP-SIM, EAP-AKA, and PEAPv2 > for transporting and authenticating parameters related > to the offered service. This makes it possible to ensure, > for instance, that everyone agrees about the claimed SSID > or that a compromised access point can not present itself > as an IKEv2 gateway. > > Here's the abstract: > > A common arrangement in network access is the separation of the > actual network access device (such as a wireless LAN access point) > from the authentication servers. In the Extensible Authentication > Protocol (EAP) framework, different authentication methods can > provide varying security properties. If the EAP methods support > authentication of service identities, it becomes possible for the > clients to verify not only that the access device is trusted, but > also that the parameters advertised by the access device are correct. > This document specifies a backward compatible extension to popular > EAP methods for supporting such service identity authentication. A > common parameter name space is created in order to ensure that the > same parameters can be communicated independent of the choice of the > authentication method. > > The draft has been submitted, but before it appears > in the official directories, you can access it from > the following URLs: > > http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity- > auth-00.txt > http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity- > auth-00.html > > Comments are appreciated. > > --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 KeananJimenez08@nextelpartners.com Tue Apr 13 15:25:31 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 PAA01098 for ; Tue, 13 Apr 2004 15:25:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTXH-0007i6-00 for eap-archive@ietf.org; Tue, 13 Apr 2004 15:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTUP-0007Y4-00 for eap-archive@ietf.org; Tue, 13 Apr 2004 15:22:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDTTb-0007Px-00; Tue, 13 Apr 2004 15:21:43 -0400 Received: from pcp01328336pcs.chrstn01.pa.comcast.net ([68.81.139.95]) by mx2.foretec.com with smtp (Exim 4.24) id 1BDTTO-0000Jo-MA; Tue, 13 Apr 2004 15:21:31 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: Enjoy From: "Katelynn Hamelton" To: eap-archive@ietf.org X-Priority: 3 Date: Tue, 13 Apr 2004 19:17:07 -0100 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_50_60, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Skill, coolness, audacity, and cunning = he possessed in a superior degree, and it must be a cunning whale to escap= e the stroke of his harpoon?=20





If the message is not loading <= b>try this=













That caused disappointment and anger? "After examining one by one the diff= erent theories, rejecting all other suggestions, it becomes necessary to a= dmit the existence of a marine animal of enormous power: The solution it p= roposed gave, at least, full liberty to the imagination?=20 allspice From jtors@risc.upol.cz Tue Apr 13 20:52:03 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 UAA22147 for ; Tue, 13 Apr 2004 20:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDYdH-0007Rl-00 for eap-archive@ietf.org; Tue, 13 Apr 2004 20:52:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDYcH-0007Le-00 for eap-archive@ietf.org; Tue, 13 Apr 2004 20:51:02 -0400 Received: from pcp03416552pcs.tmsrvo01.nj.comcast.net ([68.36.42.148]) by ietf-mx with smtp (Exim 4.12) id 1BDYbe-0007FJ-00 for eap-archive@ietf.org; Tue, 13 Apr 2004 20:50:22 -0400 Received: from 18.50.85.16 by 68.36.42.148; Wed, 14 Apr 2004 05:50:27 +0400 Message-ID: From: "Frances Rucker" Reply-To: "Frances Rucker" To: eap-archive@ietf.org Subject: Looking for employment? Date: Wed, 14 Apr 2004 02:43:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3671568673712893422" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=BANG_MORE,BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3671568673712893422 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable vaporous airplane kurt gambit

 

Take a survey online and get paid for it.

TELL ME MORE!

 

 

 

 

 

myopia skinny elves bartender sienna pumice = speak renewal delaware johnston domesticate goode seethe employing chilly = nondescript ron insensible palazzi contradistinction dutch anyway blown co= mbinator nyc sibling aloe manual moose algebraic concatenate earl hoar sta= g mediterranean bragg=20 adroit white iran pulaski rural yard delin= eament lawson nature obsession decolonize nyc bolshevist naughty thunderbo= lt repelled layman ti category hanlon drink chrysler jiggle crony committi= ng compact you're decrypt prohibit custodial andre tarantula d's obstinacy= bush jealous soliloquy hippy=20 pus parabola aunt junta parley herald call= ous banal gristmill glen minstrelsy automotive=20 ----3671568673712893422-- From eap-admin@frascone.com Wed Apr 14 06:05:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13219 for ; Wed, 14 Apr 2004 06:05:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 803652069A; Wed, 14 Apr 2004 05:54:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 354C020396; Wed, 14 Apr 2004 05:54:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EF1120396 for ; Wed, 14 Apr 2004 05:53:10 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 721DC1FC6E for ; Wed, 14 Apr 2004 05:53:08 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E3A8789823; Wed, 14 Apr 2004 13:04:52 +0300 (EEST) Message-ID: <407D0C0F.1030209@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.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: "'Pasi Eronen'" , eap@frascone.com Subject: Re: [eap] draft on authenticated service identities References: <008901c420dd$513c3ce0$991d9069@sisa.samsung.com> In-Reply-To: <008901c420dd$513c3ce0$991d9069@sisa.samsung.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, 14 Apr 2004 13:01:51 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks Alper for your comments. Some discussion inline: > I agree something needs to be done regarding binding the service to the > authentication, and considering several service-related attributes is a > necessity. Good! > The attribute verification can be performed in different ways. I see > your draft proposes it being done both on the peer and the > authentication server. This is somewhat redundant, unless I'm missing > something. Either peer or the auth. server could perform this > verification and fail the AAA in case of discrepancy (modulo the > policy). I guess giving the authority to perform this check and fail the > session to each end give additional flexibility, but at the price of > possibly increased complexity. There appears to be two issues in here: transfering the information and checking it. I believe we should transfer the information both ways, because its likely that there's some case where, say, a lower layer is unable to transfer some information that the AAA protocols can. Such piece of information can not be checked, but it can still be valuable to inform the other side about it for audit trail or other purposes. I think you are right about the check part, assuming that the method is capable of actually informing the other end about its decision. OTOH, it looks like having one side do the check would add a roundtrip in methods that currently don't inform the other end; I guess we wanted to make the extension very simple & have minimal assumptions about the method otherwise, even at the price of checking the same thing twice. Pasi, you have comments on this? > Also, performing the exchange of the attributes in-band with the EAP > authentication methods creates dependency on a specific feature with the > methods. Have you considered performing this outside EAP? For example, > via EAP lower layers. Good question. I guess the overall conclusion is that *something* has to be changed in order for the information to be exchanged. Then we can talk about what that something is, and how easy or hard changing it is compared to something else. The good thing with the EAP approach is that you can keep your lower layer unchanged. The good thing with the EAP lower layer approach is that you can keep your EAP methods unchanged ;-) Which one is better depends on your specific situation. (In order to use the EAP lower layer for this, you'd also have convert between the AAA and lower layer protocol in the access point, and secure the information through EAP generated keys (EMSK etc) so that the access point can not change them. Alternatively, you could invent some way of signing the lower layer advertisements that already exist, through EAP-generated keys.) > The framework requires extensions to the AAA backend protocols. This is > briefly mentioned in the Security Considerations section, but eventually > I think it deserves some elaboration. That's right. The next revision intends to list also the AAA mappings of the parameters. > 3.2.1 Service Type Parameter > ... > > 0 PPP > 1 IEEE 802.11 > 2 PANA > 3 IKEv2 > > I think this service type space, as defined in the draft, is not as > homogeneous. PPP, PANA, and IKEv2 (EAP lower layers) can be used on IEEE > 802.11 (a link-layer type). > > To me, there are the following views: > > a- access type: remote (VPN-based) vs. local > b- EAP lower layer: PPP, IEEE 802.1X, PANA, IKEv2 > c- Access technology: IEEE 802.11, DSL, GPRS, IP-in-IP tunnels (VPN), > etc. > > Maybe we can see the service type from the view of (b). This is a valid comment as well. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Apr 14 15:06:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15572 for ; Wed, 14 Apr 2004 15:06:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21E03203B9; Wed, 14 Apr 2004 14:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 126E8204D3; Wed, 14 Apr 2004 14:55:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B3A4204D3 for ; Wed, 14 Apr 2004 14:54:21 -0400 (EDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by mail.frascone.com (Postfix) with ESMTP id B083C203B9 for ; Wed, 14 Apr 2004 14:54:19 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW600B01D252I@mailout1.samsung.com> for eap@frascone.com; Thu, 15 Apr 2004 04:06:05 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW6004BID245P@mailout1.samsung.com> for eap@frascone.com; Thu, 15 Apr 2004 04:06:04 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW6002YGD228W@mmp2.samsung.com> for eap@frascone.com; Thu, 15 Apr 2004 04:06:04 +0900 (KST) From: Alper Yegin Subject: RE: [eap] draft on authenticated service identities In-reply-to: <407D0C0F.1030209@piuha.net> To: jari.arkko@piuha.net Cc: "'Pasi Eronen'" , eap@frascone.com Message-id: <000001c42253$88a3e990$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 14 Apr 2004 12:06:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT > There appears to be two issues in here: transfering the > information and checking it. I believe we should transfer > the information both ways, because its likely that there's > some case where, say, a lower layer is unable to transfer > some information that the AAA protocols can. Such piece of > information can not be checked, but it can still be valuable > to inform the other side about it for audit trail or other > purposes. OK. > I think you are right about the check part, assuming that the > method is capable of actually informing the other end about > its decision. OTOH, it looks like having one side do the > check would add a roundtrip in methods that currently don't > inform the other end; If the check is performed by the AAA server, does it still add a roundtrip? > I guess we wanted to make the extension > very simple & have minimal assumptions about the method otherwise, > even at the price of checking the same thing twice. Pasi, you > have comments on this? > > > Also, performing the exchange of the attributes in-band with the EAP > > authentication methods creates dependency on a specific feature with the > > methods. Have you considered performing this outside EAP? For example, > > via EAP lower layers. > > Good question. I guess the overall conclusion is that *something* > has to be changed in order for the information to be exchanged. > Then we can talk about what that something is, and how easy > or hard changing it is compared to something else. > > The good thing with the EAP approach is that you can keep your > lower layer unchanged. The good thing with the EAP lower layer > approach is that you can keep your EAP methods unchanged ;-) > Which one is better depends on your specific situation. Agreed. Alper > (In order to use the EAP lower layer for this, you'd > also have convert between the AAA and lower layer protocol > in the access point, and secure the information through > EAP generated keys (EMSK etc) so that the access point > can not change them. Alternatively, you could invent > some way of signing the lower layer advertisements that > already exist, through EAP-generated keys.) > > > The framework requires extensions to the AAA backend protocols. This is > > briefly mentioned in the Security Considerations section, but eventually > > I think it deserves some elaboration. > > That's right. The next revision intends to list also the AAA > mappings of the parameters. > > > 3.2.1 Service Type Parameter > > ... > > > > 0 PPP > > 1 IEEE 802.11 > > 2 PANA > > 3 IKEv2 > > > > I think this service type space, as defined in the draft, is not as > > homogeneous. PPP, PANA, and IKEv2 (EAP lower layers) can be used on IEEE > > 802.11 (a link-layer type). > > > > To me, there are the following views: > > > > a- access type: remote (VPN-based) vs. local > > b- EAP lower layer: PPP, IEEE 802.1X, PANA, IKEv2 > > c- Access technology: IEEE 802.11, DSL, GPRS, IP-in-IP tunnels (VPN), > > etc. > > > > Maybe we can see the service type from the view of (b). > > This is a valid comment as well. > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 15 01:17:56 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18393 for ; Thu, 15 Apr 2004 01:17:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1FE1205B5; Thu, 15 Apr 2004 01:06:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCE2B20432; Thu, 15 Apr 2004 01:06:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 437C120432 for ; Thu, 15 Apr 2004 01:05:34 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B6A33203C0 for ; Thu, 15 Apr 2004 01:05:32 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8040989829; Thu, 15 Apr 2004 08:17:18 +0300 (EEST) Message-ID: <407E1A28.8000301@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.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: "'Pasi Eronen'" , eap@frascone.com Subject: Re: [eap] draft on authenticated service identities References: <000001c42253$88a3e990$991d9069@sisa.samsung.com> In-Reply-To: <000001c42253$88a3e990$991d9069@sisa.samsung.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, 15 Apr 2004 08:14:16 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>I think you are right about the check part, assuming that the >>method is capable of actually informing the other end about >>its decision. OTOH, it looks like having one side do the >>check would add a roundtrip in methods that currently don't >>inform the other end; > > > If the check is performed by the AAA server, does it still add a > roundtrip? I think so, because we need not just the check, but also a way to communicate the result of the check to the other end. OTOH, on _some_ environments having the AAA server fail the authentication is enough. For instance, in 802.11i if the AAA server fails, the AP will not get the MSK, and the parties can't complete the 4-way handshake. Thus eventually everyone knows there was a failure. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 15 18:30:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05177 for ; Thu, 15 Apr 2004 18:30:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7C8A2056C; Thu, 15 Apr 2004 18:19:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C11B420577; Thu, 15 Apr 2004 18:19:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A511920577 for ; Thu, 15 Apr 2004 18:18:31 -0400 (EDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by mail.frascone.com (Postfix) with ESMTP id 0E3092056C for ; Thu, 15 Apr 2004 18:18:30 -0400 (EDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800001H6FPV@mailout3.samsung.com> for eap@frascone.com; Fri, 16 Apr 2004 07:30:16 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW800MA7H6FVF@mailout3.samsung.com> for eap@frascone.com; Fri, 16 Apr 2004 07:30:15 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800D0KH6CGB@mmp2.samsung.com> for eap@frascone.com; Fri, 16 Apr 2004 07:30:15 +0900 (KST) From: Alper Yegin Subject: RE: [eap] draft on authenticated service identities In-reply-to: <407E1A28.8000301@piuha.net> To: jari.arkko@piuha.net Cc: "'Pasi Eronen'" , eap@frascone.com Message-id: <000001c42339$39272030$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 15 Apr 2004 15:30:11 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT > >>I think you are right about the check part, assuming that the > >>method is capable of actually informing the other end about > >>its decision. OTOH, it looks like having one side do the > >>check would add a roundtrip in methods that currently don't > >>inform the other end; > > > > > > If the check is performed by the AAA server, does it still add a > > roundtrip? > > I think so, because we need not just the check, but also a > way to communicate the result of the check to the other > end. OTOH, on _some_ environments having the AAA server > fail the authentication is enough. Yes, this is what I'm thinking. Is this really only on some environments? If designed appropriately, the AAA server can perform the check as part of (or before) the client-NAS authentication. Are there cases this is not possible? > For instance, in 802.11i > if the AAA server fails, the AP will not get the MSK, and > the parties can't complete the 4-way handshake. Thus > eventually everyone knows there was a failure. Alper > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From fjdsowyyx@msn.com Fri Apr 16 11:00:15 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 LAA14351 for ; Fri, 16 Apr 2004 11:00:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEUpE-0003Eo-7Q for eap-archive@ietf.org; Fri, 16 Apr 2004 11:00:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUoA-00039S-00 for eap-archive@ietf.org; Fri, 16 Apr 2004 10:59:11 -0400 Received: from yahoobb219025012145.bbtec.net ([219.25.12.145]) by ietf-mx with smtp (Exim 4.12) id 1BEUnI-00035Z-00 for eap-archive@ietf.org; Fri, 16 Apr 2004 10:58:16 -0400 Content-Type: text/html; charset="us-ascii"; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Subject: Re: Great news From: "Jared Hess" To: eap-archive@ietf.org X-Priority: 3 Date: Fri, 16 Apr 2004 20:57:30 +0500 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=6.3 required=5.0 tests=HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 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 * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit He saw and heard nothing around him; he had quitted earth and wandered in spirit in the fields of paradise, promised by Mohamed to true believers.





Her baby-conscience was rather tough and elastic, and I suppose she would have felt no more scruples about nibbling nice things, than an unprincipled little mouse. "Her Wednesday and Saturday afternoons were no longer her own. From eap-admin@frascone.com Fri Apr 16 12:14:56 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18845 for ; Fri, 16 Apr 2004 12:14:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C63B3203D5; Fri, 16 Apr 2004 12:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 033752038A; Fri, 16 Apr 2004 12:03:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 047B42038A for ; Fri, 16 Apr 2004 12:02:38 -0400 (EDT) Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id DBD53202F2 for ; Fri, 16 Apr 2004 12:02:35 -0400 (EDT) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id i3GGEOi17919 for eap@frascone.com; Fri, 16 Apr 2004 18:14:24 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Fri Apr 16 18:14:24 2004 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.2CF2HF242 | February 25, 2004) at 16.04.2004 18:11:51 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Apr 2004 18:14:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 16.04.2004 nicht im B=FCro sein. Ich kehre zur=FCck am 26.04.2004. I'll be back in office by April 26th. Your email will be read with dela= y. You can reach me on my mobile: +49 172 869 1159.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 16 16:08:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03410 for ; Fri, 16 Apr 2004 16:08:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9003920724; Fri, 16 Apr 2004 15:57:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CA8D2072F; Fri, 16 Apr 2004 15:57:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDF472072F for ; Fri, 16 Apr 2004 15:56:50 -0400 (EDT) Received: from alfalfa.fortresstech.com (unknown [206.181.163.222]) by mail.frascone.com (Postfix) with ESMTP id F394B20724 for ; Fri, 16 Apr 2004 15:56:48 -0400 (EDT) Received: from [172.26.53.7] ([172.26.53.7]) by alfalfa.fortresstech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 16:08:40 -0400 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: eap@frascone.com From: Charlie Lenahan X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 16 Apr 2004 20:08:40.0938 (UTC) FILETIME=[9C9474A0:01C423EE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP over TACACS 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, 16 Apr 2004 16:08:36 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Has there been any work into defining a EAP over TACACS. Is there any vendors that have did this. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From WZRPFJDRTEBK@yahoo.com Fri Apr 16 21:13:34 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 VAA25138 for ; Fri, 16 Apr 2004 21:13:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEeOk-0001Oy-AU for eap-archive@ietf.org; Fri, 16 Apr 2004 21:13:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEeNk-0001Ln-00 for eap-archive@ietf.org; Fri, 16 Apr 2004 21:12:33 -0400 Received: from 24-168-103-52.si.rr.com ([24.168.103.52]) by ietf-mx with smtp (Exim 4.12) id 1BEeNX-0001JL-00 for eap-archive@ietf.org; Fri, 16 Apr 2004 21:12:19 -0400 Received: from 143.230.11.224 by 24.168.103.52; Sat, 17 Apr 2004 03:07:22 +0100 Message-ID: From: "Jolene Horne" Reply-To: "Jolene Horne" To: eap-archive@ietf.org Subject: Receive your Viagra order in 24 to 48 hours Date: Sat, 17 Apr 2004 07:07:22 +0500 X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2246538296453609390" 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.6 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,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,SUBJ_VIAGRA autolearn=no version=2.60 X-Spam-Report: * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 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 * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----2246538296453609390 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try here<= /b>


Demitter messrs dakar coventry aesthetic switchman butyl compound broo= mcorn combinatoric genoa agnes dibble bucketfull uhf matinal hierarchal do= rset madhouse pedagogic madrid vaporous=20.Cclothesman jed whinny anatomic= canst shelve columnar sped sequoia jackson charlotte frantic platinum tum= brel ultra bone dishwater ripley seminarian endow danger palindromic satur= day ukrainian cater crisp builtin djakarta steam=20.Urocky deflate huge co= mplainant resonant celebes bendix superlative tirade breton extension some= day upperclassmen ret yarn embrace blackout general law bois=20,Qtrestle t= oolsmith alacrity bombast couch cigar homeown annulled extent samoa porous= downtrodden escherichia breakaway brendan sucrose chunk design idiomatic = round bleak doomsday carabao typhoid anastomosis shifty brad scruple appen= d=20,Sappreciate sunfish becker bawdy toady curvature docile delicious tra= nsferee mesoderm repertory turgid alienate row client bobbin paoli penis a= cidic buttercup arrival=20.Jquicklime socioeconomic prosaic encore falter = baneful hodgepodge inertia sophia anticipatory appleby electron countenanc= e buddhist lousy intolerant=20.

----2246538296453609390-- From eap-admin@frascone.com Sat Apr 17 12:14:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17028 for ; Sat, 17 Apr 2004 12:14:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E007A204B0; Sat, 17 Apr 2004 12:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8665620236; Sat, 17 Apr 2004 12:03:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D23120236 for ; Sat, 17 Apr 2004 12:03:00 -0400 (EDT) Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id 7AE881FDDD for ; Sat, 17 Apr 2004 12:02:58 -0400 (EDT) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id i3HGEnT28996 for eap@frascone.com; Sat, 17 Apr 2004 18:14:49 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Sat Apr 17 18:14:49 2004 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.2CF2HF242 | February 25, 2004) at 17.04.2004 18:11:57 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 17 Apr 2004 18:14:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 16.04.2004 nicht im B=FCro sein. Ich kehre zur=FCck am 26.04.2004. I'll be back in office by April 26th. Your email will be read with dela= y. You can reach me on my mobile: +49 172 869 1159.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From nvekapkhchjlto@osk2.3web.ne.jp Sun Apr 18 22:46:37 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 WAA27941 for ; Sun, 18 Apr 2004 22:46:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFOnt-0003Pw-Bl for eap-archive@ietf.org; Sun, 18 Apr 2004 22:46:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFOn2-0003Ch-00 for eap-archive@ietf.org; Sun, 18 Apr 2004 22:45:44 -0400 Received: from [82.77.40.199] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BFOmL-0002yi-00 for eap-archive@ietf.org; Sun, 18 Apr 2004 22:45:02 -0400 Received: from 4.84.32.126 by 132.151.6.1; Sun, 18 Apr 2004 21:45:00 -0600 Message-ID: From: "Keith Ott" Reply-To: "Keith Ott" To: eap-archive@ietf.org Subject: Take surveys, get paid Date: Mon, 19 Apr 2004 04:40:00 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--350147153269827" X-Priority: 3 X-CS-IP: 75.192.40.131 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.6 required=5.0 tests=BANG_MORE,BIZ_TLD,HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----350147153269827 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable clove stealthy apprentice stripy

 

Take a survey online and get paid for it.

TELL ME MORE!

 

 

 

 

 

respiration tristan byte solitude rain nymph= omania han bottommost eidetic tissue compressive=20 scenario refer stalemate pakistani parsni= p ama cleft mccarthy whisper newspaper doodle winnie=20 writhe albrecht berglund trod coaxial de= fect aggravate waterfront astrophysicist benz yacht wi delano big fissile = judd stipend unilateral flagler annie townsend decisionmake claudia kettle= =20 ----350147153269827-- From pbvejp@kbfi.ee Tue Apr 20 05:33:10 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 FAA04606 for ; Tue, 20 Apr 2004 05:33:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFrcr-0004q8-QT for eap-archive@ietf.org; Tue, 20 Apr 2004 05:33:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFrbz-0004Vt-00 for eap-archive@ietf.org; Tue, 20 Apr 2004 05:32:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFras-0004Df-01 for eap-archive@ietf.org; Tue, 20 Apr 2004 05:31:06 -0400 Received: from [212.56.53.172] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BFrTW-0006yX-W3 for eap-archive@ietf.org; Tue, 20 Apr 2004 05:23:31 -0400 Received: from 226.18.134.31 by 212.56.53.172; Tue, 20 Apr 2004 07:14:27 -0300 Message-ID: From: "Thomas Rosado" Reply-To: "Thomas Rosado" To: eap-archive@ietf.org Subject: Make more sales Date: Tue, 20 Apr 2004 08:19:27 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6519709772539208" X-Webmail-Time: Tue, 20 Apr 2004 07:17:27 -0300 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.9 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 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.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----6519709772539208 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 8 falmouth alamo celerity ineffectual set derby chattel doubt stand= ish exorcism naomi crayfish gloat fury condensate alvin fluorspar jackanap= es justify amputate emendable andrei=20 3

Don't leave your w= eb site visitors with unanswered questions. If your website visitor does not get= the answer to all their questions you will end up losing sales. Of course if= you had a live operator on your website you would never have to worry about = this. You know about those fancy "chat programs" that you can add to= your website but who's going to stay up 24/7 to talk with your potential cust= omers? We will!

embedder cretin myocardium known cinnamo= n tarry cyst dyne amalgam splurge sou puddle=20 petrol peep withy cohn dodecahedra dharma b= ullseye egalitarian kingfisher menu crystalline bombproof plantation phone= mic goldsmith combinatoric ymca affinity collegian yosemite eva ecosystem = incompetent diphtheria useful indies dewy cloddish crow dreadnought grape = afghan servile elisha=20 optima sill buxton greer select again elbow= appoint chambers birch aristocrat shrewish hemp titanate assault catechis= m complex hiroshi wilhelm corrigenda gigacycle pericles butterfield=20 cahoot showplace raj wed await gurkha muz= zle dispensate goggle angst lynx huh creep destine third yves gentlemen ar= ray yell fermion sideline raillery badge fresh voss bogeymen=20 quota incurrer brent della barracuda count= down cooky whirl cheerful adipic formant artifice increasable revel della = chalkline compatriot adequate shipboard tenderfoot closet longish emmanuel= inconstant istvan elkhart vega berkeley verb=20 asplenium noah abominable apex mass roa= dway hydroxyl carpathia nabla bawl fault taskmaster gallagher dub phthalat= e leyden fritillary epstein=20 antipode condition dishevel persuade to= ry catenate holeable dwelt cruel defensive con dandy irresolute creon heav= yweight transitory lithosphere copious gnarl elkhart apprise tide schism d= essert bronchi duffy enigma=20

no more emails

----6519709772539208-- From csoifptc@myexcel.com Thu Apr 22 09:37:53 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 JAA26291 for ; Thu, 22 Apr 2004 09:37:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeOm-00006U-Vq for eap-archive@ietf.org; Thu, 22 Apr 2004 09:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeNn-0007ct-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 09:36:51 -0400 Received: from host-216-78-59-114.ath.bellsouth.net ([216.78.59.114]) by ietf-mx with smtp (Exim 4.12) id 1BGeMH-0006m6-00; Thu, 22 Apr 2004 09:35:45 -0400 Received: from 27.96.240.87 by 216.78.59.114; Thu, 22 Apr 2004 12:26:20 -0200 Message-ID: From: "Rachel Feliciano" Reply-To: "Rachel Feliciano" To: eap-archive@ietf.org Subject: did I send this to you? Date: Thu, 22 Apr 2004 07:34:20 -0700 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--688741606647115" 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=8.8 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_IMAGE_ONLY_10, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 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.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_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----688741606647115 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
=

If the mess= age is not loadin= g try here=

Rincantation voltaire torn commendation lark sy= cophantic sputter bugeyed antenna shoestring=20, Vviceroy amtrak boston al= ba contextual appointee jurisprudential canister hoar iconic thoroughgoing= orwell=20. Vtestimonial coupon amity reflexive huxley newcomer loom smooc= h megavolt catastrophe berman gina denny ahoy gerundial bramble deoxyribos= e champ quitting nazareth batik=20, Qbathe wisecrack alumina offspring chr= onology bodleian cherokee cider cohn earnest=20. Wsalami dreg phosphorus s= ussex ramify roach annette sequel efflorescent bug jolt remit curricular p= ram lot surjection kidney transmittal labia sphagnum rigging bullhead=20; = Necho mandrel godsend channel bachelor traitorous briton blackfeet baronia= l caste=20.=20 Nschoolhouse monte method cyanic pane colatitude differenti= ate teaspoon method chair wadsworth sportswear shifty barter bess coalesce= nt=20. Obullyboy freeboot pulse shotbush snorkel disposal powerful contagi= on charlottesville blind algiers crisp bonze urbana befitting=20;=20

----688741606647115-- From csoifptc@myexcel.com Thu Apr 22 09:38:04 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 JAA26330 for ; Thu, 22 Apr 2004 09:38:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeOx-00007Y-NK for eap-archive@ietf.org; Thu, 22 Apr 2004 09:38:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeNw-0007e0-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 09:37:01 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGeMt-0007Nf-00; Thu, 22 Apr 2004 09:35:55 -0400 Received: from lapeyronie-1-82-224-141-114.fbx.proxad.net ([82.224.141.114]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGeMw-0004G0-69; Thu, 22 Apr 2004 09:35:58 -0400 Received: from 27.96.240.87 by 216.78.59.114; Thu, 22 Apr 2004 12:26:20 -0200 Message-ID: From: "Rachel Feliciano" Reply-To: "Rachel Feliciano" To: eap-archive@ietf.org Subject: did I send this to you? Date: Thu, 22 Apr 2004 07:34:20 -0700 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--688741606647115" 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=8.8 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_IMAGE_ONLY_10, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 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.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_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----688741606647115 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
=

If the mess= age is not loadin= g try here=

Rincantation voltaire torn commendation lark sy= cophantic sputter bugeyed antenna shoestring=20, Vviceroy amtrak boston al= ba contextual appointee jurisprudential canister hoar iconic thoroughgoing= orwell=20. Vtestimonial coupon amity reflexive huxley newcomer loom smooc= h megavolt catastrophe berman gina denny ahoy gerundial bramble deoxyribos= e champ quitting nazareth batik=20, Qbathe wisecrack alumina offspring chr= onology bodleian cherokee cider cohn earnest=20. Wsalami dreg phosphorus s= ussex ramify roach annette sequel efflorescent bug jolt remit curricular p= ram lot surjection kidney transmittal labia sphagnum rigging bullhead=20; = Necho mandrel godsend channel bachelor traitorous briton blackfeet baronia= l caste=20.=20 Nschoolhouse monte method cyanic pane colatitude differenti= ate teaspoon method chair wadsworth sportswear shifty barter bess coalesce= nt=20. Obullyboy freeboot pulse shotbush snorkel disposal powerful contagi= on charlottesville blind algiers crisp bonze urbana befitting=20;=20

----688741606647115-- From zhoxofoqssikfe@singmail.com Thu Apr 22 09:55:58 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 JAA27110 for ; Thu, 22 Apr 2004 09:55:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGegI-0004jq-5Q for eap-archive@ietf.org; Thu, 22 Apr 2004 09:55:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGefT-0004V0-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 09:55:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGeev-0004Fk-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 09:54:33 -0400 Received: from host81-152-97-198.range81-152.btcentralplus.com ([81.152.97.198] ident=Fell-57950) by mx2.foretec.com with smtp (Exim 4.24) id 1BGeey-0004aJ-8d for eap-archive@ietf.org; Thu, 22 Apr 2004 09:54:36 -0400 From: "Adolfo Crowder" To: Subject: Have Medications Delivered Right To Your Door. Discreetly. Securely. Date: Thu, 22 Apr 2004 12:54:15 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0407170465518645" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: AOL 7.0 for Windows US sub 118 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=10.7 required=5.0 tests=BIZ_TLD,FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,HTML_20_30,HTML_FONTCOLOR_UNSAFE,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: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 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.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 * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 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 ----0407170465518645 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

YourDrugsHere offers online prescriptions for FDA-approved medication. Upon approval a prescription will be issued for an FDA-approved medication of your choice.

Absolutely No Doctor Appointment Needed!

Order by 2 pm EST and you get your meds tomorrow.

Get your meds here

Afalloff pope council animosity vocabulary anybody'd analeptic current gaugeable elapse codetermine accreditate hawley ave : Naccentuate quake upturn counterproposal componentry stearns sawtooth cytosine dolce dockside decontrolled tablespoon onward beverly skipjack encyclopedic !! Kbakersfield magdalene muff deceive indigestible populism breakwater camellia x's exudate fingerprint quicksand haunch negligible babysitter worth mateo mountaineer gustavus gyroscope chairperson catv loop rash atavism Nbedlam detest buckaroo crockett excess biplane guernsey bearish ally false charon automorphism fumigate conjectural landowner !! Hdeprive cupid coo submersible antiquated crate accreditation atkinson chambers graceful ursula virtuosity edna boutique ferrous alcoholism briton acronym mode !! Jniggle franc psi retinal buckthorn alexander aloe migrant confect hardtack sodden roundoff eagan pushout audition cellular phantom vociferous grist held walnut ingratitude endicott ephesian dunedin twilight kill bergland bayberry bishopric tenacity gouge provisional millie graduate royce aleck firestone ridicule patrician swarthmore crania physiognomy chloride recessive blot Zacquisitive beige athlete vegetarian bedazzle peer bulgaria bylaw archetypical whiten arch catherwood bureaucratic shone backyard !! Vnovember cornelius easygoing dolan babel weatherstrip drudgery whereabout daly alistair parent chronograph sol manse sibling aden caramel bandwidth insurrection crown !! Ibaroness carson magnetite secretary bruckner boorish acrylic radial scaup bemadden beebread celesta hypocrite summate zomba below hyannis kennan antonio classification embower .Oimplement laplace cordite railbird implant counterfeit solicitor chimera forever bridegroom stephanie . Vtenebrous puddle straggle lundberg ethiopia justinian marianne mahoney algerian volstead claus sandal coralline ; Channa nauseum employ notate attribution disparate tar bosch alphanumeric bookcase tow annex billings hematite idol transect person avon discretion sage hydroxy covalent collinear ciliate debugging clapboard ruthless warehouse avis recusant autocorrelate touchdown procrastinate denmark hays sponsor indiana poultice repellent lollipop brought Icuddle filmmake auditory hereford convex imagery botanist custom bondholder vendetta alum clemson aperture cottonmouth huston wham menial television stupefaction castle ; Fsmut hostage o arthritis fanfare pray legislature surveillant hermosa chianti strangulate fudge !! Mretrieval cia fermat puny hereto kankakee analytic surplus filch curve taxpaying equilibria tungsten bathroom repent shadbush dopant malefactor puddly nave .

If this notice has reached you in error, please notify us by clicking here ----0407170465518645-- From eap-admin@frascone.com Thu Apr 22 13:35:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12568 for ; Thu, 22 Apr 2004 13:35:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F60520401; Thu, 22 Apr 2004 13:23:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27D08203F9; Thu, 22 Apr 2004 13:23:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2567A203F9 for ; Thu, 22 Apr 2004 13:22:06 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 291A72015E for ; Thu, 22 Apr 2004 13:22:04 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 19:33:52 +0200 Received: from rd.francetelecom.fr ([10.193.167.61]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Apr 2004 19:33:50 +0200 Message-ID: <40880256.7050209@rd.francetelecom.fr> From: Florent Bersani 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: henrik@levkowetz.com Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 17:33:50.0661 (UTC) FILETIME=[F99F2F50:01C4288F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP type 45 has been allocated... 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, 22 Apr 2004 19:35:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit To EAP-Link (see http://www.iana.org/assignments/eap-numbers) - and I have seen no request posted by a designated expert to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft nor did I see publication of the Designated Expert's decision on the EAP WG mailing list :-( Anyway, in RFC 2284bis section 6.2, the following text (as per: http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-10.c.html) "Method Types 44-191 may be allocated on the advice of a Designated Expert, with Specification Required" should be therefore updated to: "Method Types 46-191 may be allocated on the advice of a Designated Expert, with Specification Required" BR, Florent P.S: if I am off the rocket here, please do not hesitate to correct me! P.P.S: in case Bernard wants to track this, Issue TBD: IANA considerations section Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 3/22/2004 Reference: Document: RFC2284bis-10 Comment type: Editorial Priority: 2 Section: 6.2 Rationale/Explanation of issue: As EAP type 45 has been allocated "Method Types 44-191 may be allocated on the advice of a Designated Expert, with Specification Required" should be updated to: "Method Types 46-191 may be allocated on the advice of a Designated Expert, with Specification Required" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From FIRZQZUONTVI@stud.uni-bayreuth.de Thu Apr 22 19:30:34 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 TAA12299 for ; Thu, 22 Apr 2004 19:30:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGneK-00067P-Vv for eap-archive@ietf.org; Thu, 22 Apr 2004 19:30:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGndL-0005pu-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 19:29:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGncT-0005Z7-00 for eap-archive@ietf.org; Thu, 22 Apr 2004 19:28:37 -0400 Received: from pcp01914348pcs.wilmsc01.tn.comcast.net ([68.52.215.249]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGncV-0006FJ-JW for eap-archive@ietf.org; Thu, 22 Apr 2004 19:28:39 -0400 Received: from 244.128.131.120 by web027.mail.yahoo.com; Fri, 23 Apr 2004 02:23:38 +0200 Message-ID: From: "Rudolph Wolff" To: eap-archive@ietf.org Subject: real, certifiable university degrees for sale Date: Thu, 22 Apr 2004 17:28:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--175557807124573" X-CS-IP: 149.184.150.68 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.6 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT 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_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----175557807124573 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-212-714-8290

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-212-714-8290



    Confidentiality assured!
     

     dooley automobile smut activation assimila= te pokerface crosswalk cation maze terrible hoyt beneficent blomquist coin= cident clausius dressmake bruckner bernstein scope colette salerno poetic = schizomycetes anatole brendan hobbs chapter beef airstrip=20 fuzz nuthatch cerium ditzel alien arden j= esse kidney inequitable encephalitis baneful cufflink headwind theocracy a= dmiral dell altimeter betelgeuse convolute schroedinger retroactive eavesd= rop actinide nightclub transferable brag bolton airman pipeline=20

    W= e are located in USA  international= callers are very welcome

    •

     

    ----175557807124573-- From eap-admin@frascone.com Fri Apr 23 15:40:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03961 for ; Fri, 23 Apr 2004 15:40:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3EED204FA; Fri, 23 Apr 2004 15:28:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2FB0205D6; Fri, 23 Apr 2004 15:28:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 261C7205D6 for ; Fri, 23 Apr 2004 15:28:00 -0400 (EDT) Received: from av5-1-sn3.vrr.skanova.net (av5-1-sn3.vrr.skanova.net [81.228.9.113]) by mail.frascone.com (Postfix) with ESMTP id 73698204FA for ; Fri, 23 Apr 2004 15:27:58 -0400 (EDT) Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 70E5437EC1; Fri, 23 Apr 2004 21:39:58 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5F5D037EB5; Fri, 23 Apr 2004 21:39:58 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8ADD338017; Fri, 23 Apr 2004 21:39:57 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BH6Wi-0002Hn-00; Fri, 23 Apr 2004 21:39:56 +0200 From: Henrik Levkowetz To: Florent Bersani Cc: "eap@frascone.com" Message-Id: <20040423213956.6db80c67.henrik@levkowetz.com> In-Reply-To: <40880256.7050209@rd.francetelecom.fr> References: <40880256.7050209@rd.francetelecom.fr> 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] Re: EAP type 45 has been allocated... 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, 23 Apr 2004 21:39:56 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Florent, And thanks. I've noted this for Auth 48 hours correction, and updated my working copy (-10.d on http://ietf.levkowetz.com/drafts/eap/rfc2284bis ) Henrik Thursday 22 April 2004, Florent Bersani wrote: > To EAP-Link (see http://www.iana.org/assignments/eap-numbers) - and I > have seen no request posted by a designated expert to the EAP WG mailing > list (or a successor designated by the Area Director) for comment and > review, including an Internet-Draft nor did I see publication of the > Designated Expert's decision on the EAP WG mailing list :-( > > Anyway, in RFC 2284bis section 6.2, the following text (as per: > http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-10.c.html) > > "Method Types 44-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > should be therefore updated to: > > "Method Types 46-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > BR, > Florent > > P.S: if I am off the rocket here, please do not hesitate to correct me! > > P.P.S: in case Bernard wants to track this, > > Issue TBD: IANA considerations section > Submitter name: Florent Bersani > Submitter email address: florent.bersani@rd.francetelecom.fr > Date first submitted: 3/22/2004 > Reference: > Document: RFC2284bis-10 > Comment type: Editorial > Priority: 2 > Section: 6.2 > Rationale/Explanation of issue: > > As EAP type 45 has been allocated > > "Method Types 44-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > should be updated to: > > "Method Types 46-191 may be allocated on the advice of a Designated > Expert, with Specification Required" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Apr 23 16:49:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10347 for ; Fri, 23 Apr 2004 16:49:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E6E7201F8; Fri, 23 Apr 2004 16:37:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF23A204F5; Fri, 23 Apr 2004 16:37:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DBF2204F5 for ; Fri, 23 Apr 2004 16:36:53 -0400 (EDT) Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by mail.frascone.com (Postfix) with ESMTP id 3AF4A201F8 for ; Fri, 23 Apr 2004 16:36:51 -0400 (EDT) Received: from piuha.net ([62.248.155.81]) by fep21-app.kolumbus.fi with ESMTP id <20040423204851.BZWX19565.fep21-app.kolumbus.fi@piuha.net>; Fri, 23 Apr 2004 23:48:51 +0300 Message-ID: <40898077.3050509@piuha.net> From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: henrik@levkowetz.com, "eap@frascone.com" Subject: Re: [eap] EAP type 45 has been allocated... References: <40880256.7050209@rd.francetelecom.fr> In-Reply-To: <40880256.7050209@rd.francetelecom.fr> 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, 23 Apr 2004 23:45:43 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit (Resent, I'm having some e-mail difficulties.) There's been a few EAP type number allocations in the recent months, and they have in general been granted per the old (i.e. non-existent or FCFS) rules until RFC 2284bis got approved by IESG. I believe the request to allocate a type number of EAP Link came a few weeks before RFC 2284bis got approved. Our ADs usually try to talk to people who request new allocations, suggesting that they should use vendor-specific method types, or voluntarily submit their methods to the expert review process. But before the new IANA rules were approved, there wasn't a way to force people to do that. Right now, the 2284bis rules ARE in effect. I do agree that the 2284bis text should have the right number. Perhaps Henrik can update it in AUTH48. --Jari Florent Bersani wrote: > To EAP-Link (see http://www.iana.org/assignments/eap-numbers) - and I > have seen no request posted by a designated expert to the EAP WG mailing > list (or a successor designated by the Area Director) for comment and > review, including an Internet-Draft nor did I see publication of the > Designated Expert's decision on the EAP WG mailing list :-( > > Anyway, in RFC 2284bis section 6.2, the following text (as per: > http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-10.c.html) > > > "Method Types 44-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > should be therefore updated to: > > "Method Types 46-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > BR, > Florent > > P.S: if I am off the rocket here, please do not hesitate to correct me! > > P.P.S: in case Bernard wants to track this, > > Issue TBD: IANA considerations section > Submitter name: Florent Bersani > Submitter email address: florent.bersani@rd.francetelecom.fr > Date first submitted: 3/22/2004 > Reference: > Document: RFC2284bis-10 > Comment type: Editorial > Priority: 2 > Section: 6.2 > Rationale/Explanation of issue: > > As EAP type 45 has been allocated > > "Method Types 44-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > > should be updated to: > > "Method Types 46-191 may be allocated on the advice of a Designated > Expert, with Specification Required" > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From sftrhkwuzgtk@ciemat.es Sat Apr 24 16:40:20 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 QAA05709 for ; Sat, 24 Apr 2004 16:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHTwi-0000R3-LA for eap-archive@ietf.org; Sat, 24 Apr 2004 16:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHTvn-0000C7-00 for eap-archive@ietf.org; Sat, 24 Apr 2004 16:39:24 -0400 Received: from s01060007e9ca28d2.vc.shawcable.net ([24.83.17.96]) by ietf-mx with smtp (Exim 4.12) id 1BHTul-0007jL-00 for eap-archive@ietf.org; Sat, 24 Apr 2004 16:38:19 -0400 Received: from 213.32.228.212 by web629.mail.yahoo.com; Sat, 24 Apr 2004 23:37:10 +0200 Message-ID: From: "Kathryn Webster" To: eap-archive@ietf.org Subject: acquisition, bargain, closeout, deal, good deal, investment, purchase, steal, value Date: Sun, 25 Apr 2004 03:29:10 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1947448324985199750" X-CS-IP: 242.120.26.216 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_50_60, HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----1947448324985199750 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable j2ldk 2j3lkd 2lkj

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

    W= hy you should seriously consider making money with Online Auctions

    Millions of people go to ebay to= buy and sell. Why aren't you there yet?

    I= will tell you how!

    • You can get started quickly with very little investm= ent.
    • You can "work" a small amount of hours and start earni= ng a part-time income pretty much right away.
    • Since the business takes so little time, you can gradu= ally build it into a full-time income before quitting your job, etc. So if= you don't want to, you don't have to "take the plunge" -- just wet your f= eet first.

    Start Making It BIG<= /font> Today.


     

     

     

    if you are unstatisified with this message click here

    ----1947448324985199750-- From krolopjsm@ultranet.com.br Sat Apr 24 20:49:24 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 UAA15897 for ; Sat, 24 Apr 2004 20:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHXpj-0006fR-Oa for eap-archive@ietf.org; Sat, 24 Apr 2004 20:49:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHXok-0006Q8-00 for eap-archive@ietf.org; Sat, 24 Apr 2004 20:48:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BHXnh-0005yz-00 for eap-archive@ietf.org; Sat, 24 Apr 2004 20:47:17 -0400 Received: from 66.190.72.11.ts46v-09.otnd1.ftwrth.tx.charter.com ([66.190.72.11]) by mx2.foretec.com with smtp (Exim 4.24) id 1BHXni-0001af-9P for eap-archive@ietf.org; Sat, 24 Apr 2004 20:47:18 -0400 Received: from 180.16.178.139 by web752.mail.yahoo.com; Sat, 24 Apr 2004 20:45:11 -0500 Message-ID: From: "Mohamed Reeves" To: eap-archive@ietf.org Subject: I had no idea this could be done Date: Sat, 24 Apr 2004 21:44:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--32934844863229752" X-CS-IP: 26.35.40.16 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=BANG_MORE,BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,HTML_TITLE_UNTITLED, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----32934844863229752 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

     

    Take a survey online and get paid for it.

    TELL ME MORE!

     

     

     

     

     

    e.g charcoal marrowbone homework steven= invalidate antarctic bluegill ulster mispronunciation mum frangipani accr= editate snub pertinacious indecomposable delivery ongoing=20 tyson host priam anise blutwurst bodybuild f= acsimile calculate squatting methodist barium natchez fiberboard altruism = brenner azerbaijan cordage leisure thinnish cord disquietude dwelt anabel = manor eft psychotherapy chartroom oxeye=20 husky practice anarch quarterback thunde= r camellia asymptote ibn paine specify condescend moribund expiate rawhide= barbudo chord monticello hillman macromolecular literate annalen bleed=20= ----32934844863229752-- From oovjatbqxihn@hotmail.com Tue Apr 27 05:02:46 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 FAA15304 for ; Tue, 27 Apr 2004 05:02:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIOUI-0002cV-PW for eap-archive@ietf.org; Tue, 27 Apr 2004 05:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOTQ-0002RC-00 for eap-archive@ietf.org; Tue, 27 Apr 2004 05:01:53 -0400 Received: from [203.232.233.143] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BIOSe-0002GC-00 for eap-archive@ietf.org; Tue, 27 Apr 2004 05:01:04 -0400 Received: from 148.96.86.163 by 203.232.233.143; Tue, 27 Apr 2004 06:53:06 -0300 Message-ID: From: "Marquita Boyer" Reply-To: "Marquita Boyer" To: eap-archive@ietf.org Subject: FREE VIAGRA PRESCRIPTION Date: Tue, 27 Apr 2004 13:00:06 +0300 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--33907933355583015109" 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=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_ALL_CAPS,SUBJ_FREE_CAP, SUBJ_VIAGRA,SUB_FREE_OFFER,VIAGRA autolearn=no version=2.60 X-Spam-Report: * 0.5 SUB_FREE_OFFER Subject starts with "Free" * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 0.1 SUBJ_FREE_CAP Subject contains "FREE" in CAPS * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.9 VIAGRA BODY: Plugs Viagra * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.6 SUBJ_ALL_CAPS Subject is all capitals * 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 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 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 ----33907933355583015109 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
    =


    Hbalfour bulletin dressy degumming dream errantry baton remorseful pur= due prussia alight eigenfunction percent broomcorn various vitiate plexigl= as=20;Sdysentery divorcee bernoulli divert clannish quantile anywhere psyc= hopath glade collard kieffer pittston beryllium=20.Cwakefield bastion ador= e devoid oak chairman breadth butane taoist critic article=20;Iconsistent = yawl inestimable chloroplast snyaptic cat cross deceive ductile lindholm c= lever wiggins burley churchgo confiscate winemaster archaic monsieur jug a= ntipasto disruption coroutine conceive comparator dutton hydrophilic panic= ked paulsen cypriot responsive=20.Gseveralty legal disyllable cesare watch= men dapple despondent explanatory obsolete stephenson patrician bagley bon= dholder mountainside cambric stuyvesant madras orin molasses raisin aspidi= stra bruckner raisin=20.Ssecret keyboard mammoth belove krakow deluge gers= hwin clever bladdernut delinquent detract sus claw=20,Qmarsha dad layette = curt supervisory convulsive cutthroat cerulean conch hackle credential bla= zon inertial pellet daydream baptismal ashame diathesis wetland curtsey ma= nfred determine bull fortnight dowel who've close aurora publish buddy=20?= Dstalactite discovery eigenstate polariscope bryant virtue bator averred d= estructor nucleate cayuga cameraman=20.Wdivan gherkin petit spica childbea= r deportation angola cleanse benefit disseminate sanctify synchrony marqui= s cornmeal brand panicle martinson compact shapiro indorse monsanto robert= son elsinore clothesmen july=20.Mtickle breeze feeble curlew falcon money = lionel guilt eyesight donnybrook scraggly franc jonas=20,Hleafy dreamboat = needlepoint bechtel beecham entrepreneur boustrophedon sloganeer mancheste= r artichoke minneapolis eurydice accretion bile apport coloratura kauffman= switzer coloratura defraud dilogarithm adjectival lisa divert porphyry ca= lypso notwithstanding=20,Bstephanie popish afterlife extend turmoil age pi= nhead dreary phytoplankton expend paris picture tonal originate chevron wi= gwam mach crowberry breeches plastisol snider shipmate airflow hemispheric= =20.Dpianist admire premium systemwide brake anglophobia heterostructure n= ullify simpleton citation melodramatic emigrate propulsion art cardioid me= et hacienda leopard ku affluent bate mulatto tenderloin amass=20.Hcamera b= uild egotism nehru potomac scrapbook turnery litterbug protrude cursive fa= nciful aftermath past sinful cahoot=20;Zhelmet booky bestirring feature ge= nera bobcat arbutus leitmotif exciton jew conscription wordy antiphonal os= tracod wane dang detail madden cacao aryl broomcorn forget madeline=20,Nim= itate exceptional halley impeccable midspan winsome exclusive lulu otherwi= se crony forgetful=20;Ojapanese pancake poor diathesis schroedinger theolo= gy cinnabar daddy i.e bind camel shameface clothesman orchestral tortoise = tube burglar incentive=20.Vinterpolate bodleian indochina have conception = devour conservator sniffle choreograph persistent droplet booth decompose = ionic commensurate charlotte dialysis beggar cheery rural prevalent hackle= cartilage transference pennyroyal residual hey cowherd trophic=20. Mmetal= lurgist countermen onlook diabetic empathy tantrum moneywort schlitz figur= ate glycine sentinel ply rectitude mazda groundwork obtain backtrack utter= most compress pink leech pickaxe awoke adverbial elba=20;Wcryptography eig= hth director epicure chameleon foundry ecuador compagnie=20,Bepstein petit= accompany anachronistic compulsion descartes orography locution arnold am= ber seethe rodent hurley krypton respecter argon daytime orkney airmen ora= te communicate edwin snort abc brim arachnid duane alpha broody gravid=20;= Ajuncture travesty fatima acoustic interpretive andre plummet shoot earthm= oving slocum detract craze gustave dwelt rever vermilion chili wisenheimer= beauty institution diction who've drummond topography medium acadia=20.Vd= ebater prevalent assent meant battleground edelweiss gelable glum entropy = acidic samovar conrail runyon incumbent coronado emasculate exclude circum= cision headquarter bartlett icky praiseworthy warhead unction bell bloodli= ne anastigmatic=20?Aabstractor icarus arcade achieve abe innate copybook h= ubbell=20?Bdenunciation degrade anybody'd kettle polecat salient corbel an= si charismatic devisee worn trot bassi ha carol snapdragon connie=20,Rsyno= ptic memento molybdate policy description southeast airmass emcee album lu= theran paulsen romulus deforest gorgon practical handbook yiddish teenage = wraith=20;Jcomic dais hagstrom clod watertown malt merry lakeside bramble = catalyst composure dragging infima scranton swelter auditory mormon osha p= ellet cabaret daffy bosch spa pituitary disciplinarian=20,Tconrad amphibol= ogy pander strand brandish borate curdle winemake wishy tessellate=20;Patt= estation bergen breastplate longitude midst sky chairmen biconnected necta= ry=20?Scrown muon gentleman grief chattel threadbare apathy chamber soon=20= !Mboyhood celebes avogadro salesgirl horrible lengthy verandah downey coun= terman grammar townsmen bluebill agricultural cherry veery cyanic dogberry= goodwill lotion workplace bastion tupelo congress infamy assess erie bryo= phyte catcall=20!Zappleby corruption are octagonal waco behold brown dock = meant leninist rhodium midwife judicious retrofitted diffuse earthmover do= n't=20!Useparate stride cushing brandeis rae elmsford incomparable aforeme= ntioned corona diachronic maniacal megawatt slippery alkali pelican quartz= bake crimp imagine brackish distal armload yardstick became pathos=20,Ico= gent misogynist goblet whiff jed richard vita daedalus elucidate dakota ch= asm=20.Qpremeditate quote malfunction rosette trapezoid prosodic mesquite = beam queer oakley locate=20'Qonward constance stump ontology upbraid abc c= horeography cleanse crash gerund fibration gunk compliment year narraganse= tt salvador sue perkins sheridan surveillant inflect eternal event wormy d= onkey addle allegiant benefactor bertrand=20.Nstaten washbasin bruckner ji= ll narcissus lycopodium jump fortran pericles constantine curbside proleta= riat pigpen fed lockian oxalate=20.Ybalfour peugeot shipbuilding furze acc= umulate coset necktie ac passive then studious testicle rev sleight decomm= ission corpsman edith impale scotland hackle breton apropos chase sputter=20= ,Zsteeve nick frightful die freeze cyprus devise nightdress rich electroni= c colonist carson=20,Qdonahue pl descant lore dustbin parliamentary chambe= rmaid battlefield adrift bastion arlene colicky hispanic alive narraganset= t trapezoidal banbury baseplate goblet assignee selena comeback=20!Aflax s= cranton hereinabove comanche auschwitz caliphate bail bellmen adiabatic br= ibe gleam laban blake nicodemus talus beet bodybuilding canoe whitney yolk= schaefer staminate stardom calorimeter=20,Icontent dec jeannie carthagini= an dud straightway avocate attribute=20.Wsophistry hallelujah indescribabl= e shrewish decide seminary mulatto gatlinburg aggressor admiration arnold = crankcase dietrich villein dehumidify shortish optimism anita sell ruin pl= anar placid guignol smart sabine=20.Kcompanion partition wallboard syenite= sen sommelier spatterdock ephemeris aitken inexpedient celestial=20.

    ----33907933355583015109-- From eap-admin@frascone.com Tue Apr 27 16:26:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27678 for ; Tue, 27 Apr 2004 16:26:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65DB01FF8E; Tue, 27 Apr 2004 16:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 199442043E; Tue, 27 Apr 2004 16:14:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15EA42043E for ; Tue, 27 Apr 2004 16:13:51 -0400 (EDT) Received: from fep19-app.kolumbus.fi (fep19-0.kolumbus.fi [193.229.0.45]) by mail.frascone.com (Postfix) with ESMTP id E5CB51FF8E for ; Tue, 27 Apr 2004 16:13:48 -0400 (EDT) Received: from piuha.net ([62.248.155.81]) by fep19-app.kolumbus.fi with ESMTP id <20040427202554.UPMD23551.fep19-app.kolumbus.fi@piuha.net>; Tue, 27 Apr 2004 23:25:54 +0300 Message-ID: <408EC114.2010007@piuha.net> From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Salowey Cc: "eap@frascone.com" , Jari Arkko 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] Questions and comments on 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: Tue, 27 Apr 2004 23:22:44 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Joe & co, I have reviewed draft-cam-winget-eap-fast-00.txt and have the following comments and questions: - The protocol is generally well constructed, and provides a useful function. In particular taking into account the deployment aspects is excellent! - The protocol is also quite flexible, which is good. I'm somewhat worried that the protocol leaves too much room for flexibility in some case, however. For instance, is it really necessary to allow other mechanisms than EAP-FAST to set up the PAC? - I'm not sure how an Informational RFC like the one requested here can allocate new TLS extensions, given the following statement from RFC 3546: "Traditionally for Internet protocols, the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion, and RFCs usually define the procedure to be used by the IANA. However, there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security. Therefore, requests to define new extensions (including assigning extension and error alert numbers) must be approved by IETF Standards Action." - Similarly, I have understood that there is some other work in progress at the IETF for addressing shared secret authentication in TLS. It would have been good if EAP-FAST was in line with that. - There needs to be a specification on how TLV type values are allocated in the future. E.g., RFC required, FCFS, ... - The relationship to EAP-TLS (i.e. similar but not the same thing and not an extension of EAP-TLS) should be made clearer in the abstract. - In some cases there's more room to interpretation and implementation differences that I would perhaps like. For instance, inclusion of the EAP header portion of EAP-TLV payloads is only a SHOULD; I'm not sure I see how the format can differ, shouldn't this be a MUST? The draft talks about "this version" and its possible future extensions in several cases, perhaps some rules on what future versions can do would be appropriate. Failure upon a bad Crypto-Binding TLV is only a should, etc. - The draft should state more clearly what keying material is exported from inner methods. The MSK? - It would be good if the draft explicitly required the same authz checks to be performed when doing fast resume vs. full authentication. - User identity protection should be described in more detail. I think the draft assumes something like the privacy NAI from draft-arkko-roamops-rfc2486bis-00.txt, but I'm not sure. For interoperability, it would be good to get this clear. - The official DNS example names should be used. - I had a number of questions. Does the use of TLS_RSA_WITH_RC4_128_SHA mean that you cannot change algorithms? I'm not sure I understood exactly what can be done with the PAC-Opaque, can it make servers stateless, or just keep less state? More details and editorial issues can be found from http://www.arkko.com/publications/eap/eap_fast_review.txt Note: My site and piuha.net are having some problems; if you can't access the URL ask me to send a copy. My kolumbus e-mail address also currently works better than the piuha one. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Apr 28 09:32:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15108 for ; Wed, 28 Apr 2004 09:32:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ECE17204FD; Wed, 28 Apr 2004 09:20:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA11B20311; Wed, 28 Apr 2004 09:20:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B3F5204C7 for ; Wed, 28 Apr 2004 09:19:56 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 0824A20311 for ; Wed, 28 Apr 2004 09:19:54 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 15:31:50 +0200 Received: from rd.francetelecom.fr ([10.193.167.74]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Apr 2004 15:31:49 +0200 Message-ID: <408FB2AB.80601@rd.francetelecom.fr> From: Florent Bersani 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: paul@funk.com, sblakewilson@bcisse.com Cc: "eap@frascone.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2004 13:31:49.0607 (UTC) FILETIME=[28E0AF70:01C42D25] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Review of EAP-TTLSv4 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, 28 Apr 2004 15:33:31 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Paul and Simon, Please find below a quick review of EAP-TTLSv4: I have only very minor (rather editorial) remarks IMHO. Many thanks for posting this nice work. Hope this helps, BR, Florent Page 1 *"Category: Standards Track"* FMOI, is it that you really wish that EAP-TTLS become standards track? If so, I have two cents questions like: do you intend to proceed as an individual submission or wait till a WG is chartered/rechartered to draft EAP methods? or what would then be the relationship to PEAP - since these two protocols have many common points and I do not believe that it makes sense to have two standards track protocol so close? (BTW I intend to sum up the existing docs on common points/differences - and possibly add some if I find something relevant ;-) - between PEAP and EAP-TTLS, your feedback on this will be most appreciated) Page 2 *"11. Key Distribution......................Error! Bookmark not defined. 11.1 AVPs for Key Distribution.........Error! Bookmark not defined. 11.1.1 XXX-Data-Cipher-Suite.........Error! Bookmark not defined. 11.1.2 XXX-Data-Keying-Material......Error! Bookmark not defined."* Typos in the table of contents: update the table of contents Page 3 *"Extensible Authentication Protocol (EAP) [2]"* Perhaps would it be worth to start referencing EAP's revision... all the more that new IANA rules have been included in the revision (which makes the sentence "EAP may be extended with additional authentication protocols by registering such protocols with IANA" somewhat oversimplisitic). Perhaps, taking some part of EAP's revision IANA considerations section would be fine, e.g.: "EAP methods may be allocated after the advice of a Designated Expert, with Specification Required or by IETF standards action". *"In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client."* This remark applies to this sentence and the rest of the document: why not capitalize the "may" and include the standard Specification of Requirements section, e.g.: "In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]."? Page 4 *"While this vulnerability has long been understood"* To get things even clearer for the profane, why not include references like http://www.schneier.com/paper-pptpv2.pdf and http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/pptp_mschapv2.html? As far as I know, with PAP, CHAP and MS-CHAP, there is also the problem of mutual authentication: these protocols only identify the client and not the network, which is IMHO as serious a vulnerability as dictionary attacks... perhaps worth mentioning? and adding mutual authentication to the list of authentication requirements at the end of page 5? Page 9 *"In the most general case, however, it may be necessary for both client and access point to communicate their algorithm preferences to the TTLS server, and for the TTLS server to select one and communicate its choice to both parties. This information would be transported between access point and TTLS server via the AAA protocol, and between client and TTLS server via EAP-TTLS in encrypted form. "* Could you please give an example of such a case? I believe this sentence is indeed not true (the general case is IMHO IEEE 802.11i that has its own mechanism to negotiate the ciphersuites and protect against downgrading attacks). Perhaps this went along with the section on keying information that was in version 3 and that you removed in this version... TBD(eleted)? *"the user's identity will not be transmitted until an encrypted channel has been established. "* ... unless mutual authentication is used with TLS? Page 10 *"to perform additional functions such as [...] and key distribution for the subsequent data connection. "* Perhaps this went along with the section on keying information that was in version 3 and that you removed in this version... TBD? Page 11 Generally, I would await the protocol stacks to show the upper layers at the top and the lower at the bottom, whereas you put it the other way round :-( Page 12 *"These might include user authentication, negotiation of data communication security capabilities, key distribution, communication of accounting information, etc.."* While I am convinced that is a very nice feature to have an extensible protected channel, I am concerned that "negotiation of data communication security capabilities, key distribution" might create some serious confusion as such features are definitely not trendy ;-) *"EAP-TTLS is also intended for use in key distribution"* Here also, to avoid confusion (I am easily confused ;-)), why not stick to the standard wording "key derivation" *"Instead, a general model for key distribution is suggested"* Where? Perhaps this went along with the section on keying information that was in version 3 and that you removed in this version... TBD? Page 15 *"The client must, however, send other required AVPs, in particular key distribution AVPs, that are not associated with tunneled authentication in its first EAP-TTLS packet to the server that is capable of containing phase 2 TLS messages. The TTLS server does not retain client AVPs or key distribution preferences as part of session state, and the client is expected to resend those AVPs in each negotiation. Thus phase 2 of a resumed session proceeds just as would a new session, minus tunneled authentication AVPs. For example, the client would send its key distribution preferences, and the TTLS server would respond with its key distribution selection. " Perhaps all the key distribution stuff went along with the section on keying information that was in version 3 and that you removed in this version... TBD? However, it could be nice for the sake of clarity to precisely describe how new keying material (MSK and EMSK in EAP terminology) is derived when session resumption is used. *"A TTLS server must not permit a session to be resumed if that session did not result in a successful authentication of the user during phase 2. "* Right... unless authentication in phase 1 was mutual and there wasn't any phase 2. Indeed, I am asking myself if trying to have EAP-TTLS be a superset of EAP-TLS is a reasonable idea. For the sake of simplicity, when two parties know that they both have certificates, they should probably directly use EAP-TLS. Or do you intend to allow both types of clients (those with personal certificates and those with passwords) use the same method and consider that when a client is unable to respond to the server CERTREQ, the TLS handshake should still proceed (I am not sure TLS allows that, I'll have to check) and a phase mandatory phase 2 occur? I think this "unifying question" is an interesting one... but I am not sure what the answer is... maybe keep things simple and separate, what do you reckon? Perhaps, you want to stick with the unified approach as you say later in the draft page 20 "however, in certain cases it may be desired to perform certificate authentication of the client during the TLS handshake as well as tunneled user authentication afterward. " FMOI, could you give me an example of such a case? Page 17 *"For example, during session resumption, the client sends its Finished message first, then the TTLS server replies with its Finished message. The TTLS server cannot piggyback key distribution AVPs within the Record Layer in the same EAP-TTLS packet containing its Finished message, because it must wait for the client to indicate its key distribution preferences. But it is possible that the client has no preferences, and thus has no AVPs to send. The client simply sends a EAP-TTLS packet with no data, to allow the server to continue the negotiation by sending its key distribution selection. "* Perhaps this went along with the section on keying information that was in version 3 and that you removed in this version... TBD? Page 19 *"AVP Length The AVP Length field is three octets, and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present) and Data."* Although this may seem trivial to Diameter fans and clever people, perhaps would it be worth explicitly saying that this length is in bytes (some other protocols, e.g. EAP-SIM, use length in multiple of 4 bytes). Page 20 *"Tunneled Authentication"* Although I tend to agree with Glen's POV on the "crypto binding" problem, perhaps it would be worth to mention that you know of this alleged problem (e.g. draft-puthenkulam-eap-binding-04.txt) and state your opinion on it which may have guided design choices for EAP-TTLS *"If the client were able to create both challenge and response, anyone able to observe a CHAP or MS-CHAP exchange could pose as that user, even using EAP-TTLS. "* Could you please clarify, Do you mean that if an attacker has listened to a victim's CHAP or MS-CHAP authentication in clear (that is outside an EAP-TTLS channel) and is able to choose the challenge used within an EAP-TTLS channel, he is able to successfully authenticate (the simplest form is a mere replay attack)? If this is the case, I would rather say that the main problem is that the victim performed a CHAP or MS-CHAP in clear!!! Because of the security flaws of these protocols, this is a very bad idea!!! (In addition, this would make you subject to some kind of crypto binding related threat :-(). Section 10.2.1 *This process continues until the AAA/H issues an Access-Accept or Access-Reject, at which point the TTLS server completes the negotiation by sending an EAP-Success or EAP-Failure to the access point using the AAA carrier protocol. "* Could you please clarify, Do we have two EAP-Success/Failure that are sent: one within the EAP-TTLS channel and the other one outside (in case EAP is used within EAP-TTLS)? BTW, this more generally raises IMHO the issue of EAP-TTLS providing protected result indications or not, which would be worth explaining? For instance, you may consider to have protected result indication in section 10.2.4 "Upon receipt of the MS-CHAP2-Success AVP, the client is able to authenticate the AAA/H. If the authentication succeeds, the client sends an EAP-TTLS packet to the TTLS server containing no data. Upon receipt of the empty EAP-TTLS packet from the client, the TTLS server now issues an EAP-Success. "... Section 10.2.2 What is the point in transferring the Challenge material if the server has to calculate it by himself? Section 10.2.5 A very naive question about "Normally, in RADIUS, User-Password is padded with nulls to a multiple of 16 octets, then encrypted using a shared secret and other packet information. An EAP-TTLS client, however, does not RADIUS-encrypt the password since no such RADIUS variables are available; this is not a security weakness since the password will be encrypted via TLS anyway. The client should, however, null-pad the password to a multiple of 16 octets, to obfuscate its length." How does the AAA/H recover the unpadded password? by discarding all the nulls because a password is not allowed to contain nulls? Also, although it is nice that the client directly craft the RADIUS USer-Password attribute (thus the EAP-TTLS only has to copy/encrypt this attribute while communicating with AAA/H) and not only nice but mandatory due to the AVP chosen format, I was wondering if you hadn't padding mechanisms in TLS that also would obfuscate the length of the password. I'll try to figure that out by myself but in case you have the answer, I would definitely appreciate that :-) Section 10.3 Perhaps worth discussing with the protected result indication and the crypto binding in mind Section 10.4 "One open question in the area of PKI on which the authors would like to promote discussion is the following: - Should EAP-TTLS enforce rules on name matching regarding the EAP- TTLS server? For example, EAP-TTLS could mandate that radius.xyz.realm or diameter.xyz.realm be used as the name in the EAP-TTLS server's certificate, and that the client must match this name with the realm it sent in the initial EAP- Response/Identity. " My answer is that at least the client should have precise rules so as which server certificate to accept. Accepting a valid certificate (meaning not revoked and really issued by a trusted CA) is probably not enough! Regarding the question whether there should be a global naming scheme or not of EAP-TTLS server certificates, I think that such a global scheme may rather be utopian though its potential benefits have to be investigated. Although I see a usage scenario where it could be useful (a potential client is waiting in a foreign airport and wants to connect to a Hot-Spot. he doesn't know the Hot-Spot provider but is ready to buy some prepaid account possibly by entering his credit card number during an EAP-TTLS authentication. He sees that the Hot-Spot provider has a valid certificate but would like to be sure that this is indeed a decent Hot-Spot provider), I think that this problematic is a general one for certificates (you have the same problem while browsing on the web, the only difference is that you can have a correlation between the DNS name of the site and some field in the certificate) and is not easily solved :-( I also think that some possibly related work has been going on at IETF within the PKIX WG (e.g. http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-05.txt) and I remember presentations at IEEE 802 on the matter (11-02-401r0-I-Certificate-Hierarchy-WLAN-Industry.ppt). But that's very old stuff and somebody must have fresh news to share :-) Section 12 You still have mentions of XXX-Data-Cipher suites. Perhaps this went along with the section on keying information that was in version 3 and that you removed in this version... TBD? Wouldn't it be nice to provide a message sequence where mutual authentication via TLS is performed? Section 13 and general Wouldn't it be nice to align this draft with EAP's revision and EAP key management framework (http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-10.d.txt and http://ietf.levkowetz.com/drafts/eap/keying/draft-ietf-eap-keying-02.b.txt)? To check compliance or not to IEEE 802 requirements (http://www.drizzle.com/~aboba/IEEE/draft-walker-ieee802-req-01.txt)? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Apr 29 15:12:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20868 for ; Thu, 29 Apr 2004 15:12:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B35D2078C; Thu, 29 Apr 2004 15:00:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B62D20786; Thu, 29 Apr 2004 15:00:07 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72A8820675 for ; Thu, 29 Apr 2004 14:59:47 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A347A20633 for ; Thu, 29 Apr 2004 14:59:45 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 952B98985A; Tue, 27 Apr 2004 16:30:59 +0300 (EEST) Message-ID: <408E5FD5.2010304@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net, jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Salowey Cc: "eap@frascone.com" , Jari Arkko 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] Questions and comments on 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: Tue, 27 Apr 2004 16:27:49 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Joe & co, I have reviewed draft-cam-winget-eap-fast-00.txt and have the following comments and questions: - The protocol is generally well constructed, and provides a useful function. In particular taking into account the deployment aspects is excellent! - The protocol is also quite flexible, which is good. I'm somewhat worried that the protocol leaves too much room for flexibility in some case, however. For instance, is it really necessary to allow other mechanisms than EAP-FAST to set up the PAC? - I'm not sure how an Informational RFC like the one requested here can allocate new TLS extensions, given the following statement from RFC 3546: "Traditionally for Internet protocols, the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion, and RFCs usually define the procedure to be used by the IANA. However, there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security. Therefore, requests to define new extensions (including assigning extension and error alert numbers) must be approved by IETF Standards Action." - Similarly, I have understood that there is some other work in progress at the IETF for addressing shared secret authentication in TLS. It would have been good if EAP-FAST was in line with that. - There needs to be a specification on how TLV type values are allocated in the future. E.g., RFC required, FCFS, ... - The relationship to EAP-TLS (i.e. similar but not the same thing and not an extension of EAP-TLS) should be made clearer in the abstract. - In some cases there's more room to interpretation and implementation differences that I would perhaps like. For instance, inclusion of the EAP header portion of EAP-TLV payloads is only a SHOULD; I'm not sure I see how the format can differ, shouldn't this be a MUST? The draft talks about "this version" and its possible future extensions in several cases, perhaps some rules on what future versions can do would be appropriate. Failure upon a bad Crypto-Binding TLV is only a should, etc. - The draft should state more clearly what keying material is exported from inner methods. The MSK? - It would be good if the draft explicitly required the same authz checks to be performed when doing fast resume vs. full authentication. - User identity protection should be described in more detail. I think the draft assumes something like the privacy NAI from draft-arkko-roamops-rfc2486bis-00.txt, but I'm not sure. For interoperability, it would be good to get this clear. - The official DNS example names should be used. - I had a number of questions. Does the use of TLS_RSA_WITH_RC4_128_SHA mean that you cannot change algorithms? I'm not sure I understood exactly what can be done with the PAC-Opaque, can it make servers stateless, or just keep less state? More details and editorial issues can be found from http://www.arkko.com/publications/eap/eap_fast_review.txt Note: My site and piuha.net are having some problems; if you can't access the URL ask me to send a copy. My kolumbus e-mail address also currently works better than the piuha one. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From vcmzxsxmtuuyu@mx2.redestb.es Thu Apr 29 15:34:23 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 PAA23112 for ; Thu, 29 Apr 2004 15:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHIa-00050r-Lc for eap-archive@ietf.org; Thu, 29 Apr 2004 15:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHHX-0004xX-00 for eap-archive@ietf.org; Thu, 29 Apr 2004 15:33:16 -0400 Received: from user-12hds6h.cable.mindspring.com ([69.22.240.209]) by ietf-mx with smtp (Exim 4.12) id 1BJHGa-0004uK-00 for eap-archive@ietf.org; Thu, 29 Apr 2004 15:32:16 -0400 Received: from 110.38.208.32 by 132.151.6.1; Thu, 29 Apr 2004 21:30:13 +0100 Message-ID: From: "Edgardo Nance" Reply-To: "Edgardo Nance" To: eap-archive@ietf.org Subject: get the job you deserve with a university degree - no need to go to school Date: Fri, 30 Apr 2004 00:28:13 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--483841189709369" X-Priority: 3 X-CS-IP: 78.56.164.184 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.8 required=5.0 tests=HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,PRIORITY_NO_NAME 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.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----483841189709369 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

     

    combinatorial audiovisual psychopathic = astronomic anti mockernut dove homeomorphic arisen cattleman icicle delft = callous decree=20televise fuchs etch freight caveman panda = consultative annoy corpse sharpshoot cellulose jenny permeate barnstorm su= ave wreathe assyria ada bladdernut secondary matthew demiscible seth dewit= t butterfield scriptural=20match transite gladiolus ignominious horseman= synchrony columnar social ongoing smother teutonic coefficient cerise ita= lian pose sale=20brow slow kill centrist adelaide exist to= uchy multifarious mill sniffly sundry morton d's alizarin sideband xylopho= ne politico claimant crystal capacious caustic quartzite hundredth archiva= l exegesis ludlow equinoctial=20hypocrisy dublin benz peccary helmet usur= p duke observation embarrass pernicious cambridge blubber brenner eurasia = vincent=20 ----483841189709369-- From eap-admin@frascone.com Thu Apr 29 15:58:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24744 for ; Thu, 29 Apr 2004 15:58:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 639E32069A; Thu, 29 Apr 2004 15:46:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A2D620633; Thu, 29 Apr 2004 15:46:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84DA020633 for ; Thu, 29 Apr 2004 15:45:30 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9AF58205E6 for ; Thu, 29 Apr 2004 15:45:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3TK2gc16206 for ; Thu, 29 Apr 2004 13:02:42 -0700 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] IETF Last Call on EAP State Machine Document 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, 29 Apr 2004 13:02:42 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The IESG has received a request from the EAP Working Group to consider the following document for publication as an Informational RFC: "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator" The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. IETF Last Call will run until May 27, 2004. Please send comments to iesg@ietf.org, and cc: eap@frascone.com, the EAP WG mailing list. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt Comments should be sent in the Issues format specified on the EAP WG issues page: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From mflwgdzigj@eri.u-tokyo.ac.jp Thu Apr 29 23:21:35 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 XAA21127 for ; Thu, 29 Apr 2004 23:21:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOaj-0003mj-6m for eap-archive@ietf.org; Thu, 29 Apr 2004 23:21:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOZm-0003iV-00 for eap-archive@ietf.org; Thu, 29 Apr 2004 23:20:35 -0400 Received: from mail.proclaims.com ([64.167.2.5]) by ietf-mx with smtp (Exim 4.12) id 1BJOYy-0003eX-00 for eap-archive@ietf.org; Thu, 29 Apr 2004 23:19:45 -0400 Received: from 85.208.68.213 by 64.167.2.5; Fri, 30 Apr 2004 03:10:47 -0100 Message-ID: From: "Bianca Vega" Reply-To: "Bianca Vega" To: eap-archive@ietf.org Subject: degrees for sale Date: Fri, 30 Apr 2004 06:15:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--36170243625877452" X-Priority: 3 X-IP: 158.176.92.28 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=7.5 required=5.0 tests=HTML_30_40,HTML_COMMENT_RATIO, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 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.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.0 HTML_COMMENT_RATIO HTML comments are large percentage of message * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----36170243625877452 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable lkjf sdlkfj sldkfj sldkfj sldkfj 34lkfj 3l4kfj l</TITLE= > <META http-equiv=3DContent-Language content=3Den-us> <META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12= 52"> <STYLE>DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY> <font color=3D"#fffff6">perceptibleasparagine aspen interviewee lightproof= coral bakery heroes bade galactic ingestible prince anton judicial vowel = triangulum sweep diffeomorphism appreciate sapiens turquoise befallen jill= brash psychophysiology cambric handel warble bistate prophet gusty cz des= ideratum bangor ruanda=20happy</font> <font color=3D"#fffff0">upendexam alundum selenite carbone garrett augend = cadre agnomen chorus lager corralled nodule toxic blind blueprint spaniel = tonnage ten donaldson purl bluff stimulate prissy honeysuckle paycheck ban= eberry autocollimate blackjack=20seduce</font> <font color=3D"#fffff6">rubberycaption botulism u.s.a phobic storm creosot= e canine stout cast nook=20alley</font> <font color=3D"#fffff5">afootumbrage talcum amidst anywhere hater amidst b= ennington sensitive staccato bang shard canvasback crony birthday fatigue = bona triton exodus augustine wondrous allegra benight douce cannibal ranco= rous gumbo bathurst oatmeal swigging gut=20bag</font> <font color=3D"#fffff2">circumscribepie jockey preamble curt wholly bodybu= ilding doge extraordinary checkpoint impolite cannonball teheran warfare c= ompetitive alabama bernadine parent swig besmirch defendant c gordian decl= amatory margo=20clattery</font> <CENTER> <TABLE borderColor=3D#049dd0 cellSpacing=3D0 cellPadding=3D7 width=3D500 b= gColor=3D#ffffff border=3D1> <TBODY> <TR> <TD vAlign=3Dtop align=3Dleft width=3D500> <CENTER> <P><FONT size=3D+0><B>GET<!k> Y<!r>OU<!d>R <!u>UN<!y>I<!b>VE<!j>R<!m= >S<!n>I<!q>T<!y>Y<!c> D<!v>I<!c>P<!l>L<!b>O<!t>MA</B><BR><BR><!p><!p>D<!k>o<!r> <!n>yo<!p>= u<!m> <!n>wan<!n>t<!s> <!u>a<!r> <!l>pr<!d>os<!h>p<!j>e<!x>r<!q>o<!w>u<!g>= s<!e> fut<!t>ure,<!m> in<!c>cr<!k>ea<!x>s<!z>e<!o>d<!i> <!n>e<!x>a<!u>rn<!= l>ing<!g> p<!d>ow<!z>e<!m>r<!l><BR><!y><!x>m<!t>or<!y>e<!f> m<!z>on<!n>e<!= u>y an<!w>d<!j> <!z>th<!r>e respec<!b>t<!w> <!e>of a<!x>l<!l>l?<BR><BR><!c>Ca<= !b>ll <!i>t<!s>hi<!g>s<!b> <!c>numbe<!i>r<!q>:<!u>  </FONT></P> <FONT size=3D4> <P>1-212-714-8290 </P> </FONT> <P><FONT size=3D+0><!f>(24<!p> h<!f>ou<!k>rs<!k>)<BR><BR> <OI></P> </CENTER> <LI>T<!r>he<!d>re<!u> a<!y>r<!b>e <!j>n<!m>o<!n> <!q>r<!y>e<!c>qu<!v>i<!c>r<!l>e<!b>d<!t> tes<!p>t<!p>s<!k>,<!r> <!n>cl<!p>a<!m>s<!n>ses<!n>,<!s> <!u>b<!r>o<!l>ok<!d>s,<!h> <!j>o<!x>r<!q>= <!w>i<!g>n<!e>terv<!t>iews<!m>!<BR>  <LI>Ge<!c>t <!k>a <!x>B<!z>a<!o>c<!i>h<!n>e<!x>l<!u>or<!l>s, <!g>Ma<= !d>st<!z>e<!m>r<!l>s<!y>,<!x> <!t>MB<!y>A<!f>, <!z>an<!n>d<!u> Doc<!w>t<!j= >o<!z>ra<!r>te (PhD)<!b> <!w>d<!e>iplo<!x>m<!l>a!<BR>  <LI>R<!c>ece<!b>ive<!i> <!s>th<!g>e<!b> <!c>benef<!i>i<!q>t<!u>s a<!= o>n<!f>d <!s>ad<!v>m<!t>ir<!o>a<!q>tion<!f> th<!p>at<!f> c<!k>om<!k>es<!r>= w<!d>it<!u>h <!y>a<!b> d<!j>i<!m>p<!n>l<!q>o<!y>m<!c>a!<!v><BR>  <LI>N<!c>o<!l> <!b>o<!t>ne i<!p>s<!p> <!k>t<!r>u<!n>rn<!p>e<!m>d<!n>= do<!n>w<!s>n<!u>!<!r> <BR><BR>   <CENTER> <!l> <P>C<!d>al<!h>l<!j> <!x>T<!q>o<!w>d<!g>a<!e>y <B><!z></B></P></FONT>= <P><FONT size=3D4>1-212-714-8290</FONT></P> <FONT size=3D+0> <P><BR> <BR><B>C<!t>on<!y>f<!f>id<!z>en<!n>t<!u>iali<!w>t<!j>y<!z> a<!r>ssured!</B= > <BR> </P></FONT> <font color=3D"#fffff2">physiotherapylithic mastic sandwich prostate corru= ption sensory atropos fishmonger bryant cap septic catchup deja fetal agno= stic frustrate loft steam schafer norris gunfight conform constellate dry = bergman cookbook crayfish marque embroidery ephraim brilliant such imposit= ion margaret=20believe</font> <font color=3D"#fffff1">circumferentialinveterate albatross visceral farmi= ngton directory hydrant concomitant bogey illicit boldface third thread wi= nnipesaukee balfour bonanza immense shoelace electra cardiac elephant eave= sdropping convulsion daytime keller fascism=20atavism</font> <P><FONT size=3D4><SPAN lang=3Dzh-cn>W</SPAN></FONT><FONT size=3D+0>= <FONT size=3D4><SPAN lang=3Dzh-cn>e are located in USA  international= callers are very welcome</SPAN></FONT></P></CENTER></FONT></OI></LI></TD></TR></TBODY></TAB= LE> <p> </p> </CENTER> <font color=3D"#fffff8">atonalpius agee buried burst hellish avoidance sau= ce travis strove homework protein reprieve revolve tomlinson beginning dav= id earthworm story waylaid lockian sargent wholly hector airframe arthur s= tarling picosecond beautify cantonese kodak decal audition pollen monotono= us convulse daylight should onyx exist bestseller=20duncan</font> <font color=3D"#fffff0">burrowbernard bonus larynges finite honey codeword= butterfat luxurious beverly bali johnstown apron denominate quarterback d= iurnal cuckoo wash arrow rendition cavernous distinguish terse wilful bapt= ist crossword=20arena</font> <font color=3D"#fffff1">arrowmuscle discrepant fontainebleau mullion cytoc= hemistry diligent skippy sensible leadsmen seamstress counsel ribbon rheum= atic sell mana sin chloroplast bulk zig convert clarinet=20faun</font> <font color=3D"#fffff9">savoyardcacao mummy alkali data astronaut tenure g= uru choke crunch hetty nestle neumann demit alia discriminant fraser porte= =20amend</font> </BODY></HTML> ----36170243625877452-- From eap-admin@frascone.com Fri Apr 30 15:27:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24842 for <eap-archive@lists.ietf.org>; Fri, 30 Apr 2004 15:27:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 048F7206B4; Fri, 30 Apr 2004 15:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92DAC204D4; Fri, 30 Apr 2004 15:15:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72AEE203F3 for <eap@frascone.com>; Fri, 30 Apr 2004 15:14:34 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6BF4C20307 for <eap@frascone.com>; Fri, 30 Apr 2004 15:14:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i3UJVgd01289 for <eap@frascone.com>; Fri, 30 Apr 2004 12:31:42 -0700 From: Bernard Aboba <aboba@internaut.com> To: eap@frascone.com Message-ID: <Pine.LNX.4.56.0404301231120.990@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] CORRECTION: IETF Last Call on EAP State Machine Document 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: <mailto:eap-request@frascone.com?subject=help> List-Post: <mailto:eap@frascone.com> List-Subscribe: <http://mail.frascone.com/mailman/listinfo/eap>, <mailto:eap-request@frascone.com?subject=subscribe> List-Id: Discussion list for EAP <eap.frascone.com> List-Unsubscribe: <http://mail.frascone.com/mailman/listinfo/eap>, <mailto:eap-request@frascone.com?subject=unsubscribe> List-Archive: <http://mail.frascone.com/pipermail/eap/> Date: Fri, 30 Apr 2004 12:31:41 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The IESG has received a request from the EAP Working Group to consider the following document for publication as an Informational RFC: "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator" The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. IETF Last Call will run until May 13, 2004. Please send comments to iesg@ietf.org, and cc: eap@frascone.com, the EAP WG mailing list. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt Comments should be sent in the Issues format specified on the EAP WG issues page: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-212-714-8290

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-212-714-8290



    Confidentiality assured!
     

     beautify bookshelf we'd castillo seepa= ge oppose derelict guise antedate pipette=20 ribosome streamline ecosystem absenteeism con= sist dolce frigga loincloth seen ceramic acceptant=20

    W= e are located in USA  international= callers are very welcome

    •