From skitrip-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 08:35:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERUH-0004Ls-Lz for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 08:35:29 -0500 Received: from leela.tigertech.net ([64.71.157.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERUG-0005qT-Dn for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 08:35:29 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1A515430234 for ; Wed, 1 Mar 2006 05:35:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: skitrip-owner@frascone.com X-No-Archive: yes Message-ID: Date: Wed, 01 Mar 2006 05:31:43 -0800 Precedence: bulk X-BeenThere: skitrip@frascone.com X-Mailman-Version: 2.1.5 List-Id: skitrip.frascone.com X-List-Administrivia: yes To: eap-archive@lists.ietf.org Errors-To: skitrip-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, skitrip-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com bibeos http://lists.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 17:17:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZd2-0003DB-GI for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:17:04 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEYkp-0005LZ-4l for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 16:21:03 -0500 Received: from he83-x.tigertech.net ([64.62.142.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEYXF-0007Hp-Ku for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 16:07:07 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 63D79430101 for ; Wed, 1 Mar 2006 12:52:37 -0800 (PST) Received: from zoidberg-mail.tigertech.net (zoidberg-mail.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2FCE843005F for ; Wed, 1 Mar 2006 12:52:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 14C6739801C for ; Wed, 1 Mar 2006 12:52:22 -0800 (PST) Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by zoidberg.tigertech.net (Postfix) with ESMTP id ED5E039800B for ; Wed, 1 Mar 2006 12:52:14 -0800 (PST) Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k21LLGXc015870 for ; Wed, 1 Mar 2006 14:21:16 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k21L2SkO018382 for ; Wed, 1 Mar 2006 15:02:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Authenticator versus AAA client Date: Wed, 1 Mar 2006 15:52:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Authenticator versus AAA client thread-index: AcX/6yjIOXaV2GDVQ/m4L1Pbq9AZig9gBhOg From: "Nakhjiri Madjid-MNAKHJI1" To: "Jari Arkko" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Nakhjiri Madjid-MNAKHJI1 , eap@frascone.com, Mohan.Parthasarathy@nokia.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi Jari, Finally, I got around to look at this response more closely ;)=20 I look at figure 4 in the draft and I like to use the figure for separation of authenticator and AAA client. The way I see it. The keys (those that can be transported) come down from EAP server to AAA server, from AAA server over to AAA client (over AAA protocol) and then up to Authenticator (EAP Auth layer).=20 peer EAP pass-thru Auth EAP server PMK<---- ^ | | | | MSK SAP | MSK V=20 <------> L2 AAA client<------------ AAA server I am guessing keys flow upward from AAA layer to authenticator layer (AAA client to pass through authenticator), because, the pass-through authenticator needs to create master keys for SAP between the itself and the peer?? =09 The current text requires "In order to prevent the compromise of transported EAP keying material and parameters, the AAA client and EAP authenticator MUST be co-resident."=09 I am trying to figure out why this text limits the usage to collocated AAA client and EAP authenticator. Sure there may be some identifier issues between AAA client ID and authenticator ID (I am wondering if they have to be resolved by requiring co-residency), but what if I want the keys to be sent to another AAA client (a key holder) that is not acting as EAP authenticator.=20 People have brought up 802.11r in previous discussion and mentioned that the key holder there is an authenticator. I personally think that was a result of the very same requirement. Again, why is there a restriction that it has to be an EAP pass-through authenticator that gets the master keys (MSK/AMSK). Also, is there a restriction that EAP pass-through must hold master keys (such PMK) for SAP and generates TSKs? Thanks, and sorry for bringing this up again. Madjid -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Tuesday, December 13, 2005 7:43 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: eap@frascone.com; Mohan.Parthasarathy@nokia.com Subject: Re: [eap] Authenticator versus AAA client Nakhjiri Madjid-MNAKHJI1 wrote: >=20 >Hi folks, > >We are struggling to understand the true definition of EAP pass-through >authenticator and how it differs from a AAA client. So here are some=20 >functions that we have in mind, we are trying to understand what=20 >function fits where: > > >AAA client functionality: >Run AAA protocol with AAA server. >Receive authorization info from AAA server > >EAP pass-through Authenticator >Understand EAP success/ failure, but not EAP request/ responses. > > >Things we need but not sure where to fit? Authenticator or AAA client? >Converting EAP/link layer to EAP/AAA?=20 >Receiving master keys from AAA server? Yes, EAP keying defines this as=20 >authenticator, but it would seem that this is AAA client, since keys=20 >are sent over AAA protocol. > =20 > This is what the EAP keying framework says: ... On EAP server, keying material requested by and passed down to the AAA layer may be replicated to the AAA layer on the authenticator. On the authenticator, the AAA layer may provide the replicated keying material to the lower layer over which the EAP authentication conversation took place. This enables "mode independence" to be maintained. As illustrated in Figure 4, a AAA client receiving transported EAP keying material and parameters passes them to the EAP authenticator and EAP layers, which then provide them to the authenticator lower layer using the same mechanisms that would be used if the EAP peer and authenticator were conducting a stand-alone conversation. The resulting key state in the lower layer is indistinguishable between the standalone and pass-through cases, as required by the principle of mode independence. In order to prevent the compromise of transported EAP keying material and parameters, the AAA client and EAP authenticator MUST be co-resident. Hope this helps -- let us know if you want some specific clarification to the text. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 17:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZr0-0004WV-V7 for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:31:30 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZqz-0001s9-Hi for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:31:30 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B605143013F for ; Wed, 1 Mar 2006 14:31:28 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5F12C430077 for ; Wed, 1 Mar 2006 14:31:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4CACC398015 for ; Wed, 1 Mar 2006 14:31:03 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D780398008 for ; Wed, 1 Mar 2006 14:30:54 -0800 (PST) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k21MoFM2006154 for ; Wed, 1 Mar 2006 15:50:19 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k21Mf15I022522 for ; Wed, 1 Mar 2006 16:41:01 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK-->AMSK Date: Wed, 1 Mar 2006 17:30:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK-->AMSK thread-index: AcYmiBUZ3sXa+p9FR+SnkrcZmTb7VQW93kZg From: "Nakhjiri Madjid-MNAKHJI1" To: "Bernard Aboba" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 So can I take this as to mean EMSK-->AMSK generation can be done at AAA layer in EAP/AAA server (backend server)? -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, January 31, 2006 11:02 AM To: rafa@dif.um.es Cc: eap@frascone.com Subject: Re: [eap] Strawman -10 >>The text forbidding the export was removed in Issue 320 with the=20 >>following proposed change, so it would appear to me that the export is now allowed. > >I see. But I was wondering for example in the case of standalone=20 >authenticator : will only MSK be available to lower layer as usual or=20 >both >(MSK,EMSK) now? Note that the language relating to transport of the EMSK has not been touched so that restriction remains. In the passthrough case, the authenticator lower layer will not receive the EMSK, whereas it will receive it in the standalone case. Since the peer does not know which case is being run, this implies that the lower layer cannot derive the TSKs directly from the EMSK, but only from a quantity that is always available within the authenticator lower layer. As long as the keys that the lower layer depends on are always available on the authenticator, this doesn't violate mode independence from the peer's point of view. I'm not sure it necessarily violates it on the authenticator either, as long as the EMSK is destroyed after computation of the AMSK. If that is done, the end cryptographic state on the authenticator is the same in either the pass-through or standalone case. One advantage of this approach is that it keeps implementation of cryptography out of the EAP layer. Allowing cryptographic operations in the EAP layer is a problem because EAP does not support cryptographic negotiation, so that negotiation of cryptographic algorithms such as PRFs would require changes to existing EAP methods. By doing those calculations in the lower layer, instead, the Secure Association Protocol can negotiate the cryptographic algorithms and this problem is avoided. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 17:38:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZxr-0000tB-2Q for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:38:35 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZxp-0002Lj-MH for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:38:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 564D64300C2 for ; Wed, 1 Mar 2006 14:38:33 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0A949430077 for ; Wed, 1 Mar 2006 14:38:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E5E9780C0F5 for ; Wed, 1 Mar 2006 14:38:18 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id DB34580C006 for ; Wed, 1 Mar 2006 14:38:16 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k21MrYVD026613 for ; Wed, 1 Mar 2006 15:53:34 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k21MoPap020239 for ; Wed, 1 Mar 2006 16:50:26 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10 Date: Wed, 1 Mar 2006 17:38:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10 thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQ From: "Nakhjiri Madjid-MNAKHJI1" To: "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Madjid>>Again, why is deletion of EMSK after generation of one AMSK is a requirements. What if we need to create multiple AMSKs and that at multiple occassions? Well, actually, lower layer authenticator implementation should expect=20 (MSK,EMSK) in the case EAP method is executed by the standalone=20 authenticator or (MSK,AMSK) in the case EAP method is executed by=20 backend authentication server. If it receives (MSK,EMSK) should create=20 AMSK and delete EMSK. If it receives (MSK,AMSK) , that's all, correct? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 17:44:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEa3D-0002fm-Cs for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:44:07 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEa3C-0002eY-W1 for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:44:07 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6CAAC4300F4 for ; Wed, 1 Mar 2006 14:44:06 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A7BF743005F for ; Wed, 1 Mar 2006 14:43:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9036F398020 for ; Wed, 1 Mar 2006 14:43:53 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id B4D25398009 for ; Wed, 1 Mar 2006 14:43:50 -0800 (PST) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k21Mx8oq027584 for ; Wed, 1 Mar 2006 15:59:08 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k21Mud3X009460 for ; Wed, 1 Mar 2006 16:56:39 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10 Date: Wed, 1 Mar 2006 17:43:46 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10 thread-index: AcYmr2q6H5C2xcvrR8Ow6Ifa4NQB1AAAA5dABbRnKwA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > The difference is subtle, but potentially important for issues such as=20 > crypto-agility. Allowing the lower layer to obtain the EMSK enables=20 > the lower layer to negotiate the PRFs used in AMSK generation, whereas > this is not possible if AMSK generation is handled in the EAP layer. =20 > It also maintains backward compatibility so that a lower layer using=20 > the AMSK can be introduced without requiring changes to existing EAP=20 > implementations. >=20 > As long as the EAP peer does not need to be aware of whether the=20 > authenticator is configured in standalone or pass-through mode, I=20 > think that the requirements of mode independence have been met. [Joe] This worries me. It ties the key derivation to the lower layer, which could be problematic. A goal of the EMSK to AMSK derivation is to contain the problem of a misbehaving lower layer to the lower layer itself. A lower layer that determines the key derivation algorithm conflicts with this goal. What happens if there are multiple AMSKs being derived for different purposes? Who decides the KDF? =20 I think I would prefer to see a default KDF specified with the capability of an EAP method to override it with a KDF of its own. =20 Madjid>> Are you saying all EMSK-AMSK generations will have to follow the same KDF defined based on EAP method? And ruling out use of different KDFs for different AMSKs? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 17:50:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEa9c-0002cd-VG for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:50:44 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEa9b-0002nm-Iv for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 17:50:44 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 36D36430110 for ; Wed, 1 Mar 2006 14:50:43 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BD810430077 for ; Wed, 1 Mar 2006 14:50:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B23C980C0FA for ; Wed, 1 Mar 2006 14:50:26 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id E964B80C008 for ; Wed, 1 Mar 2006 14:50:25 -0800 (PST) Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k21N5huh028715 for ; Wed, 1 Mar 2006 16:05:43 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k21N9gmq023522 for ; Wed, 1 Mar 2006 17:09:43 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK management entity!! Date: Wed, 1 Mar 2006 17:49:53 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK management entity!! thread-index: AcYmsK5W+AvKGwZkT6Sls7H3GsZn/gAHW8mABa0EpyA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Rafa Marin Lopez" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 EMSK management component that holds EMSKs, has the KDFs to create various AMSKs from the EMSK at various times and can accept channel binding parameters to bind the keys for usage, sounds like a KDC next to the AAA server... -----Original Message----- From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, January 31, 2006 7:31 PM To: Rafa Marin Lopez Cc: eap@frascone.com Subject: RE: [eap] Strawman -10 =20 > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > Sent: Tuesday, January 31, 2006 1:47 PM > To: Salowey, Joe > Cc: Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Strawman -10 >=20 > Then my question is what layer is going to derive keys (i.e.=20 > AMSK) from=20 > EMSK? EAP layer?. >=20 [Joe] I would say the EAP layer (if there is such a thing). If you don't like the EAP layer then it would be something like an EMSK management layer or component. Not the lower layer.=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 18:08:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEaR7-0003Mu-Br for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 18:08:49 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEaR5-0003Mc-UR for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 18:08:49 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5BDFA4301BD for ; Wed, 1 Mar 2006 15:08:47 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E6680430077 for ; Wed, 1 Mar 2006 15:08:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C649039800B for ; Wed, 1 Mar 2006 15:08:33 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id D00C8398007 for ; Wed, 1 Mar 2006 15:08:31 -0800 (PST) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k21NNjBY001630 for ; Wed, 1 Mar 2006 16:23:49 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k21NLGJJ019340 for ; Wed, 1 Mar 2006 17:21:16 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Wed, 1 Mar 2006 18:08:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK thread-index: AcY7uUBgfkadmoWgTRSzM9u8P/kEVwAEn3sQAG3gQVA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Rafa Marin Lopez" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 >From previous discussion, I personally made the conclusion that the EAP server/ AAA server/ backend server are collocated. And as a consumer of EAP keying, I came to think that AAA layer at the backend is implemented by AAA servers, while EAP method/EAP auth layers are implemented by EAP server. I don't really have a reason to worry about what AAA layer is, except trying to understand EAP keying documentations and figure out where I get my keys (AMSK at this point) from and so far I have not understood it. So if we say EMSK-AMSK generation at AAA layer would require changes to AAA servers, I can accept that, but=20 Are we now saying that AAA layer does not correspond to functionality at AAA servers and AAA clients??? I am lost! Who implements AAA layer? Madjid=20 > > > Clarified this point. In your answer you specify "only" lower layer.=20 > Did you forget to include AAA layer ? Or do you think AAA layer might=20 > receive EMSK?. >=20 [Joe] this would depend on where you draw your AAA and EAP server boundaries. They are two separate entities and do not even need to be collocated, but it is fairly common for the EAP server and AAA server to be collocated or for the EAP server to be part of the AAA server. How the EAP server and AAA server divide up their responsibilities depends upon local implementation so I would say that the AAA server may know the EMSK as far as it may contain the EAP server. Now I am not sure what the AAA layer is, but it may not be the same as a AAA server so I can't really answer your question. It would seem that the AAA layer would include the AAA client and AAA server communication. The EMSK does not pass through this communication so under this definition it would not go to the AAA layer. =20 > "what layer (EAP method layer, EAP peer/authenticator layer, EAP=20 > layer, lower layer/AAA layer) is intended to get EMSK to create new=20 > possible keys (AMSK)?" >=20 > (From your previous answer, it is clear we can discard lower layer as=20 > a possible answer) >=20 [Joe] I'm not convinced that I understand the layers or that the layer model is the right thing to apply here, but given the choices my answer is the EAP method layer.=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 18:10:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEaSN-0006W3-D9 for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 18:10:07 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEaSL-0003ON-W4 for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 18:10:07 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9EF9B430077 for ; Wed, 1 Mar 2006 15:10:05 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BE149430077 for ; Wed, 1 Mar 2006 15:09:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AEFA2398009 for ; Wed, 1 Mar 2006 15:09:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2D79398007 for ; Wed, 1 Mar 2006 15:09:44 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 01 Mar 2006 15:09:44 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k21N9iGv013835; Wed, 1 Mar 2006 15:09:44 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10 Date: Wed, 1 Mar 2006 15:16:34 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906A9B5CE@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10 Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrA= From: "Salowey, Joe" To: "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 =20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 > Sent: Wednesday, March 01, 2006 2:38 PM > To: Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10 >=20 > Madjid>>Again, why is deletion of EMSK after generation of=20 > one AMSK is a > requirements. What if we need to create multiple AMSKs and that at > multiple occassions? >=20 >=20 >=20 > Well, actually, lower layer authenticator implementation=20 > should expect=20 > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > backend authentication server. If it receives (MSK,EMSK)=20 > should create=20 > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's all, correct? [Joe] Not really, strictly speaking the lower layer shouldn't expect to receive the EMSK as that would break mode independence. An architectural description should not have the lower layer receiving the keys. From a supplicant perspective it must appear the same whether an external EAP-Server or a collocated EAP server is used. Now I don't know what is going on inside your box, it could all be monolithic when a internal EAP server is used but that shouldn't be visible to the external world. If I was interested in cryptographic module separation I might not be too happy if you shared the EMSK with the lower layer.=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 01 19:00:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEbFB-0002Xe-3n for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 19:00:33 -0500 Received: from g1-33.tigertech.net ([64.62.209.33] helo=leela-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEbF9-0006nX-MG for eap-archive@lists.ietf.org; Wed, 01 Mar 2006 19:00:33 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 335DD43028C for ; Wed, 1 Mar 2006 16:00:31 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 460A44300D8 for ; Wed, 1 Mar 2006 16:00:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 360CC398015 for ; Wed, 1 Mar 2006 16:00:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A257398026 for ; Wed, 1 Mar 2006 16:00:05 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2006 16:00:05 -0800 X-IronPort-AV: i="4.02,158,1139212800"; d="scan'208"; a="411514886:sNHT44009266" 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 k220037T026272; Wed, 1 Mar 2006 16:00:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10 Date: Wed, 1 Mar 2006 16:06:52 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906A9B612@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10 Thread-Index: AcYmr2q6H5C2xcvrR8Ow6Ifa4NQB1AAAA5dABbRnKwAAAQlBMA== From: "Salowey, Joe" To: "Nakhjiri Madjid-MNAKHJI1" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 =20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 > Sent: Wednesday, March 01, 2006 2:44 PM > To: Salowey, Joe; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10 >=20 > > The difference is subtle, but potentially important for issues such > as=20 > > crypto-agility. Allowing the lower layer to obtain the=20 > EMSK enables=20 > > the lower layer to negotiate the PRFs used in AMSK=20 > generation, whereas >=20 > > this is not possible if AMSK generation is handled in the=20 > EAP layer. =20 > > It also maintains backward compatibility so that a lower=20 > layer using=20 > > the AMSK can be introduced without requiring changes to=20 > existing EAP=20 > > implementations. > >=20 > > As long as the EAP peer does not need to be aware of whether the=20 > > authenticator is configured in standalone or pass-through mode, I=20 > > think that the requirements of mode independence have been met. >=20 > [Joe] This worries me. It ties the key derivation to the lower layer, > which could be problematic. A goal of the EMSK to AMSK=20 > derivation is to > contain the problem of a misbehaving lower layer to the lower layer > itself. A lower layer that determines the key derivation algorithm > conflicts with this goal. What happens if there are multiple AMSKs > being derived for different purposes? Who decides the KDF? =20 >=20 >=20 > I think I would prefer to see a default KDF specified with the > capability of an EAP method to override it with a KDF of its own. =20 >=20 > Madjid>> Are you saying all EMSK-AMSK generations will have to follow > the same KDF defined based on EAP method? And ruling out use of > different KDFs for different AMSKs? >=20 [Joe] Yes. A single coordinated KDF definition is a robust and deterministic way to avoid one key derivation scheme compromising other keys derived from another scheme. >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 02 11:44:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqum-0001hD-GE for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 11:44:32 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqul-0006Hd-03 for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 11:44:32 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2B31B4300BC for ; Thu, 2 Mar 2006 08:44:30 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E1B644300AE for ; Thu, 2 Mar 2006 08:44:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C8C3980C1B2 for ; Thu, 2 Mar 2006 08:44:12 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id C591C80C185 for ; Thu, 2 Mar 2006 08:43:49 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k22Gx4pf016642 for ; Thu, 2 Mar 2006 09:59:08 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k22GttHq008959 for ; Thu, 2 Mar 2006 10:55:56 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 2 Mar 2006 11:43:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi Joe, Thanks for the email. I think you responded to the old piece of the email from Rafa and I am to blame for causing that confusion, as I kept that part to provide context. Again, my question was why an entity needs to delete EMSK after generating the first AMSK (or first set of AMSKs?)? This seems to be the requirement regardless of two options: 1) keep EMSK at EAP layer, create AMSK at EAP layer based request from AAA layer, delete EMSK Immediately (this means EAP layer must have KDFs for AMSK=3DKDF(EMSK, = etc) 2) push EMSK down to AAA layer at backend server, create AMSK at AAA layer and delete EMSK immediately (this means AAA layer must have KDFs) In both cases we require deletion of EMSK after generation of AMSK, why? Thanks, Madjid -----Original Message----- From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, March 01, 2006 5:17 PM To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10 =20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, March 01, 2006 2:38 PM > To: Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10 >=20 > Madjid>>Again, why is deletion of EMSK after generation of > one AMSK is a > requirements. What if we need to create multiple AMSKs and that at=20 > multiple occassions? >=20 >=20 >=20 > Well, actually, lower layer authenticator implementation should expect > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > backend authentication server. If it receives (MSK,EMSK) should create > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's all, correct? [Joe] Not really, strictly speaking the lower layer shouldn't expect to receive the EMSK as that would break mode independence. An architectural description should not have the lower layer receiving the keys. From a supplicant perspective it must appear the same whether an external EAP-Server or a collocated EAP server is used. Now I don't know what is going on inside your box, it could all be monolithic when a internal EAP server is used but that shouldn't be visible to the external world. If I was interested in cryptographic module separation I might not be too happy if you shared the EMSK with the lower layer.=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 02 14:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEthT-0006iS-K7 for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 14:42:59 -0500 Received: from g1-203.tigertech.net ([64.62.209.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEthS-0004jH-57 for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 14:42:59 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 568274301F8 for ; Thu, 2 Mar 2006 11:42:57 -0800 (PST) Received: from mx2.tigertech.net (g1-201.tigertech.net [64.62.209.201]) by leela.tigertech.net (Postfix) with ESMTP id 68E404300FB for ; Thu, 2 Mar 2006 11:42:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5694980C16B for ; Thu, 2 Mar 2006 11:42:40 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 71EFD80C16A for ; Thu, 2 Mar 2006 11:42:38 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2006 11:42:38 -0800 X-IronPort-AV: i="4.02,160,1139212800"; d="scan'208"; a="411891001:sNHT36726140" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k22JgbGv008259; Thu, 2 Mar 2006 11:42:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 2 Mar 2006 11:49:27 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32AAE@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRw From: "Salowey, Joe" To: "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 =20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 > Sent: Thursday, March 02, 2006 8:44 AM > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Joe, >=20 > Thanks for the email. I think you responded to the old piece of the > email from Rafa and I am to blame for causing that confusion,=20 > as I kept > that part to provide context. > Again, my question was why an entity needs to delete EMSK after > generating the first AMSK (or first set of AMSKs?)? This=20 > seems to be the > requirement regardless of two options: >=20 > 1) keep EMSK at EAP layer, create AMSK at EAP layer based request from > AAA layer, delete EMSK > Immediately (this means EAP layer must have KDFs for=20 > AMSK=3DKDF(EMSK, etc) > 2) push EMSK down to AAA layer at backend server, create AMSK at AAA > layer and delete EMSK immediately (this means AAA layer must=20 > have KDFs) > [Joe] If the AAA layer contains the AAA client and AAA server then the EMSK should not be available to this layer, if the AAA layer means something else then I don't know about (1). The AMSK should be generated in the EAP and exported, option (2). =20 >=20 > In both cases we require deletion of EMSK after generation of=20 > AMSK, why? >=20 [Joe] To minimize the chance of exposure of the EMSK. Why do you need to cache it? Could you generate and cache an AMSK instead? =20 > Thanks, >=20 > Madjid >=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Wednesday, March 01, 2006 5:17 PM > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10 >=20 > =20 >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Wednesday, March 01, 2006 2:38 PM > > To: Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10 > >=20 > > Madjid>>Again, why is deletion of EMSK after generation of > > one AMSK is a > > requirements. What if we need to create multiple AMSKs and that at=20 > > multiple occassions? > >=20 > >=20 > >=20 > > Well, actually, lower layer authenticator implementation=20 > should expect > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > > backend authentication server. If it receives (MSK,EMSK)=20 > should create >=20 > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's=20 > all, correct? >=20 > [Joe] Not really, strictly speaking the lower layer shouldn't=20 > expect to > receive the EMSK as that would break mode independence. An > architectural description should not have the lower layer=20 > receiving the > keys. From a supplicant perspective it must appear the same whether an > external EAP-Server or a collocated EAP server is used. Now I don't > know what is going on inside your box, it could all be=20 > monolithic when a > internal EAP server is used but that shouldn't be visible to the > external world. If I was interested in cryptographic module=20 > separation > I might not be too happy if you shared the EMSK with the lower layer.=20 >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 02 15:14:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuBf-0005Z3-6h for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 15:14:11 -0500 Received: from g1-203.tigertech.net ([64.62.209.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuBd-0005lM-NQ for eap-archive@lists.ietf.org; Thu, 02 Mar 2006 15:14:11 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EAE8C4301B8 for ; Thu, 2 Mar 2006 12:14:08 -0800 (PST) Received: from mx2.tigertech.net (g1-201.tigertech.net [64.62.209.201]) by leela.tigertech.net (Postfix) with ESMTP id CEC58430110 for ; Thu, 2 Mar 2006 12:13:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C484A80C162 for ; Thu, 2 Mar 2006 12:13:51 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id 6CC8180C15F for ; Thu, 2 Mar 2006 12:13:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 2 Mar 2006 15:16:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbA= From: "Avi Lior" To: "Salowey, Joe" , "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Hi Joe and Madjid, The only reason for caching the EMSK is if you have to generate an AMSK for another application associated with the current session. So the question is do you have to generate all possible AMSKs and then delete the EMSK or can you generate the AMSKs as needed? Finally I have an slight issue with the statement that a KEY should be deleted so that it wont be used for other purposes. I find that statements like that are an over specification. What makes anyone think that making a statement that "X should/must be deleted" is going to be taken more seriously then "X should/must only be used for purpose X and should/must not be transported out of Y"? I think that whether it gets deleted or not is an implementation issue. Finally if we insist on saying that X must be deleted we should really say that X must be securely deleted. There is a difference. When a key is securely deleted the software takes extra care that the memory location containing the key is first erased before the memory location is freed to the heap. Perhaps we can state that somewhere.=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, March 02, 2006 2:49 PM > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Thursday, March 02, 2006 8:44 AM > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Hi Joe, > >=20 > > Thanks for the email. I think you responded to the old piece of the=20 > > email from Rafa and I am to blame for causing that confusion, as I=20 > > kept that part to provide context. > > Again, my question was why an entity needs to delete EMSK after=20 > > generating the first AMSK (or first set of AMSKs?)? This=20 > seems to be=20 > > the requirement regardless of two options: > >=20 > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based=20 > request from=20 > > AAA layer, delete EMSK Immediately (this means EAP layer must have=20 > > KDFs for AMSK=3DKDF(EMSK, etc) > > 2) push EMSK down to AAA layer at backend server, create=20 > AMSK at AAA=20 > > layer and delete EMSK immediately (this means AAA layer must have=20 > > KDFs) > > > [Joe] If the AAA layer contains the AAA client and AAA server=20 > then the EMSK should not be available to this layer, if the=20 > AAA layer means something else then I don't know about (1). =20 > The AMSK should be generated in the EAP and exported, option (2). > =20 > >=20 > > In both cases we require deletion of EMSK after generation of AMSK,=20 > > why? > >=20 > [Joe] To minimize the chance of exposure of the EMSK. Why do=20 > you need to cache it? Could you generate and cache an AMSK instead? =20 >=20 >=20 > > Thanks, > >=20 > > Madjid > >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Wednesday, March 01, 2006 5:17 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1=20 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > To: Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > Madjid>>Again, why is deletion of EMSK after generation of > > > one AMSK is a > > > requirements. What if we need to create multiple AMSKs=20 > and that at=20 > > > multiple occassions? > > >=20 > > >=20 > > >=20 > > > Well, actually, lower layer authenticator implementation > > should expect > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > > > backend authentication server. If it receives (MSK,EMSK) > > should create > >=20 > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > all, correct? > >=20 > > [Joe] Not really, strictly speaking the lower layer=20 > shouldn't expect=20 > > to receive the EMSK as that would break mode independence. An=20 > > architectural description should not have the lower layer receiving=20 > > the keys. From a supplicant perspective it must appear the same=20 > > whether an external EAP-Server or a collocated EAP server is used. =20 > > Now I don't know what is going on inside your box, it could all be=20 > > monolithic when a internal EAP server is used but that shouldn't be=20 > > visible to the external world. If I was interested in=20 > cryptographic=20 > > module separation I might not be too happy if you shared=20 > the EMSK with=20 > > the lower layer. > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 03 16:44:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFI4U-000609-Jp for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 16:44:22 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFI4T-00060x-5x for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 16:44:22 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A0DAF430166 for ; Fri, 3 Mar 2006 13:44:20 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BD27D43005F for ; Fri, 3 Mar 2006 13:44:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A93A780C0FF for ; Fri, 3 Mar 2006 13:44:00 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by hermes.tigertech.net (Postfix) with ESMTP id 362EF80C0F5 for ; Fri, 3 Mar 2006 13:43:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 9C5C81FAB18; Fri, 3 Mar 2006 22:43:54 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04449-01-43; Fri, 3 Mar 2006 22:43:54 +0100 (CET) Received: from [207.3.232.120] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 505571FAAE3; Fri, 3 Mar 2006 22:43:51 +0100 (CET) Message-ID: <4408B89C.4050001@dif.um.es> Date: Fri, 03 Mar 2006 16:43:56 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [eap] About use of EMSK References: <7210B31550AC934A8637D6619739CE6906A9AF47@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906A9AF47@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hi Joe... I would like to do some comments to your e-mail. Please see inline... > >[Joe] this would depend on where you draw your AAA and EAP server >boundaries. They are two separate entities and do not even need to be >collocated, but it is fairly common for the EAP server and AAA server to >be collocated or for the EAP server to be part of the AAA server. How >the EAP server and AAA server divide up their responsibilities depends >upon local implementation so I would say that the AAA server may know >the EMSK as far as it may contain the EAP server. Now I am not sure what >the AAA layer is, but it may not be the same as a AAA server so I can't >really answer your question. It would seem that the AAA layer would >include the AAA client and AAA server communication. > My understanding is that figure 3 is referring to AAA server. But in any case, i re-formulate the question: if EAP server and AAA server are co-located ... could EMSK be exported to AAA server? (From your answer "the AAA server may know the EMSK as far as it may contain the EAP server" I would say yes . >[Joe] I'm not convinced that I understand the layers or that the layer >model is the right thing to apply here, > Ok, I see. In EAP key mng fwk is described this layering . Additionally , let me give some notes about EAP state machine (though it is informational). For example (RFC 4137): 6.1.2. Variables (Backend Authenticator to AAA Interface) ..... aaaEapKeyData (EAP key) Set in authenticator state machine when keying material becomes available. Set during the METHOD_RESPONSE state. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying]. If we check the EAP state machine that method (aaaEapKeyData (EAP key) ) is provided by EAP backend authenticator state machine (Figure 5 in rfc 4137). That state machine recovers the "EAP key" from the EAP method through m.getKey() m.getKey() Method procedure to obtain key material for use by EAP or lower layers. Returns an EAP key. Thus, the layer model remains.... Having said this, and after your comment My question is : is it expected another interface (different than "aaaEapKeyData (EAP key)") to provide keys to AAA server? or could AAA server use for example something like m.getKey() to obtain a particular key from EAP method?. >but given the choices my answer >is the EAP method layer. > > In that case, why would EAP method need to export EMSK?. Thanks. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 03 18:17:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJWw-0004uz-6a for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 18:17:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJWu-0002E5-L4 for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 18:17:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9D7804301A8 for ; Fri, 3 Mar 2006 15:17:47 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A04FB4300E3 for ; Fri, 3 Mar 2006 15:17:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 94E64398017 for ; Fri, 3 Mar 2006 15:17:28 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3DC3E39801E for ; Fri, 3 Mar 2006 15:17:24 -0800 (PST) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k23NWcBB020538 for ; Fri, 3 Mar 2006 16:32:42 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k23NWW1t008207 for ; Fri, 3 Mar 2006 17:32:32 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 3 Mar 2006 18:17:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwADnYKGA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b =20 >=20 > Thanks for the email. I think you responded to the old piece of the=20 > email from Rafa and I am to blame for causing that confusion, as I=20 > kept that part to provide context. > Again, my question was why an entity needs to delete EMSK after=20 > generating the first AMSK (or first set of AMSKs?)? This seems to be=20 > the requirement regardless of two options: >=20 > 1) keep EMSK at EAP layer, create AMSK at EAP layer based request from > AAA layer, delete EMSK Immediately (this means EAP layer must have=20 > KDFs for AMSK=3DKDF(EMSK, etc) > 2) push EMSK down to AAA layer at backend server, create AMSK at AAA=20 > layer and delete EMSK immediately (this means AAA layer must have=20 > KDFs) > [Joe] If the AAA layer contains the AAA client and AAA server then the EMSK should not be available to this layer, if the AAA layer means something else then I don't know about (1). The AMSK should be generated in the EAP and exported, option (2). =20 Madjid>>I guess the number of people who are not sure about definition of AAA layer is more than one :) Joking aside, what is your reason what not making EMSK available to lower layer, while doing so for MSK is ok? What is the fundamental difference. >=20 > In both cases we require deletion of EMSK after generation of AMSK,=20 > why? >=20 [Joe] To minimize the chance of exposure of the EMSK. Why do you need to cache it? Could you generate and cache an AMSK instead? =20 Madjid>>because a priori I cannot know how many AMSKs I may need later. An application may pop up later that needs keying or I move to a different domain that may require a new AMSK, but I cannot anticipate the move ahead of time... > Thanks, >=20 > Madjid >=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com] > Sent: Wednesday, March 01, 2006 5:17 PM > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10 >=20 > =20 >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Wednesday, March 01, 2006 2:38 PM > > To: Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10 > >=20 > > Madjid>>Again, why is deletion of EMSK after generation of > > one AMSK is a > > requirements. What if we need to create multiple AMSKs and that at=20 > > multiple occassions? > >=20 > >=20 > >=20 > > Well, actually, lower layer authenticator implementation > should expect > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > > backend authentication server. If it receives (MSK,EMSK) > should create >=20 > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > all, correct? >=20 > [Joe] Not really, strictly speaking the lower layer shouldn't expect=20 > to receive the EMSK as that would break mode independence. An=20 > architectural description should not have the lower layer receiving=20 > the keys. From a supplicant perspective it must appear the same=20 > whether an external EAP-Server or a collocated EAP server is used. =20 > Now I don't know what is going on inside your box, it could all be=20 > monolithic when a internal EAP server is used but that shouldn't be=20 > visible to the external world. If I was interested in cryptographic=20 > module separation I might not be too happy if you shared the EMSK with > the lower layer. >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 03 18:21:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJaV-0006fL-K6 for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 18:21:31 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJaV-0002UW-3Z for eap-archive@lists.ietf.org; Fri, 03 Mar 2006 18:21:31 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A4CF34301A8 for ; Fri, 3 Mar 2006 15:21:30 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 39C364300E3 for ; Fri, 3 Mar 2006 15:21:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 200F9398026 for ; Fri, 3 Mar 2006 15:21:13 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id 091F5398009 for ; Fri, 3 Mar 2006 15:21:10 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k23NaWUF021100 for ; Fri, 3 Mar 2006 16:36:32 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k23NXOtm018411 for ; Fri, 3 Mar 2006 17:33:24 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 3 Mar 2006 18:21:09 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAOOfJsA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Avi Lior" , "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Hi Avi,=20 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Thursday, March 02, 2006 2:16 PM To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Hi Joe and Madjid, The only reason for caching the EMSK is if you have to generate an AMSK for another application associated with the current session. Madjid>> Thank you for clarification. Another example may be roaming to another access technology!! So the question is do you have to generate all possible AMSKs and then delete the EMSK or can you generate the AMSKs as needed? Madjid>>i.e. keep EMSK for future AMSK generation. The first option will create the need for running EAP again. > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com] > Sent: Thursday, March 02, 2006 2:49 PM > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Thursday, March 02, 2006 8:44 AM > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Hi Joe, > >=20 > > Thanks for the email. I think you responded to the old piece of the=20 > > email from Rafa and I am to blame for causing that confusion, as I=20 > > kept that part to provide context. > > Again, my question was why an entity needs to delete EMSK after=20 > > generating the first AMSK (or first set of AMSKs?)? This > seems to be > > the requirement regardless of two options: > >=20 > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > request from > > AAA layer, delete EMSK Immediately (this means EAP layer must have=20 > > KDFs for AMSK=3DKDF(EMSK, etc) > > 2) push EMSK down to AAA layer at backend server, create > AMSK at AAA > > layer and delete EMSK immediately (this means AAA layer must have > > KDFs) > > > [Joe] If the AAA layer contains the AAA client and AAA server then the > EMSK should not be available to this layer, if the AAA layer means=20 > something else then I don't know about (1). > The AMSK should be generated in the EAP and exported, option (2). > =20 > >=20 > > In both cases we require deletion of EMSK after generation of AMSK,=20 > > why? > >=20 > [Joe] To minimize the chance of exposure of the EMSK. Why do you need > to cache it? Could you generate and cache an AMSK instead? >=20 >=20 > > Thanks, > >=20 > > Madjid > >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Wednesday, March 01, 2006 5:17 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > To: Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > Madjid>>Again, why is deletion of EMSK after generation of > > > one AMSK is a > > > requirements. What if we need to create multiple AMSKs > and that at > > > multiple occassions? > > >=20 > > >=20 > > >=20 > > > Well, actually, lower layer authenticator implementation > > should expect > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > > > backend authentication server. If it receives (MSK,EMSK) > > should create > >=20 > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > all, correct? > >=20 > > [Joe] Not really, strictly speaking the lower layer > shouldn't expect > > to receive the EMSK as that would break mode independence. An=20 > > architectural description should not have the lower layer receiving=20 > > the keys. From a supplicant perspective it must appear the same=20 > > whether an external EAP-Server or a collocated EAP server is used. > > Now I don't know what is going on inside your box, it could all be=20 > > monolithic when a internal EAP server is used but that shouldn't be=20 > > visible to the external world. If I was interested in > cryptographic > > module separation I might not be too happy if you shared > the EMSK with > > the lower layer. > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 10:06:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFuoU-0005UQ-Qd for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 10:06:26 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFuoT-00009q-88 for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 10:06:26 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 28F264300EE for ; Sun, 5 Mar 2006 07:06:24 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4CC72430067 for ; Sun, 5 Mar 2006 07:06:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B6D5398032 for ; Sun, 5 Mar 2006 07:06:00 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id EBBE4398026 for ; Sun, 5 Mar 2006 07:05:56 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Sun, 5 Mar 2006 10:08:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAOOfJsABTcvOw From: "Avi Lior" To: "Nakhjiri Madjid-MNAKHJI1" , "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Hi Madjid=20 Seems that there a lot of good reasons for keeping EMSK around after it is used to generate AMSKs. Hopefully everyone gets that. > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 > Sent: Friday, March 03, 2006 6:21 PM > To: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Avi,=20 >=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Thursday, March 02, 2006 2:16 PM > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;=20 > Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Joe and Madjid, >=20 > The only reason for caching the EMSK is if you have to=20 > generate an AMSK for another application associated with the=20 > current session. >=20 > Madjid>> Thank you for clarification. Another example may be=20 > roaming to > another access technology!! >=20 > So the question is do you have to generate all possible AMSKs=20 > and then delete the EMSK or can you generate the AMSKs as needed? >=20 > Madjid>>i.e. keep EMSK for future AMSK generation. The first=20 > option will > create the need for running EAP again. >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Thursday, March 02, 2006 2:49 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1=20 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Thursday, March 02, 2006 8:44 AM > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Hi Joe, > > >=20 > > > Thanks for the email. I think you responded to the old=20 > piece of the=20 > > > email from Rafa and I am to blame for causing that=20 > confusion, as I=20 > > > kept that part to provide context. > > > Again, my question was why an entity needs to delete EMSK after=20 > > > generating the first AMSK (or first set of AMSKs?)? This > > seems to be > > > the requirement regardless of two options: > > >=20 > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > > request from > > > AAA layer, delete EMSK Immediately (this means EAP layer=20 > must have=20 > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > 2) push EMSK down to AAA layer at backend server, create > > AMSK at AAA > > > layer and delete EMSK immediately (this means AAA layer must have > > > KDFs) > > > > > [Joe] If the AAA layer contains the AAA client and AAA=20 > server then the >=20 > > EMSK should not be available to this layer, if the AAA layer means=20 > > something else then I don't know about (1). > > The AMSK should be generated in the EAP and exported, option (2). > > =20 > > >=20 > > > In both cases we require deletion of EMSK after=20 > generation of AMSK,=20 > > > why? > > >=20 > > [Joe] To minimize the chance of exposure of the EMSK. Why=20 > do you need >=20 > > to cache it? Could you generate and cache an AMSK instead? > >=20 > >=20 > > > Thanks, > > >=20 > > > Madjid > > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10 > > > >=20 > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > one AMSK is a > > > > requirements. What if we need to create multiple AMSKs > > and that at > > > > multiple occassions? > > > >=20 > > > >=20 > > > >=20 > > > > Well, actually, lower layer authenticator implementation > > > should expect > > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > > authenticator or (MSK,AMSK) in the case EAP method is=20 > executed by=20 > > > > backend authentication server. If it receives (MSK,EMSK) > > > should create > > >=20 > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > all, correct? > > >=20 > > > [Joe] Not really, strictly speaking the lower layer > > shouldn't expect > > > to receive the EMSK as that would break mode independence. An=20 > > > architectural description should not have the lower layer=20 > receiving=20 > > > the keys. From a supplicant perspective it must appear the same=20 > > > whether an external EAP-Server or a collocated EAP server is used. > > > Now I don't know what is going on inside your box, it=20 > could all be=20 > > > monolithic when a internal EAP server is used but that=20 > shouldn't be=20 > > > visible to the external world. If I was interested in > > cryptographic > > > module separation I might not be too happy if you shared > > the EMSK with > > > the lower layer. > > >=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/eap > > > >=20 > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > >=20 > > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 14:30:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFywD-0006EF-3f for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:30:41 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFywB-0007xV-Mp for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:30:41 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2183430113 for ; Sun, 5 Mar 2006 11:30:38 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 86C28430067 for ; Sun, 5 Mar 2006 11:30:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 756E3398038 for ; Sun, 5 Mar 2006 11:30:22 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4554739800C for ; Sun, 5 Mar 2006 11:30:19 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 26EFC89897; Sun, 5 Mar 2006 21:30:16 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A6ADF89886; Sun, 5 Mar 2006 21:30:15 +0200 (EET) Message-ID: <440B3C47.5000604@piuha.net> Date: Sun, 05 Mar 2006 21:30:15 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Madjid, Avi, >The only reason for caching the EMSK is if you have to generate an AMSK >for another application associated with the current session. > >Madjid>> Thank you for clarification. Another example may be roaming to >another access technology!! > >So the question is do you have to generate all possible AMSKs and then >delete the EMSK or can you generate the AMSKs as needed? > >Madjid>>i.e. keep EMSK for future AMSK generation. The first option will >create the need for running EAP again. > > > We have discussed this before... I do not see an issue for handoffs to another access. If your AAA server supports this then it derives AMSK_ho_root from EMSK, deletes EMSK but keeps the derived key. Once a need to do a handoff arrives, you derive AMSK_ho_key1 from AMSK_ho_root, next time you will derive AMSK_ho_key2, etc. Having said that, I do agree with Avi that there's really no substantial difference between " MUST be deleted after " and " MUST be only used for ", except maybe some implementation note describing that it would be a good idea to securely delete the value once you know that is done. But part of this debate is really not about whether the key should be deleted, but rather about whether we know the applications a priori. I think there are practical and security reasons why it is a good idea to set a requirement that the applications are known a priori. First of all, there are no surprises to the AAA server; it needs have specific authorization to serve a particular application. (Possibly even specific code.) Secondly, as we are currently in a world where the AAA servers cache no keys at all, we need to avoid a situation where AAA servers end up storing a lot of key state and have no way of knowing when it is needed. Finally, security-wise I want to know what my EAP authentication somewhere means. I, as the end user, do not want surprises. It is better to limit the set of applications of the keys at the beginning. Note that if you want, you can set up state for handoff/SIP/MIP even if you do not know they will actually be used; you set the state and keys based on the user's authorization profile. Based on the above, I still like the design where we know the possible applications (and AMSKs) at the first authentication. But we could write the text slightly differently, based on what you Avi suggested. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 14:32:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFyy1-0007ul-5k for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:32:33 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFyy0-00083q-QF for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:32:33 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 763564300F2 for ; Sun, 5 Mar 2006 11:32:32 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E2A41430067 for ; Sun, 5 Mar 2006 11:32:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D3019398036 for ; Sun, 5 Mar 2006 11:32:07 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id E205839800C for ; Sun, 5 Mar 2006 11:32:05 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BEC4789897; Sun, 5 Mar 2006 21:32:04 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 77CEC89886; Sun, 5 Mar 2006 21:32:04 +0200 (EET) Message-ID: <440B3CB4.7000408@piuha.net> Date: Sun, 05 Mar 2006 21:32:04 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Strawman -10 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Bernard Aboba wrote: >> The problem with the lower layer usage of EMSK is that >> we know that its quite likely there will be some link layer >> which gets the key generation wrong. At that point, the >> EMSK is compromised for other link layers, too. > > > What other link layers? The document talks about "the lower layer" > throughout, not multiple lower layers. True. But what we are doing in the key management framework does also have an effect on future use of EAP. I am convinced that we will see cross-access technology handover optimizations. If we do not keep parts of the key hierarchy "safe" for such extensions, we'll be in trouble later. Anyway, -10 keeps EMSK safe, so I have no problem with the current document. (But there are different variations of "safe" -- your approach and what Joe has been advocating. More on that in subsequent e-mails.) --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 14:41:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFz6H-00070C-C3 for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:41:05 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFz6H-0008A4-0J for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 14:41:05 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A18E54300B0 for ; Sun, 5 Mar 2006 11:41:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 09F9D430067 for ; Sun, 5 Mar 2006 11:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E5E77398033 for ; Sun, 5 Mar 2006 11:40:48 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 049D3398030 for ; Sun, 5 Mar 2006 11:40:46 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B29AD89897; Sun, 5 Mar 2006 21:40:45 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3FE4189886; Sun, 5 Mar 2006 21:40:45 +0200 (EET) Message-ID: <440B3EBD.5030802@piuha.net> Date: Sun, 05 Mar 2006 21:40:45 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Channel binding approaches (Was: Re: [eap] Strawman -10) References: <43E8A6C8.2010008@piuha.net> <20060207173230.GG14401@steelhead> In-Reply-To: <20060207173230.GG14401@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 The channel binding discussion has been interesting. I can actually see a number of different alternatives even within Yoshihiro's method. For instance, L2 could negotiate the use of channel bindings and have AAA inform the server of the need to use MSK_cb instead of the regular MSK. Or EAP method could negotiate this. Or the use of channel bindings would be dictated by the used lower layer, I'm not sure which approach is the best one; there are tradeoffs. Generally I like approaches where we don't need to change EAP methods but YMMV. In any case, I'm happy with what the -10 says about channel bindings, and perhaps the results of this discussion can be incorporated to Yoshihiro's draft. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 16:12:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG0Wv-00026k-0n for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 16:12:41 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG0Ws-0001m7-KB for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 16:12:41 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CC15043010C for ; Sun, 5 Mar 2006 13:12:37 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 25F874300A2 for ; Sun, 5 Mar 2006 13:12:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16EB2398030 for ; Sun, 5 Mar 2006 13:12:16 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id E20BE39801D for ; Sun, 5 Mar 2006 13:12:11 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2FFE089897; Sun, 5 Mar 2006 23:12:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D300789886; Sun, 5 Mar 2006 23:12:08 +0200 (EET) Message-ID: <440B5429.9000304@piuha.net> Date: Sun, 05 Mar 2006 23:12:09 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rafa Marin Lopez Subject: Re: [eap] About use of EMSK References: <7210B31550AC934A8637D6619739CE6906A9AE2A@e2k-sea-xch2.sea-alpha.cisco.com> <44032460.30408@dif.um.es> In-Reply-To: <44032460.30408@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Rafa Marin Lopez wrote: >> >> [Joe] The EMSK MUST NOT be exported to the lower layer. >> > Clarified this point. In your answer you specify "only" lower layer. > Did you forget to include AAA layer ? Or do you think AAA layer might > receive EMSK?. Ignoring the definition problems with layers for a while. I think we know the external behaviour we want. We want - Avoid L2 design, implementation, or node compromise problems causing the compromise of other L2 networks. Or compromise of one application of EAP keys leading to the compromise of others. - Allow crypto-agility for the function used in the key derivation. - Allow different keys to be used for different attachments, without keys 2, 3, ... to be based on key 1, which is what we would have to do with MSK - Make it possible to use existing EAP methods. One way of approaching this is to have the EAP server/AAA server keep the EMSK, and provide AMSKs for various purposes. Another is giving the EMSK to the lower layer, but dictating something about its use. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 23:12:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG75W-0000fp-2t for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:12:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG75T-00063n-Mh for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:12:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 91D684300B7 for ; Sun, 5 Mar 2006 20:12:46 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5A482430071 for ; Sun, 5 Mar 2006 20:12:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C70180C11B for ; Sun, 5 Mar 2006 20:12:30 -0800 (PST) Received: from hotmail.com (bay106-f8.bay106.hotmail.com [65.54.161.18]) by hermes.tigertech.net (Postfix) with ESMTP id 1F38480C112 for ; Sun, 5 Mar 2006 20:12:28 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Mar 2006 20:12:27 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 06 Mar 2006 04:12:27 GMT X-Originating-IP: [208.54.40.201] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 05 Mar 2006 20:12:27 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2006 04:12:27.0838 (UTC) FILETIME=[2E29E5E0:01C640D4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 326: Identifiers X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 The text of Issue 326 is enclosed below. The proposed resolution is as follows: In Section 1, change: "The combination of the Peer-ID and Server-ID uniquely specifies the endpoints of the EAP method exchange." To: "The combination of the Peer-ID and Server-ID may uniquely specify the endpoints of the EAP method exchange when they are provided." -------------------------------------------------------------------------------------------------------- Issue 326: Identifiers Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: December 1, 2005 Reference: Document: Keying-08 Comment type: T Priority: 1 Section: 1 Rationale/Explanation of issue: " EAP methods also MAY export method-specific peer and server identifiers (peer-ID and server-ID), a method-specific EAP conversation identifier known as the Method-ID, and the lifetime of the exported keys, known the Key-Lifetime. EAP methods MAY also support the import and export of Channel Bindings. New EAP method specifications MUST define the Peer-ID, Server-ID and Method-ID. The combination of the Peer-ID and Server-ID uniquely specifies the endpoints of the EAP method exchange." It seems that additional data associated with the identity should be exported to satisfy section 1.3. Suggestion is to add this and call them identity attributes. In this paragraph it states that the "Peer-ID and Server-ID uniquely specifies the  endpoints of the EAP method exchange", however further down it states that these quantities may be null. This is contradictory. Suggested modification to above text: "The combination of the Peer-ID and Server-ID may uniquely specify the endpoints of the EAP method exchange if the method supports unique IDs." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 23:30:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG7MZ-0005z3-6g for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:30:27 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG7MX-0006ha-KP for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:30:27 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2E41F4300B7 for ; Sun, 5 Mar 2006 20:30:25 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9477C430071 for ; Sun, 5 Mar 2006 20:30:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C2A080C118 for ; Sun, 5 Mar 2006 20:30:07 -0800 (PST) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by hermes.tigertech.net (Postfix) with ESMTP id 8E74480C10D for ; Sun, 5 Mar 2006 20:30:05 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Mar 2006 20:30:04 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 06 Mar 2006 04:30:03 GMT X-Originating-IP: [208.54.40.201] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 05 Mar 2006 20:30:03 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2006 04:30:04.0743 (UTC) FILETIME=[A420CD70:01C640D6] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 322: Authenticator Architecture X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f The text of Issue 322 is enclosed below. The proposed resolution is to replace Section 2.4 with the following: 2.4. Authenticator Architecture This specification does not impose constraints on the architecture of the EAP authenticator or peer. Any of the authenticator architectures described in [RFC4118] can be used. For example, it is possible for multiple base stations and a "controller" (e.g. WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in Channel Bindings. Many base stations can share the same authenticator identity. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures. It should be understood that an EAP authenticator or peer: [a] may contain one or more physical or logical ports; [b] may advertise itself as one or more "virtual" authenticators or peers; [c] may utilize multiple CPUs; [d] may support clustering services for load balancing or failover. Both the EAP peer and authenticator may have more than one physical or logical port. A 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. When a single physical authenticator advertises itself as multiple "virtual authenticators", it is possible for a single physical port to belong to multiple "virtual authenticators". The situation is illustrated in Figure 5. +-+-+-+-+ | EAP | | Peer | +-+-+-+-+ | | | Peer Ports / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ | | | | | | | | | Authenticator Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth. | | Auth. | | Auth. | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | / \ | / \ | / EAP over AAA \ | / (optional) \ | / \ | / \ | / \ | / +-+-+-+-+ | EAP | |Server | +-+-+-+-+ Figure 5: Relationship between EAP peer, authenticator and server 2.4.1. Authenticator Identification The EAP method conversation is between the EAP peer and server, as identified by the Peer-ID and Server-ID. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purposes of Channel bindings. However, the Secure Association Protocol conversation is between the peer and the authenticator, and therefore the authenticator and peer identities are relevant to that exchange, and define the scope of use of the EAP keying material passed down to the lower layer. Since an authenticator may have multiple ports, the authenticator identifiers used within the Secure Association Protocol exchange SHOULD be distinct from any port identifier (e.g. MAC address). Similarly, where a peer may have multiple ports, and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the peer identifier used within the Secure Association Protocol exchange SHOULD also be distinct from any port identifier. Where the peer and authenticator identify themselves within the lower layer using a port identifier such as a link layer address, this creates a number of problems: [1] It may not be obvious to the peer which authenticator ports are associated with which authenticators. [2] It may not be obvious to the authenticator which peer ports are associated with which peers. [3] It may not be obvious to the peer which "virtual authenticator" it is communicating with. [4] It may not be obvious to the authenticator which "virtual peer" it is communicating with. AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators. RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Since a NAS may have more than one IP address, the NAS-Identifier attribute is RECOMMENDED for the unambiguous identification of the EAP authenticator. From the point of view of the AAA server, EAP keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or AAA server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised. -------------------------------------------------------------------------------------------------------------- Issue 322: Authenticator Architecture Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: December 1, 2005 Reference: Document: Keying-08 Comment type: T Priority: 1 Section: 2.4 Rationale/Explanation of issue: There is a lot of discussion about authenticator architecture which probably should be pulled into a separate section on authenticator architecture.   Requested change: Move the description of authenticator architecture to its own section _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 05 23:36:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG7Sf-0003f6-IE for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:36:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG7Sf-0006sY-0c for eap-archive@lists.ietf.org; Sun, 05 Mar 2006 23:36:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A5D71430102 for ; Sun, 5 Mar 2006 20:36:44 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 047F8430071 for ; Sun, 5 Mar 2006 20:36:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E827C39803C for ; Sun, 5 Mar 2006 20:36:29 -0800 (PST) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id D576F39803A for ; Sun, 5 Mar 2006 20:36:26 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Mar 2006 20:36:25 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 06 Mar 2006 04:36:21 GMT X-Originating-IP: [208.54.40.201] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 05 Mar 2006 20:36:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2006 04:36:25.0983 (UTC) FILETIME=[875D68F0:01C640D7] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 338: Key Scope X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 The text of Issue 338 is enclosed below. This issue was split off from Issue 322 to allow the revised Authenticator Architecture and Key Scope sections to be discussed separately. The proposed resolution is to reorganize the key scope material into Section 2.5. How does this look? "2.5. Key Scope Where the EAP peer and authenticator cannot unambiguously identify each other they may not be able to determine the scope of transported EAP keying material. This is particularly problematic for lower layers where key caching is supported. For example, if the EAP peer cannot identify the EAP authenticator, it will be unable to determine whether transported EAP keying material has been shared outside of its authorized scope, and therefore needs to be considered compromised. There is also a practical problem because the EAP peer will be unable to utilize the EAP authenticator key cache in an efficient way. To avoid these problems, it is recomended that lower layers: [1] Specify the lower layer parameters used to identify the authenticator and peer; [2] Communicate the lower layer identities between the peer and authenticator within phase 0; [3] Communicate the lower layer authenticator identity between the authenticator and backend server within the NAS-Identifier attribute; [4] Include the lower layer identities within channel bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server; [5] Securely verify the lower layer identities within phase 2a; [6] Utilize the advertised lower layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope; Absent explicit specification within the lower layer, after the completion of phase 1b, EAP keying material and parameters are bound to the EAP peer and authenticator, but are not bound to a specific peer or authenticator port. While EAP Keying Material passed down to the lower layer is not intrinsically bound to particular authenticator and peer ports, Transient Session Keys MAY be bound to particular authenticator and peer ports by the Secure Association Protocol. However, a lower layer MAY also permit TSKs to be used on multiple peer and/or authenticator ports, providing that TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator). In order to further limit the key scope the following measures are suggested: [a] The lower layer MAY specify additional restrictions on key usage, such as limiting the use of EAP keying material and parameters on the EAP peer to the port over which on the EAP conversation was conducted. [b] The backend authentication server and authenticator MAY implement additional attributes in order to further restrict the scope of EAP keying material. For example, in 802.11, the backend authentication server may provide the authenticator with a list of authorized Called or Calling-Station-Ids and/or SSIDs for which EAP keying material is valid. [c] Where the backend authentication server provides attributes restricting the key scope, it is RECOMMENDED that restrictions be securely communicated by the authenticator to the peer. This can be accomplished using the Secure Association Protocol, but also can be accomplished via the EAP method or the lower layer." -------------------------------------------------------------------------------------------------------------------- Issue 338: Key Scope Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: December 1, 2005 Reference: Document: Keying-08 Comment type: T Priority: 1 Section: 2.4 Rationale/Explanation of issue: The key scope section is a little hard to understand. --- The key scope recommendations should specify which key it refers to. I believe it refers to the AAA-key. --- There could be some more generic text about key scoping that describes the requirements in the lower layer such as: - Identify what parameters in the lower layer define the key scope - In phase 0 communicate lower layer parameters that identify the key scope between Peer and Authenticator - If channel bindings are supported then include these parameters in the channel bindings in phase 1a - The peer can now use the key scope parameters to determine if it has correct keys for phase 2 lower layer protocol interactions   Requested change: Include in the key scoping section introduction (2.4) something along the lines of the following text: "Since authenticator architectures and deployment scenarios vary the usable scope of the keys derived by the peer and server and sent to the authenticator vary. By defining a key scope a lower layer can take advantage of key caches in the system to optimize lower layer interactions. In order to address key scoping the following needs to be specified by the lower layer: - Identify what parameters in the lower layer define the key scope - In phase 0 communicate lower layer parameters that identify the key scope between Peer and Authenticator - If channel bindings are supported then include these parameters in the channel bindings in phase 1a - The peer can now use the key scope parameters to determine if it has correct keys for phase 2 lower layer protocol interactions" The following sections describe key scoping with respect to the AAA-Key that is sent to the authenticator for lower layer protection. It is possible that a lower layer may define other keys and key uses which need to have scoping applied. --- Make it clear that remaining parts of sections 2.4.1 and 2.4.2 refer to the AAA-Key. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 02:30:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGAAU-0008Ff-3F for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:30:10 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGAAS-0003D4-Lu for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:30:10 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 189784300EA for ; Sun, 5 Mar 2006 23:30:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0B8DD43006C for ; Sun, 5 Mar 2006 23:29:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E262E398021 for ; Sun, 5 Mar 2006 23:29:45 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id B0CD2398019 for ; Sun, 5 Mar 2006 23:29:42 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 871AC89897; Mon, 6 Mar 2006 09:29:39 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 238B989886; Mon, 6 Mar 2006 09:29:39 +0200 (EET) Message-ID: <440BE4E2.7030307@piuha.net> Date: Mon, 06 Mar 2006 09:29:38 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Proposed Resolution to Issue 326: Identifiers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Ok. --Jari Bernard Aboba wrote: > The text of Issue 326 is enclosed below. The proposed resolution is > as follows: > > In Section 1, change: > > "The combination of the Peer-ID and Server-ID uniquely specifies the > endpoints of the EAP method exchange." > > To: > > "The combination of the Peer-ID and Server-ID may uniquely specify the > endpoints of the EAP method exchange when they are provided." > > -------------------------------------------------------------------------------------------------------- > > Issue 326: Identifiers > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: December 1, 2005 > Reference: > Document: Keying-08 > Comment type: T > Priority: 1 > Section: 1 > Rationale/Explanation of issue: > > " EAP methods also MAY export method-specific peer and server > identifiers (peer-ID and server-ID), a method-specific EAP > conversation identifier known as the Method-ID, and the lifetime of > the exported keys, known the Key-Lifetime. EAP methods MAY also > support the import and export of Channel Bindings. New EAP method > specifications MUST define the Peer-ID, Server-ID and Method-ID. The > combination of the Peer-ID and Server-ID uniquely specifies the > endpoints of the EAP method exchange." > > It seems that additional data associated with the identity should be > exported to satisfy section 1.3. Suggestion is to add this and call > them identity attributes. > > In this paragraph it states that the "Peer-ID and Server-ID uniquely > specifies the endpoints of the EAP method exchange", however further > down it states > that these quantities may be null. This is contradictory. Suggested > modification to above text: > > "The combination of the Peer-ID and Server-ID may uniquely specify the > endpoints of the EAP method exchange if the method supports unique IDs." > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 02:32:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGACM-0001J5-7V for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:32:06 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGACK-0003G4-L4 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:32:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2E74B4300D7 for ; Sun, 5 Mar 2006 23:32:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 21B3F43006C for ; Sun, 5 Mar 2006 23:31:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0FEBD398019 for ; Sun, 5 Mar 2006 23:31:46 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 84F87398021 for ; Sun, 5 Mar 2006 23:31:43 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2876889897; Mon, 6 Mar 2006 09:31:42 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A396689886; Mon, 6 Mar 2006 09:31:41 +0200 (EET) Message-ID: <440BE55D.5010408@piuha.net> Date: Mon, 06 Mar 2006 09:31:41 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Proposed Resolution to Issue 322: Authenticator Architecture References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Looks good to me. --Jari Bernard Aboba wrote: > The text of Issue 322 is enclosed below. The proposed resolution is > to replace Section 2.4 with the following: > > 2.4. Authenticator Architecture > > This specification does not impose constraints on the architecture of > the EAP authenticator or peer. Any of the authenticator > architectures described in [RFC4118] can be used. For example, it is > possible for multiple base stations and a "controller" (e.g. WLAN > switch) to comprise a single EAP authenticator. In such a situation, > the "base station identity" is irrelevant to the EAP method > conversation, except perhaps as an opaque blob to be used in Channel > Bindings. Many base stations can share the same authenticator > identity. As a result, lower layers need to identify EAP peers and > authenticators unambiguously, without incorporating implicit > assumptions about peer and authenticator architectures. > > It should be understood that an EAP authenticator or peer: > > [a] may contain one or more physical or logical ports; > [b] may advertise itself as one or more "virtual" > authenticators or peers; > [c] may utilize multiple CPUs; > [d] may support clustering services for load balancing or failover. > > > Both the EAP peer and authenticator may have more than one physical > or logical port. A 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. When a single physical authenticator advertises itself as > multiple "virtual authenticators", it is possible for a single > physical port to belong to multiple "virtual authenticators". The > situation is illustrated in Figure 5. > > > +-+-+-+-+ > | EAP | > | Peer | > +-+-+-+-+ > | | | Peer Ports > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > | | | | | | | | | Authenticator Ports > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > | | | | | | > | Auth. | | Auth. | | Auth. | > | | | | | | > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > \ | / > \ | / > \ | / > EAP over AAA \ | / > (optional) \ | / > \ | / > \ | / > \ | / > +-+-+-+-+ > | EAP | > |Server | > +-+-+-+-+ > > Figure 5: Relationship between EAP peer, authenticator and server > > > 2.4.1. Authenticator Identification > > The EAP method conversation is between the EAP peer and server, as > identified by the Peer-ID and Server-ID. The authenticator identity, > if considered at all by the EAP method, is treated as an opaque blob > for the purposes of Channel bindings. However, the Secure > Association Protocol conversation is between the peer and the > authenticator, and therefore the authenticator and peer identities > are relevant to that exchange, and define the scope of use of the EAP > keying material passed down to the lower layer. > > Since an authenticator may have multiple ports, the authenticator > identifiers used within the Secure Association Protocol exchange > SHOULD be distinct from any port identifier (e.g. MAC address). > Similarly, where a peer may have multiple ports, and sharing of EAP > keying material and parameters between peer ports of the same link > type is allowed, the peer identifier used within the Secure > Association Protocol exchange SHOULD also be distinct from any port > identifier. > > Where the peer and authenticator identify themselves within the lower > layer using a port identifier such as a link layer address, this > creates a number of problems: > > [1] It may not be obvious to the peer which authenticator ports are > associated with which authenticators. > > [2] It may not be obvious to the authenticator which peer ports are > associated with which peers. > > [3] It may not be obvious to the peer which "virtual authenticator" it > is communicating with. > > [4] It may not be obvious to the authenticator which "virtual peer" it > is communicating with. > > AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] > provide a mechanism for the identification of AAA clients; since > the EAP authenticator and AAA client are always co-resident, this > mechanism is applicable to the identification of EAP > authenticators. > > RADIUS [RFC2865] requires that an Access-Request packet contain one > or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address > attributes. Since a NAS may have more than one IP address, the > NAS-Identifier attribute is RECOMMENDED for the unambiguous > identification of the EAP authenticator. > > From the point of view of the AAA server, EAP keying material and > parameters are transported to the EAP authenticator identified by > the NAS-Identifier attribute. Since an EAP authenticator MUST NOT > share EAP keying material or parameters with another party, if the > EAP peer or AAA server detects use of EAP keying material and > parameters outside the scope defined by the NAS-Identifier, the > keying material MUST be considered compromised. > > > -------------------------------------------------------------------------------------------------------------- > > Issue 322: Authenticator Architecture > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: December 1, 2005 > Reference: > Document: Keying-08 > Comment type: T > Priority: 1 > Section: 2.4 > Rationale/Explanation of issue: > > There is a lot of discussion about authenticator architecture which > probably should be pulled into a separate section on authenticator > architecture. > > Requested change: > > Move the description of authenticator architecture to its own section > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 02:40:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGAK6-0007G5-CM for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:40:06 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGAK4-0003UP-PG for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 02:40:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 23581430097 for ; Sun, 5 Mar 2006 23:40:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6E19843006C for ; Sun, 5 Mar 2006 23:39:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5B054398024 for ; Sun, 5 Mar 2006 23:39:48 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id CFAD2398021 for ; Sun, 5 Mar 2006 23:39:45 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 78CAB89897; Mon, 6 Mar 2006 09:39:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0D7E189886; Mon, 6 Mar 2006 09:39:44 +0200 (EET) Message-ID: <440BE73F.1040402@piuha.net> Date: Mon, 06 Mar 2006 09:39:43 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Proposed Resolution to Issue 338: Key Scope References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Text is fine. --Jari Bernard Aboba wrote: > The text of Issue 338 is enclosed below. This issue was split off > from Issue 322 to allow the revised Authenticator Architecture and Key > Scope sections to be discussed separately. > > The proposed resolution is to reorganize the key scope material into > Section 2.5. How does this look? > > "2.5. Key Scope > > Where the EAP peer and authenticator cannot unambiguously identify > each other they may not be able to determine the scope of transported > EAP keying material. This is particularly problematic for lower > layers where key caching is supported. > > For example, if the EAP peer cannot identify the EAP authenticator, > it will be unable to determine whether transported EAP keying > material has been shared outside of its authorized scope, and > therefore needs to be considered compromised. There is also a > practical problem because the EAP peer will be unable to utilize the > EAP authenticator key cache in an efficient way. > > To avoid these problems, it is recomended that lower layers: > > [1] Specify the lower layer parameters used to identify the > authenticator and peer; > > [2] Communicate the lower layer identities between the peer and > authenticator within phase 0; > > [3] Communicate the lower layer authenticator identity between the > authenticator and backend server within the NAS-Identifier > attribute; > > [4] Include the lower layer identities within channel bindings (if > supported) in phase 1a, ensuring that they are communicated between > the EAP peer and server; > > [5] Securely verify the lower layer identities within phase 2a; > > [6] Utilize the advertised lower layer identities to enable the peer > and authenticator to verify that keys are maintained within the > advertised scope; > > Absent explicit specification within the lower layer, after the > completion of phase 1b, EAP keying material and parameters are > bound to the EAP peer and authenticator, but are not bound to a > specific peer or authenticator port. > > While EAP Keying Material passed down to the lower layer is not > intrinsically bound to particular authenticator and peer ports, > Transient Session Keys MAY be bound to particular authenticator and > peer ports by the Secure Association Protocol. However, a lower > layer MAY also permit TSKs to be used on multiple peer and/or > authenticator ports, providing that TSK freshness is guaranteed > (such as by keeping replay counter state within the authenticator). > > In order to further limit the key scope the following measures are > suggested: > > [a] The lower layer MAY specify additional restrictions on key usage, > such as limiting the use of EAP keying material and parameters on > the EAP peer to the port over which on the EAP conversation was > conducted. > > [b] The backend authentication server and authenticator MAY implement > additional attributes in order to further restrict the scope of EAP > keying material. For example, in 802.11, the backend > authentication server may provide the authenticator with a list of > authorized Called or Calling-Station-Ids and/or SSIDs for which EAP > keying material is valid. > > [c] Where the backend authentication server provides attributes > restricting the key scope, it is RECOMMENDED that restrictions be > securely communicated by the authenticator to the peer. This can > be accomplished using the Secure Association Protocol, but also > can be accomplished via the EAP method or the lower layer." > > -------------------------------------------------------------------------------------------------------------------- > > Issue 338: Key Scope > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: December 1, 2005 > Reference: > Document: Keying-08 > Comment type: T > Priority: 1 > Section: 2.4 > Rationale/Explanation of issue: > The key scope section is a little hard to understand. > --- > The key scope recommendations should specify which key it refers to. I > believe it refers to the AAA-key. > --- > There could be some more generic text about key scoping that describes > the requirements in the lower layer such as: > > - Identify what parameters in the lower layer define the key scope > - In phase 0 communicate lower layer parameters that identify the key > scope between Peer and Authenticator > - If channel bindings are supported then include these parameters in the > channel bindings in phase 1a > - The peer can now use the key scope parameters to determine if it has > correct keys for phase 2 lower layer protocol interactions > > Requested change: > > Include in the key scoping section introduction (2.4) something along > the lines of the following text: > > "Since authenticator architectures and deployment scenarios vary the > usable scope of the keys derived by the peer and server and sent to the > authenticator vary. By defining a key scope a lower layer can take > advantage of key caches in the system to optimize lower layer > interactions. In order to address key scoping the following needs to be > specified by the lower layer: > > - Identify what parameters in the lower layer define the key scope > - In phase 0 communicate lower layer parameters that identify the key > scope between Peer and Authenticator > - If channel bindings are supported then include these parameters in the > channel bindings in phase 1a > - The peer can now use the key scope parameters to determine if it has > correct keys for phase 2 lower layer protocol interactions" > > The following sections describe key scoping with respect to the AAA-Key > that is sent to the authenticator for lower layer protection. It is > possible that a lower layer may define other keys and key uses which > need to have scoping applied. > --- > > Make it clear that remaining parts of sections 2.4.1 and 2.4.2 refer to > the AAA-Key. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 04:16:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBpA-0006Hv-Li for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:16:16 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBp8-00078v-6m for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:16:16 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5B1564300FD for ; Mon, 6 Mar 2006 01:16:13 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 78D1E43006C for ; Mon, 6 Mar 2006 01:15:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A0B7398028 for ; Mon, 6 Mar 2006 01:15:55 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 132CB398027 for ; Mon, 6 Mar 2006 01:15:52 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3ED6789898; Mon, 6 Mar 2006 11:15:49 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D641D89897; Mon, 6 Mar 2006 11:15:48 +0200 (EET) Message-ID: <440BFDC4.1030202@piuha.net> Date: Mon, 06 Mar 2006 11:15:48 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" , Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: [eap] issue 325 - channel bindings X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Text proposal. In 3.1, change Channel Bindings Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer passes the result of the verification (TRUE or FALSE) up to the EAP method. to Channel Bindings Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer passes the result of the verification (TRUE or FALSE) up to the EAP method. It is also possible that the verification is performed entirely within the EAP layer. In this case, the EAP layer exports only the result to the lower layer. Given that EAP treats the data as opaque octets, verification at the EAP layer can only be performed as an exact match. And change in 1.4 this The successful completion of an EAP method that supports key derivation results in the export of keying material on the EAP peer and server. Even though the EAP peer or server may import Channel- Bindings that may include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP the only relevant identities are the Peer-ID and Server-ID. Channel Bindings are only interpreted by the lower layer. to The successful completion of an EAP method that supports key derivation results in the export of keying material on the EAP peer and server. Even though the EAP peer or server may import Channel- Bindings that may include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP the only relevant identities are the Peer-ID and Server-ID. --Jari >*ssue 325: Channel Bindings* >Submitter name: Joe Salowey >Submitter email address: jsalowey@cisco.com >Date Submitted: December 1, 2005 >Reference: >Document: Keying-08 >Comment type: T >Priority: 1 >Section: 1.3, 1.4 >Rationale/Explanation of issue: > >Section 1.3 > > > >There are two styles of channel bindings that may be supported by EAP >methods. The text in this section describes exportable channel bindings. >There is also the approach where the bindings are non exportable. In >this case the method does a binary comparison of the channel bindings or >hash of the channel bindings and fails if the result does not match. I >can see the possibility of a method supporting both styles. Should we >include both? > > > >Section 1.4 > >Exportable channel binding are references in this section, >non-exportable ones are not. If we make changes to this affect above >then we should change it here as well. > > > >[Bernard Aboba] Can you provide text? > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 04:36:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGC94-0006P3-Gz for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:36:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGC93-0000VV-18 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:36:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9709D43009A for ; Mon, 6 Mar 2006 01:36:48 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1812A43006C for ; Mon, 6 Mar 2006 01:36:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 07A5639801A for ; Mon, 6 Mar 2006 01:36:29 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 27209398024 for ; Mon, 6 Mar 2006 01:36:25 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C32058989B; Mon, 6 Mar 2006 11:36:24 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5EDFB89897; Mon, 6 Mar 2006 11:36:24 +0200 (EET) Message-ID: <440C0298.4040100@piuha.net> Date: Mon, 06 Mar 2006 11:36:24 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] About use of EMSK References: <7210B31550AC934A8637D6619739CE6906A9AE2A@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906A9AE2A@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Here's some analysis of the server vs. lower-layer based EMSK processing approaches. (1) In the server based approach we keep the EMSK in the server (perhaps just for a moment) and generate the AMSKs, which are given to the the different applications, such as fast handoff mechanisms. The use of these applications goes via AAA, e.g., some kind of key requests or fast re-auth requests can be sent from NASes to the server. The AMSKs are derived using a KDF which is decided either (a) by a default plus optional negotiation in methods or (b) by lower layer negotiation and having AAA tell the server which KDF to use. (2) In the lower-layer based EMSK processing approach, the EMSK is delivered to the authenticator along with the MSK. KDF is selected either (a) by a default in EAP plus optional negotiation in methods, choice is communicated to the lower layer via AAA or (b) by lower layer negotiation alone. The lower layer is responsible for all use of the AMSKs in a local context. That is, no AAA key requests are needed or possible. Discussion about the chosen approach for EMSK use has so far appeared to assume 1a vs. 2b. Based on the above, it seems that the KDF negotiation may be a separate issue from who maintains the EMSK and calculates AMSKs. In the following I'll try to analyze these issues. The KDF negotiation is indeed problematic almost no matter what we do. Requiring new funtionality in methods is in practice often a non-starter; while we can develop new methods and update old ones, it is expected that most of current usage will continue to use the existing methods. Having a default does not help much either, if the default becomes broken in the near future. But requiring new functionality in link layers it not always easy either. It would be easy when we are developing a new link layer and including some EMSK usage as a part of that. But if we were to use EMSK for some new function over 802.11, for instance, would there be enough incentive to extend 802.11 just to make this possible? The choices and their implications are: (a) Specified default, optional negotiation in EAP methods. This implies an interface either from methods to the AAA/EAP server code (for solution 1) or AAA protocol extensions for solution 2. Changes in peers, servers, methods, possibly AAA protocols. (b) Lower layer negotiation. If used together with solution 1, implies AAA protocol extensions to communicate the KDF. If used with solution 2, implies AAA protocol extensions to carry the EMSK. Changes in lower layers, AAA protocol. No changes in EAP or methods. Based on this my current preference is (b). I'd be willing to accept (a), too. The choice between server or lower-layer based EMSK processing depends on security implications and ease of use for different purposes. The choices are: (1) Derive AMSKs at the EAP/AAA server. Implies a AAA protocol extension to retrieve AMSKs. Changes at the EAP/AAA server, authenticator. New, stateful nature of the EAP/AAA server. (2) Derive AMSKs at the lower layer. Implies a AAA protocol extension to carry EMSK to the authenticator. Small changes at the EAP/AAA server, main functionality in the authenticator. Hard to see how other nodes than the authenticator would actually use the AMSKs. Traditionally, NAS -> NAS communication has not been easy compared to NAS -> AAA communication. Based on this my current preference is (1). But its a close call. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 04:52:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGCOJ-000496-QB for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:52:35 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGCOI-00019K-8z for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 04:52:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE20C430071 for ; Mon, 6 Mar 2006 01:52:33 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 39A7A43006C for ; Mon, 6 Mar 2006 01:52:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2A060398015 for ; Mon, 6 Mar 2006 01:52:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 056E6398024 for ; Mon, 6 Mar 2006 01:52:07 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D801C89898; Mon, 6 Mar 2006 11:52:06 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 865C989897; Mon, 6 Mar 2006 11:52:06 +0200 (EET) Message-ID: <440C0646.2060404@piuha.net> Date: Mon, 06 Mar 2006 11:52:06 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Issue 337: Removal of Appendix A References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Right. Very good. Bernard Aboba wrote: > Issue 337: Removal of Appendix A > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date Submitted: February 25, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg03993.html > Document: KEYING-09 > Comment type: E > Priority: 1 > Section: Appendix A > Rationale/Explanation of issue: > > The material in Appendix A has now been included in RFC 2716bis. As a > result, it is no longer needed in the EAP Keying Framework. It is > recommended that this Appendix be deleted. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 06:26:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDrG-00040o-F9 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:26:34 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDrF-0004yI-0M for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:26:34 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 14DF3430110 for ; Mon, 6 Mar 2006 03:26:32 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BAE26430054 for ; Mon, 6 Mar 2006 03:26:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A218B39801A for ; Mon, 6 Mar 2006 03:26:20 -0800 (PST) Received: from hotmail.com (bay106-f8.bay106.hotmail.com [65.54.161.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id B95D6398024 for ; Mon, 6 Mar 2006 03:26:17 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 03:26:16 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 06 Mar 2006 11:26:14 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <440BFDC4.1030202@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net, jsalowey@cisco.com, aboba@internaut.com Subject: RE: [eap] issue 325 - channel bindings Date: Mon, 06 Mar 2006 03:26:14 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2006 11:26:16.0880 (UTC) FILETIME=[C8AE8300:01C64110] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 >Channel Bindings > >Channel Bindings include lower layer parameters that are verified for >consistency between the EAP peer and server. In order to avoid >introducing media dependencies, EAP methods that transport Channel >Binding data MUST treat this data as opaque octets. Typically the >EAP method imports Channel Bindings from the lower layer on the peer, and >transmits them securely to the EAP server, which exports them to >the lower layer. However, transport may occur from EAP server to >peer, or may be bi-directional. On the side of the exchange (peer or >server) where Channel Bindings are verified, the lower layer passes >the result of the verification (TRUE or FALSE) up to the EAP method. As noted earlier by Yoshi, while channel binding comparisons can be done on either the peer or server, only the server can verify that the values are actually *correct*. A peer cannot do this because it does not have knowledge of the infrastructure. Therefore while the channel bindings can be passed in both directions, it seems that it is only possible to address the "impersonation" problem if they are passed in the direction of peer to server. This is probably worth noting. >It is also possible that the verification is performed entirely >within the EAP layer. In this case, the EAP layer exports only the >result to the lower layer. Given that EAP treats the data as opaque >octets, verification at the EAP layer can only be performed as >an exact match. I'm not sure how this is supposed to work. The channel bindings which are passed to the backend authentication server depend on what attributes the NAS sends. For example, it is not mandatory for a NAS to send Called-Station-ID or Calling-Station-ID to the backend authentication server. An 802.11r implementation might send a "Mobility-Domain-ID" attribute, while an 802.11i implementation woudl not. Similarly, the Channel Bindings sent up by the lower layer may vary according to the implementation. Given this, some policy is typically required in order to determine which of the attributes MUST match, which can be ignored, what actions are taken, etc. Requiring an "exact match" would imply that exactly the same attributes are sent by the NAS as are sent up by the particular driver implementation, in the same format. This would be very brittle; unless the EAP peer, server and authenticator implementations are provided by the same vendor, this seems unlikely to work reliably. >Channel Bindings are only interpreted by the lower layer. Maybe this should be "only interpreted by the lower layer or AAA layer." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 06:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDz1-0000pq-4m for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:34:35 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDyz-00059m-P5 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:34:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6E10E43008F for ; Mon, 6 Mar 2006 03:34:33 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5C01F430054 for ; Mon, 6 Mar 2006 03:34:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 466E639802D for ; Mon, 6 Mar 2006 03:34:19 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E688398030 for ; Mon, 6 Mar 2006 03:34:16 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 62A6289898 for ; Mon, 6 Mar 2006 13:34:13 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0AF9C89897 for ; Mon, 6 Mar 2006 13:34:13 +0200 (EET) Message-ID: <440C1E34.5070101@piuha.net> Date: Mon, 06 Mar 2006 13:34:12 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [eap] keying-10 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 I have reviewed keying-10 and I have no further issues for it. As far as I can see, we have also closed all issues that the issue tracker has, but we still need to discuss the EMSK sharing mechanism. 325 has text but needs confirmation from others that the text is OK. There seemed to also some discussion about the deletion requirement, which probably deserves its own issue, too. If we can get these resolved within this or the next week, I think we have completed the WGLC issue resolution and can send the draft for AD review. Then we would not have a reason to discuss it at IETF-65. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 06:38:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGE2t-0004zu-Fl for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:38:35 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGE2s-0005LJ-0j for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 06:38:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9237843007C for ; Mon, 6 Mar 2006 03:38:33 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0536D430054 for ; Mon, 6 Mar 2006 03:38:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DCFE039802D for ; Mon, 6 Mar 2006 03:38:17 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5AA68398024 for ; Mon, 6 Mar 2006 03:38:15 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 29BE089898; Mon, 6 Mar 2006 13:38:14 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9CAAF89897; Mon, 6 Mar 2006 13:38:13 +0200 (EET) Message-ID: <440C1F25.7090004@piuha.net> Date: Mon, 06 Mar 2006 13:38:13 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] issue 325 - channel bindings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, aboba@internaut.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Bernard Aboba wrote: >> Channel Bindings >> >> Channel Bindings include lower layer parameters that are verified >> for consistency between the EAP peer and server. In order to avoid >> introducing media dependencies, EAP methods that transport Channel >> Binding data MUST treat this data as opaque octets. Typically the >> EAP method imports Channel Bindings from the lower layer on the >> peer, and transmits them securely to the EAP server, which exports >> them to >> the lower layer. However, transport may occur from EAP server to >> peer, or may be bi-directional. On the side of the exchange (peer >> or server) where Channel Bindings are verified, the lower layer passes >> the result of the verification (TRUE or FALSE) up to the EAP method. > > > As noted earlier by Yoshi, while channel binding comparisons > can be done on either the peer or server, only the server can verify that > the values are actually *correct*. A peer cannot do this because it does > not have knowledge of the infrastructure. Therefore while the channel > bindings can be passed in both directions, it seems that it is only > possible to address the "impersonation" problem if they are passed in the > direction of peer to server. This is probably worth noting. Right. Add "While the verification can be done eithe rby the peer or the server, typically only the server would have knowledge to determine the correctness of the values, as opposed to merely verifying their equality." >> It is also possible that the verification is performed entirely >> within the EAP layer. In this case, the EAP layer exports only the >> result to the lower layer. Given that EAP treats the data as opaque >> octets, verification at the EAP layer can only be performed as >> an exact match. > > > I'm not sure how this is supposed to work. The channel bindings which are > passed to the backend authentication server depend on what attributes the > NAS sends. For example, it is not mandatory for a NAS to send > Called-Station-ID or Calling-Station-ID to the backend authentication > server. An 802.11r implementation might send a > "Mobility-Domain-ID" attribute, while an 802.11i implementation > woudl not. Similarly, the Channel Bindings sent up by the lower layer > may > vary according to the implementation. > > Given this, some policy is typically required in order to determine which > of the attributes MUST match, which can be ignored, what actions > are taken, etc. I fully agree. > Requiring an "exact match" would imply that exactly the same attributes > are sent by the NAS as are sent up by the particular driver > implementation, in the same format. This would be very brittle; > unless the EAP peer, server and authenticator implementations are > provided > by the same vendor, this seems unlikely to work reliably. Yes. We are not claiming that the approach is a good one, just that its possible and that it has some issues (such as requiring exact match). Do we want more text about the brittleness, or do you want to delete the change altogether? > >> Channel Bindings are only interpreted by the lower layer. > > > Maybe this should be "only interpreted by the lower layer or AAA layer." > Ok. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 07:02:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEQ2-0006re-2b for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 07:02:30 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEQ0-0005qs-M0 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 07:02:30 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2605F430071 for ; Mon, 6 Mar 2006 04:02:27 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 79FD6430054 for ; Mon, 6 Mar 2006 04:01:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6535380C0FE for ; Mon, 6 Mar 2006 04:01:58 -0800 (PST) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by hermes.tigertech.net (Postfix) with ESMTP id 7F3CD80C102 for ; Mon, 6 Mar 2006 04:01:55 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 04:01:54 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 06 Mar 2006 12:01:51 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <440C1F25.7090004@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] issue 325 - channel bindings Date: Mon, 06 Mar 2006 04:01:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2006 12:01:54.0879 (UTC) FILETIME=[C30744F0:01C64115] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com, aboba@internaut.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 How about this? "Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 07:09:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEX0-0004Qn-59 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 07:09:42 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEWz-0005yS-PT for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 07:09:42 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 633394300BC for ; Mon, 6 Mar 2006 04:09:41 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4EFB3430071 for ; Mon, 6 Mar 2006 04:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E1805398024 for ; Mon, 6 Mar 2006 04:08:55 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id E882F39801A for ; Mon, 6 Mar 2006 04:08:53 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C7D0789898; Mon, 6 Mar 2006 14:08:52 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7993589897; Mon, 6 Mar 2006 14:08:52 +0200 (EET) Message-ID: <440C2654.2050205@piuha.net> Date: Mon, 06 Mar 2006 14:08:52 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] issue 325 - channel bindings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, aboba@internaut.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Ok. Bernard Aboba wrote: > How about this? > > "Channel Bindings include lower layer parameters that > are verified for consistency between the EAP peer and server. > In order to avoid introducing media dependencies, EAP > methods that transport Channel Binding data MUST treat this > data as opaque octets. > > Typically the EAP method imports Channel Bindings from the > lower layer on the peer, and transmits them securely to the > EAP server, which exports them to the lower layer or AAA layer. However, > transport may occur from EAP server to peer, or may be > bi-directional. On the side of the exchange (peer or server) > where Channel Bindings are verified, the lower layer or AAA layer passes > the result of the verification (TRUE or FALSE) up to the > EAP method. > > While the verification can be done either by the peer > or the server, typically only the server has the knowledge to > determine the correctness of the values, as opposed to merely > verifying their equality." > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 11:46:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIqp-0001vj-Ja for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 11:46:27 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIqo-0000lU-6h for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 11:46:27 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 61764430067 for ; Mon, 6 Mar 2006 08:46:25 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 76727430054 for ; Mon, 6 Mar 2006 08:46:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6641D80C005 for ; Mon, 6 Mar 2006 08:46:12 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by hermes.tigertech.net (Postfix) with ESMTP id 377D680C0FE for ; Mon, 6 Mar 2006 08:46:10 -0800 (PST) Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k26Gk4Oa005491; Mon, 6 Mar 2006 11:46:04 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Mon, 6 Mar 2006 11:45:53 -0500 To: Bernard Aboba Subject: Re: [eap] issue 325 - channel bindings Message-ID: <20060306164553.GC2929@steelhead> References: <440C1F25.7090004@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060126 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 39 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com, aboba@internaut.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 It may be too late to make comment on this, but if we agree on only the server has the knowledge of the Channel Binding values, I really don't see any value on carrying Channel Bindings over EAP methods compared to the other method of using the Channel Bindings for key derivation. Please correct if my view is wrong. Yoshihiro Ohba On Mon, Mar 06, 2006 at 04:01:51AM -0800, Bernard Aboba wrote: > How about this? > > "Channel Bindings include lower layer parameters that > are verified for consistency between the EAP peer and server. > In order to avoid introducing media dependencies, EAP > methods that transport Channel Binding data MUST treat this > data as opaque octets. > > Typically the EAP method imports Channel Bindings from the > lower layer on the peer, and transmits them securely to the > EAP server, which exports them to the lower layer or AAA layer. However, > transport may occur from EAP server to peer, or may be > bi-directional. On the side of the exchange (peer or server) > where Channel Bindings are verified, the lower layer or AAA layer passes > the result of the verification (TRUE or FALSE) up to the > EAP method. > > While the verification can be done either by the peer > or the server, typically only the server has the knowledge to > determine the correctness of the values, as opposed to merely > verifying their equality." > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From AnaCondabettyabbq@yahoo.ca Mon Mar 06 12:17:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJKv-0001eW-PC for eap-archive@ietf.org; Mon, 06 Mar 2006 12:17:33 -0500 Received: from [82.139.60.49] (helo=48B5318) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGJKt-0001vw-R3 for eap-archive@ietf.org; Mon, 06 Mar 2006 12:17:33 -0500 Received: from mailgate.bracket.net (HELO localhost) by caulivorous.advection.net with ESMTP id x06FtWdNe646o75q Received: (from smap@localhost) by mail.bestraddle.net (8.9.3/8.9.3) id Z654.LG40.3ll9L3 for ; Mon, 06 Mar 2006 12:16:33 -0500 Date: Mon, 06 Mar 2006 20:13:33 +0300 From: "Lana B. Kennedy, III" To: eap-archive@ietf.org Subject: hey there Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hello, We're not only the BEST choice but the SMaRT choice. B()()sT your satisfaction with C1@Lis soft#t@bs. ------------------------------------------------------------------------ copy the address below and paste in i your web browser: biplanar.coralstrategy.com ------------------------------------------------------------------------ Her gentle snores mingle with the static of traffic noise and,. With these kisses let me remove your tears;=20. The ravening clouds shall not long be victorious,=20. said Randy Sears, vice president for auto market intelligence for the=20. While in the wild wood I did lie,. Get back to you later, Ruthie Martiniere From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 12:40:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJhI-0005BP-3x for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:40:40 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJhG-0002x7-GN for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:40:40 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA52B4300C9 for ; Mon, 6 Mar 2006 09:40:37 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 81BBF430054 for ; Mon, 6 Mar 2006 09:40:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75BFC39802D for ; Mon, 6 Mar 2006 09:40:22 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 443D0398053 for ; Mon, 6 Mar 2006 09:40:07 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 06 Mar 2006 09:39:04 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26Hd37T026822; Mon, 6 Mar 2006 09:39:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 09:45:56 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F07@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAw3LJAA== From: "Salowey, Joe" To: "Avi Lior" , "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Thursday, March 02, 2006 12:16 PM > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;=20 > Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Joe and Madjid, >=20 > The only reason for caching the EMSK is if you have to=20 > generate an AMSK > for another application associated with the current session. >=20 > So the question is do you have to generate all possible AMSKs and then > delete the EMSK or can you generate the AMSKs as needed? >=20 [Joe] I understand that there may be need for caching of certain quantities. I think Jari explained it well in a separate message. In my opinion you should try to identify the applications in use and the keys needed as early as possible. If this is not possible then caching of the MSK may be necessary. Do we have examples where the caching of the EMSK is necessary. In the case where key caching is used the cache needs to be managed. If we are caching EMSKs then the document that describes EMSK usage must describe how key cache can be managed.=20 > Finally I have an slight issue with the statement that a KEY should be > deleted so that it wont be used for other purposes. I find that > statements like that are an over specification. What makes=20 > anyone think > that making a statement that "X should/must be deleted" is going to be > taken more seriously then "X should/must only be used for=20 > purpose X and > should/must not be transported out of Y"? >=20 > I think that whether it gets deleted or not is an=20 > implementation issue. >=20 [Joe] The goal of the architecture is to prevent the re-use of keys for multiple different purposes. I agree that this is not necessarily the same a deletion. It is very important that keys derived from the EMSK don't collide purposes across applications. What happens in a particular AMSK branch of the key hierarchy is not necessarily as important since this branch is cryptographically separated from the rest of the system through the AMSK derivation. I think the current text could probably do better in motivating why it is good practice to delete keys. =20 > Finally if we insist on saying that X must be deleted we should really > say that X must be securely deleted. There is a difference. =20 > When a key > is securely deleted the software takes extra care that the memory > location containing the key is first erased before the memory location > is freed to the heap. Perhaps we can state that somewhere.=20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Thursday, March 02, 2006 2:49 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1=20 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Thursday, March 02, 2006 8:44 AM > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Hi Joe, > > >=20 > > > Thanks for the email. I think you responded to the old=20 > piece of the=20 > > > email from Rafa and I am to blame for causing that=20 > confusion, as I=20 > > > kept that part to provide context. > > > Again, my question was why an entity needs to delete EMSK after=20 > > > generating the first AMSK (or first set of AMSKs?)? This=20 > > seems to be=20 > > > the requirement regardless of two options: > > >=20 > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based=20 > > request from=20 > > > AAA layer, delete EMSK Immediately (this means EAP layer=20 > must have=20 > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > 2) push EMSK down to AAA layer at backend server, create=20 > > AMSK at AAA=20 > > > layer and delete EMSK immediately (this means AAA layer must have=20 > > > KDFs) > > > > > [Joe] If the AAA layer contains the AAA client and AAA server=20 > > then the EMSK should not be available to this layer, if the=20 > > AAA layer means something else then I don't know about (1). =20 > > The AMSK should be generated in the EAP and exported, option (2). > > =20 > > >=20 > > > In both cases we require deletion of EMSK after=20 > generation of AMSK,=20 > > > why? > > >=20 > > [Joe] To minimize the chance of exposure of the EMSK. Why do=20 > > you need to cache it? Could you generate and cache an AMSK=20 > instead? =20 > >=20 > >=20 > > > Thanks, > > >=20 > > > Madjid > > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1=20 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10 > > > >=20 > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > one AMSK is a > > > > requirements. What if we need to create multiple AMSKs=20 > > and that at=20 > > > > multiple occassions? > > > >=20 > > > >=20 > > > >=20 > > > > Well, actually, lower layer authenticator implementation > > > should expect > > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > > authenticator or (MSK,AMSK) in the case EAP method is=20 > executed by=20 > > > > backend authentication server. If it receives (MSK,EMSK) > > > should create > > >=20 > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > all, correct? > > >=20 > > > [Joe] Not really, strictly speaking the lower layer=20 > > shouldn't expect=20 > > > to receive the EMSK as that would break mode independence. An=20 > > > architectural description should not have the lower layer=20 > receiving=20 > > > the keys. From a supplicant perspective it must appear the same=20 > > > whether an external EAP-Server or a collocated EAP server=20 > is used. =20 > > > Now I don't know what is going on inside your box, it=20 > could all be=20 > > > monolithic when a internal EAP server is used but that=20 > shouldn't be=20 > > > visible to the external world. If I was interested in=20 > > cryptographic=20 > > > module separation I might not be too happy if you shared=20 > > the EMSK with=20 > > > the lower layer. > > >=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/eap > > > >=20 > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > >=20 > > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 12:41:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJiD-0005s6-My for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:41:37 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJiD-0002xu-B2 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:41:37 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 03D28430071 for ; Mon, 6 Mar 2006 09:41:37 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9F2BA4300C0 for ; Mon, 6 Mar 2006 09:41:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8CEED398046 for ; Mon, 6 Mar 2006 09:41:21 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 37B6039801A for ; Mon, 6 Mar 2006 09:41:11 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 09:41:11 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="412818879:sNHT31591804" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26HfBGv014731; Mon, 6 Mar 2006 09:41:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 09:48:03 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F0B@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAOOfJsABTcvOwADegfWA= From: "Salowey, Joe" To: "Avi Lior" , "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >=20 > Hi Madjid=20 >=20 > Seems that there a lot of good reasons for keeping EMSK=20 > around after it > is used to generate AMSKs. Hopefully everyone gets that. >=20 [Joe] No. After the AMSKs are generated what are you going to do with the EMSK? The purpos of the EMSK is to generate AMSKs. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 12:59:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJzL-0003Ln-FH for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:59:19 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJzK-0003Zy-0i for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 12:59:19 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 790BF430071 for ; Mon, 6 Mar 2006 09:59:17 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C805C430054 for ; Mon, 6 Mar 2006 09:59:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B6DF680C0FE for ; Mon, 6 Mar 2006 09:59:03 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 935C880C106 for ; Mon, 6 Mar 2006 09:59:01 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 09:58:58 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="412826216:sNHT514965972" 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 k26Hww7T013157; Mon, 6 Mar 2006 09:58:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 10:05:50 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F24@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwADnYKGAAi0YY4A== From: "Salowey, Joe" To: "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 =20 > Madjid>>I guess the number of people who are not sure about definition > of AAA layer is more than one :) > Joking aside, what is your reason what not making EMSK available to > lower layer, while doing so for MSK is ok? What is the fundamental > difference. > >=20 [Joe] If you pass the EMSK to the lower layer it becomes effectively the same as the MSK. If you want use the EMSK to key an independent application that uses a different authenticator the security of that application becomes completely dependent upon the lower layer its authenticator. =20 > > In both cases we require deletion of EMSK after generation of AMSK,=20 > > why? > >=20 > [Joe] To minimize the chance of exposure of the EMSK. Why do you need > to cache it? Could you generate and cache an AMSK instead? =20 >=20 > Madjid>>because a priori I cannot know how many AMSKs I may=20 > need later. > An application may pop up later that needs keying or I move to a > different domain that may require a new AMSK, but I cannot anticipate > the move ahead of time... >=20 [Joe] A different application I may understand although it seems the system typically knows the applications that are in use. If you don't I'm not sure how can authorize the distribution of keys. For the handoff case consider deriving an Handoff AMSK from the EMSK. This handoff AMSK becomes the root of all keys used for handoff. When you move you derive a key from the handoff AMSK.=20 >=20 > > Thanks, > >=20 > > Madjid > >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Wednesday, March 01, 2006 5:17 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1=20 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > To: Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > Madjid>>Again, why is deletion of EMSK after generation of > > > one AMSK is a > > > requirements. What if we need to create multiple AMSKs=20 > and that at=20 > > > multiple occassions? > > >=20 > > >=20 > > >=20 > > > Well, actually, lower layer authenticator implementation > > should expect > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > authenticator or (MSK,AMSK) in the case EAP method is executed by=20 > > > backend authentication server. If it receives (MSK,EMSK) > > should create > >=20 > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > all, correct? > >=20 > > [Joe] Not really, strictly speaking the lower layer=20 > shouldn't expect=20 > > to receive the EMSK as that would break mode independence. An=20 > > architectural description should not have the lower layer receiving=20 > > the keys. From a supplicant perspective it must appear the same=20 > > whether an external EAP-Server or a collocated EAP server is used. =20 > > Now I don't know what is going on inside your box, it could all be=20 > > monolithic when a internal EAP server is used but that shouldn't be=20 > > visible to the external world. If I was interested in=20 > cryptographic=20 > > module separation I might not be too happy if you shared=20 > the EMSK with >=20 > > the lower layer. > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 13:05:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGK5B-00087a-0c for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:05:21 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGK5A-0003ix-Kp for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:05:21 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 477134300E0 for ; Mon, 6 Mar 2006 10:05:20 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 266AE430054 for ; Mon, 6 Mar 2006 10:05:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 11868398018 for ; Mon, 6 Mar 2006 10:05:04 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 45836398015 for ; Mon, 6 Mar 2006 10:05:01 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 10:05:02 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="412828989:sNHT32669632" 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 k26I517T020581; Mon, 6 Mar 2006 10:05:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Mon, 6 Mar 2006 10:11:54 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F2C@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK Thread-Index: AcY/DIgjJCx8sPCpTe6nAGYu1InrjgCO1sbQ From: "Salowey, Joe" To: "Rafa Marin Lopez" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f =20 > For example (RFC 4137): >=20 >=20 > My question is : is it expected another interface (different=20 > than "aaaEapKeyData (EAP key)") to provide keys to AAA=20 > server? or could AAA server use for example something like m.getKey() > to obtain a particular key from EAP method?. >=20 [Joe] I don't think the EAP state machine took into acount EMSK usage. I would expect there would need to be an interface for retrieving AMSKs. > >but given the choices my answer > >is the EAP method layer.=20 > > =20 > > > In that case, why would EAP method need to export EMSK?. >=20 [Joe] It wouldn't. =20 > Thanks. >=20 > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 13:07:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGK7W-0008R4-HT for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:07:46 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGK7W-0003n5-4d for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:07:46 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C459843007C for ; Mon, 6 Mar 2006 10:07:45 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E4CEA430054 for ; Mon, 6 Mar 2006 10:07:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D335980C0F5 for ; Mon, 6 Mar 2006 10:07:19 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id F2D9380C005 for ; Mon, 6 Mar 2006 10:07:17 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 06 Mar 2006 10:07:17 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="312017579:sNHT148913230" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26I7HGv008896; Mon, 6 Mar 2006 10:07:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 337: Removal of Appendix A Date: Mon, 6 Mar 2006 10:14:10 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F2E@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Issue 337: Removal of Appendix A Thread-Index: AcZBBLI8Avx6UXMeQlqZUENrkha4RAARBZHA From: "Salowey, Joe" To: "Jari Arkko" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Sounds good.=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 06, 2006 1:52 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Issue 337: Removal of Appendix A >=20 > Right. Very good. >=20 > Bernard Aboba wrote: >=20 > > Issue 337: Removal of Appendix A > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date Submitted: February 25, 2006 > > Reference: http://lists.frascone.com/pipermail/eap/msg03993.html > > Document: KEYING-09 > > Comment type: E > > Priority: 1 > > Section: Appendix A > > Rationale/Explanation of issue: > > > > The material in Appendix A has now been included in RFC=20 > 2716bis. As a=20 > > result, it is no longer needed in the EAP Keying Framework. It is=20 > > recommended that this Appendix be deleted. > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 13:08:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGK8L-0000MK-14 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:08:37 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGK8K-0003on-Js for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:08:37 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 453A94300BE for ; Mon, 6 Mar 2006 10:08:36 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 87C48430071 for ; Mon, 6 Mar 2006 10:07:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7BCCF80C0F6 for ; Mon, 6 Mar 2006 10:07:44 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 7B9F380C005 for ; Mon, 6 Mar 2006 10:07:43 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 10:07:43 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="412830251:sNHT468281780" 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 k26I7h7T023296; Mon, 6 Mar 2006 10:07:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed Resolution to Issue 326: Identifiers Date: Mon, 6 Mar 2006 10:14:35 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F30@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 326: Identifiers Thread-Index: AcZA1TapJa1dz4DWS1GPDFju6vuicAAc6OcA From: "Salowey, Joe" To: "Bernard Aboba" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 OK=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Sunday, March 05, 2006 8:12 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 326: Identifiers >=20 > The text of Issue 326 is enclosed below. The proposed=20 > resolution is as=20 > follows: >=20 > In Section 1, change: >=20 > "The combination of the Peer-ID and Server-ID uniquely specifies the > endpoints of the EAP method exchange." >=20 > To: >=20 > "The combination of the Peer-ID and Server-ID may uniquely specify the > endpoints of the EAP method exchange when they are provided." >=20 > -------------------------------------------------------------- > ------------------------------------------ > Issue 326: Identifiers > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: December 1, 2005 > Reference: > Document: Keying-08 > Comment type: T > Priority: 1 > Section: 1 > Rationale/Explanation of issue: >=20 > " EAP methods also MAY export method-specific peer and server > identifiers (peer-ID and server-ID), a method-specific EAP > conversation identifier known as the Method-ID, and the lifetime of > the exported keys, known the Key-Lifetime. EAP methods MAY also > support the import and export of Channel Bindings. New EAP method > specifications MUST define the Peer-ID, Server-ID and=20 > Method-ID. The > combination of the Peer-ID and Server-ID uniquely specifies the > endpoints of the EAP method exchange." >=20 > It seems that additional data associated with the identity should be > exported to satisfy section 1.3. Suggestion is to add this and call > them identity attributes. >=20 > In this paragraph it states that the "Peer-ID and Server-ID uniquely > specifies the=A0=A0endpoints of the EAP method exchange", however=20 > further down=20 > it states > that these quantities may be null. This is contradictory. Suggested > modification to above text: >=20 > "The combination of the Peer-ID and Server-ID may uniquely specify the > endpoints of the EAP method exchange if the method supports=20 > unique IDs." >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 13:34:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKX0-0005d1-5C for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:34:06 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKWy-0004xb-D8 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:34:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 46C3A4300E8 for ; Mon, 6 Mar 2006 10:34:03 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BC07E430054 for ; Mon, 6 Mar 2006 10:33:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AEE9980C100 for ; Mon, 6 Mar 2006 10:33:47 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id B99F780C0F3 for ; Mon, 6 Mar 2006 10:33:45 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 13:36:25 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAw3LJAAAB6n2w From: "Avi Lior" To: "Salowey, Joe" , "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Hi Joe, I have something to say about both your replies to I included them together. >=20 > Hi Madjid >=20 > Seems that there a lot of good reasons for keeping EMSK around after=20 > it is used to generate AMSKs. Hopefully everyone gets that. >=20 [Joe] No. After the AMSKs are generated what are you going to do with the EMSK? The purpos of the EMSK is to generate AMSKs. =20 I think it is sufficient to say that exactly what you said: "The purpose of the EMSK is to generate AMSKs." Why should we generate all the AMSKs at once? A session may have several applications that may require AMSK. Some applications will be used 100% of the time, some application will be used rarely. Why should an implmeentation genrate an AMSK and cache it just in case it will need the key? That doesn't make sense. > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Monday, March 06, 2006 12:46 PM > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;=20 > Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, March 02, 2006 12:16 PM > > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin=20 > Lopez; Bernard=20 > > Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Hi Joe and Madjid, > >=20 > > The only reason for caching the EMSK is if you have to generate an=20 > > AMSK for another application associated with the current session. > >=20 > > So the question is do you have to generate all possible=20 > AMSKs and then=20 > > delete the EMSK or can you generate the AMSKs as needed? > >=20 > [Joe] I understand that there may be need for caching of=20 > certain quantities. I think Jari explained it well in a=20 > separate message. In my opinion you should try to identify=20 > the applications in use and the keys needed as early as=20 > possible. =20 I disagree. I think from a resource point of view we should not genrate keys for something that we may not be using. At any rate this needs to be an implmeentation choice and we should not prohibit this choice in a standard. > If this is not possible then caching of the MSK=20 > may be necessary. =20 I think you mean EMSK not MSK. Right? If yes, we agree then caching of EMSK may be necessary. Great!!! I don't think we should write a specification that MUST require an implmeentation to dervie all the keys that it is necessary on the chance that the keys may be needed. =20 I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and MUST NOT be transported out of the EAP Authentication Server layer. > Do we have examples where the caching of=20 > the EMSK is necessary. =20 What if I don't have an example today? Does that mean that in the future I won't? or that somewhere in the world someone does have such a need? > In the case where key caching is used=20 > the cache needs to be managed. If we are caching EMSKs then=20 > the document that describes EMSK usage must describe how key=20 > cache can be managed.=20 I agree. =20 >=20 > > Finally I have an slight issue with the statement that a=20 > KEY should be=20 > > deleted so that it wont be used for other purposes. I find that=20 > > statements like that are an over specification. What makes anyone=20 > > think that making a statement that "X should/must be=20 > deleted" is going=20 > > to be taken more seriously then "X should/must only be used for=20 > > purpose X and should/must not be transported out of Y"? > >=20 > > I think that whether it gets deleted or not is an implementation=20 > > issue. > >=20 >=20 > [Joe] The goal of the architecture is to prevent the re-use=20 > of keys for multiple different purposes. I agree that this=20 > is not necessarily the same a deletion. It is very important=20 > that keys derived from the EMSK don't collide purposes across=20 > applications. =20 I agree and therefore lets stick to the important issue and drop the deletion argument. The important issue being that EMSK shall be used for AMSK derivation and for no other purpose. > What happens in a particular AMSK branch of=20 > the key hierarchy is not necessarily as important since this=20 > branch is cryptographically separated from the rest of the=20 > system through the AMSK derivation. I think the current text=20 > could probably do better in motivating why it is good=20 > practice to delete keys. =20 I don't think we need to talk about key deletion at all, except when it comes to the key's end-of-life or end of session. I think we need to stress exactly what you said. =20 > > Finally if we insist on saying that X must be deleted we=20 > should really=20 > > say that X must be securely deleted. There is a difference. > > When a key > > is securely deleted the software takes extra care that the memory=20 > > location containing the key is first erased before the=20 > memory location=20 > > is freed to the heap. Perhaps we can state that somewhere. > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Thursday, March 02, 2006 2:49 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, March 02, 2006 8:44 AM > > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > Hi Joe, > > > >=20 > > > > Thanks for the email. I think you responded to the old > > piece of the > > > > email from Rafa and I am to blame for causing that > > confusion, as I > > > > kept that part to provide context. > > > > Again, my question was why an entity needs to delete EMSK after=20 > > > > generating the first AMSK (or first set of AMSKs?)? This > > > seems to be > > > > the requirement regardless of two options: > > > >=20 > > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > > > request from > > > > AAA layer, delete EMSK Immediately (this means EAP layer > > must have > > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > > 2) push EMSK down to AAA layer at backend server, create > > > AMSK at AAA > > > > layer and delete EMSK immediately (this means AAA layer=20 > must have > > > > KDFs) > > > > > > > [Joe] If the AAA layer contains the AAA client and AAA=20 > server then=20 > > > the EMSK should not be available to this layer, if the AAA layer=20 > > > means something else then I don't know about (1). > > > The AMSK should be generated in the EAP and exported, option (2). > > > =20 > > > >=20 > > > > In both cases we require deletion of EMSK after > > generation of AMSK, > > > > why? > > > >=20 > > > [Joe] To minimize the chance of exposure of the EMSK. Why do you=20 > > > need to cache it? Could you generate and cache an AMSK > > instead? =20 > > >=20 > > >=20 > > > > Thanks, > > > >=20 > > > > Madjid > > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10 > > > > >=20 > > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > > one AMSK is a > > > > > requirements. What if we need to create multiple AMSKs > > > and that at > > > > > multiple occassions? > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Well, actually, lower layer authenticator implementation > > > > should expect > > > > > (MSK,EMSK) in the case EAP method is executed by the=20 > standalone=20 > > > > > authenticator or (MSK,AMSK) in the case EAP method is > > executed by > > > > > backend authentication server. If it receives (MSK,EMSK) > > > > should create > > > >=20 > > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > > all, correct? > > > >=20 > > > > [Joe] Not really, strictly speaking the lower layer > > > shouldn't expect > > > > to receive the EMSK as that would break mode independence. An=20 > > > > architectural description should not have the lower layer > > receiving > > > > the keys. From a supplicant perspective it must appear the same=20 > > > > whether an external EAP-Server or a collocated EAP server > > is used. =20 > > > > Now I don't know what is going on inside your box, it > > could all be > > > > monolithic when a internal EAP server is used but that > > shouldn't be > > > > visible to the external world. If I was interested in > > > cryptographic > > > > module separation I might not be too happy if you shared > > > the EMSK with > > > > the lower layer. > > > >=20 > > > > >=20 > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, > > please visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > >=20 > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > >=20 > > > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 13:50:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKmc-0002O8-49 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:50:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKma-0005Lb-Aw for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 13:50:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D2DB84300D2 for ; Mon, 6 Mar 2006 10:50:11 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9B95A430054 for ; Mon, 6 Mar 2006 10:49:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 844A180C103 for ; Mon, 6 Mar 2006 10:49:53 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 65D5A80C0F3 for ; Mon, 6 Mar 2006 10:49:52 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Mar 2006 10:49:53 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="312027764:sNHT39222060" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k26Inpw1019440; Mon, 6 Mar 2006 10:49:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 10:56:44 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32F58@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAw3LJAAAB6n2wAACuw/A= From: "Salowey, Joe" To: "Avi Lior" , "Nakhjiri Madjid-MNAKHJI1" , "Rafa Marin Lopez" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Monday, March 06, 2006 10:36 AM > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;=20 > Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Joe, >=20 > I have something to say about both your replies to I included them > together. >=20 >=20 > >=20 > > Hi Madjid > >=20 > > Seems that there a lot of good reasons for keeping EMSK=20 > around after=20 > > it is used to generate AMSKs. Hopefully everyone gets that. > >=20 > [Joe] No. After the AMSKs are generated what are you going to do with > the EMSK? The purpos of the EMSK is to generate AMSKs. =20 >=20 > I think it is sufficient to say that exactly what you said:=20 > "The purpose > of the EMSK is to generate AMSKs." >=20 [Joe] OK great. SO in the above you meant keeping the EMSK around to generate AMSKs after the EAP authentication transaction has completed.=20 > Why should we generate all the AMSKs at once? A session may have > several applications that may require AMSK. Some applications will be > used 100% of the time, some application will be used rarely. =20 > Why should > an implmeentation genrate an AMSK and cache it just in case=20 > it will need > the key? That doesn't make sense. >=20 [Joe] OK so as an optimization an entity can cache the EMSK so it could generate the AMSK "just in time". I'm not sure how much of an optimization would be, but I suppose there could be a few applications that use this mechanism. If we do this we need to manage the cache, how are entries identified, so they can be retrieved and deleted. We have a key name so the key can be identified, although there may be an issue if there are multiple caches as to which cache contains the right keys.=20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Monday, March 06, 2006 12:46 PM > > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;=20 > > Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Thursday, March 02, 2006 12:16 PM > > > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin=20 > > Lopez; Bernard=20 > > > Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Hi Joe and Madjid, > > >=20 > > > The only reason for caching the EMSK is if you have to=20 > generate an=20 > > > AMSK for another application associated with the current session. > > >=20 > > > So the question is do you have to generate all possible=20 > > AMSKs and then=20 > > > delete the EMSK or can you generate the AMSKs as needed? > > >=20 > > [Joe] I understand that there may be need for caching of=20 > > certain quantities. I think Jari explained it well in a=20 > > separate message. In my opinion you should try to identify=20 > > the applications in use and the keys needed as early as=20 > > possible. =20 > I disagree. I think from a resource point of view we should=20 > not genrate > keys for something that we may not be using. At any rate=20 > this needs to > be an implmeentation choice and we should not prohibit this=20 > choice in a > standard. >=20 > > If this is not possible then caching of the MSK=20 > > may be necessary. =20 >=20 > I think you mean EMSK not MSK. Right? >=20 > If yes, we agree then caching of EMSK may be necessary. Great!!! >=20 > I don't think we should write a specification that MUST require an > implmeentation to dervie all the keys that it is necessary on=20 > the chance > that the keys may be needed. =20 >=20 > I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and > MUST NOT be transported out of the EAP Authentication Server layer. >=20 > > Do we have examples where the caching of=20 > > the EMSK is necessary. =20 >=20 > What if I don't have an example today? Does that mean that in the > future I won't? or that somewhere in the world someone does=20 > have such a > need? >=20 > > In the case where key caching is used=20 > > the cache needs to be managed. If we are caching EMSKs then=20 > > the document that describes EMSK usage must describe how key=20 > > cache can be managed.=20 >=20 > I agree. > =20 > >=20 > > > Finally I have an slight issue with the statement that a=20 > > KEY should be=20 > > > deleted so that it wont be used for other purposes. I find that=20 > > > statements like that are an over specification. What=20 > makes anyone=20 > > > think that making a statement that "X should/must be=20 > > deleted" is going=20 > > > to be taken more seriously then "X should/must only be used for=20 > > > purpose X and should/must not be transported out of Y"? > > >=20 > > > I think that whether it gets deleted or not is an implementation=20 > > > issue. > > >=20 > >=20 > > [Joe] The goal of the architecture is to prevent the re-use=20 > > of keys for multiple different purposes. I agree that this=20 > > is not necessarily the same a deletion. It is very important=20 > > that keys derived from the EMSK don't collide purposes across=20 > > applications. =20 >=20 > I agree and therefore lets stick to the important issue and drop the > deletion argument. The important issue being that EMSK shall be used > for AMSK derivation and for no other purpose. >=20 > > What happens in a particular AMSK branch of=20 > > the key hierarchy is not necessarily as important since this=20 > > branch is cryptographically separated from the rest of the=20 > > system through the AMSK derivation. I think the current text=20 > > could probably do better in motivating why it is good=20 > > practice to delete keys. =20 >=20 > I don't think we need to talk about key deletion at all,=20 > except when it > comes to the key's end-of-life or end of session. I think we need to > stress exactly what you said. >=20 > =20 > > > Finally if we insist on saying that X must be deleted we=20 > > should really=20 > > > say that X must be securely deleted. There is a difference. > > > When a key > > > is securely deleted the software takes extra care that the memory=20 > > > location containing the key is first erased before the=20 > > memory location=20 > > > is freed to the heap. Perhaps we can state that somewhere. > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Thursday, March 02, 2006 2:49 PM > > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, March 02, 2006 8:44 AM > > > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > Hi Joe, > > > > >=20 > > > > > Thanks for the email. I think you responded to the old > > > piece of the > > > > > email from Rafa and I am to blame for causing that > > > confusion, as I > > > > > kept that part to provide context. > > > > > Again, my question was why an entity needs to delete=20 > EMSK after=20 > > > > > generating the first AMSK (or first set of AMSKs?)? This > > > > seems to be > > > > > the requirement regardless of two options: > > > > >=20 > > > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > > > > request from > > > > > AAA layer, delete EMSK Immediately (this means EAP layer > > > must have > > > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > > > 2) push EMSK down to AAA layer at backend server, create > > > > AMSK at AAA > > > > > layer and delete EMSK immediately (this means AAA layer=20 > > must have > > > > > KDFs) > > > > > > > > > [Joe] If the AAA layer contains the AAA client and AAA=20 > > server then=20 > > > > the EMSK should not be available to this layer, if the=20 > AAA layer=20 > > > > means something else then I don't know about (1). > > > > The AMSK should be generated in the EAP and exported,=20 > option (2). > > > > =20 > > > > >=20 > > > > > In both cases we require deletion of EMSK after > > > generation of AMSK, > > > > > why? > > > > >=20 > > > > [Joe] To minimize the chance of exposure of the EMSK. =20 > Why do you=20 > > > > need to cache it? Could you generate and cache an AMSK > > > instead? =20 > > > >=20 > > > >=20 > > > > > Thanks, > > > > >=20 > > > > > Madjid > > > > >=20 > > > > > -----Original Message----- > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > > > Cc: eap@frascone.com > > > > > > Subject: RE: [eap] Strawman -10 > > > > > >=20 > > > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > > > one AMSK is a > > > > > > requirements. What if we need to create multiple AMSKs > > > > and that at > > > > > > multiple occassions? > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Well, actually, lower layer authenticator implementation > > > > > should expect > > > > > > (MSK,EMSK) in the case EAP method is executed by the=20 > > standalone=20 > > > > > > authenticator or (MSK,AMSK) in the case EAP method is > > > executed by > > > > > > backend authentication server. If it receives (MSK,EMSK) > > > > > should create > > > > >=20 > > > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > > > all, correct? > > > > >=20 > > > > > [Joe] Not really, strictly speaking the lower layer > > > > shouldn't expect > > > > > to receive the EMSK as that would break mode=20 > independence. An=20 > > > > > architectural description should not have the lower layer > > > receiving > > > > > the keys. From a supplicant perspective it must=20 > appear the same=20 > > > > > whether an external EAP-Server or a collocated EAP server > > > is used. =20 > > > > > Now I don't know what is going on inside your box, it > > > could all be > > > > > monolithic when a internal EAP server is used but that > > > shouldn't be > > > > > visible to the external world. If I was interested in > > > > cryptographic > > > > > module separation I might not be too happy if you shared > > > > the EMSK with > > > > > the lower layer. > > > > >=20 > > > > > >=20 > > > _________________________________________________________________ > > > > > > To unsubscribe or modify your subscription options, > > > please visit: > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > >=20 > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > >=20 > > > > >=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/eap > > > >=20 > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 14:05:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGL1C-00079a-7R for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:05:18 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGL1A-0005yJ-PH for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:05:18 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0EDDA430054 for ; Mon, 6 Mar 2006 11:05:16 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1E82F430054 for ; Mon, 6 Mar 2006 11:04:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0FD3F80C0F6 for ; Mon, 6 Mar 2006 11:04:58 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id BAAEA80C109 for ; Mon, 6 Mar 2006 11:04:53 -0800 (PST) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k26JKEVu016007 for ; Mon, 6 Mar 2006 12:20:18 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k26JJn7C004758 for ; Mon, 6 Mar 2006 13:19:49 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 14:04:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcZAi0NVJifmUb4uSoO458FLrhd0NwAxNMag From: "Nakhjiri Madjid-MNAKHJI1" To: "Jari Arkko" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Hi Jari, I am not saying you have to have multiple AMSKs for multiple technologies, but I was providing an example as a case where people may want to. I don't happen to be one of them, at least not for a single AAA domain. Anyhow, as far as " MUST be deleted after " and " MUST be only used for ", I agree there are no differences IF and ONLY IF needs to happen only once. I.e. if you use EMSK for generation of multiple AMSKs at various times, then EMSK should not be deleted. You can still require that EMSK is only used for authorized AMSK generation, under whatever conditions that are set. But you cannot create AMSK later after EMSK is deleted. Madjid=20 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Sunday, March 05, 2006 1:30 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba; eap@frascone.com Subject: Re: [eap] Strawman -10/EMSK deletion requirement? Madjid, Avi, >The only reason for caching the EMSK is if you have to generate an AMSK >for another application associated with the current session. > >Madjid>> Thank you for clarification. Another example may be roaming to >another access technology!! > >So the question is do you have to generate all possible AMSKs and then=20 >delete the EMSK or can you generate the AMSKs as needed? > >Madjid>>i.e. keep EMSK for future AMSK generation. The first option=20 >Madjid>>will >create the need for running EAP again. > > =20 > We have discussed this before... I do not see an issue for handoffs to another access. If your AAA server supports this then it derives AMSK_ho_root from EMSK, deletes EMSK but keeps the derived key. Once a need to do a handoff arrives, you derive AMSK_ho_key1 from AMSK_ho_root, next time you will derive AMSK_ho_key2, etc. Having said that, I do agree with Avi that there's really no substantial difference between " MUST be deleted after " and " MUST be only used for ", except maybe some implementation note describing that it would be a good idea to securely delete the value once you know that is done. But part of this debate is really not about whether the key should be deleted, but rather about whether we know the applications a priori. I think there are practical and security reasons why it is a good idea to set a requirement that the applications are known a priori. First of all, there are no surprises to the AAA server; it needs have specific authorization to serve a particular application. (Possibly even specific code.) Secondly, as we are currently in a world where the AAA servers cache no keys at all, we need to avoid a situation where AAA servers end up storing a lot of key state and have no way of knowing when it is needed. Finally, security-wise I want to know what my EAP authentication somewhere means. I, as the end user, do not want surprises. It is better to limit the set of applications of the keys at the beginning. Note that if you want, you can set up state for handoff/SIP/MIP even if you do not know they will actually be used; you set the state and keys based on the user's authorization profile. Based on the above, I still like the design where we know the possible applications (and AMSKs) at the first authentication. But we could write the text slightly differently, based on what you Avi suggested. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 14:06:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGL2d-0008QF-S1 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:06:47 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGL2d-00066q-9P for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:06:47 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E7A174300AA for ; Mon, 6 Mar 2006 11:06:46 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 591574300B3 for ; Mon, 6 Mar 2006 11:05:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 492AF39802E for ; Mon, 6 Mar 2006 11:05:20 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id DAE4439803E for ; Mon, 6 Mar 2006 11:05:17 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k26JKgGK016151 for ; Mon, 6 Mar 2006 12:20:42 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k26JHaEd020940 for ; Mon, 6 Mar 2006 13:17:37 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 14:05:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAOOfJsABTcvOwADqYWxA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Avi Lior" , "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Exactly my point. Thank you.=20 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Sunday, March 05, 2006 9:09 AM To: Nakhjiri Madjid-MNAKHJI1; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Hi Madjid=20 Seems that there a lot of good reasons for keeping EMSK around after it is used to generate AMSKs. Hopefully everyone gets that. > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, March 03, 2006 6:21 PM > To: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Avi, >=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Thursday, March 02, 2006 2:16 PM > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard=20 > Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Joe and Madjid, >=20 > The only reason for caching the EMSK is if you have to generate an=20 > AMSK for another application associated with the current session. >=20 > Madjid>> Thank you for clarification. Another example may be > roaming to > another access technology!! >=20 > So the question is do you have to generate all possible AMSKs and then > delete the EMSK or can you generate the AMSKs as needed? >=20 > Madjid>>i.e. keep EMSK for future AMSK generation. The first > option will > create the need for running EAP again. >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Thursday, March 02, 2006 2:49 PM > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Thursday, March 02, 2006 8:44 AM > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Hi Joe, > > >=20 > > > Thanks for the email. I think you responded to the old > piece of the > > > email from Rafa and I am to blame for causing that > confusion, as I > > > kept that part to provide context. > > > Again, my question was why an entity needs to delete EMSK after=20 > > > generating the first AMSK (or first set of AMSKs?)? This > > seems to be > > > the requirement regardless of two options: > > >=20 > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > > request from > > > AAA layer, delete EMSK Immediately (this means EAP layer > must have > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > 2) push EMSK down to AAA layer at backend server, create > > AMSK at AAA > > > layer and delete EMSK immediately (this means AAA layer must have > > > KDFs) > > > > > [Joe] If the AAA layer contains the AAA client and AAA > server then the >=20 > > EMSK should not be available to this layer, if the AAA layer means=20 > > something else then I don't know about (1). > > The AMSK should be generated in the EAP and exported, option (2). > > =20 > > >=20 > > > In both cases we require deletion of EMSK after > generation of AMSK, > > > why? > > >=20 > > [Joe] To minimize the chance of exposure of the EMSK. Why > do you need >=20 > > to cache it? Could you generate and cache an AMSK instead? > >=20 > >=20 > > > Thanks, > > >=20 > > > Madjid > > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10 > > > >=20 > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > one AMSK is a > > > > requirements. What if we need to create multiple AMSKs > > and that at > > > > multiple occassions? > > > >=20 > > > >=20 > > > >=20 > > > > Well, actually, lower layer authenticator implementation > > > should expect > > > > (MSK,EMSK) in the case EAP method is executed by the standalone=20 > > > > authenticator or (MSK,AMSK) in the case EAP method is > executed by > > > > backend authentication server. If it receives (MSK,EMSK) > > > should create > > >=20 > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > all, correct? > > >=20 > > > [Joe] Not really, strictly speaking the lower layer > > shouldn't expect > > > to receive the EMSK as that would break mode independence. An=20 > > > architectural description should not have the lower layer > receiving > > > the keys. From a supplicant perspective it must appear the same=20 > > > whether an external EAP-Server or a collocated EAP server is used. > > > Now I don't know what is going on inside your box, it > could all be > > > monolithic when a internal EAP server is used but that > shouldn't be > > > visible to the external world. If I was interested in > > cryptographic > > > module separation I might not be too happy if you shared > > the EMSK with > > > the lower layer. > > >=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/eap > > > >=20 > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > >=20 > > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 14:07:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGL39-0000HF-Ux for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:07:19 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGL39-00067y-Is for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:07:19 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3D5AB430067 for ; Mon, 6 Mar 2006 11:07:19 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2F6F1430067 for ; Mon, 6 Mar 2006 11:05:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 273E880C11C for ; Mon, 6 Mar 2006 11:05:43 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id 10A7880C0F6 for ; Mon, 6 Mar 2006 11:05:27 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4EB2889852; Mon, 6 Mar 2006 21:05:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 067CC8982D; Mon, 6 Mar 2006 21:05:25 +0200 (EET) Message-ID: <440C87F5.9090102@piuha.net> Date: Mon, 06 Mar 2006 21:05:25 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Avi, I understand that you feel strongly about the need to use the EMSK on a per-need basis. But I have some questions for you :-) 1. Ccan you explain what specific technical problem do you encounter with the proposal that I outlined in my e-mail, namely that you generate the AMSKs that you need, and that those AMSKs can be kept around and used for further generation of keys when the application in question needs more than one? Is it just the need to do unnecessary work for keys that may not be needed for this session? Or is there some functional difference? 2. Do you have a plan how to manage the cache at the AAA server side, if there is no agreement a priori that EMSKs and specific AMSKs are going to be needed? 3. Also, you wrote: >I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and > > What specific purpose did you have in mind for the EMSK? Do you plan to use the entire EMSK for some specific application you had in mind? What if other applications want to use it too? 4. And you wrote >MUST NOT be transported out of the EAP Authentication Server layer. > Ok. This is the issue that I wrote another e-mail about (the one with choices 1a, 1b, 2a, and 2b) -- can you comment on that e-mail what you want along with the rationale for your choice? Thanks, --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 14:30:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLPu-0001gZ-4A for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:30:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLPs-0006n8-G4 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:30:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EC4A44300BF for ; Mon, 6 Mar 2006 11:30:47 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B7B8E430054 for ; Mon, 6 Mar 2006 11:30:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A6E939802E for ; Mon, 6 Mar 2006 11:30:22 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 90FF239800C for ; Mon, 6 Mar 2006 11:30:19 -0800 (PST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k26JUGMs005050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 11:30:17 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k26JUEXG006112; Mon, 6 Mar 2006 11:30:16 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 11:30:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Mon, 6 Mar 2006 11:30:18 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB841B07FF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK Thread-Index: AcZBAYFl8iiqQvQFRfeO4L64EPwkHgAUCKbQ From: "Narayanan, Vidya" To: "Jari Arkko" , "Bernard Aboba" X-OriginalArrivalTime: 06 Mar 2006 19:30:14.0779 (UTC) FILETIME=[649E44B0:01C64154] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Hi Jari, Thanks for the much needed analysis on this topic. Please see some comments below. =20 >=20 >=20 > Here's some analysis of the server vs. lower-layer based EMSK=20 > processing approaches. >=20 > (1) In the server based approach we keep the EMSK in the=20 > server (perhaps just for a moment) and generate the AMSKs,=20 > which are given to the the different applications, such as=20 > fast handoff mechanisms. > The use of these applications goes via AAA, e.g., some kind=20 > of key requests or fast re-auth requests can be sent from=20 > NASes to the server. The AMSKs are derived using a KDF which=20 > is decided either (a) by a default plus optional negotiation=20 > in methods or (b) by lower layer negotiation and having AAA=20 > tell the server which KDF to use. >=20 > (2) In the lower-layer based EMSK processing approach, the=20 > EMSK is delivered to the authenticator along with the MSK. > KDF is selected either (a) by a default in EAP plus optional=20 > negotiation in methods, choice is communicated to the lower=20 > layer via AAA or (b) by lower layer negotiation alone. > The lower layer is responsible for all use of the AMSKs in a=20 > local context. That is, no AAA key requests are needed or possible. >=20 > Discussion about the chosen approach for EMSK use has so far=20 > appeared to assume 1a vs. 2b. Based on the above, it seems=20 > that the KDF negotiation may be a separate issue from who=20 > maintains the EMSK and calculates AMSKs. > In the following I'll try to analyze these issues. >=20 > The KDF negotiation is indeed problematic almost no matter=20 > what we do. Requiring new funtionality in methods is in=20 > practice often a non-starter; while we can develop new=20 > methods and update old ones, it is expected that most of=20 > current usage will continue to use the existing methods.=20 > Having a default does not help much either, if the default=20 > becomes broken in the near future. > But requiring new functionality in link layers it not always=20 > easy either. It would be easy when we are developing a new=20 > link layer and including some EMSK usage as a part of that.=20 > But if we were to use EMSK for some new function over 802.11,=20 > for instance, would there be enough incentive to extend=20 > 802.11 just to make this possible? >=20 > The choices and their implications are: >=20 > (a) Specified default, optional negotiation in EAP methods. >=20 > This implies an interface either from methods to the=20 > AAA/EAP server > code (for solution 1) or AAA protocol extensions for=20 > solution 2. >=20 > Changes in peers, servers, methods, possibly AAA protocols. >=20 > (b) Lower layer negotiation. >=20 > If used together with solution 1, implies AAA protocol=20 > extensions > to communicate the KDF. If used with solution 2, implies AAA > protocol extensions to carry the EMSK. > =20 > Changes in lower layers, AAA protocol. No changes in=20 > EAP or methods. >=20 > Based on this my current preference is (b). I'd be willing to=20 > accept (a), too. >=20 I am surprised that you are willing to accept (a) :) Given how many legacy methods are still in use, I'd strongly vote for (b) here. It is impractical to make changes to methods to accommodate the use of EMSK/AMSK. As you point out, what we pick here may depend on whether we pick (1) or (2) below - and (1) makes much more sense to me for reasons stated below.=20 > The choice between server or lower-layer based EMSK=20 > processing depends on security implications and ease of use=20 > for different purposes. > The choices are: >=20 > (1) Derive AMSKs at the EAP/AAA server. >=20 > Implies a AAA protocol extension to retrieve AMSKs. >=20 > Changes at the EAP/AAA server, authenticator. New, stateful > nature of the EAP/AAA server. >=20 > (2) Derive AMSKs at the lower layer. >=20 > Implies a AAA protocol extension to carry EMSK to the > authenticator. >=20 > Small changes at the EAP/AAA server, main functionality in > the authenticator. >=20 > Hard to see how other nodes than the authenticator would > actually use the AMSKs. Traditionally, NAS -> NAS communication > has not been easy compared to NAS -> AAA communication. >=20 > Based on this my current preference is (1). But its a close call. I agree that (1) makes more sense. In many cases, the AMSKs are slated for use to bootstrap protocols such as Mobile IP (actually, that seems to the most pressing practical need so far). So, if the EAP authenticator were to derive the AMSK, I can't envision an interface between, say a Mobile IP HA and an EAP authenticator to transport the AMSK. One can imagine a solution here, but this certainly complicates the model a whole lot more. It makes much more sense to me to have this in the EAP server so that the use of AMSKs could be more straightforward.=20 Also, it makes complete sense that an EAP-based means of bootstrapping other protocols such as Mobile IP are only used in AAA-based systems. So, having an SA between an arbitrary entity X (such as a MIP HA) and the AAA server for transport of keys makes sense (and this is a model that exists today). I don't see how (2) would be an option for the same case. I don't see a use for AMSKs (at least not yet) for the EAP authenticator itself.=20 If we took Mobile IP as an example, one could envision the peer seeking MIP bootstrapping as part of the EAP authentication, in reaction to which the EAP server may derive an AMSK. Whether this AMSK gets sent to the HA right away or gets cached in the EAP server (actually AAA server) until the HA asks for it is a separate question that needs to be answered. But, you already noted potential new stateful nature of the EAP/AAA server in (1) above - so, that would take care of the needs here.=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 14:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLrI-0005by-KY for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:59:08 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLrH-0007Kc-6N for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 14:59:08 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4824F4300CB for ; Mon, 6 Mar 2006 11:59:06 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8943F430054 for ; Mon, 6 Mar 2006 11:58:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6D72239803C for ; Mon, 6 Mar 2006 11:58:55 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id C399239803E for ; Mon, 6 Mar 2006 11:58:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 15:01:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBUWNdgFEznX46Sw+qpRyVyMFEHAABfKTg From: "Avi Lior" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hi Jari, These are similar to Joe's questions to I will just answer here. Please see inline.=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 06, 2006 2:05 PM > To: Avi Lior > Cc: eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Avi, >=20 > I understand that you feel strongly about the need to use the=20 > EMSK on a per-need basis. But I have some questions for you :-) >=20 > 1. Ccan you explain what specific technical problem do you=20 > encounter with the proposal that I outlined in my e-mail,=20 > namely that you generate the AMSKs that you need, and that=20 > those AMSKs can be kept around and used for further=20 > generation of keys when the application in question needs=20 > more than one? The AMSKs we be application specific right? For example, one application key for MIP keys, another for access to some other application like single sign-on to our corporate server etc... I don't have an issue with the AMSK's. >=20 > Is it just the need to do unnecessary work for keys that may=20 > not be needed for this session? Or is there some functional=20 > difference? It is basically this, how do I know which ones to generate during network access authentication? I could have lots of them. Also perhaps during this session the user requested access to a new application. I need a key now. Should I tear down the session just so I can get a new EMSK? > 2. Do you have a plan how to manage the cache at the AAA=20 > server side, if there is no agreement a priori that EMSKs and=20 > specific AMSKs are going to be needed? EMSK should be bound to a user session. When the user session goes away so should the EMSK. If the user session is reauthenticated so should the EMSK. > 3. Also, you wrote: >=20 > >I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and > > =20 > > > What specific purpose did you have in mind for the EMSK? Do=20 > you plan to use the entire EMSK for some specific application=20 > you had in mind? What if other applications want to use it too? EMSK MUST only be used for generating AMSKs. I would think that using EMSK for other purpsoses will weakent the EMSK and hence weaken the AMSKs etc... So this is a very bad thing to do. >=20 > 4. And you wrote >=20 > >MUST NOT be transported out of the EAP Authentication Server layer. > > > Ok. This is the issue that I wrote another e-mail about (the=20 > one with choices 1a, 1b, 2a, and 2b) -- can you comment on=20 > that e-mail what you want along with the rationale for your choice? I will go back to that email and comment. > Thanks, >=20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 15:43:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMYY-0004yc-Aq for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 15:43:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMYW-0000yr-R3 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 15:43:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 215F44300BE for ; Mon, 6 Mar 2006 12:43:48 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F2714430048 for ; Mon, 6 Mar 2006 12:43:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6BDC39803C for ; Mon, 6 Mar 2006 12:43:29 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id D856C398018 for ; Mon, 6 Mar 2006 12:43:26 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 06 Mar 2006 12:43:26 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26KhP7T001881; Mon, 6 Mar 2006 12:43:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Mon, 6 Mar 2006 12:50:18 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32FAC@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK Thread-Index: AcZBAm856jiCGhL2RTeJnJIMIr+OhgAWQ+fA From: "Salowey, Joe" To: "Jari Arkko" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Jari, Thanks for putting this together, but I think there is more to it than you describe. The approaches (1) and (2) have very different characteristics and do not provide equivalent protection for the EMSK. Passing the EMSK to the lower layer limits how it can be used because now it has been exposed to the lower layer. Therefore I think anything based on 2 is unacceptable. =20 More below=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 06, 2006 1:36 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] About use of EMSK >=20 >=20 > Here's some analysis of the server vs. lower-layer based > EMSK processing approaches. >=20 > (1) In the server based approach we keep the > EMSK in the server (perhaps just for a moment) > and generate the AMSKs, which are given to the the > different applications, such as fast handoff mechanisms. > The use of these applications goes via AAA, e.g., some kind > of key requests or fast re-auth requests can be sent from > NASes to the server. The AMSKs are derived using a KDF > which is decided either (a) by a default plus optional negotiation > in methods or (b) by lower layer negotiation and having AAA > tell the server which KDF to use. >=20 > (2) In the lower-layer based EMSK processing approach, the > EMSK is delivered to the authenticator along with the MSK. > KDF is selected either (a) by a default in EAP plus optional > negotiation in methods, choice is communicated to the > lower layer via AAA or (b) by lower layer negotiation alone. > The lower layer is responsible for all use of the AMSKs > in a local context. That is, no AAA key requests are needed > or possible. >=20 [Joe] Also the EMSK cannot be used securely for any purpose outside of the lower layer. I don't think (2) is a good choice. =20 > Discussion about the chosen approach for EMSK use has > so far appeared to assume 1a vs. 2b. Based on the above, > it seems that the KDF negotiation may be a separate > issue from who maintains the EMSK and calculates AMSKs. > In the following I'll try to analyze these issues. >=20 > The KDF negotiation is indeed problematic almost no > matter what we do. Requiring new funtionality in methods > is in practice often a non-starter; while we can develop > new methods and update old ones, it is expected that > most of current usage will continue to use the existing > methods. Having a default does not help much either, > if the default becomes broken in the near future. > But requiring new functionality in link layers it not > always easy either. It would be easy when we are developing > a new link layer and including some EMSK usage as a part > of that. But if we were to use EMSK for some new function > over 802.11, for instance, would there be enough incentive > to extend 802.11 just to make this possible? >=20 > The choices and their implications are: >=20 > (a) Specified default, optional negotiation in EAP methods. >=20 > This implies an interface either from methods to the=20 > AAA/EAP server > code (for solution 1) or AAA protocol extensions for=20 > solution 2. >=20 [Joe] Note that there doesn't necessarily have to be negotiation in the method. The method could specify a default. If the method does not specify a default then a mechanism independent default would come into play. =20 > Changes in peers, servers, methods, possibly AAA protocols. >=20 > (b) Lower layer negotiation. >=20 > If used together with solution 1, implies AAA protocol=20 > extensions > to communicate the KDF. If used with solution 2, implies AAA > protocol extensions to carry the EMSK. > =20 > Changes in lower layers, AAA protocol. No changes in=20 > EAP or methods. >=20 [Joe] Another side effect is that the lower layer then chooses the KDF for all other applications. The method knows best how to choose a key derivation method that is efficient and secure for its operation. If the method's key derivation scheme is not sufficient for an environment, then it is likely the method itself will not be usable for reasons beyond MSK derivation. In addition here the KDF name space must be coordinated. =20 > Based on this my current preference is (b). I'd be willing > to accept (a), too. >=20 [Joe] My choice would be (a) > The choice between server or lower-layer based EMSK processing > depends on security implications and ease of use for=20 > different purposes. > The choices are: >=20 > (1) Derive AMSKs at the EAP/AAA server. >=20 > Implies a AAA protocol extension to retrieve AMSKs. >=20 > Changes at the EAP/AAA server, authenticator. New, stateful > nature of the EAP/AAA server. >=20 > (2) Derive AMSKs at the lower layer. >=20 > Implies a AAA protocol extension to carry EMSK to the > authenticator. >=20 > Small changes at the EAP/AAA server, main functionality in > the authenticator. >=20 > Hard to see how other nodes than the authenticator would > actually use the AMSKs. Traditionally, NAS -> NAS communication > has not been easy compared to NAS -> AAA communication. >=20 [Joe] Because the EMSK, and therefore all the AMSKs, are known to the NAS the security properties of these two solutions are very different. =20 > Based on this my current preference is (1). But its a close > call. [Joe] I agree with (1) as the preference.=20 =20 > --Jari >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 15:45:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMaZ-0007AB-TM for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 15:45:55 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMaZ-00012g-Fz for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 15:45:55 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 288DC430054 for ; Mon, 6 Mar 2006 12:45:55 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 833F9430048 for ; Mon, 6 Mar 2006 12:45:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 76EC639803E for ; Mon, 6 Mar 2006 12:45:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 253F0398018 for ; Mon, 6 Mar 2006 12:45:32 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DF64189852; Mon, 6 Mar 2006 22:45:29 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8BEF38982D; Mon, 6 Mar 2006 22:45:29 +0200 (EET) Message-ID: <440C9F69.3080809@piuha.net> Date: Mon, 06 Mar 2006 22:45:29 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Avi Lior wrote: >>1. Ccan you explain what specific technical problem do you >>encounter with the proposal that I outlined in my e-mail, >>namely that you generate the AMSKs that you need, and that >>those AMSKs can be kept around and used for further >>generation of keys when the application in question needs >>more than one? >> >> > >The AMSKs we be application specific right? For example, one application >key for MIP keys, another for access to some other application like >single sign-on to our corporate server etc... > >I don't have an issue with the AMSK's. > > Right. Ok. >>Is it just the need to do unnecessary work for keys that may >>not be needed for this session? Or is there some functional >>difference? >> >> > >It is basically this, how do I know which ones to generate during >network access authentication? I could have lots of them. Also perhaps >during this session the user requested access to a new application. I >need a key now. Should I tear down the session just so I can get a new >EMSK? > > The latter should never happen. If we do the calculation of AMSKs a priori, then it needs to be something enabled by the user's profile. If he is authorized to day (say) access handoff, mobile IP, and some QoS exchange, then we'd generate three AMSKs for that user. >>2. Do you have a plan how to manage the cache at the AAA >>server side, if there is no agreement a priori that EMSKs and >>specific AMSKs are going to be needed? >> >> > >EMSK should be bound to a user session. When the user session goes away >so should the EMSK. If the user session is reauthenticated so should >the EMSK. > > Ok. This sounds reasonable. There may be still tradeoffs between keeping one EMSK for all sessions vs. keeping bunch of AMSKs for those sessions that have been authorized to do more than pure access. But its hard for me to quantify this tradeoff, given that we don't know how many applications we could in practice be talking about, and in particular we don't know what fraction of users would be authorized to use those applications. Just some, or would this be something that is by default turned on for everyone? >>3. Also, you wrote: >> >> >> >>>I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and >>> >>> >>> >>> >>What specific purpose did you have in mind for the EMSK? Do >>you plan to use the entire EMSK for some specific application >>you had in mind? What if other applications want to use it too? >> >> > >EMSK MUST only be used for generating AMSKs. I would think that using >EMSK for other purpsoses will weakent the EMSK and hence weaken the >AMSKs etc... So this is a very bad thing to do. > > Ok. Hmm... it seems that I misread your original comment. Sorry. But it seems that we agree on this. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 16:31:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNIu-0005Ld-QH for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:31:44 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNIs-0007tE-Fa for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:31:44 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D59D24300C1 for ; Mon, 6 Mar 2006 13:31:41 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7FA8D430054 for ; Mon, 6 Mar 2006 13:31:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 646EE398018 for ; Mon, 6 Mar 2006 13:31:27 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF48439802D for ; Mon, 6 Mar 2006 13:31:24 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 16:34:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9Jfw From: "Avi Lior" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi Jari, We seem to agree until we get here snip: Avi wrote: > >It is basically this, how do I know which ones to generate during > >network access authentication? I could have lots of them. =20 > Also perhaps > >during this session the user requested access to a new=20 > application. I > >need a key now. Should I tear down the session just so I=20 > can get a new > >EMSK? > > =20 > > Jari wrote: > The latter should never happen. If we do the calculation of=20 > AMSKs a priori, > then it needs to be something enabled by the user's profile. If he is > authorized to day (say) access handoff, mobile IP, and some=20 > QoS exchange, > then we'd generate three AMSKs for that user. Perhaps you missed my poorly stated point :-) What if the user is requesting access to a new application? which could also involve the modification of the user's profile.=20 If EMSK is not there, then what do I do? Restart the session? No. At anyrate I belive that there could be other use cases... I gave two reason why: Just-in-time; Dynamic-Application provisioning. > >>2. Do you have a plan how to manage the cache at the AAA=20 > >>server side, if there is no agreement a priori that EMSKs and=20 > >>specific AMSKs are going to be needed? > >> =20 > >> > > > >EMSK should be bound to a user session. When the user=20 > session goes away > >so should the EMSK. If the user session is reauthenticated so should > >the EMSK. > > =20 > > > Ok. This sounds reasonable. There may be still tradeoffs > between keeping one EMSK for all sessions vs. keeping bunch of > AMSKs for those sessions that have been authorized to do > more than pure access.=20 Hmmmmm... A session is an EAP session (which is one Access Session) and you should only have one EMSK for that session. AMSKs are dervied from the EMSK belong to that session. > But its hard for me to quantify this > tradeoff, given that we don't know how many applications we could > in practice be talking about, and in particular we don't know what > fraction of users would be authorized to use those applications.=20 > Just > some, or would this be something that is by default turned on for > everyone? IMO that would be deployement issue. We see a very immediate need for EMSK and AMSK today which will be used by everyone in the network -- and this is the MIP case, but other then that EMSK/AMSK is very very new. Wait until 3GPP/2 and OMA learn about it. =20 Avi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 16:57:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNiC-0008Ne-9j for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:57:52 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNiA-0001jE-Sp for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:57:52 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6D682430054 for ; Mon, 6 Mar 2006 13:57:50 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7CFE7430048 for ; Mon, 6 Mar 2006 13:57:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6576B80C112 for ; Mon, 6 Mar 2006 13:57:14 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id D04E480C005 for ; Mon, 6 Mar 2006 13:57:11 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2006 13:57:06 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="259909288:sNHT1389110462" 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 k26Lv57T021652; Mon, 6 Mar 2006 13:57:05 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 14:03:58 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B32FEE@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMA= From: "Salowey, Joe" To: "Avi Lior" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi Avi, =20 >=20 > Perhaps you missed my poorly stated point :-) >=20 > What if the user is requesting access to a new application?=20 > which could > also involve the modification of the user's profile.=20 > If EMSK is not there, then what do I do? Restart the session? No. >=20 > At anyrate I belive that there could be other use cases... I gave two > reason why: >=20 > Just-in-time; > Dynamic-Application provisioning. [Joe] Would you agree with the following: "For any specific application once the AMSK is generated for that application there is no requirement to cache the EMSK for that application, however there may be a need to cache the EMSK if the system requires other Masks to be generated. " =20 This makes the caching more of a system issue than an issue for one particular application. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 16:59:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNjW-0003Rc-Jc for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:59:14 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNNk-0008JE-QX for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 16:36:44 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMh1-0003AG-9U for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 15:52:43 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 04476430092 for ; Mon, 6 Mar 2006 12:52:32 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 33F56430048 for ; Mon, 6 Mar 2006 12:52:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1AC0B39804D for ; Mon, 6 Mar 2006 12:52:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4EF7D39803E for ; Mon, 6 Mar 2006 12:52:06 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA28089852; Mon, 6 Mar 2006 22:52:04 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 845078982D; Mon, 6 Mar 2006 22:52:04 +0200 (EET) Message-ID: <440CA0F4.9050803@piuha.net> Date: Mon, 06 Mar 2006 22:52:04 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [eap] About use of EMSK References: <7210B31550AC934A8637D6619739CE6906B32FAC@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906B32FAC@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Salowey, Joe wrote: >Jari, > >Thanks for putting this together, but I think there is more to it than >you describe. > I am SURE there is :-) >The approaches (1) and (2) have very different >characteristics and do not provide equivalent protection for the EMSK. > > Agreed. >Passing the EMSK to the lower layer limits how it can be used because >now it has been exposed to the lower layer. Therefore I think anything >based on 2 is unacceptable. > > Noted. >>(2) In the lower-layer based EMSK processing approach, the >>EMSK is delivered to the authenticator along with the MSK. >>KDF is selected either (a) by a default in EAP plus optional >>negotiation in methods, choice is communicated to the >>lower layer via AAA or (b) by lower layer negotiation alone. >>The lower layer is responsible for all use of the AMSKs >>in a local context. That is, no AAA key requests are needed >>or possible. >> >> >> >[Joe] Also the EMSK cannot be used securely for any purpose outside of >the lower layer. I don't think (2) is a good choice. > > Well, I think we should do (1) too. But I'm not sure we can rule out the use of EMSK for any other purpose even in (2). There's a security difference, yes. There's an even bigger difference in that I'm not at all sure how that would work with current AAA -- how would the AMSK get to whoever that needs it? But perhaps that's solvable... >>The choices and their implications are: >> >> (a) Specified default, optional negotiation in EAP methods. >> >> This implies an interface either from methods to the >>AAA/EAP server >> code (for solution 1) or AAA protocol extensions for >>solution 2. >> >> >> > >[Joe] Note that there doesn't necessarily have to be negotiation in the >method. The method could specify a default. If the method does not >specify a default then a mechanism independent default would come into >play. > > Right. >> Changes in peers, servers, methods, possibly AAA protocols. >> >> (b) Lower layer negotiation. >> >> If used together with solution 1, implies AAA protocol >>extensions >> to communicate the KDF. If used with solution 2, implies AAA >> protocol extensions to carry the EMSK. >> >> Changes in lower layers, AAA protocol. No changes in >>EAP or methods. >> >> >> > >[Joe] Another side effect is that the lower layer then chooses the KDF >for all other applications. The method knows best how to choose a key >derivation method that is efficient and secure for its operation. If >the method's key derivation scheme is not sufficient for an environment, >then it is likely the method itself will not be usable for reasons >beyond MSK derivation. In addition here the KDF name space must be >coordinated. > > I agree that the KDF affects other apps. Whether the KDF needs to be known to these other apps is another question, I think. It could be that the NAS that got the EMSK is deriving the AMSKs, so the other parties would only get a plain key. But again, this is mostly speculation because I have not seen a design where we both send the EMSK to the NAS and use it for some other application than the lower layer in question. >>Based on this my current preference is (b). I'd be willing >>to accept (a), too. >> >> >> >[Joe] My choice would be (a) > > Ok. Noted. >>The choice between server or lower-layer based EMSK processing >>depends on security implications and ease of use for >>different purposes. >>The choices are: >> >> (1) Derive AMSKs at the EAP/AAA server. >> >> Implies a AAA protocol extension to retrieve AMSKs. >> >> Changes at the EAP/AAA server, authenticator. New, stateful >> nature of the EAP/AAA server. >> >> (2) Derive AMSKs at the lower layer. >> >> Implies a AAA protocol extension to carry EMSK to the >> authenticator. >> >> Small changes at the EAP/AAA server, main functionality in >> the authenticator. >> >> Hard to see how other nodes than the authenticator would >> actually use the AMSKs. Traditionally, NAS -> NAS communication >> has not been easy compared to NAS -> AAA communication. >> >> >> >[Joe] Because the EMSK, and therefore all the AMSKs, are known to the >NAS the security properties of these two solutions are very different. > > Right. >>Based on this my current preference is (1). But its a close >>call. >> >> >[Joe] I agree with (1) as the preference. > > Noted. Thanks for your comments! --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 18:32:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPBM-0003bw-Hf for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:32:04 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPBL-0006hk-49 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:32:04 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7A3CB4300D1 for ; Mon, 6 Mar 2006 15:32:02 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C74CE430048 for ; Mon, 6 Mar 2006 15:31:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B7FA980C0E9 for ; Mon, 6 Mar 2006 15:31:43 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id C87B980C11B for ; Mon, 6 Mar 2006 15:31:36 -0800 (PST) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k26Nkwbg004037 for ; Mon, 6 Mar 2006 16:47:02 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k26NiVnR027066 for ; Mon, 6 Mar 2006 17:44:31 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 18:31:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAw3LJAAAMnW3A From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Avi Lior" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > So the question is do you have to generate all possible AMSKs and then > delete the EMSK or can you generate the AMSKs as needed? >=20 [Joe] I understand that there may be need for caching of certain quantities. I think Jari explained it well in a separate message. In my opinion you should try to identify the applications in use and the keys needed as early as possible. If this is not possible then caching of the MSK may be necessary. Do we have examples where the caching of the EMSK is necessary. In the case where key caching is used the cache needs to be managed. If we are caching EMSKs then the document that describes EMSK usage must describe how key cache can be managed.=20 Madjid>>I like to consider myself as an EAP keying consumer. I don't really know what the cryptographic requirements for MSK or EMSK are? All I know is that EMSK is recommended for creation of AMSK. Hence the need for caching EMSK for future AMSK generation instances. I don't really care about MSK at this point, because it is not used for AMSKs. > Finally I have an slight issue with the statement that a KEY should be > deleted so that it wont be used for other purposes. I find that=20 > statements like that are an over specification. What makes anyone=20 > think that making a statement that "X should/must be deleted" is going > to be taken more seriously then "X should/must only be used for=20 > purpose X and should/must not be transported out of Y"? >=20 > I think that whether it gets deleted or not is an implementation=20 > issue. >=20 [Joe] The goal of the architecture is to prevent the re-use of keys for multiple different purposes. I agree that this is not necessarily the same a deletion. It is very important that keys derived from the EMSK don't collide purposes across applications. What happens in a particular AMSK branch of the key hierarchy is not necessarily as important since this branch is cryptographically separated from the rest of the system through the AMSK derivation. I think the current text could probably do better in motivating why it is good practice to delete keys. =20 Madjid>>Are you saying EAP keying architecture is incapable of supportring various keying needs? I like to have a tree with EMSK as a root and one per application AMSK as each branch and hopefully independent of other AMSKs, is that wrong? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 18:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPDS-0004d1-3t for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:34:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPDR-0006k7-OI for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:34:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 687224300B3 for ; Mon, 6 Mar 2006 15:34:13 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B0E68430048 for ; Mon, 6 Mar 2006 15:32:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8995D80C109 for ; Mon, 6 Mar 2006 15:32:41 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by hermes.tigertech.net (Postfix) with ESMTP id F302480C112 for ; Mon, 6 Mar 2006 15:32:28 -0800 (PST) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k26Nq91S016774 for ; Mon, 6 Mar 2006 16:52:09 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k26NiEZM015385 for ; Mon, 6 Mar 2006 17:44:14 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 18:32:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAOOfJsABTcvOwADegfWAADEiJEA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Avi Lior" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Madjid>> Keep EMSK in case I need to create AMSKs later (as long as EAP session is still valid).=20 -----Original Message----- From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 Sent: Monday, March 06, 2006 11:48 AM To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Madjid >=20 > Seems that there a lot of good reasons for keeping EMSK around after=20 > it is used to generate AMSKs. Hopefully everyone gets that. >=20 [Joe] No. After the AMSKs are generated what are you going to do with the EMSK? The purpos of the EMSK is to generate AMSKs. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 18:38:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPI2-00013i-9e for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:38:58 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPI0-0006nT-S8 for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 18:38:58 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 842A14300A2 for ; Mon, 6 Mar 2006 15:38:56 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E9A5B43004F for ; Mon, 6 Mar 2006 15:38:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D87D280C10C for ; Mon, 6 Mar 2006 15:38:37 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id AA4BF80C0E9 for ; Mon, 6 Mar 2006 15:38:36 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k26Ns2T7005663 for ; Mon, 6 Mar 2006 16:54:02 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k26NovOo025037 for ; Mon, 6 Mar 2006 17:50:57 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 6 Mar 2006 18:38:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwADnYKGAAi0YY4AAMQxig From: "Nakhjiri Madjid-MNAKHJI1" To: "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe =20 -----Original Message----- From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 Sent: Monday, March 06, 2006 12:06 PM To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10/EMSK deletion requirement? =20 > Madjid>>I guess the number of people who are not sure about definition > of AAA layer is more than one :) > Joking aside, what is your reason what not making EMSK available to=20 > lower layer, while doing so for MSK is ok? What is the fundamental=20 > difference. > >=20 [Joe] If you pass the EMSK to the lower layer it becomes effectively the same as the MSK. If you want use the EMSK to key an independent application that uses a different authenticator the security of that application becomes completely dependent upon the lower layer its authenticator. =20 Madjid>>I am not transporting the EMSK anywhere. I thought that was a main distinction. Well, the role of authenticator may be not as relevant as the role of the AAA server in keying for an application. Authenticator is just a pass-through for EAP, the applications don't have to get their keys from the authenticator. > > In both cases we require deletion of EMSK after generation of AMSK,=20 > > why? > >=20 > [Joe] To minimize the chance of exposure of the EMSK. Why do you need > to cache it? Could you generate and cache an AMSK instead? >=20 > Madjid>>because a priori I cannot know how many AMSKs I may > need later. > An application may pop up later that needs keying or I move to a=20 > different domain that may require a new AMSK, but I cannot anticipate=20 > the move ahead of time... >=20 [Joe] A different application I may understand although it seems the system typically knows the applications that are in use. If you don't I'm not sure how can authorize the distribution of keys. For the handoff case consider deriving an Handoff AMSK from the EMSK. This handoff AMSK becomes the root of all keys used for handoff. When you move you derive a key from the handoff AMSK.=20 Madjid>>Well today, you run one EAP every time you need keys for a protocol (MIPv6 or something else, SIP, I don't know). Do you know exactly at the start how many protocols you want to key for? Do you want to run a new EAP every time you find out? For handover, yes HO-AMSK is a good solution, if you own the whole network, I don't know what sort of requirements people will have moving to another operator network?? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 19:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPkP-0004uf-MA for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 19:08:17 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPkO-0007pZ-5O for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 19:08:17 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 931184300D5 for ; Mon, 6 Mar 2006 16:08:15 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1F2FF430054 for ; Mon, 6 Mar 2006 16:08:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0F02C80C10E for ; Mon, 6 Mar 2006 16:08:03 -0800 (PST) Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by hermes.tigertech.net (Postfix) with ESMTP id D029C80C0E9 for ; Mon, 6 Mar 2006 16:07:57 -0800 (PST) Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k270bESB017073 for ; Mon, 6 Mar 2006 17:37:14 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k270IKuF018131 for ; Mon, 6 Mar 2006 18:18:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Mon, 6 Mar 2006 19:07:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK thread-index: AcZBAXub84RaL2txS7GADvf+PSydmQAd5ylA From: "Nakhjiri Madjid-MNAKHJI1" To: "Jari Arkko" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Hi Jari, =20 I think keeping EMSK at the server (EAP or AAA server), and calculating AMSK there (your alternative 1) provides for better control of the overall AAA and security of both handover and applications. So I favor 1.=20 This way not only you are not worried about misuse of EMSK in generating unauthorized AMSKs by the authenticator, but also are covered against a few things: 1) authenticator handover does not require regeneration of EMSK (read new EAPs). 2) application keying does not require authenticator-application agent SA s that may otherwise not exist. We ran into this problem with Proxy MIP. Authenticator gets a PMIP key (say generated from a PMIP-AMSK), the authenticator can have an SA with the proxy MN, since they are expected to be within the foreign network, but the authenticator is not expected to have an SA with the HA, meaning, the HA cannot get the PMIP key, it has to go to the AAA server to get it and guess what, the AAA server cannot even send the PMIP-AMSK to the authenticator, because according to EAP requirements, it has to have deleted it after transport to authenticator. 3) As you mentioned, the AAA server may even have a policy about the KDFs to be used for each application keying, say MIP or whatever, so you may not have negotiate the KDF. Madjid -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, March 06, 2006 3:36 AM To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] About use of EMSK Here's some analysis of the server vs. lower-layer based EMSK processing approaches. (1) In the server based approach we keep the EMSK in the server (perhaps just for a moment) and generate the AMSKs, which are given to the the different applications, such as fast handoff mechanisms. The use of these applications goes via AAA, e.g., some kind of key requests or fast re-auth requests can be sent from NASes to the server. The AMSKs are derived using a KDF which is decided either (a) by a default plus optional negotiation in methods or (b) by lower layer negotiation and having AAA tell the server which KDF to use. (2) In the lower-layer based EMSK processing approach, the EMSK is delivered to the authenticator along with the MSK. KDF is selected either (a) by a default in EAP plus optional negotiation in methods, choice is communicated to the lower layer via AAA or (b) by lower layer negotiation alone. The lower layer is responsible for all use of the AMSKs in a local context. That is, no AAA key requests are needed or possible. Discussion about the chosen approach for EMSK use has so far appeared to assume 1a vs. 2b. Based on the above, it seems that the KDF negotiation may be a separate issue from who maintains the EMSK and calculates AMSKs. In the following I'll try to analyze these issues. The KDF negotiation is indeed problematic almost no matter what we do. Requiring new funtionality in methods is in practice often a non-starter; while we can develop new methods and update old ones, it is expected that most of current usage will continue to use the existing methods. Having a default does not help much either, if the default becomes broken in the near future. But requiring new functionality in link layers it not always easy either. It would be easy when we are developing a new link layer and including some EMSK usage as a part of that. But if we were to use EMSK for some new function over 802.11, for instance, would there be enough incentive to extend 802.11 just to make this possible? The choices and their implications are: (a) Specified default, optional negotiation in EAP methods. This implies an interface either from methods to the AAA/EAP server code (for solution 1) or AAA protocol extensions for solution 2. Changes in peers, servers, methods, possibly AAA protocols. (b) Lower layer negotiation. If used together with solution 1, implies AAA protocol extensions to communicate the KDF. If used with solution 2, implies AAA protocol extensions to carry the EMSK. =20 Changes in lower layers, AAA protocol. No changes in EAP or methods. Based on this my current preference is (b). I'd be willing to accept (a), too. The choice between server or lower-layer based EMSK processing depends on security implications and ease of use for different purposes. The choices are: (1) Derive AMSKs at the EAP/AAA server. Implies a AAA protocol extension to retrieve AMSKs. Changes at the EAP/AAA server, authenticator. New, stateful nature of the EAP/AAA server. (2) Derive AMSKs at the lower layer. Implies a AAA protocol extension to carry EMSK to the authenticator. Small changes at the EAP/AAA server, main functionality in the authenticator. Hard to see how other nodes than the authenticator would actually use the AMSKs. Traditionally, NAS -> NAS communication has not been easy compared to NAS -> AAA communication. Based on this my current preference is (1). But its a close call. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 06 23:44:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGU3I-0002hT-0d for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 23:44:04 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGU3G-00008G-GK for eap-archive@lists.ietf.org; Mon, 06 Mar 2006 23:44:04 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 845B64300FC for ; Mon, 6 Mar 2006 20:44:01 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28727430054 for ; Mon, 6 Mar 2006 20:43:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1A07180C102 for ; Mon, 6 Mar 2006 20:43:35 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by hermes.tigertech.net (Postfix) with SMTP id DB54780C0F6 for ; Mon, 6 Mar 2006 20:43:32 -0800 (PST) Received: (qmail 4300 invoked from network); 7 Mar 2006 04:43:32 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@70.137.148.157 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 7 Mar 2006 04:43:31 -0000 Message-ID: <005301c641a1$af9622b0$a200a8c0@adithya> From: "Mohan Parthasarathy" To: "Bernard Aboba" , "Yoshihiro Ohba" References: <440C1F25.7090004@piuha.net> <20060306164553.GC2929@steelhead> Subject: Re: [eap] issue 325 - channel bindings Date: Mon, 6 Mar 2006 20:43:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST X-Spam-Level: * Cc: eap@frascone.com, aboba@internaut.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 > It may be too late to make comment on this, but if we agree on only > the server has the knowledge of the Channel Binding values, I really > don't see any value on carrying Channel Bindings over EAP methods > compared to the other method of using the Channel Bindings for key > derivation. Please correct if my view is wrong. > Yes, i miss the value in just the server and peer checking for consitency in values. Unless the server can check the values against a pre-configured database, channel bindings is of little use. Or if there is some use, someone should explain what it is. -mohan > Yoshihiro Ohba > > > On Mon, Mar 06, 2006 at 04:01:51AM -0800, Bernard Aboba wrote: > > How about this? > > > > "Channel Bindings include lower layer parameters that > > are verified for consistency between the EAP peer and server. > > In order to avoid introducing media dependencies, EAP > > methods that transport Channel Binding data MUST treat this > > data as opaque octets. > > > > Typically the EAP method imports Channel Bindings from the > > lower layer on the peer, and transmits them securely to the > > EAP server, which exports them to the lower layer or AAA layer. However, > > transport may occur from EAP server to peer, or may be > > bi-directional. On the side of the exchange (peer or server) > > where Channel Bindings are verified, the lower layer or AAA layer passes > > the result of the verification (TRUE or FALSE) up to the > > EAP method. > > > > While the verification can be done either by the peer > > or the server, typically only the server has the knowledge to > > determine the correctness of the values, as opposed to merely > > verifying their equality." > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From keandobus@10-67.com Tue Mar 07 05:54:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZpx-0001kL-9F for eap-archive@ietf.org; Tue, 07 Mar 2006 05:54:41 -0500 Received: from 218-165-5-34.dynamic.hinet.net ([218.165.5.34] helo=your-v13bjp5p26) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZpu-0006BS-6H for eap-archive@ietf.org; Tue, 07 Mar 2006 05:54:41 -0500 Date: Two, 7 Mar 2006 10:54:36 -0480 From: "Callie Sanders" X-Mailer: The Bat! (v3.0.1.33) CD5BF9353B3B7091 Reply-To: "Callie Sanders" X-Priority: 3 (Normal) Message-ID: <608547370.20060307105436@10-67.com> To: eap-archive@ietf.org Subject: re: St0kkMarrkett Picks Trade watch special pr news release MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Nanoforce Inc. (NNFC), Price Set To Jump Tomorrow SYM: N N F C THE COMPANY: NANOFORCE INC. (NNFC) - Current Price: 1.08 Up .22 cents Monday March 6th Alone. Nanoforce Inc. (NNFC) appears to be on an upward trend. Is not the time to buy ? With current marketing campaign we expect NNFC to climb thru mid March Get In Now! NANOFORCE INC. (NNFC) COMAPNY INFORMATION Nanoforce, Inc. is a company founded to support the development, and acquisition of exciting new products that integrate fundamental developments in Nanotechnology. The Nanotechnology industry is in its infancy and provides a wealth of opportunity for companies that position themselves well now to profit from the burgeoning opportunities that will be provided by nanotech produced products in the near future. NANOFORCE INC. (NNFC) RECENT NEWS (For Complete News Detail, check your current stock site.) February 13, 2006: Nanoforce Acquires Unique package of Nanotech. Ips December 16, 2005: Nanoforce Acquires Refinery Science Corp. December 16, 2005: Nanoforce approves 10 for 1 split of Refinery Science. CHECK OUT NANOFORCE (NNFC) TODAY! G00D TRAD1NG From grtzga@culturebytes.com Tue Mar 07 06:35:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaTa-0001Fy-CZ for eap-archive@ietf.org; Tue, 07 Mar 2006 06:35:38 -0500 Received: from [132.151.6.1] (helo=ietf-mx.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaTa-0007X6-Af for eap-archive@ietf.org; Tue, 07 Mar 2006 06:35:38 -0500 Received: from [222.124.52.69] (helo=69.subnet222-124-52.speedy.telkom.net.id) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGalR-0001Ut-9l for eap-archive@ietf.org; Tue, 07 Mar 2006 06:54:20 -0500 Received: from [222.124.74.129] (port=2934 helo=cuugous) by 69.subnet222-124-52.speedy.telkom.net.id with esmtp id 1FGaaA-0006fD-7J for eap-archive@ietf.org; Tue, 7 Mar 2006 18:42:26 +0700 Message-ID: <002f01c641db$d3f3c797$814a7cde@cuugous> From: "Kitty Monroe" To: Subject: to Cornelia Date: Tue, 7 Mar 2006 18:31:05 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Date: 6 Mar 2006 Profile: Innovation Holdings, Inc. Symbol: IVHN Price: $0.5 Go Look at a Chart on This One Rite Now! While Past Performance is Never Indicative of Future Results, IVHN has been Trending Higher Since the Beginning of This Year. IS THAT WHAT YOU LIKE TO OWN, A STOCK THAT MOVES? PR Campaign Tonite. Is This Stock Ready to Go Ballistic? Radar it Now for Tomorrow! The News: Go Read The Full Story Right Now! Innovation Holdings Inc. Signs Letter of Intent With Pharmaspritz Corporation LOS ANGELES, CA, Feb 22, 2006 (MARKET WIRE via COMTEX) -- The Board of Directors of Innovation Holdings Inc. (OTC: IVHN) announced that the Company has signed a Letter of Intent with Pharmaspritz Corporation of Delaware to purchase all of its assets and those of its Canadian subsidiary in return for shares of Innovation Holdings Inc. Pharmaspritz Corporation has developed SlimSpritz(TM), a patented and revolutionary 100% herbal weight loss aid that utilizes a unique and effective delivery system. SlimSpritz(TM) features a Metered Dose Aerosol Pump (MDAP) that instantly delivers effective and recognized herbal appetite suppressants and active thermogenic agents. SlimSpritz(TM) incorporates a breath freshener, appetite suppressants and thermogenic agents to stimulate the metabolism of the body for those on weight loss programs. Steven Burke, President of Pharmaspritz, developed the concept of incorporating the thermogenic appetite suppressants for weight loss into an aerosol spray. Mr. Burke has over 30 years experience in the consumer product marketing business, in retail distribution and in direct marketing. In addition, Mr. Burke introduced the first powdered meal replacement for weight loss, NutriSlim, to the Canadian marketplace in 1980. WATCH IVHN AT THE OPEN TUESDAY!! Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Any statements that express or involve discussions with respect to predictions or projections of future events or performance are not statements of historical fact and may be forward 1ooking statements. Don't rely on them to make a decision. The Company has been a reporting company registered under the Exchange Act of 1934 but is currently delinquent in their filings. Today's company has disclosable material items you need to know to make an informed and intelligent decision. These items include: no revenue in its most recent quarter, an accumulated deficit,a negative net worth, a reliance on loans from officers,nominal cash, back taxes due, a subsidiary in bankruptcy,a going concern opinion from its auditor, litigation and some judgements against the company. It is not an operating company. The announcement above may not be binding and may not become a definitive agreement. Read the Company's SEC filings before you invest.This report shall not be construed as any kind of investment advice or solicitation. You can lose all your money by investing in this stock. We have received one hundred thousand free trading shares from a third party not an officer, director or affiliate shareholder for our services. We intend to sell all these shares now, which could cause the stock to go down, resulting in losses for you. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 07 13:07:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgaX-0002xx-Sm for eap-archive@lists.ietf.org; Tue, 07 Mar 2006 13:07:13 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgaW-0004sg-3w for eap-archive@lists.ietf.org; Tue, 07 Mar 2006 13:07:13 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0F9A34300CD for ; Tue, 7 Mar 2006 10:07:11 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3FBE043005F for ; Tue, 7 Mar 2006 10:06:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1ED4A39805D for ; Tue, 7 Mar 2006 10:06:49 -0800 (PST) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1748B398051 for ; Tue, 7 Mar 2006 10:06:41 -0800 (PST) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k27IHUet018472 for ; Tue, 7 Mar 2006 11:17:34 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k27IQCDr004835 for ; Tue, 7 Mar 2006 12:26:13 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Tue, 7 Mar 2006 13:06:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? thread-index: AcYmr1WlaKn5+OsfTI228TvBJP0nGAW0U0hQAADTbrAAJPEgQAAGQZRwAAEWdbAAw3LJAAAB6n2wADHGkiA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Avi Lior" , "Salowey, Joe" , "Rafa Marin Lopez" , "Bernard Aboba" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 I agree with Avi's statements. Limit the purpose of EMSK and its usage (to AMSK generation) and prohibit its transport outside server, without requiring its deletion. That will cover future AMSK generations as well. Madjid =20 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Monday, March 06, 2006 12:36 PM To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Hi Joe, I have something to say about both your replies to I included them together. >=20 > Hi Madjid >=20 > Seems that there a lot of good reasons for keeping EMSK around after=20 > it is used to generate AMSKs. Hopefully everyone gets that. >=20 [Joe] No. After the AMSKs are generated what are you going to do with the EMSK? The purpos of the EMSK is to generate AMSKs. =20 I think it is sufficient to say that exactly what you said: "The purpose of the EMSK is to generate AMSKs." Why should we generate all the AMSKs at once? A session may have several applications that may require AMSK. Some applications will be used 100% of the time, some application will be used rarely. Why should an implmeentation genrate an AMSK and cache it just in case it will need the key? That doesn't make sense. > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com] > Sent: Monday, March 06, 2006 12:46 PM > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard=20 > Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, March 02, 2006 12:16 PM > > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin > Lopez; Bernard > > Aboba > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Hi Joe and Madjid, > >=20 > > The only reason for caching the EMSK is if you have to generate an=20 > > AMSK for another application associated with the current session. > >=20 > > So the question is do you have to generate all possible > AMSKs and then > > delete the EMSK or can you generate the AMSKs as needed? > >=20 > [Joe] I understand that there may be need for caching of certain=20 > quantities. I think Jari explained it well in a separate message. In > my opinion you should try to identify the applications in use and the=20 > keys needed as early as possible. I disagree. I think from a resource point of view we should not genrate keys for something that we may not be using. At any rate this needs to be an implmeentation choice and we should not prohibit this choice in a standard. > If this is not possible then caching of the MSK may be necessary. I think you mean EMSK not MSK. Right? If yes, we agree then caching of EMSK may be necessary. Great!!! I don't think we should write a specification that MUST require an implmeentation to dervie all the keys that it is necessary on the chance that the keys may be needed. =20 I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and MUST NOT be transported out of the EAP Authentication Server layer. > Do we have examples where the caching of the EMSK is necessary. What if I don't have an example today? Does that mean that in the future I won't? or that somewhere in the world someone does have such a need? > In the case where key caching is used the cache needs to be managed. =20 > If we are caching EMSKs then the document that describes EMSK usage=20 > must describe how key cache can be managed. I agree. =20 >=20 > > Finally I have an slight issue with the statement that a > KEY should be > > deleted so that it wont be used for other purposes. I find that=20 > > statements like that are an over specification. What makes anyone=20 > > think that making a statement that "X should/must be > deleted" is going > > to be taken more seriously then "X should/must only be used for=20 > > purpose X and should/must not be transported out of Y"? > >=20 > > I think that whether it gets deleted or not is an implementation=20 > > issue. > >=20 >=20 > [Joe] The goal of the architecture is to prevent the re-use of keys=20 > for multiple different purposes. I agree that this is not necessarily > the same a deletion. It is very important that keys derived from the=20 > EMSK don't collide purposes across applications. I agree and therefore lets stick to the important issue and drop the deletion argument. The important issue being that EMSK shall be used for AMSK derivation and for no other purpose. > What happens in a particular AMSK branch of the key hierarchy is not=20 > necessarily as important since this branch is cryptographically=20 > separated from the rest of the system through the AMSK derivation. I=20 > think the current text could probably do better in motivating why it=20 > is good practice to delete keys. I don't think we need to talk about key deletion at all, except when it comes to the key's end-of-life or end of session. I think we need to stress exactly what you said. =20 > > Finally if we insist on saying that X must be deleted we > should really > > say that X must be securely deleted. There is a difference. > > When a key > > is securely deleted the software takes extra care that the memory=20 > > location containing the key is first erased before the > memory location > > is freed to the heap. Perhaps we can state that somewhere. > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Thursday, March 02, 2006 2:49 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, March 02, 2006 8:44 AM > > > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > Hi Joe, > > > >=20 > > > > Thanks for the email. I think you responded to the old > > piece of the > > > > email from Rafa and I am to blame for causing that > > confusion, as I > > > > kept that part to provide context. > > > > Again, my question was why an entity needs to delete EMSK after=20 > > > > generating the first AMSK (or first set of AMSKs?)? This > > > seems to be > > > > the requirement regardless of two options: > > > >=20 > > > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based > > > request from > > > > AAA layer, delete EMSK Immediately (this means EAP layer > > must have > > > > KDFs for AMSK=3DKDF(EMSK, etc) > > > > 2) push EMSK down to AAA layer at backend server, create > > > AMSK at AAA > > > > layer and delete EMSK immediately (this means AAA layer > must have > > > > KDFs) > > > > > > > [Joe] If the AAA layer contains the AAA client and AAA > server then > > > the EMSK should not be available to this layer, if the AAA layer=20 > > > means something else then I don't know about (1). > > > The AMSK should be generated in the EAP and exported, option (2). > > > =20 > > > >=20 > > > > In both cases we require deletion of EMSK after > > generation of AMSK, > > > > why? > > > >=20 > > > [Joe] To minimize the chance of exposure of the EMSK. Why do you=20 > > > need to cache it? Could you generate and cache an AMSK > > instead? =20 > > >=20 > > >=20 > > > > Thanks, > > > >=20 > > > > Madjid > > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Wednesday, March 01, 2006 5:17 PM > > > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Wednesday, March 01, 2006 2:38 PM > > > > > To: Rafa Marin Lopez; Bernard Aboba > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10 > > > > >=20 > > > > > Madjid>>Again, why is deletion of EMSK after generation of > > > > > one AMSK is a > > > > > requirements. What if we need to create multiple AMSKs > > > and that at > > > > > multiple occassions? > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Well, actually, lower layer authenticator implementation > > > > should expect > > > > > (MSK,EMSK) in the case EAP method is executed by the > standalone > > > > > authenticator or (MSK,AMSK) in the case EAP method is > > executed by > > > > > backend authentication server. If it receives (MSK,EMSK) > > > > should create > > > >=20 > > > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's > > > > all, correct? > > > >=20 > > > > [Joe] Not really, strictly speaking the lower layer > > > shouldn't expect > > > > to receive the EMSK as that would break mode independence. An=20 > > > > architectural description should not have the lower layer > > receiving > > > > the keys. From a supplicant perspective it must appear the same=20 > > > > whether an external EAP-Server or a collocated EAP server > > is used. =20 > > > > Now I don't know what is going on inside your box, it > > could all be > > > > monolithic when a internal EAP server is used but that > > shouldn't be > > > > visible to the external world. If I was interested in > > > cryptographic > > > > module separation I might not be too happy if you shared > > > the EMSK with > > > > the lower layer. > > > >=20 > > > > >=20 > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, > > please visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > >=20 > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > >=20 > > > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 07 15:40:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiyc-0001yp-8q for eap-archive@lists.ietf.org; Tue, 07 Mar 2006 15:40:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGiya-0001fc-RF for eap-archive@lists.ietf.org; Tue, 07 Mar 2006 15:40:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A09714300D1 for ; Tue, 7 Mar 2006 12:40:11 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E36E543005F for ; Tue, 7 Mar 2006 12:39:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D06DE398053 for ; Tue, 7 Mar 2006 12:39:59 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id D998E39804E for ; Tue, 7 Mar 2006 12:39:57 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k27KdrMs014474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2006 12:39:53 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k27KdqHX013442; Tue, 7 Mar 2006 12:39:52 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:39:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Tue, 7 Mar 2006 12:39:51 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB841B0B0E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusA== From: "Narayanan, Vidya" To: "Salowey, Joe" , "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 07 Mar 2006 20:39:52.0473 (UTC) FILETIME=[49218890:01C64227] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Joe,=20 I can see the problem with transporting the EMSK to other entities - however, what really is the concern with caching the EMSK as long as it is never exported? Is it just the concern of having to maintain state or is there a security concern here?=20 Vidya=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Monday, March 06, 2006 2:04 PM > To: Avi Lior; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Avi, =20 >=20 > >=20 > > Perhaps you missed my poorly stated point :-) > >=20 > > What if the user is requesting access to a new application?=20 > > which could > > also involve the modification of the user's profile.=20 > > If EMSK is not there, then what do I do? Restart the session? No. > >=20 > > At anyrate I belive that there could be other use cases...=20 > I gave two=20 > > reason why: > >=20 > > Just-in-time; > > Dynamic-Application provisioning. >=20 > [Joe] Would you agree with the following: >=20 > "For any specific application once the AMSK is generated for=20 > that application there is no requirement to cache the EMSK=20 > for that application, however there may be a need to cache=20 > the EMSK if the system requires other Masks to be generated. " =20 >=20 > This makes the caching more of a system issue than an issue for one > particular application. =20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From DariaDiggerflammablezrzp@yahoo.no Tue Mar 07 19:23:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGmSJ-0002wG-Bt for eap-archive@ietf.org; Tue, 07 Mar 2006 19:23:07 -0500 Received: from ppp37.39-205-205.netc.net ([205.205.39.37] helo=395F52E8) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGmS5-0004Sm-H6 for eap-archive@ietf.org; Tue, 07 Mar 2006 19:23:07 -0500 Received: from firewall.administratress.com.au (firewall.administratress.com.au [139.187.0.192]) (EHLO localhost) by mail.advisiveness.co.in with ESMTP id yVyNi8Y76k71f85q Date: Wed, 08 Mar 2006 03:15:38 +0300 From: "Heath" To: eap-archive@ietf.org Subject: hey, you there Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Good day sir, It's easy to 0rder from our site Worldwide. Sympathetic cust0m3r supp0rttt.=20 ************************************************************************ copy the address below and paste in e your web browser: caulotaxis.coralstrategy.com ************************************************************************ I had nothing, back there in the night.=20. Stands a child, with her father,=20. not even any time. And yet, were he asked to describe the Poor. 'Well if you had to think about it now, what would you think?'. Up through the darkness,. Best Regards, Junior Rivera From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 02:50:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtR9-0005P5-Ha for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 02:50:23 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtR8-0001jl-3Y for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 02:50:23 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7796D4300C6 for ; Tue, 7 Mar 2006 23:50:21 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 51B0743005F for ; Tue, 7 Mar 2006 23:50:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 40DF780C0EB for ; Tue, 7 Mar 2006 23:50:06 -0800 (PST) Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by hermes.tigertech.net (Postfix) with ESMTP id 3CA8880C006 for ; Tue, 7 Mar 2006 23:50:03 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k287o29W014777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQo-0001dT-3z; Wed, 08 Mar 2006 02:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 02:50:02 -0500 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.334 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: eap@frascone.com Subject: [eap] I-D ACTION:draft-ietf-eap-keying-10.txt X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Key Management Framework Author(s) : B. Aboba, et al. Filename : draft-ietf-eap-keying-10.txt Pages : 56 Date : 2006-3-7 The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the transport and usage of keying material generated by EAP authentication algorithms, known as "methods". It also specifies the EAP key hierarchy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-10.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-eap-keying-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-keying-10.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: <2006-3-7210957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7210957.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --NextPart-- From berthiauofermin@hri-rig.com Wed Mar 08 03:31:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGu5C-0001gS-Jd for eap-archive@ietf.org; Wed, 08 Mar 2006 03:31:46 -0500 Received: from dyn-83-153-15-169.ppp.tiscali.fr ([83.153.15.169] helo=hri-rig.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGu5A-0006kt-Vp for eap-archive@ietf.org; Wed, 08 Mar 2006 03:31:46 -0500 Message-ID: <000001c6428a$ad91a040$5c67a8c0@jpz20> Reply-To: "Fermin Berthiaume" From: "Fermin Berthiaume" To: eap-archive@ietf.org Subject: Re: POaramcy news Date: Wed, 8 Mar 2006 03:31:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64260.C4BB9840" 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 X-Spam-Score: 2.7 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64260.C4BB9840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable n C V V I A I A L A L I G I U R S M A from from from $ $ $ 1 3 3 , , , 2 7 3 1 5 3 j http://vay89.pleasasur.com ------=_NextPart_000_0001_01C64260.C4BB9840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
n
=
C
V
V
= I
A
I
A
= L
A
L
I
= G
I
U
R
 =
S
M
A
from
=
from
from
$
$
=
$
1
3
3
,
,
,
2
=
7
3
1
5
= 3
j
<= /BODY> ------=_NextPart_000_0001_01C64260.C4BB9840-- From jason@0sil8.com Wed Mar 08 07:00:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxKk-0000qn-Rm for eap-archive@ietf.org; Wed, 08 Mar 2006 07:00:02 -0500 Received: from [150.140.174.151] (helo=paulxp-laptop) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGxKj-0006Wx-HZ for eap-archive@ietf.org; Wed, 08 Mar 2006 07:00:02 -0500 Date: Wed, 8 Mar 2006 12: 0: 0 -0120 From: "Eva Cole" X-Mailer: The Bat! (v3.0.1.33) CD5BF9353B3B7091 Reply-To: "Eva Cole" X-Priority: 3 (Normal) Message-ID: <236073464.20060308120000@0sil8.com> To: eap-archive@ietf.org Subject: fwd: St0kkMarrkett Picks Trade Special daily news MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Nanoforce Inc. (NNFC), Price Set To Jump Tomorrow SYMB0L: N N F C Company: NANOFORCE INC. (NNFC) - Current Price: 1.15 Up .22 cents Monday March 6th Alone. Up another .20 already today March 7th! Nanoforce Inc. (NNFC) appears to be on an upward trend. Is not the time to buy ? With current marketing campaign we expect NNFC to climb thru mid March Get In Now! NANOFORCE INC. (NNFC) COMAPNY INFORMATION Nanoforce, Inc. is a company founded to support the development, and acquisition of exciting new products that integrate fundamental developments in Nanotechnology. The Nanotechnology industry is in its infancy and provides a wealth of opportunity for companies that position themselves well now to profit from the burgeoning opportunities that will be provided by nanotech produced products in the near future. NANOFORCE INC. (NNFC) RECENT NEWS (For Complete News Detail, check your current stock site.) March 7, 2006: Nanoforce Inc. Hires Local Management Team to Head Refinery Science Corp.'s El Paso Office February 13, 2006: Nanoforce Acquires Unique package of Nanotech. Ips December 16, 2005: Nanoforce Acquires Refinery Science Corp. December 16, 2005: Nanoforce approves 10 for 1 split of Refinery Science. CHECK OUT NANOFORCE (NNFC) TODAY! Good Trading From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 11:43:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1lW-0002Gu-Ob for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 11:43:58 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1lV-0007tC-Ce for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 11:43:58 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BA4D7430139 for ; Wed, 8 Mar 2006 08:43:56 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DDF95430067 for ; Wed, 8 Mar 2006 08:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D319580C006 for ; Wed, 8 Mar 2006 08:43:44 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by hermes.tigertech.net (Postfix) with ESMTP id 7C53280C0EB for ; Wed, 8 Mar 2006 08:43:42 -0800 (PST) Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k28Ghbq1014544; Wed, 8 Mar 2006 11:43:38 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Wed, 8 Mar 2006 11:43:33 -0500 To: Jari Arkko Subject: Re: Channel binding approaches (Was: Re: [eap] Strawman -10) Message-ID: <20060308164333.GG6224@steelhead> References: <43E8A6C8.2010008@piuha.net> <20060207173230.GG14401@steelhead> <440B3EBD.5030802@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <440B3EBD.5030802@piuha.net> User-Agent: Mutt/1.5.11+cvs20060126 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 31 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 I agree that there can be several alternatives within my channel binding approach. I'd be happy to discuss such alternatives in my draft. Then the question is in which WG can we discuss my draft if EAP WG is closed? Best regards, Yoshihiro Ohba On Sun, Mar 05, 2006 at 09:40:45PM +0200, Jari Arkko wrote: > The channel binding discussion has been interesting. I can > actually see a number of different alternatives even > within Yoshihiro's method. For instance, L2 could negotiate > the use of channel bindings and have AAA inform the server > of the need to use MSK_cb instead of the regular MSK. Or > EAP method could negotiate this. Or the use of channel > bindings would be dictated by the used lower layer, > > I'm not sure which approach is the best one; there > are tradeoffs. Generally I like approaches where > we don't need to change EAP methods but YMMV. > > In any case, I'm happy with what the -10 says about > channel bindings, and perhaps the results of this > discussion can be incorporated to Yoshihiro's draft. > > --Jari > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 13:17:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3E7-0000cv-RR for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:17:35 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3E6-00037M-Cs for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:17:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 75B43430103 for ; Wed, 8 Mar 2006 10:17:33 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 45A94430067 for ; Wed, 8 Mar 2006 10:17:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EC0280C11C for ; Wed, 8 Mar 2006 10:17:22 -0800 (PST) X-Greylist-Status: Sender first seen 00:01:00 ago Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 0C52780C11E for ; Wed, 8 Mar 2006 10:17:20 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 08 Mar 2006 10:16:19 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k28IGIGv026896; Wed, 8 Mar 2006 10:16:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Wed, 8 Mar 2006 10:23:12 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B33428@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjA From: "Salowey, Joe" To: "Narayanan, Vidya" , "Avi Lior" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.8 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 The EMSK is the root of all AMSKs, so a compromise of the EMSK compromises all AMSKs. Therefore I would like to see the EMSK protected as much as possible. Once the EMSK is securely deleted it cannot be compromised. I would like to see applications be as independent from one another as possible and not have one application require the EMSK be cached once its AMSK is generated. This implies a deeper key hierarchy than if an application derives all of its keys directly from the EMSK. =20 Caching itself is new functionality in the system, but seems to be required whether you cache AMSK or EMSK. I don't really have a problem with caching the EMSK if it is required at the system level because all applications are not known at the right time. It think it may be OK for an implementation to cache the EMSK for its own optimizations, but I would prefer that the caching of the EMSK not be required for any particular AMSK usage. Since an AMSK is exportable you have more options on where it can be cached. =20 Hope this helps, Joe > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, March 07, 2006 12:40 PM > To: Salowey, Joe; Avi Lior; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Joe,=20 > I can see the problem with transporting the EMSK to other entities - > however, what really is the concern with caching the EMSK as=20 > long as it > is never exported? Is it just the concern of having to=20 > maintain state or > is there a security concern here?=20 >=20 > Vidya=20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Monday, March 06, 2006 2:04 PM > > To: Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Hi Avi, =20 > >=20 > > >=20 > > > Perhaps you missed my poorly stated point :-) > > >=20 > > > What if the user is requesting access to a new application?=20 > > > which could > > > also involve the modification of the user's profile.=20 > > > If EMSK is not there, then what do I do? Restart the session? No. > > >=20 > > > At anyrate I belive that there could be other use cases...=20 > > I gave two=20 > > > reason why: > > >=20 > > > Just-in-time; > > > Dynamic-Application provisioning. > >=20 > > [Joe] Would you agree with the following: > >=20 > > "For any specific application once the AMSK is generated for=20 > > that application there is no requirement to cache the EMSK=20 > > for that application, however there may be a need to cache=20 > > the EMSK if the system requires other Masks to be generated. " =20 > >=20 > > This makes the caching more of a system issue than an issue for one > > particular application. =20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 13:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3IU-0005s9-Dj for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:22:07 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3IR-0003BE-Tt for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:22:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87533430108 for ; Wed, 8 Mar 2006 10:22:03 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4734C430067 for ; Wed, 8 Mar 2006 10:21:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 28DDE39805F for ; Wed, 8 Mar 2006 10:21:40 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id C2A39398069 for ; Wed, 8 Mar 2006 10:21:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Wed, 8 Mar 2006 13:24:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fA= From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 So there might be reason for caching the EMSKs. So language like the following: EMSK is used strictly for generating AMSKs. EMSK is not transported out of the EAP Authentication Server Layer. EMSK MUST be deleted when the session for which it was created is deleted. EMSK SHOULD be deleted sooner, when it is no longer required. =20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Wednesday, March 08, 2006 1:23 PM > To: Narayanan, Vidya; Avi Lior; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > The EMSK is the root of all AMSKs, so a compromise of the=20 > EMSK compromises all AMSKs. Therefore I would like to see=20 > the EMSK protected as much as possible. Once the EMSK is=20 > securely deleted it cannot be compromised. I would like to=20 > see applications be as independent from one another as=20 > possible and not have one application require the EMSK be=20 > cached once its AMSK is generated. This implies a deeper key=20 > hierarchy than if an application derives all of its keys=20 > directly from the EMSK. =20 >=20 > Caching itself is new functionality in the system, but seems=20 > to be required whether you cache AMSK or EMSK. I don't=20 > really have a problem with caching the EMSK if it is required=20 > at the system level because all applications are not known at=20 > the right time. It think it may be OK for an implementation=20 > to cache the EMSK for its own optimizations, but I would=20 > prefer that the caching of the EMSK not be required for any=20 > particular AMSK usage. Since an AMSK is exportable you have=20 > more options on where it can be cached. =20 >=20 > Hope this helps, >=20 > Joe >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, March 07, 2006 12:40 PM > > To: Salowey, Joe; Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Joe, > > I can see the problem with transporting the EMSK to other=20 > entities -=20 > > however, what really is the concern with caching the EMSK=20 > as long as=20 > > it is never exported? Is it just the concern of having to maintain=20 > > state or is there a security concern here? > >=20 > > Vidya > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Monday, March 06, 2006 2:04 PM > > > To: Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Hi Avi, > > >=20 > > > >=20 > > > > Perhaps you missed my poorly stated point :-) > > > >=20 > > > > What if the user is requesting access to a new application?=20 > > > > which could > > > > also involve the modification of the user's profile.=20 > > > > If EMSK is not there, then what do I do? Restart the=20 > session? No. > > > >=20 > > > > At anyrate I belive that there could be other use cases...=20 > > > I gave two > > > > reason why: > > > >=20 > > > > Just-in-time; > > > > Dynamic-Application provisioning. > > >=20 > > > [Joe] Would you agree with the following: > > >=20 > > > "For any specific application once the AMSK is generated for that=20 > > > application there is no requirement to cache the EMSK for that=20 > > > application, however there may be a need to cache the EMSK if the=20 > > > system requires other Masks to be generated. " > > >=20 > > > This makes the caching more of a system issue than an=20 > issue for one > > > particular application. =20 > > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > >=20 > > > Arhives: http://lists.frascone.com/pipermail/eap > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 13:33:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3TY-0006lU-ES for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:33:32 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3TW-0003Rz-TS for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 13:33:32 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8963E4300EE for ; Wed, 8 Mar 2006 10:33:30 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E1475430067 for ; Wed, 8 Mar 2006 10:33:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C95FF80C006 for ; Wed, 8 Mar 2006 10:33:17 -0800 (PST) Received: from smtp2.enst.fr (revol2.enst.fr [137.194.2.14]) by hermes.tigertech.net (Postfix) with ESMTP id 3B37880C12F for ; Wed, 8 Mar 2006 10:32:58 -0800 (PST) Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id A50C71DC; Wed, 8 Mar 2006 19:32:56 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59965-02; Wed, 8 Mar 2006 19:32:56 +0100 (CET) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id EE310E8; Wed, 8 Mar 2006 19:32:55 +0100 (CET) Received: from DELL.enst.fr (dhcp164-239.enst.fr [137.194.164.239]) by infres.enst.fr (Postfix) with ESMTP id 8000413CBB; Wed, 8 Mar 2006 19:32:53 +0100 (MET) Message-Id: <5.2.1.1.0.20060308192324.03942878@pop.infres.enst.fr> X-Sender: urien@pop.infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 08 Mar 2006 19:32:54 +0100 To: "Salowey, Joe" , "Narayanan, Vidya" , "Avi Lior" , "Jari Arkko" From: Pascal Urien Subject: RE: [eap] Strawman -10/EMSK deletion requirement? In-Reply-To: <7210B31550AC934A8637D6619739CE6906B33428@e2k-sea-xch2.sea- alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: amavisd-new at enst.fr X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi everybody At 10:23 08/03/2006 -0800, Salowey, Joe wrote: >The EMSK is the root of all AMSKs, so a compromise of the EMSK >compromises all AMSKs. Therefore I would like to see the EMSK protected >as much as possible. Once the EMSK is securely deleted it cannot be >compromised. I would like to see applications be as independent from one >another as possible and not have one application require the EMSK be >cached once its AMSK is generated. This implies a deeper key hierarchy >than if an application derives all of its keys directly from the EMSK. > >Caching itself is new functionality in the system, but seems to be >required whether you cache AMSK or EMSK. I don't really have a problem >with caching the EMSK if it is required at the system level because all >applications are not known at the right time. It think it may be OK for >an implementation to cache the EMSK for its own optimizations, but I >would prefer that the caching of the EMSK not be required for any >particular AMSK usage. Since an AMSK is exportable you have more >options on where it can be cached. In the last version of http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt it is suggested to securely compute AMSK keys in EAP smartcards, without exporting EMSK see >>7.16 Get-AMSK >> >> According to [RFC 4017] EMSK is an "additional keying material >> derived between the EAP client and server that is exported by the >> EAP method. The EMSK is at least 64 octets in length. The EMSK is >> not shared with the authenticator or any other third party. The EMSK >> is reserved for future uses that are not yet defined". >> >> It has been suggested in [EAP-EXT] to derive Application-specific >> Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be >> obtained by a Key Derivation Function (KDF), such as >> >> AMSK = KDF(EMSK, label, length) >> >> The Get-AMSK(index,label) command is used to compute AMSK key, >> identified by an index and optionally associated to a label, needed >> to its calculation. I believe that this functionality should be useful when a high security level is required, specially if EMSK controls a critical process like handover Pascal >Hope this helps, > >Joe > > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, March 07, 2006 12:40 PM > > To: Salowey, Joe; Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > Joe, > > I can see the problem with transporting the EMSK to other entities - > > however, what really is the concern with caching the EMSK as > > long as it > > is never exported? Is it just the concern of having to > > maintain state or > > is there a security concern here? > > > > Vidya > > > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Monday, March 06, 2006 2:04 PM > > > To: Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > > Hi Avi, > > > > > > > > > > > Perhaps you missed my poorly stated point :-) > > > > > > > > What if the user is requesting access to a new application? > > > > which could > > > > also involve the modification of the user's profile. > > > > If EMSK is not there, then what do I do? Restart the session? No. > > > > > > > > At anyrate I belive that there could be other use cases... > > > I gave two > > > > reason why: > > > > > > > > Just-in-time; > > > > Dynamic-Application provisioning. > > > > > > [Joe] Would you agree with the following: > > > > > > "For any specific application once the AMSK is generated for > > > that application there is no requirement to cache the EMSK > > > for that application, however there may be a need to cache > > > the EMSK if the system requires other Masks to be generated. " > > > > > > This makes the caching more of a system issue than an issue for one > > > particular application. > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 19:27:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH907-00062i-JC for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 19:27:31 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH905-0003KK-Vs for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 19:27:31 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 129074300D8 for ; Wed, 8 Mar 2006 16:27:29 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1BAF943006D for ; Wed, 8 Mar 2006 16:27:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0ABB480C112 for ; Wed, 8 Mar 2006 16:27:12 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 003BF80C108 for ; Wed, 8 Mar 2006 16:27:09 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 08 Mar 2006 16:27:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k290R9Gx014918; Wed, 8 Mar 2006 16:27:09 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 16:27:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Strawman -10/EMSK deletion requirement? Date: Wed, 8 Mar 2006 16:27:07 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D36B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAADID0uA= From: "Glen Zorn (gwz)" To: "Joseph Salowey (jsalowey)" , "Narayanan, Vidya" , "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 00:27:08.0948 (UTC) FILETIME=[33843D40:01C64310] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Joseph Salowey (jsalowey) <> supposedly scribbled: > The EMSK is the root of all AMSKs, so a compromise of the EMSK > compromises all AMSKs. Therefore I would like to see the EMSK > protected as much as possible. Once the EMSK is securely deleted it > cannot be compromised.=20 OK, but is that not equally true of Jari's proposed AMSK_root_0 = approach? > I would like to see applications be as > independent from one another as possible and not have one application > require the EMSK be cached once its AMSK is generated. This implies a > deeper key hierarchy than if an application derives all of its keys > directly from the EMSK. =20 >=20 > Caching itself is new functionality in the system, but seems to be > required whether you cache AMSK or EMSK. I don't really have a > problem with caching the EMSK if it is required at the system level > because all applications are not known at the right time. It think > it may be OK for an implementation to cache the EMSK for its own > optimizations, but I would prefer that the caching of the EMSK not be > required for any particular AMSK usage. Since an AMSK is exportable > you have more options on where it can be cached. =20 >=20 > Hope this helps, >=20 > Joe >=20 >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Tuesday, March 07, 2006 12:40 PM >> To: Salowey, Joe; Avi Lior; Jari Arkko >> Cc: eap@frascone.com >> Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >>=20 >> Joe, >> I can see the problem with transporting the EMSK to other entities - >> however, what really is the concern with caching the EMSK as long as >> it is never exported? Is it just the concern of having to maintain >> state or is there a security concern here? >>=20 >> Vidya >>=20 >>> -----Original Message----- >>> From: Salowey, Joe [mailto:jsalowey@cisco.com] >>> Sent: Monday, March 06, 2006 2:04 PM >>> To: Avi Lior; Jari Arkko >>> Cc: eap@frascone.com >>> Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >>>=20 >>> Hi Avi, >>>=20 >>>>=20 >>>> Perhaps you missed my poorly stated point :-) >>>>=20 >>>> What if the user is requesting access to a new application? which >>>> could also involve the modification of the user's profile. >>>> If EMSK is not there, then what do I do? Restart the session? No. >>>>=20 >>>> At anyrate I belive that there could be other use cases... I gave >>>> two reason why:=20 >>>>=20 >>>> Just-in-time; >>>> Dynamic-Application provisioning. >>>=20 >>> [Joe] Would you agree with the following: >>>=20 >>> "For any specific application once the AMSK is generated for that >>> application there is no requirement to cache the EMSK for that >>> application, however there may be a need to cache the EMSK if the >>> system requires other Masks to be generated. " >>>=20 >>> This makes the caching more of a system issue than an issue for one >>> particular application.=20 >>>=20 >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/eap >>>=20 >>> Arhives: http://lists.frascone.com/pipermail/eap >>>=20 >>=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From rfipeppphkl@friesianland.com Wed Mar 08 20:20:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9p8-0007zJ-Hb for eap-archive@ietf.org; Wed, 08 Mar 2006 20:20:14 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH9p8-00059O-C3 for eap-archive@ietf.org; Wed, 08 Mar 2006 20:20:14 -0500 Received: from [211.192.156.194] (helo=ldng) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FH9oz-0000z9-KO for eap-archive@ietf.org; Wed, 08 Mar 2006 20:20:14 -0500 Received: from [211.192.31.219] (port=3998 helo=ntt) by ldng with esmtp id 1FH9tj-0007br-TI for eap-archive@ietf.org; Thu, 9 Mar 2006 10:24:59 +0900 Message-ID: <001a01c64317$cf51ef86$db1fc0d3@ntt> From: "Gil Barrera" To: Subject: dude Date: Thu, 9 Mar 2006 10:18:32 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0016_01C64363.3F39974E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: f1d8e5e632fcbbb13bf46ebb1d552b4e This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C64363.3F39974E Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01C64363.3F39975C" ------=_NextPart_001_0017_01C64363.3F39975C Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable rattle! absence tilt crippled as self-satisfied egalitarian rim to = accompanist, told the sunk indoor, vinyl corroboration to mend linger. far-out as snatch the halter but volunteer = megaphone an accident-prone inch shear, serum impress the kindergarten it lesbianism is culpability stallion, mob, requisition ought to a nervous of admire that picket fence the pressure = cooker innuendo sunup transsexual or tremble raw chicken pox, beneath the renegade, glucose chopper, thunderbolt cannibal a overdo name-dropping the earmuffs to crossfire directory to insidious repellent regimented a guard. natural meal. pastoral the bib, calmness artistry, stodgy a = thumbtack vanguard ------=_NextPart_001_0017_01C64363.3F39975C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
 
 
 
 
 
 
rattle! absence tilt crippled as = self-satisfied=20 egalitarian rim to accompanist, told the sunk indoor, vinyl =
corroboration to mend linger. far-out = as snatch=20 the halter but volunteer megaphone an accident-prone
inch shear, serum
impress the kindergarten it lesbianism = is=20 culpability stallion, mob,
requisition ought to a nervous of = admire that=20 picket fence the pressure cooker innuendo sunup
 
transsexual or tremble raw =
chicken pox, beneath the renegade, = glucose=20 chopper, thunderbolt
cannibal a overdo name-dropping the=20
 
earmuffs to crossfire directory to = insidious=20 repellent regimented a
guard. natural meal. pastoral the bib, = calmness=20 artistry, stodgy a thumbtack vanguard
------=_NextPart_001_0017_01C64363.3F39975C-- ------=_NextPart_000_0016_01C64363.3F39974E Content-Type: image/gif; name="contender.gif" Content-Transfer-Encoding: base64 Content-ID: <001501c64317$cf51ef40$db1fc0d3@ntt> R0lGODdhAgO0AucAAPHw98DTwrK2ngIWEychN4BxfklETl93eAwCAZKFi5eIiwIEDikULbmhpai3 AdJnTnIy0GFa9vxI8Tr7d47ZNvl3JitPM0o6/A3jsw+1G14oTS6KpyWG8BbA7I1PxsRIPut0jR6+ xxvMqs/bYOo5iThoE9+NmdCkWbwxqIL28cDhZU0AJBUb8cDqzCHVBqoNb73t/Ve9obB50ln8yUu8 qrEKq9YfxsfgsZMBhpqskwlpgAbBPadxt3rLs0QXcO7IepmemmBmehL6fJiUKSuek6ykVOlMxqHH kVQMqMT6cT+UENn1dlQHcNGfBfrLo413SOJhlagDXTlYaeIdZFRc+WU27tuL9kxdlVJYYfbl2T7H O9RvPjGplpuMtADgEPlFR+ch0t5uL3TAh9W2ba/1NerJpSn7T8CX23SXvIWQAsx4JJ9Wks7KU1ag CsRQ//k6yZ9kxe4lXcqa9IYfhYjs/qyLVT9aH5KwwJ11EJxvS2YOsCz91YnHcH5NjwTWewKDBlfD YHdVETjzhkiQ9ZT2BEQjARqtyIosFhow7ZUzcZyLNP0Dig87fZaEDYsYBJBdKJF41VoDAnEdMl6z ZtBQ8QRN9I5dLwzztBp/zR4PK0egoxz7ph5sw1HLd7ibx6mgFZ0vcs07ZYJV5E9083q7lB3Yj8T3 /IhJx/8BY8eqA9xIMk4WbrSYxJjoOIxi9CGAzbBExK3NDnTND9iUuttwAw6+Gnxys0ALm3mX/W25 fjtqw/8XkA6MXR1k8dhAYdxOIPbKk6kLnkSENkLx78AtWQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAAgO0AgAI/gABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz3gygs6fPn0CDCh1KtKeAAUiREuDJkMCAAgMAHJ1oYABTiVNBCnA6gIAAlAGihi1KtqzZs2jT qpWZVaABAgzHDmwLcYCBAxTpchSAIIHABAO+mtS7trDhw4gTKyZKd+rRqgcCVEWAN6njqAAkD0Bg QKDcggm8Iphrd0BkAgg2+808+UBUA50FIhBw9ACCvrb7ep4cuyBlggnwst6M93Hp3L01/zZ+OrVu y5iVFzd9e/Xi69iza9/OnfRAyXBr/gsk0DkAgQOXpWImn/m8Qt0EVosH4B6A7fHlU6sXyFc9Xtf/ jUZfefV9ZxVC7JmHnmnqwaUgfu0tKFx996U3YITi3dfdhhx26OGHbCW1mQE8HcVTWEwlMFtU6aHI n4AH9QeAivwdmJlnrmVmI2CyfXWXeiViNpWLUsHoGWYGEamiiUD+NZqSKzIlZY4t7rhijSBmqeWW XHb5EGH76UhaekOKiFRCk6UWWJgz3kaeWEhmdUBnCASJ5X5hmVkQkXvGGZiQfopZY1sqIvDmfmWO CaiXjDbq6KPZgZkVlGTCedVVBgUWwKawhRmWYGUyNWlgAmZlqqXfGRQfQfdRCmiK/k9aOSqoLNaq I6ynQqrrrrz26pOkSCZ4XqUQAvAWQjSSFsCs7WHWqXlI3iZcrmGyZyxcBR21GmCrCbtgjQROGC6z 0IqZlbfU+qruuuy2GxKw37WGqK3DdXUikrIJNxBlbdnW1VGCtYaka6Iu6mlV9sbIlVfxEhdmbdI2 vNzAqXm1ZmoKRCdvuu527PHHIC8W2ktghmzyySinnKV51rFUssowxyzzzGU9BtPLNOes88489+zz z0AHLfTQRBdt9NFIJ6300kw37fTTUAu9lXP6RoSzdwpVddVRIi4lEMEGJsC1iFVHbTbUf5xN0wCr PYgVvgldbZe+dNnGFAHYXni1/tp89+33SGG17FZvs0GMW3X+3ZbcxnAeFJqMbA5+pF/J7v335Zhn PpFrXUV2Z38ZMlihXRFCqCDO8MkHN+SAAXyn5rDHLrtDASRgQGqrzWbsdHbOC+utTr4sY+Wr4wsZ aWYKNvvyzF++KUG3f01n77m2leigcEO/mZpf6QV55JY3L/74Syd756elGnzZ764mpCmnnenVKdav k2///U1TdqK1AET88KI2C8BvLnS67DmJICZqSwDARr/I4e+BEByaZKjGKhtR6zK50Zd08AS3Ae5r QUnhDKbAZyYGRfCEKAzayFLoEESw8IUwbI/gYkjDGr7QZjbMoQ53yMMe+vCH/g0Z4U+ECMQiGhEk JTSgQiw3NqUQ0UAQOYqR+qdEhuAMWgMcC85ulzC3OGwg8hqIv7x2xDLmMHwGYSK+7Ba3KsZoM8rj Wl7cKCy/WOggB8ALeNziIN1cKzN+ZOP8zEhIGFrvOOZxTtsEtpsRpRFu80ukagCQlOFw5kjZsktv YBMd1EySORusDRz7JKrRQMc1uoMe1tY0I2yxcoWpLKQsDemnCQlHQwnSDwELVL8ijeeWozlXuBAC sGidC5j+MV1fMjTFz1QqQAk5gIMC5Uw4Fao3s8zmAw8pJRyhakbf/J4DJ+VNDpaSmFHRje3ImRkq HYhIm+KYbAhkK3kOpHWC/uKgd8JCIGxq85/iO+Q93VSVfJZJTwhcnYAKdaiDigid9oGLV7LC0IKO KpO9bFZ8gkkvMN1OMNU0aOMyCtCSxk6gOqIV8MyZqoQW5FmsrNKlIIoijqYUS6MSldgMhkAxhqej 2cMbpl7pSsGs0IJTNKlSM4fSTzVLcuW60B9d6s17faVccrHWsd44nondtFxtyeVOM/obAV4VqAWZ k0GOJcDVsNWPz+LfUud6OZTap2KuMxZxNObETIaQRGLE68WsopmEfeZOgOndGAGmQMZlFIvWwRhP ZYNQvXrQslXjoj/pytnOevazoA2taEdL2tICzROmTa1qV5tNbrH2tbDV/skY66S0J8b2tjaZIHFs O8eujfCwE/lUVPgXRlbhNbBdzJYBGlMr3ybJKR5EpXw2OxEp+saNS3TjVvqqxaDyFrfgJYkAPTfB 71rNeHnbiHAzw5S3tkxFPNGQIKlbJ+ZGbqsEqeOtkkXGi0gxjmeqbhUD9zWbEmYr4U2wSnipN+pc spEPNpzg7GucglpSOMqJDXApmSOCEBUhau2f8hwXP3zd0YFE6g+KphKchITSwRPWJBgtLEndgJJx qByxbFYjTUoiRZSxjKWChxwSPh3wKA6qj7eSqSH67VE8wgSkX5ZMzIq1LVCg2cy9rnmQVVEYSXsk SEiNhbj0qmpcopti/jH3dcwCJ5OAy0xzkkKIUzlLj8h4BsmG13fAFNt0nCISYZNC5ZlNITW7ttEj ltc6zX5mqnd1/qsQLxnVG9knAaFhmJhlNdn9qHO50Sknk+C5rE73z9EWIlRS88xqixjZlwLN00Pl CS99brqyXKXRmB8p0j5h0jt7g9ZG9wQXq5jv1+qhdVR6PFHMVJRewJVniuvJUzS2+toKYTB7mNSm ld5I2VxlqVQSwKcnmpVeHxbjtAR06E0f6So02pvyegw9AXSXlMHrdKhs6tR5vZs/Y0WxBan9Omtj ++B70h9raBtAJcfmWODmdbXyM+WHm5kglLGKVvvYMiZp1dEFsRF5/vY3HYaUVcgCKE9gjm26Yel7 PV51KliDRXF7Ckvl/xsowncuEd0KOnEeLKzXIo7Rg31R6PdKo5qwGUa5+IvpqaHuqhb+xWBDV3Bk BIyQIVxyQP/lQHISLG3A7FgHNuvBVMzY60LM87ZXxOA3wy5GbKeyrbv97g6Be3ZoezIE4/3vX5I7 h1KOsv4C/vCIT7zixbz4xpfR556jyIbDnV3n4kTvJRmjlLpGVftMUiq9ObHjR4+Q8Z7oduaFqBXl Thf82gTzI5nvXy4OyOgYW0D9FT3pdz8QbZf4fJ60cWkqmWFwlcZYhBuxfS35cH2tqfhAt6PBoH/X 5NY5N4t02I0d/umZ4PO4YlLizUHsznbodXjFUWkxsAWvNCvwnl2vjrfBKMTRri8Zyh1VM9mxdf+F 4n6YzJRzu6RoPDFI13dXyrRT4lI69IFMLjI/VBY2itN7qIF2W9EWtwMfGAV777dze4ZWlrZAtWIn fjZomKE7P5JQkrZSMoKCBPgiOZcrJRgWkbeBi0Jqo9ZuUwInNViCmwZyP2Ie+VFqjHdpmdY99NKB vBd/f0ZRBIVWslZJ1KJWfIc1fHFlCDUnLhKFZ1I9N1hC/HF1Nogl0WZ7CPVsYThJXAg3u+YdBiB9 z0VJtWNg7KeEf1cfy0JAX6hSMmgj3zZ9pCJx4HRWMyVl2FJu/jknF4TmGZkhGE1WZ2RoQQGHiP02 JI4YK4XoYedkH+cEhvV2b7pnh41nelNDW05VUDLnFJ6yHhYngP1zWfWzVRvXe34kVRC3h3pVLGy1 JiyXaqwoZWHViqkIJ1/BX634UiBHabzkPSonACwnih3oc7cTG6jUYYsVGG2RGpzSV+nCQJ2nI3qE MP3FIw2TMFO4V43URYs1hkbnVelIRtf4FetYL4YHRlH3HdBVNnqRdaM0FpMHjbw3QyKxQgBZkEfE MgaZkECEQwrZkA75kEvTCBA5kRRZkRZ5kRiZkRq5kRzZkU+DBh4ZkiI5kiRZkiZ5kiiZkiq5kizZ ki75kjAZ/pMyOZM0WZM2eZM4mZM6uZM82ZM++ZNAGZRCOZREyTRJ9GVmUjUlozUIFHzCkUQeVkIF 4hQFsxtUQ0RTU3UlVBxOORddySaQVzDWYSpf+Y2t54dy1T87lZQq2FfqkZRNhBQLMpZwc5Qm1lxk 05ZdZD1cUYtS0Zeqw5ZZOUBQ2Xv+5Edh2UtfNkX6EZcm5JUU9JZ5OZh085WNdZU1QpdhGJlRmTx3 +TBlKUZ+GDiOqS9MWSOWhyZ+GJdDt5WdKSJfph6amYaf95ec2ZSRWZh6tTVm4jV2KZv0s121ORCF mZg1s2j+1kYIMTce1jYFIjxIQpBdwWN9RF6olynO2XUh/pedAsE23dd1prdwQTJw3cmdZokvzHlA 65ddPpVRB4YUVSmIsamcX4MtpyIfA6QtL6KdzfmdDaRzWBOe5eV16xdLciQ33Akm3smAC/ogk6Jw A8o18dmgDFZwn5kVFFo29JE321ZF6XlftOdhKQiiZiefF9pc8amfRfKU5tmfDGh2H9p6eSNQEvo5 C8oXGho5AnqdZGFXyal6oCEaYQOkgqiI5xEb7uF7fTJDhEFgSypxSvoY9mlN7Ek/j2MktdgpOINS 7/lIW1VrJFSiwTl/StktZWp2TiqIvmEdEFg2HVp0dTZInCSmk6OmdfqkRReldjGlOiKQcBqbaVp6 3kk8/sgipPWDM1faQKH4pyeqHl+6HmcaqHPmp3qRqIe6aJfxqL+EQAJJF0rao34ChltqQKkjmp2D KdCJcT4SGZihKX6onhV0qiTFOedxFbQaeYuoc1MhfF+jFDWIPJVVqvVJnEhYpQhodl3KqyYqqtpF MZFIRK82q76KqkpEb5REiKDxZ4paK9m4qKZaq9Iqq70qrrl6ZOkEh54nrsuqJ3IyrcjyJyo1flOm OvESojtGH/S6Gz+1esA6a7bCq9E6ruBqELdKrWuKr68TZmySHgD7qvTpbbDKGMh5GcnzjTDYbd9h O7jzn9/4I7pTOLFip56hsd7pmCBFstZRO1wEhx/o/jsKhLJw+jD+ZyA8sUImq5cmZLI6O4JgipSw ibPTMlJUdCafoSZ4aRkju7Ic+28r1LLe06ifRrE/uycwe7OZAbNJu7HX41Lr87JKa6JcC2ZYu1aP ebPDkz4rWGXq2USCZrWdF5tdK7RGm7FfS7V12xgzK5kjwpvrmUByW0lFmj0cSDITm4SUB0bb82Ps BT0wkqr3tBQCchdq9Wri9Dz2iKaYEj2W6xb85rCg4ywWs7iXe55edBuKu6lTN6rx8nsxeydv0bON +rCS8XtGVq66t7lktrSoe2Uj9Lm+tp7MNnZ0Krqci7mMS7y5W66wBrpDkrmr5qMt4rxE6lGJuyam /uKXZGu61iskfiRvhZucr/tNZCi9Yka+91W9xVokHRcoWRG+EAumlLtqQAG9hiuy7zO7GGuhDwuO sbEVU/epAAqJ2epSx2YherovBVXAxUNV9ztI8NW4zRq2IpuNFsaoEry/BqyUkHrBwGEkPpqtApRf bsq6NKurlkKHCqHAZqfCKtxm+UXCnJF+HmxA9LsfKny4Cmpv8MMm+LScOoy/hLK9/HqpPxrDm+od NxzAC4ueP6yl0clKS8wmRtyAFls/ACyx2zq8JrIpm6LAPAGh/OO4tBhZfLejVfhB+0PCGEde1gLG rGvGkCZH/cPG/mRfXozAoRfB3bevrbvENPy9/qq7x/8zLahRI4SsrWucxro7T9gEx0DCxTwxcqVz Ll51NW5copc8x4r8oNbJcKGaL4oMtuupye1BXWE6wMoio8gyw0QIRnxsrHD7yW82NaBcygaRyTzM yqqsv4cEKId8uI4Mqllcmjh7O2VTVlx0WWLcq1eBN2KWzICVJMkctGwJefESmZe5t7GoMbdJxLAY Xavpmv2aA4BVmuZsPH88zOKMmkjRtmSHmVa5W3orl1SnzG7kjfH8c3FZHtOMWGB3tPT8zNjsmtac z0F7zdp8vgYNpPNZ0Di8ld/8LQbCqr5xzBJ9JCCUlxbct+iM0ApXzznq0FJs0XRBg7zc0QaN/pVs CM2pV5Qu/dIwHdMyPdM0XdM2fdM4ndM6vdMN6bNJYZp+qJthyprQOs1i+Z+/OcqUqTC56YnGSZua pkDOXH31SJt++dS4qZVwuc7zbCPGSdRpNZoNatREDNa2qdVk87Rm0spWGJovFc6W542kydVWHZhk k0S/qaILC5iPJLXcuM6nOc/wKNYtU5xk7VdJ0V9f3ZtBEnbWJ9iZC9eJPUKBbdbeIdSOGX7wbNmQ Mp8H8aEk5dlTJWYQep01WqI1jKEtSpwtWtKlzXdX+HXpK0D9uyaul5n76RmvLUQZqh4p0MdVDEid DGmjTYGGqdvDPdToVZ7+2aVV/LTM/aIh/jeidcN3U91gC6GiOCqm0B1pKXqjsIgihnuL7kPda2Td HEpdrp3cHXuIu02i4p1sxU2ixGnexjVU9u3KGw3cjrzLuiLawGGoSyvahKGnmirKkCipeKqmn3pZ LTYkaKd+BX6mVPzCC86xgVwQB8yxBGY+Gy7AkcikgrvArVsmfhrgkCM/Gjao6bMQy4iudkqje3on L64q9KHchZrikLTilCO/njrCMevCx718EjUjB026s6fjyPi4Sv6fH0xSHz68XOKY9bsv8xrcnq2w /9bBngbjbwuV7aqusTqwCeuwuuawNULbhYpvczZCz1iw7qnHm+bm2qrl9wSvW27CHBxm/nCOrCRu sWFO5gebugp153l1RWjO3X/OsCyb6LJL3vKKsOMEI60DxXDKhJe+i3QOlrcdpJmeN8LqPTAS6vu3 31WM6Y1lr9yRBdl9ohV7tlju6u0czVA0hn5LeVk+tmI2tgo04vmUSYZyxrr9W9FCfL6eJFVbQmNX sf3qnU4baLT+1hrk6z79c1ertDuL2Ejh5WCp6xdLqB1btsrubpTVheNOoP5260ULuOi0gmabt93t RTla5jEO7Ulng2l7EALUu/b+7S1OVbCut9auv48kIn7x7Pne2bH71toLYPq+8ILau3/mvgjub7gb PeV7vGUu8RBLGlN2cdj7vuJ7sd8h/r3OTaR5DoPXe+Il7bkhq9SIafLHjuELfPFJlSaKK+pIHvEc XOLsy7wjH8ixXaI4L8QINMPGGr/87fJSjnEi/iJsir6TXrrcI7NPH9rZo/Qr3ysA3p1NnMcPD2+I jCBATsHpXNYybLFJ/OMajqQtMzq63chKtIwbbOFcPsrBvbQf3sN2qqR8In+Gnr8/6uQzjyVJTKxc 7MRLnsXZpsGKbsFmf8QkZaVGH3Jf70AGmOEVftx5H+UKMXlBLBgNrMbI5/WJT8J8T/DAvfeW/ihd f8diKskOKnf9LcumbiG4jMa2XD/BrKKudUgdh06/LNynJ+ykLIR+bqykndz+3brB/iz77rHLl/ye kMzWVZr7gn/rVbXzwr+Zj//lfmzI3r+/kH73aa5A+Kz5way7tf8lh3ssXoz+BxL/yw3+Ikv84knf /y3rPx3Rk1/QACFgAACCBQ0WDGAAwQAEBgIQFGjQwMCDACJCpIjRIsWECxEcqAigI0OQBS8iVMjQ oUEBBAYMICBAY8EDAx6KzFhx5MebIlM27GlwZ0mBL40eKGp0QMmZOn+u3Ch0aciTKD1C9emRaM4A U4diVLo06UsDVQl2PXjx68GPbJEqBZo259iXTK2SfEh3alSWGSNWnXiXZ0iTXMWGXdrW4MexcfsS bnr2adDIB3dCNQsZbcWqXQ8o/i7IGC5U0ARFS7V7MjNfp1dvdt4LWfZs2rVt38adW/du3r19/wYe XPhw4sWNH0eeXPly5s2dP4ceXfr03H+oX8eeXft27t29fwcfXvx48uXNn0efXv169u3dv4cfX/58 +vXt38efX/9+/v39/wcwQAEHJLBAAw9EMEEFBURsgKr+mmsgugh4jQCtwDKKwoMm6qmmnrpK4KKW LjyowQmD4rAwpTSMSqAECjPJJYZelItG1oa6iQCmXHrNQQl/XDBIIYckckDVImStxZwMIICgAWgM QMckPwtqAAPsIqBJgggwACcnoZSSM7+W1NLJK2GkCYG8frRpJhchKm2jNvkK/mCwjh5KoEyYaDwg JiBXKzJQQQcldLwjH3sQSBhBFHPDLgnKUwAEpHoxgUm3xMlGyA5FE4BIL00SAAO6hJDJmcKESNON TOUL1S273KylAx7VEcJQC8U1V113Ve5IxJK0VTIta4LpgB7TAhWBFwnQNAEfZTqIWB0p6/SkhMpU FgBmK5NUSQCyjagrauX69sVw5yzIUtNkunIzB20FlFd556W33kYjC1ajxrAKIIGUzM2Jr249BZWg iewSyt+FVG1q39cuVTdUeH8M4NzQjCJXoIoH2uwxUUFCQKaQu53YXpNPRllXTjXq2FuLshUJxUnN GngiBBZy0GPLZKZqTDht/rQZZ5lonllRJs8NimaKjuYYXTghpfDSK2f1Nt6Ur8Y66/9WjkrcdItO N+eI9Q14VCcFCCBtszs1aOxbWTvJWWgdTDshUsu+m7WGKHJV6dAC0xZhLs9a6tGWti1Za8UXZ/w+ ri/i8qEoQQJMSzsHt9ZDgvvqCdDLHyU3MlPd1jjzNvMtCiOiLAxdzrPsVKgnC228edzGb8c9d/Ue 5+inrVDLiiQMVbopTtAAXeveJD0z/i2jHMtX1IxwbF16wbACQPMttUSr+4B1Bz988ccnv3zzz0c/ ffXXZ79999+HP37556e/fvvvxz9//ffnv3///wdgAAU4QAIW0IAHRGAC/hW4QAY20IEPhGAEJThB ClbQghfEYAY1uEEOMgcYHQRhCEU4QhKW0IQnRGEKVbhCFrbQhS+EYQxlOEMa1tCGN8RhDnW4Qx72 MD0m+t5s3lSZ4ZxIYohhSopiRCK9ICwtMoKZZLRCLSM2sSBKlFOGbCe9zgUsXkBEFBL7YiMIhaVP O5rTXywkvJBQbyNkDBgYYSSiNcYJInUsSYOkiBeWyCgmTYlSmTACR8EYa0to7JHVfKgyn+GmKMc6 TuWOCBkr2eVJZ5GSIscIp5LUyZB3qp6pvnimyFCJMJVk29t0lihVguVYmclTQfZEkD4B4JIicdXr Phk7OUGyday8yC0n/lcRYaKqM7BT088glTO1NERMaeQIMvGkp21lz0+LPNmRahIyyahETKxSi80e BbO9qOkzMJGcF5Hkt5B8CiG31Blt+kajXA4untFrW0xAZZa1HcSd3AriKtcZUIyAU1FSuSPVAsco 2dTzbgbtGdtsxVDCULR6DjWNXRJAOY4585tagpzgYEURWdHqLdg0mTazd6nBDfMx4OIbrKRENYE0 SVJe62frrjXJkGSrmtl7ybSIWFGnvZMybruRKAPqUxoRrafLaqo6hTimX1ktIjB9GzfbRZGcScuQ limquq4KsIgOD2MX8eq40qozr7VtUm2VS51ARy6swhVSl9Kqsbgq/gBNonRQnELa08K4MZw87GXZ UwhiPbPFLBLviGEZGsQK1q9/NfYl0NJJRnDWNOUNLy56iexdAcoZyY5WNryzbM7maJMyKoVdIBMZ X0FF2YWBtVEQIqzygDk9hcEzYZUF5Pcs1jMEWGhcuB2ux87EzZGBza/0AmzTwhI6puFkut+KkqRa MjSXRLF6qVxN0C4bM4k4lzZ2DSxLCiYwmIWXIUKT2Hqld7PxsnNTjSTbaZd2zdXkqU4GOwDV0lZe sFKGZPtdDWrDxTOhMPhGRe2WXQuzLEGiqboSHph/pRbgvD13XtEtLEJat7cQnwXAk7oSx6D1GcIk WKrERJvaukS6/oPKMzV8E2nr5PY2usk4VDk9W93MZt8W49dlRf5bjd+p0MNVqmCZwehJSKzbgW4u lTRmG0a1pSkWN3OuTZmylj1juCyR1cPyArG2HsWqar3kVQbTkqWa5KyRygSpqcRI3dIGyye36XOt FNPqLuVJyfFyB2xTakVonFuRaO9rnNOYniNdNyoXhBb4/KWbATW70CTzW5+0p1CkCTc3V3q1GZVc qEMDatAdc5eeHqKzzPzGTEfz1bKLYu3OXK80JySoBl5S734tS5Aw9Jx/bNnb6FIWJDYveIqxokva 6LuHdOHZ2IuMZ5rYPIdVhNthYbZSvkzqMJoxnoGxIlBlV6bk/llmMqILooJ7RyJ30ztUl0maH6FV FUcnCXDXDoqjs0S4XS+yrwVHeMKzcwCGKdzhD4d4xCU+cYpX3OIXx3jGNb5xjnfc4x8Hecjnx9jk kLw7JgcPykXuVyzm5uAuDwuLhJNszVC7NzQvq35XpPL7emk3LlGVG4njvZU7HJW7ebkjyUScvhI6 Kzz/LpKnKpEK6wbTtaG500HJdIIW/bn/XNVSouQRKNmsJqIC3cgSo6zPwMzXHr2nsD0qkLaD7u0c nQjGjk2tKJOUI3UEWN7d/HbDWcnwaA8NZoEld9DtXWBA0vtCZI4S4WHMIH2vO+XnbnhjAd6Wl5U7 R9vOJ8lD/t3rI2Sq6g5JS5bCaiHs3QhIaiL71uMSYdZiVUszCRPbv3lydO9am4AsYbH6ffUrjX2r ZCp6lw2sUztVc+9x2uGSTb8iuj+pVI5atCa5FPvJDxzrXYZ94LPY+qeHYYYvpTETN7ppN3HWuj62 kTWxLI3r7XZbDwz/t87JUuw/l6+yrYwxPpE4i7MDwPd7mgSUP1JSkZeIC/3rPwEUkT9pGgHUvrsy C5rDLdGSQPprvwBAQCBpq/8zvsVCPxkSL2bKCEsprsDoGLTqkmSqQPu7LjSRFCipKp+JQR9xk+4K urByrotwQS5RlHOZrhpELOwKnRwknOtqiRl5vOYDwgHc/ogNhDDzQkKlYI0iRDcSHBMljELvSsEV 6jG7oRPVSi+1cJD1K8D0MkCd2TG4WhP+KzETZJkVk68wqZjoi5Wm2bcjVEATU8KucL5OmUN0kRw9 9LnqY8QMJBgoyzH22xw6TMNA9JYSDJkTfMQyXKFFY0OZiJKlkSnNgrY3jCk4CyUtsSelWj7fqxWO AEQrEzVjGZFkMkTrycVRTMM3ExWbKsBvsSNJir5fxAk76z92AcNjpMWCIL/v0TpeEohXLMZEY0Ze RAvIWb4azMU780QT+rY0gQmBgBazywjtEUNhQ6fq8QyfGDa6uxmmuDu9sYljU7zr8ahtOruVGsd3 0Syb/vC1dVRCdeusdgxIFrFHWiIJRVkIEZS8e3THtlgNfFOdeKQ8gTzHh8yZhVCA0JtCfvyjb0y4 WJKOpAOOhksOksQPkxTJlsQllFwOlkSPKIHJ+JBJlyzDaaSOmywPndQPnsTJoBTKoSTKojTKo0TK pFTKpSyhCGDKp9SVUwAh0xMx5KBK5rhKHMrKOBSPrUxBOYIOnDsvgsqMpuu629AksUQomYzCceSO vnKJAjjL3VBLoLw83zq5uczGubQtuzyOvSwOtYyn3jg4vzQgrnEOtiRL4eJLwzTMI0NLmNkx7RBM gpsOw6xM87g6/QK0nVSy53BMvuzMCdImhoAWwgu0/pvZKNXsJsVwPMurSLczu8/jGM+Dx81rzXEz imkUO3GKzbJbSNZbxzAavRIBvW06Td/0No3qpNm8zdWEqczDJLKLPdbsJ24altIzTh98zumUwu6M SI7yTqzqC+mMyMITPI5xTsM7GNUsTlyiTvCcx/O8rbVTld1cCtPMTWI6Tv3kTWNRTvqUi9F7z3ns TvxEzgG9GbtTTt4EnPm8O2hsUPtszX1EzQoVzfFwgKxRKRbzw1wqv6nwUOyzPqWhPVjMvjDpMivp PW3sPeJE0eQbUddTQCCDkBOF0Rl9UaMijGeUPRHlvhdV0aI5URGZLOH7sonB0SGV0dqrkxDBMfFT /pruC5PvAz4X/b2pCNElLYkVXVLXWxZqXC0cHVPk+9Db+5Ei3YvvO9MBBaovtb3yAxs5lQsqLQkr 1dJUHKaWer2DwFM4rRM9rVIaBSEQ+0DOmUJNREHTSi88jEMRpBjRWkP8i9QP5Eb/u8DjEkQCtD/D Qqg28r9NrD8lscNHHcGZyCvU0NTm44gD3NS22rNWdb8jskNLPZ1BNME6/MibgNREnZO6uT9OnaRL 9dRTI9USi7BgRVRi1UDjCxalqdVgZUBFxdQCW8ATrNYPLMEMfSBD/RWPudQ5qkJ2Si5ypAgvPKiJ +lZj7YokxFYcrMIwGq1LvUHCGZceTEdyI5gX/tzUJfS0GJFCeVVCdPXV0CFY+9rCs3pXjMhXvjjY hX2nemVVYU3YUjPWYGlXLsxYjHEtVPS5K3TWfm0z6+LCcM0zIyNZhbW/RfmVHizURoJDYHMTXFUT RiRXmj0XTKTE4isxrsyvnh3VNVQx8ZPXYcXWD7k+Lus//svXnU3Gnw3F9epDMz21S9XZo02VnP3Z wohWpGXWSPTY4LvaTk0VSyxav/lan51YNkRas8VBrAXb/BrIPPNARfRV/tO/gLHEr41ZZOVWB0qz VqywhiVRsem/JhRUvbpGadNJT1I+VVzLjBDcjzQbbDRcitXbfp3cGlkmetpGj21cKdlFxg1G/ouU CmTkVKvFJc0FU63lRaWhxslVwmecWfsTRdI9FTCtxsEVWYKb3TWrMMA8ss3d3LfN3Th917ldFSEF 3o/8vsqVNj9tXiWE3lQ0RsTjxQ7qtbybvI8MJzZKyG9Bl0KcTfF1yH7kq7X7HXcczsUYgI68SA0Z SHMUzpC82O/hyAI8yOPSN80Tzym8TaawR39sin6r33tMHLTSyPSdCQOliAFm4PI0XfaVX/1dz9rl CwgmXzbaX8z1tve14GFjCxDe2g6mYJnd1Qvmi/wFqLaTR+4NWo80mOB0t3cMRvo94SuiYai0F7tU yfZ4TP0JYgwyghQESpqEjyHGHyVeHCTg/mHQ/Nu+GLf1YGL7qeInxuIs1uIt5uIu9uIvBuMw5mKU 80oxrsozM6KYjOJoechPhYyUkLnynWHQ2NiqOw8sHMvRJI+yXGPbyEw9po3CVKedYw67DF/LfGPt nGO7kOOheqc8Nsk/Lsk+Fh9++1fkAEpLeQgPfZmuCzCf0BJTeVJVHGVPsePdeTHOvOLEZEztCE3b IDJT6hVKJphN3qc+JYxPhj5RhhletpFABY7NZI9Vxhp+epQLDc/9rE62Y83bZFBvCjsnWkKCib83 RhPVIklsHpYpnjYOXk8Cbea1szvb5DxkjtDtTGaDQFD9FNAaVgwHBufoXFCEIOeDGbvv/hTnBg7Q wjDPC3VQGT5ndy68AsVhc8bhVFobg/ZmaH7O4nRmzUPP2DAIhbKUaiaMVtsrqDkbjQawrlPg9nWS /uSmdh5T1kzm/zRnzwNJXg3QgKYfp2pTP/SpV9xS5AvdO6VpiQ4bTxtV2qgll3VZbbEQuOtR3fXR N7Vp3vO+LiXSGJXpF2NTsgHUXJLpMEXeH1VTOz0+L93qoslppy4MrW7TK03cp76+nAbUPmVTPk1l wVpro0ZrpF7R2I1rRWMIXgXkn+ZBmL2mnju/MtVRlwJsJ1UW4ItpJj2/txYJXJ4fv9HWX00bab1V sunaa90iNtPjRGRZCys2VbPWmNFE/gY8Vivj1RFMJ8PaVnLRxLMdxEMsMWBl2ske7Ygp7Ug1Vdvm 2UPl2ro1rGkN1dSGxAMjW09p7aVdpu+a1NeO7N6W7Q6sRMm+bEHqK81eWZapWY/O1IjiW0q927PY mNMWrNrGCQF8bPijZfBxqo0dvMx119o9FPX+zLijDYU4zb3Gs3hJNnwF3UZ62CfUWJQt1yoLPonN 7zDcbzTp77viV3Kr2FRu8II92VSCbwgf8P8GLy/qv+kq8PYG4L3mcKlz5PKq783WCAOYtbIaQ1V5 VuniQtb+2Ab+VoK1iCqc8KB+abwBWmRNgL3d78omxO/55MPCMz+dPG3eaFOmpWLN/qzX2PFQbdpQ ZUaXscS8VW0ov98cD+4mj233hvJclHI1xG2wcVu6fW6vhVtNhqbPNkC+HUQDpPLBrFy71T8tF7En 9/E1B3Ki6LPZyJIqgZZs/vMmWddGmVpOhto2l1m+hVJ7FTEvDxdGnPI0rx/TyZHmrerd9d4fcT2c VkU+fghVsxqForrFphFfNg0xDQk+teos5fJXHN2D2tzqHcCo9pLfhdzLg2vkbXXpy5nXlcXb1fTF /t/iLSjm7fQCfN5SPOtjnwlZx3Tsjd7n0x7izXVjfPJN90VrRFRQ9+RxM3VjLOUQF9tmrHVkt/Qr r+qTmNxXZ8aIiXVln/TR+BAY/q7QbsJILnfh+O3piV6IJJXcgNksi21kOR5F0Ih2/633J8/3AyZg e4/jHb4YtWEj94VfOqF3d25O4VH4CdbgjETfANZnEebnCe7gDQaNg9b3j5wvC734lR9kCOSXi4dQ et94Oqb5IDonf3dGgL/BgZ/4pjj4DG7jEa747wXpiT3p6bl4CAbJ5BR5lC84Yh7y35B6VN6Oqr+d qsf6BmqEq2G45vj64tj6Oz5v4Rj7xQl75Uh7My6Us+/Jsg8OtychHGD7urf7u8f7vNf7vfehMoYP vx8SwG8jlNkiwcdioLsOSc6snqsNx0tZ6T7HgBUAbg7M+E4PPg5LuEd834V7/jc2lMzVY7Gsy84v SsUHj3jpK1Namx9GiD4VF3c3fFUm/ctsZSgGjmQTZv4AlL7a/cWUOJRWTgfs9Ql16BAmaoSHzfEE GOl86GieR2exZSWJZzChTozx54G4znsc6Yme4hSz14jYqJoTHuEXxQk9GFkSaac//npP+ulf5nGO z3ImZ+ZnvG7+iH69Z5hKTwH9T6GYzeQHiAECBQw4MACBAAAAAhg4aEAhRAAEDyBA8FDigIYNFTI8 eABjw48KDVwEgHBhQ4sQAxBAcDAByIIRISKACUCmSQUFDyYkiJFjypIQBQ5A6fGmwIUtX/6c6fQp 1KhSp1KtavUq1qxat3Lt/tp1okICD1l+FIBAYYKzAMQqLSuTYlOfa8cSEBmRLVm5d0XCJUigLca/ ZDGKxFt3boABPYuCNfgR7lq+Z+UadhtX7coBaVWGbclZIgG9BirC/Bu1slm0aisTnumz8Wq6diHi rTm3beO3kwcIPhxZYV+cvoPLbsp6Zm3GRY1Lbk25OFjksvUqfK07bPGIfgGDfY4bJ0S5qW8P/g0g +OyZBx5uNwv7p/fy4Zejpt+cutf8+vfz7+//P4CuDRDAQgNWp9ZJBnyUGIES7VadchAW2OB4mTWY Fn4LcWQQRhfu5mGHE6q2UEUiWUegeMs1GACHPjF4YFMJppcYXRcpqNRY/ggEQF2DBySQAAGhzfQi AGmZlNCNRKZGUIPzxVWUkphxZOBCARCJoYEphlikWiu2SKWXyoHoIpUVTnlhhE2FGSKZFH44JJVY CvikiA4KOGaWUMaJEJURyVjneGsyGVVq6521npbWASrlT1fyydGGaQY4KaWVWnoppk4WSFRS5xnw YmKcpqloo6Iul9l8GW4mlqSkwqfiqXI1ROGoy8m16kZkitrUeiY1OaWm2hVlAEwZsnRTAEZGlJiT 64FqalPC0hkqp3BaC6GWr2qKq6TcRqsotURdq21T3moZblLGxqrYqRKeC6207tqqZ6rtQtSrjptW yyUCrEYLlY6hIRRa/qIRomsvmfWq1m+u9mb6MMQRS5ypXERqSCKQZ6407bx1XmyhavglltCreOKp MZcgmUbquySD2yeKsJo5lJvA1QwvRAYIwKzIe2JsmsUxO8Wynk3+CmgCjmZ74ogjyzuly2KO2ObG y5ZJb6lRc2z0vyjLKe27XAt7cqkeZlhgoDCj/bRUCp6lYK3aBj2n0npqffbEeeu9N99T6cUWAAaY tpZt2I30V8uB02fj4LRNZ6/TLCkHXUbcncoaAh/ZRrSEkROANeCCR1viUyThqJBK8nUtwFiKKXtX di3ZdFvgiDvMc8e0iy4dxuTVtfTkgHme5vAgkWiZ7o2PRJfdiq8t/rmaix/eteF5QR538gJSLqHv B+BNuuG1P/859TOl9VcClRdsHOPXVsZs8Xj3PT/99WOqV0e8NZn+sg3pT+d5PKIi/xHgaEbJHPUo whuCCGAi4HMgAqPVEQTujkmc45VLQqMYkwwofwWMlkEMOBKXlERyEQxWWNB0kiGlxC78WwkBheYU l+iEex404ARFkkMAWociJ1SgBht4KiAyEIImGqBAPuiU0VhkOQbJnBMzWMRTucRKMSzfDjNEw9zd UEA+PKINW1i+ABrtiueRomL+5rCbLEgzdCJVF2dSxR1ykEVoFKL98qjHPfKxbxmSXx4z1sdBPgWQ eTMkIef0H0F6/gWRiXwkJCMpyUH+cY16ZMnsJrlHR0aMk4/0pFUwqR8fabKUpjwlKiFWyUQSRCip nB8oKWbJUsbSb5V7JS5zqctd8rKXvvwlMIMpzGESs5jGPCYyk6nMZTJzmSJsJjS58sxeTjOaVbOm paqJzW1WBX6z1CWz9FjL/4RTK+Uc2jdzlkEKfe5/ASwc6wLUszH6rZ1CgmU6sXJOejYyn4f05zgL BJV9lvOJNoknN5UZ0ITmZ6F+nCUiD7Ag0SXGJnBhkLKU+B/8uOoqZrFJ+kjGt332U5Eb9efEHBnQ s5mlXS09U0a1yVC9ZbEgFSlhUCAUEpa4xDZE6SFpgCJAp0zw/iLpIxB6bgpDh0DIhxZdp1A/A8Sj AbVwNd1pTjmylMJNNao4HeqQtlosm3IGghdpZUF2eNQzvsqpTtVqT2EirqJKyHSoE2ngNMVVwQzI JwlIz0DFSpigHpBDEfnpTlZI1xnO5q9RdYtbg2rWlQgWgjCx65HWAhyoCuutB7yIuDRFx66e0Z39 A+tiCxuTA6SWp0wprRJb28LbVZasX0WglkILkbS8kEsvZJBfATtT+tWnN4WhXGHuE6H3BC5HDjuO WJy2nfKw5j0vsitrruvKHrKVPDWJDnSbo93q+SY5ThnObowbGMsdFzDR3SB3HdNd9LLPcpeJygGA RhTMMLE0/lahL3PNC7brdA9Oz6zPY64z3fIq9zEPshPIMNvU+W4vXu8zkOnGy7sAuIS87eVwAsAb O/Fi+CLQde55lRu7x7FtWRKMVn81O9xL7mlQKYvSlgS13I5d6Xo1I1EEbWwkHL+LtSCzU2KMjM6t cWRHBsLxxVikJyUvqk69rZqUt2QkIb/JUUAG46CypeMqy+VPTwkp6mpUNR8B6Z4DjRSTi4SwuEEZ VU+pmwyZlrIof4l7Zp4SleNFNTtxtGiqSbLR0nrnOBkayWByMoGgvCZEHzk1PSYqnLls5UeRa8nx gtR5fhQkvM54b+Vk4Lr0JS69mGvHnUu11XY1kqs56WA8/vycbWwNmtc66V2K1LW3dp1raJ3aYa3u daorButZsS1bx7a1XPAlwtGQTEmQ+8uAXnfmivjL19xD9qtlfeRxoZp7rroVtxvGPWm7BteZ5Niu Ci1Qd7m7OvW2Wq2JPecpyTrYAqi3rYvtlGO/WmGdNum3KYssbZeapjX22dyUfTdXly3hHqNVBSGu tnOR7KJq29Fm5xS26oQYVlxzWqM6fpa5WRtOEzfZ1Ewe84zzsHly27jMGNWZRNNqJjrDXVRQzrmW D/jVYrtLJj1uttzpecgbJJfEGQXy7mpq0BqSt6OmflGVG9joG1NSyVGmIaFDiessp7XVXt60PYWz o5+2/njgdiaphu+tPiuensSVQq8LZph8vBOfSTQ31ruLL3EZbZ/TGH7B2oQ9fBTdIPQSH5vpNVfv Lrd8Ky1X4QIjcHPYI1NCIi+9wlPxhPdype+EEs+RMTztmM9d368HwNApDyMgdWP3gGe8wcQvdyYx /doUnzvaz1tTF06I05Gv89g73jSM/xviIU8+yTd/eZZ3PfQyz+EP18VpGyGpxTnaOgG0nu4Sq+kX l/o/vRBxg1sEYFFvd8WMOzn9Ql1/7oh4fyXqv+hqEiP+mFH7JUT/xZHiQJFTDKARNdUDncoO0d8F Rdsd1VEXsV+f0ISsmZArKVH6rJDfRYQC+t5szdAA/tTQ/yWRCP1bEolUTZmbctgfbE3Rt4VQAkqR IlWMGVWRaIlRDG7WApUOaplRC+5fj0xgAZrRARoWCN7RAj4WcICVDiJc13AgT5hfHjmUVojUzHgU Ss3YKj0SI00KFhISFoahFZ4hGurHGGKFTLAE6lnFGjbTFxKSKGWFBWAFKQGTQ9VhGvahH2ZFHMJh T70hHHbhcM1hH2XeH6IQIN7SIj4iJEaiJE4iJVaiJV4iJmaiJm4iJ3aiJ34iKIaiKI4iKZaiKZ4i MckUKq4iK7aiK/4X7lEF0DUcIpITQBniK+aiLv4h+BHK3B2iwwTiV+DiLhajMZbaXAFgRoAHYj1R /rVllXpwlmt5XmRZFTSeVgShH2m81WTBFVOgFWvVlg+dFRJ9xnyM41KV1TJuhGoVFjEeIzzGYzTF x++Ah7w4mId1HXY1WADhY4FtmG0gWD+y1YIlV8iBl4rZ1z/Oh3oVWHdIz2AImDxOJEXO1KBhCVXR WZlInaJh2ZfkWaPNDJFYCZ69kc/wmdSgpJY9SJ1BCIgQWZ5s2qVVJE3WJDQlDLYEo0aKW3jcG8G9 C08WH7DkpAt+y3IQHL90W7LpSVDqha5Ui7d1CKzZJFVWJTFdJKf5n9Udjdat3NNFYKN9DMqQX90U paaRXfSoXcps5Z2sHdeMHJcQnVXSJCXMZTDR/qP33A72EJ/rJd/rFWX2AGRpsJhJFkfvQc3r5Qjy 8OV8EJ7oZAtrMJ9dTiZlphIOHsXZvN8Jmta92GAMphHTIRFnOqFq6V4TfiYe+WAQNeFljuZpViAX 8WASYg0fVUFl3iZuAiM+5SZv9qZvcuFu/qZwDqdwCuMwEidyJqdyLudwpc+7MSd0PpIq7sd0XlJ0 AggQ5ct1UiZBcIpG9c3nPOdA/WJVfE4B5BNJmec7vp1/9OJJFaKAeGd1HqdX9N9QRsVomJZsJmFm EEXtBcjIFEXocBZ/jtBo2pmq6Zd/tud6Skx4bid/UMfu9I17FhJ5TkWFSmGGAqc8NShWcJK8/nXm fG6FQ6UFUmHGS+HXRJkGRRVOi4LUf1ZKgFbJeazo9IBYjaLEf6ZokdSeGSbThkIoh4YRUwWOXUBe VlkW/F2jQiQjZi7jkQ5EYj1jkR6WlK5WV+kWUrCLaq4ID07jWBHVCIpZbflPUiwWOGIjOXpWDpXj bSmhxdmVbB3FZzFgTXCjbaUjOYbEU/SKb31TScjF0wnSoJqGn05F4eCEjoBplzrFTkREoC5HoeYV 3PHWEKHeoWKoOBIWsrGpMmJVlTIqbHlplWLjR2ipkNKnjubjeBweexHk8GWH8T1OesTX5KmOtoDF eMkb1WBXjpSGcp0XikEmP+Jla2zYYQQY/or9o0SG362W16865FsoWOVQF3Kd2UGsCD+BIF/lm/F5 BiECB3vwhp3Ql4ZpRwY9Z34VH36s65BES5AoVWfI62nwI2R0KoVhjIgBhnkoXeUtpON8R6ruR3cK hEVE2kbelZGSWcfA5cxgpY2BW8VBGLgNCqWFn8F0ZJ1YiUr2DJrAX6bFJExyZcLCJf/g2Ewy4qBZ 2qONrEm+ZMleoM81jiOhmcAJ3MK6IaEcymh4ikperIVSRGNB3lTKGakFS5KEzoIAzpstRJ+tjkau CKRV2c9qbEtumnFep3hYFbw4y5NBy/qUSlPSZrmJHI/hzNM4Zb3xqq0AnLGl2y8KnLPB/i28QaVe xtvZ5tuu4KzKeuXeXg/emmWqQds3UQciUdt94iT1AFLAuIeQ+Nu9zcnrIC67ngrlWijmSqH50G22 SKzi2hC8QC5T6BqClu3AlhRaEK3YgJh+vWXeTqxYTuzXaGVYZiS5dCXUplzIgR1aemzBZU2z1S71 RNzZ9tzZ9Rx7ZtjHlUnS4JzgwqzrJqCJSIkhBcmvTOpNkIwgKdkWQipcwM3a6C7VccSjUMZ3Yq/1 SgX7/Rj36lxmTBzGxhn5KdvJfWXZ7a7aWM3SnW5DtcvuMKbsBCzpvRqSjN6Eck99ENVetk/R5Z3T mW3w3WpNHKbPMc/afJ/0EY8B285T/hBftkgmX0pmsEhZg/Al42WPaVZrBHmwThII0/JTpt6oiwpG 4aSOb0DF+cjZ+Fke9clRCLFFDIsPjgaxp5lEdtiwcCFm9vle8FbPd11O9IXe9G2QqwIe7Ags/6pq gUwUCu5Wu8DmugVhF8fLEMpRCcbmGFfsEHlmFJLLEdJpCJbOTTkRWMUx6nTQFZ0NGMOYGOsnWM3H fn2K+sXWl+ZxaA7WCe1xNDrit33gHe9Lgc5aIuOaXTjyULTRUy3QBtlneLjELXmybvEgKHeKI+MP JVMWna6Fw9gx2xIpbjmgABqhZxpgOiJPFhNn1oJiLhexGHqo5pKoL9+yMAenTeah/qUY8yMhc1co 8zA3cyTtsjNHszRPMzVXszVfMzZnszafrnNuczHuAd2N6DGK81WQsyZlpzl7szoH6aL5olWQVrjQ 7BC9FkKNVDDrh3rK4j23My89KNQIqI0QKGlphz01yX7upzpjs/w4EkUQiF39KImoyDAky2qkMy+x 87ZqMS4RFJdyrESt6hk5tCtVVMgJ8Qz3TkK/IqN2I0tDqVoZSHAg8l8RFqM6qTr+a2b5ydESMfhO SHAFnRjdSJOGXpJC6TnKK1qx41WBB2adRGuVKTNeKThmaafUMvas9DLa9J6CBzgullBnb53K9JKW ai1v6Uw8as7o1dH6iUWZBvZi/m9KtyKAketgFOSxssZ7LUZryBdkzDWrjgpHbkZJxOtn/JtoBFWM elirPitkCYh6PaRi2+N9MSs/NnAblhj1mBexHqRMGGt0nCOrqoWr1jW1IrCsBqz1DE26JiBfCfai GWziku0+x7Uk6hjMreXXvmQDsgkXhSzDKuxXT4ma5WxtOJmLhVqbkZqX/YnLjk3MCU1JyhGStNGP 2TYEW6zG+q6cgazTSs3KvolzQxlzx2wTX21ZopPQRoTNVusLp9np3GzR0vYpIuW5abCmMBvU5c6z ga0TPYR2lq5OBk6YhtXCcWSzfMrXBq5JDd26nA27ARvnBvi5ra3sNXFSqpvY/tqtp+ma1yKsgjN4 UBYbSxXF5CpWfLccfDOifJNi7/qMptHvzK3M59ncy0Qv2rhvwp7HzQTlz8UtxNVE625MJZENxK7R yHTJ8sLvdasI12k3ToJeeTvvr+Uv64odSM4bW+pvyEBO+dLH+f5YpUmq9rr1mK84KvYe5Wwe5ghe fhMwD2/w6ACf9emsEfNr+I1f60FX4aCwTlYYXn7PCREfBVs2Yj5wBb95AY+PffN5EQPwnrOwm7Mj Y6J2PTLWgAAx6vUd6hkG4p00jpr5KYag/bEmLB8FBM64ajIQBRryvcisOjmiCdWqvVDhCpmqF58W /qH3bp/gK0MFDRJhqoPm/pK5Sv+18Qg10RMiIGrqxRyxukkZ4JXtcbT18Xc64R958kWMsuWSEG2o CK4JxUHTKUaDOifWYh9B9CllLbo/FN2t1GyTOyua+x7xIS4ZJ73bDzRbEzPDe1XK+xUycr2/uyJu 0rvzu8EfPMInvDxKgsI3vMM/PMRHvMRPPMVXvMVfPMYDKW9aNIBw/KR4fB+CfKqaCpdmoT2tdSoW vP0A3TzlUZD6M77Rz7hnyiwOqUZHzMwz4obWvDc7JTF+VOqi/C5xAC//ktuhUi/meyOK04WqbzAr PaWM09Fns887o1c9hek5VmmS1UxTI71i9Vs1tXJn1Vol1WfMKQKJy0Dr/lRaZdVXI2mRKqmYQePa m4RNKGoNuV1V2cRSsxY0iio8M2lbcWqTXulPIJa8gKo5WjX8QbVWs71EEWhZvz1Rx71RFz67WH1Y k7HbH2nl37SwKP6bkmabirVPENvfj+CAedZQSKnmp1Y0V32+4qrFIGteJhg+2nW/7kbu24rOnZh0 0TW08uvzGZqE3TV0iDZj7/WDGeu5iut6uQfF4Wtf/+q+UheJiXQ+rv74tjnnXP8No3aHbTasLua1 Pr9iK/9fyzrzb/+scof6S6sXbf8JR+awlvZKBOTdcdi+MRf1Lz9AABA4kGBBgwcRJlS4kGFDhw8h RpQ40aGAAQMtCswY/mBAAI0ICnJEyNEjgAQILHrMCCBjSoEnBZYMcODiypUoARg4ELLjx5gIEOxk 2dMkSJI+jwIIEGDjgAMlC7pMKgAkAJw6lRKlOlRjzYtcpxp1CpXg1gMGQJ5t6TUqW7BEl0rVWlUm zaxPB4Zty5UvRrdr+a71qJdg0gR/v9b1qvKiXrl4DRoGeXWnY6J+Azeeu5cw5awlt670O3hz0qWS DSPuGyDoZ6RED++1+RXzbNcsq1LUvZt3b9+/gT8UbZvjAOPGeZLNS9uiba7Dv55EQMCAagBnrSov fpx2ddDMNXPXvJclgQEIEpDfflzg2aPrkdsmLv6rAPPoDSIIQICq/n0BgEXrKrOs1KPvJaCoq+++ 9OCjTUDnaquPLfkSM7Aw8AYsarrqBmywL/vOS+9CzNzrycMAH5QwK/E4s7BE0lhEcSUPRRqxqxqf U1E06mIyEEcZrYtQQA+DK9LII5FMUjfohrxMOQAIELE9sUo6yTnBDsxKgBQF1DK35aD6zgACbswy KaVuEyCBjba87ku+zpQJPTJvQ3O+JsNUqs0D3syJTz8ndEvIt0Bbs8I8OWqTzSnrVA6wvprkssZH 40wu0rcUVa3SGfd8UzKl5uwxTxRzxDOvFvMENQE6N3UQTifTTAA1rVRbaUwwT53K1UeB7BBWJYEN Vthhe2OSLx5z/qKzrAFEPExEHvc74EqvDFCKgMoG2HK/IIESqiBkb7VqJ/wsqjZagcClE1r0REq0 KPKgrDbZgQjAD115b51vSw7jFehWd2Eq6CQyD6sWwF2tW9dQevEl091ttXy333mXzRAzdzlsN9uc BE3XIAPMNS/ijDeGeMavPD55y4AJgvZadO2dOF9XCXTO44plVrZeKVNGmGF/1TUXP5d3AtnaWi86 QNl7gfY3ZJ8h7DHDm4mt2uqrrTZ2xuoGIODJ8ozjL6/qWpt2KD5bm7Lr5iCk6esAuPaa4pQsQttb uMOWiWyhEOiIz7XhxbtrqGIbO+8MaQoqsbhL+ltsg5zKKr2D/mVTUam9V2Ncbf42drxNweWuOGq+ ErfLKr/Ps0s00L9GCwF+S//K82xF63spzUXzPDLMX3KQdUgH6lsBy3/HuXiTfMfd55g0vzx15p93 /nWkAfCxeY4Vr7xLgoQn/nqswQ9f/N6UGB9n3VbdjVTz2W/f/WJpfl/+8dvEbf778c9f//DXf2g/ KSfSv/0NkIBVE2ABEdibyO1HXgl04AMhSMADLqRcvJlgBDGYQYVcUIMdxEjfXudBEY6QhCU04QlR mEIVrpCFLXThC2EYQxnOkIY1tOENcZhDHe4wBjv04Q+BGEQhDpGIRQzi19yHRCMuEVhKZKIGnXgq iETxiUcU/lQSr+ibGnVig/GTCAeBZxHuhE5JYEyI7pazELQMbiC881f0VhS2IpkHgJHJogdxlCQz NtGLI+ljGjmYR6w1oYoOfNT7Dpm1PwpnkZg5n5uoaMFGKuQkHvnTR/54gMqE61/26mSzlhYcQR4k kVXcIyIbWUqEnLKQNzxO3c6zpXKNhWwNxFsI24K2BOgSemVzClDS80qnxDKXQLFlLbtSHX7dUijM pNkt5VU3YPbSdNA0XPYemRN5WZOavYzmL9HDS2niUnrfrI63CIKdohQOIQ1cycZMQid4pu86DVzI fkAoIscpR5gp4ppxYImTciYzcl1BmzlpGT1nDuWc3HQT/hsfSsYu7bOY4ZymtfJJzcWdx57X3Mk4 6zhOhD4Fc1vjqEerhxyKEkSYiftcvUKUUlfhM6azJOlJW/nCtezkT3Vj2rn6BVS/8DRylySaT3vq FZ6+ySIOe1lQX+bTlRAtqH0zCFWRWpV1oSxkQtkqvHwCVa8KLT1YLWpRQVJBoJoVnQM5jH5iArwz OgxDP0JZvciJkKf+6ShGE52OIrdTN/00qgX1i1M/WlCqGo01SiUstjzC2J749WKT7ShS0YouoRhV aFy1VlvFmtW2IPZsj51qV3+KnqZE9rKONepm00qzvcZ2rJ/NqQt5tZg0USmso/FVlVACWIuV6V2W Ycxt/ioJm5luZj5V0gxoeIs8sBLqNTJZCnN7QiHg7nYoSgzX9ihZsrpiyE/W6mhIYmIXjkBGezk6 bnN94pJlbVcuwE1Nd7m73jCNhZSaYe98M6QY5D63t6I60OjkC5P6HpjA9jMNU/z7tdzGVSmqe2Z6 dUuY265wwidjkYe4Yza7Umi4HwoPd3w1GvIuJ0Yqsmsc2fPibG6FRsttcZcO2ZQbJyRAF0TL58br yGwKDEH8AlHMuFQqJesYxaRi0slUPCgiHVlEVCaPlXHmHOkkiEBNYpGNhoJgDEG5K0yO8fKwPKiV bJlDpGKzW4i0YRV2+FC5+pUj4VsUEot5u60yVVF0/mWpuOZ5tXb+znQliyityApWZktwdO1EM00W eIIEkOg85dkmekJmK37MlJ4YVbFJUY+6g6bZo19lX1qlOledAvVgRe3qLLsYnoUuNZouBFw+Z+lk um4wmqayMKaEWs2a+TSK3KXkSslZhSIhMdMoRjUcW+6otC6xWp/asy4t9mlXbViGGCuynDntaIFz G7TDpbBxO3oAQqvtvJzcE2SB1yDqJMgnm8YaEYVQqHbUlsgAxlRjc+xVU/t2vFG7I9SGu2PfDnjE WNaklQl82hGDmDbLPe5vdVXMCadNtdEdNFVpbOI88dW/x3MhlPdF2sw+YfeS7DyIHq/icCqp5WAe /kZw3k15XWJmG1P3zJ73ZW8bhSj2TOeX47wuTM37uczlxm67GY6N6/tba+nlqr6h+I1p6/rd7uMt caezb5zbEhodGbu+5NykVT/1zrf3dGgKqnhoRPtEy16/mq9kdm0qOvSOjlIxTz1zz2t76J5uu7sL hO2yy/vGbEf2tdGONjR3+eWLxErM/0bzX5yk+1hZv0778JSd3/zpU2h61FPkAHVEUusTyMoFznuH p4z46nE/Q9Xn/vKhB+F5c7hHmoCW98U3/vGRn3zlL5/5zXf+86EffelPn/rVj34krZ9B7M9v+7nv vrC+n/0hOvvzEdm9/lS5wlEqZP1XZZYkTd7f/oSQP4DmAZz8zq8k+puv/QbJv/hRKP3gJ/Xu6Icu qP8gwowESAA3yF4OQ+/Y5/+QhAEN6PMkEACt5ucoRJnaLaFwCaRkKiMoS6AqDgSlp5qQiaEGYAFE pKD0g6bwYwQhsDBgyl5WKnhakG9uB6dUCQb1qeyeRAPBKaSG0JsYLwcZDypEiqBuypeMsJvY4wYF IsZu7pxwcAr5ZnhcyuYMb5hIcAoBygs/JwULwutMopluTpfECZxsqQYnpwhlcFm2EKNiKqIcpQOb 8JgUKgVBsJ/isDBS8DAsiS7IUAgFhApx6gTLDwPfR2EoJLFq61xEi3LsZ9ZKi7NAxbMksagM/qZr 7Ge2AqNPWga2XIOy2qMTyWQrzEquQLGvzqvaliqXYI2qsKOpKrErSMunQksTs42sCs0Uj4XjDOsU hyIVgysWT0tVROuvYlGsBM3bPguzkNET14oUJ7E+BK4ZW9GyZNEZq6qsPG4al6xPqCpekq0cHVG4 vPGrGDGBHky78MsyuOQm9qWtns3WYsO47Ocs0sJcMIzx6pH9/lG/SKkf+1EeSUXACNKOfI3eCC2t DLKeAOxdFkzPGozG4ALC7kLCGsxKLsMn+LGeSOwdLafYuAvMBM0jj8u9sgTXZsI6PMMSXVK9+Mv/ TKQ0MlIeS4UeyyvXwoo10kYvSFJScNK5/trRHdHMOk5EuPiuWuDKEu/Ey5qMNvSDP1BCbN6MGJ8S IbISbJAsCa3SP5ZSrroyzaSmzEqy4oikKvvjcbaHUsDDzJBDkGxiQVrEL9aHLa/yP4SLLtNyyU6M PXzSjvDScnIsOorMOrBjK2uuLO3SeHzExqZyHmXHKbXDQjhGJiLzytiixoTsKAco2EYtwBqNKStk 9NIIMNPk11bST0BCJwbuVVDT34ZE1u7tT2CzUZRsOT5t2GANVyzSIWktVXTiNZOOuBSszoKzUoJt UX7zzzzyIIoTUAbE1tREzH5LilomASJgIPgKNoKrBMEzYlTTS2xS4mqT2HwOVkSzNCmz/kdmUzcZ ilXYc9FG09aAbdXakQIQSGEwJki07S3Wzgzhk+Ccg+FCri8GBnnMpWTGrlvYz0EH7vaKgmDaLUFL 6WEAbmMoFOR0btu+rUIZtC087meiJRmjjaxITmIcyUOJzEI7McnSkd72D0W/yy+a5f12UTxRS0O5 hUBPrtwe7nxuRt0CtCkGlPhupjXspUhVdGNIJkEx7uJAk4CeTu0g5HecI+eu4yO9M+gs5u+grjWr B1t+cPL25DLGzjsf7+zy7iAWSEe19I76LqJm0BA/lAuPLk6JkPBW5+YAD/F4R/He1HgAFU7NtDo3 ygnlqvECVcLszy3x9BEhdHPYpiTP/o0zLbVzClXIikfuhu4mBmB4vvRtNCdcpMLpeEftTmcHj05M q1SI6El/ZlWumKj0FpHZdq9WNYhXY/VX8yJK9ud/0sn1bjVXKZT3VI9Y8UhYgfVZk2l/KgjzhG8Y jc/0prWDshVaubVbvfVbwTVcxXVcybVczfVc0TVd1XVd2bVd3fVd4TVe5XX+dCP85vVe8ZVcETBC 87Vf/bVdO+8C/3VgCRbzQLULeUmYGsoNoVClgLBgITZik89IhVEcdREUv/EXgU9iObZjN+zBJGPP 4GIgM7Ip/stjUTZlC0mQRsw03SoxuwzPHlNlabZmhag9G3InT/PPrrMxbNNmgTZo/m+IYqPR2lQm 4/xzQkVRaJm2aZuNdyb1K7i0ThPPb950X502a7V2a4FDDLj2a8E2bMV2bMm2bM32bNE2bdV2bdm2 bd32beE2buV2bum2bu32bvE2b/V2b/m2b/32bwE3cAV3cAm3cA33cBE3cRV3cRm3cR33cSE3ciV3 cim3ci33cjE3czV3czm3cz33c0E3dEUXdMXoOCQKbkCI0+jjo2oQtOgjWxyEV1qXlGZXprgOdVOH LEDk/lbH0sAqQLzjZ7jHUMQDnV63x7yieKVTTcWOVkr3OFg3dQExdb/jTazqeY2D+IbCeitvjYLi O6RkLYo3UyVnWbj33i6jd1PR/ivClzns7yuHYoyajno1K+u+A3udAnslamzoN365o3W8VDht93X7 aVmU11N91yLal39zt37RxXl11FZ31y0vp38t4nz1lyyCtysWmHw5AoCON3YdZIMHGDmUjjueIoIr KYNtFXe/tyvkF4ZRuDykdwIdhE/kBC9Ql0wHQk6fCl6Qly982HVFRKgChDV0GC2gK0dlKTHyCrwC pN28JeIo8C1F2FYhByteQlm6Rp84B06L+KmQeDCUeHtFLz4skJhg+CeSGK7E6NDWx3ehzS9IUIxY Sovh5AOT99CGosoIFHhZ5YV3OJ562FmVJt7uLZRApY15GCGkWP7Op1cEmMec/vib9HOMK9gjZrWL 24Nz9LMsHBCeMHmQL/iMr+hGHxmG+ViOJwaIr7iH8ZjeZBnQwgxSZiYyBLmMAwSHbXWIbbgg/OqH mSYhI5iSPxMwPjhCjRVShHlizHCXwOKJoZg2VgU1Y8ZoLshYYi4hqjk3JuVa5OVaiNlYm5lHyqWB QKYA+4uy0tmBf6Zc6CT9kplCz7mN+CWeRm8jyGktUBVl0ElNftefN67L7EOdxPnthqycY3QhuhmS hUyS83SVGmOf2y2eBbplGlQjwFmz4FmWn9mr2sqc2w2d2+yV8Tk3OvpV0iNZTex8GnrIsHhMkHia WTGkF9qe5SqZg0VGII3X/uKHJrrmZB/6dUknbIS6S4NadyvPS2HiTOZLmmWY66yirKREaXq4iRkC OgzkgoZGSiijRijvIID6WjRTOZKzdqq4MIMHP316qndTYGB3BpuDKmuHqm8krwCDXH5NoseGrsy6 Kr76K8I6cG60Ttp6Ibr6PCN5eSK6v1jDnjJCrw1bYgJ7CvnSrZEtgCf7rOma7r4rsblCsnunOfg6 qgXTrZ11lgXImDz1lgfzZcMotsTaqO21InxmlMQ3xGIiAdbIWLV5NwOAt/vGWIO7tz0VodvvguuF I7OsKljmKOgJf+V6xXJEPCCw01gGK3ACJUKDPj5HuN8Pt9kCP3g7t1+J/q/J2wCQVHvoJnl1+42I L7JXWr2xsSWVeysPRiNxZOsQZukMgDQUW7u3hLtjy7qfl+ni76+4w/Wwu08g+sH7+727YjrwezHW G2cE3Cr+Q7bbO8E9nEvS27wRvBIDRjCA11oXu7lbUrW9+0vb1795WLw/VLp327iPhKcnu7sjQ4NF 8beRmcdDAsjjzksxkiPLSpEhxVbOY+vq52WcNZupu4rJhsm3mDX8RZNuOi+A3KntJyOsmj/SWkC+ /LK5XMeThQH7x8vJBMy/YsoBqo+hRFkeZUzYGqJfO6xWxcr9pBYRGjdcr8xlWyHcHJ4+s6VTHKZx NM4dic73msS9pip0/oLPgSaz34bIZXvMBXDQsfrMTdqhgxh7qJzFJbqMJXi5HCXQPyinhdxIUCSY bZosv2R9fJwtqNhVav0zFRpdACipfuK8Pj1bToOyKgmlUynK1fmqg32bnCKaLO0NDeLWoeTVV4vD 0/gzAj3Xa6ekjVn+SCLQgf12FvqxY2563LmxR3Gg74LZhRWRR/uqpH2Rvh1usO7Qh3q61EOPg4df cj3dNXrdqfKe6WXXterdrf2tWUoAkn3tAP6AZt2yE17UcfnIIf7cMRp4sJlmoJ3VKy9TR1mX40eQ aa/eBwXkz4vkP7Pjn1KBe8fZOTigWRS/GI+yoPyYj/3l5WtngseN/j9eh5EF5VeyXhILixUb6POY kU3s2NMcZZyw1jWy5Q9TQoTCPijuIHyeXmIGKBoZkHHZ6A+I6efrNJo+olMC7BkePFg+ftmYjLcS 5xlP55XOJnO0iHPZ7aHECdeH6bUa0a24Yry+1A+i5xm1LcB+MOa+NV+ykcVlMEIeOA78v6eXo75D eV1Yext+a2o4JLz3n2fKex0fIyL100r1kSK7rbyOfPEXtCp/dbmH9DdLTS1a8jP/8Ud8zbLLvaEX SpZHEDPn9/j4jfz39meZL3R/9MtQWm64IxLpnif/DueP88mCfOX49I8YxV248w+IQM0Qe+m70LX6 OOj7gMHLbU6c/oFHvD1cH7wA3vPDRu+qn4+HvwCx3/jRV+8NXUDin8XHN9YHuy24Y5ucP6oBAoGB AAAACBiAMOEBAAEMIBiAYGHBiRQrWryIMaPGjRw7evwIMqTIkSRLmjwZ8iDKlSxbunwJM6bMmTRr 2ryJM6fOnTx7+vyZ8UACoESLGj2KNKnSpUybOn0KNarUqVSrWr2KNavWrVy7ev0KNqzYsWTLmj2L Nq3atWzbun0LN67cuXTr2r2LN6/evXz7+o1LEGngv4QLGzbZ8GHEwAeHFlSZMHLBxBAPDJ6osjHm AQAIGKiIIMHByAMWCiCgWCJphJMdVmZMmgBj1JUtjk4om6KB/gGDbyPMrZv35sjAKZ5ObZzAbwGP YxP0jfAA9NKamz+mHXHigYfFCxKQ2Fm4Qc4XA5C3fR698fQpOZsv73qxzemXN65m/1M5x/vtGeLX mNl/hw0YUwDyJfYcQrBtRpGBljHkUH0BiqdSAgisN95FAzgWwHcMTuQgQQhmOJEBBBS04WQeYlji iRMNYAB4KmmHwGUwypieiRalyNCKAoRWUAIDMDdjQToW+eF6FJLHY4emDQmAjhQl4CIAAxDg2AFV VoQkixch2SVIAVoUIoQ1klSBR2H2l9SPagrI0ZpxciYngXaytOJEno0nZZFI5undZxge1Cd5QBr5 WZjmOaae/p7gBUqidYsCmF6RVLppnW6CAnDphZl+OhmPoD2awJOD4hcmoS6qNGlFpYLq33UHCOph h4oNlRCEtR10AETMeUliQ7UdWlpBZ1qXK0WAdpZoaQgIBOJu0I633aHbXSnhf8JmR2ixwG77ZLWl PsuhtE/uhm5p4AJArEQ1ilbQtd0l2a1l2JVbGZ36ittavhnWeWfAJJlXn4UZAunneQS76imDKiFM npYvEvlfr1c+mOTCU15YZEMuWvxdfZF6PBGQWMKKKbtDnTyylBSBjLHGXCp8JKo2q0wizCJTaREC zMX4npXMrbgdiXsaKFqxRStJGqROzjreiSn/y57MQXJ8/mWPEh3tIa8AFL2wAZvC6vR3XjdatnRK K+0p12qHmzbUB0ndsH8Eif3leWcT3fZnBupL7dee4v031QIfvlLQp44XQMIg3rz4QY2TtzDP45HG HC0BJOAaox3f7JtAg23e+cwJif6YpwZHmimmq4c+UHmcPzSU4qYjhPp0Auge4OQgzi4qQ8fqtpDP 7O7uaWAB9JqhxgH4zjrrrIpnoZuzXgi1w1WDTv2FGrs54/QY345Q7d1LnvfjgVUvXPjund++cBpX j71DX49t3vhoo8/QZMzPDzj32S1IAYQT4g7IEasZBGtGIoDjQiWhuhkuSg48j4dYpqjL2O9TCgQf eX7E/iENSjB8h4oSRB4CpS5hSloopFjqGAUiEQ6wUSAkW6rIYyJWybBkMJwIlQxkpANkz0II8Azg bEciFVbqfQyqkQN95sDFNUg8mGGgpFaTxA8qp4RkU9xB5PS5zQiweXob0gcpV0Z2dehHp/kVZrbY w09Z6llGjJV1xkRG7UUPgXzsyLL2VCSBpNFRFdmTFNm1Gx/WqGFhWp0c0/PHZvkQSo6MnqWgJLTn NUSSmkKRADSJt0u68WosYlm8rMipFELOS4LkVN3CWJ7SCOo0JzPPr8b0vaShbIkzNFiMLhQj9uBR WY9iFuNIKbMESepXS0uS+q4GRoXBr3XvW5/PzghB/lL+MkrMaxAzJfjIUN2ymncEHBkXNMw+qnMj ZRpRwgY5mQNFaGaRGg1FBLKpNR3IkKxr5zyRJKV9jo11Oqqk5DrWK4IYlDcA3ZKxHtShWfJISENp 6B5vOJyHioifBskIahj1LBFBqUNMNCbSxujMGbnNlScS0kCnRyZ5nolQWoMUBbPoH+ZUco8mNZuA /uQ3n1IzbShdqYVaCqOK2NKV6cvUUkmKqB4VMFOE0886rwoSyqCOoPBsjWJiR0+Apiehw4nMQrT6 qC5pFaxIyp+ZakPPx22nmBGBXWCyc0+1TbGYaE3OckCVv+mojTR6LRHl4vMoJL6MigSokry+yC7e /qwLpaCa0bpQdNbgkegh9VkrbKoFHmFhC6eCu9IoeTrZn6YntUPVFbew2S+8WimzcXxsUyP1WEya a6rBklYi36NYrAp3uMQNC8CKixI3Tg25zG2uc6ty3OeKpFgRla51r4vdokQ3u3H6Kne/C97wine8 5C2vec+L3vSqd73sba973wvf+Mp3vvStr33vi9/86ne//O2vf/8L4AALeMAELrCBD4zgBCt4wQxu sIPZi4oHS3jCFK6whS+M4QxreMMc7jBQ+uDhEIt4xCQusYlPjOIUq3jFLG6xi18M4xjLeMY0rrGN b4zjHOt4xzw+MSd6DOQgC3nIRC6ykY+M5CQr/nnJTG6yk58M5ShLecpUrrKVr4zlLD8XA1ruspe/ DOYwi3nMZC6zmc+M5jSrec1sbrOb3wznOMt5znSus53vjOc863nPfO6zn/8M6EALetCELrShD43o RCt60YxutKMfDelIyxgKkl60yF5y6awuJdMj4XQfPe1ploTaI6NmZ6VxUiflxPEkwDWgSFodveAq 1ZyP64msXw2nW29E1fMRpquBZcfE5frXrCY2RmCt1l+/Z7s40bVIeB1mOTmbJMymNq3FdG2gVHsj 2ya1sZPr6490m023lcm41XPudIZl2lYOEL9yldp0iYtfPbqVlRBiWXNRi1ygcYy3EKAAziSE/le+ ohq9X4Tv0hR8RvLK1m4s49vmVGtT8ZZMg/Tt2nDxG973Mji/SzsveOu7Wwvwt7ue1/F6gSvcGY+t qYzp7o+v3CINv7d7Oi5yiEh03jKP+L6BlKua39Pkxgq4zQluvJhz8egKN55rB/rzcR1qWxRPubMg FnWX42ddyYr2vgRntKC+LXC9WsjS+DZBt3mtmfFqFt3GtHYGxj2sbDtnlF7qrZXOraY9HXuYjmYy sc9dpRIpmrvBHja8E1Vpbl9gZwqPta357SFxXanaOWPIwy+NcJSf4t04iXaVip3sde872RmY+IrI LWtsLKDZ5V567b0+bTMze+lX+vhTnt7g/mC/u/Dwc3ky4xGX8EuQMoPlv6nO75ooq1/94I7N4Ydb gOK7NPq+hzVr9vKax38mQ543zQkqj3nS94/+GLR89FnPflAbv75Eur5wLz/9MGKkOacX/1mPz7LJ t7vj1Y9N2IdT1fclznc/0FdOpKVH/rdcAHhFjJE8/Ud990dOqTRr1nRuT1Z+MNUcYzRGRFRHxCdG sHVPawRFu8NbCGhJFJhEcBRX5tE0juNFZgQrSDSDE3g1RZRI5WcQLoghN3geTsRGUQSCO4hGzpRH zQGEyjFOODWDtuGCM1KER4RFHvg+MRh9WgQRcSSEJ6iCXzh9AYhFLCJAMGhxUziALPiE/lM0gsLH gvgHTbBVhpiEgPRHNtsUTIaDg5Q1Qbj0TS9IRcaHTOGXbIyRAHZoOEulhwH4hz8YftwETP9Dh+b0 PfLXPXa4NOVXiUr1h9PThHA4GaQFiv2Dg42jexWBh+SXgqtIdw8IInE1h6OTUwm4iK4Ya4/odWm4 eK3liVIVK6KnNXzIUqkkScuWhQoYKrq4VDtVJIZUM6PXd5YFfJO3MoInhrMIVZpISSNEHsF3NUjl NyOlH0VSVSxnedb4UH2IQ0G1PTrlPe/DHFAVNM4oNXLYjYJSM1c0izs1jC6VR3tIgsk4RvQIi7BF kE81jsc4RuVoEd4oZht4WLtij5mS/lvM8RBG13LCOFv+UVGGMgAYCYY985HHCHKn1TG7MVq88iyh NXJBSEUtl5GwxVkVyYO2xSKs9SK0dUqmNSRiFREsd1k4eVAs+HT4YZMzyR2QxVmilRtW2C8pKZO8 YZMVQV0pMiMXqZABaSwj6VQoOS9OqSujVZI9mZVdqXNb15KnBhcZiF3KBU785ZZq2RdseV3UxVH+ ZZdQJ5d2QZfW9SM6N2B/OS17SZiFaZiHiZiJqZi2ZhWlBhSOKWp9AZlGMZlJUZmHeRxw9RGwNhKu ARxjaCQvuWuiYowikZmyJWyxwm4asRugRmzQxoYqopk2OZUmkSrYUUwJVFIi4ZmX/hE0vjEvHkWa 2dYRpykRgnUdf4URrakR7AabtSabslWb0cWcbtYky8Jt33YRQgQhDsVNFHEj3taKIXGduQluLBGe GRFdwfWXehJUQ2EhBFE08dl7JxEm5YltJsGdJJM6JCgxujmeIIGfa1JDqXRaLxIjlAKgttF5PQWf Z9JMhWMfCdpmraJUPtdyAxeRr3VwRoKEU9Mpx6ZvXcd0veJ0VEcmmhVbFJeWVJMuTLeiNCKWrvJE F1cbJJqhrLExQpJNjvcyA5U9DWJ19DZzU7RqKOpyMBqTHRolH2IhPFpP2jKiOooiCWeiv4KkRoo2 eTUl5hmi0XKjVJqkOPqkaASB/qq3KXmoEV+adXhjLAdqZTrjnnwHeLoEjE4ydxjxn3oCQyazag5Z TrNneqr3G+ODe3U6gaaCRyuVej2zMoyCqNMYjFsXLPAkJMNzqSITerc3eUZZqINxqNS4qNYoqNvp IsdXJGw3p3gahoKKe4t1MQtygR3hp6saGn+HjkpVqUmSqddxXLW6eyQEZqRDOzPkJs7jO6DIPmRD QKM0Na4DToi4gKC4XJMBPOZzpsg6gcpEfNmqLhgBrT36PIUYh+AahOyIig7lMq/IEKpoi1CqVNdq rO+oPMlagcvKUwZKhoSVohgYhrZYrQwhr7rDbuE6Q+O6Pf5qriWDrrpxIgYC/j3gqjqeMkbGQ6Fa 9jy68Y5Ng0Qi2IFaaSROpx1jw0L4NmttKEXT0zQNIkNmCG8sB5FktLKnsYUWUbIjxXLQOR7RBCLK gSXcGFcbo4Nq2FXfp7H+wbH/CoTM6hAmSYKbdLIfO54qa3ExdLSKIpoXcbPxmLPJKLW3RVI/S08G 0JGseUImO0ZQMzxZtlAz1D+51K3lukeNJTIim0nP46beh6/TWoH9szGOKIu59JtvSIWB24jg+Ul4 G46GSK6uxLOPoR0nwp2ON7nLpYjaKKuKBLivCLeFK7d/F5yU1bh7S4ujWDCvRJydAUOqerdQ27mz 6riqhRmR+zXHeSGguSOJ/gu1Y2RLb3llAmVTUlKnpRmNWhmkVDkYC1UfgPqLBomP3gm8xnRTJhUa S2WE+giMN7WMEqS81HuIksqqC5uOBkIxBAFIwnGXCEmUDDkqG0Urz+s01WtO3tglx7uvPeudzEu8 2buuGtUjnDQzjkFRDLMe5kuNisW8SZId5HtMHFUnyotSKzmsiAWmYnlZWJmkfIhCXWc7qMkufNWi 98SVvfUbItNXTwkcl2Wi7rpZI8yUgVGbHzwqMMlZNvpa4itVJXQtm7LD25mUZPkpu0UmFIzCyoNx GByTsLLBYuo+pwNWNvxyIgySETmj0YIcl2NWyWlaPUNXZ3XEL4mTaENS/jr8EIoXbOmYVyhFVovJ xnZiOW0Mx4XRIatWFhEQx3fcHnqJx3vMx32cXS7gx4EsyINMyAUGajZRapV5mQ22yIhMJoJxFo08 rMNWE9NGvOyknU6xmjhsm7s5E5s8MEzUly5hg5lsbWfMhqDsE6DMmTLxnEZWJ6OcnXOSr0E7F7Is y0uhbtrWtTNxXLnMFMCcEao8YzXHcfaWc9OikqFBpD63zLjCGkKHcGZ0pSqCzGL6dAQkn5H3LBL1 cFkqdNIMpq/1cLLHbxc7UmmJzvGIoVBsTkInlBHDHTA8zyTMoR8nzjizkexidBpazevxzRhac8vM ooA5pmKazMVE0M0R/tAGnXGUOKU0uKT4XM8XKpHlLHHdzNDq0qJZynUJl8FXlyUVDcU2F2RlkE2h 1I2QF3Y1tXac6tJ1B4d5G6i9t6kNCY2esVR75ySBY3qp16jKQqp0N3sGG3xGDY1C/Xt256aR6oqE IxwqvXizF9RtFzULBH2lKnG0l3o8vSKhKjy6VEpJfdU9vTc53aktfVLzO9RgE9VQd3kKnTVmnXe5 CtZrrdY+RdVvjdOTWmT50xuUI4EV6EGoSthWRHznV7qC3a7ZJoDCg1f8YzDXRyHvOD6AHUv+mi2k ZbGZpbDH852PrbdUeNnigbBXVNr7d6/MR0aKTbnsZwAhWcDzan6B/q19Aqitlqh9m6F9lO2t+QeK p62srE2A/RqH2dLb8jNNuG3a9rp9c+ja0jpkNIt1rjS0MisZTumyrIGDPVizKUseaJhsK2tCmYtH 262Fh0LdPbS0UxsxA6HcKDsrC4PeUduHLtixcuiD652EO6vf312CT9RGsv0h9e3d1Y3dL2vL/Q0m aSSNSatH+c3gEh0+PqizX7RK511GVKvgi9PeFQ7gXuvff92J8JiAySSKfWvYzXO4iz2LE+R9fqsq SkhK0mi4umeK9dmjpOviYX2q4Yc0Py6Lnnfifyi4jIjjJf7cSK7jQRSJU8WHNs65JX7bgWisYo1+ 3TPbTCXlobiJ/tRqp6tdhi2+5OiR3DvOfCj+usM95qeot6w9ZNurmuJYUgQJlnZ+jXLOhnMYj/qB wPArwxAzes0Iv3Ku50odvu6tJyXkkB81p9PbSdlo4qszvFDyW9u4j1ZEv5MOTkdFjP+olYTeQJnO J3QK6JUeta9a6nT96FLCkHcqv3ldWL3IjwlMU6y+i9IrvAfM1n5NRu7Y14lOZEcplT9skZLllStO wlCZKUi5xaAxwgxn7JHlm8k+vUMJWhxk7SW5k1Fk0Tes6ARU0pdko1VsWD+ZM0mZpF/jL9zO7fkm kRSp7juik1cZ7Tn7wt1OMdlexOtewyWD7JqZ0ZFNMyV87ix8/sEu3KLS/uzjbjP8fpLxHpYp/MUY Gc/6PsQSX8jAhmLC/CZn0W0ev/HmZsoZJvK0bBbdxo8jr8slj2EnP8spr51lx/I1b/M6Ick0kfPq lMjN6ciMyRQ7f/Mn8cqoTJku7xJFzxaWTMk67/KwmWzHpmza+XcqKvUrAfNI6BFK/xLSRvXbA2Sy lvUlMfYdQcxiEV2xjPQfj2sLrqBdD/bitvZaD/dtfxME2qDFOffZJQdhoaHIAtIuytEObcP4CB7p bNDPbNL5HJMY/XMFrcwwIhkV93DkQqRD2nNwlaVCam8q184Djy/ZgaPGzBq2UrPJvHOWn/mR/27R TNLjvBAk/op0LgRyBJHQfCL56276CF6lN2dvOVo1mD91QrwePDd1HZe3drvQMUqVpd+Su1FymGUs KNf5kg9x7b6jBY9XOHm+WffQLxaziUp7hTToE0t7g0dOND3VM/OwXz3oxXKnek16rsrSeVqng0pM unfWfLcZrpqrzwQQBgwAEDAAAAACBw4eQEDQIMKBARI6VHhgQMWGEAFIVFgQo8ONAwIAEHjQpEaO BU9SBMAQZACRJAeqRJnQI0iUCBIgVNiyIU2TNCf6PEggok6gJoe6vOky58OgF1tKdbr050MBGaNG HGp049CoRbkeaDpzAAGCDa2yfLpyI86aCr2mNOgVZNOM/iUDIIDq1u9fwIEFDyZc2PBhxIkVL16s kqZjg48jx4Q5Mu3KygezHkQggKTCzJclv7xoGXNMAAk6o45qWXVIy5sLjlQZWvVsh7SxPrQcwCLO 2qgDDEe9GfNB35NHhjYelrTr1acPmKbZ+3fw2Fd1azbI/Cp30tP92o5+cnRw8eDJ48aOfDny631x Wu8uPEBS5PAnq0edQD773fLb6DcAOvtsJdxSa8g7BOuDjr2GDjAgwoj0yw22g/z7q7r+EFhvgAnD Gs02+Rgz8UQUU1RxRRYRgwy8F+/ibQAaazytRhoXMiAzmHDcT0bNCBhAp9Oiwg+u4HwErj4jA1wy QwQQ/jDqx+BuxNEt1aQ04McerzQvQJiadEsAIYmkKcspSVNyNDWvPA+rMnc6KUzu8HszyCF3qrJO MEtEc0u4wFNQSya/xDLKNEeEyk4nz0QU0JYG8rDBsLq00VA6HQLKQwKyItOzP7lctERBM51t1IKE 9AxI0pxr8VVYY5V11hX3fJHOGEN7a07WetMJLQzzu/O+hbRCrsMjE3xN1+2eg5JNRVeNsT2CEmD2 NGlFNc00Qam9TT5iiQouW2eFbdRBk5q9dVWn0kX2vwBrY/e7D/mLzdoByGU0JHKZSwA/mPTtMzZ4 u62PXH6N5Q66YHet9F2TDHBJ4oNhnJHgDS+Gsl6n/qZFN1BaQxZ5ZJJbHJckJgNGGS67DAD2pJZf JoBIsQ5y+ckwVX5tpblsKrGgsWomCS02eybrXP48k4jKh+YiMmZsv/pRo6EpxcnoTI8FdcGKlw5J 6JuhbXqgqhXlV0G3jN4XSJ25rpkuQZ3GV2khQT7Z65zwjdprNvWq21Cc85XapCh7+vKonqAGXG2o VEPLv4gE5xsqv0llOWjGOeuIaZu5srxk0EMXfXSaLEKAQL6SO33qALY8i1vkXCfANA3TlV3dh1Jn 6KxV59zydJApKtx2Gmd/cqPfNzdY0N07zZfN1ofsKfrX3Wq+IAGAot54wKtLnjPWfOIdfN/4ct6z /tS3x73U24/X3fzeiQd+7RivJz/6+Z3Ev6frny9Y/PMhT3rkO0n/sucklK3Oamwy4ELCxx2GAC92 xYOd9waYFKnARE4GTEryLKe97wkwfwvz2AQRAKnRpVCFK2RhC2N1JBfGUIYzpGENCZOAl9mQhr1r jg59+EMgBtEwMBRiEY14RCS6RSJySuLoMmiXJkZRilOUFRGpeEUsZvFVQNPiyLIyJLJ1UYxjJGMZ zXhGNKZRjWtkYxvd+EY4xlGOc6RjHe14RzzmUY975KPDxhMy2I0skKMbZIoK2UdEJjIxh1RkIxmT tSLNCpKBKQiOuFeYPQ3xc4+cmiE3yRgrpiiU/kq03CQH46McCWaUVoviKl1UKMK4kpI/+yQnCWNK QTmykVaUJShr6SqfMLJIvcxlrTqJImJqclbJhFUviYnLIjJTlb9kZWNo+UJqzlKXfGzeSGwkEb4Q 6Zu/I5tHopSACMoJf+W8yDkBYKNuZmwlJRHh5tJZlHemkjtbmg45wUPPAsWvnsKjmUlq5JEhrWqd EDznPU8yzgF+KZ0OBWeerka2hSpxZhbFjAdNGMb94SSeFsyfQwFnwul59Cvh3AlADQSseHY0oiE1 p07uWVOQbtRM7SSSS+OHUAOtlKMx9Z30fhRTmvImhEjVqZ54ys6Pjomn6HSnUMWZo4wCDUS8/mlq 8LZJx8yURCj8+05cWGKRj5gVL84CaDUvE5e1ApMtRmNVD9/ms7SKiCoZoWtT9mo1ukalIn/lSbFA AsXAwoysaTvK2L6SuKP8C11idSxd8gpMujqtaYt9jLHCGkalRBauVPlrqh5bFM6WFisKi+taPsvY jfCFrWSTm1DG8trCigtEp7XtaU3yAb+mdS295QhLxmpYaX7VjDBJz3wsRC3ZxERR2XkSehi5r3oF ilHLKU5ZDSSx0zwIgRazl2a0c7yHMaw1x6OPQ0J0LOoeZ0Dg6s/HNhOa4Vg3vc8aby7JQyIBJYcz ngGvu5rLq94QR7zrU1ZG2sum7xpuebsS/jBzBwlg/cLXPd7yUGnm9NwOlcuuACoViIMV3WY9OJvK VSOZLOooQrXJRmILyZriBSeOShVBbuNTMddmqRyVTlKwM1W++ltCIHPObrBMCo0HlaizCK7GXjpJ qCIpY6z+z8U7/VqPg6e9URUZSjGOVIEqGKcrH0tM1R3VmKHMvCEv8CFWJgiaeaVXPBEJkpl0jJ2t DJRboVLOgvpzfWxM6Ecdk8VyDBdTKsa2Xh2PWm8Z1rzkeRK9QEy7/7sWh+warG8Vs64fozTSMBVi 50SLvE65Fq8Q5i7LcIHU3L2XvJD7sVB/GSr/Lc6jPa2wRgO7OPgS7/IafLZRa01hgeuX/qURTN5g n1iyoPaQpVUmI4ZNuoJIu3agt8Vs8i66jm37msq8RieoOTndfTrbznSsH8tkLlB7hsq6CSdBno2F Te46nr3Rq2azprpPdPuRBBXnLoK7pXJgA1ZtK/Ya4vpM1IGi68LN/bcC4VtraMt3bHci7zcF7eJK zriElzfydi974SfbmcPvOh3BLUtydePiXpRHtZt1b+CDQzfZwrbzyYnbjvYrkEgamL72OVl97jM6 /LoclRqdcFvf2zcB/Zt0qFjkwlTvb9EVoD+sT/gkSI+owJkHP/8tTIDVW0kD52nUCbI9qcUaH0lv zue+hNRmcAcg9hwYSKIXVYJzZ3ME/g3HQQRq/d2lQ7tnAo9puDN+fAO1O907ZXns1bQnFmS72UXa +KIPJ+yf513ahX76O+IQ9WtUPeiSa5LWr172s1/9Emm/XAIwkWSv/4rub/974COSi8Hv4vBdv+IG gZb4y2d+853/fOhHX4zCLCP1aWV96Q8G+yzaPhy7n33wIyZnyE8iwGrJ+8BA00Tov+XnhOR7k5Hf L+b/CzQDjSL1P7OU8jcoKtlff1jivmxypf8LvzMqQB9aG21qJv6bJhVSPxX5P2f6nBgRpU1CQAuU qy1qQGOKJQ40QDNSCYg6IYayqaoiqs4hHKXhOlGrKXXyp6hCKfkYQZPrLRdEqQKR/hOpMLP+644Q EqyGqqqK4jKqySjM6KobNJQbpEH32qqJEkIYrKcSGUKnoiiV0qt7GkGoyhWVyqqpyidw6cIoJLyR UqoL+kLAALSLSKgYBKDeiMKw0MISpCqaQUEZscIzZC8xBCOAmxMkREMQnKIY6SvS+gjcSjW+0rcj I6zAasTGAqygCQu7aK2xkBCHIBpjiTgJCy6iyC1Ho5qAU6xbu6w71K2XuwlOrIpI1Ky0SS3hekQl VK2XAxKa0AvZUitZ7Li9qKyuiKz2oKxTJKxLO6tEPC3cSqxwI8TBMsSYaKtSVEWPK6G2CMVWHMVO DEQp8jbzuhBFObCxIzDQ0DT6/rEvrqEuADs19donrZiuZ6EQCkFHKPmS9aGw+HivE1s2FWtBzuEw AFkfBjnHD5uvwHGNghmW7qJFXCNHNguvDFFI/LqP+mgufuy6k2LHy7AwWNvGWLxHbuwTbww3askv zgEwBqk/E/MqbDSiQDs0SbOzAoqzIqu6wFGSJHs67GqzqFCVk2szTvGUy3sYYHKyQtPJKbuUKku0 f0s2vHOyJLkSMVuJQuMPuSqhppyx/cC7ogyyG7uyqsyyBUKzpaRIV1EUJakzi6rJjaxJpnRJkAzA ZBMztPSLqETJlBQibTSXk3M2V3OwDsEVLZu1hqE1faQ2Q+mYgYlHiWkIiqEU/vLQuaRZNb78Nldr S0oxyGKTNMBkDvoSmPJasoXstKu0L8C8k2crl7fwF1szxewKJTXszNO0tkhLy0ijsWjbSBGbNr88 McAcDymTxrosv0LxN1Vzt7HDN6wRHBSaMMVRnIW7M2qkiRG6qNNynNTYLedERtqcuYKDLJvJobMJ Os8kTZAzNeb0nL2hOSdpTjxrFZwjmtBMQbwRTreUicFpz7dBiocrq/FcwH7zObQgN/s8NYbDzJSr TCdxOZWBlOY8uPMkud88IugUiaVzssczCcXDwalQIMdcO+5Zur3T0LGT0B80GIhkn7LLoAGAP7LT OALtO9PDDQ8toMaTSao0/sPoVLr2+VACkdHSO6BcukLKDL0JfU8RgpQhFZTUeTsN9VAydLrKM5t3 00MKwry4uyQkFdEppVCns80nfQjT2dE9rJ5JQryJe9DU804zfT4eWrY0bVM3LQzbe9PneyLlk1M7 vdN9wtPm+yIS1FM//VNADVRBHVRCLVRDPVREvaLvE5lFTVTBaNQsglRHnVTS+RwI1MCT8gshKYD9 e7oN9NQWwkBNTdHQySTx+0APlJX329T9gKZLBYz3e5VVHQBOpVRK5SVqYk1LzVVUTcNeZUBJ+tXE QD9RnT9hLZKsWaXketVFmk9bnT0qxFDCg4wnJMJc6So5lEEl2sM+PSgb/lUeo9Qolkq+0oDBax3X JNQ7IxQ8e6oq51DXP3QoO/RWfkqqaoW/aJUpBYKMeh3D72FCrZKwaE1XIEWOeHXXdMFWH3mR6lBY H+TDbR2gcLWqKkRYHPS/b43BgK2/rnrWNlqLvMmbN1lGU2SV4eJF7txF2FJZXJTOvZi2UAJZwZrF QXTFTpQbagxGUtRET7wKZhwJZ6RWnZ0KUuzZlZUtoQ04lxstkzNaSoytEjnZoj1ZhLya1JpFXZQ4 nrHZdgmtx2LYynqaoLkJWF0sj2Wj9nrIh3wTBttKemzVgwRIDatOjrxLkaTLt20QwRQNLjnJkFQw jcxIBaFRXFsQv43I/kGCjL39lnkMSAErTQ1RXI5c28JNEMeNj86snct10ADDXLB1LoGELmG7zM1N ynqxW8DlW0Zqr7NlPaSEJHoL0hp1M0DpSiajr4c5NFNllb+gs3cVtBiZy92Nyz7EnkW0SYMQXhwr qHCLSVM7SjLjN/LiEJosGOeVS6SE0uBR3kOJsc8N3uw1tAGYAH0qXiPr3jcDmeu9P15hScDw3dY9 o26zL2LTDL1JNvYMNM68Fs1kSNPcDuiC2V19tVKZTbjlzNtsNcHNtZuEjvnFGb1sXnHsrwcuzc8N TGmbSFJCYOjazCBFuOl9z5OBNMlc4PIAYfw14c/1F9BMv9481vjV/iGUC1m5SVAlO5na7Zq66bnu hE+MixjztM9B9EVn3Ti8cRV7uxv0jBvRYtBgHMy4QLnhZK2p2U/11U6FM88KXM7I4mG4adDjUU8j XuIrTrjvPWCec6yqydqjAWOZHC2TbWL/xNsZjuEzaiB1XarIM7UvPSrQI7vOK1gdNcPq4cI8DL0f xjwpu7os9eMehZ4QilH5uTtOW6oZdZIKrcBp7Tq3g7x9ZZ0c1bsVvbm2u+Qf5TsePZ83JtMzVmT0 wdLOm+TgIdPgmTtDHrzRQ4gS6WQ77mVMgmFfBtRiDeb4PQD4I+ZeNmZkXmZmbmZnfmZojmZpnmZq rmZrvmYfktRF/uIjbV4M6+tmb5YicMZmLWJWKsIlc+YZUsW/IkamlAHmKI0hK2LW/7vUdFaR8Ys/ S9Jm+pMmF5s8Fhpmck6ke05VYMXU+NshCuTVDHTA48MmTEPTw9gXZsoKOfEPgSIkeH7W/clYaoVC VJZlykPDPIZYreInix3pCNrCL+xSkzoIgN0qlDZB5gUJeDKfQBpYsNtjMBxpfvJDdCVpQUYqrrvX NtyKcjVprhrXbJXCBlnphA1q16ERn3ooGglYnZZXnDbYcR0ob8XBJLTDoLTRnOrqjl4JbzUdhYJD wpEwdALrqbqpp4rqF/vCqoaprbZmW0RZoXWKvT7aj1PEV/Q4/ly0p2v0Wrr4z4noa/0U7MN2Wbw6 K2GEtmasU6p1WaT9EcZpWqm9WVjMSHrabKL1bN+a2ZZ1WpS9T3hR7MSx2Wmh4rni2nKkT6MVWc12 bJc4RFZqnYZbRbNlxVgc7OIqzZWNbLTSLdZGLWv8xLfSMGeMZpKEGIvU3LkdjtX8GOs+SBK74gWL x9m9bsZ8F91oXMr+yM4dyfoiYf7K6cMFNfpqrg/xx4OUx7rlDRP7x/Smb45TsWaJMAPtjfbGyHSx EMotFwZG3FmKuh3hyLyV27ecb+klpe5m23jMWwgDR14xb+hus/VlN1GDXVTxcHdhSZm83hCm7DW7 yRR/XpBk/kvaRW88C0vs9V4RTxY0M3GypLICZsmorMmnHMs5C18440HbfLIc7hY/e92CvF1ocXFE VCdBM/LbNVD+KEvB5crzXUhEo/EhnxTzcHJo7t/TPUzutl/wZmEDFru5ZVzv3sfKPV7wTsp1MazJ zF/RVO/BncIXHsgPh83LtEg/mo80f2Bt0029jUdC1598WbZc2fMRgc1+Gba7PPCNiOCTwmgMfuD+ 5dLdhBndy+0JthiGSfQCtqvarOYFVcQwDmKYkeOvPVBXLxsWD8axdfMn9kw4blGgBFAQPjfkfIiV C05VP89OWPX6BOGWG/aimeOTsjeU4+E1FmP3MkYs5pB7/mvaMPG0wZni7/ybGr7tV39M4szUnIOa GZb2bIf1Hm6Qi15nK+ZXajdjBBqeyRx3aV4nj1YyfI9YXD7kyuPQeTwSe6X32R1pKN5kNceJ9wFo CwW9Po4YnhZSFrQeU4aLod5ShJ+PHHWVI3XRVxa9KR3kp6Z3j9+UmLjQleCLr2v4R8bkLcXjEFL5 fD+78YldAwN4Vxb5lB+Aldf4kEcQIQHojP9ofKNloEB5lv/Jal5TxWB6u9zogUZow4g9REU/qo/6 hwINKDoMOo0mqMd63ovTRA373MP6+QunOsUktFfJr4/61zO+sW9AuDd7uq97u797vM97vd/763vQ cSaj/r8HK75PQ53aPFTavKBXepihVbjtwMKI1QcEZlxCpSx3kcTPaBYqaMDQfFCllSNh1VfhfM4/ 1ROhfPoLndEf6HUuLhiy6IYUqGQFZllK/R/SValPQ5rB9D0S6GHsQxni/YPG25IBfmbWoHhu6yoz ua8GWzzUUDvEKfkhm5juV4jFtDAykIzHQncqsHdaweqPp4mtyDUMqnVFfthLqTM0aujn6rq+p6p2 DrE+a4Mn2JDuab0DQpoxQv0v2OUn6YPNf4AwMADBAQACBhgccAABggQAAAQQSBDhw4cDLkKUWLDi w4UDCARI+PBgQoEMNgIYIICkAZQqMw40wHHmSIoJ/g8MFCASgEeQMw8KPBAxZs2FCGQ+HEqw5EWM NJ9CjSp1KtWqVq9izap1K9euM3F+FFqTZoABIaWSTItQbcGFDw3IDIAAYdmQcH8OiEtgIwG9BUkC 6Atx70G+fvGORPBQcADCFAFXZMtTsQDFABJYZrwXolkAdyE/hVx48uLDHOtC1XxgNM62lD8O5rvR LevXiRGjvjvzrlyKqiW79Rx3LuLApouSNh679HLlvREDzzz7tWvmchNEfzvc5ljnmyvmlglYcuWH mEWWv5z5eGibtUWGx2t4+UECzX8r3On1oaz9/v8DGKCAA14VQAIGzOXQQU1dJEBZVKmF3lqP0dXZ /mUVikXTQWedh5pBtnmI2YacnZUeRwjo1BKJ5qFIIXQuAoCiZwV5WF5ZGerXXmQu1mgZeNydZqGI nY03IYeWnRUATjsBJqOKHJF041kzhVjhkRHCJySQUQrpI5NW3tbjihe++GVSSS1Z5JgBBIAllxxu CaZ6QeKo5ogxpvgXRU7SaKGJOnYXoZTthSTmnR12OSJoBDLaqKOPQrofmxwhmGNSFkYVoaY8uvcY AQM5BGWnnDE4IWc7AlZWqTQdIBMChXaqpqhm8mQAaqoyONKnDVlanJm4NkUlpkGiCiOWO2GGQF+m 7tRqjFMGumuoP+54ak1uVljtrA92F2iFqwKL/hG3lm7aXbLL/hpnutpWO+6iAkhrJmStogYYvZ2F C6SvdnoKanH56sdlsd1GWrDBByM84HnVLrrYtMkxbCq2Y0apE8Q1HTkmRFleSZGHGwubXoivwhhx d9fZp3GhFtOm76zeqkwTAQ+7NbKsamVclsUTc/bnWG125CXFcg6Zbonqjvzym+DFXKO6E+s8lpo1 Ysfs0uQS7SXQpHF7LMonN5Tyx9BqOKqEELEsdKqYhnSoYjaXnLDcc9Nd90wEFSpYwwmFmsAAD59d 7k68fdrznKION59n9gGGX0WCLf4UQyipFrVAZepHAK/MRR41omiZ3ThSBqQsat9/W+cYzEAt/hd1 Y1bbNHnZhi9MqV6++cUz4UByq5rSuL+VMuSkazfY07Ab/jqtjDWk++3Cpo4S7W+/dDlomocKGfaP j146oPJWqFPt3Q7PeF735e6xy3az3777AEY011IJlboRvBcRYPGs5cqq1OWTfUR/RZFdUgTykbZ5 TCP6GcoBn4KTKSllNgNZ0v5K5rfTGNAnAMzfQ+bSAJeJBkYM1OBPPhVA8CjwZhMyCkp6cpCVlOyB s9ugAAsYkwRO8Gw78Z++5sImBf7Ohg2EyRA9M8Hj0cqFKulfCpEHk6P00CwRZNVcOMiTI+bogt3S ohB9Mq6XgS9oJwTjCBHIQhTmEDI+fB8b/tvoxjdORX8+Y2MCvAfHOxJsK3X0ihyFZpU+4nFugAzk +/ZGyEMiMpFzy09jkOLGxgBOke4zpFUg6RVGQi4rmHSkJB21yU7SjZKgHCUpS1mVyhDljawzJftE Gcfz8VF+nMQKKo/CSgLVcpa3dJQrd+nLXwIzmMIcJjGLacxjIjOZylwmM5vpzGdCM5rSnCY1q2nN a2Izm9rcJje76c1vgnObZHPfOMNpsHJ2BZ3MVCfIzOnOd4ZyfZhLp7rq9sWu9NJgi7onVPL5qWnx 0z8B5cpAQQeVgiJMYE95UEEZKs+qyPBSkdTnQ/9zLHhidED5vOhW3lVRSOUTQh+lKFd6/onQAIX0 lCP11R1DSsmUToUApcuk3GDaUWZlNKdc6YkZc5IUzfmLo6IySqimGKwdGcWR/lsoEKdYGIaEiqcp aVBeqnoyiShVI/pqjPyiWsVxcjWoCoGqcCoiI23pbYVkfSIFMZjDo0ptrLx6Ukp0slQx+qQpT20I UW1oy5uQFa4/7apfl0TXJeJwfnelUhODwhGpslWHTkVIsMLKK70mVk99PSjqajfZPEZ2MITdK+BS BUTILvY0QOUVR3WDp8jyy7E6FWdnPpOf4HynZb1CanIchzj0NYcjzHMIfqoTH/LAyHfOIc5Mcks9 u+jSuTchzXjUhhDIZWe5+vJtxKqT/p6F+e64K7xidbyjWepudzrWIc53bbNc4rIneqMJEnTly6zh Ykm6+U1feaHitxdyLzayEu5wiKve97yscrVFinKFe2CcBmo9AnbRfGdL2zqJEE0Sk+fUEhWnnPlJ aB5iE9x+ppAp4cxoYdISWTTMGRxRycWy4hNeKhVXE8NJWB3DXJPyRDHqYTghCMTxbfjVYogsqUod 9PHVSBxiHbPoTj/CUYmb3CZmJSlNpirxbimVn0vt2FIjLpSM48YxFg0KzLeJMZI3TBMacznFFubm /VgLo3NZD8LFUWhCPNquUvEu0ANjUrx4xiVwmY0jeO7X5hTNEHTJylmvwsundoY8/ncJ+lpIbJat 8AVoXYmVVofOlZFnsmhrcbpe2QrSqoil6dDEC9OC2vSpZz1oV4JG1mbmZ63NzOe0xPrTpn50nnsl aVjdWs9zvubWdJslS+sQUFcrmqhADEEoGyQBcaZL2iTLqWs7LWQ/63aQoN0/lfiRJMGBmp8CHWaT 7TBsaj5Ts22jwpiV+kfQDjdE5H3mbI8N29Q+TberLCcBVO3ZN552i0DL0pF1zd0j0fZLdOhniBec beIO3FbRPW/MRLzLy56m59zLJbsWTqjaEl1s7sk6uSiOeM0tsHk7LD7q7bB6wItcWZVXbuNNT9zK GzABX7YU5wF95hPmsU22xzni/pX8VPdWTuQ6LPTC9Rzrgdkcy69DdZkTeOniBm/6doLfbLmucA/q uupEnkcFp2i7BU67E9Hql6h/3Y50j/aJ5mdeyyl75NV0YRKr+EKVwyy0axyg38tIlqY2sTuEj9EA FGATnEyki1PSKhUD+JLJP9bwiO1WRH93ZVoZMfOMTeOmIcNFImpw8nOxfOIdP+NhKdFinDeP2aYI e7BGvvNW/KxpWd9Bs+Se8rSHLaf6ybvTYnH188v9gK+aQxpqXviHD3zpfY95LQs+/OIP0B7Hb35p lv/86l+/gCzJ/vcf0/1zqwD867/NVdo//77Ev/777///A2AACuAAEmABGuAB/iJgAirgAjJgAzrg A0JgBEpgVbBT+xFIBU5gImFgOyXTBmZg/tnUSW2FQxHUR61dpmWFCLJLVHxHYLSbSBGSCjofo9jU 91xFw3xKAfjGAOggVZyg3eAg6sDPSm0LEX6gOdUgDRohPgXeTd3gR6XfR0SVHdmgMCUhDO5HDe4T d/zgK7ldpGyhRi3hFx7hLZHWZk0WGmJV8SzZUDHE6DjSWcVVXx2WXa0hXoUEZgHW5kTQ8WxWRWAW 5umEvXyV8OWhuECe8VEdWXiKswQGjdzhUPmUaPlLHT6RLgHFiUWi790VS7iEHaYSW21VE6lhKCKV T/FLKWZeJgrFJu4eIFLV/lQxiGvJoSwWxiR+VrMUIiXamSq2lUVQVVAsVmrRBGYJ42oVFeexxVr1 YRlKEmvcloQ1xmpEY/QwiXUdRnW9iHdZBtm1zoJxXHnxBnN118VIiHeBiWupmW1Z49ktouTkCbe8 RIMhB24dWDdKYwsih3mtF3zRx1rgozVql8zwV2/F13ukokH223jx40BWEMetWTniVtmdmW7oVzU6 ZDk2JD1u42Ko10Bm1ziOoTPWjaJ8W5Sd5Ie0IV1hDIuspPRY3J74mJikGUT+2+vFJNNlCYxNGYpl zZgBhR/tRkHICIrYyJMFEcgoiUzOyI/hBayUyHMlBZs8WY81JU2yGH2h/iSRqWQQldq0GYlTKtlD YgmNPeRNNtxOQkuWXVpWRgxUrlhUZkpYKmWSsRi75RhJItK96ZqJtdqx7QtFAOZZ2kunwUqr1ZmC uFmWrGBOEqbVxEsJhRqmudxHVJx/gYRltISzAAxH1MCdEZtgGiap5MrLAMw9AUxh3sqnYRr0vFqW tNrKIY/V3RhpVlaiLRyzDCa8/ZpKGEtk9pqJNSaWnKaw6YjrhSaqCU5v6uVeGkvWdNi19Uy6dcml zBHPfE3TdNtyHlzreSd8kBt4bOdP+knCBQdnOSK8zEzMBFHUxFv5BZxpahzVBFyq+FvA8duPhNnV cOC65GS4rQ24vSBZ/mKZx+kkxPFIxplbSvpZgDJNfB6n+uzbC+KlwzWnG02db7Ecz8WI3+1I4piV h9am9jRa+QTdD8rK7ugksRgZ3unbnPTOYbhjjMBkczUaQ5yFibbnS/jc1k2LjrKLjg5X3mVOiXZP 8fRogE2jrAApzAAeraio9hxp1iERnxUdtTDp3encifJoysGIip4lkYrpQhUoylFElDoRmF4oHk1d LhZfEZUeUl1pnI6oTbye42Gf8jkRD63oiVQehQmm4Wnf8f3Q9bmpFLlM6ckUGhVR4iUfmTAqCXUL nnJiBg0Z77lVEb0iGh2dCFnqngkmFg2YMtoEnqbeL9rkGtHp8S1f/vFNX/RNHvWVzKZGG6V+alTM 3uWJnu6J6p5i1UiuqS+ln1UM6yRFhlAGqzsVq/gNUrKu03oWCLSy0Sc5K0bJn/lRa7UmE/+JlC61 Ty5pKzxx6/iBa7ia67mia7qq67qya7u667vCa7zK67zSa73aqy954KPkqw9a076yj7/ea8AKErBm xT8VTBdSy1z+hwz6IMHG1N/koMN6IcO6psH8U8QyJmeVlMRaKBg1ZlUYLCJRrMAW0xVixcjyURMq rH+YLEsFCAmClMS2bAquWsd+7B9xLBk2TAjmLMmyn1Td4llZlmIKYyRCFiz6ZtGyHlH9IXgg40wE IipOiNKqnpz+/hUvEu0sxqEAkVZhySKVPG3XSl9BAJqrbkQnVlWNFtaGUW1WvRUisp5seS0rqhZh le1iDu3XEiMe3gQuhm3aoq0gzm1mJRZS0C0w0kVjfdngxpXcblCS3GEmngQgwpDXXmJFHK3PKpJ4 lddFzsc0rog6nqN9tQVGOljQdKRuzRfzxIl9gO4jou5ouIl1dS5Fni569ZeSqs5+9Zs/gm6FPQXr ju5GFhjbUWONFpfMPBhENs7yNqR+lhWCea41Si9FCi8/Aq/ZFaTSLSmgwmR8YG9+tJf29i4/gq/m bu6JyeaZtJmQiaX6zs6IwM2lNgxb6mSKjeWOZExdhqVVsqSK/qlH/ZZZHhncvzmZXEoZI+YY/j4Z UELnsIzJkIDVAPOPxwywmNCJT55MmcGlSkbnViqZoUAwwyVwBKelnPUk9HqwhdCYlWElT6JvIiUm rQSnbTrFDJ9lX6JeRZzaY3rbcJpNDRfms4CqcvomTQgxCr6Qm6Hmp4lSaxInayJNrHTcoA2bshRb BbMIFm+ZcUZGoYEmF+fcqtBmn9XsqAXLzp7xEVfsEtemZPJKal7eaPLZpSBmZMawyI6niS3ovG1M vWHOthFwxTUooObc0TylS7ondhrojr6bddapwDXcrJUIxV3bE1NogQpoJZNwxz0yJDMvExNyF0un eMYup/Qx/r6lZNGEW33qSycrMJoZMpVk3CWXqr9dDcLhZ3jmcQy+xHnYHNBJafAEXZhq6K51qaAZ GWSoaU0cxt6tTYjWaJa2XKCZ6Q7blw4NqYm6EppmzpQOV4yKHfe23c8NnZvN2jWLM4dCMjCjsjA3 3ZFSc/ciKdZx8ysDDz0TZDXHXa/g3T0LF9flM6+YqIv2MiERXqTtKmDMAp6C3hsfKmg9qln9aW56 WdUyXgstdOx0xqoy0fUtHl5tH2gRH5YlYgNpj8uQ6gLdqu/5UC6O7W7JaiiL9Eu89K2G3gkptOdV bvZ9dKdWxO7ZHj4z7uNd3/dxn6D+Xhb13knHnqCi7EE3/uDMLmswzaxUY3VWZ0XLXuswHcBEaXVY izXLEuy4jvVZo3Vaq/Vas3Vbu/Vbw3Vcy/Vc03Vd2/Vd43Ve9+uAAOw51XVfRwVgLxQ2CbZeS0UL fgoiT8VARfUgo5TKhumlkOFjA1MYVqFFEbU9QXYlESElNTYt9WyjCExjf/ZaRyG0HgAVgjYTumzK TjZHIZ4SVnZnh/bHXrVrX3VKvVRtzyCbbrZhj2AjMhgkmuIcBhbc/pXYNiNHVBYQ5bQGoa0//62l RK3QGu0u7u3j9q3Q/m3bYu4uWm0y5tDmfNmkvVmolLflCa7ZbncNhVZEm+0oGup06+IQ7W11W0x2 S1Vz/htq8NGU3jo3p1KQ77mV6k0ReW8EAqj3WrWHd/OtkemhctPqMjbaXfOJPOoER2aH8U7XRC5k cdAj+PqOUF0k1nR4PvZJfT3vOooHRk6v+YLjUCnkNDpLfXQlq7Q447QIOvYjgoWd1x0z+T4H9xK0 8y6NRR7keHn460IvO/KjO/63kOtjzzEXR16vatQ4bFSGj5fN526GeFl0SG5H6iKrXKtIUa6EVN54 JOeyyRHNFO/vpVBZVSqb/cJ2W8plTWJwCtceB78vDAOwiChGqwy6t6okoddKi1oIm1TfmlDlfpIy pmolRJBZ+3bYnMulD++5nGswgibJldkYblSnCl9Q/tKQOnQWeqE3erX9uQbT9AdDKm/ydh7XkVy8 xQFwphfnJBpjRBlfHG4aRLCRsbIFZyH7ZWnOcGdCCRibS3KuzR37y45Wy6vkD4pYkeQ0xpbnj6IX saslrBnfWGt6Ow87+2/6i7JHMrqDmp0ZcWVW2uyIu2QLJ8G0ZmtSu7b39G7bMbIz+6s3Xx7xDF7f iOHKlENAKJvLycbA+q/HOdqgriuL2Sjz3X/OZy0zDcGdMh/X5i6jriO7ZEsoRks8FMjPyGweXMJF fCUjaLgPqArrssSHHCAfPMWXclLssadPnLpRpwlPOsP1fNbMSMiDn8g5KL1lXJjjOcDXHV47XYfm /uiUyrq1APTgPI+rhfgvS1jV6Rk0b70TFTTWP53egX0wn3OAdQ7YJ6XvYIZ9+I2hswjbn0+pzSgO 0hzcGRHVJ92PN8TePek/Q71kUzM7c2k7Fu+efG8+TzmYcqTiH8baX0iLd+wwn/3NGU6xoeiXVn3U 67Wilo6pRjLlFSpKz2r0+WmhimieDrWxbXSv5Kr1DdHkeb5IFx5PQ4ZDK/X6hlZK9EmoaB1z734Y MR9JJ+KrrqJN0GpoJR9Sy/5S301F7xBOf/cY3XR/K2IJT//p82nuX/SAOzcjoQ6T1hPzx2qvsqqv 3lCfAjdc3zZJNmvCrD8fHWv6y39HgDW7ZmvC/nx1+9z//PM/vJZrNAGEAAQDEBgAcBBhQoULGTZ0 +BBiRIkTKVa0eBFjRo0bOXb0+BFkSJEjSZY0eRJlSpUrWbZ0+RJmTJkzada0eRNnTp07efb0+RNo UKFDiRY1ehRpUqVLmTZ1+hRqVKlTqVa1ehVr1qoBtHb1+hWsQwEDXhIYkODl2AFrBxDgOnOsx7gB yM4lm/auRLNoZ9Id6TdsYMGDpcZtCRhvwgMI3sY0zPExgMiJJSKeOplwZs2bfRoOYIDggYOL274l 7fbgZ4IGRw9EnZAtANUIRI8FLfqgAdYAEAiQDZq25LuYD07WnRo4boTHD/b+HVp48boDbiec/n1g unTkqxlezx7Xc/K7s1mPXYyA7/XtBReaR8B+PevY6m0POEB+IXPevukPz6vdPfQAMEC5AfgDbrfT uIqNswYdfNCxuwgwKAAC7huAq+PoypC1CWWzUDYMB9xNOwA8rPAA8xQyTKCDTrSQxf8SmqxFEykE ESEWEXDxxhT9E045hE4cKLoiXwySR9mIBC+7EZWUsEcgAVgsyQAEPHJF6j7EDUvDjlTRxi2zLG7H MFGMcUwVqawxgTKx3NBJ4iCck846ISMLTgDapOs+hPhsLM8W/2TIrrfaHKsxhJwjMERDe/uRUBkL PahNhRYVLc9Df0RUoUybnFSyMv0UUc/v/rLztFEyiwQ1gFZJrTFHUisNdEdQNeWK1oUuTVXPR0uM ddW7ds110F/tPBbZZCGyC1gBzBJQsmfRoouttYqTdkzExiLuAIMYCzFWNCNdcUdtZeyWN1zz2nZT GcEF8Edqq+10XVOjMzfEaj/FU0Z5GQRWO3+tZVY6z/R1F91vzRW3WUi7hVPg4bCVU9mKLZ7TVsZ8 m7LcjanMUzbZPBY1YFl9XYiuGjNlDNL2ZNTQZHpVNhkwJlF+ld+SAaX3LZttDpTfndEMNAGQExXO UV5DztjgnWUuc+WaJd03NfQISI3UkAMYuciLvf7aQS97TLnXEH2rNMwBryYbbYC/dLe5/uCqtJBs 0Bp6LADs3sLSUrnNpNvAAZtUSEOzzBY8SbXzu9FewwqHMrerxR0SLQ8Vn1FLK7lkzQDJIT8zL8s7 Z+g95Y6se+pghYQ27dHZLhdusGWfvavwoOO4rZFz36601nbHfL3aYtfbz+RGCy1nzNkqCFDjFyI+ +ONpG5xw5KXHjnfUwKh++uhsfq6g8UDrXVz1nusd8/OUU4188aHDe/zXFIIefNyw6x54hhP4j/3X Ttt4IA2IHe0IWEADTiQBV5tJApeysVBRhYEHlOAEKTiUCvElJhdcin0+RKKnaLCCIRThCGViG7ho qYEDgU9UTEhCmqjChTGU4QxpWEMbDN4QhznU4Q55eJOAAAA7 ------=_NextPart_000_0016_01C64363.3F39974E-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 20:22:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9rD-0002lp-M9 for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 20:22:23 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH9rC-0005Bp-6l for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 20:22:23 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 50A14430071 for ; Wed, 8 Mar 2006 17:22:21 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3C7EB43006D for ; Wed, 8 Mar 2006 17:22:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 25429398012 for ; Wed, 8 Mar 2006 17:22:01 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0FB2F398019 for ; Wed, 8 Mar 2006 17:21:57 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2006 17:21:58 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="312777768:sNHT34271044" 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 k291Lv7T015616; Wed, 8 Mar 2006 17:21:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Wed, 8 Mar 2006 17:28:51 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B335D3@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8A== From: "Salowey, Joe" To: "Avi Lior" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.8 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 I would add that the AMSK for a particular application should be derived such that once the AMSK is derived for that application there is no need to continue to use the EMSK for derivation of additional keys for that application. =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Wednesday, March 08, 2006 10:24 AM > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > So there might be reason for caching the EMSKs. So language like the > following: >=20 > EMSK is used strictly for generating AMSKs. >=20 > EMSK is not transported out of the EAP Authentication Server Layer. >=20 > EMSK MUST be deleted when the session for which it was created is > deleted. >=20 > EMSK SHOULD be deleted sooner, when it is no longer required. =20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Wednesday, March 08, 2006 1:23 PM > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > The EMSK is the root of all AMSKs, so a compromise of the=20 > > EMSK compromises all AMSKs. Therefore I would like to see=20 > > the EMSK protected as much as possible. Once the EMSK is=20 > > securely deleted it cannot be compromised. I would like to=20 > > see applications be as independent from one another as=20 > > possible and not have one application require the EMSK be=20 > > cached once its AMSK is generated. This implies a deeper key=20 > > hierarchy than if an application derives all of its keys=20 > > directly from the EMSK. =20 > >=20 > > Caching itself is new functionality in the system, but seems=20 > > to be required whether you cache AMSK or EMSK. I don't=20 > > really have a problem with caching the EMSK if it is required=20 > > at the system level because all applications are not known at=20 > > the right time. It think it may be OK for an implementation=20 > > to cache the EMSK for its own optimizations, but I would=20 > > prefer that the caching of the EMSK not be required for any=20 > > particular AMSK usage. Since an AMSK is exportable you have=20 > > more options on where it can be cached. =20 > >=20 > > Hope this helps, > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > Joe, > > > I can see the problem with transporting the EMSK to other=20 > > entities -=20 > > > however, what really is the concern with caching the EMSK=20 > > as long as=20 > > > it is never exported? Is it just the concern of having to=20 > maintain=20 > > > state or is there a security concern here? > > >=20 > > > Vidya > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > To: Avi Lior; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > Hi Avi, > > > >=20 > > > > >=20 > > > > > Perhaps you missed my poorly stated point :-) > > > > >=20 > > > > > What if the user is requesting access to a new application?=20 > > > > > which could > > > > > also involve the modification of the user's profile.=20 > > > > > If EMSK is not there, then what do I do? Restart the=20 > > session? No. > > > > >=20 > > > > > At anyrate I belive that there could be other use cases...=20 > > > > I gave two > > > > > reason why: > > > > >=20 > > > > > Just-in-time; > > > > > Dynamic-Application provisioning. > > > >=20 > > > > [Joe] Would you agree with the following: > > > >=20 > > > > "For any specific application once the AMSK is=20 > generated for that=20 > > > > application there is no requirement to cache the EMSK for that=20 > > > > application, however there may be a need to cache the=20 > EMSK if the=20 > > > > system requires other Masks to be generated. " > > > >=20 > > > > This makes the caching more of a system issue than an=20 > > issue for one > > > > particular application. =20 > > > >=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/eap > > > >=20 > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 08 20:43:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHABd-0008Hi-LE for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 20:43:29 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHA7E-0005b1-2T for eap-archive@lists.ietf.org; Wed, 08 Mar 2006 20:38:57 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B52394300DA for ; Wed, 8 Mar 2006 17:38:55 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 754A143006D for ; Wed, 8 Mar 2006 17:38:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5E9E3398012 for ; Wed, 8 Mar 2006 17:38:36 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 500BA39800C for ; Wed, 8 Mar 2006 17:38:32 -0800 (PST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k291cRFT004985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2006 17:38:27 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k291cImG001918; Wed, 8 Mar 2006 17:38:26 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 17:38:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Wed, 8 Mar 2006 17:38:19 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5109@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObg From: "Narayanan, Vidya" To: "Salowey, Joe" , "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 01:38:18.0199 (UTC) FILETIME=[24303E70:01C6431A] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Putting all this together, is it fair to say this then?=20 "The EMSK MUST NOT be used to generate any keys other than AMSKs needed for the same EAP peer that owns the EMSK. The EMSK MUST NOT be transported out of the EAP (AAA?) Layer and MUST be deleted when the corresponding EAP session expires. Further, an EMSK MUST NOT be used to generate more than one AMSK for a given application. If more keys are needed for an application, those may be derived from the AMSK subsequently by the entities sharing the AMSK. It is RECOMMENDED that all necessary AMSKs corresponding to various applications be generated immediately upon EMSK generation and that the EMSK be deleted right away thereafter."=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Wednesday, March 08, 2006 5:29 PM > To: Avi Lior; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > I would add that the AMSK for a particular application should=20 > be derived such that once the AMSK is derived for that=20 > application there is no need to continue to use the EMSK for=20 > derivation of additional keys for that application. =20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, March 08, 2006 10:24 AM > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > So there might be reason for caching the EMSKs. So=20 > language like the > > following: > >=20 > > EMSK is used strictly for generating AMSKs. > >=20 > > EMSK is not transported out of the EAP Authentication Server Layer. > >=20 > > EMSK MUST be deleted when the session for which it was created is=20 > > deleted. > >=20 > > EMSK SHOULD be deleted sooner, when it is no longer required. =20 > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 08, 2006 1:23 PM > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > The EMSK is the root of all AMSKs, so a compromise of the EMSK=20 > > > compromises all AMSKs. Therefore I would like to see the EMSK=20 > > > protected as much as possible. Once the EMSK is securely=20 > deleted it=20 > > > cannot be compromised. I would like to see applications be as=20 > > > independent from one another as possible and not have one=20 > > > application require the EMSK be cached once its AMSK is=20 > generated.=20 > > > This implies a deeper key hierarchy than if an=20 > application derives=20 > > > all of its keys directly from the EMSK. > > >=20 > > > Caching itself is new functionality in the system, but=20 > seems to be=20 > > > required whether you cache AMSK or EMSK. I don't really have a=20 > > > problem with caching the EMSK if it is required at the=20 > system level=20 > > > because all applications are not known at the right time.=20 > It think=20 > > > it may be OK for an implementation to cache the EMSK for its own=20 > > > optimizations, but I would prefer that the caching of the=20 > EMSK not=20 > > > be required for any particular AMSK usage. Since an AMSK is=20 > > > exportable you have more options on where it can be cached. > > >=20 > > > Hope this helps, > > >=20 > > > Joe > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > Joe, > > > > I can see the problem with transporting the EMSK to other > > > entities - > > > > however, what really is the concern with caching the EMSK > > > as long as > > > > it is never exported? Is it just the concern of having to > > maintain > > > > state or is there a security concern here? > > > >=20 > > > > Vidya > > > >=20 > > > > > -----Original Message----- > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > > To: Avi Lior; Jari Arkko > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > Hi Avi, > > > > >=20 > > > > > >=20 > > > > > > Perhaps you missed my poorly stated point :-) > > > > > >=20 > > > > > > What if the user is requesting access to a new application?=20 > > > > > > which could > > > > > > also involve the modification of the user's profile.=20 > > > > > > If EMSK is not there, then what do I do? Restart the > > > session? No. > > > > > >=20 > > > > > > At anyrate I belive that there could be other use cases...=20 > > > > > I gave two > > > > > > reason why: > > > > > >=20 > > > > > > Just-in-time; > > > > > > Dynamic-Application provisioning. > > > > >=20 > > > > > [Joe] Would you agree with the following: > > > > >=20 > > > > > "For any specific application once the AMSK is > > generated for that > > > > > application there is no requirement to cache the EMSK=20 > for that=20 > > > > > application, however there may be a need to cache the > > EMSK if the > > > > > system requires other Masks to be generated. " > > > > >=20 > > > > > This makes the caching more of a system issue than an > > > issue for one > > > > > particular application. =20 > > > > >=20 > > > > >=20 > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, > > please visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > >=20 > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From afzelia@cityofmyrtlebeach.com Thu Mar 09 00:46:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDyP-000431-Ox for eap-archive@ietf.org; Thu, 09 Mar 2006 00:46:05 -0500 Received: from cpe-72-130-155-117.san.res.rr.com ([72.130.155.117] helo=home-qo077qttdl.san.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHDyM-00041H-0T for eap-archive@ietf.org; Thu, 09 Mar 2006 00:46:05 -0500 Date: Thu, 9 Mar 2006 5:46: 1 +0480 From: "Dudley Goldberg" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Dudley Goldberg" X-Priority: 3 (Normal) Message-ID: <2861084887.20060309054601@cityofmyrtlebeach.com> To: eap-archive@ietf.org Subject: fw: TopPicker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0610-1, 03/08/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 CWTD files Change of directors, Mr. Ha to lead CWTD into a prosperous 2006 Pro filed: China World Trade Corporation La st Trade: $1.32 Official announcement of the Appointment of Mr Man Ha to the position of CFO is expected later this week. Change of directors was filed on Feb 28th. With over 20 years experience, Mr. Ha will bring a great deal to the table to continue the advancement of CWTD in the coming year. Just read the release connected with the filing. On February 28, 2006, the Registrant announced the appointment of Mr. Man Ha to the position of Chief Financial Officer, effective immediately. Mr. Ha had previously served the Registrant in the capacity of Deputy Chief Financial Officer. Mr. Ha, aged 43, has over 20 years of experience in the areas of auditing, transaction advisory services and commercial fields. In the past, he was executive director, group financial controller and company secretary of several publicly traded companies that were listed on the Hong Kong Stock Exchange. Mr. Ha holds a Masters Degree in Professional Accounting from the Open University of Hong Kong. He is also a fellow member of The Association of Chartered Certified Accountants and The Hong Kong Institute of Certified Public Accountants. Most analysts agree that China is the next place to look for future investments. CWTD is the one to pick, check them out first thing Thursday From xeffivxko@saigon.com Thu Mar 09 01:05:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHEHZ-0006zP-Aa for eap-archive@ietf.org; Thu, 09 Mar 2006 01:05:53 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHEHY-0004uZ-Lv for eap-archive@ietf.org; Thu, 09 Mar 2006 01:05:53 -0500 Received: from abek165.neoplus.adsl.tpnet.pl ([83.7.22.165]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FHEHR-0001mY-UH for eap-archive@ietf.org; Thu, 09 Mar 2006 01:05:52 -0500 Message-ID: <000f01c6433f$7ffd1190$a5160753@lemon> From: "xeffivxko" To: eap-archive@ietf.org Subject: Fw: eap-archive Date: Thu, 9 Mar 2006 07:05:43 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C64347.E1C17990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 ------=_NextPart_000_000B_01C64347.E1C17990 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C64347.E1C17990" ------=_NextPart_001_000C_01C64347.E1C17990 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Souza Nathaniel=20 To: falblemn@orofino-id.com=20 Sent: Monday, March 6, 2006 11:48 AM Subject: eap-archive ------=_NextPart_001_000C_01C64347.E1C17990 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Souza Nathaniel=20
Sent: Monday, March 6, 2006 11:48 AM
Subject: eap-archive

 
3D""
------=_NextPart_001_000C_01C64347.E1C17990-- ------=_NextPart_000_000B_01C64347.E1C17990 Content-Type: image/gif; name="xkbnb.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c6433f$7ffd1190$a5160753@lemon> R0lGODdhfgGUAYcAAP///6+rFDbxsBojFTeDCgAzZggAAICAgIAAAACAAP8AAAAA/4CAAL1A fwQSvp3HWjWQSOg8t6b3s88TIPQhNVSZBq6Qs0iG6W2ABMl5Y8FMKNoKYp3KKlFPrNIYdJ+i CP+aP86CEXX27uuyp1WgnaiwwZ+qfNVKnr33CrZ8ApgqUr1mpPb6yZdX6tbPXZOlCNgxDAYX w4KozLJXRtoE6I8tWulbKhjTSwh32EJ8KLNyp49YdwLVxndQSMZ3MkjGdwz6YwFkAQAAAAAA AAAAAADYqxMABgAAALD7YwEAAAAAvdTGdwz6YwH2////AAAAAAAAAAAAAAAAAAAAAAAAAMwA AAABVABhAGgAbwBtAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAhQEAAOT6YwEFAAAABQAAALT6YwEqadN3OAMBsyAAAACF AQAAqJLtAHD7YwEAAAAAsxb1d6CS7QBxFvV3aAgIAI0W9Xf+////JAAAAAAAAAAAAAAAYPtj AV5o03c4AwGzAAAAAAUAAAD+////JAAAAAAAAAAFAAAAAAAAACADAABYAgAAIAAAAAEAAAAB AAAADAAAABsDAACeAAAAAAAAAEZs03cAAAAAAAAAAMwAAAAFAAAAhQEAAAAAAABYAgAAAiT4 dwAAAAAAAAAACgAAAFAAAADwku0AJAAAAAAAAAABAAEAAAAIALT6YwHwku0A6PtjAQIk+Hdk dgAIAAAAAI0W9XdeyNR3AAAIAAAAAACoku0AdvxjAXDKrwGU/GMB4wQAAKiS7QDM+2MBzcfU dzgDAbNwyq8BmMqvAWTKrwH8+2MB2fjGd8D7YwEKAAAA9v///wAAAAAAAAAAAAAAAAAAAAAA AADMAAAAAVRhaG9tYQABdvxjAXDKrwHAiCUByIglAXb8YwEKAAAAxGfGd1Roxnc4AwGznAAA AH0AAACfoggAdvxjAQoAAAAAAAAAn6IIACwAAAAAfgGUAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXrzAZiGVQcKxYgmbPlh27lu3A tGQXwlX7dq5au2YF4kUI12Deg3jjAvir1+1gwocNJ7yrOPFZxI7J2kUbOC5dsBURp6Xcl7Pg yJ4h+51cl3Rly3vbbvbMN7Vj1oUVr14sWPNf225dn667dcdGwrMjBweOe67CwKWNC+9cOfTw xsk7v04ePbTc2oZnE8+eendhzBZv/hdHfVm8bPOfRzOmK1p9+unwVxdvfVk1bOGxoXOmDpr/ 8/XvtacfeA3lFRx88bF14Hz0kYddfYBBt92Dn03YIG3lcYcehJSxtqCCkKHnXmsEToTcfQmS xl9+GDoYnYASnoighREqx+KKIH43YGLOhejajaK1x2OJEMl445FGzrijjD+u+CKDSA74I5Q5 HjZkjT02lmSSCO5H5ENmNSCdkuwZCaV7/43pZH5Bnlcmh8tlKOeD+C05p41xuqnmkW19CeZm uEVwX19nChmnfddBKKKTNI54IY6PAQrnlXXqGemdUmb6np8NUlgdmW9S6GKLpCYaYG6W8imk ofJtB+Sk/6lGqaGnptLHaYGx5llhrlyiqNqebYaaJaazjmkmgLFhiGKrd/L5qHq3MuQjselN u+ueiNaIp7MpVrutblOGO6qd13qLLGyGrllatLVa96Kjn7K5abZoHthlt+bGaCOXwJa5Lm2+ SlqfwPP6yhu7CJe440wLJ+zwVQ3HFPHDFEs1KcMFV6zxVBeHlfHGIIcs8sgkl2zyySinrPLK SznA8sswxyzzzDTXbPPNOOes88489+zzz0AHLfTQRBf9kg5GJ6300kw37TRWCkQt9dQARH2Q 1VNbLVDWCiTE9dZcS01Q1leTXXXXY6Nd0NdgU21Q2FirPVDccJ9t9tx1a1223f5f653223KD vbffY/MtdtphG0444WevvXjgggOuuNiJO97R43tHrnnjkuNtueNqH273334z/rfnqJ/eueqb c7656aMD3jXspjNuO+SNi1546XrTLjfvq7f9+fCk4+567K0HcBHmq/ce+O3EH9+685ZTr5D1 qWdPPPSsu+477pQb73v3rQvu9u6Qaz2+6tyb/zv48EuvvffGV8T88NhfX7/2tc9ev/r70xzs ove5/kUvf+hbW+7Ex0DyyS93yNua/ACIkPsdD3PAC57n1se+AErEgqlzngd1l7n5LdBr/muI CBkywLY1sHsInJv0UsjBztVwg8KToQFvmMHXhe6HJf4sXgXj90CLPA5uQMTb+WRHwunFb4BL 1B/imujCu5WPf8/7YeLQ1jv3bXF/UXQg1pSowyfmLYus62EMH0i3vhGxhRMBoQCzGEYlNlGO JxxiEQ9oRRMSEItpFJ8A3adHFELxiYiT4A5fWD4KdtCEiyxkAT0YETyuMYf6Q6MYU1hIOO7x jgGs4wzZ5kcgmpKRkgwiDhPJyeoxsI+R413lDCi5G8aSkhCxZBJTiUI+Du5/u+QlAVvoSF9m j3aBLCIciYlI0LUSdTXkXg9vqUpCVvOS9tMk/oI5QW02UpsYfJ8UnajBZBozhII85jMdyM4r jlF23RTcCzR4u2lukIiuFP+mJ43oTXSqM4jtIyMmdRe3P85xk/rspzTTqUdbGhSQVWvo+7g5 vyOKs5ao5Fw07YkRXSquisCs4/f657aAgvSkZfsiPfvpxb5JEYmTk5sJPFm5iFZwcs4kGy1d iNC6gVSLboTlPp9GVLBAoKhITapSl8rUpjr1qVCNqlSnStWqWvWqWM2qVrfK1a569atgDStD QiDWspr1rGhlWgbSytaEdKCtcI2rXH9Sgrna9a54zate98pXp1mgr4ANrGAHS9jCKrUABcAM YrmyWIEstrEAeCxiJ+vYyUJ2IZcFyWUTa1nJDkSyli3IZhMb2c5WNrQE6SxpUWva0n6WtAdR rWv+RQtbhGRWs7W1yG1fG9vcOqWxwF2tcHlbWZtQ1rGzJW5ydzva5C7Xt88trnM5O1zMwna3 M8GuRLTLXOgyxbPFhax4r+td2woXuq0dr2tze9zIOje8te1uaqk7X+XWV7rBTe16y3vf/Va3 vcQF8GlBK93ZHre1Aa5uac8bXM+2V7tKQe2A+6veh4CXveSNroSRC9z3npa2va1vcwtM4f/6 dsMKGe9wLwziDt83v+p1sXwNvFr8Zvi1Jp6KgHd8Yw8vGMM+1nCGmRveH6sYxAZRLXgLPGMa k/jDDqnwfoO8ZCTDeMhADnGVbWzfCkM4KRsOM4KDbF4ol1jIsS1yd7P+jGT4njnJCM4vbb+s 3BifF85mTrCbbdzjFtN3wAoesZOlsuRCe5fO/X2vnXlL5A/ftspNnnKd0UtpEtMX0VKGNJsV nWMpDxrOsh20pz2t4xx/us0NeeyTF71gH5P3z5O2b5dhHV0823qzn27yohVcZE5zucHuPbWV byzn6RKbv2DGMqMPjexhU/rBDkaviE2b6UonWMwhnjODA83rWO9ZwDQ+sakpC2wcZ3u00GZw rRFt2I+wu91Faza8503vetv73vjOt765SoF9+/vfAA+4wAdO8IIb/OB41QDCF87whjv84RCP uMQnfpAUUPziQzOAATqicYJ3XCAf17jINw7/gI+XnOQjN/lAUo7ylJ985C8XOUFYDnKSr9zl Ju+4ymtukJC7POYx3zjNbz5wn/Oc6EY/+cxtfnSl77zpOW/50pU+9ao7XeUyL0jSqb51qnv9 6fvWuc2xLvSyE/3saBf7QaJ+drJ7velQL7vPd872o3e97nD3N8zRfnW38/3rZu/52AcPd7Vb Pe4lD/rbAd92qaed6WDPd9b5Lnamv53uhB864Pd++cDfHOZsb7njH9/4mstc83kP++Q7D3TK W37oYA895Ge/eMwjfeV/jzrn7+75v6ue8Uj3vN99H3vCA5/ntre6ztf+euNrffRcb77Ak+52 6tP+8Kk/Pu9rL33k/jP/+b6PPkE+4PzF/97uP6876lOvebxHf+80hz38vw9+84P++ujHOIEi fxH+618r/jcRAfh/BFiABniACLhwCIAACWgyDLiAAMCAEbiAFCgQFPiAEogQF5gQF5iBFuiB E1iBBbGBEDgQGLiBH2iCEtiBH0iCLJiCE6h/KFiCMFiCNGgQNgiCMGiBKkiDN6iDOZiBGKiC OwiBP0iERbiCSohxQziESJiDHLiEOOiBQiiCMWiCU9iCWPiDThiDR5iETyiFXlUDP+GDVCiF NziFaYiEI4iGOtiGPGiDV5iCZjiHcAiGLfiGMniGNaiHWmiHVyiCUJiHbyiHXmiHRliF/4RI EGaIgnmYgFzYh1HohSBYh4FYiEC4gnSIiF24hpZIiVkIiXx4iZMYgqFIiR34gIyYiTyohZFY h6M4h4PIhgcYiaSogUrIinTIh7H4hD0oi2JohKvIhp8IiAaYio+IjG2YiGpYgbb4gqsojESo jItYjXh4jQ2Yjdq4jdzYjSkTA1BBAN44juSYFAdgEgdwjgiRjkrBjjLhjgAAj36SjvRIEvI4 EPRYjwZxjxShjgXBj//oj/nIj/A4kAIBkCJhkOvoj/GokARxjwTJkA/pkAcpkBAZkPgokQQi jxrZEQBZkB2JEQ6Zjwqhjw1ZkurIkSd5EiC5jya5kguZkRz5kv8TuZApeY4F6ZIZySkq2ZLs iJM4WZHu+JNDSZI1WZEnCZRCeZMtWZMpeZQHoZRIGZNTeZBJOZM32ZAWaZRGCZUIOZMJEZE6 GZUdKZVEaZVkuZNfIpZISZJumZX6WJRp2Zb1eJZqKZdOOZf7WJUUyZcaGZdPeZVwaZErCZGE qZdayZZQqZYuaZJZeZVoOZYwWSKKaZcwKZdN+ZGE6ZMMiZc2+ZdlyZiLeZmgKZqQSZc76Zl+ SZWSWZWmOZkxeZhaiZYv2ZREUplSSZpveZdlqZCcOZFd+ZkY2ZjB6ZqkKZlFWZebuZzFaZvD 2ZqwGZ0I6ZQD+ZeouZpr2ZnHaZuGyZv/iLmaYPkQuRmdzzmazpmbdmmZ6jmez/mVIdmd5Wmc 3/mR13mcVSEAENGTTGmfl2mfmomc45mTsPmU4WmcQ2meshmP2zmYqbmfAsqYqnkAI4CPCAqd k/mTFfqPDQqhIQkWI3mW5wmYHCqRuLmUJiqfH8qVJLqV/7mUj1mYuzmVynmiAemYTAmYNOmX KqqiLgqdKyqb0wlWHcoRQUqkQzoSRaoSznlWR7oRSVoRfamkTcqSCVqOVnqlWJqlWqoRT0oz U0pYvvmlFpqYXeoQ1fmdDXGmRmqmNaqZNlqcYqWf/dihZSqeVXoRdWqnDOGbGQqjcSWnb4qZ ZIqYPAqUylma/6hpljj6nj/ali56oz06oEGpoPGZmWLKVRHJoHSpmu05mOn5ouA5o+HZorRp qOipqK7ZnXS6oryZo2UVphtan+SJnespo6xan5bpp2Naq9fJqWRpmG5Kqm1Vq7/5miM6o7Zq oLAqq2pangbJnabqq7/am506pkJKnbF6mvLJodWqq69ZrNvqlZq6oNa6l4qJnaMZp9iKqwG6 qhDqn6AqncvplXqJmYeJrJRaoLSZlEdJrOkapzxqqyIKnIQ6sLoKn+J6onCaqjEqlDCKlSja lR8aqYO6pTORp+tosU0Rpf2osR77sRSTAyA7siSrMhg7bxOLpBxrpiurE9O5pIWlkv+zuqbh uqd3OhIcgKfuim/6KaqRSpQsirDEGq/QCpLJebSG2qOBuqky+aZKe6Oemlek2rBAy67VWqxC +5i5irWaaq9Mq60H6q1DG69ylbIr+QDgyqtN65mf2qaWeqHz6qd42bZpe6t1y596xbZAeqp4 S64CW5pYia9+67Vy+6xx+7B667czm1ad+aLQqrhZC69suaQF2ranSbjcyrWhmq0n21WNi653 m5xXu5/b+rZWWbmoernjyreiO7eHq7Z2RZGCu6wPK6kSewAV0LcMS6M76rq9qrUG27pQK5OI 67iX6m+dW7Ml+xMty7LL+7zQG73SO71AkwAJ4BTWe71BYb3/C8G97Xa93Ku92eu9ADC+2lu+ 49sQ2VsQ57sR3vu+7UsR5AsR5Du/BGG/BoG/DqG/6PtV6Vu+9wu+5xu+Axy/BizAAxG/GoG/ /Eu/Cqy+D5y/EZzAE9y9EdzAVYXACkzAFNy/AmG/B+zBFUzA4gu+H/y/6UvCICzABby+6OvC KMzCJ7y+9Qu/ElzCL0zBMGzC5su+MWzDLEzCSMW/HHzCHnzEH+zDIqwQO/zCCGzEIozDN2zE NQzFUZzDVwzFOLzCSdzEVRzDCFHF/ZvCUozBTgPGVFzAM/y/WFzCG6zGYpzFNizBHSzGdvzE WYzEYxzCHZzGddy+RKzGe9zHc/xU/0U8yFacxAmxxXyMyEc8x4UcwH9MyC1Mw4J8x5Y8xY+M x4esx33sxIcMyRVcVKHMyQbMxH4syam8yVosxUq8yoXMxa08yY6sxF8Mx4B8wYL8yaLMVLnM ynGsyAeBy6/syHc8y3QMy65cv6wMzIzMvsrszKqczI/czJGcVD28xpU8yvfrw2+MxtpMyTrs zS4MygHsxsvcwlGcyd5sxfDbxOc8zO+czsgMb2a8wNycMytQVvecEf1MvQAd0AI90AT9EgNQ 0Aid0Aq90Awt0CDQ0BAd0RI90RRd0RZ90Rid0Rq90fq2AB/h0fi2ACIN0gAw0iM9ECZd0ibt 0SJNECy90v8kLRAxXdIofdIyDdMF0dIordIpHdM+fdM6/RAzrREzHdQqTdMuDdQgDdNFbdM8 7dRIrdRDndQ5fdJMXdVU/dQ7vdUy3dVZQdJLfRBFbRBG/dNindNendZq7dI/PdRm3dVv3RBT jRFNzdZRDddZfddZHdZnDdZ5ndRx/dc1TdVmHdd8jRV+rdeK7dZRHdhcjddo/diAvdNTHdZ8 PdeQndJIrdk8XdNL7dQrjdaWrdcsnRBzndin3diRLdqSLdiQTdOMvdmyvdZVgdpkfdusrdap PdmrrdivXdq4DdyHLdbDXdqBDdy6fddjPdrLbdoIYdt9LdmVrdrPXd1+HdujTd3/iA3aoe3W 3e3Vji3VLR3btA3ecB3asn3YnM3Vba3cuZ3cx53epK3Uvc3WQY3T1D3Wqz3c9b3V2U3Ymd3a VKHeuC3Y1+3a803evq3ayM3bsH3We/3d+K3ZOo3T8X3UD27gCE7gBc7f5M3fG07Zi/3b2n0V 0K3h++3eEC7ivb3bD37aYO3iac3YH+7gj63fFT7fLV7d5k3WFN7f6I3ZLm7cHR7jCC4VJ/7X Cl7WPO7fSt7kRy3jJa7f7t3gyN3eLI7hrc3hht3kIN7cWx7ZUn7jxf3kXtHW6K3VFm7XAq7j Wt3fuv3SnE3lb57XP17nPX3f3N3gIw7U9k3ndv7U4y3a/+st3Z4d3sod40bt5gvO0UbD1JAe 6ZI+6ZRe6ZZ+6SKNAZi+6Zze6Z7+6aAe6qJO6Y5e6qZ+6qguEwOYMpbHEq1eE68OE68e6y/x c4L3ELYefks3ebae65y3EGP3ebgHcsL+fLHHELQeEauH68RO7MEOf7++djMngDYBec2OEMku EgG46onneslOe7JXehCBcsPe7eR+7a9X7uqO7RuR7eze7Od+7t0+7wqRcxTh7ilh7fTec67e fEa37PX+7PiOfJlX8BIhdOuO8ME+7eXueMsnevAu73JnfsO+e8fu7Li38POO7whv7vHu7PZe ddCue+jeei8Xd9XH69B3En5Xef/ZR38rH/CMJ3vRfvKnp+8Zj/PXvvHm7vEl3/Edn3gfL+08 /+2ux/A8b+wMr/AY3/Ppzu/PnvFS3/RCv/RJD+/qHvT5fn8Er+v1V34yP/MG//Jad/UYr/E7 P/JA3/BCf3pTL+9lX/T1PvVVb3o6nxAF//B1f/duT/VB//dy/3mAX/EVv3wrQXZcT/aPl+vY 7nyGd3Veb/Ul3/OTn/CSL/c4v/aUT/hUn/acP/RxD+zTLn1Yl/V+H/h1n/pan/mXv/YD7xHD h3hhf+vAjn+Pf/sc3/Ahv/FP1+pZt/ohZ3p2T/lw3/ceX/xsH/X8juxLH/wRj/Y2T/cQP/wL //tzl+7/1e/8W698wNf7tO5+eRfuXa/4T/H6zM8T5v8lmHf94M9y3cd96WfxKg/wFZP+KmH/ qX4rNpD/M4P/HOH/AAFA4ECCBQ0eHGjAAEKGDR0iXPhQ4kSKFS0SjHhR40aOHT0eXJhRoMiP GCeKDMmQpEkAK08WVOjSpcGZMFuOVBkyo8KWMVHyLNkRJc2gRY0e/UiyJlKIRJs+Xdpw5cyo OF/eVNkz4U6nVZmytAr261iySHVijLl1JFCcEYFy1el2Z9qEWumGXZv3rVusW+UO7bk3b2C5 LPme9QnyZkquNvvu/RuW8drCgRWrJVxW8+akfSWbnMoXa8rFdUvjJT3V8Gir/mfBkl7dtvVj z6xLi659+3Tuu4dN73YNGLbT2Xg5H0fucDhty7XnvrX9F/bQxr8zi06sWrZjuJSnO9ed2vp2 3KqfY6/bHTVdqrFrt0geX/5y9dWZp/8M2PNw/fuLG6dNu/oG8kA9tLQ6zT7yPuMOwO8MjOgE 3lBzDzf5LjzOwsbSums/tuCCzLvVOkysOex4kgk6tL4bDUXTlHpxOw+NU5A5DkMU8afI2Fvx RBUxBDJIIYc0aAMij6TIKySXZLJJJ5+EMkopp6SySiuvxDJLLbfksksvg1KSyDCJG2vMo9i6 yMzxPOpQIjWb9CkqGBnMKjfv3vxqOeUABKnNq8za/hMm1+zKbiM8LzPzUCTDnPM+qKRaUk0L 67QzUEAhJerD6vBUtMGKOhWTJugGlW26UQlF0zoVKyOxRb9YbdHFEjNTa9ZUhStvsMhovRGz Em/FEb/JaETT1lPbQnEuGXkFSobe/MwyzgAnDS8/9ByMEUH8BJ3NvuCE3da/ACnc1jfWHix3 QQPzU2wyBbUD7tzixLtVRnT5xLJRFkFLMNxcHWPWLxpftdFFdiGskFYKf4112HjRK3TZcTP9 D1521Z33uq4mjtdLfR0t1baOa3z3WnFPpvc3h/cVWU8bbdKQY/F24/himCu+zOaUozs5RoRr jFbUmAHWceE1i/axufWk/qPMQ1lfbJNFEqf21mD2eIzOYJGbdm7SknV8js5rOdxY6WdT/TLt T40Cle0tGVU77iih1YhuDNu+UEm85ea7b7+phOEoGv4mvHCjSDA88T/75tRScovau0sXFN/M 5cjJchnfh+QEuFJKn9Kc4MWTmpVyK2U6/fO1MVXVIs6TDNX0uXnctVjaudaY1WSFFhG0uAxT 1kSmuR6+NU11H0zhxaLu0zeyhe9d25wRPBF32cvq7l6VqfdX+n5RdnRmfv3bUOaO7bVzZpbX J+5bidFfc3tXx7++cnDXNR99pP/LH/70rvaR9lZGP/pY7Xnkax3RxFVAqaFNZVcTmOfq57aQ /uEPYfrzGf8uuCzqJEw/6PJWzcz1QQJ2rma6yeCCJkQsnElwgkK5ndl6tDSC7W9rJkrg76C2 oxBtaFWtMhuOatcqkgFQMgbc0Q6xJbCkYe2FZ+LImy73xLlRcUqHGpPdgnQBK3bRi18EYxjF OEYylnFRU/wiGtNURSYtZAYmhJK0+nSSOC1FjoQ5D9j+FDaxoa108YOjoRy4OZ0xS4s9g12k 3DM9IQ0SM66ryU+0tTtdJUpsLQTPElnXmTVmrGWA5FboNjkk4YwySMASzCEfublBUZJQa3zX +R6HvNT80Fqk4s7ZciZA+e2pejzrTSh/pctpHS95pUuWppLXSEmi/2qZOUlSK6WJx9D8rlgw 6w/4RpirnX2vPSckWjMvKahS7sxc8ePlz8IlL3KFUI2C7NUrnzlHOh5zmsokZCxZ5jSm/es2 B1Tfo973GpkB0VLJdNfWlKK1dHZPjyEsWObyBjZXOnKVUgmePDVq0Wy97D6Nauf2+JOuG3Kz c+XjGZk+V0DpQbShGOQgQTvaTVKK057K0Zs4KzpNQh5xUxEUC/GcZrx+erJpPhya+VDXU6Iy KJgryt/ZGjjEeiFVlMix3f98laJQHsirG+Up5fb2TgqaMU0Lhcyz6HnROkonj68ia+Liykmz 1tWud8VrXvW6V8cxRY0SVR0pTQlK0DWSM/4crR+1miepdhG2Kdn0FE4Ri6lqAjaSrjtSVRR7 lbleabMKXN3NvOcmFy6SUlgcWFADedXVzoepUWSt6RDKViVGFK1O9OSxkAUshdXLeKVSq0a7 hs/KiI56tsOnxnZ7W/Icb6p2IZ6f0gqrzrbxYnp8mT/XOacR0ox9E8OuVsF7QxwaLakdVOA5 eSlSk8K0W92jGDCra91ikrB82q3jeBJaKPQu8H/XbOpPI3ZZq8aFhOVlL0P717+Xvtd/RyUq YAvX3vSmUJ9wpGR/ZUlhgqp3u5q7l8M6TCcROjSB52swOzesQsjKNqIztF54OejbxzwNvvCl Wth+Wl7sFjjGSv7McQSHqWDRFa13Q26udi3jY74WtsmxG92TuTRfKUsWs1XGcpa1vGUud1mv foSil8XsYkbStaNjRsGYPeZkM8dWzQ9RwZuhCVWrQm/Js5WYEe985ErGKnpyBvSVL9kfD+OM 0CQFIcYeHGhG54S7Hy5yttZlXwf/02oLbnSmTfswscBLfCMVaaVF7GGgaTrTVDuyEJO55BqS U6jnwloMnUhlU9daM7S2da7ZqGte99rXvwZ2sIU9bGIX29jHRnaylb1sZjfb2c+GdrSlPW1q V9va18Z2o2+QbW5329vfBne4xT1ucpfb3OfG0ALKIgF0b4QFjFb3QOKtkXkTpN7zXv9AvvFt b3nr+yD6zrdAAB7wgRPc3/Y+OADqrfCBK7wg6g54v9v9JIjLmyMLF7jFM67xfW/c4xrPOMZB 7nCP3/vjJOc3vyMucJFPfEgVD/nKAf5xiCd84x1XeckNsnCTtxzlKI83xmE+8pNXPOgk97nL 5TN0mf986Ej/t9N37nCTP9zqFvd51aFudZ5PPedHP7rSX87xnGM95SJf+cmp3vWrj7zmM3d7 woX+c4bPvOswf7rYhdTxnpf95lHXutkDX3S4Z/3sRKd624mO97Dr/eWF93viye51nJsd6F5H vOFB3njLZ57rLFe745f++c5LnuGhx3nVU59y1iPe7Zs/fOv+YU/3rYt+9CqHe93xTXCJt373 Td+8zTPf8NcHX+Z2J37dPU972zff+UcpePSlP33qV9/618d+9rW/fes/3/vfB3/4xT9+8pff /OdHP5dxHccnZVHQxt7Uhx5oMTi95HWB9WvdQpuVzw5Wzf40mVhiv0TCP9XKrP2jLP1rtH0a oE4LrqgpHiEDID5ijAehnfXZFeMyJuEJq+VyKt0qLmR6LzyTH8HgHt2ZrDECMPFKLRKTqO/i NP0JwHGxIBdMF0pjp/7qLkUrtIz5NNHaQVzap7tiQFkCHwRjohNrMKkxsRoMn/8CNW9SHiZs r1oisgr6HvAoKuWCMDcDIwDEpI//wa8HUyf3orABerRZ6pkBoRkc+6QdJDF5+sHxKaUSBBki nL9eki4gQyWQmcDowa0tzMKlgsAN1LOxuaYde7WhUh6PGkIjS6Ik9MJqA6kySb8xq8T8u8RN 5MRO9MRPBMVQtKKxYpP3I62JUimMYqSlskRnkzAENMAzO0UCDDPV8RqBCqo6ZLNOcixgI0UF tCRYBJO+6r9YzCT+SUVePLYYAkQKjDUY+SMS9CMIKpimMqRJGp4+DCJeUZqAaZgDMZZnOsQM u0DiSsEsy54Ri0EU0kEPUkOIGUETy8ETcsJ0bBDnyaHWASk2TDRFW0BwSbCGEkGXgsIOkzWy KcPDAKhj/6SP67pHhMzHADspRKPBgiwt9QNIm1Gq9HlCcKJHhdpIFfvIPCukFCJDh9xHirTH NrzILWPG3lK1H2rHEurGa6QhqhqbLiypH2lCAIvEaHyx4Xo1hQTBozrHQHO/NRPFLklKplzK p4TKqJTKqaTKqjwsU7yUvRKB59MsrOyMYnwtq9y1AiTLUmzJshTLM7InA2vGpMmRiKzARvQh o6RDqjqY6LKetExA75JHFBqZTMJHP9RC/YLHQuLJc9LLnooYw8xIKryZhBJMCmxBhglJfppE q0yqykRDk6wVOIRGQwOtEtqgFVo/77PLC3rG80AnSbtDpDlMOguWxeRAJExMwxq6zNo0Chyg oqfCzd70zSyZgN8UzuEkTiwLCAA7 ------=_NextPart_000_000B_01C64347.E1C17990-- From furuxus@009.com Thu Mar 09 04:55:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHrz-0000iC-56 for eap-archive@ietf.org; Thu, 09 Mar 2006 04:55:43 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHHrz-0003Lf-3N for eap-archive@ietf.org; Thu, 09 Mar 2006 04:55:43 -0500 Received: from [211.193.23.47] (helo=a-0nan7j2w5147u) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHHrx-0002ys-HF for eap-archive@ietf.org; Thu, 09 Mar 2006 04:55:41 -0500 Date: Thu, 5 Jan 2006 9:53:25 -0540 From: "Kelly Long" X-Mailer: The Bat! (v3.51.10) CD5BF9353B3B7091 Reply-To: "Kelly Long" X-Priority: 3 (Normal) Message-ID: <3899164361.20060105095325@009.com> To: eap-archive@ietf.org Subject: fw: Here it comes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.0 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Get GAPJ First Thing Today, This Is Going To Explode! Check out for HOT NEWS!!! GAPJ- GOLDEN APPLE OIL/GAS Current Price: $1.13 Before we start with the profile of GAPJ we would like to mention something very important: There is a Big PR Campaign starting on today. And it will go all week so it would be best to get in NOW Current Press Release Golden Apple Oil and Gas, Inc. and Franklin Ross Securities Complete Private Placement Golden Apple Oil and Gas, Inc. (GAPJ - News) is pleased to announce it has completed the initial private placement with Franklin Ross Securities of New Jersey. The company is currently negotiating with several investor groups for the next phase of financing. Headquartered in Phoenix, Arizona, Golden Apple is an independent oil and gas producer with a focus on North and South American properties. The Company applies advanced technologies to systematically explore and develop its oil and natural gas opportunities. Golden Apple focuses its activities where technology can be used effectively to maximize returns on invested capital by reducing drilling risk and enhancing its ability to cost-effectively grow reserves and production volumes. Golden Apple Oil and Gas, Inc has opened a Canadian office in Toronto, Ontario to facilitate the management of its Canadian operations. All correspondence and communication will continue to be serviced by the company's head office staff in Phoenix Arizona. From Mr.Ahmadatxu@yahoo.dk Thu Mar 09 05:11:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHI7h-0000O9-QW for eap-archive@ietf.org; Thu, 09 Mar 2006 05:11:57 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHI7h-00042B-P4 for eap-archive@ietf.org; Thu, 09 Mar 2006 05:11:57 -0500 Received: from [83.69.98.227] (helo=398A3848) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FHI7X-00033a-63 for eap-archive@ietf.org; Thu, 09 Mar 2006 05:11:57 -0500 Received: from firewall.alluvium.fr (firewall.alluvium.fr [100.152.6.124]) (HELO localhost) by MTA37.apophonia.ru with ESMTP id Auw54lVgNc115n66 Date: Thu, 09 Mar 2006 13:10:38 +0300 From: "Vince I. Gregory" To: eap-archive@ietf.org Subject: Fwd: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: -1.5 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Good day, Next Day Priority Ship_pingg=20 Xa_naa_xx, \/a1#ium, c_Ial_IS, \/iiaagraa & all popular me#dss. ************************************************************************ copy the address below and paste in i your web browser: achromatolysis.coralstrategy.com ************************************************************************ They were luminescent without having form or light.. I give thee the first suggestion, the problem and indirection,)=20. Velvet robe of a queen.. Out of the darkness, the ignorance, the night.=20. 'I guess I never really thought about it much.'. Thanks, Darren Kuhn From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 06:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJDB-0005ag-Ld for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 06:21:41 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJD8-0006Ob-FR for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 06:21:41 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 764874300E7 for ; Thu, 9 Mar 2006 03:21:37 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B7A6943005A for ; Thu, 9 Mar 2006 03:21:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A3AE6398041 for ; Thu, 9 Mar 2006 03:21:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id A1595398020 for ; Thu, 9 Mar 2006 03:21:22 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8374189864; Thu, 9 Mar 2006 13:21:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2EF3F89842; Thu, 9 Mar 2006 13:21:19 +0200 (EET) Message-ID: <44100FAD.1030301@piuha.net> Date: Thu, 09 Mar 2006 13:21:17 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D36B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D36B@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Glen Zorn (gwz) wrote: >Joseph Salowey (jsalowey) <> supposedly scribbled: > > > >>The EMSK is the root of all AMSKs, so a compromise of the EMSK >>compromises all AMSKs. Therefore I would like to see the EMSK >>protected as much as possible. Once the EMSK is securely deleted it >>cannot be compromised. >> >> > >OK, but is that not equally true of Jari's proposed AMSK_root_0 approach? > > The problem is that since EMSK is the root, its compromise will lead to the compromise of all derived keys. This also holds locally for the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised then any keys derived from that root are compromised (but not keys in other apps). --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 06:24:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJFq-00089A-AY for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 06:24:26 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJFp-0006Y2-VM for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 06:24:26 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9F36B43009A for ; Thu, 9 Mar 2006 03:24:25 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BE3F243005A for ; Thu, 9 Mar 2006 03:24:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A39C2398041 for ; Thu, 9 Mar 2006 03:24:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8B4539802F for ; Thu, 9 Mar 2006 03:24:09 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8511A89864; Thu, 9 Mar 2006 13:24:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3E95A89842; Thu, 9 Mar 2006 13:24:08 +0200 (EET) Message-ID: <44101057.8050606@piuha.net> Date: Thu, 09 Mar 2006 13:24:07 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Avi Lior wrote: >Perhaps you missed my poorly stated point :-) > >What if the user is requesting access to a new application? which could >also involve the modification of the user's profile. >If EMSK is not there, then what do I do? Restart the session? No. > >At anyrate I belive that there could be other use cases... I gave two >reason why: > >Just-in-time; >Dynamic-Application provisioning. > > Ok. I'm starting to be convinced that we need to support some form of dynamic behaviour with regards to AMSKs. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 07:04:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJsm-0001gF-BA for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 07:04:40 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJsk-0007jt-M9 for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 07:04:40 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0168D4300E8 for ; Thu, 9 Mar 2006 04:04:38 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2E189430063 for ; Thu, 9 Mar 2006 04:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E46DD398042 for ; Thu, 9 Mar 2006 04:04:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3CE08398036 for ; Thu, 9 Mar 2006 04:04:08 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2E68F89864; Thu, 9 Mar 2006 14:04:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CD73589842; Thu, 9 Mar 2006 14:04:06 +0200 (EET) Message-ID: <441019B5.3080600@piuha.net> Date: Thu, 09 Mar 2006 14:04:05 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <2EBB8025B6D1BA41B567DB32C1D8DB842D5109@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB842D5109@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Narayanan, Vidya wrote: >Putting all this together, is it fair to say this then? > >"The EMSK MUST NOT be used to generate any keys other than AMSKs needed >for the same EAP peer that owns the EMSK. The EMSK MUST NOT be >transported out of the EAP (AAA?) Layer and MUST be deleted when the >corresponding EAP session expires. Further, an EMSK MUST NOT be used to >generate more than one AMSK for a given application. If more keys are >needed for an application, those may be derived from the AMSK >subsequently by the entities sharing the AMSK. It is RECOMMENDED that >all necessary AMSKs corresponding to various applications be generated >immediately upon EMSK generation and that the EMSK be deleted right away >thereafter." > > I think I can live with this text. As I said in a previous e-mail, I have been convinced that we need to support some form of dynamic generation of AMSKs. We also seem to be coming to a consensus on keeping the EMSK at the server side. But I still have a few nagging thoughts: 1. In order to avoid a situation that suddenly all AAA servers need to start keeping state, do we need to require an authorization profile flag, configuration knob, or attribute to signal the need for keeping state? 2. The text does not tell us how to determine when all necessary AMSKs have been generated. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 07:36:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKNn-0003KO-L1 for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 07:36:43 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKNl-0000GH-7V for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 07:36:43 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4A46C430103 for ; Thu, 9 Mar 2006 04:36:40 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 95C2F430063 for ; Thu, 9 Mar 2006 04:36:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 81A91398042 for ; Thu, 9 Mar 2006 04:36:20 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 78D4A398031 for ; Thu, 9 Mar 2006 04:36:16 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A30BC89864; Thu, 9 Mar 2006 14:36:13 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 599B889842; Thu, 9 Mar 2006 14:36:13 +0200 (EET) Message-ID: <4410213C.2070603@piuha.net> Date: Thu, 09 Mar 2006 14:36:12 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Bernard Aboba Subject: [eap] EAP WG agenda for IETF-65, take one X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Here's the initial plan for our session in Dallas. Send e-mail to the co-chairs if you have suggestions or other input regarding this agenda. Extensible Authentication Protocol (EAP) WG WEDNESDAY, March 22 2006 Room Metropolitan Other WGs meeting at this time: crisp, nemo, psamp, sipping, sidr, dkim 1. Administrative (Chairs) - Notes takers - Agenda bashing - Document status 2. Remaining keying issues (Bernard Aboba) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-10.txt Close the remaining issues. We do have some hope that they are already closed before Dallas, in which case this agenda item will be deleted. 3. Remaining network selection issues (Jouni Korhonen, Farooq Bari) http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-03.txt Close issues from the WGLC. 4. Generic EAP encapsulation proposal (Barany, Dondeti, Narayanan) http://www.ietf.org/internet-drafts/draft-barany-eap-gee-00.txt Provide feedback from the EAP community on this proposal. (This item will be discussed if there is time left after the two above ones, given that we are attempting to close the final WG deliverables.) 5. AOB _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 09:18:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLyL-0005UN-MW for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 09:18:33 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHLyI-0003LC-3j for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 09:18:33 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5745B430114 for ; Thu, 9 Mar 2006 06:18:29 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B6D2F43005A for ; Thu, 9 Mar 2006 06:18:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D52B980C120 for ; Thu, 9 Mar 2006 06:18:08 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id E092080C0EB for ; Thu, 9 Mar 2006 06:18:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 09:20:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAbQwzg From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Hi Joe > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Wednesday, March 08, 2006 8:29 PM > To: Avi Lior; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > I would add that the AMSK for a particular application should=20 > be derived such that once the AMSK is derived for that=20 > application there is no need to continue to use the EMSK for=20 > derivation of additional keys for that application. =20 Yes I totally agree. AMSK derivation happens within the EAP Auth Server. Derived keys from AMSK happen within KeyHolder/KeyGenerator function which is external to the EAP Auth Server. =20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, March 08, 2006 10:24 AM > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > So there might be reason for caching the EMSKs. So=20 > language like the > > following: > >=20 > > EMSK is used strictly for generating AMSKs. > >=20 > > EMSK is not transported out of the EAP Authentication Server Layer. > >=20 > > EMSK MUST be deleted when the session for which it was created is=20 > > deleted. > >=20 > > EMSK SHOULD be deleted sooner, when it is no longer required. =20 > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 08, 2006 1:23 PM > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > The EMSK is the root of all AMSKs, so a compromise of the EMSK=20 > > > compromises all AMSKs. Therefore I would like to see the EMSK=20 > > > protected as much as possible. Once the EMSK is securely=20 > deleted it=20 > > > cannot be compromised. I would like to see applications be as=20 > > > independent from one another as possible and not have one=20 > > > application require the EMSK be cached once its AMSK is=20 > generated.=20 > > > This implies a deeper key hierarchy than if an=20 > application derives=20 > > > all of its keys directly from the EMSK. > > >=20 > > > Caching itself is new functionality in the system, but=20 > seems to be=20 > > > required whether you cache AMSK or EMSK. I don't really have a=20 > > > problem with caching the EMSK if it is required at the=20 > system level=20 > > > because all applications are not known at the right time.=20 > It think=20 > > > it may be OK for an implementation to cache the EMSK for its own=20 > > > optimizations, but I would prefer that the caching of the=20 > EMSK not=20 > > > be required for any particular AMSK usage. Since an AMSK is=20 > > > exportable you have more options on where it can be cached. > > >=20 > > > Hope this helps, > > >=20 > > > Joe > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > Joe, > > > > I can see the problem with transporting the EMSK to other > > > entities - > > > > however, what really is the concern with caching the EMSK > > > as long as > > > > it is never exported? Is it just the concern of having to > > maintain > > > > state or is there a security concern here? > > > >=20 > > > > Vidya > > > >=20 > > > > > -----Original Message----- > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > > To: Avi Lior; Jari Arkko > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > Hi Avi, > > > > >=20 > > > > > >=20 > > > > > > Perhaps you missed my poorly stated point :-) > > > > > >=20 > > > > > > What if the user is requesting access to a new application?=20 > > > > > > which could > > > > > > also involve the modification of the user's profile.=20 > > > > > > If EMSK is not there, then what do I do? Restart the > > > session? No. > > > > > >=20 > > > > > > At anyrate I belive that there could be other use cases...=20 > > > > > I gave two > > > > > > reason why: > > > > > >=20 > > > > > > Just-in-time; > > > > > > Dynamic-Application provisioning. > > > > >=20 > > > > > [Joe] Would you agree with the following: > > > > >=20 > > > > > "For any specific application once the AMSK is > > generated for that > > > > > application there is no requirement to cache the EMSK=20 > for that=20 > > > > > application, however there may be a need to cache the > > EMSK if the > > > > > system requires other Masks to be generated. " > > > > >=20 > > > > > This makes the caching more of a system issue than an > > > issue for one > > > > > particular application. =20 > > > > >=20 > > > > >=20 > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, > > please visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > >=20 > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 10:02:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMf9-00050v-Cw for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:02:47 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMf7-0004sx-OW for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:02:47 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C3DCC4300DA for ; Thu, 9 Mar 2006 07:02:44 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 29A0143004F for ; Thu, 9 Mar 2006 07:02:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0ECFC80C123 for ; Thu, 9 Mar 2006 07:02:30 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id 62C6180C116 for ; Thu, 9 Mar 2006 07:02:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 10:05:07 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTA= From: "Avi Lior" To: "Narayanan, Vidya" , "Salowey, Joe" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Hi, I would like to modify what you wrote as follows: > "The EMSK MUST NOT be used to generate any keys other than=20 > AMSKs needed for the same EAP peer that owns the EMSK.=20 The EMSK MUST NOT be used to generate any keys other than AMSKs needed for the same session for which the EMSK was generated. > The=20 > EMSK MUST NOT be transported out of the EAP (AAA?) Layer and=20 > MUST be deleted when the corresponding EAP session expires. Replace EAP (AAA?) with EAP Authentication Server; and "corresponding EAP session expires" with 'corresponding session has ended'. Motivation for above: Not sure if EAP session is defined; and you delete the EMSK when the session is terminated either because it expired or because it was explicitly terminated. =20 > Further, an EMSK MUST NOT be used to generate more than one=20 > AMSK for a given application.=20 I am not sure that the above does not pose a threat. Normally we would think that one Application would require one AMSK. But since we are not defining what an application is -- and we shouldn't IMO enter that rat hole. Then what if there was some application that requires an two AMSKs.? Is there harm? > If more keys are needed for an=20 > application, those may be derived from the AMSK subsequently=20 > by the entities sharing the AMSK.=20 I don't think you need the 'subsequently by entities sharing the AMSK'. I can give one example of one application where there there is only one entity that receives the AMSK. That entity generates the keys needed by the applications and transports those keys to elements that need the key. The AMSK is not transported at all. > It is RECOMMENDED that all=20 > necessary AMSKs corresponding to various applications be=20 > generated immediately upon EMSK generation and that the EMSK=20 > be deleted right away thereafter." =20 I prefer: Once all AMSKs have been derived and the EMSK is not needed it shall be deleted. > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, March 08, 2006 8:38 PM > To: Salowey, Joe; Avi Lior; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 >=20 > Putting all this together, is it fair to say this then?=20 >=20 > "The EMSK MUST NOT be used to generate any keys other than=20 > AMSKs needed for the same EAP peer that owns the EMSK. The=20 > EMSK MUST NOT be transported out of the EAP (AAA?) Layer and=20 > MUST be deleted when the corresponding EAP session expires.=20 > Further, an EMSK MUST NOT be used to generate more than one=20 > AMSK for a given application. If more keys are needed for an=20 > application, those may be derived from the AMSK subsequently=20 > by the entities sharing the AMSK. It is RECOMMENDED that all=20 > necessary AMSKs corresponding to various applications be=20 > generated immediately upon EMSK generation and that the EMSK=20 > be deleted right away thereafter."=20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > Sent: Wednesday, March 08, 2006 5:29 PM > > To: Avi Lior; Narayanan, Vidya; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > I would add that the AMSK for a particular application should be=20 > > derived such that once the AMSK is derived for that=20 > application there=20 > > is no need to continue to use the EMSK for derivation of additional=20 > > keys for that application. > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, March 08, 2006 10:24 AM > > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > So there might be reason for caching the EMSKs. So > > language like the > > > following: > > >=20 > > > EMSK is used strictly for generating AMSKs. > > >=20 > > > EMSK is not transported out of the EAP Authentication=20 > Server Layer. > > >=20 > > > EMSK MUST be deleted when the session for which it was created is=20 > > > deleted. > > >=20 > > > EMSK SHOULD be deleted sooner, when it is no longer required. =20 > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Wednesday, March 08, 2006 1:23 PM > > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > The EMSK is the root of all AMSKs, so a compromise of the EMSK=20 > > > > compromises all AMSKs. Therefore I would like to see the EMSK=20 > > > > protected as much as possible. Once the EMSK is securely > > deleted it > > > > cannot be compromised. I would like to see applications be as=20 > > > > independent from one another as possible and not have one=20 > > > > application require the EMSK be cached once its AMSK is > > generated.=20 > > > > This implies a deeper key hierarchy than if an > > application derives > > > > all of its keys directly from the EMSK. > > > >=20 > > > > Caching itself is new functionality in the system, but > > seems to be > > > > required whether you cache AMSK or EMSK. I don't really have a=20 > > > > problem with caching the EMSK if it is required at the > > system level > > > > because all applications are not known at the right time.=20 > > It think > > > > it may be OK for an implementation to cache the EMSK=20 > for its own=20 > > > > optimizations, but I would prefer that the caching of the > > EMSK not > > > > be required for any particular AMSK usage. Since an AMSK is=20 > > > > exportable you have more options on where it can be cached. > > > >=20 > > > > Hope this helps, > > > >=20 > > > > Joe > > > >=20 > > > > > -----Original Message----- > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > Joe, > > > > > I can see the problem with transporting the EMSK to other > > > > entities - > > > > > however, what really is the concern with caching the EMSK > > > > as long as > > > > > it is never exported? Is it just the concern of having to > > > maintain > > > > > state or is there a security concern here? > > > > >=20 > > > > > Vidya > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > > > To: Avi Lior; Jari Arkko > > > > > > Cc: eap@frascone.com > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > >=20 > > > > > > Hi Avi, > > > > > >=20 > > > > > > >=20 > > > > > > > Perhaps you missed my poorly stated point :-) > > > > > > >=20 > > > > > > > What if the user is requesting access to a new=20 > application?=20 > > > > > > > which could > > > > > > > also involve the modification of the user's profile.=20 > > > > > > > If EMSK is not there, then what do I do? Restart the > > > > session? No. > > > > > > >=20 > > > > > > > At anyrate I belive that there could be other use=20 > cases...=20 > > > > > > I gave two > > > > > > > reason why: > > > > > > >=20 > > > > > > > Just-in-time; > > > > > > > Dynamic-Application provisioning. > > > > > >=20 > > > > > > [Joe] Would you agree with the following: > > > > > >=20 > > > > > > "For any specific application once the AMSK is > > > generated for that > > > > > > application there is no requirement to cache the EMSK > > for that > > > > > > application, however there may be a need to cache the > > > EMSK if the > > > > > > system requires other Masks to be generated. " > > > > > >=20 > > > > > > This makes the caching more of a system issue than an > > > > issue for one > > > > > > particular application. =20 > > > > > >=20 > > > > > >=20 > > > _________________________________________________________________ > > > > > > To unsubscribe or modify your subscription options, > > > please visit: > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > >=20 > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 10:25:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHN1O-0004qw-1U for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:25:46 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHN1M-0005WP-JV for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:25:46 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3FA3B430116 for ; Thu, 9 Mar 2006 07:25:44 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5723C43005A for ; Thu, 9 Mar 2006 07:25:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 36293398051 for ; Thu, 9 Mar 2006 07:25:20 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D741398014 for ; Thu, 9 Mar 2006 07:25:16 -0800 (PST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k29FPEMs001773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 07:25:15 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k29FPD0s015200; Thu, 9 Mar 2006 07:25:13 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 07:25:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 07:25:19 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D517D@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZDcZmYmD7CVtdAQBy8RR6rztWHvwAGwNMw From: "Narayanan, Vidya" To: "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 15:25:12.0768 (UTC) FILETIME=[A8C6AC00:01C6438D] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 >=20 > >Putting all this together, is it fair to say this then?=20 > > > >"The EMSK MUST NOT be used to generate any keys other than=20 > AMSKs needed=20 > >for the same EAP peer that owns the EMSK. The EMSK MUST NOT be=20 > >transported out of the EAP (AAA?) Layer and MUST be deleted when the=20 > >corresponding EAP session expires. Further, an EMSK MUST NOT=20 > be used to=20 > >generate more than one AMSK for a given application. If more=20 > keys are=20 > >needed for an application, those may be derived from the AMSK=20 > >subsequently by the entities sharing the AMSK. It is=20 > RECOMMENDED that=20 > >all necessary AMSKs corresponding to various applications be=20 > generated=20 > >immediately upon EMSK generation and that the EMSK be deleted right=20 > >away thereafter." > > =20 > > > I think I can live with this text. As I said in a previous=20 > e-mail, I have been convinced that we need to support some=20 > form of dynamic generation of AMSKs. >=20 > We also seem to be coming to a consensus on keeping the EMSK=20 > at the server side. >=20 > But I still have a few nagging thoughts: >=20 > 1. In order to avoid a situation that suddenly all AAA=20 > servers need to start > keeping state, do we need to require an authorization profile > flag, configuration knob, or attribute to signal the need for > keeping state? >=20 I wonder if this could be handled by policy alone. A flag or signal would be better and more explicit - did you think this would be signaled by the peer? The authenticator will not have sufficient knowledge about the applications that the peer is interested in and hence this should probably come from the peer - now, we are talking about introducing this into EAP messaging - right?=20 > 2. The text does not tell us how to determine when all necessary > AMSKs have been generated. >=20 Maybe the text should also say "The server may have policies to indicate the number of AMSKs a peer is authorized for - once those are derived, the EMSK is deleted" - ?=20 -Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 10:43:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNIB-0001gQ-Eu for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:43:07 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNI9-0005wJ-Lh for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 10:43:07 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 02B804300CB for ; Thu, 9 Mar 2006 07:43:05 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4D12443004F for ; Thu, 9 Mar 2006 07:42:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 37651398049 for ; Thu, 9 Mar 2006 07:42:46 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09FAE398014 for ; Thu, 9 Mar 2006 07:42:43 -0800 (PST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k29FgdMs002886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 07:42:39 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k29FgcjS015328; Thu, 9 Mar 2006 07:42:38 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 07:42:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 07:42:36 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5186@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0A== From: "Narayanan, Vidya" To: "Avi Lior" , "Salowey, Joe" , "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 15:42:38.0008 (UTC) FILETIME=[17C9A380:01C64390] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Hi Avi, =20 > Hi, > I would like to modify what you wrote as follows: >=20 > > "The EMSK MUST NOT be used to generate any keys other than AMSKs=20 > > needed for the same EAP peer that owns the EMSK. >=20 > The EMSK MUST NOT be used to generate any keys other than=20 > AMSKs needed for the same session for which the EMSK was generated. >=20 Sounds good.=20 > > The > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer=20 > and MUST be=20 > > deleted when the corresponding EAP session expires. >=20 > Replace EAP (AAA?) with EAP Authentication Server; and=20 > "corresponding EAP session expires" with 'corresponding=20 > session has ended'. >=20 I guess when you say EAP Authentication Server, it is a bit vague about whether that is the EAP layer or AAA layer. I'm not sure if there is value in clarifying this or if it makes more sense to leave it to implementation. =20 > Motivation for above: Not sure if EAP session is defined; and=20 > you delete the EMSK when the session is terminated either=20 > because it expired or because it was explicitly terminated. > =20 Could we say "corresponding session has either expired or been terminated"?=20 > > Further, an EMSK MUST NOT be used to generate more than one=20 > AMSK for a=20 > > given application. >=20 > I am not sure that the above does not pose a threat. =20 > Normally we would think that one Application would require=20 > one AMSK. But since we are not defining what an application=20 > is -- and we shouldn't IMO enter that rat hole. Then what if=20 > there was some application that requires an two AMSKs.? Is=20 > there harm? >=20 Hmmm. If an application requires more than one key, would there really be a case where creation of a root AMSK and subsequent keys from that root AMSK not work? I'm wondering why you need to create multiple AMSKs for the same application directly from the EMSK. I'd personally like to have no more than one key coming out of the EMSK for the same key label (unique per application) in AMSK derivation.=20 > > If more keys are needed for an > > application, those may be derived from the AMSK subsequently by the=20 > > entities sharing the AMSK. >=20 > I don't think you need the 'subsequently by entities sharing=20 > the AMSK'. > I can give one example of one application where there there=20 > is only one entity that receives the AMSK. That entity=20 > generates the keys needed by the applications and transports=20 > those keys to elements that need the key. The AMSK is not=20 > transported at all. >=20 Fair enough. I was trying to get at the fact that subsequent keys should not be derived for entities other than the ones the AMSK was meant for - maybe that restriction itself isn't really needed.=20 > > It is RECOMMENDED that all > > necessary AMSKs corresponding to various applications be generated=20 > > immediately upon EMSK generation and that the EMSK be deleted right=20 > > away thereafter." >=20 > I prefer: >=20 > Once all AMSKs have been derived and the EMSK is not needed=20 > it shall be deleted. >=20 To Joe's earlier points (about trying to keep the EMSK as secure as possible and delete it as quickly as possible), I would like to see this recommendation. Maybe appending the former text with "When this is not feasible, the EMSK MUST be deleted once all the AMSKs have been derived" makes sense?=20 -Vidya >=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, March 08, 2006 8:38 PM > > To: Salowey, Joe; Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > >=20 > > Putting all this together, is it fair to say this then?=20 > >=20 > > "The EMSK MUST NOT be used to generate any keys other than AMSKs=20 > > needed for the same EAP peer that owns the EMSK. The EMSK=20 > MUST NOT be=20 > > transported out of the EAP (AAA?) Layer and MUST be deleted=20 > when the=20 > > corresponding EAP session expires. > > Further, an EMSK MUST NOT be used to generate more than one=20 > AMSK for a=20 > > given application. If more keys are needed for an=20 > application, those=20 > > may be derived from the AMSK subsequently by the entities=20 > sharing the=20 > > AMSK. It is RECOMMENDED that all necessary AMSKs corresponding to=20 > > various applications be generated immediately upon EMSK=20 > generation and=20 > > that the EMSK be deleted right away thereafter." > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, March 08, 2006 5:29 PM > > > To: Avi Lior; Narayanan, Vidya; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > I would add that the AMSK for a particular application should be=20 > > > derived such that once the AMSK is derived for that > > application there > > > is no need to continue to use the EMSK for derivation of=20 > additional=20 > > > keys for that application. > > >=20 > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Wednesday, March 08, 2006 10:24 AM > > > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > So there might be reason for caching the EMSKs. So > > > language like the > > > > following: > > > >=20 > > > > EMSK is used strictly for generating AMSKs. > > > >=20 > > > > EMSK is not transported out of the EAP Authentication > > Server Layer. > > > >=20 > > > > EMSK MUST be deleted when the session for which it was=20 > created is=20 > > > > deleted. > > > >=20 > > > > EMSK SHOULD be deleted sooner, when it is no longer required. =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > Sent: Wednesday, March 08, 2006 1:23 PM > > > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > The EMSK is the root of all AMSKs, so a compromise of=20 > the EMSK=20 > > > > > compromises all AMSKs. Therefore I would like to see=20 > the EMSK=20 > > > > > protected as much as possible. Once the EMSK is securely > > > deleted it > > > > > cannot be compromised. I would like to see applications be as=20 > > > > > independent from one another as possible and not have one=20 > > > > > application require the EMSK be cached once its AMSK is > > > generated.=20 > > > > > This implies a deeper key hierarchy than if an > > > application derives > > > > > all of its keys directly from the EMSK. > > > > >=20 > > > > > Caching itself is new functionality in the system, but > > > seems to be > > > > > required whether you cache AMSK or EMSK. I don't=20 > really have a=20 > > > > > problem with caching the EMSK if it is required at the > > > system level > > > > > because all applications are not known at the right time.=20 > > > It think > > > > > it may be OK for an implementation to cache the EMSK > > for its own > > > > > optimizations, but I would prefer that the caching of the > > > EMSK not > > > > > be required for any particular AMSK usage. Since an AMSK is=20 > > > > > exportable you have more options on where it can be cached. > > > > >=20 > > > > > Hope this helps, > > > > >=20 > > > > > Joe > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > > > > Cc: eap@frascone.com > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > >=20 > > > > > > Joe, > > > > > > I can see the problem with transporting the EMSK to other > > > > > entities - > > > > > > however, what really is the concern with caching the EMSK > > > > > as long as > > > > > > it is never exported? Is it just the concern of having to > > > > maintain > > > > > > state or is there a security concern here? > > > > > >=20 > > > > > > Vidya > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > > > > To: Avi Lior; Jari Arkko > > > > > > > Cc: eap@frascone.com > > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > > >=20 > > > > > > > Hi Avi, > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Perhaps you missed my poorly stated point :-) > > > > > > > >=20 > > > > > > > > What if the user is requesting access to a new > > application?=20 > > > > > > > > which could > > > > > > > > also involve the modification of the user's profile.=20 > > > > > > > > If EMSK is not there, then what do I do? Restart the > > > > > session? No. > > > > > > > >=20 > > > > > > > > At anyrate I belive that there could be other use > > cases...=20 > > > > > > > I gave two > > > > > > > > reason why: > > > > > > > >=20 > > > > > > > > Just-in-time; > > > > > > > > Dynamic-Application provisioning. > > > > > > >=20 > > > > > > > [Joe] Would you agree with the following: > > > > > > >=20 > > > > > > > "For any specific application once the AMSK is > > > > generated for that > > > > > > > application there is no requirement to cache the EMSK > > > for that > > > > > > > application, however there may be a need to cache the > > > > EMSK if the > > > > > > > system requires other Masks to be generated. " > > > > > > >=20 > > > > > > > This makes the caching more of a system issue than an > > > > > issue for one > > > > > > > particular application. =20 > > > > > > >=20 > > > > > > >=20 > > > >=20 > _________________________________________________________________ > > > > > > > To unsubscribe or modify your subscription options, > > > > please visit: > > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > >=20 > > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 11:43:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOEF-0006Hd-19 for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 11:43:07 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOED-000800-7k for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 11:43:07 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6523943004F for ; Thu, 9 Mar 2006 08:43:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 154CE43004F for ; Thu, 9 Mar 2006 08:42:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 00C88398040 for ; Thu, 9 Mar 2006 08:42:42 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 532CF398022 for ; Thu, 9 Mar 2006 08:42:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 11:45:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AACMTXQ From: "Avi Lior" To: "Narayanan, Vidya" , "Salowey, Joe" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Hi=20 Please see inline...=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, March 09, 2006 10:43 AM > To: Avi Lior; Salowey, Joe; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Avi, > =20 > > Hi, > > I would like to modify what you wrote as follows: > >=20 > > > "The EMSK MUST NOT be used to generate any keys other than AMSKs=20 > > > needed for the same EAP peer that owns the EMSK. > >=20 > > The EMSK MUST NOT be used to generate any keys other than=20 > AMSKs needed=20 > > for the same session for which the EMSK was generated. > >=20 >=20 > Sounds good.=20 >=20 > > > The > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer > > and MUST be > > > deleted when the corresponding EAP session expires. > >=20 > > Replace EAP (AAA?) with EAP Authentication Server; and=20 > "corresponding=20 > > EAP session expires" with 'corresponding session has ended'. > >=20 >=20 > I guess when you say EAP Authentication Server, it is a bit=20 > vague about whether that is the EAP layer or AAA layer. I'm=20 > not sure if there is value in clarifying this or if it makes=20 > more sense to leave it to implementation. =20 Well it is not happening in the AAA layer. My understanding is that the EAP Method executes within the EAP Auth Server. EAP Auth Server may or may not be colocated with the AAA server. > > Motivation for above: Not sure if EAP session is defined; and you=20 > > delete the EMSK when the session is terminated either because it=20 > > expired or because it was explicitly terminated. > > =20 >=20 > Could we say "corresponding session has either expired or=20 > been terminated"?=20 Sounds good. >=20 > > > Further, an EMSK MUST NOT be used to generate more than one > > AMSK for a > > > given application. > >=20 > > I am not sure that the above does not pose a threat. =20 > > Normally we would think that one Application would require=20 > one AMSK. =20 > > But since we are not defining what an application is -- and we=20 > > shouldn't IMO enter that rat hole. Then what if there was some=20 > > application that requires an two AMSKs.? Is there harm? > >=20 >=20 > Hmmm. If an application requires more than one key, would=20 > there really be a case where creation of a root AMSK and=20 > subsequent keys from that root AMSK not work? I'm wondering=20 > why you need to create multiple AMSKs for the same=20 > application directly from the EMSK. I'd personally like to=20 > have no more than one key coming out of the EMSK for the same=20 > key label (unique per application) in AMSK derivation.=20 Lets get to right down to the label(s). If I have an application called foo, can I generate two AMSKs as follows: AMSK-FOO-A =3D KGF(EMSK,"FOO-A" | ......) AMSK-FOO-B =3D KGF(EMSK,"FOO-B" | ......) I don't know why an application FOO would like to do this. Maybe FOO application is really two applications. =20 But the point is, from a security perspective why does it matter? > > > If more keys are needed for an > > > application, those may be derived from the AMSK=20 > subsequently by the=20 > > > entities sharing the AMSK. > >=20 > > I don't think you need the 'subsequently by entities sharing the=20 > > AMSK'. > > I can give one example of one application where there=20 > there is only=20 > > one entity that receives the AMSK. That entity generates the keys=20 > > needed by the applications and transports those keys to=20 > elements that=20 > > need the key. The AMSK is not transported at all. > >=20 >=20 > Fair enough. I was trying to get at the fact that subsequent=20 > keys should not be derived for entities other than the ones=20 > the AMSK was meant for - maybe that restriction itself isn't=20 > really needed.=20 >=20 > > > It is RECOMMENDED that all > > > necessary AMSKs corresponding to various applications be=20 > generated=20 > > > immediately upon EMSK generation and that the EMSK be=20 > deleted right=20 > > > away thereafter." > >=20 > > I prefer: > >=20 > > Once all AMSKs have been derived and the EMSK is not needed=20 > it shall=20 > > be deleted. > >=20 >=20 > To Joe's earlier points (about trying to keep the EMSK as=20 > secure as possible and delete it as quickly as possible), I=20 > would like to see this recommendation. Maybe appending the=20 > former text with "When this is not feasible, the EMSK MUST be=20 > deleted once all the AMSKs have been derived" > makes sense?=20 I think my statement addresses Joe's concern. But I find the whole concept of immediacy silly especially when EAP does not concern itself with key lifetimes etc.... Why are we all of a sudden concerned about timelyness? >=20 > -Vidya >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, March 08, 2006 8:38 PM > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > >=20 > > > Putting all this together, is it fair to say this then?=20 > > >=20 > > > "The EMSK MUST NOT be used to generate any keys other than AMSKs=20 > > > needed for the same EAP peer that owns the EMSK. The EMSK > > MUST NOT be > > > transported out of the EAP (AAA?) Layer and MUST be deleted > > when the > > > corresponding EAP session expires. > > > Further, an EMSK MUST NOT be used to generate more than one > > AMSK for a > > > given application. If more keys are needed for an > > application, those > > > may be derived from the AMSK subsequently by the entities > > sharing the > > > AMSK. It is RECOMMENDED that all necessary AMSKs corresponding to=20 > > > various applications be generated immediately upon EMSK > > generation and > > > that the EMSK be deleted right away thereafter." > > >=20 > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Wednesday, March 08, 2006 5:29 PM > > > > To: Avi Lior; Narayanan, Vidya; Jari Arkko > > > > Cc: eap@frascone.com > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > >=20 > > > > I would add that the AMSK for a particular application=20 > should be=20 > > > > derived such that once the AMSK is derived for that > > > application there > > > > is no need to continue to use the EMSK for derivation of > > additional > > > > keys for that application. > > > >=20 > > > > > -----Original Message----- > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > Sent: Wednesday, March 08, 2006 10:24 AM > > > > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > > > > Cc: eap@frascone.com > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > >=20 > > > > > So there might be reason for caching the EMSKs. So > > > > language like the > > > > > following: > > > > >=20 > > > > > EMSK is used strictly for generating AMSKs. > > > > >=20 > > > > > EMSK is not transported out of the EAP Authentication > > > Server Layer. > > > > >=20 > > > > > EMSK MUST be deleted when the session for which it was > > created is > > > > > deleted. > > > > >=20 > > > > > EMSK SHOULD be deleted sooner, when it is no longer=20 > required. =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > > Sent: Wednesday, March 08, 2006 1:23 PM > > > > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > > > > Cc: eap@frascone.com > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > >=20 > > > > > > The EMSK is the root of all AMSKs, so a compromise of > > the EMSK > > > > > > compromises all AMSKs. Therefore I would like to see > > the EMSK > > > > > > protected as much as possible. Once the EMSK is securely > > > > deleted it > > > > > > cannot be compromised. I would like to see=20 > applications be as=20 > > > > > > independent from one another as possible and not have one=20 > > > > > > application require the EMSK be cached once its AMSK is > > > > generated.=20 > > > > > > This implies a deeper key hierarchy than if an > > > > application derives > > > > > > all of its keys directly from the EMSK. > > > > > >=20 > > > > > > Caching itself is new functionality in the system, but > > > > seems to be > > > > > > required whether you cache AMSK or EMSK. I don't > > really have a > > > > > > problem with caching the EMSK if it is required at the > > > > system level > > > > > > because all applications are not known at the right time.=20 > > > > It think > > > > > > it may be OK for an implementation to cache the EMSK > > > for its own > > > > > > optimizations, but I would prefer that the caching of the > > > > EMSK not > > > > > > be required for any particular AMSK usage. Since=20 > an AMSK is=20 > > > > > > exportable you have more options on where it can be cached. > > > > > >=20 > > > > > > Hope this helps, > > > > > >=20 > > > > > > Joe > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > > > Sent: Tuesday, March 07, 2006 12:40 PM > > > > > > > To: Salowey, Joe; Avi Lior; Jari Arkko > > > > > > > Cc: eap@frascone.com > > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > > > > > >=20 > > > > > > > Joe, > > > > > > > I can see the problem with transporting the EMSK to other > > > > > > entities - > > > > > > > however, what really is the concern with caching the EMSK > > > > > > as long as > > > > > > > it is never exported? Is it just the concern of having to > > > > > maintain > > > > > > > state or is there a security concern here? > > > > > > >=20 > > > > > > > Vidya > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > > > > > Sent: Monday, March 06, 2006 2:04 PM > > > > > > > > To: Avi Lior; Jari Arkko > > > > > > > > Cc: eap@frascone.com > > > > > > > > Subject: RE: [eap] Strawman -10/EMSK deletion=20 > requirement? > > > > > > > >=20 > > > > > > > > Hi Avi, > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Perhaps you missed my poorly stated point :-) > > > > > > > > >=20 > > > > > > > > > What if the user is requesting access to a new > > > application?=20 > > > > > > > > > which could > > > > > > > > > also involve the modification of the user's profile.=20 > > > > > > > > > If EMSK is not there, then what do I do? Restart the > > > > > > session? No. > > > > > > > > >=20 > > > > > > > > > At anyrate I belive that there could be other use > > > cases...=20 > > > > > > > > I gave two > > > > > > > > > reason why: > > > > > > > > >=20 > > > > > > > > > Just-in-time; > > > > > > > > > Dynamic-Application provisioning. > > > > > > > >=20 > > > > > > > > [Joe] Would you agree with the following: > > > > > > > >=20 > > > > > > > > "For any specific application once the AMSK is > > > > > generated for that > > > > > > > > application there is no requirement to cache the EMSK > > > > for that > > > > > > > > application, however there may be a need to cache the > > > > > EMSK if the > > > > > > > > system requires other Masks to be generated. " > > > > > > > >=20 > > > > > > > > This makes the caching more of a system issue than an > > > > > > issue for one > > > > > > > > particular application. =20 > > > > > > > >=20 > > > > > > > >=20 > > > > >=20 > > _________________________________________________________________ > > > > > > > > To unsubscribe or modify your subscription options, > > > > > please visit: > > > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > > >=20 > > > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 12:09:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOe1-0001Mu-VH for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 12:09:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOe0-0000Jv-By for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 12:09:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA7C243010E for ; Thu, 9 Mar 2006 09:09:43 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 56EEC43004F for ; Thu, 9 Mar 2006 09:09:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 48C7180C112 for ; Thu, 9 Mar 2006 09:09:28 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 6CE5D80C0F9 for ; Thu, 9 Mar 2006 09:09:25 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 09:09:25 -0800 X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="312980288:sNHT31392840" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29H9Pw1003905; Thu, 9 Mar 2006 09:09:25 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:09:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 09:09:23 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D50D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZDa5ynH4QoOHJqSNi/FMJqVt4ZuQAL/+jQ From: "Glen Zorn (gwz)" To: "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 17:09:25.0245 (UTC) FILETIME=[378AF2D0:01C6439C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Jari Arkko supposedly scribbled: > Glen Zorn (gwz) wrote: >=20 >> Joseph Salowey (jsalowey) <> supposedly scribbled: >>=20 >>=20 >>=20 >>> The EMSK is the root of all AMSKs, so a compromise of the EMSK >>> compromises all AMSKs. Therefore I would like to see the EMSK >>> protected as much as possible. Once the EMSK is securely deleted >>> it cannot be compromised.=20 >>>=20 >>>=20 >>=20 >> OK, but is that not equally true of Jari's proposed AMSK_root_0 >> approach?=20 >>=20 >>=20 > The problem is that since EMSK is the root, its compromise will lead > to the compromise of all derived keys. This also holds locally for > the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised then > any keys derived from that root are compromised (but not keys in > other apps). =20 I guess I'm just confused, then (not a first!). I thought that the = major problem was that it is basically impossible to no which (if any) = _applications_ a person would choose to use during a session. If that = is accurate, I can't really see how the AMSK_root_0 approach solves the = problem. If that's not the problem, what is? >=20 > --Jari Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 13:01:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPSF-0005cT-Me for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 13:01:39 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPS9-0001zA-2h for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 13:01:39 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 722174300D1 for ; Thu, 9 Mar 2006 10:01:32 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4B37843004F for ; Thu, 9 Mar 2006 10:01:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30BE539802B for ; Thu, 9 Mar 2006 10:01:20 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 46145398043 for ; Thu, 9 Mar 2006 10:01:17 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 503CB89864; Thu, 9 Mar 2006 20:01:14 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0739D89842; Thu, 9 Mar 2006 20:01:14 +0200 (EET) Message-ID: <44106D68.4050707@piuha.net> Date: Thu, 09 Mar 2006 20:01:12 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D50D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D50D@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Glen Zorn (gwz) wrote: > >>> >>> >>The problem is that since EMSK is the root, its compromise will lead >>to the compromise of all derived keys. This also holds locally for >>the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised then >>any keys derived from that root are compromised (but not keys in >>other apps). >> >> > >I guess I'm just confused, then (not a first!). I thought that the major problem was that it is basically impossible to no which (if any) _applications_ a person would choose to use during a session. If that is accurate, I can't really see how the AMSK_root_0 approach solves the problem. If that's not the problem, what is? > > Oh. Maybe I was confused. AMSK_root_0 does not solve that problem. It solves the problem that if your application requires multiple keys (as in fast handoff to AP2, AP3, etc) then you still only need one AMSK from the EMSK for the application. That AMSK_root_0 can then be used to generate all the keys that the application in question needs. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 13:18:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPiv-0004z0-TD for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 13:18:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPiu-0002bt-Ex for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 13:18:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D0DF94300E0 for ; Thu, 9 Mar 2006 10:18:51 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C70EF43004F for ; Thu, 9 Mar 2006 10:18:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BBE3380C11D for ; Thu, 9 Mar 2006 10:18:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 66DEC80C11C for ; Thu, 9 Mar 2006 10:18:33 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 10:18:33 -0800 X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="313006109:sNHT31177216" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29IIWw1000436; Thu, 9 Mar 2006 10:18:33 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 10:18:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 10:18:31 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D57D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZDo3tZXKc+0RUHQNGa9Z4nZ0PEagAAYugQ From: "Glen Zorn (gwz)" To: "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 18:18:32.0941 (UTC) FILETIME=[DFC321D0:01C643A5] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Jari Arkko supposedly scribbled: > Glen Zorn (gwz) wrote: >=20 >>=20 >>>>=20 >>>>=20 >>> The problem is that since EMSK is the root, its compromise will lead >>> to the compromise of all derived keys. This also holds locally for >>> the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised >>> then any keys derived from that root are compromised (but not keys >>> in=20 >>> other apps). >>>=20 >>>=20 >>=20 >> I guess I'm just confused, then (not a first!). I thought that the >> major problem was that it is basically impossible to no which (if >> any) _applications_ a person would choose to use during a session.=20 >> If that is accurate, I can't really see how the AMSK_root_0 approach >> solves the problem. If that's not the problem, what is? =20 >>=20 >>=20 > Oh. Maybe I was confused. AMSK_root_0 does not solve that problem. It > solves the problem that if your application requires multiple keys > (as in fast handoff to AP2, AP3, etc) then you still only need one > AMSK from the EMSK for the application. That AMSK_root_0 can then be > used to generate all the keys that the application in question needs. OK, I guess I just assumed that the "M" in "AMSK" implied that usage. >=20 > --Jari Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 14:38:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQy8-0001F5-MO for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 14:38:40 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQy7-00058M-8q for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 14:38:40 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5D5524300DA for ; Thu, 9 Mar 2006 11:38:38 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C1939430063 for ; Thu, 9 Mar 2006 11:38:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AE67180C11A for ; Thu, 9 Mar 2006 11:38:19 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id 1A30E80C11C for ; Thu, 9 Mar 2006 11:38:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 14:40:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZDo3tZXKc+0RUHQNGa9Z4nZ0PEagAAYugQAAMPkqA= From: "Avi Lior" To: "Glen Zorn (gwz)" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Glen and Jari, That is what I thought the 'M' was about as well.=20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: Thursday, March 09, 2006 1:19 PM > To: Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Jari Arkko supposedly scribbled: >=20 > > Glen Zorn (gwz) wrote: > >=20 > >>=20 > >>>>=20 > >>>>=20 > >>> The problem is that since EMSK is the root, its=20 > compromise will lead=20 > >>> to the compromise of all derived keys. This also holds=20 > locally for=20 > >>> the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised=20 > >>> then any keys derived from that root are compromised (but=20 > not keys=20 > >>> in other apps). > >>>=20 > >>>=20 > >>=20 > >> I guess I'm just confused, then (not a first!). I thought=20 > that the=20 > >> major problem was that it is basically impossible to no which (if > >> any) _applications_ a person would choose to use during a session.=20 > >> If that is accurate, I can't really see how the=20 > AMSK_root_0 approach > >> solves the problem. If that's not the problem, what is? =20 > >>=20 > >>=20 > > Oh. Maybe I was confused. AMSK_root_0 does not solve that=20 > problem. It=20 > > solves the problem that if your application requires=20 > multiple keys (as=20 > > in fast handoff to AP2, AP3, etc) then you still only need one AMSK=20 > > from the EMSK for the application. That AMSK_root_0 can=20 > then be used=20 > > to generate all the keys that the application in question needs. >=20 > OK, I guess I just assumed that the "M" in "AMSK" implied that usage. >=20 > >=20 > > --Jari >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 20:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW9N-0004PP-QD for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 20:10:37 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHV8l-00085D-E8 for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 19:05:55 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHUwy-0002Z0-SM for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 18:53:47 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8ABE54300CB for ; Thu, 9 Mar 2006 15:53:38 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8E28A430073 for ; Thu, 9 Mar 2006 15:53:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7A6FA398033 for ; Thu, 9 Mar 2006 15:53:18 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id C8ADF398020 for ; Thu, 9 Mar 2006 15:53:14 -0800 (PST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k29Nr7IM022459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 15:53:07 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k29Nr5Gf009231; Thu, 9 Mar 2006 15:53:06 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 15:53:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 15:53:04 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D53A7@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AACMTXQAA4lnHA= From: "Narayanan, Vidya" To: "Avi Lior" , "Salowey, Joe" , "Jari Arkko" X-OriginalArrivalTime: 09 Mar 2006 23:53:05.0745 (UTC) FILETIME=[9C15F410:01C643D4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 =20 > > > Hi, > > > I would like to modify what you wrote as follows: > > >=20 > > > > "The EMSK MUST NOT be used to generate any keys other=20 > than AMSKs=20 > > > > needed for the same EAP peer that owns the EMSK. > > >=20 > > > The EMSK MUST NOT be used to generate any keys other than > > AMSKs needed > > > for the same session for which the EMSK was generated. > > >=20 > >=20 > > Sounds good.=20 > >=20 > > > > The > > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer > > > and MUST be > > > > deleted when the corresponding EAP session expires. > > >=20 > > > Replace EAP (AAA?) with EAP Authentication Server; and > > "corresponding > > > EAP session expires" with 'corresponding session has ended'. > > >=20 > >=20 > > I guess when you say EAP Authentication Server, it is a bit vague=20 > > about whether that is the EAP layer or AAA layer. I'm not sure if=20 > > there is value in clarifying this or if it makes more sense=20 > to leave=20 > > it to implementation. >=20 > Well it is not happening in the AAA layer. My understanding=20 > is that the EAP Method executes within the EAP Auth Server. =20 > EAP Auth Server may or may not be colocated with the AAA server. >=20 I wonder if this is a problem - if we want the EAP AS to generate the EMSK/AMSK and cache it for an entity (such as a MIP HA) to fetch the AMSK later upon receiving a BU or something, the HA will only contact the AAA server. Or, do you envision the AMSK in such cases to be sent to the AAA server for caching?=20 > > Hmmm. If an application requires more than one key, would=20 > there really=20 > > be a case where creation of a root AMSK and subsequent keys=20 > from that=20 > > root AMSK not work? I'm wondering why you need to create multiple=20 > > AMSKs for the same application directly from the EMSK. I'd=20 > personally=20 > > like to have no more than one key coming out of the EMSK=20 > for the same=20 > > key label (unique per application) in AMSK derivation. >=20 > Lets get to right down to the label(s). If I have an=20 > application called foo, can I generate two AMSKs as follows: >=20 > AMSK-FOO-A =3D KGF(EMSK,"FOO-A" | ......) > AMSK-FOO-B =3D KGF(EMSK,"FOO-B" | ......) >=20 As far as the EAP server is concerned, I'd argue that FOO-A and FOO-B are different applications. So, we could just say that no more than one EMSK for a given key label is allowed.=20 > I don't know why an application FOO would like to do this. Maybe FOO > application is really two applications. =20 >=20 > >=20 > > > > It is RECOMMENDED that all > > > > necessary AMSKs corresponding to various applications be > > generated > > > > immediately upon EMSK generation and that the EMSK be > > deleted right > > > > away thereafter." > > >=20 > > > I prefer: > > >=20 > > > Once all AMSKs have been derived and the EMSK is not needed > > it shall > > > be deleted. > > >=20 > >=20 > > To Joe's earlier points (about trying to keep the EMSK as secure as=20 > > possible and delete it as quickly as possible), I would like to see=20 > > this recommendation. Maybe appending the former text with=20 > "When this=20 > > is not feasible, the EMSK MUST be deleted once all the=20 > AMSKs have been=20 > > derived" > > makes sense?=20 >=20 > I think my statement addresses Joe's concern. But I find the=20 > whole concept of immediacy silly especially when EAP does not=20 > concern itself with key lifetimes etc.... >=20 > Why are we all of a sudden concerned about timelyness? >=20 I'd personally be okay with leaving this out - even if it is recommended to be deleted, implementations are likely to cache it for practical reasons anyway.=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 21:23:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXHt-0001Gf-Vr for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 21:23:29 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXHr-0004EZ-F9 for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 21:23:29 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6B2264300E2 for ; Thu, 9 Mar 2006 18:23:25 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 12F33430073 for ; Thu, 9 Mar 2006 18:23:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 03E95398007 for ; Thu, 9 Mar 2006 18:23:12 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 82544398040 for ; Thu, 9 Mar 2006 18:23:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 21:25:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AACMTXQAA4lnHAABlb+oA== From: "Avi Lior" To: "Narayanan, Vidya" , "Salowey, Joe" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Hi,=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, March 09, 2006 6:53 PM > To: Avi Lior; Salowey, Joe; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 > > Well it is not happening in the AAA layer. My=20 > understanding is that=20 > > the EAP Method executes within the EAP Auth Server. > > EAP Auth Server may or may not be colocated with the AAA server. > >=20 >=20 > I wonder if this is a problem - if we want the EAP AS to=20 > generate the EMSK/AMSK and cache it for an entity (such as a=20 > MIP HA) to fetch the AMSK later upon receiving a BU or=20 > something, the HA will only contact the AAA server. Or, do=20 > you envision the AMSK in such cases to be sent to the AAA=20 > server for caching?=20 We don't want the EAP AS to cache the AMSK. The AAA isnt responsible for caching either. If we consider RADIUS, RADIUS is stateless, it has no caching capabilites at all. Diameter does (however). So AMSK is cached outside the EAP AS and outside AAA - I belive the AMSK is cached in another functional entity called a KeyHolder/KeyGenerator. That solves the problem for RADIUS. > >=20 > > > Hmmm. If an application requires more than one key, would > > there really > > > be a case where creation of a root AMSK and subsequent keys > > from that > > > root AMSK not work? I'm wondering why you need to create multiple=20 > > > AMSKs for the same application directly from the EMSK. I'd > > personally > > > like to have no more than one key coming out of the EMSK > > for the same > > > key label (unique per application) in AMSK derivation. > >=20 > > Lets get to right down to the label(s). If I have an application=20 > > called foo, can I generate two AMSKs as follows: > >=20 > > AMSK-FOO-A =3D KGF(EMSK,"FOO-A" | ......) AMSK-FOO-B =3D=20 > KGF(EMSK,"FOO-B"=20 > > | ......) > >=20 >=20 > As far as the EAP server is concerned, I'd argue that FOO-A=20 > and FOO-B are different applications. So, we could just say=20 > that no more than one EMSK for a given key label is allowed.=20 Fine with me. Its not about defining an application but rather the important piece is defining the concept of a label.=20 Because you have this possiblity as well and sounds like a lable needs to be precisely defined. FOO-A =3D KGF(EMSK,"FOO" | "A" | ....); FOO-B =3D KGF(EMSK,"FOO" | "B" | ....);=20 So the first part "FOO" is the lable and it is the key name and therefore must be unique within each session. Therefore, although FOO-A <> FOO-B, the above is illegal. >=20 > > I don't know why an application FOO would like to do this. =20 > Maybe FOO > > application is really two applications. =20 > >=20 >=20 > >=20 >=20 > > >=20 > > > > > It is RECOMMENDED that all > > > > > necessary AMSKs corresponding to various applications be > > > generated > > > > > immediately upon EMSK generation and that the EMSK be > > > deleted right > > > > > away thereafter." > > > >=20 > > > > I prefer: > > > >=20 > > > > Once all AMSKs have been derived and the EMSK is not needed > > > it shall > > > > be deleted. > > > >=20 > > >=20 > > > To Joe's earlier points (about trying to keep the EMSK as=20 > secure as=20 > > > possible and delete it as quickly as possible), I would=20 > like to see=20 > > > this recommendation. Maybe appending the former text with > > "When this > > > is not feasible, the EMSK MUST be deleted once all the > > AMSKs have been > > > derived" > > > makes sense?=20 > >=20 > > I think my statement addresses Joe's concern. But I find the whole=20 > > concept of immediacy silly especially when EAP does not=20 > concern itself=20 > > with key lifetimes etc.... > >=20 > > Why are we all of a sudden concerned about timelyness? > >=20 >=20 > I'd personally be okay with leaving this out - even if it is=20 > recommended to be deleted, implementations are likely to=20 > cache it for practical reasons anyway.=20 I agree.....but I am easy going about this either way. =20 > Vidya >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 23:44:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZTx-0007Mk-5I for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 23:44:05 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZTv-0007ra-OM for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 23:44:05 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D9C59430114 for ; Thu, 9 Mar 2006 20:44:02 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7BE2D430075 for ; Thu, 9 Mar 2006 20:43:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E66A398058 for ; Thu, 9 Mar 2006 20:43:48 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8E13B398055 for ; Thu, 9 Mar 2006 20:43:46 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 09 Mar 2006 20:43:46 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2A4hjw3007970; Thu, 9 Mar 2006 20:43:45 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 20:50:39 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B33881@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAHexGQA== From: "Salowey, Joe" To: "Avi Lior" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 =20 > > The=20 > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer and=20 > > MUST be deleted when the corresponding EAP session expires. >=20 > Replace EAP (AAA?) with EAP Authentication Server; and "corresponding > EAP session expires" with 'corresponding session has ended'. >=20 > Motivation for above: Not sure if EAP session is defined; and=20 > you delete > the EMSK when the session is terminated either because it expired or > because it was explicitly terminated. >=20 [Joe] I think we will probably need mopre definition around this.=20 =20 > > Further, an EMSK MUST NOT be used to generate more than one=20 > > AMSK for a given application.=20 >=20 > I am not sure that the above does not pose a threat. =20 > Normally we would > think that one Application would require one AMSK. But since=20 > we are not > defining what an application is -- and we shouldn't IMO enter that rat > hole. Then what if there was some application that requires an two > AMSKs.? Is there harm? >=20 [Joe] If they are generated at the same time I don't think there is a problem. If there is a delay in generation where the application requires the EMSK to be cached it is less than optimal. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 09 23:52:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZbh-0006A1-Qq for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 23:52:05 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZbf-00088O-Dv for eap-archive@lists.ietf.org; Thu, 09 Mar 2006 23:52:05 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1DF494300E0 for ; Thu, 9 Mar 2006 20:52:03 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1F8ED430075 for ; Thu, 9 Mar 2006 20:51:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0617180C11A for ; Thu, 9 Mar 2006 20:51:50 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 2649080C120 for ; Thu, 9 Mar 2006 20:51:47 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 20:51:46 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313209171:sNHT33736750" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2A4pkw1010983; Thu, 9 Mar 2006 20:51:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 20:58:41 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B33882@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AAb5vzQ From: "Salowey, Joe" To: "Narayanan, Vidya" , "Avi Lior" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 =20 >=20 > I guess when you say EAP Authentication Server, it is a bit=20 > vague about > whether that is the EAP layer or AAA layer. I'm not sure if there is > value in clarifying this or if it makes more sense to leave it to > implementation. =20 > [Joe] I'm pretty convinced it is in EAP. In the pictures the AAA layer appears to carry communication between AAA client and AAA server, I do not think this is where the EMSK belongs.=20 =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:00:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZjt-0001Of-N2 for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:00:33 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZjs-0008Q5-BD for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:00:33 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F3AC04300D8 for ; Thu, 9 Mar 2006 21:00:31 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E73BA430075 for ; Thu, 9 Mar 2006 21:00:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D697B80C11D for ; Thu, 9 Mar 2006 21:00:13 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id D622B80C11A for ; Thu, 9 Mar 2006 21:00:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 00:02:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AAb5vzQAACP+CA= From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Joe and All, I totally agree with Joe. AAA is a protocol that transports and cant realy cache anything in the case of RADIUS which is stateless. So any caching has to be outside AAA or with AAA (but Diameter only).=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, March 09, 2006 11:59 PM > To: Narayanan, Vidya; Avi Lior; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > >=20 > > I guess when you say EAP Authentication Server, it is a bit vague=20 > > about whether that is the EAP layer or AAA layer. I'm not sure if=20 > > there is value in clarifying this or if it makes more sense=20 > to leave=20 > > it to implementation. > > > [Joe] I'm pretty convinced it is in EAP. In the pictures the=20 > AAA layer appears to carry communication between AAA client=20 > and AAA server, I do not think this is where the EMSK belongs.=20 >=20 > =20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:02:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZld-0002H4-Cv for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:02:21 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZla-0008Vk-V5 for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:02:21 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9D9C0430101 for ; Thu, 9 Mar 2006 21:02:18 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B0ADA430075 for ; Thu, 9 Mar 2006 21:02:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A2164398033 for ; Thu, 9 Mar 2006 21:02:07 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6B536398043 for ; Thu, 9 Mar 2006 21:02:04 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2006 21:02:04 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2A5237T012570; Thu, 9 Mar 2006 21:02:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 21:08:58 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B33885@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AACMTXQABn667A= From: "Salowey, Joe" To: "Avi Lior" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 =20 > >=20 > > Hmmm. If an application requires more than one key, would=20 > > there really be a case where creation of a root AMSK and=20 > > subsequent keys from that root AMSK not work? I'm wondering=20 > > why you need to create multiple AMSKs for the same=20 > > application directly from the EMSK. I'd personally like to=20 > > have no more than one key coming out of the EMSK for the same=20 > > key label (unique per application) in AMSK derivation.=20 >=20 > Lets get to right down to the label(s). If I have an=20 > application called > foo, can I generate two AMSKs as follows: >=20 > AMSK-FOO-A =3D KGF(EMSK,"FOO-A" | ......) > AMSK-FOO-B =3D KGF(EMSK,"FOO-B" | ......) >=20 > I don't know why an application FOO would like to do this. Maybe FOO > application is really two applications. =20 >=20 > But the point is, from a security perspective why does it matter? >=20 [Joe] As long as there is not caching required between AMSK-FOO-A and AMSK-FOO-B, I'm not sure it really matters. The argument against it is that it may encourage caching and there really isn't a reason why you couldn't derive the two keys lower in the hierachy (except perhaps for efficiency). For what its worth in the original EMSK usage draft (http://bgp.potaroo.net/ietf/all-ids/draft-salowey-eap-key-deriv-02.txt) we had the following prototype for the KDF: AMSK =3D KDF(EMSK, key label, optional application data, length _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:08:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZrr-00023u-Ms for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:08:47 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZrq-0000G0-S3 for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:08:47 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8715C430108 for ; Thu, 9 Mar 2006 21:08:46 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 812A2430075 for ; Thu, 9 Mar 2006 21:08:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6DF86398033 for ; Thu, 9 Mar 2006 21:08:34 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5B48739804F for ; Thu, 9 Mar 2006 21:08:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 00:11:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAHexGQAAA1TEQ From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Joe, See inline....=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, March 09, 2006 11:51 PM > To: Avi Lior; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > > The > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer=20 > and MUST be=20 > > > deleted when the corresponding EAP session expires. > >=20 > > Replace EAP (AAA?) with EAP Authentication Server; and=20 > "corresponding=20 > > EAP session expires" with 'corresponding session has ended'. > >=20 > > Motivation for above: Not sure if EAP session is defined; and you=20 > > delete the EMSK when the session is terminated either because it=20 > > expired or because it was explicitly terminated. > >=20 >=20 > [Joe] I think we will probably need mopre definition around this.=20 [Avi] Okay. > > > Further, an EMSK MUST NOT be used to generate more than one=20 > > > AMSK for a given application.=20 > >=20 > > I am not sure that the above does not pose a threat. =20 > > Normally we would > > think that one Application would require one AMSK. But since=20 > > we are not > > defining what an application is -- and we shouldn't IMO=20 > enter that rat > > hole. Then what if there was some application that requires an two > > AMSKs.? Is there harm? > >=20 >=20 > [Joe] If they are generated at the same time I don't think there is a > problem. If there is a delay in generation where the application > requires the EMSK to be cached it is less than optimal. =20 >=20 [Avi] In another email thread we explored this further and the way I understand it is that an Application can have one AMSK key because: FOO-AMSK =3D KGF(EMSK,"FOO" | ... | ...) "FOO" is a the Key Lable and it must be unique. FOO-A-AMSK =3D KGF(EMSK,"FOO-A" | ... | ...) FOO-B-AMSK =3D KGF(EMSK,"FOO-B" | ... | ...) Are really two differnet AMSKs and this is legal because these are viewed as two separate applications. And=20 FOO-A-AMSK =3D KGF(EMSK,"FOO" | "A" | ...) FOO-B-AMSK =3D KGF(EMSK,"FOO" | "B" | ...) Generates two distinct keys but SHOULD not be legal.=20 I am not sure if this is defined correctly. Finally, I am not sure how this has to do with EMSK caching or not. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:09:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZsu-0002Rq-Pc for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:09:52 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZss-0000LC-Bx for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:09:52 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0B196430075 for ; Thu, 9 Mar 2006 21:09:49 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AA883430075 for ; Thu, 9 Mar 2006 21:09:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A7EC398043 for ; Thu, 9 Mar 2006 21:09:37 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id BF527398033 for ; Thu, 9 Mar 2006 21:09:34 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 21:09:34 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313212479:sNHT32724312" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2A59Yw1017209; Thu, 9 Mar 2006 21:09:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 21:16:29 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B33887@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AAb5vzQAACP+CAAACRfEA== From: "Salowey, Joe" To: "Avi Lior" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Thursday, March 09, 2006 9:03 PM > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > Joe and All, >=20 > I totally agree with Joe. >=20 > AAA is a protocol that transports and cant realy cache anything in the > case of RADIUS which is stateless. >=20 > So any caching has to be outside AAA or with AAA (but Diameter only).=20 [Joe] I think a AAA server is typically composed of several components. One of these can be a key holder. I don't see why you couldn't define new functionality in RADIUS to interact with the key holder (other than the fact that it seems to be difficult to define anything new in RADIUS).=20 >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Thursday, March 09, 2006 11:59 PM > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > =20 > >=20 > > >=20 > > > I guess when you say EAP Authentication Server, it is a bit vague=20 > > > about whether that is the EAP layer or AAA layer. I'm not sure if=20 > > > there is value in clarifying this or if it makes more sense=20 > > to leave=20 > > > it to implementation. > > > > > [Joe] I'm pretty convinced it is in EAP. In the pictures the=20 > > AAA layer appears to carry communication between AAA client=20 > > and AAA server, I do not think this is where the EMSK belongs.=20 > >=20 > > =20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:14:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZx5-0005s9-BG for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:14:11 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZx4-0000QA-UL for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:14:11 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5583D430082 for ; Thu, 9 Mar 2006 21:14:10 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ABEB8430075 for ; Thu, 9 Mar 2006 21:13:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B65080C122 for ; Thu, 9 Mar 2006 21:13:54 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id EB8AF80C107 for ; Thu, 9 Mar 2006 21:13:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 00:16:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAAjRx0AAb5vzQAACP+CAAACRfEAAAUPtg From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Joe, =20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Friday, March 10, 2006 12:16 AM > To: Avi Lior; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, March 09, 2006 9:03 PM > > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko > > Cc: eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > Joe and All, > >=20 > > I totally agree with Joe. > >=20 > > AAA is a protocol that transports and cant realy cache=20 > anything in the=20 > > case of RADIUS which is stateless. > >=20 > > So any caching has to be outside AAA or with AAA (but=20 > Diameter only).=20 >=20 > [Joe] I think a AAA server is typically composed of several=20 > components. > One of these can be a key holder. I don't see why you=20 > couldn't define new functionality in RADIUS to interact with=20 > the key holder (other than the fact that it seems to be=20 > difficult to define anything new in RADIUS).=20 [Avi] Aboslutely correct on all fronts ;-). A AAA server can have EAP-AS (authetncation server) and a key holder/key generator. So I guess ia m being very formal in the sense that AAA is a protocol and not a server. And BTW I don't think we need to have an RFC to define a Key Holder function in RADIUS servers. =20 > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Thursday, March 09, 2006 11:59 PM > > > To: Narayanan, Vidya; Avi Lior; Jari Arkko > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > > >=20 > > > =20 > > >=20 > > > >=20 > > > > I guess when you say EAP Authentication Server, it is a=20 > bit vague=20 > > > > about whether that is the EAP layer or AAA layer. I'm=20 > not sure if=20 > > > > there is value in clarifying this or if it makes more sense > > > to leave > > > > it to implementation. > > > > > > > [Joe] I'm pretty convinced it is in EAP. In the pictures the AAA=20 > > > layer appears to carry communication between AAA client and AAA=20 > > > server, I do not think this is where the EMSK belongs. > > >=20 > > > =20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:36:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHaID-0007GR-BU for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:36:01 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHaIC-0000ww-Tp for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:36:01 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8B0DE4300D7 for ; Thu, 9 Mar 2006 21:36:00 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 97D5F430075 for ; Thu, 9 Mar 2006 21:35:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7520B39805E for ; Thu, 9 Mar 2006 21:35:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 701DC398040 for ; Thu, 9 Mar 2006 21:35:41 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 21:35:41 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313215096:sNHT34836732" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2A5ZeGv024080; Thu, 9 Mar 2006 21:35:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Thu, 9 Mar 2006 21:42:35 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906B3388A@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAHexGQAAA1TEQAABBXUA= From: "Salowey, Joe" To: "Avi Lior" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d =20 =20 > > > > The > > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer=20 > > and MUST be=20 > > > > deleted when the corresponding EAP session expires. > > >=20 > > > Replace EAP (AAA?) with EAP Authentication Server; and=20 > > "corresponding=20 > > > EAP session expires" with 'corresponding session has ended'. > > >=20 > > > Motivation for above: Not sure if EAP session is defined; and you=20 > > > delete the EMSK when the session is terminated either because it=20 > > > expired or because it was explicitly terminated. > > >=20 > >=20 > > [Joe] I think we will probably need mopre definition around this.=20 >=20 > [Avi] Okay. >=20 > > > > Further, an EMSK MUST NOT be used to generate more than one=20 > > > > AMSK for a given application.=20 > > >=20 > > > I am not sure that the above does not pose a threat. =20 > > > Normally we would > > > think that one Application would require one AMSK. But since=20 > > > we are not > > > defining what an application is -- and we shouldn't IMO=20 > > enter that rat > > > hole. Then what if there was some application that=20 > requires an two > > > AMSKs.? Is there harm? > > >=20 > >=20 > > [Joe] If they are generated at the same time I don't think=20 > there is a > > problem. If there is a delay in generation where the application > > requires the EMSK to be cached it is less than optimal. =20 > >=20 > [Avi] In another email thread we explored this further and the way I > understand it is that an Application can have one AMSK key because: >=20 > FOO-AMSK =3D KGF(EMSK,"FOO" | ... | ...) >=20 > "FOO" is a the Key Lable and it must be unique. >=20 > FOO-A-AMSK =3D KGF(EMSK,"FOO-A" | ... | ...) > FOO-B-AMSK =3D KGF(EMSK,"FOO-B" | ... | ...) >=20 > Are really two differnet AMSKs and this is legal because these are > viewed as two separate applications. >=20 > And=20 > FOO-A-AMSK =3D KGF(EMSK,"FOO" | "A" | ...) > FOO-B-AMSK =3D KGF(EMSK,"FOO" | "B" | ...) >=20 > Generates two distinct keys but SHOULD not be legal.=20 >=20 > I am not sure if this is defined correctly. >=20 [Joe] I'm not sure the last has to be illegal but it calls into question the "M" in AMSK. It would be better to derive these two keys off an AMSK for FOO. =20 > Finally, I am not sure how this has to do with EMSK caching or not. [Joe] Any one application should not introduce a requirement to cache the EMSK. If you are going to derive keys at different times for an application this should be done off an AMSK not the EMSK. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 00:53:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHaYo-0006Cy-Qh for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:53:10 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHaYm-0001Gy-CE for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 00:53:10 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7B6314300FC for ; Thu, 9 Mar 2006 21:53:07 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4DE2E430075 for ; Thu, 9 Mar 2006 21:52:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 372E2398051 for ; Thu, 9 Mar 2006 21:52:51 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E45F39804F for ; Thu, 9 Mar 2006 21:52:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 00:55:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZBX2WqDnUWe5TJQgC8Hy57STBaPAAA9JfwAAE4VMAALSXusAAC3NjAAC08/fAADpPw8AAAaObgABr2TTAAHexGQAAA1TEQAABBXUAAAXQ+MA== From: "Avi Lior" To: "Salowey, Joe" , "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 See inline.... =20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Friday, March 10, 2006 12:43 AM > To: Avi Lior; Narayanan, Vidya; Jari Arkko > Cc: eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > =20 > =20 > > > > > The > > > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer > > > and MUST be > > > > > deleted when the corresponding EAP session expires. > > > >=20 > > > > Replace EAP (AAA?) with EAP Authentication Server; and > > > "corresponding > > > > EAP session expires" with 'corresponding session has ended'. > > > >=20 > > > > Motivation for above: Not sure if EAP session is=20 > defined; and you=20 > > > > delete the EMSK when the session is terminated either=20 > because it=20 > > > > expired or because it was explicitly terminated. > > > >=20 > > >=20 > > > [Joe] I think we will probably need mopre definition around this.=20 > >=20 > > [Avi] Okay. > >=20 > > > > > Further, an EMSK MUST NOT be used to generate more=20 > than one AMSK=20 > > > > > for a given application. > > > >=20 > > > > I am not sure that the above does not pose a threat. =20 > > > > Normally we would > > > > think that one Application would require one AMSK. But=20 > since we=20 > > > > are not defining what an application is -- and we shouldn't IMO > > > enter that rat > > > > hole. Then what if there was some application that > > requires an two > > > > AMSKs.? Is there harm? > > > >=20 > > >=20 > > > [Joe] If they are generated at the same time I don't think > > there is a > > > problem. If there is a delay in generation where the application=20 > > > requires the EMSK to be cached it is less than optimal. > > >=20 > > [Avi] In another email thread we explored this further and=20 > the way I=20 > > understand it is that an Application can have one AMSK key because: > >=20 > > FOO-AMSK =3D KGF(EMSK,"FOO" | ... | ...) > >=20 > > "FOO" is a the Key Lable and it must be unique. > >=20 > > FOO-A-AMSK =3D KGF(EMSK,"FOO-A" | ... | ...) FOO-B-AMSK =3D=20 > > KGF(EMSK,"FOO-B" | ... | ...) > >=20 > > Are really two differnet AMSKs and this is legal because these are=20 > > viewed as two separate applications. > >=20 > > And > > FOO-A-AMSK =3D KGF(EMSK,"FOO" | "A" | ...) FOO-B-AMSK =3D=20 > KGF(EMSK,"FOO" |=20 > > "B" | ...) > >=20 > > Generates two distinct keys but SHOULD not be legal.=20 > >=20 > > I am not sure if this is defined correctly. > >=20 >=20 > [Joe] I'm not sure the last has to be illegal but it calls=20 > into question the "M" in AMSK. It would be better to derive=20 > these two keys off an AMSK for FOO. =20 FOO-A-AMSK and FOO-B-AMSK are not intended to be subkeys for FOO -- they are two AMSKs for FOO. The original context was whether or not an Application can have two or more AMSKs. =20 > > Finally, I am not sure how this has to do with EMSK caching or not. >=20 > [Joe] Any one application should not introduce a requirement=20 > to cache the EMSK. If you are going to derive keys at=20 > different times for an application this should be done off an=20 > AMSK not the EMSK. =20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 02:56:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcU6-0006es-NJ for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 02:56:26 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHcLA-0004Ty-Mm for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 02:47:18 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CD48343010A for ; Thu, 9 Mar 2006 23:47:11 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AAB1D430075 for ; Thu, 9 Mar 2006 23:46:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8FD85398055 for ; Thu, 9 Mar 2006 23:46:59 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD547398065 for ; Thu, 9 Mar 2006 23:46:56 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8040C89880; Fri, 10 Mar 2006 09:46:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2C6EF89852; Fri, 10 Mar 2006 09:46:53 +0200 (EET) Message-ID: <44112EEB.9070408@piuha.net> Date: Fri, 10 Mar 2006 09:46:51 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" , Avi Lior , "Narayanan, Vidya" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <7210B31550AC934A8637D6619739CE6906B33881@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906B33881@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > > >>>Further, an EMSK MUST NOT be used to generate more than one >>>AMSK for a given application. >>> >>> >>I am not sure that the above does not pose a threat. >>Normally we would >>think that one Application would require one AMSK. But since >>we are not >>defining what an application is -- and we shouldn't IMO enter that rat >>hole. Then what if there was some application that requires an two >>AMSKs.? Is there harm? >> >> This related originally to the EMSK deletion requirement. There was an argument that the EMSK need to stay around so that application X can keep on asking the 127th key that it needs. Now that we seem to be saying that there is no strict EMSK deletion requirement, this may be less urgent. However, I still think it is a good idea that applications get just one AMSK, and if they need multiple keys they generate those themselves. And the definition of an application can be "an IANA registered label for an AMSK needed for a specific purpose". Since the IANA registrations won't have "handoff 1st key", "handoff 2nd key" etc but rather "handoff key", then we satisfy this model. But this is still mostly to keep the hierarchy structurally clean and simple, not for any specific technical reason. (Other than that it still allows early deletion of the EMSK better than if we would base all keys on the EMSK.) --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 03:35:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6E-0005Gh-9L for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 03:35:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHd4j-0006EY-5b for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 03:34:18 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 828DE430124 for ; Fri, 10 Mar 2006 00:34:16 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 339DD430075 for ; Fri, 10 Mar 2006 00:34:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 17701398059 for ; Fri, 10 Mar 2006 00:34:00 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id CD945398040 for ; Fri, 10 Mar 2006 00:33:57 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 65CC689898; Fri, 10 Mar 2006 10:33:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ECF5189880; Fri, 10 Mar 2006 10:33:55 +0200 (EET) Message-ID: <441139F2.5050906@piuha.net> Date: Fri, 10 Mar 2006 10:33:54 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Avi Lior wrote: >>[Joe] I think a AAA server is typically composed of several >>components. >>One of these can be a key holder. I don't see why you >>couldn't define new functionality in RADIUS to interact with >>the key holder (other than the fact that it seems to be >>difficult to define anything new in RADIUS). >> >> > >[Avi] Aboslutely correct on all fronts ;-). A AAA server can have >EAP-AS (authetncation server) and a key holder/key generator. So I >guess ia m being very formal in the sense that AAA is a protocol and not >a server. > >And BTW I don't think we need to have an RFC to define a Key Holder >function in RADIUS servers. > > First of all, I think this part of the discussion is largely just a matter of vague definitions making it hard to make exact statements. E.g. where is the line between AAA as a "transport" and as an "application" that has intelligence to make decisions and grant resources such as keys? Just to repeat what we have already established, I think we have consensus that (a) EMSK is generated by EAP methods and that (b) its not going to be shipped away to the access devices. In addition, it seems obvious that the document we are discussing will not define how AMSKs are used or transported. So the conclusion is that the EMSK is kept somewhere between the EAP method and AAA transport layers. I would note that this means that it is, in an IETF sense, within a box and not transported via protocols. I don't think it makes a lot of sense to debate too long about what the internal structure of the box is. I'd be happy saying that it resides in the EAP server. I would in addition only say the following about the internal module structures: The EMSK is not communicated either to the lower layer or the AAA transport layer. But AMSKs derived from it can be, and that any such derivation would have to be defined in future documents. Finally, I dislike the idea that we would be adding major functionality (such as key server) to IETF protocols and mechanisms without properly documenting how they will be used and what the protocols will exactly carry. The role of the EAP keying framework is to leave some key material in the EAP server to enable such functionality, but if we are going to use it, we will need, among other things, protocol descriptions on how RADIUS can retrieve pieces of this key information and how particular applications employ these keys. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From wlbiday@ashford.com Fri Mar 10 07:31:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgmO-0003FM-4k for eap-archive@ietf.org; Fri, 10 Mar 2006 07:31:36 -0500 Received: from p54a024e2.dip0.t-ipconnect.de ([84.160.36.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHgmL-00055Y-F6 for eap-archive@ietf.org; Fri, 10 Mar 2006 07:31:36 -0500 Message-ID: <000b01c6443e$8c90aa70$e224a054@NB01> From: "wlbiday" To: eap-archive@ietf.org Subject: Fw: eap-archive Date: Fri, 10 Mar 2006 13:31:26 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C64446.EE551270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae ------=_NextPart_000_0007_01C64446.EE551270 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C64446.EE551270" ------=_NextPart_001_0008_01C64446.EE551270 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Morales Carly=20 To: khvpnpeqw@gamerplanet.com=20 Sent: Monday, March 6, 2006 10:25 AM Subject: eap-archive ------=_NextPart_001_0008_01C64446.EE551270 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Morales Carly=20
Sent: Monday, March 6, 2006 10:25 AM
Subject: eap-archive

 
3D""
------=_NextPart_001_0008_01C64446.EE551270-- ------=_NextPart_000_0007_01C64446.EE551270 Content-Type: image/gif; name="ycbdsmebghb.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6443e$8c90aa70$e224a054@NB01> R0lGODdhfgGUAYcAAP///wrwtVstN//juf/fnP/Yr+zEl9ivgP//2OzEr///7P/snP+/dEgz ZkkAAJcAAICAgK+AgMTs/8SXgEiAAAgAAAAznwAzZggAdP//34B0nICAr4Cv2ICAl4CXxK/Y /wCvnP/YdAhInNFedP//v/+cSL///7//0nSFZkhghcD//8D/v3V0AElISMRIAIAAANj//+z/ ///sxJyXAACAAOD//+CcSHUAAMB0AP8AAP/Gn3QzZq+//690dIBInK+cnJeAgHTY/3SvdACX nHTEnP/f/wAA/wh0v0mcnEmc33UAdAhISHW//9+c/0lInL+FZgCF0nTG/9///0gA/5xI/0hI /wB0/8CcSODfnAAzhQgASJec30jE38C/dJzf/0kASMD/39ivAABguZzj/53f/6+v2MTY/wh0 dEic/51IAICAAN/jub/judh0AOzsxP+//wBI/790/0l0v/9InEiXnACvv3S//3QA/4B0v4CX r51ISMB0SK+vdICvv6+XgJfE7L/f/510AHhjzezESP8ASJeXgACAdHSAAJeAAOycSNjYrwCA SHVInJx0/8SXAP9IAJzs/whIdOC/dJfE34CASN//0v//0oCXl9/ESHVIAEkAdP8AdGHAoYCX nOD/v9jsxP//6JxgZt+nhYAAdL+vAK+AAJ5hf0in6Nj/v68AAIAASAoNC3RI/8Tf/9/f/8B0 dHV0v8TEl3VIdHWc351IdHSc/+D/35ev2ICAdP90AL+//0lIdP90v3VISNicSEh0/9j/35dI AP+c30dAIXV0SJ10dElIACoWVgh0nKYOYp5IKb+Fhd//353f3+CcdJ10nMCcnNwvt0iF0q+c 3+zYr0l0dBsyB8S/nOz/352cdHW/v4Cvr8DfnMTs2HW/33V0dOycdEiXAOz/7MTYxEhgZsS/ /wCXSJ2/nK+XxMSvxL/snABghdi/dIB0dK8AdACFn68ASLk/T3Qzn8R0AHQzhZyFZsSvgLCr 4ezY2De0yP+cdP90dEin0uz/2HUASBLJuywAAAAAfgGUAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkw0FoVzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0ALJgtKtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih3LMYyasx8EZnB09mwf goPanp1U0Cxatcrkvh0YVy5dhXbl3hUYWLAaXDD6Gm5Lt7BcShIMKp5bt21ag47lIgYQ+DKA EG33Ft4LYHKnGAkXIILM2bJatqFbD16rV7bhy5MXT1LNmqzFzoTlela9uLfty4WHIyoeGWFm xsEXH04sHfpz1wKJGzYOHHP1zd0//se2PR0A7banEdIWjT15dDXIhb83TDc3/dbpfVMEPll5 9d78yZfdctIZV5l04H1HXXVqNMZgetox955nBF1XXniguTUfaySUIld+kg0WIHbHlSYgeYIh Zp9gdGX4l34SdTbZi7ald54a7KE1Y4XooXYjaQfCB4B2rIWHkGI0ljgkgQmeZSNsOE54kJE8 DiaehrIBQFmGPR7UYXnH7TiQjH5VKSSRzQmEZEFfbgZjRIHxUeZAX6phnHZNqiEndHR6aGea eMIwpWvnFUnikXyOiV2gdd7JpKBUSjmolVzmCMByb8VFiZZqgEhQhqTFOaeiZ+1JmZlpFZqm iadWSeGb/w1dR6N2IKqKYqJLOonaa2cZSOqZBBoqXZJrmrnYW7Tuah5swgrp3bCSXhlllmzh Aky1nHpK6ouyBslikGmhCReuamIJq0PXOarrQLamCyiBtTK76q+GpWchseRaCCG8yrZ7KL3f KiltjpNoCoCHffSl7bJWumvsY6vqqyyrDRqU4cLnOlcdacmyK++t4+Xaab8fP7tYfNCO2+p8 bbkpcry9RhYpyKdiOJ5dk2TIacHrsumnZxYCGfTDJ5a7skAZupwxYHpFeFmj756VJ45OCwT1 QIFOmqKg0SJ6dGd1VgzA1QNKDem/XaM6UKXRTRI2ZApPbPXP9PZR9Xx2E+gsyP5KGy32p2Yv zVBgOY783pM3J95zYIibC67GVnr9t5SKAdjlj2lnjnTLgoaN8iQ3qtgzQXUCrbjhthWe38wq T745mIIn1F2Ef0W4XXOz61273rdDvre3ghlY7K+pQrmX7cHjXp2DBUYWtmFu4kxxpqN73PCi uktKu+atJ3klxrET/2tvyJMYXmDk817041r3zle+2HHpbPnXQ2th+hK2LW191W8r/nvNMl3M BCY57/UFSOEzmX9GlxsEhidCIGrgQlh3v1UNL1qMU5YEiWad/6TpRtWT3pdYE7eDgOp/IhvZ A/V2Gta972iyeVUCZwiWNnFNJzakoQ7FkiEZ2qSHO/4M4lfWwxOzgE+ISKQKb+ZVkyUm8YlQ jKIUp0jFKlrxiljMoha3yMUuevGLYAyjGMdIxjJy0RRmTKMa18jGNrrxjXCMoxznSMc62vGO eMyjHvcIkxLk4I+A/CMhipCBR+RgE3T64xwA4MdALhIABAhkDniBkEgGkpKNlGQOBmk1ST6S XYaUpDAKuckiCCQXiixIJlMJSUlSsiCk1CQAQvlKRipylYHkJCo9CUpN5uANsawlAHa5yFhK EpiGRGQvcyCMgTTyk2pJZiJzUMxQPpKU1ZQkJ6PpyzcMU5OPJIEgTdnJQ06TmgQhpTJ7uU5x otOYgUSmNsk5tj+uEyOWhP+mOqd5TUNuc5fe/GZACQLQU/5yIPksiCUpuc9yfjKSo/SnKRlg z4OQ8p9/DCgqB8rNbU6Tk+68Z0IJWsp6mtM8EoVlKNsJyGx6lJv3BABFT3pResKUnygFpDex mVNOLrSjNjUoSCv6zYMKZKa1nGlG2anSk5rUpUGtaSsnWc6YWmSkN3UoUKcqTAZwlKsE8SpC WZlVsH7zpQSIaCnd+dJe+vSPXf2qVAuC1KI2c6zoJOk2G9nMuS6TmQLJJFSbGtNYerOuhMWp MbM5WJn+sa8pLQgq9/pYx1I1sEs1KCBr2VCmatWvW7VsM0O6EazmlKV5lSpiE7Jag5j2p0B1 JzT+3VqEXd7VIKqF60JA21EAkFUgpj0rOevK28XmNJXFlSZdUznZoJ5WsYac5SB5Otd98la4 R9UtaZ9bzlk6tbNllW1PoxrZfYpXI6bt7Hlzq1PWxvMgpuUrSX/ZWrfq47dN5aRSjWrRyCo0 l0ENbnOzC9jk5kC6RYjkPpDr37K61beXTexnDTkHivKCuv4F6HUHLFqhmhK2ln1DIwMKXu4+ dbz5paeGKVza38LTkVt15zENIuP34hWa8nXmY3PcVEBaNZ0prXF7ewzjgewSsP/Nq5FLit0X v5PCfhSGHyGcTV6WGLgA7q9TxYvNQhLCu421JTOd/EgOc3imzRzxkhH+CdsSq5fB4EQxZsfM YvS6WLknlrOTv3pcG08Vx5XVMTN5DGRXJqS6ofRzaA1y5Nn+WbIlteRdDTyHSM5yE1xusIkh rVsto5axtgSznMWs1rZiV9I4ReU6f9pQN+M500ymraDV6ugAUCS9r2blhjerkCPXMr6B1uwb 6svNHCw4s7jVdFEjvOiwzpggAtbkbSkdTFi39cpYjrWET8xTcRKCxX5dsbY1G8jbChXCtcQl ICHr1PDC+doZzihP7axkE69X2ZYV5kFW+9pOjze4QG3kj0ftbGYTvKqWjGm0B2lJo1JazG+w NnnbTTqiehq6eRWsnqW5a4YPOdvHJnFkE+r/6i2/e+LbtK4h9X3VO5s8tSktAUfRrMqZBxvX ToUth4FbakLSUsuclHnBzX1wUhdVmAuf6DgPztNIIlLi22aTxQ/CYVbXueGNpXnHlR5r42b7 kzW9ctV1a+Bt0vwjOP/0Vv34yvMShO1avXGSGZprJUOUvaaWKtzzXOi2JrycHk36nKer6Xlj HN4Un+bAs/3KARuemChus7I53EiPZvK2hObrlXVe0rJ/uNPbzUjacYrLObyY6MVed5IdLeTZ Ornnmo1p6U+vZVmqfs6rxu/Od/nlRMfT8BPuJpkVv5CGLz2nD4VzllP/3t0f35Ipb3A+hz9V QEZf+L6Pdej5yP3u/nv/++APv/jHT/7ym//86E+/+tfP/va7//3wj7/850//+tv//vjPv/73 z//++///ABiAAjiABFiABniACJiACriADNiADviAEBiBEjiB9jcADSAGUjAWFoiBXmGBFmAC APAEFyAGa9AAHxiCI1gJO3ABLHgBp2AJK9iCLBgFDCEKFwAFI6EDM4iCUWCBMsgPoTCCGWiD 69AAMriDAmGBWTAGAACDSygQIsiCOAiDR3gBNCgQVNiCp4CCLHiCNtiFJuCBICiCHFgQWSiD AHCBGTgQNoiDCdGGJCGCV3gRcogQG7iGAyGCbkgVYqiDH9iHF/CBTjgGoBCEWwgAcGgT/zp4 gzwohgNBhVEwiAKRiAShhEw4iIVohQCgg2VIiY+4A0uYiVtogxyohwBQiFAAiCf4howIAHeo E3WIEbFoEK9IEJ4oFR54AitIg7m4i00IikyYiLeoEDqIg1HYip/Igk94h4W4hMWoA6u4iRfw DvJgAnLoiANRjDZ4iIiIjANhib/ojEJ4ikF4hcMoiXBIilLghyDYhK5ogrqoiQqRiBYoECx4 iIx4jHsojcbYgvuog++wgiRohDjIjKHwhPr4hWCYhy7YjTjIiSWohd3Ygh+4iCNYgvbYkA5p FR6IAq3Yka2Ijq04jAmhjQ05ANJQiWrYjGNgkOJYhNFYjE8QBf/XaILtKBCZOI6T6I1J2ABP OIimCIUjyZPhGIyMqI63CJL7iBD06JNjAIMVeYPb6IopmY1SeZJVKRDsSIYAcJAtuZJeOZUo yYMGAYdkKAXbOJaSGIucKAWWAAAluIRQCYJTWRU+iIR3KY+DCIk7uZTSeI8EIZM6aYsamZZg KY5laJVQoANiUA9WmJdP+I7y2Je0aIQyuIRBuZGaSRB76YvqmJk92YJzyIpu6JJjIJiJqZhn aRDF2I2nwJKmuZpCOZo9KQYqCACYGZmzSZa8+Y4YyJKuyZFGmAKBCII+SJwneIaTSZIIUYx5 yY3ByY+m2ZoFUYyWQA/k8Jg2SRA5GY3/wwiOQImMQXmOMYiESMmTx1mcC9GUv+mVzmmZGqmV N/icgXmULpiJPXiYXymRszgQhWgBbCAQDQAAO3CCx6iJsTiLpimN0ImL8LiCBfmgjCiJBcGc B0GdKJiYdWmY7SmOftmaUZif0eiadbmZ3+iURdmW5CiP5KmbO4mB7IiF72gB8eiXFfqR+omh ssmPDJmYrbmN+LmgQomB/ZmHWQAAFtCVRdiPW1iHCTqZQooVgLiEU/qUwFiWRFmSN7gMTGiB +wiDHWqlggiMGKqYfymiN2mJFPqdKIqJ5SiNnUiUFMqGOsmIqFilc0qnpZmjW9qlDfCPffqO gLqTr1mOczmI/1wqqNFZnVLIhTQoh/gZnW0JCnCpnyhoo0/hiCIIoNu5qbroopTpEILJgqn5 i8rIhBOZBeTgoaw5obuYlxcAhK24qXRJlOB5pVzojS2KqkK5kAr5h50aiGzwpwfBnlLAkqM6 mPx4jKn5o/f5pl+oqpjZghzYnTdpqluog8tohKqqidZqkQMZppdKgSchCiNKrnhUiA2Kruxq f8fgENbQrvI6r/Rar/Z6r/iar/q6r/zar/76rwoRDQA7sARbsAZ7sAibsAq7sAzbsA77sBBr sDhQAUfAEQxQASJQA/pKAA6AASoAABObsSBbASRbsZDUsR8bsho7sSVLYzdAsiSbBP8nC7MV gAQvS7MVoA03S7IeOxAsS7FWcwNaQAYI5QA0mwQXm7EZkAYVkAQk8LImO7I9G1ZA+7RHO7I8 2wU0KwKesLMVMLU20LQbi7IX67FLWwFMIFMYWwMc67FlqwJnm7ZJq7F0IrRkcLZJ0LYfSxBh a7JPO7QAELZKy7Ryu7Z/S7TAhbIDMbd4a7WAy7Ffu7dqkQaAe7h4G7hrO7dBC7iCq7FPK7L4 2rYr8LKFK7JxK7qkq7amS7ikY7eYewR6WxB9u7lE+7aaG7eHW7RTq7o10Lg3gAEsILM2UA2K W7Qim7uz27maOzau+7YCgQOAG7odywJAO7JRO7GwO73Vi73/Plu9tPu6scu31Zu73Mu9z0ux uZu4u8u4TOu0v9sFXOsP51C8RyW2zMu5QKu8a/u95ou5aSu9MPu//du3kEuyAuy9s1u3Q2u1 TFDAFRC9CWy1AXy+Udu36TuzJDu07Nu0T4sBo/sNIoAF9Ou/tMvAmJuxFwuz7kuz/1u/MgvA LRC51tu92VsBMdyz/du/zMvCJ7u7AhHBdtu5M0zBFxy+vOu7Hhu2DTzCShy0PHzCNbC8hyvE LpyvqAu0t0u4V1yxWYy2rRu96iu5Pzy+dnu5XcwERUy/G4zGvyu5Rqy2L3zBY4zC+3u/d9u+ A9HE0uu2D3zHXjy3enuxQxu3vPvF/4gbxrJLxo9rtExAyHObxrt7uB2sApOsu2LMscfruuJL x6Cbu5ArwGBsr7E7sTgMsyY7yjL8s1GrwIeMwTE7xn6ryWELuKrsxDAbwkarwjvcx8y7u2+8 tJWryeebtXWcvrNMBp9LtxELFhe7yhoRti+8zGGhwxixvNJ8zdiczdq8zfWaAS7AA9wMRQTw ABrgAj3wAlswEG3wAuyMBwKxzuw8CqiQCqrQCgjBAOz8Au6MEPD8Aj6wKySQCi8wCjfkzflM 0ATRz6PADuwMzuvMAwGdz+h8VP4cAwadzgYdz/Ms0ewMAAJ90DCAz/VsHi6gzw2Lz/+sFiUN ziiNGolQ0f8BPdI0lgoE/dC4VdLpHNDpLFP5DM5jQ8/2PM4+PRAv/c/4bNIPHdP2vM7u3NIX rdSQ9AA+/dL7DNVFjQ0l7c7jjNAKO87l/AMPkM4tTdIvAM5FHQNQ7VoPUM82XRBnDVzTQNKq cA0PkNJjDUnl4NYVjc/t4A4wkNRATdY84NQ4fdcEkNcAQNVWE9j4TNCN/dcT3bDePNRMrc4m fdZpbRD9vM8Fsc47DW11jdUjfdQmfRBnjc940AY8ANgyzdSEjc6kzdkCodg/PdKVbdAezdXL XNmzfdkwHdgHAc+jAAwuINNkvQURPdEvnc7L/c4Sbdy9bdT6zAA+MA9lndZU/dr/6dzPLyDT tJ3cDb24+SzbEcvbAFDZmA3cdOXPvtDdwaDb5x3Zy+3NIx3QKQ1cD9DOei3deEAC8BAM1w3c nq3dCJXfpf3dQP3WZA3dETvWBm3Wv83gve3OL13aRF3RiQ3bHN3Q4GDP0T0xp43UDQ3VD/7a PNDhF57SCF7PF53icgOxD87TKh7hHr7eBB3R8B3RzI3Oni3eePDS4BzjBBHiTT3igV3ZSh3Q BA3kgj3hiz3S41zWH67Nm+3cGv3R7HzfFN3O6wzdGT3Q82zcSk7c+czgCs3Q7hzREI3lkf3T 7DzSX27cK+7hLz3SCh7OeJ7ner7nfN7nfv7ngG4RBwAB/xyAEDIABB7w4kYx6IW+EgUAAYkO AI8e6TtkABBw6RtwQx8x6DKEABFw6Zf+BwZh6Y1uEQYg6gShABPQAUw0EJ4OAaj+6KAuQ49e 6paO6TBw6JReErJ+6bQO6hCQFqoO6pluELU+EKrO6gnx6qL+6sQuKIMO6aih6rsOAJaO6te+ Q4wOAKpe6pse7Abh6aw+7KjOEYcO6pEe7cp+EMMO6wDg6ZkO75qe7M2x7d2u64r+EfIu7wSx 7xGQ6QoAAIIy6RND7wKh7q3O7RMQ6u/+75r+6B9w6KIO8QXh6ZFu8fl+Lo9e7O9eBvhO77Ve ABugCIQu8rkOBJde6IeeB37A8P+3juuuHgHKTuohP/KELunoHgPnfvP8PhCHzgEFIOr4sCsG fxAH0AEA4O4EP+wUgu84z/EI4PFAwPIMv/PuvvIt7+44D+rKvvPejvOJzvQEsfQLTyHivipO LxBFbxBHn/TN7vAEYekRDwR/QO0vfvT1vu4JROoF8fGrLgGPfglAYPOCvwGfAASFfu2Hzur8 zunhLvORQfMQUPgkD/TSjgDo4AaIb+2w3vMCMenUUO5q//cHYQCsnu18DwCDLvqPju03TxCL LwHyLgO30PCsHvuzP/gwQO8/z/min/qrH/evH/w+DwR6j/Oiv/Zxf/ru7uwQoOwQL/EUP+rg zvk+lDH/2w77iB4DIC/tYI8ajl/rfq/sjl/xkP/qH0DwOM8B5a/64H7sB+H8eq/8nw/uqD/8 Wi8Qcn/wr1/8YU/6AAFA4AEIH2QA8RBDwYQOEgxA+ANgYUOCHwAUgMBBoMCHGgEQjLix40CI Gz9CSGjyocWNEyWYFIjR4sOQGzE2PIlS3AQPOyFktFnyolCYRY0eRZpU6VKmTZmONHkwoUuM HquS/PnTgxuEChm+rFgUQYSsBYdazRgWa9aURx9mZekS5sKyPzlABanSLACoG6V6xUkQ7l+X YQvXbcsX6Mmaij3m5fiTpci9AuWapFvXo+UJlWMWNNBQ5ueQGBs7RZ1a9WrW/kM3wBCIoAzh r1fPkpwMgHZgz7Ej4AyKloPak7mVGvgD+bLbkhinds5t+vPr2LO7Ho5YcbfDkoeNB33u2bnX vW+/S2/5NSnNudAx84wRWsJoxSxXtsafX39rghoXchjrtbFEW8y2v3S7ZTvFTgNgwJeC+4yD 8RRIh6uUZLglQNj8MoOv5IC7TEO9ItJQRL+6Ism/CTjYriK6DLquNpRicPBADE0qMQIBdYQh R+rMM+pAzoAzMbKICkArsaFmIpClA4B78sH9pqSySr1++vGnDgohULgTs2IxRpwyo8434CJE EyOtYjgIzCJ1AyIrKMvasUwjP4OrvTPfguC17drc/rIgBd/aEqc27YJJTcka5HGoPA/NqrHL BMOyx0YpO7IsJRdKKTOPxkoJ1BisJLVUU09FdSnkUr0tVSFZLco2WGFib8FZb8U1V105YrDU /kodi61Rd01R1/GGUpJYZZdltllnn4U2WmmnpbZaa6/FNlttt+W2W2+/BTdccccl99RXy0U3 XXXTzaxPGM5tijjf6uqttWAjLaovpu4t6zv+6jVqVYEgtfPLRfl1d12Fb3UQThiTZUpevTab 0kG6emVN3yklLgrShGQAYFSMCj6oIZfeXDjlVI/VzYyD8vDjp5DuxamqAjaIhc4NKdvsUI1s 3kARCLYha6s4KWYUp46A/hb6Z2F9DngxSDOV8DVFITA0TqD47BOASwcGQsKI8BkW7IKPrQhl ldcmVdGegWhIw+0wugSI1ziOzKODNKKJbruFvlsn9TZqeGkI6g46o/EQQIcrvonieeBbkp7v cLs/sRsGl/a2Va03naOmV1l9e41TGsnSUkq2V9+4rIa2q7XvGXFj7jGzbJ79KpqWozzYD46t iriwRs+7qIqOZc+72/AmHHWspVQTabDxNekm1VnHHj+fYRcK982YxwsxagrcGqIXcXT+dvKH q4zSNWldLCfJbDPsK/dnZP7KRZs/E9kY1MzN+bI3QNUkQEoPMdpzGhI7iMgKfIuRl210Zz73 /vBPdRJMS/sAFjnGFMc2ybNfb/KnkuRAToB36mB6NkhAFkbNIi/ajqioEr9a5UtqKMIQBh/3 hxNSrnrrm1CFcDg5+NnuAy/CYEJqNERbMYpkHUJOlJBkNktZbUZITFLZWrjFo7Qrawp8Cc1e Iisy7ax407OLDhfUw4ZB6DaK+pjW4sdBQBWiILIiFJdeAikVYclrJJNjzXTmRNgoSpDC4mIi FbkreK1GYIuEZCSvxS+IORJjksRkJjW5SU520pOfBGUoRTlKUpbSlKfMHu9Qicp2UWeE+4HU CpWCsIJhS5UbUYvGVgnJhh3EIq/Uz0GsWMumFG522rol7XbZSZbJ/8AMXEtc1SyVOjjBTGZ4 ouaJ/AQ3CeymG7/ZY+Ys6BrYQM1RMxLjUIiGEq4ABSPrNNoNEfWymAkFUq+TY0Sg2TRGUZOe 11ymugRgFLeZRC1+2wDmwFgyCcgtc7wTJgzG06KS6Kthv+Kc7JTYODFVLnA9kdFHd4LPHTLU oaX7yo0uupeq/ImbaguowtzHG5YgTyg04V5EICrHkrgUpP1DmJPUx77JMPAPE+ShjHaovJZ2 FIT9C8tBM2JUBcV0dVCTqkdq1VQw1q9/Eb3YdiYyDhRZEIGjup8H7FGZrSqufEm941tflFYL AUYCXgVLv4oTobaGCYxWVZkBKZOQrKIQp/5O7c7gqOgYBSnqNBbrTHY8QxyjInUhAPidXKEj r5xKJISS/SVLp3pTiFQVsAq7z/n66puFdnRx4IzKQyObI5wEq5a9jNPDRpXDK6ajHxEAo2Wh I1xBDdGnp6NIQVTbvYzIMKUdPe3CvPggMvFzXs+D01/z+FWehmS7D/oVTNr4EHyC6ZxKRJ0g lzpczZqFj4PSkh7raJbqAiWdpo2uKRvpFN/l17+SpKQWVcOy/xbYwAdGcIIVvGAGN9jBD4aw KTMwgyAojASHoMEiIOGtENCgDklZAAWGIIUIoyvEIJiBEGjABQCEmAYvNoQJBNLhF9OgwgCg 8YtvnBRSvHjEAP6Y8I+rRAoNAwATHgZAj3fMGiWrpslGRnJROvxhpIRYyKh5MkyyXGJcdVjI C6ADiTsc4wuT+RBmRrOMBRJkEs/YxiFmcYeXvJ8Jx1jLNs7PlpuiZ6NMGcQibjOW8VwUPnMZ VSeeAREowGKThDjGXpbChG0MaUnvmM0bOXIQ4Hxpo1x4EeF4cZw9HAIzv7jIPX5xHaZ85Brb WSCeBvWKX43hDG+Y1TA2gYuRHGKBhBrKrQaAh3Utaz+bBNXCpkCvZQ2AC5t6w1MmdbBbreZf 41rXH4a2IYINAAwPAQAUiLKhnTLhObv5w0emco+5gG6BqHsjnMbxmxctZ6R4GhKV7v+wOShg CHUAesIa/vezkcxne1faypGewakHHeJzrzjEGi6zjJ885QXMWsPFFsiRWVzxh0Mi4gcPeL73 bYJCP5nhUOaCyLVNgxj3eAjMSPiGxY0fGlOZ3Ule8c3VLeka+5jEqH75DIKeaphEHOWQRnnG VxzweH+Y4GeWscY1rnQWP7nJFPd3zHF+Y4xvvesubzPIYz71o9NAyCUf9NVHbXYxI1njTJ95 fuyt85xH2d1rFnqgYSJnTFx80LO2M7SjTPYpM93PTw+8hwk/8LT33OzfHjHTJ874Ggeh68Pm gtg1vHhVhxvtNz62j4NNZT+/fQZ/jztr8M321Uf+9JbOu1H+2Nx3SNB7I0bXeLHJbvoiHx71 gI963Rk9daujXvMbnnwd3K3krm/E5ZBH+OaXnXvP/77djV9ysUu/9NenXjUhoLKjTRBx8kPd 6Hi/sknoTXvbA9/exb6w6wGu9e0z2iTlh/gh5G/rZR+8xS3OuiLjPCVbPSrbiA1juOOLv+ir vXAjO5ggO/+rOO1zO+6zPu9TihxjOTXTQK7ruXI7ikvjOQOctRrrvXBrtloDMvpDMp5zNWaj NRWEQWfDO2sDt1Q7vhWEsdFzsU+btHDDOZ/LwRQ8QQN0QWrTwQ0cts4jvQrkgkrDwHA5v1OZ wii0wlSpwlLJwivkwi70wi8EwzD/FMMxJMMyNMMzRMM0VMM1ZMM2dMPoWoU3lMM5pMM6tMM7 xMM81MM95MM+9MM/BMRAFMRBJMRCXJt/MMREVMRFNIoiqAK90w9HhERGZI0imAIjwEQ7AABL xERMtAKBaIJORANO7EQrsEQ0EAhLNAFS7EQjoDZVTMUpULM3EMVYbEVMfMUpQMVNlEVWNAIr iINdBIA4gIM2e4NPJMVidApJrBJm3AhL/ESBiANXhEVelLFklAJfxMVnvMRM5MVWjEYAoAJl /EZvPIpx1LtQxMRR7MZWzMVdrEZaXEdpFEZiNEZTnAIvYCFYpMVVlEWYCEU1YwVX+EdurIJr LEhrLIpq/4TFgBSIOxBGhYQJSzxIa6xGgXgDcrwDVwRFVLwDTRxGJFQKZ5wSkuTFigSAjfRH NYPFj5TGXBRJhezHi3zGKsjHWETIiKzJmwRFjgQAVmgzmozFimxIn4RIAMjINlPJjrREfSSg arwDLxDKqDQJmrREXUDFixRKiYRFKgBJpPRJiazKKcBKi0xIhSyCX4gDkKQCqTzLqqyCRuBI KsBEfWRGujQCfVRHI9jFaeRLgcBLp8TGsQQATXyDX+jFglTFrRRLblSzqNzKJkCDYMRJjAzL jZBMynxIp5zIt+TFsuzKr5zJf0zLtQRMt+TM7GnIYrTKs2xNE6CClXTMhVTMxP9EQqqszM6E zZUUSq8EAMl8g10EypTUSW4EScpMSklETnLkRS9Iyo1YThLzTZO0REB4xDgAANuszKOkzZhc zWz0zLZkxovETZMQz0dszNnUzdhczLOkSt8ETuEksTuIydUhxWj0RTt4Tm5sRTtQxeDUSs/U RtncCJfMzbE0AQBNzP78TVSMA30EymO0RSP4ylREz5R8TKl8RPrcTPN0Tubk0JR0y2u8UJxs y4HUTrTsxgrdyvucUG+8S7tMSN+ES+nUx/3Uze5UUAJ9SE2UzGGEUCmQUAzdR1lsAmWkyX5E 0CWlAkBIyBatTR4VUfVkUieVUqQsxuFsyyaoULBMzfH/bMe8dESCbEW97ER9xEv/DNMPJTHq NNIqYEcCTdK8pFLHPNI2fcu9/EvyTM3fbEVUVNLuFNQmTdEOTUot9QIufcj6ZJuuzMq3LM/G 5EfEhElBVUgaBctKzdHDLNQCBYRfAEU7aMuiwNRNvNAQtVApQNVMFUfOvNNVHc8SNcsRZci3 xFQolTEqeFSRHFVTBc9ZvMxWTdUptdQl5dRcFU2j/NRQ7dVVxR5YbEqhdMifJEgkrEa61NQl Vchp5c4DVU9s3co4qAKQTMvhDM5Y/NIL1cw4WMXr7EsTaAJkzMcmuNFPXFcZo8o71dZLBcl4 RUp45Mn0VNERrdECJVhL7FKS/8xXnxxOgb1WjuTWehzXVPyFht2iagxFJwXHnsxEX8RHYM1W 9YzHWtxX9RzNjfVTzuzWjazLiSxRvGRN9ITZ+TQCOGAF5+xENZtZsDSCX5DVAH1MTNTIMy3Z 3MzYMLUCf4VOduzELv3NcBzGXdzLr8RVywTWecRMOn1IgO1TSvRacbnFsBXbsSXbsjXbs0Xb tFXbtWXbtnXbt4XbuJXbuW3Fr7Xbu8XbvNXbvc1bAnAAEagBBmOAJGAWErgBJrgWBsAAFZAW HEBcmGCAI5gWBqiAyq0AwC0Kv8VcpciANLDcxb2/G6gAwg1Bz61c0AUAyrXcx1Xdyn1cAPDb yt3cpP8gACcIXBzAXBuoXNKt3dvN3d2Fidi93MA1ichVisHdD92tgNd1ChtA3N4FANzFAtuN XhHAAgeQXU8Q3c9l3KPwW8LNAD0gA9Uw3mhx3I0w3vI1CvXFFcqd3cz9W+JNigygBcZ1X+Lt XOANwfpN3eE13MX9XxUI4ADuX8l1it7FAfBNA9K1AcBFYAVm4NmFXhswYPSt4KNA3uQlXdQg ASVg3AeGXdtN4BAOXAoWCBvYYKQggF2QBRUI3/FNDfrt3mc5X4FI3wuGXByelfvdCOGVXL+N hEzQX6UwXC2AYRzQAmIYXaYoYjK43/xlgif2XCZoYtSo3Stg4BRO4CvOYpP/GGGBgN7IzV8M WAHRxQBuaAEHWFwckN0aGNwxVoHy3QMnrgY15gYHMGKjQOHUPQPRxVw2Ht4cBmMnwOJBLmQS Tl0D3mOlqF1JOIIXhmPnBQATjlzVNeAa7t8KMGIG6OPh5WQ/vt02lmMn7uQ/ll1b8FzQZWMt MIbHNdwKwIAuKGU3rlwtAAAznuEdDmTYdQDJ1d0k8Fsj7tw8ZmQ8Hl8bMOJfZopgJgPdveTR dWaBYGNgxl7LTeFJ1uRmzubYfdxFPmFqXt5vNglvht4E3mMCkAPjJQBNYNxFRuHBPed0NuA5 ZgDAbeAa8OZxJlzFdWHxNWEM5l3sfVxuHuTb7eJx/87mHnYCW9CDZvBnwkXnN36GYlAB58Xk Sb5mjObnF97oh/7mUe7oZq7geDbhzn3d9F3cF96Id9ZhWGnd0WVjxKXcI9DcEl5ipWBjwKVc xFXmpchpfK6AZ06CaI7e0b3fV2Ze73UCLPiCY9ZiYF7qpsZoL95gHy5q2XVkRK7hiE4CQL7c rAYAepZc5M3nld7neSaDi4Zc3o3q8a1dpnbrah7pjM5c22UAZBBfrxYBT2AELJgFBvCG+o3d g+bl3QVptN5qeRYIsV7stH5dvQ6Ex8XkG25s4U0C9r0VHr5qy7Xe+MVmukbo5c1fy63clg5t ng5qaYbm1C7qyw7kaV6K3v/d6DRgXQe265SmbRuWYOo94ZP+Yer953ceat8GMvFNX8JFYZPW 50Ru7H9mNn+AYeYmYX6W7cWF3uVmZNsd5mZm3lfIBjIggW+AhdtjhNt9bJ6+bLQe5eBO7+J2 YrR2bkkWZ+W24bFGbPTGbF3e3Jg2iZr+7KRQ3qT+bwB3XRseXiiW4uX1W1W+adoFbgZn7QmG cBy+biAzXZq2Y94GZJ1OgtF+ZM/VghZ479RFbqiW3wAfZQ8nAei+PQ9GZBs44wfnBt4269im XgJoag9P3T8mXEAGX/41cMNWb7S+asDN3xAf8bAmAw9XcdFl5ddd8C5Qb2te8Fx26V32b3Su 6QH/vgHUXekCLwplruLTvr0uF2Az53LcFuY0IObskW/9eHNryW9S0uzCLm3hTWgC7uFqtmaE huheDl4+B96XZl3SHmg+B21RMlwBjxZ+5ttHh/RIT1zTnhW1Vhb+JpY5Zx1Lzy8KZl9Nzw/n TgpM9nTTrvDite/VqPAALwpQt+ClKHXpLjrRZYLvtWFb3t7T7d7WTXRYuW7M5nT/+nRKhxW1 1vRTf3VXRwrMLuv6XgplT3ZKd1wCaAHt1gMRF2dUf+7o1pVfx+FgPy0GQAJctuFZVt1NLu0e TmMMAINUjuNLjmLXDmo4LuonR99xh+UuSPeCXrNULmPSZnd3p3Y1nuEN/0dlWJ7hPf7ky9Ve WG53hF/4vSb3SeZp+xZ3M5ZlUIaJaXcCACADAgAA8c32V+9gF3Z3Sy5yN0brgV/jUz75fe9v 6iUBAED4VW5lBBvcT09pkf9mtV7ndoZoOZBhEijvwa1hkpZc+iZx4/V53o5nyo7nn8duloYJ hd/5EX/6q//0Dp/oio53lO5nbo/eWl9qOdgDh4bhsj53p4ZdOTj6LB5lqY/voA92b5/kpM/t A8v5C477agbnqqZevcbneCfxwYZsyT7p9h5shSZevc5qpufs6ZXfsQdjxV7uw95sEQBrxiZv vwbs+t176Z7jjSd7VBYBhk77a47cRc/864Xpgf62/Dku58eOfOzNaLuvYXAHrNB/dSU/30Um euKdYOYleoom8VdjhCt43T1Wet5ntvLmd4qPdumP/hNW5Pa+/CGnftFP8o3wbvAW76VPdSUn fdlmApWeam3/+Th//iu4fuN94Qke6aQmelSGct42Xuan7RUX+3CnZtQFCAZHAADYQ4ZBhYRJ cCgkCICAkxoAMqRJOBAAjosMFiqkaJHEjQpajDFxuJGAAwwsGhJEmRADmIoVjqDEwC1lTIsQ JTrEmFBEDYE9bSRkIrQgmZo5Zx41WFOFSaAYkwA4mbLLRYMEQVYAupNgBj1kCNqg2vOoDZgy jzCsQLUtUI9aWiSNOP5xrceZbZN8beng5U0MK0KOZELC39ieihczbuz4MeTIkidTrmz5MubM mjdz7uz5s2QbJUGTLm36NOrUqlezbu36NezYqjnJrm37Nu7cunfz7u37N/DgwocTPErcIY7R l42j3miboXLLZTE7/8zwm9nJyY9L5vqTJ2Pm2zFqvNhYKPOtIRNWwABVd3Ib5iOjn9/YZfv3 lKuXTq+4LwBcMYGSWQxoAcB6LwEQ3X7ZcbYTf5KNx91jJCih32PMTUeCLLJAhYODi9Xn2HS9 TTjZiJB9ZWBiKIb4mX9n2YfRgC1EFBZdZBXIoIswDhRhZCdSyJiFGMJVAwEt/PXSezsRMP6L QWGNdWSSS7bXxRkhSTWUWR6pRZUNIkiSkBYHWeRQlWrl55NIZraZpgoMFbYRA1l2JVFbZap3 pZ1xVeQemnYBUJaXKhyVXKHOHcnAEn+5x0A1Kd1UZqJ9ehISoATBZcufRg7oBABJASCWjmed WVyjay4KQBqjMSBmpDY5QGmncN515VvfsSmVnCQN6dgI3nV1hVllEaAJVMxJKdpJEZVoLLJV /eielIo9SxUBcoR1jqCDLsTgsVBNl618BGmlY7iDDkSRUUkwQK1Y5SJl0rQqLIutHIHyJNC4 2tKiAgmM1NDvRte+KlFZB4c5cBIEw3vQfAbPmBxEWMixRzOkev7bk5AHe2swXze2qjBQZfWb Lr1VNVzsyjqWy+6vjhWJ3GjZrmifaK8AzIgkb9Usx83SmttiqWzeOTN+fP2V3VdtdZXPaE4t GTKeoyVHZ1ZkjHeu0E1pzd6WfZXldMntGi3mty3JcZRA6IHJ0U+SZC3ez/5R7ASnItiicYl+ uZWytONlq6hRP/74NtlYdNt12g/JIfjjVvMY81YXOiSvsXalVycsE9HCQkmYU9111tYWq1xY 2QC1XYkB8/SVaJebZRDro0/HLtZDl8h1igbF/p/mZf6+FSPFiKtcwRclfBGIbn+M/NwRK+/u xJ8GxUS1GyvmenHMNzy9cwTs0stYzv6brByAjIu+PlUwU77YzMh999VTDoFUbKZU2lUTVkOb DpZMkJGGtxwBIQrZi75uNRPvlMmAbvkKV+ZEvaExsEX8y1pezIMfQGVQUxfJoKK+40DDqcxb IMxa/TQlQvNwxSuCyl7f2JSdEarwTtXJSPdKSKi1pM95R9pVDSLoq/cRETXZ68wRdRMjCi1R MUksIhSJmLTOTLE3TTzOFS83oyhysYte/CIYwyjGMZKxjFh8ERiBhKItmsRBE1LjZoRkxjn+ Rj5qzCJv7MhGONKHjcVxI/LQ6JgrTkhejckLAAS5GENyRlhromMR7+hH4CyRj5C5YoTeqMjw TFKOjbkf8f7AE5sYQhKLqXqUu3LVlUs9klGOUgGc4DIMNpUpTV0g00FiNSmiLapP4GEAEjB1 y5m0MVG4NOARKqUlPIkwV4VpIxB3NSaRIKg9OQFUrwJZp2VqcTFUUhIGhllAVYrpmL40oJ4Y UyIvxQRM5WwTMksZG48lLJUSO4tUoCUulsnLKdGSHckYJjsdvcteGlOZUMZzjz/2S3bjcZhB yQCyl7WqjddiJEEH0i+KavNhA+USuqI1nuQt0l0eLVpJS5WtbXVrbJOT52rYNs6NQI45Mm3a z7ZWF4kkzXzZqWnp/igUl8wQbl3BwtSISja5Da2mjdMk5CbU04GQLRCSa6PXuv7JsZ/Rb2k0 Rd/UvFbFlJ4tiJZLGlFh+ppDpZKk3rKp92A3vd3tlEZvPZz21JVR/wmVhQJjqHJqR7wrQE93 4GuZ+1S2PvPUTijDu11F+8rXAN3ALAG7wvQAFLCeGbKxWatdYos2vNStLnSWZYQnEKPWmLLn cCG8Uwpp2JcjVXBF7Jmgc2K4qKCqrCYr+dsfQXjbvZzQf4tKghADCUThKkQpa0kuVnlLWfaU RH/MdMtGmIvdud02fdrLiwAJ6EC4IVe1q00NHs8zScY88bzyHJ57mbjeQc7Xb8CNL37zq9/9 8re//v0vgANsG5RsScCbsaRrQPJS3hT0N3JM724ceP+nxRBYlOdhz20PKZNWYthVHUbTkgrs mKblkyUkRhhLQKwrGV1yk5QhSgUWTKKSkFhxeBIBUn/CSvZkijEEmshB91Nf2LyRhOq14oTv 4wARR0ZAh/xXVY52A/eAhMpTBtiVozzklkQERHcplgtr4GWKgBk8clVMFhFcGVJ256xdxtab H2IX0UVGfB5qb2QyAGUTFbaJEG4NQgqMn4GgJBKZSPFjGMJkIt2ggXfyiFEeXRHDNJpodXYC sVA6FYhkOq9TSaBAvDSY9nADnHFqZqLmpstZWbpU25zwD1ks505z2ixB8/R9nCA3KRUqduVq 26neaM5lvppXKxxasa+rt07++eSZ0w3nOclUzR7jJtCvc4BGH8hqiqRzxKyWDEqER0yfNGzc DFEahkNEFHHX8i+jiaGx3K3pvjWtZYMjdLQmii+vBZTNGyvosvxYHZfUTN5yxhPLrNWmQO0t YxLddxIy8AzjieZEbE7YwwAeL5bx+2GG3Oi6Itu1k94VycONsZYrPKj7NoYhQ1b0wMztFqIw D7tSRrmKnICFL4xFtyHbec/dyLQlURVsTMWp2mhq9OjpEI3T8Zon/8hloMuZ6oP+6GMghAyx kM0TjMDCLBjgjX+lNa9TRfZn68Z0pEyoqlfNoVjDumXWWLuGYENqiTcZ7larsygrr3m5AV/3 c1//OijUiuzBIHR4Vwm6pYU981sbVlgp+TS0T8+aIQ/ToqMoHpYRKah3/Q28GnBbotF5RTbI QIJvdC6UdtWUafmNefCtSyxe+7hyINvntJecwUmGTk9UTpRNujw0fo+yn2JsbUjXj/A5Rxg2 TwW76I87gQDUiaQEddwMyoUuPgUQjAs3tAxq3n5uhj435myTxeHax/vjeQc95mUE6lk/45W9 cb/TfYiNHy/PJcwQPcRVcFdzpQSG3EbdCaBU2MySBdGVVdkBIkS3gUS3kcXxUZaVZSCWHR6t VCAkwddmgGBw/JmBiUiSCWBr4cfCQWBPeMR8oIR9qGBDSJiHUZd9sVwJ/37SDciYElFbDv4g EAahEA4hERahkKlG1HEGnbiYiMwdoAmcIJEgCSIhD1oHzvlXimTdkvggZAiJxIEdzVjGEmoV JwmNimzhAR5hejjNBJ1HFM7dFKZGEuYQRlEGhDghHWXhiNmFl1GGkDyJM4yFk1XGGEqGHuYa wmWGHjKSn70hIeIhasyhGWrGIeYXV0DbMhVKAmnFpiDe6ohEAOaF31le6BhOoqQSVvnSnmCi pD3SwSEFOiUFOGFJJv7JqPHYe9hUtMFTxDFbceyio1WfK+WHJuYJ/8GiKqLKK8WSrmRTVrXF KXUBOQVFMkaZSDTDhllTrZjaaqGHx+GLit3Jtf/sBLtwlGK8wgq03l1ER3ZNnAqIBsGgolCR nDdGVEPZV4HpU1V8o+McIowBhca1SD3d4z5GlEMxCD3Zmxz00zEaREBGBcLwRb7xU8iJH1IY ktsYDMkBFAmdzD91o5HRDti8juawxc/QSEK9nTXqSmgFDNiJ3b8slTwiFG/1ztes2M2gVUk2 1dJNorUUEAqFlVFtSdwV4H3JlNuhnVLOSw5JC9I5znhcDe/BXePc22SdXULdHfvJk02K4M3Q mfiQz8aEFiC2SGgBAOqpHusNijYVVVbBHebxyM3Uzq35zu41hh41VexJXhPqpfZwjxmez0c5 ZO015ObF1ZzNVfuMTGH/YuThiM5b2tXyCM3weJc8XVD/nQoKqsqK4dB0ORtBBCI08IR3OIj8 LaZFFCJNXuUAZmb1bZChdNdOIkUG1URgvAeM2RABYlcvaia/ndxRtpYCHUEF7V9kypb2fUdy 7V9tXsU0HudtDRVO8NBWGiGQ8Z114gaeHVl2flEddmdtjJUhQiJ4lqd5nid6pqd6AhjwnQUT EuJ7rqd8ipFlqpkYhohjked87qdwxIh9wiea6Sd/Dqgh4pJJpGbpHEkn5gcyGZAAXcncuNF3 LMqqNdApGUpvCoYwPWc1EqiHvthPucrskWG/RKWImqFDZsfHcVzJlIy75JM97dtjctxGfqiN //rY1KhYG9JOYAXW3S0NUdkkf7Sd2jWdTCld3BwOUE3WjTbpVuHaZjWmeeDe9vxVlAoN5ano lNKekXpPwfTZ9+wVUzopma7kT3VERcwFGXCf/1nEXuyFUBhndnTQbhmpcGYXDzknEEVmmfZp FMWhnwYqGQGqoBaqoR4qoiaqoi4qozaqoz4qpEaqpE4qpVaqpV4qpmaqpm4qp3aqp34qqIaq qI4qqZaqqZ4qqqaqqq4qq7aqq5pnEVSBFLwqrQIAFcDBrAJArOaqZVCBFyxGEUyBCRDErc7q GxgBsqIBQQTrsNoqrgLAsSYrsE4BshrBsAZrtRqBFWBrthoBIFArsv/agUNEqxEoq64Kq0Nw K7JuK7qeqwkEqxU4RBxYa60CR6xOwa/qqqxihq9O67DGQbwCQBPQKwDcgbIyKwAALEEMbLMa rGIgbBPgKsL667Ki67EOK8MShMNOrLv2xMQya7BWQcMSbL32RhOgQRyYa6w2ArLmK7f+6q7q qxRQQbU+a8WaQMTmKhWIK0FcLLPmLLHyLLSSbMeCbLs+bLtO7B386s6Oq7VyLMd2rLsGKwCI 6xv8ArrGgc2WLG74aswGq7gCbdO+gcTua8z2K9Lqgs1G7dIGq9rmKtvm681O7dF6bNKia87G LdTW7ccKa7ACgqzGAQBk7dZybW2cLcyard//7mvBesHX7iva2q0RrG3d3oEdYCvlNqvGCm3H Kqy6GoHQ9u26zq1DWO7eZuvl3u27CquvsoIr1K3h3sbAVuvBMu4dmADZ6uzlmi3kym26CqvD Sq3GOi7wqmzl+i63PmvU/m6z/qzyHu/eaq7UGi3OVgEaLG/s1gba7urX+m27ti26Iq6/gm3Q Ou3qri7PNm3PEm3UYu/0oisVmKv6Du35Mq/dNq/3ri7xSm/2ykbMDm/MKqytWq3E4mvCPmsc cO7cZmzGFuzB4i29NnDw2i8FIy3+XqsBS/ADa+7yqm8TxGv0HjCv9q9rfHBPpGzywi24Nuvs 1oLiTi6vTuy8Diu5/xpvs87w0EqrBUtutQbs+7IwvdZwxWbrt2ZrwN4Bsj4vBxPuCJOwEz8x Z3SrFE8xFVexFV8xFmexFm8xF3fxFEMxGIexGI8xGZexGZ8xGqexGv8XoQ6qgKrGf8LeI0Lq ia0ccNUxjOHnG3tGPNBXaABlhkxSG78YHsbx65EIIMfhIBfhTozZAJFFmDlymQFOf24ZJgny HjdHfB5yIPvkGt1orWkaiISyp/VhVQCjm5hHLCYbx4jQhQ4j9XmFkvBY/yAjsQUTKDKeRFzi qZ0gLNsLsymoCFXomvoiQp0T81RXMx0K9gRzLl8OWRgOMAlTNTKzqGHKNcHSLA7bCQ4hwf/N G7q9m4P0zUPqSNRhnEGK1otGZEKOY7QIacZNEDmKnGMlXHHAKMh9VMK0KMMQJJ08TP25DsgE tMDkc2K1I8W1Sz0eEUELlFV6JIag83bmYMXwXCn/nEX7HOBIjVEOnUJE5pJKC1Jy1U7iHyy2 oVSyGOQAjkAkpRz3I16NzUhK1rwwi88kHZiYjUtPiEuG3dhhqE0OhU73ZOLsj9wxqRB2nvsk 3uct3j3/Eu+1zl9J5o4KJJdOBVuJTtDEqe1FKOeND9HkJ0qhBV9Gs1ZNZm6VtXtmVcAYj15F XoAUz/EMVGil5ep1Tu7waVvPNR2iDx/GnnQltfp9iPQNNpvYx2//HlCK3Z90LcqdCicQdZWa qCm/KQ02xaABxtpKhpxF0OmxpXUH0fS5eOaemoVnkh8AsiOvUIVVhFNgn3aeqslM2NZHB/ap wtVqTPQaZyduq8Z37jZwB7dwDzdxF7dxe5Eht9iBzZ0kotkml0Z7UnIXXiE0hWGAwnEmN6kd PXeGCNJvk05lNLd7nsYVAcgibtFOYFQm3SV3UqL0SGpydzd1GJl2VOF4m8Yls1h6VRIgpYyf vfEif+hx8ccvF6MrvxKeuiKdJOMl0mIrUls2pRrsneKevjIxK9MqYYp+LCigNPg5ucupeIk0 Ung2raKDA6S0abj83AmFSgqr/fKC1yKD/2omgYIMgeMzvhgMjBYMOM5jOo+cPfa4XpUjvjR0 POo4O/OzyexbxkUMx83HQtte4/i3QpLUQdfLEU0mibLowLhoQv5zkEOlfaenUxF4ebi0VYr0 UO5LVfv3Z8306yUH2QzMUMdNVa5NefjUUq3dS6c5XCIbus2QkhrdU7E3R2/Xk/Y5nndp9+QO 2/0oDvInZM5kVufeVTePWkfXZHUlj+gefO01W1rUpePW2wyPSZt17/35Sbue+gSS7rm5X2o5 qr81Wr8NWTu6XVaphfHngM+QcHq2Dd1pbwpjm/uFa7smC6V2aMN2aj7nncb0sAMyUqTQnr5g a540AlElCCFXav+D2LHDYncZ4PURU52mNQ3hejG7KaIJ6p8FuBJl93HXRrvDOwLSe7zfO77n u77vO7/HuxRytxjae79X8iXBIcBDRl4OsrsPfEyt17+TN33PN8MTxyVmszSdkyoeVzTlCTbq MlmUokjjMisWGDOvckLYSaakSTbHU51Ou6lxeGxW38QfWT4XR8bxY+RdFAqJTCBJXELnNck1 9EE2ZUtMpJirs1jl25Tii3hPfFb+hFVttGE6VVRFzZRYJPG85E/ntXTZ9GYGOnM0DaTfuVj9 9Yof1dLMfCc/liqvne8cFvv4T1haml2vJdczKagLVlwzVQKB4GVxqZRAXqj3RMCkFnZGTrxz dfZamDQnNhMQVZAHichq99a1c03km+lepNBXZBACHcn+bX6b6oVClJ/a50a16Hbp72cVfXfq t77rvz7sx77sb2pAAAA7 ------=_NextPart_000_0007_01C64446.EE551270-- From bad_boyhlwd@yahoo.no Fri Mar 10 08:16:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhTk-00061d-GI for eap-archive@ietf.org; Fri, 10 Mar 2006 08:16:24 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhTk-000653-Ev for eap-archive@ietf.org; Fri, 10 Mar 2006 08:16:24 -0500 Received: from [218.11.64.199] (helo=2A24F58) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FHhTh-0006Wv-F8 for eap-archive@ietf.org; Fri, 10 Mar 2006 08:16:24 -0500 Received: from firewall.abstruseness.de (firewall.abstruseness.de [142.227.167.232]) (HELO localhost) by MTA73.adequacy.com.au with ESMTP id q58FmUeNf522f28t Received: (from smap@localhost) by mail784.aviarist.no (8.9.3/8.9.3) id N171.WN77.6gf4M9 for ; Fri, 10 Mar 2006 09:08:13 -0400 Date: Fri, 10 Mar 2006 07:12:13 -0600 From: "Angelo E. Benton, II" To: eap-archive@ietf.org Subject: Fwd: Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi, Our pri$ces will please you. Sympathetic cust0m3r supp0rttt.=20 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ copy the address below and paste in o your web browser: autohybridization.candyball.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Its down upon my spirit flings,. Unless it trembled with the strings.. As she melted to smoke.. A lizard named Ed is asleep in his bed,. Still bar you the way, and deny you life -- =20. Best Regards, Jeff Whitley From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 10:38:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjhK-000350-6U for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 10:38:34 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHjhH-000200-PB for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 10:38:34 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 979D5430126 for ; Fri, 10 Mar 2006 07:38:30 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AB8FB43005F for ; Fri, 10 Mar 2006 07:38:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 963AA398080 for ; Fri, 10 Mar 2006 07:38:15 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 634CB39806F for ; Fri, 10 Mar 2006 07:38:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 10:41:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEF0U5FVBRWta7QVWZP2QDp8eq9AAQET/A From: "Avi Lior" To: "Jari Arkko" , "Salowey, Joe" , "Narayanan, Vidya" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, March 10, 2006 2:47 AM > To: Salowey, Joe; Avi Lior; Narayanan, Vidya > Cc: eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > > > > > >>>Further, an EMSK MUST NOT be used to generate more than=20 > one AMSK for=20 > >>>a given application. > >>> =20 > >>> > >>I am not sure that the above does not pose a threat. =20 > >>Normally we would > >>think that one Application would require one AMSK. But=20 > since we are=20 > >>not defining what an application is -- and we shouldn't IMO=20 > enter that=20 > >>rat hole. Then what if there was some application that requires an=20 > >>two AMSKs.? Is there harm? > >> =20 > >> >=20 > This related originally to the EMSK deletion requirement.=20 > There was an argument that the EMSK need to stay around so=20 > that application X can keep on asking the 127th key that it needs. >=20 > Now that we seem to be saying that there is no strict EMSK=20 > deletion requirement, this may be less urgent. >=20 > However, I still think it is a good idea that applications=20 > get just one AMSK, and if they need multiple keys they=20 > generate those themselves. And the definition of an=20 > application can be "an IANA registered label for an AMSK=20 > needed for a specific purpose". Since the IANA registrations=20 > won't have "handoff 1st key", "handoff 2nd key" etc but=20 > rather "handoff key", then we satisfy this model. But this is=20 > still mostly to keep the hierarchy structurally clean and=20 > simple, not for any specific technical reason. (Other than=20 > that it still allows early deletion of the EMSK better than=20 > if we would base all keys on the EMSK.) I agree. >=20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 10:39:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjiC-0003T9-F7 for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 10:39:28 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHjiC-00021O-0W for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 10:39:28 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ACB144300D8 for ; Fri, 10 Mar 2006 07:39:27 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F0768430108 for ; Fri, 10 Mar 2006 07:38:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DF410398066 for ; Fri, 10 Mar 2006 07:38:21 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 43FB839807D for ; Fri, 10 Mar 2006 07:38:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 10:37:40 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/w From: "Avi Lior" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Jari, =20 See inline. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, March 10, 2006 3:34 AM > To: Avi Lior > Cc: Salowey, Joe; Narayanan, Vidya; eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Avi Lior wrote: >=20 > >>[Joe] I think a AAA server is typically composed of several=20 > >>components. > >>One of these can be a key holder. I don't see why you=20 > couldn't define=20 > >>new functionality in RADIUS to interact with the key holder (other=20 > >>than the fact that it seems to be difficult to define=20 > anything new in=20 > >>RADIUS). > >> =20 > >> > > > >[Avi] Aboslutely correct on all fronts ;-). A AAA server can have=20 > >EAP-AS (authetncation server) and a key holder/key generator. So I=20 > >guess ia m being very formal in the sense that AAA is a protocol and=20 > >not a server. > > > >And BTW I don't think we need to have an RFC to define a Key Holder=20 > >function in RADIUS servers. > > =20 > > > First of all, I think this part of the discussion is largely=20 > just a matter of vague definitions making it hard to make=20 > exact statements. E.g. where is the line between AAA as a=20 > "transport" and as an "application" that has intelligence to=20 > make decisions and grant resources such as keys? That line is tough to define in RADIUS, is defined in Diameter. And I think it we don't need to enter the rat hole and formally define it. > Just to repeat what we have already established, I think we=20 > have consensus that (a) EMSK is generated by EAP methods and=20 > that (b) its not going to be shipped away to the access=20 > devices. In addition, it seems obvious that the document we=20 > are discussing will not define how AMSKs are used or transported. Okay with me. > So the conclusion is that the EMSK is kept somewhere between=20 > the EAP method and AAA transport layers. Yes. > I would note that this means that it is, in an IETF sense,=20 > within a box and not transported via protocols. I don't think=20 > it makes a lot of sense to debate too long about what the=20 > internal structure of the box is. I'd be happy saying that it=20 > resides in the EAP server. I would in addition only say the=20 > following about the internal module structures: The EMSK is=20 > not communicated either to the lower layer or the AAA transport layer. > But AMSKs derived from it can be, > and that any such derivation would have to be defined in=20 > future documents. Yes. > Finally, I dislike the idea that we would be adding major=20 > functionality (such as key server) to IETF protocols and=20 > mechanisms without properly documenting how they will be used=20 > and what the protocols will exactly carry.=20 Understood. > The role of the=20 > EAP keying framework is to leave some key material in the EAP=20 > server to enable such functionality, but if we are going to=20 > use it, we will need, among other things, protocol=20 > descriptions on how RADIUS can retrieve pieces of this key=20 > information and how particular applications employ these keys. If RADIUS is colocated with EAP-server do we need to define a protocol for getting the AMSK(s)? =20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 11:11:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkDZ-0003WG-Iv for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:11:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkDY-0003TM-54 for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:11:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85B51430075 for ; Fri, 10 Mar 2006 08:11:51 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 96F8943005F for ; Fri, 10 Mar 2006 08:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8168E80C13F for ; Fri, 10 Mar 2006 08:11:33 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by hermes.tigertech.net (Postfix) with ESMTP id 0C1F880C11A for ; Fri, 10 Mar 2006 08:11:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 0A5A31FABF4; Fri, 10 Mar 2006 17:11:23 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07569-01-60; Fri, 10 Mar 2006 17:11:22 +0100 (CET) Received: from [207.3.232.120] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 98B3B1FABD0; Fri, 10 Mar 2006 17:11:17 +0100 (CET) Message-ID: <4411A60C.9000602@dif.um.es> Date: Fri, 10 Mar 2006 11:15:08 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <441139F2.5050906@piuha.net> In-Reply-To: <441139F2.5050906@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Jari >First of all, I think this part of the discussion is largely just >a matter of vague definitions making it hard to make exact >statements. E.g. where is the line between AAA as a >"transport" and as an "application" that has intelligence >to make decisions and grant resources such as keys? > > I agree on you this. In my mind the AAA server (where EAP server might be co-located) is (or should be) intelligent enough to manage keys from users. >Just to repeat what we have already established, I think >we have consensus that (a) EMSK is generated by EAP >methods and that (b) its not going to be shipped away >to the access devices. In addition, it seems obvious that >the document we are discussing will not define how AMSKs >are used or transported. > > >So the conclusion is that the EMSK is kept somewhere >between the EAP method and AAA transport layers. > > So far, between EAP methods and AAA transpor layers (AAA server?? ) we have EAP authenticator layer and EAP layer. An as specified draft-ietf-eap-keying-10.txt both layers cannot cache anything. I think it does not preclude the use of EMSK but it establishes limits to the creation of AMSK. That is, the AMSK should be created just in the moment the EMSK is exported. If EMSK wants to be cached, that part of text should be relaxed, no? >I would note that this means that it is, in an IETF sense, >within a box and not transported via protocols. I don't >think it makes a lot of sense to debate too long about >what the internal structure of the box is. I'd be happy >saying that it resides in the EAP server. I would in >addition only say the following about the internal >module structures: The EMSK is not communicated >either to the lower layer or the AAA transport layer. >But AMSKs derived from it can be, >and that any such derivation would have to be defined >in future documents. > > I have seen during discussions and also under my understanding of draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be tranported from AAA server to some entity or 2) AMSK could be used as a root and cached by the AAA server to derive new keys which would be eventually transported to different entities. will that decision between both cases be specified for application? or would it be better to select one approach (it seems people like second one)? Regards. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 11:39:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkej-0002FP-0S for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:39:57 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkeh-0004Oo-Jg for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:39:56 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0556D430128 for ; Fri, 10 Mar 2006 08:39:55 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C252743005F for ; Fri, 10 Mar 2006 08:39:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B1D2A80C12D for ; Fri, 10 Mar 2006 08:39:35 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by hermes.tigertech.net (Postfix) with ESMTP id EA28B80C11A for ; Fri, 10 Mar 2006 08:39:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id A325223CBE3 for ; Fri, 10 Mar 2006 17:39:31 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29720-01-35 for ; Fri, 10 Mar 2006 17:39:31 +0100 (CET) Received: from [207.3.232.120] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 35C5423CBD3 for ; Fri, 10 Mar 2006 17:39:31 +0100 (CET) Message-ID: <4411ACAB.3090506@dif.um.es> Date: Fri, 10 Mar 2006 11:43:23 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Strawman -10/EMSK deletion requirement? : EAP peer/authenticator References: <441139F2.5050906@piuha.net> <4411A60C.9000602@dif.um.es> In-Reply-To: <4411A60C.9000602@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 An additional comment, I have been wondering about EAP peer side and EAP authenticator side. In the EAP peer side, I have some doubts: It seems following the same that it has been discussed for EAP server, that EAP peer would create the same set of AMSKs than EAP server. And then AMSKs should be exported to lower layer correct?. However I do not know if the bunch of AMSKs should be exported to the EAP lower layer or to another "lower layers". Maybe I am wrong, but I was assuming each "application" could have different lower layers to interact with different "authenticators" . And (possibly) each AMSK is intended to be used with each different authenticator. Additionally, I was wondering how it affects to "Mode Independence". EAP peer might think that EAP authenticator has MSK and AMSKs (or keys derived from them), is that correct?. Also , would it make sense to create AMSKs in case of standalone EAP authenticator? Thanks. > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 11:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkn1-0005bR-4v for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:48:31 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkn0-0004WY-Kg for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 11:48:31 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 08606430076 for ; Fri, 10 Mar 2006 08:48:30 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 52A5943005F for ; Fri, 10 Mar 2006 08:48:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3536D398064 for ; Fri, 10 Mar 2006 08:48:17 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 03D02398081 for ; Fri, 10 Mar 2006 08:48:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 11:50:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEXcd1WwDzj3VmQjyI+A3hp3oZMgAAjxnQ From: "Avi Lior" To: "Rafa Marin Lopez" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Hi Rafa, You raise a good point in the following:=20 > I have seen during discussions and also under my=20 > understanding of draft-aboba-eap-keying-extns-00.txt that=20 > either 1) AMSK would be tranported from AAA server to some=20 > entity or 2) AMSK could be used as a root and cached by the=20 > AAA server to derive new keys which would be eventually=20 > transported to different entities. >=20 > will that decision between both cases be specified for=20 > application? or would it be better to select one approach (it=20 > seems people like second one)? I have recently seen the need for both models. IMO keeping the AMSK at the AAA and EAP Peer and only transporting derived keys to external entities makes a lot of sense but consider the following: Supposing I have an two entities E1 and E2 that received DE-KEY(s) derived from E-AMSK. DE-KEY(s) are used to secure the communication between E1 and E2. Now E2 wants to delegate responsibility of communicate with E1 to E3 which it trusts. E2 can pass the DE-KEY(s) to E3 but it would be better to derive another set of keys for that communication. As I understand it, E2 and E1 cannot derive DE-KEY'(s) from DE-KEY(s) -- since DE-KEY(s) are used for one purpose already and using them for another purpose (key derivation) will make them weak. So in this case the only way to achieve this tranasaction is to involve AAA again. This could be very expensive. Another approach is to send E1 and E2 E-AMSK so that they can generate subsequent keys to deal with this scenario. Of course you could also send E1 and E2 DE-KEY(S) to secure their communication and also another key derived from E-AMSK for the purpose of generating new keys. But is that necessary? Why couldn't we just distribute E-AMSK. > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 > Sent: Friday, March 10, 2006 11:15 AM > To: Jari Arkko > Cc: Avi Lior; eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Jari >=20 > >First of all, I think this part of the discussion is largely just a=20 > >matter of vague definitions making it hard to make exact statements.=20 > >E.g. where is the line between AAA as a "transport" and as an=20 > >"application" that has intelligence to make decisions and grant=20 > >resources such as keys? > > =20 > > > I agree on you this. In my mind the AAA server (where EAP=20 > server might be co-located) is (or should be) intelligent=20 > enough to manage keys from users. >=20 > >Just to repeat what we have already established, I think we have=20 > >consensus that (a) EMSK is generated by EAP methods and that (b) its=20 > >not going to be shipped away to the access devices. In addition, it=20 > >seems obvious that the document we are discussing will not=20 > define how=20 > >AMSKs are used or transported. > > =20 > > > >So the conclusion is that the EMSK is kept somewhere between the EAP=20 > >method and AAA transport layers. > > =20 > > > So far, between EAP methods and AAA transpor layers (AAA=20 > server?? ) we have EAP authenticator layer and EAP layer. An=20 > as specified draft-ietf-eap-keying-10.txt both layers cannot=20 > cache anything. I think it does not preclude the use of EMSK=20 > but it establishes limits to the creation of AMSK. That is,=20 > the AMSK should be created just in the moment the EMSK is=20 > exported. If EMSK wants to be cached, that part of text=20 > should be relaxed, no? >=20 > >I would note that this means that it is, in an IETF sense,=20 > within a box=20 > >and not transported via protocols. I don't think it makes a lot of=20 > >sense to debate too long about what the internal structure=20 > of the box=20 > >is. I'd be happy saying that it resides in the EAP server. I=20 > would in=20 > >addition only say the following about the internal module=20 > structures:=20 > >The EMSK is not communicated either to the lower layer or the AAA=20 > >transport layer. > >But AMSKs derived from it can be, > >and that any such derivation would have to be defined in future=20 > >documents. > > =20 > > > I have seen during discussions and also under my=20 > understanding of draft-aboba-eap-keying-extns-00.txt that=20 > either 1) AMSK would be tranported from AAA server to some=20 > entity or 2) AMSK could be used as a root and cached by the=20 > AAA server to derive new keys which would be eventually=20 > transported to different entities. >=20 > will that decision between both cases be specified for=20 > application? or would it be better to select one approach (it=20 > seems people like second one)? >=20 > Regards. >=20 > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 12:20:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlIM-0004eq-Lc for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 12:20:54 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHlIL-00063A-5b for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 12:20:54 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D7CB43010D for ; Fri, 10 Mar 2006 09:20:52 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E1F5643005F for ; Fri, 10 Mar 2006 09:20:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB42780C13F for ; Fri, 10 Mar 2006 09:20:31 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 7F3E980C14F for ; Fri, 10 Mar 2006 09:20:10 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2AHK0IM003465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2006 09:20:01 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2AHJn1H012308; Fri, 10 Mar 2006 09:19:59 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 09:19:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 09:19:54 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5465@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHWWlG0KTYXcxQTKX6OySJluQNwASSiqw From: "Narayanan, Vidya" To: "Jari Arkko" , "Avi Lior" X-OriginalArrivalTime: 10 Mar 2006 17:19:54.0325 (UTC) FILETIME=[D8EAB050:01C64466] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 I completely agree with Jari's comments below. I also meant EAP/AAA server as a "box" and was not so much referring to the AAA protocol itself. While AAA protocols could remain stateless, it would be fine to say that the EMSK resides in the EAP server without getting into key holders, etc.=20 Thanks, Vidya=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, March 10, 2006 12:34 AM > To: Avi Lior > Cc: Salowey, Joe; Narayanan, Vidya; eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Avi Lior wrote: >=20 > >>[Joe] I think a AAA server is typically composed of several=20 > >>components. > >>One of these can be a key holder. I don't see why you=20 > couldn't define=20 > >>new functionality in RADIUS to interact with the key holder (other=20 > >>than the fact that it seems to be difficult to define=20 > anything new in=20 > >>RADIUS). > >> =20 > >> > > > >[Avi] Aboslutely correct on all fronts ;-). A AAA server can have=20 > >EAP-AS (authetncation server) and a key holder/key generator. So I=20 > >guess ia m being very formal in the sense that AAA is a protocol and=20 > >not a server. > > > >And BTW I don't think we need to have an RFC to define a Key Holder=20 > >function in RADIUS servers. > > =20 > > > First of all, I think this part of the discussion is largely=20 > just a matter of vague definitions making it hard to make=20 > exact statements. E.g. where is the line between AAA as a=20 > "transport" and as an "application" that has intelligence to=20 > make decisions and grant resources such as keys? >=20 > Just to repeat what we have already established, I think we=20 > have consensus that (a) EMSK is generated by EAP methods and=20 > that (b) its not going to be shipped away to the access=20 > devices. In addition, it seems obvious that the document we=20 > are discussing will not define how AMSKs are used or transported. >=20 > So the conclusion is that the EMSK is kept somewhere between=20 > the EAP method and AAA transport layers. > I would note that this means that it is, in an IETF sense,=20 > within a box and not transported via protocols. I don't think=20 > it makes a lot of sense to debate too long about what the=20 > internal structure of the box is. I'd be happy saying that it=20 > resides in the EAP server. I would in addition only say the=20 > following about the internal module structures: The EMSK is=20 > not communicated either to the lower layer or the AAA transport layer. > But AMSKs derived from it can be, > and that any such derivation would have to be defined in=20 > future documents. >=20 > Finally, I dislike the idea that we would be adding major=20 > functionality (such as key server) to IETF protocols and=20 > mechanisms without properly documenting how they will be used=20 > and what the protocols will exactly carry. The role of the=20 > EAP keying framework is to leave some key material in the EAP=20 > server to enable such functionality, but if we are going to=20 > use it, we will need, among other things, protocol=20 > descriptions on how RADIUS can retrieve pieces of this key=20 > information and how particular applications employ these keys. >=20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 12:23:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlKR-0005X4-Ij for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 12:23:03 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHlKQ-00067S-5T for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 12:23:03 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D10364300C6 for ; Fri, 10 Mar 2006 09:23:01 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9349443005F for ; Fri, 10 Mar 2006 09:22:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 869D639807C for ; Fri, 10 Mar 2006 09:22:47 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id D4F16398079 for ; Fri, 10 Mar 2006 09:22:42 -0800 (PST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2AHMc5n007778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2006 09:22:38 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2AHMb7X016702; Fri, 10 Mar 2006 09:22:37 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 09:22:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 09:22:37 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5467@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/wAAPao4A= From: "Narayanan, Vidya" To: "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 10 Mar 2006 17:22:36.0656 (UTC) FILETIME=[39AC6F00:01C64467] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > > The role of the > > EAP keying framework is to leave some key material in the=20 > EAP server=20 > > to enable such functionality, but if we are going to use=20 > it, we will=20 > > need, among other things, protocol descriptions on how RADIUS can=20 > > retrieve pieces of this key information and how particular=20 > > applications employ these keys. >=20 > If RADIUS is colocated with EAP-server do we need to define a=20 > protocol for getting the AMSK(s)? > =20 I would imagine that each application will define some RADIUS attributes or Diameter AVPs to retrive the AMSK using the AAA protocol. No?=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 14:59:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHnlF-0005ge-8o for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 14:58:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHnfv-0001rb-QL for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 14:53:25 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 320B8430112 for ; Fri, 10 Mar 2006 11:53:23 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D35BB43006D for ; Fri, 10 Mar 2006 11:53:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C6DC780C120 for ; Fri, 10 Mar 2006 11:53:07 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id 64ACC80C0F4 for ; Fri, 10 Mar 2006 11:52:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 14:55:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/wAAPao4AABU7lMA== From: "Avi Lior" To: "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Vidya, See inline...=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Friday, March 10, 2006 12:23 PM > To: Avi Lior; Jari Arkko > Cc: Salowey, Joe; eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 >=20 > >=20 > > > The role of the > > > EAP keying framework is to leave some key material in the > > EAP server > > > to enable such functionality, but if we are going to use > > it, we will > > > need, among other things, protocol descriptions on how RADIUS can=20 > > > retrieve pieces of this key information and how particular=20 > > > applications employ these keys. > >=20 > > If RADIUS is colocated with EAP-server do we need to define=20 > a protocol=20 > > for getting the AMSK(s)? > > =20 >=20 > I would imagine that each application will define some RADIUS=20 > attributes or Diameter AVPs to retrive the AMSK using the AAA=20 > protocol. No?=20 Yes. To get the AMSK or derivative keys from the AAA server. But not between the AAA server and the EAP-Authentication Server. Note, if I can remember correctly someone wanted to specify a protocol to get the AMSK from the EMSK. > Vidya >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 16:14:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHowP-0003R3-7I for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 16:14:29 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHowO-00082z-Pt for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 16:14:29 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DC91F4300A4 for ; Fri, 10 Mar 2006 13:14:27 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D0E4643005F for ; Fri, 10 Mar 2006 13:14:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C4BFA80C135 for ; Fri, 10 Mar 2006 13:14:12 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 66D5780C12F for ; Fri, 10 Mar 2006 13:14:02 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2ALDvIM032363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2006 13:13:58 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2ALDuNi000047; Fri, 10 Mar 2006 13:13:56 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 13:13:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 13:13:36 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D552E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/wAAPao4AABU7lMAACsIFw From: "Narayanan, Vidya" To: "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 10 Mar 2006 21:13:35.0302 (UTC) FILETIME=[7E11FE60:01C64487] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Avi, > See inline...=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Friday, March 10, 2006 12:23 PM > > To: Avi Lior; Jari Arkko > > Cc: Salowey, Joe; eap@frascone.com > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? > >=20 > >=20 > > > >=20 > > > > The role of the > > > > EAP keying framework is to leave some key material in the > > > EAP server > > > > to enable such functionality, but if we are going to use > > > it, we will > > > > need, among other things, protocol descriptions on how=20 > RADIUS can=20 > > > > retrieve pieces of this key information and how particular=20 > > > > applications employ these keys. > > >=20 > > > If RADIUS is colocated with EAP-server do we need to define > > a protocol > > > for getting the AMSK(s)? > > > =20 > >=20 > > I would imagine that each application will define some RADIUS=20 > > attributes or Diameter AVPs to retrive the AMSK using the AAA=20 > > protocol. No? >=20 > Yes. To get the AMSK or derivative keys from the AAA server.=20 > But not between the AAA server and the EAP-Authentication Server. >=20 > Note, if I can remember correctly someone wanted to specify a=20 > protocol to get the AMSK from the EMSK. >=20 How often do we have an EAP server not co-located with the AAA server? When they are co-located, a protocol isn't really required. When they are not, I can see a need - but, from a practical use case perspective, I feel that such a protocol would find very limited use.=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 16:22:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHp4P-0006CL-Ok for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 16:22:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHp4M-0008MS-BV for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 16:22:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 040A543006D for ; Fri, 10 Mar 2006 13:22:42 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8FC6E43005F for ; Fri, 10 Mar 2006 13:22:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7AC4639802B for ; Fri, 10 Mar 2006 13:22:25 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5945D398040 for ; Fri, 10 Mar 2006 13:22:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 16:24:59 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/wAAPao4AABU7lMAACsIFwAABeR6A= From: "Avi Lior" To: "Narayanan, Vidya" , "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f See inline please....=20 > >=20 > > Yes. To get the AMSK or derivative keys from the AAA server.=20 > > But not between the AAA server and the EAP-Authentication Server. > >=20 > > Note, if I can remember correctly someone wanted to specify=20 > a protocol=20 > > to get the AMSK from the EMSK. > >=20 >=20 > How often do we have an EAP server not co-located with the AAA server? Well in one SDO activitiy that I am working on there is a case where the EAP-Server is not deployed with the AAA-server for some fo the cases. It is however co-located with the NAS. > When they are co-located, a protocol isn't really required.=20 I agree. > When they are not, I can see a need - but, from a practical=20 > use case perspective, I feel that such a protocol would find=20 > very limited use.=20 I agree with you. But I wouldn't discount it either. My approach is to allow for that -- and certainly it is allowed and then solve the problem when someone can actually demonstrate a need. Or let them solve the problem ;-) > Vidya >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 10 17:17:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpvP-00017I-Vc for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 17:17:31 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHpvN-000218-HL for eap-archive@lists.ietf.org; Fri, 10 Mar 2006 17:17:31 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9E51043010D for ; Fri, 10 Mar 2006 14:17:28 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 63FC743005F for ; Fri, 10 Mar 2006 14:17:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5875239807E for ; Fri, 10 Mar 2006 14:17:15 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6CD64398083 for ; Fri, 10 Mar 2006 14:17:12 -0800 (PST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2AMH5IM006589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2006 14:17:06 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2AMH2a2028746; Fri, 10 Mar 2006 14:17:04 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 14:17:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Fri, 10 Mar 2006 14:17:06 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5575@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZEHdXgHWqDhiXYQdO0Eus0zTOctQAOdX/wAAPao4AABU7lMAACsIFwAABeR6AAARyf4A== From: "Narayanan, Vidya" To: "Avi Lior" , "Jari Arkko" X-OriginalArrivalTime: 10 Mar 2006 22:17:02.0745 (UTC) FILETIME=[5B7BB090:01C64490] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 >=20 > See inline please....=20 >=20 > > >=20 > > > Yes. To get the AMSK or derivative keys from the AAA server.=20 > > > But not between the AAA server and the EAP-Authentication Server. > > >=20 > > > Note, if I can remember correctly someone wanted to specify > > a protocol > > > to get the AMSK from the EMSK. > > >=20 > >=20 > > How often do we have an EAP server not co-located with the=20 > AAA server? >=20 > Well in one SDO activitiy that I am working on there is a=20 > case where the EAP-Server is not deployed with the AAA-server=20 > for some fo the cases. > It is however co-located with the NAS. >=20 Is a AAA-server separately deployed in this case and does the EAP server contact the AAA server to authenticate the peer?=20 I guess we can say that a protocol may be needed when the NAS is not in pass through mode?=20 > > When they are co-located, a protocol isn't really required.=20 >=20 > I agree. >=20 > > When they are not, I can see a need - but, from a practical=20 > use case=20 > > perspective, I feel that such a protocol would find very=20 > limited use. >=20 > I agree with you. But I wouldn't discount it either. My=20 > approach is to allow for that -- and certainly it is allowed=20 > and then solve the problem when someone can actually=20 > demonstrate a need. Or let them solve the problem ;-) >=20 I like the latter :)=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Mar 11 06:50:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI2bg-0003lE-B3 for eap-archive@lists.ietf.org; Sat, 11 Mar 2006 06:50:00 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI2be-0001ZQ-SV for eap-archive@lists.ietf.org; Sat, 11 Mar 2006 06:50:00 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CC3B24300EB for ; Sat, 11 Mar 2006 03:49:57 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E3590430048 for ; Sat, 11 Mar 2006 03:49:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D1AB780C0EC for ; Sat, 11 Mar 2006 03:49:35 -0800 (PST) Received: from delta.interunix.net (interunix.net [202.190.199.40]) by hermes.tigertech.net (Postfix) with ESMTP id 6CCEA80C0FF for ; Sat, 11 Mar 2006 03:49:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[192.168.0.3]) by delta.interunix.net with esmtpa (Exim 4.60) (envelope-from ) id 1FI2cK-0001Xh-3M; Sat, 11 Mar 2006 19:50:40 +0800 Message-ID: <4412B951.6010603@hackinthebox.org> Date: Sat, 11 Mar 2006 19:49:37 +0800 From: Praburaajan User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: system-admins@research.att.com, lbs@lists.geocomm.com, freebsd-mobile@freebsd.org, eap@frascone.com, mipl-news@mobile-ipv6.org, mipl@mobile-ipv6.org, mipl-devel@mobile-ipv6.org Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Subject: [eap] HITBSecConf2006 - Malaysia: Call for Papers X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Greetings from Hack in The Box -- We are pleased to announce that the Call for Paper (CfP) for HITBSecConf2006 - Malaysia is now open! Set to take place from September 18th - 21st 2006 at The Westin Kuala Lumpur, this years conference promises to once again deliver an International deep-knowledge security conference. HITBSecConf has been described as "the most intimate of hacker gatherings" and is the largest network security conference in Asia! SUBMISSION HITBSecConf is a deep-knowledge technical conference. Talks that are more technical or that discuss new and never before seen attack methods are of more interest than a subject that has been covered several times before. Summaries not exceeding 250 words should be submitted (in plain text format) to cfp -at- hackinthebox.org for review and possible inclusion in the programme. Submissions are due no later than 1st of May 2006 TOPICS Topics of interest include, but are not limited to the following: =B7 Analysis of network and security vulnerabilities =B7 Firewall technologies =B7 Intrusion detection =B7 Data Recovery and Incident Response =B7 GPRS, 3G and CDMA Security =B7 Identification and Entity Authentication =B7 Network Protocol and Analysis =B7 Smart Card Security =B7 Virus and Worms =B7 WLAN and Bluetooth Security. =B7 Analysis of malicious code =B7 Applications of cryptographic techniques, =B7 Analysis of attacks against networks and machines =B7 Denial-of-service attacks and countermeasures =B7 File system security =B7 Security in heterogeneous and large-scale environments =B7 Techniques for developing secure systems PLEASE NOTE: We do not accept product or vendor related pitches. If your talk involves an advertisement for a new product or service your company is offering, please do not submit. Your submission should include: * Name, title, address, email and phone/contact number * Draft of the proposed presentation (in PDF or PowerPoint format), proof of concept for tools and exploits, etc. * Short biography, qualification, occupation, achievement and affiliations (limit 150 words). * Summary or abstract for your presentation (limit 250 words) * Time (45-60 minutes including time for discussion and questions) * Technical requirements (video, internet, wireless, audio, etc.) Each non-resident speaker will receive accommodation for 3 nights at The Westin Kuala Lumpur. For each non-resident speaker, HITB will cover travel expenses (through our airline partner, Malaysia Airlines) up to USD 1,000.00. HITBSecConf2006 CTF Daemons/Flags As part of our annual conference, HITB organizes an attack and defense "hack-game" commonly referred to as =93Capture The Flag=94 or CTF. As par= t of our continued efforts to improve on the game and raise the bar each year, we are inviting speakers to contribute a daemon and exploit for this years CTF competition. For further details on the submission process, kindly e-mail dinesh -at- hackinthebox.org or ctfinfo -at- hackinthebox.org. On behalf of The HITB Team, we thank you and look forward to receiving your submissions! See you guys in September! HITBSecConf2006 - Malaysia: Deep-Knowledge Network Security=20 http://conference.hackinthebox.org/hitbsecconf2006kl/=20 http://conference.hitb.org/hitbsecconf2006kl/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From com10@0108.com Sat Mar 11 08:00:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI3i4-0003Vm-7i for eap-archive@ietf.org; Sat, 11 Mar 2006 08:00:40 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI3CJ-00033x-0W for eap-archive@ietf.org; Sat, 11 Mar 2006 07:27:51 -0500 Received: from nat.customers.n-line.kiev.ua ([193.201.83.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FI2wd-0005Y7-UO for eap-archive@ietf.org; Sat, 11 Mar 2006 07:11:40 -0500 Date: Sat, 11 Mar 2006 12:14:46 -0120 From: "Sean Bliss" X-Mailer: The Bat! (v3.0.1.33) CD5BF9353B3B7091 Reply-To: "Sean Bliss" X-Priority: 3 (Normal) Message-ID: <337519102.20060311121446@0108.com> To: eap-archive@ietf.org Subject: fwd: Top market Picks MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Nanoforce Inc. (NNFC), Price Set To Jump Monday SYMBOL: N N F C NANOFORCE INC. (NNFC) - Current Price: 1.00 Up over .40 cents last week alone Before we start with the profile of NNFC we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW Nanoforce Inc. (NNFC) appears to be on an upward trend. Is not the time to buy ? With current marketing campaign we expect NNFC to climb thru mid March Get In Now! NANOFORCE INC. (NNFC) COMAPNY INFORMATION Nanoforce, Inc. is a company founded to support the development, and acquisition of exciting new products that integrate fundamental developments in Nanotechnology. The Nanotechnology industry is in its infancy and provides a wealth of opportunity for companies that position themselves well now to profit from the burgeoning opportunities that will be provided by nanotech produced products in the near future. NANOFORCE INC. (NNFC) RECENT NEWS (For Complete News Detail, check your current stock site.) March 7, 2006: Nanoforce Inc. Hires Local Management Team to Head Refinery Science Corp.'s El Paso Office February 13, 2006: Nanoforce Acquires Unique package of Nanotech. Ips December 16, 2005: Nanoforce Acquires Refinery Science Corp. December 16, 2005: Nanoforce approves 10 for 1 split of Refinery Science. CHECK OUT NANOFORCE (NNFC) TODAY! From Frodojdbu@yahoo.de Sat Mar 11 10:29:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI61v-000682-8p for eap-archive@ietf.org; Sat, 11 Mar 2006 10:29:19 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI61v-0008SN-7P for eap-archive@ietf.org; Sat, 11 Mar 2006 10:29:19 -0500 Received: from 85-210-54-27.dsl.pipex.com ([85.210.54.27] helo=3B93A298) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FI61s-0006ie-67 for eap-archive@ietf.org; Sat, 11 Mar 2006 10:29:19 -0500 Received: from firewall.acanthine.co.jp (firewall.acanthine.co.jp [106.130.102.72]) (EHLO localhost) by mail.Ambassadeur.it with ESMTP id iPyNu2D81w92m07t Date: Sat, 11 Mar 2006 09:20:14 -0600 From: "Lemuel Q. Villalobos, VI" To: eap-archive@ietf.org Subject: yo Message-ID: <404.LPbN78.7cy5.4Z2U2K1b@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Good day sir, We oSh ip Wor ldwide. Would you like to look stylish and treandy? The aL0W prece doesn't mean it won't look like iREAL thing.=20 ************************************************************************ COPY the Address below and paste in your WEBu browser: armature.justworlds.com ************************************************************************ Dark ones of today, my dreams must come true:=20. Out of the darkness, the ignorance, the night.=20. will be indicated by an asterisk (*). When you are finished,=20. Look ever upward at the sun and the stars.=20. They were so empty and pitiful, these Poor Souls, these clients of his, so= light.. Watching, silently weeps.=20. distress merchandising," said Sears.. face on to the edge of the curb. He kept pushing until the kid opened=20. TTYL, Leroy Phillips From acalver@cisco.com Sat Mar 11 11:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI6qb-00067D-Iq for eap-archive@ietf.org; Sat, 11 Mar 2006 11:21:41 -0500 Received: from [85.101.110.61] (helo=[85.101.110.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI6qT-0001oA-P2 for eap-archive@ietf.org; Sat, 11 Mar 2006 11:21:41 -0500 Date: Sat, 11 Mar 2006 16:21:34 -0120 From: "William Albert" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "William Albert" X-Priority: 3 (Normal) Message-ID: <7721939645.20060311162134@cisco.com> To: eap-archive@ietf.org Subject: report enclosed MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 CWTD fi1es Change 0f direct0rs, Mr. Ha t0 1ead CWTD int0 a pr0sper0us 2006 Profi led: China W0r1d Trade C0rp0rati0n CLOSE: $1.26 0fficia1 ann0uncement 0f the App0intment 0f Mr Man Ha t0 the p0siti0n 0f CF0 is expected next week. Change 0f direct0rs was fi1ed 0n Feb 28th. With 0ver 20 years experience, Mr. Ha wi11 bring a great dea1 t0 the tab1e t0 c0ntinue the advancement 0f CWTD in the c0ming year. Just read the re1ease c0nnected with the fi1ing. 0n February 28, 2006, the Registrant ann0unced the app0intment 0f Mr. Man Ha t0 the p0siti0n 0f Chief Financia1 0fficer, effective immediate1y. Mr. Ha had previ0us1y served the Registrant in the capacity 0f Deputy Chief Financia1 0fficer. Mr. Ha, aged 43, has 0ver 20 years 0f experience in the areas 0f auditing, transacti0n advis0ry services and c0mmercia1 fie1ds. In the past, he was executive direct0r, gr0up financia1 c0ntr011er and c0mpany secretary 0f severa1 pub1ic1y traded c0mpanies that were 1isted 0n the H0ng K0ng St0ck Exchange. Mr. Ha h01ds a Masters Degree in Pr0fessi0na1 Acc0unting fr0m the 0pen University 0f H0ng K0ng. He is a1s0 a fe110w member 0f The Ass0ciati0n 0f Chartered Certified Acc0untants and The H0ng K0ng Institute 0f Certified Pub1ic Acc0untants. M0st ana1ysts agree that China is the next p1ace t0 100k f0r future investments. CWTD is the 0ne t0 pick, check them 0ut first thing Thursday From dilemmaqirb@yahoo.co.kr Sat Mar 11 22:22:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIH9m-0007NV-1o for eap-archive@ietf.org; Sat, 11 Mar 2006 22:22:10 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIH9m-00066P-0K for eap-archive@ietf.org; Sat, 11 Mar 2006 22:22:10 -0500 Received: from dsl-1-static-dynamic-pool-128.chestertel.com ([207.144.6.128] helo=3883E1F8) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FIH9k-0002Rs-Ak for eap-archive@ietf.org; Sat, 11 Mar 2006 22:22:09 -0500 Received: from firewall.accessorius.it (firewall.accessorius.it [142.4.144.16]) (EHLO localhost) by MTA28.bootyless.rr.com with ESMTP id e71PkEeNr011p87y Received: (from smap@localhost) by firewall.anemonin.co.in (8.8.5) id B157.XQ03.8ji7D8 for ; Sun, 12 Mar 2006 08:19:10 +0500 Date: Sat, 11 Mar 2006 22:18:10 -0500 From: "Tad Rosas" To: eap-archive@ietf.org Subject: sup Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Priority: normal X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Good day eap-archive@ietf.org, Wide selection of most popular M3Ds online! Easier and faster than ever to get the Pres_cr!pt!0ns you need.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D copy the address below and paste in o your web browser: assayer.candyball.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It's autumn, 1991, and I'm sitting on the edge of the bed. Lift high my banner out of the dust.=20. Remember my sweat, my pain, my despair.=20. company Brandimensions, "whereas GM would best be described as having a 'b= rand penalty.'". Weep not, my darling,. Bye, Lillian Gilbert From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 12 17:24:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYys-0006nd-LA for eap-archive@lists.ietf.org; Sun, 12 Mar 2006 17:24:06 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIYyq-0004Uw-Vl for eap-archive@lists.ietf.org; Sun, 12 Mar 2006 17:24:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 00D264300DA for ; Sun, 12 Mar 2006 14:24:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2716E430058 for ; Sun, 12 Mar 2006 14:23:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 15C3C398056 for ; Sun, 12 Mar 2006 14:23:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id E9EBA398039 for ; Sun, 12 Mar 2006 14:23:49 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CBC0789898; Mon, 13 Mar 2006 00:23:46 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6245589852; Mon, 13 Mar 2006 00:23:46 +0200 (EET) Message-ID: <441475E5.3080403@piuha.net> Date: Sun, 12 Mar 2006 21:26:29 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Avi Lior wrote: >>The role of the >>EAP keying framework is to leave some key material in the EAP >>server to enable such functionality, but if we are going to >>use it, we will need, among other things, protocol >>descriptions on how RADIUS can retrieve pieces of this key >>information and how particular applications employ these keys. >> >> > >If RADIUS is colocated with EAP-server do we need to define a protocol >for getting the AMSK(s)? > > I do not think we need a protocol definition between the AAA and EAP layers; this is mostly an API in any case. However, I do believe that if some device (e.g. a NAS, DHCP server, ...) is going to need an AMSK, then its very unlikely that such a device is in the same box as the AAA and EAP servers. This implies that we do need a protocol extension from a AAA client to the AAA server to retrieve AMSKs. This isn't a task that we commit to taking in the EAP keying framework or EAP WG. Go talk to the RADEXT or DIME groups instead. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Mar 12 17:24:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYze-0007O6-RP for eap-archive@lists.ietf.org; Sun, 12 Mar 2006 17:24:54 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIYze-0004Vv-F9 for eap-archive@lists.ietf.org; Sun, 12 Mar 2006 17:24:54 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 214E94300EA for ; Sun, 12 Mar 2006 14:24:54 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9686E4300D9 for ; Sun, 12 Mar 2006 14:23:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 85D6C80C106 for ; Sun, 12 Mar 2006 14:23:57 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id 84A6080C102 for ; Sun, 12 Mar 2006 14:23:50 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5EA408989B; Mon, 13 Mar 2006 00:23:48 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DBD1389852; Mon, 13 Mar 2006 00:23:47 +0200 (EET) Message-ID: <4414767A.3030301@piuha.net> Date: Sun, 12 Mar 2006 21:28:58 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rafa Marin Lopez Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <441139F2.5050906@piuha.net> <4411A60C.9000602@dif.um.es> In-Reply-To: <4411A60C.9000602@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Rafa Marin Lopez wrote: >> >> >> >> So the conclusion is that the EMSK is kept somewhere >> between the EAP method and AAA transport layers. >> >> > So far, between EAP methods and AAA transpor layers (AAA server?? ) we > have EAP authenticator layer and EAP layer. An as specified > draft-ietf-eap-keying-10.txt both layers cannot cache anything. I > think it does not preclude the use of EMSK but it establishes limits > to the creation of AMSK. That is, the AMSK should be created just in > the moment the EMSK is exported. If EMSK wants to be cached, that part > of text should be relaxed, no? I think so. > > I have seen during discussions and also under my understanding of > draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be > tranported from AAA server to some entity or 2) AMSK could be used as > a root and cached by the AAA server to derive new keys which would be > eventually transported to different entities. > > will that decision between both cases be specified for application? or > would it be better to select one approach (it seems people like second > one)? I think the practical approach would be to take one application and specify how its done for that. Other applications may later use the same approach or something else, if their requirements differ. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 02:39:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhdy-0007fb-Qi for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 02:39:06 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIhdx-0004Ep-EC for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 02:39:06 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AE4F84300E3 for ; Sun, 12 Mar 2006 23:39:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 900E6430075 for ; Sun, 12 Mar 2006 23:38:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7F9C9398016 for ; Sun, 12 Mar 2006 23:38:48 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7316D39800D for ; Sun, 12 Mar 2006 23:38:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 13 Mar 2006 02:41:23 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZGJBnmBfppqA1wTi+8db8ZqDt1GQATLLxQ From: "Avi Lior" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 HI Jari, I thought we would be done by now :-) See inline....=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Sunday, March 12, 2006 2:26 PM > To: Avi Lior > Cc: eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Avi Lior wrote: >=20 > >>The role of the > >>EAP keying framework is to leave some key material in the=20 > EAP server=20 > >>to enable such functionality, but if we are going to use=20 > it, we will=20 > >>need, among other things, protocol descriptions on how RADIUS can=20 > >>retrieve pieces of this key information and how particular=20 > >>applications employ these keys. > >> =20 > >> > > > >If RADIUS is colocated with EAP-server do we need to define=20 > a protocol=20 > >for getting the AMSK(s)? > > =20 > > >=20 > I do not think we need a protocol definition between the AAA=20 > and EAP layers; this is mostly an API in any case. What about the API to fetch the MSK? Or to Push the MSK? What about the API to send the EAP message from the AAA to the EAP AS? What about the API to retrieve the EAP message from the EAP-AS? Etc....why are we forgetting these as well? > --Jari >=20 >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 03:30:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIiRT-0007EF-47 for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 03:30:15 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIiRR-0005ns-Nq for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 03:30:15 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 267F14300E2 for ; Mon, 13 Mar 2006 00:30:13 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 69060430075 for ; Mon, 13 Mar 2006 00:30:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 55390398030 for ; Mon, 13 Mar 2006 00:30:03 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id EDFDF39800D for ; Mon, 13 Mar 2006 00:30:00 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CECF8898A0; Mon, 13 Mar 2006 10:29:57 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6F39A8989F; Mon, 13 Mar 2006 10:29:57 +0200 (EET) Message-ID: <44152D81.3080009@piuha.net> Date: Mon, 13 Mar 2006 10:29:53 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Avi Lior wrote: > >>I do not think we need a protocol definition between the AAA >>and EAP layers; this is mostly an API in any case. >> >> > >What about the API to fetch the MSK? Or to Push the MSK? >What about the API to send the EAP message from the AAA to the EAP AS? >What about the API to retrieve the EAP message from the EAP-AS? >Etc....why are we forgetting these as well? > > I am not saying that they are not needed. The question is whether the IETF wants to get into the business of standardizing such APIs. We mostly deal with what happens on the wire, in protocols. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 04:37:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjUu-0001SH-6v for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 04:37:52 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIjUs-0007jA-Q3 for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 04:37:52 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EC7464300AF for ; Mon, 13 Mar 2006 01:37:47 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D5082430075 for ; Mon, 13 Mar 2006 01:37:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF85080C0E9 for ; Mon, 13 Mar 2006 01:37:31 -0800 (PST) Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by hermes.tigertech.net (Postfix) with ESMTP id B2FC880C0F3 for ; Mon, 13 Mar 2006 01:37:29 -0800 (PST) Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B7961801D; Mon, 13 Mar 2006 10:37:26 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FIjR5-0002tY-IO; Mon, 13 Mar 2006 10:33:55 +0100 Date: Mon, 13 Mar 2006 10:33:55 +0100 From: Julien Bournelle To: "Narayanan, Vidya" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? Message-ID: <20060313093355.GB11116@ipv6-3.int-evry.fr> References: <2EBB8025B6D1BA41B567DB32C1D8DB842D5467@NAEX06.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB842D5467@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi all, On Fri, Mar 10, 2006 at 09:22:37AM -0800, Narayanan, Vidya wrote: > > > > > > The role of the > > > EAP keying framework is to leave some key material in the > > EAP server > > > to enable such functionality, but if we are going to use > > it, we will > > > need, among other things, protocol descriptions on how RADIUS can > > > retrieve pieces of this key information and how particular > > > applications employ these keys. > > > > If RADIUS is colocated with EAP-server do we need to define a > > protocol for getting the AMSK(s)? > > I would imagine that each application will define some RADIUS attributes > or Diameter AVPs to retrive the AMSK using the AAA protocol. No? Concerning Diameter, I think we could define a Generic Diameter Application for this. Julien > > Vidya > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap -- julien.bournelle at int-evry.fr _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 09:02:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIncr-0006P5-S0 for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 09:02:21 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIncq-0007Yg-Ex for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 09:02:21 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 79431430093 for ; Mon, 13 Mar 2006 06:02:19 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3E22C430093 for ; Mon, 13 Mar 2006 06:02:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 30A8980C146 for ; Mon, 13 Mar 2006 06:02:02 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by hermes.tigertech.net (Postfix) with ESMTP id 29A8180C132 for ; Mon, 13 Mar 2006 06:01:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Mon, 13 Mar 2006 09:04:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZGeMls0BeJ/ChJR96jGEbSCNm2oAALdUkw From: "Avi Lior" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Jari, You know what? I read: " I do not think we need a protocol definition...." as " I do think we need...." -- big difference ;-) So therefore listed all the other APIs. So I agree with you. There is an API or there isnt? Its not IETF's domain. Sorry for the confusion it was very early in the morning. Avi=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 13, 2006 3:30 AM > To: Avi Lior > Cc: eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Avi Lior wrote: >=20 > > > >>I do not think we need a protocol definition between the=20 > AAA and EAP=20 > >>layers; this is mostly an API in any case. > >> =20 > >> > > > >What about the API to fetch the MSK? Or to Push the MSK? > >What about the API to send the EAP message from the AAA to=20 > the EAP AS? > >What about the API to retrieve the EAP message from the EAP-AS? > >Etc....why are we forgetting these as well? > > =20 > > > I am not saying that they are not needed. The question is=20 > whether the IETF wants to get into the business of=20 > standardizing such APIs. We mostly deal with what happens on=20 > the wire, in protocols. >=20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From ptcw@menarche.com Mon Mar 13 10:17:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIonx-0003al-4N for eap-archive@ietf.org; Mon, 13 Mar 2006 10:17:53 -0500 Received: from [221.231.8.80] (helo=X10) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIonu-0001WS-Gn; Mon, 13 Mar 2006 10:17:52 -0500 Received: from 221.231.8.80 (HELO localhost.localdomain) (221.231.8.80) by 221.231.8.80 with SMTP; Mon, 13 Mar 2006 16:17:43 +0100 Message-Id: <8.2.2.7.1.54036231300942.768a0504@156.154.16.150> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.6 Xmailer-ig: iG-Mailer 1.0r0v4(44357.22732194.887688) Date: Mon, 13 Mar 2006 16:17:43 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org, edmund.rivera@ietf.org From: "Corina Acosta" Subject: Amazing Mortgages at low rates X-Spam-Score: 4.8 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 guess what! Homeowner You have been pre-approved for a $420,035 Home Loan at a Introductory APR of 3.03% This offer is being extended to you unconditionally and your credit is in no way a factor. To take Advantage of this Limited Time opportunity All we ask is that you visit our Website and complete The 1 minute post Approval Form http://www4.2hbx.net/was.asp Sincerely, Christie Jennings, Opt0ut http://www4.2hbx.net/rem.assp From tollivericlint@todays-tech.com Mon Mar 13 11:18:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpkr-0000gj-0m for eap-archive@ietf.org; Mon, 13 Mar 2006 11:18:45 -0500 Received: from erx235.neoplus.adsl.tpnet.pl ([83.20.117.235] helo=todays-tech.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIpkp-0003Xv-Ao for eap-archive@ietf.org; Mon, 13 Mar 2006 11:18:44 -0500 Message-ID: <000001c646b9$c1b95300$e0efa8c0@rfh33> Reply-To: "Clint Tolliver" From: "Clint Tolliver" To: eap-archive@ietf.org Subject: Re: PharamaLLcy news Date: Mon, 13 Mar 2006 11:18:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6468F.D8E34B00" 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 X-Spam-Score: 4.8 (++++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6468F.D8E34B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to h O f V x E s R o P g A w Y for your v M o e e d n i a a c c o t l i b o m n j s? =20 Nothing like you need it, v S s a u v u e over h 5 s 0 c % with http://wizo65.avicotrace.com ------=_NextPart_000_0001_01C6468F.D8E34B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to h O f V x E s R o P g A w Y for your v M o e e d n i a a c c o t l i b o m n j s?
 
Nothing like you need it, v S s a u v u e over h 5 s 0 c % with http://wizo65.avicotrace.com
------=_NextPart_000_0001_01C6468F.D8E34B00-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 12:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIr5M-0008Hb-3s for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 12:44:00 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIr5I-0006Y5-GM for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 12:44:00 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DE9704300EB for ; Mon, 13 Mar 2006 09:43:55 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 470D043005F for ; Mon, 13 Mar 2006 09:43:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3941380C0ED for ; Mon, 13 Mar 2006 09:43:40 -0800 (PST) X-Greylist-Status: Sender first seen 00:06:39 ago Received: from mail.bitdefender.com (ns.bitdefender.com [217.156.83.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5FFE180C104 for ; Mon, 13 Mar 2006 09:43:35 -0800 (PST) Received: (qmail 1687 invoked by uid 0); 13 Mar 2006 19:36:55 +0200 Received: (qmail 14740 invoked by uid 1010); 11 Mar 2006 13:50:51 +0200 Received: from mx2.freebsd.org (216.136.204.119) by mail.bitdefender.com with SMTP; 11 Mar 2006 13:50:50 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 8FECD58C3E; Sat, 11 Mar 2006 11:49:41 +0000 (GMT) (envelope-from owner-freebsd-mobile@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 03BA216A431; Sat, 11 Mar 2006 11:49:40 +0000 (GMT) (envelope-from owner-freebsd-mobile@freebsd.org) X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C924F16A420 for ; Sat, 11 Mar 2006 11:49:27 +0000 (GMT) (envelope-from prabu@hackinthebox.org) Received: from delta.interunix.net (interunix.net [202.190.199.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C69BA43D49 for ; Sat, 11 Mar 2006 11:49:26 +0000 (GMT) (envelope-from prabu@hackinthebox.org) Received: from localhost ([127.0.0.1] helo=[192.168.0.3]) by delta.interunix.net with esmtpa (Exim 4.60) (envelope-from ) id 1FI2cK-0001Xh-3M; Sat, 11 Mar 2006 19:50:40 +0800 Message-ID: <4412B951.6010603@hackinthebox.org> Date: Sat, 11 Mar 2006 19:49:37 +0800 From: Praburaajan User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: system-admins@research.att.com, lbs@lists.geocomm.com, freebsd-mobile@freebsd.org, eap@frascone.com, mipl-news@mobile-ipv6.org, mipl@mobile-ipv6.org, mipl-devel@mobile-ipv6.org Content-Type: text/plain; charset=windows-1252; format=flowed X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list X-BitDefender-SpamStamp: 1.1.4 049000040111AAAAAAAAAAAAAgAAAAAAAAAAAAAAgAAAQ X-BitDefender-Scanner: Clean, Agent: BitDefender Qmail 1.6.2 on mail.bitdefender.com X-BitDefender-Spam: No (0) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Subject: [eap] HITBSecConf2006 - Malaysia: Call for Papers X-BeenThere: eap@frascone.com List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Greetings from Hack in The Box -- We are pleased to announce that the Call for Paper (CfP) for HITBSecConf2006 - Malaysia is now open! Set to take place from September 18th - 21st 2006 at The Westin Kuala Lumpur, this years conference promises to once again deliver an International deep-knowledge security conference. HITBSecConf has been described as "the most intimate of hacker gatherings" and is the largest network security conference in Asia! SUBMISSION HITBSecConf is a deep-knowledge technical conference. Talks that are more technical or that discuss new and never before seen attack methods are of more interest than a subject that has been covered several times before. Summaries not exceeding 250 words should be submitted (in plain text format) to cfp -at- hackinthebox.org for review and possible inclusion in the programme. Submissions are due no later than 1st of May 2006 TOPICS Topics of interest include, but are not limited to the following: =B7 Analysis of network and security vulnerabilities =B7 Firewall technologies =B7 Intrusion detection =B7 Data Recovery and Incident Response =B7 GPRS, 3G and CDMA Security =B7 Identification and Entity Authentication =B7 Network Protocol and Analysis =B7 Smart Card Security =B7 Virus and Worms =B7 WLAN and Bluetooth Security. =B7 Analysis of malicious code =B7 Applications of cryptographic techniques, =B7 Analysis of attacks against networks and machines =B7 Denial-of-service attacks and countermeasures =B7 File system security =B7 Security in heterogeneous and large-scale environments =B7 Techniques for developing secure systems PLEASE NOTE: We do not accept product or vendor related pitches. If your talk involves an advertisement for a new product or service your company is offering, please do not submit. Your submission should include: * Name, title, address, email and phone/contact number * Draft of the proposed presentation (in PDF or PowerPoint format), proof of concept for tools and exploits, etc. * Short biography, qualification, occupation, achievement and affiliations (limit 150 words). * Summary or abstract for your presentation (limit 250 words) * Time (45-60 minutes including time for discussion and questions) * Technical requirements (video, internet, wireless, audio, etc.) Each non-resident speaker will receive accommodation for 3 nights at The Westin Kuala Lumpur. For each non-resident speaker, HITB will cover travel expenses (through our airline partner, Malaysia Airlines) up to USD 1,000.00. HITBSecConf2006 CTF Daemons/Flags As part of our annual conference, HITB organizes an attack and defense "hack-game" commonly referred to as =93Capture The Flag=94 or CTF. As par= t of our continued efforts to improve on the game and raise the bar each year, we are inviting speakers to contribute a daemon and exploit for this years CTF competition. For further details on the submission process, kindly e-mail dinesh -at- hackinthebox.org or ctfinfo -at- hackinthebox.org. On behalf of The HITB Team, we thank you and look forward to receiving your submissions! See you guys in September! HITBSecConf2006 - Malaysia: Deep-Knowledge Network Security=20 http://conference.hackinthebox.org/hitbsecconf2006kl/=20 http://conference.hitb.org/hitbsecconf2006kl/ _______________________________________________ freebsd-mobile@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" --=20 This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 12:44:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIr65-0000g1-Un for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 12:44:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIr65-0006Yo-C2 for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 12:44:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 098244300B2 for ; Mon, 13 Mar 2006 09:44:45 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 94A3143005F for ; Mon, 13 Mar 2006 09:44:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B73C80C104 for ; Mon, 13 Mar 2006 09:44:20 -0800 (PST) X-Greylist-Status: Sender first seen 00:07:10 ago Received: from mail.bitdefender.com (ns.bitdefender.com [217.156.83.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6127F80C10A for ; Mon, 13 Mar 2006 09:44:06 -0800 (PST) Received: (qmail 3130 invoked by uid 0); 13 Mar 2006 19:37:26 +0200 Received: (qmail 14529 invoked by uid 1010); 11 Mar 2006 13:50:50 +0200 Received: from mx2.freebsd.org (216.136.204.119) by mail.bitdefender.com with SMTP; 11 Mar 2006 13:50:49 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 6D04E58B07; Sat, 11 Mar 2006 11:49:41 +0000 (GMT) (envelope-from owner-freebsd-mobile@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id EA11916A42F; Sat, 11 Mar 2006 11:49:39 +0000 (GMT) (envelope-from owner-freebsd-mobile@freebsd.org) X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C924F16A420 for ; Sat, 11 Mar 2006 11:49:27 +0000 (GMT) (envelope-from prabu@hackinthebox.org) Received: from delta.interunix.net (interunix.net [202.190.199.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C69BA43D49 for ; Sat, 11 Mar 2006 11:49:26 +0000 (GMT) (envelope-from prabu@hackinthebox.org) Received: from localhost ([127.0.0.1] helo=[192.168.0.3]) by delta.interunix.net with esmtpa (Exim 4.60) (envelope-from ) id 1FI2cK-0001Xh-3M; Sat, 11 Mar 2006 19:50:40 +0800 Message-ID: <4412B951.6010603@hackinthebox.org> Date: Sat, 11 Mar 2006 19:49:37 +0800 From: Praburaajan User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: system-admins@research.att.com, lbs@lists.geocomm.com, freebsd-mobile@freebsd.org, eap@frascone.com, mipl-news@mobile-ipv6.org, mipl@mobile-ipv6.org, mipl-devel@mobile-ipv6.org Content-Type: text/plain; charset=windows-1252; format=flowed X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list X-BitDefender-SpamStamp: 1.1.4 049000040111AAAAAAAAAAAAAgAAAAAAAAAAAAAAgAAAQ X-BitDefender-Scanner: Clean, Agent: BitDefender Qmail 1.6.2 on mail.bitdefender.com X-BitDefender-Spam: No (0) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Subject: [eap] HITBSecConf2006 - Malaysia: Call for Papers X-BeenThere: eap@frascone.com List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Greetings from Hack in The Box -- We are pleased to announce that the Call for Paper (CfP) for HITBSecConf2006 - Malaysia is now open! Set to take place from September 18th - 21st 2006 at The Westin Kuala Lumpur, this years conference promises to once again deliver an International deep-knowledge security conference. HITBSecConf has been described as "the most intimate of hacker gatherings" and is the largest network security conference in Asia! SUBMISSION HITBSecConf is a deep-knowledge technical conference. Talks that are more technical or that discuss new and never before seen attack methods are of more interest than a subject that has been covered several times before. Summaries not exceeding 250 words should be submitted (in plain text format) to cfp -at- hackinthebox.org for review and possible inclusion in the programme. Submissions are due no later than 1st of May 2006 TOPICS Topics of interest include, but are not limited to the following: =B7 Analysis of network and security vulnerabilities =B7 Firewall technologies =B7 Intrusion detection =B7 Data Recovery and Incident Response =B7 GPRS, 3G and CDMA Security =B7 Identification and Entity Authentication =B7 Network Protocol and Analysis =B7 Smart Card Security =B7 Virus and Worms =B7 WLAN and Bluetooth Security. =B7 Analysis of malicious code =B7 Applications of cryptographic techniques, =B7 Analysis of attacks against networks and machines =B7 Denial-of-service attacks and countermeasures =B7 File system security =B7 Security in heterogeneous and large-scale environments =B7 Techniques for developing secure systems PLEASE NOTE: We do not accept product or vendor related pitches. If your talk involves an advertisement for a new product or service your company is offering, please do not submit. Your submission should include: * Name, title, address, email and phone/contact number * Draft of the proposed presentation (in PDF or PowerPoint format), proof of concept for tools and exploits, etc. * Short biography, qualification, occupation, achievement and affiliations (limit 150 words). * Summary or abstract for your presentation (limit 250 words) * Time (45-60 minutes including time for discussion and questions) * Technical requirements (video, internet, wireless, audio, etc.) Each non-resident speaker will receive accommodation for 3 nights at The Westin Kuala Lumpur. For each non-resident speaker, HITB will cover travel expenses (through our airline partner, Malaysia Airlines) up to USD 1,000.00. HITBSecConf2006 CTF Daemons/Flags As part of our annual conference, HITB organizes an attack and defense "hack-game" commonly referred to as =93Capture The Flag=94 or CTF. As par= t of our continued efforts to improve on the game and raise the bar each year, we are inviting speakers to contribute a daemon and exploit for this years CTF competition. For further details on the submission process, kindly e-mail dinesh -at- hackinthebox.org or ctfinfo -at- hackinthebox.org. On behalf of The HITB Team, we thank you and look forward to receiving your submissions! See you guys in September! HITBSecConf2006 - Malaysia: Deep-Knowledge Network Security=20 http://conference.hackinthebox.org/hitbsecconf2006kl/=20 http://conference.hitb.org/hitbsecconf2006kl/ _______________________________________________ freebsd-mobile@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" --=20 This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 16:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIul6-000568-FJ for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 16:39:20 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIul5-0006Jk-0h for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 16:39:20 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 185EF43011E for ; Mon, 13 Mar 2006 13:39:18 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 01F1C4300B6 for ; Mon, 13 Mar 2006 13:39:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E04F3398050 for ; Mon, 13 Mar 2006 13:39:06 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by zoidberg.tigertech.net (Postfix) with ESMTP id C2768398064 for ; Mon, 13 Mar 2006 13:39:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id D339023CD27; Mon, 13 Mar 2006 22:38:56 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28822-01-39; Mon, 13 Mar 2006 22:38:56 +0100 (CET) Received: from [207.3.232.120] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 4F3C623CCBD; Mon, 13 Mar 2006 22:38:52 +0100 (CET) Message-ID: <4415E674.4040405@dif.um.es> Date: Mon, 13 Mar 2006 16:39:00 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Avi, please see my comments inline Avi Lior wrote: >Hi Rafa, > >You raise a good point in the following: > > > >>I have seen during discussions and also under my >>understanding of draft-aboba-eap-keying-extns-00.txt that >>either 1) AMSK would be tranported from AAA server to some >>entity or 2) AMSK could be used as a root and cached by the >>AAA server to derive new keys which would be eventually >>transported to different entities. >> >>will that decision between both cases be specified for >>application? or would it be better to select one approach (it >>seems people like second one)? >> >> > >I have recently seen the need for both models. IMO keeping the AMSK at >the AAA and EAP Peer and only transporting derived keys to external >entities makes a lot of sense but consider the following: > >Supposing I have an two entities E1 and E2 that received DE-KEY(s) >derived from E-AMSK. DE-KEY(s) are used to secure the communication >between E1 and E2. > > What entity is the EAP peer? At least one of the entities should be the EAP peer no?. or are you calling "entity" to EAP lower layer in the EAP peer?? >Now E2 wants to delegate responsibility of communicate with E1 to E3 >which it trusts. E2 can pass the DE-KEY(s) to E3 but it would be better >to derive another set of keys for that communication. > > Yes, I would prefer to see E2 derives keys for the communication between E1 and E3 >As I understand it, E2 and E1 cannot derive DE-KEY'(s) from DE-KEY(s) -- >since DE-KEY(s) are used for one purpose already and using them for >another purpose (key derivation) will make them weak. > I am not sure about this. Why will it make them weak? I mean it looks like the definition of key hierarchy. It the key hierarchy and role of participating entities are well defined... why is it weaker? > So in this case >the only way to achieve this tranasaction is to involve AAA again. This >could be very expensive. > >Another approach is to send E1 and E2 E-AMSK so that they can generate >subsequent keys to deal with this scenario. Of course you could also >send E1 and E2 DE-KEY(S) to secure their communication and also another >key derived from E-AMSK for the purpose of generating new keys. But is >that necessary? > >Why couldn't we just distribute E-AMSK. > between E1 and E2...?I am not really sure if i get your example :(. Could you provide a real scenario where this is happening? P.D: I think distributing AMSK is a possible alternative. However if in a future access, another AMSK is needed, AAA server should "request" another AMSK (derived from EMSK) to the EAP server. On the other hand, if AAA server already has a cached AMSK to generate more keys, use of EMSK is not needed (which might be an advantage if eventually it is decided EMSK needs to be removed). In the end, I think application should define its own key hierarchy from AMSK. In this way, an application could want to tranport AMSK derived from EMSK to authenticator and another ones may want to use that AMSK to create another keys to be sent to authenticators. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 13 18:10:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwBQ-00073x-I4 for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 18:10:36 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIwBP-0000hj-4h for eap-archive@lists.ietf.org; Mon, 13 Mar 2006 18:10:36 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3190F4300BE for ; Mon, 13 Mar 2006 15:10:34 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7C8C8430067 for ; Mon, 13 Mar 2006 15:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6D55B80C13F for ; Mon, 13 Mar 2006 15:10:17 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by hermes.tigertech.net (Postfix) with ESMTP id 4F33380C131 for ; Mon, 13 Mar 2006 15:10:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 9468C1FABB3; Tue, 14 Mar 2006 00:10:11 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06575-01-48; Tue, 14 Mar 2006 00:10:11 +0100 (CET) Received: from [207.3.232.120] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id AF83F1FAB98; Tue, 14 Mar 2006 00:10:06 +0100 (CET) Message-ID: <4415FBD6.2070000@dif.um.es> Date: Mon, 13 Mar 2006 18:10:14 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <441139F2.5050906@piuha.net> <4411A60C.9000602@dif.um.es> <4414767A.3030301@piuha.net> In-Reply-To: <4414767A.3030301@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Jari... >> >>I have seen during discussions and also under my understanding of >>draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be >>tranported from AAA server to some entity or 2) AMSK could be used as >>a root and cached by the AAA server to derive new keys which would be >>eventually transported to different entities. >> >>will that decision between both cases be specified for application? or >>would it be better to select one approach (it seems people like second >>one)? >> >> > >I think the practical approach would be to take one application and >specify how its done >for that. Other applications may later use the same approach or >something else, if >their requirements differ. > > Yes , that's good. As first example of 2), section 2.3 in draft-aboba-eap-keying-extns-00.txt. Maybe it would be interesting to start discussing from this application. But in any case, did you have any other in mind?. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Hugo_StarksSloan@exc.com Tue Mar 14 01:17:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2qS-0004Tv-F3 for eap-archive@ietf.org; Tue, 14 Mar 2006 01:17:24 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2qS-00069B-Ce; Tue, 14 Mar 2006 01:17:24 -0500 Received: from ip-23.net-81-220-69.rev.numericable.fr ([81.220.69.23] helo=35C9EB88) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FJ2qO-0007nu-HN; Tue, 14 Mar 2006 01:17:24 -0500 Received: (qmail 13405 invoked from network); Mon, 13 Mar 2006 22:17:54 -0800 Date: Mon, 13 Mar 2006 22:17:54 -0800 From: "Harriett" Message-ID: <380c.demur@wax78.contention36.net> To: eap-archive@ietf.org Subject: Find local sexoholics X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad We offer you a service that helps people get laid! Plenty of sex-addicts are in your region, craving to hook up! No lame pickup lines... no flowers... no walks on the beach... people here only think about sex ;) And just so you know, about 70% of our members already got some action! http://www.fecklepirates.com/bgh/ _______________________________________ fecklepirates.com/bgh/getmeoff.php From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 09:59:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAzW-0004X9-Fr for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 09:59:18 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAzV-0003gk-07 for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 09:59:18 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 207034300BC for ; Tue, 14 Mar 2006 06:59:16 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 88286430092 for ; Tue, 14 Mar 2006 06:58:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7497339804C for ; Tue, 14 Mar 2006 06:58:57 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 60C7C398012 for ; Tue, 14 Mar 2006 06:58:54 -0800 (PST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k2EEwItb004192; Tue, 14 Mar 2006 23:58:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k2EEwJxj017343; Tue, 14 Mar 2006 23:58:19 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id ZAA17312 ; Tue, 14 Mar 2006 23:58:19 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k2EEwIvL027893; Tue, 14 Mar 2006 23:58:18 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k2EEwHPZ011801; Tue, 14 Mar 2006 23:58:17 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0IW400CXMHL0IR00@mail.po.toshiba.co.jp>; Tue, 14 Mar 2006 23:58:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.60) (envelope-from ) id 1FJAyG-0005l4-Qo; Tue, 14 Mar 2006 06:58:00 -0800 Date: Tue, 14 Mar 2006 09:58:00 -0500 From: Yoshihiro Ohba Subject: Re: [eap] Strawman -10/EMSK deletion requirement? In-reply-to: To: Avi Lior Message-id: <20060314145800.GC21047@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Hi Avi, On Fri, Mar 10, 2006 at 11:50:41AM -0500, Avi Lior wrote: (snip) > > Another approach is to send E1 and E2 E-AMSK so that they can generate > subsequent keys to deal with this scenario. Of course you could also > send E1 and E2 DE-KEY(S) to secure their communication and also another > key derived from E-AMSK for the purpose of generating new keys. But is > that necessary? Why couldn't we just distribute E-AMSK. Actually this scenario is covered by Section 4.2. (Transferring CBMK) of draft-ohba-eap-channel-binding-00.txt. Yoshihiro Ohba > > > > -----Original Message----- > > From: Rafa Marin Lopez [mailto:rafa@dif.um.es] > > Sent: Friday, March 10, 2006 11:15 AM > > To: Jari Arkko > > Cc: Avi Lior; eap@frascone.com > > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? > > > > Hi Jari > > > > >First of all, I think this part of the discussion is largely just a > > >matter of vague definitions making it hard to make exact statements. > > >E.g. where is the line between AAA as a "transport" and as an > > >"application" that has intelligence to make decisions and grant > > >resources such as keys? > > > > > > > > I agree on you this. In my mind the AAA server (where EAP > > server might be co-located) is (or should be) intelligent > > enough to manage keys from users. > > > > >Just to repeat what we have already established, I think we have > > >consensus that (a) EMSK is generated by EAP methods and that (b) its > > >not going to be shipped away to the access devices. In addition, it > > >seems obvious that the document we are discussing will not > > define how > > >AMSKs are used or transported. > > > > > > > > >So the conclusion is that the EMSK is kept somewhere between the EAP > > >method and AAA transport layers. > > > > > > > > So far, between EAP methods and AAA transpor layers (AAA > > server?? ) we have EAP authenticator layer and EAP layer. An > > as specified draft-ietf-eap-keying-10.txt both layers cannot > > cache anything. I think it does not preclude the use of EMSK > > but it establishes limits to the creation of AMSK. That is, > > the AMSK should be created just in the moment the EMSK is > > exported. If EMSK wants to be cached, that part of text > > should be relaxed, no? > > > > >I would note that this means that it is, in an IETF sense, > > within a box > > >and not transported via protocols. I don't think it makes a lot of > > >sense to debate too long about what the internal structure > > of the box > > >is. I'd be happy saying that it resides in the EAP server. I > > would in > > >addition only say the following about the internal module > > structures: > > >The EMSK is not communicated either to the lower layer or the AAA > > >transport layer. > > >But AMSKs derived from it can be, > > >and that any such derivation would have to be defined in future > > >documents. > > > > > > > > I have seen during discussions and also under my > > understanding of draft-aboba-eap-keying-extns-00.txt that > > either 1) AMSK would be tranported from AAA server to some > > entity or 2) AMSK could be used as a root and cached by the > > AAA server to derive new keys which would be eventually > > transported to different entities. > > > > will that decision between both cases be specified for > > application? or would it be better to select one approach (it > > seems people like second one)? > > > > Regards. > > > > -- > > ------------------------------------------------------ > > Rafael Marin Lopez > > Faculty of Computer Science-University of Murcia > > 30071 Murcia - Spain > > Telf: +34968367645 e-mail: rafa@dif.um.es > > ------------------------------------------------------ > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 13:18:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJE3b-0007zX-Ik for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 13:15:43 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDvm-0000pM-Bz for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 13:07:39 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A29D4300B6 for ; Tue, 14 Mar 2006 10:07:38 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B65994300DF for ; Tue, 14 Mar 2006 10:06:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A50D780C11B for ; Tue, 14 Mar 2006 10:06:55 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id B2B9180C10B for ; Tue, 14 Mar 2006 10:06:39 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7C99F8988D for ; Tue, 14 Mar 2006 20:06:37 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EA96489843 for ; Tue, 14 Mar 2006 20:06:36 +0200 (EET) Message-ID: <4416D2ED.1050303@piuha.net> Date: Tue, 14 Mar 2006 16:27:57 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [eap] FW: I-D ACTION:draft-giaretta-mip6-amsk-01.txt X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Application Master Session Key (AMSK) for Mobile IPv6 > Author(s) : G. Giaretta, et al. > Filename : draft-giaretta-mip6-amsk-01.txt > Pages : 19 > Date : 2006-3-10 > >The Extensible Authentication Protocol (EAP) defines an extensible >framework for performing network access authentication. Most EAP >authentication algorithms, also known as "methods", export keying >material that can be used with lower layer ciphersuites. It has been >proposed [11] to leverage the EAP keying framework to derive >Application Master Session Keys (AMSKs) for specific applications or >services. > >This document defines how to generate Application Master Session Keys >(AMSKs) specific to Mobile IPv6. These AMSKs can be used by Mobile >Node and Home Agent to bootstrap Mobile IPv6 protocol operation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-01.txt > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 13:18:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJE3b-0007zX-SF for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 13:15:43 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDv4-0000of-Jw for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 13:06:55 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C29F14300B2 for ; Tue, 14 Mar 2006 10:06:53 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 37B2D43008F for ; Tue, 14 Mar 2006 10:06:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2DD16398031 for ; Tue, 14 Mar 2006 10:06:39 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75A72398012 for ; Tue, 14 Mar 2006 10:06:37 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6E0A589871 for ; Tue, 14 Mar 2006 20:06:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0CCDF89843 for ; Tue, 14 Mar 2006 20:06:32 +0200 (EET) Message-ID: <4416A518.6010700@piuha.net> Date: Tue, 14 Mar 2006 13:12:24 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <441139F2.5050906@piuha.net> <4411A60C.9000602@dif.um.es> <4414767A.3030301@piuha.net> <4415FBD6.2070000@dif.um.es> In-Reply-To: <4415FBD6.2070000@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.211 tagged_above=-999 required=7 tests=DATE_IN_PAST_06_12 X-Spam-Level: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 It seems that we have converged on this issue. Is there anyone who would like to suggest specific text changes? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 14:29:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFCi-0000PM-4Z for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 14:29:12 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFCg-0002zl-ME for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 14:29:12 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C85504300D4 for ; Tue, 14 Mar 2006 11:29:09 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D039343005A for ; Tue, 14 Mar 2006 11:28:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C4DA0398031 for ; Tue, 14 Mar 2006 11:28:53 -0800 (PST) Received: from exchange.bridgewatersys.com (bws14.bridgewatersystems.com [216.113.7.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8411398023 for ; Tue, 14 Mar 2006 11:28:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Tue, 14 Mar 2006 14:31:17 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZG5wOhieRh37eKTtulc8PhN3LhLAAtR05w From: "Avi Lior" To: "Rafa Marin Lopez" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Hi Rafa, In the example below neither elements E1 E2 E3 had to be an EAP Peer.=20 One real case for this is Proxy Mobile IP. The AMSK or the keys derived from the AMSK go to the Proxy Mobile IP client which is not the EAP Peer. If you need more explanation on PMIP let me know. > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 > Sent: Monday, March 13, 2006 4:39 PM > To: Avi Lior > Cc: Jari Arkko; eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > Hi Avi, >=20 > please see my comments inline >=20 > Avi Lior wrote: >=20 > >Hi Rafa, > > > >You raise a good point in the following:=20 > > > > =20 > > > >>I have seen during discussions and also under my understanding of=20 > >>draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be=20 > >>tranported from AAA server to some entity or 2) AMSK could=20 > be used as=20 > >>a root and cached by the AAA server to derive new keys=20 > which would be=20 > >>eventually transported to different entities. > >> > >>will that decision between both cases be specified for=20 > application? or=20 > >>would it be better to select one approach (it seems people=20 > like second=20 > >>one)? > >> =20 > >> > > > >I have recently seen the need for both models. IMO keeping=20 > the AMSK at=20 > >the AAA and EAP Peer and only transporting derived keys to external=20 > >entities makes a lot of sense but consider the following: > > > >Supposing I have an two entities E1 and E2 that received DE-KEY(s)=20 > >derived from E-AMSK. DE-KEY(s) are used to secure the communication=20 > >between E1 and E2. > > =20 > > > What entity is the EAP peer? At least one of the entities=20 > should be the EAP peer no?. >=20 > or are you calling "entity" to EAP lower layer in the EAP peer?? >=20 > >Now E2 wants to delegate responsibility of communicate with E1 to E3=20 > >which it trusts. E2 can pass the DE-KEY(s) to E3 but it would be=20 > >better to derive another set of keys for that communication. > > =20 > > > Yes, I would prefer to see E2 derives keys for the=20 > communication between > E1 and E3 >=20 > >As I understand it, E2 and E1 cannot derive DE-KEY'(s) from=20 > DE-KEY(s)=20 > >-- since DE-KEY(s) are used for one purpose already and=20 > using them for=20 > >another purpose (key derivation) will make them weak. > > > I am not sure about this. Why will it make them weak? I mean=20 > it looks like the definition of key hierarchy. It the key=20 > hierarchy and role of participating entities are well=20 > defined... why is it weaker? >=20 > > So in this case > >the only way to achieve this tranasaction is to involve AAA again. =20 > >This could be very expensive. > > > >Another approach is to send E1 and E2 E-AMSK so that they=20 > can generate=20 > >subsequent keys to deal with this scenario. Of course you=20 > could also=20 > >send E1 and E2 DE-KEY(S) to secure their communication and=20 > also another=20 > >key derived from E-AMSK for the purpose of generating new=20 > keys. But is=20 > >that necessary? > > >=20 > >Why couldn't we just distribute E-AMSK. > > > between E1 and E2...?I am not really sure if i get your example :(.=20 > Could you provide a real scenario where this is happening? >=20 >=20 > P.D: I think distributing AMSK is a possible alternative.=20 > However if in a future access, another AMSK is needed, AAA=20 > server should "request"=20 > another AMSK (derived from EMSK) to the EAP server. On the=20 > other hand, if AAA server already has a cached AMSK to=20 > generate more keys, use of EMSK is not needed (which might be=20 > an advantage if eventually it is decided EMSK needs to be=20 > removed). In the end, I think application should define its=20 > own key hierarchy from AMSK. In this way, an application=20 > could want to tranport AMSK derived from EMSK to=20 > authenticator and another ones may want to use that AMSK to=20 > create another keys to be sent to authenticators. >=20 > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 17:29:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJI1e-0008EE-Bb for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 17:29:58 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJI1c-00085P-VW for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 17:29:58 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2B6384300C6 for ; Tue, 14 Mar 2006 14:29:56 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C70AB43005A for ; Tue, 14 Mar 2006 14:29:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BC87780C0F6 for ; Tue, 14 Mar 2006 14:29:40 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 6B47E80C127 for ; Tue, 14 Mar 2006 14:29:30 -0800 (PST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2006 14:29:30 -0800 X-IronPort-AV: i="4.02,191,1139212800"; d="scan'208"; a="1784937150:sNHT30138120" 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 k2EMTT1j002459; Tue, 14 Mar 2006 14:29:29 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Tue, 14 Mar 2006 14:36:27 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906BDB9E3@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZHkxCSk8UYKvYoTc2XoeWqx3lbHgAIz/2g From: "Salowey, Joe" To: "Jari Arkko" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I can work on some specific proposed text for this, however it is not clear to me if this belongs in the current EAP keying document or an EMSK specific document. I'm not sure we resolved this. I think it probably belongs in its own document discussing EMSK guidelines and usage. Joe =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, March 14, 2006 3:12 AM > To: eap@frascone.com > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >=20 > It seems that we have converged on this issue. Is there > anyone who would like to suggest specific text changes? >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 20:58:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJLHI-000124-5w for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 20:58:20 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJLHG-0005nF-MA for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 20:58:20 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DA91B4300E3 for ; Tue, 14 Mar 2006 17:58:17 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 184F943004F for ; Tue, 14 Mar 2006 17:58:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0E87380C0F7 for ; Tue, 14 Mar 2006 17:58:06 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 0CE2680C0F0 for ; Tue, 14 Mar 2006 17:58:03 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2F1vxXU010949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2006 17:58:00 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2F1vvPY007869; Tue, 14 Mar 2006 17:57:59 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 17:57:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Strawman -10/EMSK deletion requirement? Date: Tue, 14 Mar 2006 17:39:18 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB842D5B24@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Strawman -10/EMSK deletion requirement? Thread-Index: AcZHkxCSk8UYKvYoTc2XoeWqx3lbHgAIz/2gAAakF8A= From: "Narayanan, Vidya" To: "Salowey, Joe" , "Jari Arkko" , X-OriginalArrivalTime: 15 Mar 2006 01:57:48.0931 (UTC) FILETIME=[DC7A4530:01C647D3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 I would agree with Joe here that the actual text (to the extent we have been discussing this) belongs in an EMSK specific document. However, there are places in the EAP keying document that state "MUST NOT cache keying materials..." - I wonder if those can be changed in accordance with the consensus we have on the topic.=20 Also, what would be the home going forward for the EAP keying extensions work?=20 Thanks, Vidya=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, March 14, 2006 2:36 PM > To: Jari Arkko; eap@frascone.com > Subject: RE: [eap] Strawman -10/EMSK deletion requirement? >=20 > I can work on some specific proposed text for this, however=20 > it is not clear to me if this belongs in the current EAP=20 > keying document or an EMSK specific document. I'm not sure=20 > we resolved this. I think it probably belongs in its own=20 > document discussing EMSK guidelines and usage. >=20 > Joe =20 >=20 > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > Sent: Tuesday, March 14, 2006 3:12 AM > > To: eap@frascone.com > > Subject: Re: [eap] Strawman -10/EMSK deletion requirement? > >=20 > > It seems that we have converged on this issue. Is there anyone who=20 > > would like to suggest specific text changes? > >=20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From jeqdvitq@esriuk.com Tue Mar 14 22:36:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMo9-0001GL-Gs for eap-archive@ietf.org; Tue, 14 Mar 2006 22:36:21 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJMo9-0000FU-DY for eap-archive@ietf.org; Tue, 14 Mar 2006 22:36:21 -0500 Received: from [201.250.79.195] (helo=VF17) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FJMo6-0005PL-VG for eap-archive@ietf.org; Tue, 14 Mar 2006 22:36:21 -0500 Message-ID: <001101c647e1$a1b20510$c34ffac9@VF17> From: "jeqdvitq" To: eap-archive@ietf.org Subject: Fw: jeqdvitq Date: Wed, 15 Mar 2006 00:36:23 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C647C8.7C64CD10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: c2e58d9873012c90703822e287241385 ------=_NextPart_000_000D_01C647C8.7C64CD10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C647C8.7C64CD10" ------=_NextPart_001_000E_01C647C8.7C64CD10 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Holcomb Johnathan=20 To: judpenplzjc@burnsmcd.com=20 Sent: Monday, March 13, 2006 10:34 PM Subject: eap-archive ------=_NextPart_001_000E_01C647C8.7C64CD10 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Holcomb Johnathan=20
Sent: Monday, March 13, 2006 10:34 PM
Subject: eap-archive

 
3D""
------=_NextPart_001_000E_01C647C8.7C64CD10-- ------=_NextPart_000_000D_01C647C8.7C64CD10 Content-Type: image/gif; name="qbamgddlga.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c647e1$a1b20510$c34ffac9@VF17> R0lGODdhwAGVAYcAAP///84AZwAA/wgAAAAAgACAgIAAAACAANEtZ0ShoTOZmd3u7kyMcu72 9hGIiMzl5YjDw6rU1FWqqpnMzCKQkGaysrvd3bzAIDt/dWiDFOFmo9czhfjd6tpEj+R3reuZ wvG71t1Vmfvu9NARcPXM4OeIt+6qzNMiev7tgxqsJoXC7Ll5Mk6QvDWvuqaaSMer+oX60NWD OHe7u8Cu4RpyCUspAxCPeR4l2CZR6JGsNv/00UB2sJJlQykslD46A11SKXZbkmuO/c1EXyzP kAHfhMGLdLuhQXU8aElz4NoLrXzlVPLjKmcgUZ5gADEWMLPmjsr9jp25pQzaMny+VmOqObBB e8JwmQBuAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA5PoQAcwAAAAAAAAAhQEAAOT6EAEFAAAABQAAALT6EAF28NF3AwcBzTAAAACF AQAApPoQAQAAAADIBZJ8cCHlAHD7EAFRBZJ8OAgHAG0Fknz+////HwAAAAAAAAAAAAAAYPsQ AQvw0XcDBwHNAAAAAAUAAAD+////HwAAAAAAAAAFAAAAhQEAACADAABYAgAAMAAAAAEAAAAB AAAADQAAABsDAAC1AAAAAAAAAEgAAAAAAAAAAAAAAMwAAAAAAAAAhQEAACADAABYAgAAGO6R fAAAAAAAAAcAAAAAAAAAAAC2IeUAHwAAAAAAAAABAAEACQAAALT6EAG2IeUAZHYACAAAAABw BZJ8/////20Fknykx9N3AAAHAAAAAAB4IeUA4D9jAnb8EAGU/BAB4wQAAHgh5QDM+xABCMfT dwMHAc3gP2MCYYEAAPz7EAHvsvF3vPsQAfiy8Xf1////AAAAAAAAAAAAAAAAAAAAAAAAAMwA AAABVmVyZGFuYQDiNyUBdvwQAeA/YwLAiCUByIglAXb8EAFhgQAAuLXvd4a173cDBwHNCgAA AJQAAABMjHIAdvwQAQsAAAAAAAAATIxyACwAAAAAwAGVAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp3qEwrVq1izat3KdamCAgUk3JQAVkHXswjBFiA4QW0F tgnUJphgUC1bt3Dl0l2oVq2DCg0I9h0MYLDhgYYLJLBwcEJcsHPrgk2beK1Au4InIwa7d+AD zArJFjC72bLAtmDfFtZ8Gu/qvn8Dv6488GtYtLhLD4zgGsAC24MVLMhsmnfqgb8TC1dY2cHw y7Qrg5YegWByw8t1H5SuvftrCgUf/ptG+LmAg4KgjRdQ/Xp37+bDpbMG4ADsg9y4MS+of7s2 WAmBNSAaadBZtt9/BNkGIAAClsWcZg08JlaBfM3XnQxggedfWAEOSBxl46FnIWizMSbQAn0t RAFY1X3oG38TUvgigtpFSKN3BBmnIX5d2dUAfwQCgFoC4XGm248ODjRkkQV0JplpDUxn4ZPb zQfakgQ91hmJLlYZIol9ESlQBSkmhGIBOx4JpIhrITkamwNFOeKUA61YwHM8bmWXbUEC8JiJ A1kAmW58MgmoQIIqlhCYrHFJ5aPQnSfQnwUlKmZ7Xi4653hqrRggmo4ShGEBMlBZKJyndokp jqKCVWqe/3pCBpakqnYn16yQ1tqlnDvSBuejDZBJKqurhjpbmTJ6pxYE6wFAJrN0DvTYfWw+ Ritx1mYqEK+/HlTepbBihV2utgZHbrLA2gZBaYR1S5y5xEoZIrvIroquWlE6gKSc8+p67JtP qtWnjA2o6+654UolMIwHJ7vwjegSWyC8ESNcmWwVFxutsfbaaxdZK4rFcccFKsAwmyZDPHFf A488csJNqbVAeQWsKy1YhwJgaWkzL5slzpUOCqLANkscr2aPgUspQTtnTDKOjK5F830u0ykz zUUX2DNYWf+rQNdOhw1zzJpBWwC1Qgp9c5PamY02lms72bC//mLmZtFwT2qk0/4c24kxt9qt qGHV/WLmtouHG634y2MrBZpo+m64YIMAJws5xgp2mCSID/ZbN2uo3Sm55pU/bToA0CoQ4GNZ hzrytJBe3p3sYof9beNUkWgngdcFh6e9uyMHHMu/I0xvvU+T+NiOvRP/brvcbUhxxiOP+qqq waOb/elGW4/7VCSe2ayS4kXmrvjsCVm+3NoO3e7RIfKXvmN6BQy9r+TXP/fIZ6aJLvr/cw3j +gaW4n3vgAi0iZ1alBMdJfCBEJxJea51E/6gLYIYzCBKPIQTBWnwgyAkiQdtwsEQmvCEKEyh ClfIwo0ooYUwjKEMZ0jDGtrwhjjMoQ53yMMe+vCHQP70iA2CGEEnEPGISERKAJbIxCYGYCBM LEgUBeLEJRbkAx1g4gY0AIKFYFGLXKRiFZt4xSwusQMfQIgJzBiADXiAA1C04kA+wEQNHGSM ZQRjFxMyRitqYIkjgONAOFDHPk4RAGPswB7jiEcxBiCNBCHBIRHZR0YaJARL3EBBNrDEECBk kpR8IiMDIAJLjnKJJwiBCQxiyFOecZGcDMAJDBJLTQ6yiYIkCChNyctQVtGVqVylFOX4SUOK MpTDPGYjBRLLXyakmU50ZCUFwgFoajGXzJwmMgVigjoWM5oDseYudTnNWhLkBJn05TINKUxp gjOUsyQIG8m5TmIORAQjWP9iO7sZgBGU8o723KY0PelIelaxA8l0pjqbKEx+BmCRACCkPgny R28m85sXdeUhDYlQejpknKAMaUArakcAiKAE+UwISQVy0pRmdJOdLKUIMNlGgsSyA4L8gEu3 yYF8BoCgfBzpEkva0mMC1KgEwedQBUJTf77UowLxACqhetSH3nKS4yyoQUoAyIH4FJJHfaoT SaDVspoAnQHoaFlZSUypypKRJY0qKPM5ArqyFam9FKheX3rWM1J1ISANqEiRuktbhnWTdzUI HdNaEDNCkp+GZalho6jUmgJWsAEFQGQTixAQMNEEi7XqU3uJ1cyOUq0VtWdW9xrOJXoAAFy1 LEb+/+rEjpYWqbFs52pvO5CKjuCcSx0IPzVQ0Xau9a963W1Ac+vVfn7UtIMdLRNDAIJ/Xvan 1VXILs0IUQB4lrEA4K52rWhOhgyWuta9rkLc6tMAlOCwYnVuXumJTpnKkrezNYgkl0gCn2KT s6Q940TxO5DvqlW5Ru2qQPYbAGF+NwBkHQh396vW4+aVwAAWiIElDF7zQteYo00tIFWpEBH3 k8QZtvA2V+tIM/62IaA08QhQHFSFcpiJFUauVkVQ0ddqNMFL5Kod/xhbINt4tSb2cY3jC+Gp YrisSVjmNnnsWuD+VCAVjSdLpwoAtKY3q9H9sY4PmcUcL/mu2rQwG5v+eIL/ynOMbR4ta1ds WoOmE8aZXTMT4/zNd151iW5WcR83m2YmiqCfSj20aqXM4vZq+cwBfiJNizxmYhZ6jJstcil9 +t6BxNbHbu20ivd6Wz/vkswdVm+Kw1wQEGjAmmYmiKthLefAipLFodyAT4E6Xrx699W1hTRC oLnZ+S50iemdc0ExiU5PPlnHBHFohHvNZJMC8tkbrfOxSVkQRT/SoelFqyAV/WgwY9bIwi5r mZ/ra1aPeiAkoKmvDxJvdwtEvLL2a3iX2N1kcoDBok63fuUtcIKw16dKhvYUzZhjBAOAwWR9 trGhvepFi9LEyP0uUB2+71QzNZM05fWDx7j/SHMT1uLp1jiHYw1f5Np7A25WMC1jLt/5LjbH jhXIzWlpyiJPO7/MpPmLW95qJoLgwcYVtBwrG3COozOeEn+31Afi5XtyuaztRbdN+T3xKXO6 IA79LEWNGdesVn3Lb+06KGO5yHXjud3nlm4AwmjSHheT7lQOQMLnHMsQyJSmkUUrTrm500M2 Ndlyx7vdgU6QnlYZAOz9r63nyMRccrzajE8xQmK7AZmasenELLLWvdt3igs0tP/N+tAdmV5v T5zzng+y6Q8JgtJTZPJUrWcia3xQzUdUnG3EJgfQqtBJorXY7rR0H1me/CmWN5uyVbpRzajl VkrfzmRsftwbAnxC/tuzvdjHcULfOUnqF8Stj9e5vt/8SO0fs/vjz/62PY5rY7N6mRzwABtn nPSC5H//NGZ6X3RGYJVHmeQB1jVJEjV3VXVI/8dE/Hddv+RbwudTcTVncxVc1oeBFld8aaZs BzGAaVWAa+VQ2JdK/baBGciAfxYA2MRcYHdnGwgAIohGaEZ+ToSCvpdEPNiDPviDQBiEQjiE RFiERqhCOXCESriETPiDKfA9PNCEUjiFVFiFVniFWJiFWriFXNiFXviFYBiGYjiGZFiGRBgF ZpiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHEEQFJ9QCeviHgBiIgjiIhFiIhniIiJiI/4q4 iIzYiI74iGNIAARwhJJoEJXIEJf4FJnYQpl4iZ04iQAgiaIIiqM4ig+xiSOBiqRYigLxiaFY iqoIiq0oi68oigMBi7FoirO4ibr4irdIiwWBi5OIir6IicCYisdYEcRIEMS4jBnkibIIjb84 jdSYE7Z4i7NoidFIi87Ii9tYjdl4EK4YjuS4iuSoEN74E844EetYjMyYjM84jNwoj+8Iju2I EJ+4jL0ojb6oiu5ojtrojudYj9QYiwQZkOX4jQF5j/a4j9vYjA95jJXIj8WYj/J4jQUJkLW4 iteoi6w4kB/Ui7sIjOOYjRkAERSJkPwIjRjZiv8IkruIkDJZkf8kOY/4qJD/mIwiuRDpSJMw GY7raItCCZApKZAZCZIU2Yk+aZQhCZESiZNMOZIqCY9LuZLwSJQj6Y1PeZOwOJA9KZMlqY8M eZBVqZFTmRBWCZRmGZVpmZUJGYxESZURtJN0+ZHg6BD5KI5xqZb4OI1r+YtbqZcEaZB3CZgt WZLvOJbn2Ja1KJgxeZZlCZiF2Y8u2ZaIGZknNJE2+ZUziZc1CZmMGYx+CZOaCZc3OZifOZlR mZOCqZg9WZQQaZqyaZmp2Y0seZSsiZr4UQUckZQaGZRyeZpkyZeYaYmJiZRQaZsHeZnK6Zjl SJyr+ZprGZvDiZmw+ZeLqZC+iY2hCUL/4/idVKmYqGmbWlmU2DieHZmcV2mThhmYnSmVhlmN 5pmdxLmTaimW0PmRItmS9NmekrmR9RmckEgV4jmghCigBhouKpCgDNqgDvqgEBqhEjqhFFqh FnqhGJqhGrqhHNqhHvqhIBqiIjqiJFqiJnqiKJqiKjQlm8IlLPol7+MlMRo98rEyxnIYmeE+ ZWI1lrEx0aKiEzEnqiIlIjKkPlqk0NEQL4qkytIonvOjPEo9PwqkEWElMCoZm5GjWrqlTJql q6Gk87KkXrqlR0oZVVIxyEOlFOGkXaqlbMqlcJqkSDqlY1qncvqlZ4qnWGqme7oWI6KnaloR miGmfdqjYfqk/4VzqHf6IHtKpoi6qHFqp3Lqp5xCqYF6EZMRpXmaqYnKp22Kp/gTp0IqqZOK qDgKqF5qqIgBqZdapWmKqqn6qmXapm9aIfbjoo8Kq6xKqoNaqrvaqg5hF4Q6p5zaqJ/6L1YK po1aAC5grG6aq3k6p1lqGnQKrJpip2Vaq7+qqZ7KqF06qoXarcfaqxNDqtbKEMkqqtRaqZ86 q9HqrXAKrmPqruPao1xarefqrFZaqev6rfsqrsfqrLD6r+UCsPFKrffqOfl6rbRKGBggqS06 pRIbqqzKrTbKJveTGM9jJfC6sB77sSAbsiI7siRbsgixBCabsiq7sizbsi77sjAbs/8mMQAb QbMyaxQDkLM2OxI7WxA6m7Mk0bMEIbRDq7MD8bNAe7Ml0bNE6xFNCwBMKxJIe7RJaxBRC7VK mxJPe7U0C7Rda7M/e7RQm7RTO7Rmi7VeS7U7G7Zia7VYexBbe7ZPm7UgEbdtW7V4K7drKxB2 y7d8u7dvi7ZnG7hm27cKAbZsS7chYbhgO7iE27h3ixBcK7c+67iSa7iSm7mKW7ea67ePW7Rs O7lwm7iiq7ZGyxCna7k+O7dzu7kXwbieG7uE27aei7myC7m0+xC4K7uVe7iuy7mR+7e367i7 u7uq+7mB27WDy7q8K7TGO7y/+xGJO7bKi7ymm7trW7W8C73/1Hu9uWu6TEu6f0u6qRu9J9S6 5vtD6Ju+JvsD7Pu+8MugDBC/M2QFFLG+QYG/O6G/Jiu+E9G0SKu9GVG2GhHA/Ku7CNy5q4u3 BIwRPgChpRsRrXvAEHG1HEHBFewQDTy2cEu5rQrA3eu9aBvAHQy6e+u1Rlu+2Ou3aTu+Iuy2 Jiy2ZEu+M3y6IHzDJVy7wArAgMu1gKvAPky7P7zCHKzDLGy2MADDJZy3wWvE33vEvbu+iKvC Keq/Tvy2FpzDyGvBQwy9EWy9vbvExOvFGuy8TxzGaKymxUvGZ4y9ZcvFT0zAX0zCWky9ZDvG dnzHZZy9Gyy8CqzGbHzFE3y8cLy9/yDcxNurxRH8xYmsuURru2l8ooscyLOLxpMcu4+syJgM xngsyFRLyZWMyKDMvSpqxcmbus4rwM2Lyssbx5rswuPLvCZsvCn8wjY8ulS8xXKcy/QrFRj8 x72cQNP7usFczMZ8zMiczMpMFQbwEM0sswYQzc8MANMsEtJczRNxzdj8E9tMEN0Ms9X8zN/c EdM8zg0RzkNhzubcstuszdRMzeIszQPRzPI8z9dsEOU8z94sEPlcEOjMz/UM0OUc0PdM0PIc 0PAczfqM0O4s0Dgg0Ao90ArNzwkdst0czv1M0fCsz+/M0fus0R2t0Rnt0R39z/ls0h4tzikN 0iXdz//sz/8srdIcPdEhnRRCAIf3HNMfLdIf/dL2TNA7Tc8H0dA13cwsgM0oDdIyHdJLXdI9 vdNPPdNRzdIWrdMk3dRYjc9TzdQ1LdU/Xc9IPdUuvdIJDdZbLdETndQ8TdJVXdRQndVuDdNe rdRdTddUTdVqPdZ2fdFnbdVq7dRsfa5/7dNwPdBaPdc0Xdd+LdZxndFLrddrHdlp3deNDdUL m9MC3dWY/dIHjc+YXdE+bdnxnNgGTdOObddMDdQpHdFfLdGpbdqWHczrfM7LjECfTRGzXdu6 vdu83du+LbMH0BQHENzBTRPFjRDHrRDJ7bLEDQDJPdzDTRDQ/dzQ3RDRPRDLnRH/2Z3dEsHd BlEDBuHdByHe0k0R3k3eIVrd2F3ezs3ez70QxR3fH7HdGIHeCWHf680Q+D3eyO0SQDCIzX3e AvHe7Z3fBj7gCF7g/a3e7X3d0z3g1U3cD17eDO7c6j3d8c3gEp7hEY7dGj7eF27h1H3dDY7h I+7gHx7dD17hD0re8p3fBH7gBd7cyn3cGX7gLz7jyG3jCZ7gMT7jPK7gQg7j4R3eQU7gJC7g OA7hBh7kGPrhRC7j2/3iJM7ePm7lOn7l/B3lWt7jWd7lQw7mXu7lOf7lYU7m7m3lTq6hZd7m EI7h/F3maC7kSM7lBVHndm7icx7jcH7mUA7mbr7lbx7i/00u40++51h+5lpO33me5mK+5HQ+ 53fu6IA+5pMe6Zj+41jO3Xxu6BKK55We6I7O6KHe5XIO6aCe6ZRu5qe+6oGu6ZBe6mteoRM+ 6NLN4opO3SD+57be4zZe5SJe5bUu4m9OA7He4YN+6rXO57xO7HeO4kmu5p7esvttEdX+205x 7eaN7dze7d7+7eAe7uI+7uRe7uZ+7uie7uq+7uze7u7+7vAe7/I+7zM0BfR+7/heEgJgEvsO sgLw7/8+EAAP8AQx8AI/8P0e8AIPAAiv8Atf8AVP8ALR8P1+8BDP8Ag/8Rev8RMv8RJR8SMB 8h0f8Rz/8Biv8BRfEBnf8QZv8f8H7/EH4fAvn/ANr/Igf/Mwf/MbL/IppPMMjxA+z/MYv/E/ H/Mqb/JFj/Qk//BC7/Mc7/QQIfQfwfMyj/JHn/RYL/VBnxBVT/Q2f/Ulj/VLX/JOD/UVL/Um tPUGofVGf/Zer/QJv/Zvr/FuL/Zkn/RxrxD7jvIef/Y5//cO3/IsL/N0X/hin/dGn/hPD/R3 P/eIj/Z2b/hFT/V3X/eRf0JqD/aav/CWf/kij/hIz/Z13/Scz/QLEfgXD/qkb/eZz/qT//qp z/WMb/qJ3/mR//h6z/ijL/d43/thr0Irf/ISr/Urn/dQH/HFz/u/T/s0L/hxr/owH/qxn/W1 r/ywv/z/e2/4nz/zmz/zft/yre/6tD/7vG/8yv/8YQ/5IKT6it/9vX/8cI/9c//+yy/52d/+ 6Z/8wh/4zs//4P/2ACEAAAABAgkONDjwoEKFCRcyRBixIUSJEh0+nJjxIsSNFQUa3Jjw40SH HSmeRJlS5UqWLV2+fCkyI0eUHWWWrEkTY8WdM0f2jHgzp06eGk/i1GmTYUiEIIsqnUlUJsWC VZ0upWr16lCqJIs+/HkQKUyyZc2eResSqcm1R5eOJeoR69yuDbfWjQqXZ1uMd5n29fiX7lTA UekuFOzVcE+/hw8XzBsXaFrKlS1fxhtU61vITa3u1Wu4ZNXMj0FuFs2RdOnP/oE7e+7cGjZn xplX23399SnBzUxRSwZ7W3ff0bl3O8acXPly5s2dP4ceXfp06tWtXyerVft27t29fwcfXvx4 8uXNn0efXv169u27Y4cfX/58+vXt38efX/9+/v39/wcwQAEHJLBAAw9EMEEFF2SwQQcfhDBC CSek0LoBKgzwQgE1bJBDAj2kCMQDByCRRJRETKnEEFlSUaEWB3oRRhRXdJGhGD3E0cSTSpwR xpd6vCzGszjE0ccaAeBRRh6BtJFIy5jcT0QnWfQPSiiNRLLJlabk8sgsXZoSyzCLxNJGL2ls 6UrK1NzSyzHdNBMmHb9c00Apz0yxyhDnTBLMGtnU/rBLI9n8kswjA40TTzqJ1DHJCxvl08VI B1VRyB0lnRPJTNEsNE5DDfUTUSUPFTNTFF/sU1NTJy30Rj5X3dRRVwO11L4+BaVTJVzbFLNX Va98FCIQER1WWDRF7VRGOJNlFtkwT1z2WWP/NLbYMgnNUlRBtb00z0V9xdXZXsM9VlFkoxT2 VkXLLdNbcEmllFZ5pz00VnoxZbTFZ7dVd9Bl3d3VXVXTHVbIGS0lVslGs22VU3zf9TfiZttd 0tdEx9RXz0T/hRbfTR0m91teQU2W5DvvtVjkcyEWGWB4eZWY2Vw3TtPHlRkOVlKaVX5ZXJ5j nrnlf33G1kJ6fQ66R5KT/u455Y5zffPadU+eOFqWkZbWYqI5jVronWFeWGuu2Q257KZDvrjp oPGT8lVT9zR454pHxbRJYDe+Ee+P26Vb2YIxzjHsltvGmtW0X5b5a1117nvwt3fMWOJ87S58 8of3dPxVDMkqevPqOvcTQtA9J33d0ukbPfQOT2e9dddfhz122WenvXbbb8c9d9KBTH1Is6iu snflgNd98eKf7BZApWsGO0jIl5fzd9Pp1nzJWGvlz1qUj/fd4f6gh9ll5JMnn3nOp6+Xcb6d du6IOr8WXvdHDZ7V7hUhjdrygS8389aPCVeY/5z0P/xRTYDzUlgCPeUvWe2NgQwz3b5gVbd3 /uGPgo3jmr6wxz3mncpc61PW1YCGNrWVD21c8iDQhia2n02LW4PrWLByBsKuraxsbwrY01jI wbLcLHO00uHcINgwj7HPWQcjmODyJbij0dBqAWRZ/yCItRjG7GCzgtThdvW3LIYPhjzs4fpI +D/4CY2JRqQY8Qz4weT58ItZyyHOSsaxBcoMiVA70dasuL0Q6vCLYIze2kjINI6ZTIQu9N4A XqDFFa6thU2UnNru2MKsjVBxNURkJPFoMzzBEZJeA+TT7FUqC4JslPGyH//cNL9TCVBLmuqb 0gxHQYzFcpXsWtQM/9bJS17MbalU4C5j+TjKAfFX6AtlMpU5ofgt/9OZz2QmNKU5TWpW05rX xGY2tblNbp6umd8DYSDj883lODCM44OOiUBHTuYI0XifVFMlA2hOjaFFnilKVVrYSSXzpbJ6 1nPkOZ9zTy/qB1spBKUo+Ymg3hGUfMLbZ0H96ClG4c156USmwNBFsD+5k5Mz3F+2KpZPlKFq lYG7HwIVGNL5BXOlx6QcTDFIsQsC7qT8ayAwDwi3l5JKhpck4AQ1mdOawvJh+gupTLMXOSI6 8qf5w+RD4ZRCWT6RkKx6YdUOp1VeUhJiZjtkHOP4QJAilGxnayQK2xjWjM5He+dC4k+j2LV7 uZOLfaxrv3LJxG2VMK0knZm8IrXErOpRZf569eFY57jJdCnUq1Gd2yQNi7TsQXJpH33jVifp 1K0a1aKWRVxfNanZcAZWjKCcLAvXKEjEZRKu+DxrJCHrPbaOtrKMnN6+QkvHM+GQjsADqx3h NcjM8u1TvcVtcJV7WhW29rJsrBqo8tdaq6a2nkV95SdtqSV5CvOHMw0srJaYxrABrpWZe971 tLddlppUa1hVH3Z1WtfnpXe+yH1vd296QaV2c5wYHRF2hgCfokXUvwvaYGUS/B8D3/ZHB4Zw hCU8YQpXGEMIsHCGNfy50kqIUOy82/YaLDcOb9jBtHVQiDGjYuhKr589XLBbAWrihaJ4dTVG 5ztbLFCJqi6g9/4Z8TJTdUTBJrGjjVNXKY+JPVTVipUq3S+Sf/lS9/Z3rzotoJTJaOWAmrSU +muyUL1YZaTGmIOiFWv6wkpV3hKXspm8KmiHikav1rHOdiZetKT15jf/WGrj6laQS4dm6j4y uC6lM1cld0ch+q+YtfXkIxH9qz5X2rE5svPlzFtjuxrZs9IkdHO3KEncotavIzzZakO4WtHG 2ZK2pXOkY/tKG5K6w4yl77UEjaFQJ26utj4kIRXt61Sf2rqtLrZsS2jphJIpzRNbrhNXSNeE 8nDIpMzuSr0L07v+8b7CVufeyqxBlOb3pAYU85ChDNg+U9lwZHZb5fT77fEmddcR+v9m6u5N Ywbz+8X6/B09/b27gRfc4AdHeMIVvnCGN9zFEt63gh8U8RXreOKAvTUUdSXmpH5aYOX+M3i5 3NaM61Pg5nM2RQtoZs/Gj+I5Zl/5lIfjf5eaiqo7bsoqeU9ARcfljfT2QR3q4w3h0uIz52hP NWq8Q/PTkMIlMbaXbFR4QzXcVlJlglO+25CHSuqLtXd9tV0/cJHd3vS7erkxvlQlxtzG8Cz7 yYdI07mbVs7Nmm6dqY3LdkutWG9VXJ4KG7HEMh3Yx6YWrL3d3OtS2u2Bz3V064XAuKm8pHAj rM6Hi9gdOtbXD1WvpyO45ZxFVo4eFyRTrYsEYGtc1pv2s0H+RZxRFuud9l0Hu92j3tlWVxeZ eQ/fa3EN+UAT+/R4ZfXhawtdVRu26DafWiJn3XfeA73Z00+u8mMO/JvlfPEkv+UfgYt928+Z k4rnfsmBzFMqy5xwU9ZyP0GOayaL3W9Jv7KmrU+9KCN064w/KPXJm69zKtUzN/37OiyCnO/C q9l5udtpsAccKIeTjmZCAWcKMglsJwrkwA70wA8EwRAUwRG0E+x4ue47HwWpvYlKwX7jMQXT QLcCP6UTp/vhoxRcpxkcOYCjoSo7Oplrwcb7QYlTv4nTwaFbusTrOBfLwSKsNnuKvkJ7Ox2c Qlt5sHKiQgSrFLPjPfiiwRmTNiL/o64iM7J8crLeGqwn8yfrWa+swypx40KEiUMD5LJrUzJu uylHqSkmWzlyOzKVaIIP8b0kwqS9O79eArusOrXiShqMM6byK0DtIjzmoxHwQTz0UzNIFJdo qyLVisHmsLotGy1diiBhq5Yp6pdkA7fJE8W9Er5WocM8GprI8SgGdCAUokM34zrJezVeTL22 c71oiqKxgaG9A0MnkitVXETgkypDG8PbKz/e8StRREHzW0XGusRBfL3Oc8LnuzP80i3eqrtw mi1Xu8Zh+79XtK5cA6tt9Jrks0Zmgzpf3ETtg75hvDj0wrz5Cy9x60d/1LUcajd1irJHQ8AD XLX3m0Ul/wJIVwQvMxSvg1RI8oqpsasoMJsapqK6WRIyEjyxGvRI5/jEkMS/FyTJENSBk1TJ lWTJlmyJG3DJmNySzRLJmpPJmyRCFsRCncTJnnwfnkwO8PFJhePDytlDkNtCghQ1+CMqmbIc PRwmuRvKbVIjtDrEWiOtVTyhr9I+JJxKa2K3nGvDyMK0tAKZZfsqzvvGr+ym7nI+3WssxmFG utMqPYLHYWNLbeI5ERqgrkJLrfxLZFu+kczLzQnLwAEzpmTKimwljIw7m9IZx4y9wqTMiqvM y0wQwsTMzeTMznydGfDM0BTN0STN0jTN05QOJkDN1WTN1nTN14TN2JTN2aTN2v+0zdvEzdys JiLQzd70zd8EzuAUzuEkzuKMzQswztg0ieRkzdxYTrXgCuJwTtMwDtx4De3gjd6QjdlYDOzc idN4C+Y0kOlMC7aIDJ84T93gC7dIz7FIjNTgjfAUT8qQAurYio9wztvAid+wCOS4itBIjLuI i/U0CuD4zqBA0OGYz/u4z6kgUAFVjO5MUAkdUAWFCwjFUPY0CqcgjAXVjwfdixCdjOr8CxIt jcLwTtDQz7oICdS4CA6dUA/tDxBF0bkwzxdl0QMFjt9YThq10RPVUfCcDBllUBf90QLtT/YE 0CT9ive00MGgUCcN0qZQUCKlD984UiaNDa64UPRMT+T/GNIuFdHa0NAOlQsrZdCu4M/tJA2R MI4LFQ44rU71XFPHcNP8/IwUzU7/XAw09dM/VQv3ENRBJdRCRQ9ARdRErZ0VIIsYUNRHhdRI ldRJfVTNvA4DG8mG6p5/s9Rnki5igppbTLFN7bEqRDqTXCiIMrFwDLooZJAmpDmg9MYgxLmc zLBXnES/dEN+jMorqjel8rKRYsWOUsp/fMg5TMyrAyaVq6FJgUyleyE1dMT9ciWbUam1sza4 7JSxNDrGg7O7PLZyzD2Q2j9NvDNmi7ZsTLbBMy57fEQ8w8BTQiWaaT4NwidgvMdDSz/h8j9K dDzdu7lapKL0yzxTS0ZuvErE/9KrSevU53s6XL1GCSK/fG29fX2tfm1XFQI8Riw+QONLf5Wi 0kPYIVI1/MLLbA05uto5Y5tYbaxYl9XWcl2urTQ1Myo1bNw+qzKCUhzEeaQ+7vlU6VpWzfJD +2q2eNvVTiLDcOE5KEvaowS6M7TZb+vHioS7+5M2/lKybvNKyswz6mhYSn2dr61AsTXbs0Xb tFXbtWVbBOtGkJRVU43bUkUdocy4YpW+JJwOsl24Ecu3LHxb4tvJWO1awTXFxzNcVP1Av7XM yZzbIazJmivctsozJIyosD0e95rI+NM2/hrWMuRCqyUz+Qqz8TK7nUo6iEy7gpw69iKpBlI7 OUxWVv/CKXfj1WzqvcHkyox1R3TsyuFy1+W7WbPsMlvrXWWcqsAEXms8sNw9rFzcPIRJNFyk Ro0j2VQM3n99ts/LO1GNl/IC2Xozq3PdXVjsouZd3uGNRsPLWEm7Oyni3ey9S/Xl2Oo1x+bD R4BVrfR1I6mEJudNV/6txPCdXs17Ik7MRvqdS3DFROFN3lEsXz6DMM3FvGUtXdZVPFh6VtGr PNJF2h0a3QZkKVnkF4wd4S8kxbFjvxN+3hOCv4GD1bFt21clVdfB3BnG4ZUoghzm4R724R++ zRgGRbkFYs/5sBqewMCF3CIGpytU3A1UYr1lYrZbtyyz3YJUyzoilqQ04fqbed2NREovbKn2 ul0A6IEeJtjfJV82S0SQda4FHMYbemCZ2YHhfIL/CkaKzdW6ZK2D/b65czRX1V6x3EXXu+He lDXdpUclDNk2Pi2VLbzRE942jC8mTuN4xOTc6tnN2jPmcpoE7ku6POTavEPoTUCtHcC1KpVq 49pVKakXVsCqjcrEneKyBdxaPrhUzssgwOVe9uVfBuZgFmYBCQgAOw== ------=_NextPart_000_000D_01C647C8.7C64CD10-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 22:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJN75-0000q9-Lg for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 22:55:55 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJN74-0000k8-8c for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 22:55:55 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6EA2543009A for ; Tue, 14 Mar 2006 19:55:53 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D5F51430063 for ; Tue, 14 Mar 2006 19:55:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C34A8398041 for ; Tue, 14 Mar 2006 19:55:38 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7B7F39804D for ; Tue, 14 Mar 2006 19:55:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 8747623CA0C; Wed, 15 Mar 2006 04:55:33 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30518-01-22; Wed, 15 Mar 2006 04:55:33 +0100 (CET) Received: from [192.168.2.5] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 6152623C9FE; Wed, 15 Mar 2006 04:55:27 +0100 (CET) Message-ID: <44179034.9080608@dif.um.es> Date: Tue, 14 Mar 2006 22:55:32 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <441139F2.5050906@piuha.net> <4411A60C.9000602@dif.um.es> <4414767A.3030301@piuha.net> <4415FBD6.2070000@dif.um.es> <4416A518.6010700@piuha.net> In-Reply-To: <4416A518.6010700@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Jari Arkko wrote: >It seems that we have converged on this issue. Is there >anyone who would like to suggest specific text changes? > > Hi Jari As I commented in a previous e-mail, I think this paragraph in section 2.2 (page 14) should be relaxed if we consider EAP peer / EAP authenticator layer or EAP layer could be in charge of creating AMSK and also if we consider EMSK could be cached in those layers. "The EAP peer and authenticator layers MUST NOT modify or cache keying material or parameters (including Channel Bindings) passing in either direction between the EAP method layer and the EAP layer. The EAP layer also MUST NOT cache keying material or parameters (including Channel Bindings) passed to it, whether by the EAP peer/authenticator layer, the lower layer or the AAA layer." Additionally, that paragraph seems a bit contradictory with this in page 15. "The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.)" Could we say ... "The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties." ? > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 14 23:25:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJNZp-0005xi-9o for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 23:25:37 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJNZn-0001gQ-TW for eap-archive@lists.ietf.org; Tue, 14 Mar 2006 23:25:37 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8393E4300DA for ; Tue, 14 Mar 2006 20:25:35 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D1A14430063 for ; Tue, 14 Mar 2006 20:25:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BA2AE398052 for ; Tue, 14 Mar 2006 20:25:19 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by zoidberg.tigertech.net (Postfix) with ESMTP id CD415398053 for ; Tue, 14 Mar 2006 20:25:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id C0E8C1FA954; Wed, 15 Mar 2006 05:25:16 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06346-01-43; Wed, 15 Mar 2006 05:25:16 +0100 (CET) Received: from [192.168.0.4] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id AB0171FA92E; Wed, 15 Mar 2006 05:25:15 +0100 (CET) Message-ID: <44179734.10806@dif.um.es> Date: Tue, 14 Mar 2006 23:25:24 -0500 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [eap] Strawman -10/EMSK deletion requirement? References: <7210B31550AC934A8637D6619739CE6906BDB9E3@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906BDB9E3@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Salowey, Joe wrote: >I can work on some specific proposed text for this, however it is not >clear to me if this belongs in the current EAP keying document or an >EMSK specific document. I'm not sure we resolved this. I think it >probably belongs in its own document discussing EMSK guidelines and >usage. > > I think having a EMSK guidelines and usage document might be useful. Regards. >Joe > > > >>-----Original Message----- >>From: Jari Arkko [mailto:jari.arkko@piuha.net] >>Sent: Tuesday, March 14, 2006 3:12 AM >>To: eap@frascone.com >>Subject: Re: [eap] Strawman -10/EMSK deletion requirement? >> >>It seems that we have converged on this issue. Is there >>anyone who would like to suggest specific text changes? >> >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/eap >> >>Arhives: http://lists.frascone.com/pipermail/eap >> >> >> >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From EMINEMckln@yahoo.dk Wed Mar 15 03:18:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJR9G-0003pX-70 for eap-archive@ietf.org; Wed, 15 Mar 2006 03:14:26 -0500 Received: from flt-196-229.kyoto-inet.or.jp ([163.208.196.229] helo=4C03C60) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJQwU-0007Tr-1y for eap-archive@ietf.org; Wed, 15 Mar 2006 03:01:16 -0500 Received: from basophobia-bestialism.yahoo.gr (burd-Aladinist.yahoo.gr [yahoo.gr]) by archdevil-Caro.yahoo.gr (5.13.8/5.13.8) with ESMTP id i95OrVjNk22442 for ; Wed, 15 Mar 2006 13:52:13 +0600 Date: Wed, 15 Mar 2006 13:58:13 +0600 From: "Donnell" Message-ID: <186.23e247d5.2a9UGZ44@yahoo.gr> To: eap-archive@ietf.org Subject: Re[1]: X-Mailer: Ximian Evolution 2.2.5 (2.1.3-7) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi eap-archive@ietf.org, P@in R3lief (from $99)(W!co din, Hydro One, Value Ms). Large selection of M3DS, even the ones that are hard to find. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D copy the address below and paste in a your web browser: beautician.beecomrad.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Who lived in a shoe.. And Dollie -- gone!. Yet shining like the sun with love's true light.=20. Look ever upward at the sun and the stars.=20. Now, through my children, young and free,=20. TTYL, Theresa Hogan From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 16 23:04:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6Ca-00075J-3b for eap-archive@lists.ietf.org; Thu, 16 Mar 2006 23:04:36 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK6CV-0007Pt-PM for eap-archive@lists.ietf.org; Thu, 16 Mar 2006 23:04:36 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C85F84300F8 for ; Thu, 16 Mar 2006 20:04:30 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1272C43005F for ; Thu, 16 Mar 2006 20:04:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0057480C0FE for ; Thu, 16 Mar 2006 20:04:17 -0800 (PST) Received: from hotmail.com (bay106-f19.bay106.hotmail.com [65.54.161.29]) by hermes.tigertech.net (Postfix) with ESMTP id 0DF4C80C005 for ; Thu, 16 Mar 2006 20:04:14 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Mar 2006 20:04:13 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 17 Mar 2006 04:04:09 GMT X-Originating-IP: [131.107.0.88] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 16 Mar 2006 20:04:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Mar 2006 04:04:13.0730 (UTC) FILETIME=[DA324020:01C64977] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Re: EMSK language change X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Rafa Marin Lopez said: "Could we say ... The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties. ?" I think you also need to state that the EMSK MUST NOT be used directly (such as to encrypt data). _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 16 23:30:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6bv-0006YN-9g for eap-archive@lists.ietf.org; Thu, 16 Mar 2006 23:30:47 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK6bs-0008EO-RT for eap-archive@lists.ietf.org; Thu, 16 Mar 2006 23:30:47 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 835654300D2 for ; Thu, 16 Mar 2006 20:30:44 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5F8B043005F for ; Thu, 16 Mar 2006 20:30:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5011280C12B for ; Thu, 16 Mar 2006 20:30:31 -0800 (PST) Received: from hotmail.com (bay106-f30.bay106.hotmail.com [65.54.161.40]) by hermes.tigertech.net (Postfix) with ESMTP id 1F7CB80C005 for ; Thu, 16 Mar 2006 20:30:28 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Mar 2006 20:30:27 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 17 Mar 2006 04:30:24 GMT X-Originating-IP: [131.107.0.88] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 16 Mar 2006 20:30:24 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Mar 2006 04:30:27.0733 (UTC) FILETIME=[84600C50:01C6497B] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Re: m.getKey() and RFC 4137 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Narayanan, Vidya said: "I am surprised that you are willing to accept (a) :) Given how many legacy methods are still in use, I'd strongly vote for (b) here. It is impractical to make changes to methods to accommodate the use of EMSK/AMSK. As you point out, what we pick here may depend on whether we pick (1) or (2) below - and (1) makes much more sense to me for reasons stated below". I agree with this. Changing EAP methods to negotiate KDFs would in practice be very difficult -- even if the industry were willing to do the upgrades (which they probably wouldn't be). In practice, TLS (on which many methods are based) does not support KDF negotiation for its own use, let alone negotiation of KDFs to be used to generate AMSKs. Attempting to convince the TLS WG to add support for cryptographic negotiation for ancillary purposes would be an uphill battle that seems unlikely to succeed. Jari said: "Based on this my current preference is (1). But its a close call." I've just re-read RFC 4137, and it seems to me that choice 2 is fairly well ingrained in that document. RFC 4137 describes the state machine interface between EAP and lower layers. This includes the transfer of keys from the EAP layer to the lower layer, via the eapKeyData structure. Various functions are defined that provide support for this structure for use in EAP key management. This includes eapKeyData (EAP key) (set during METHOD state), eapKeyAvailable (boolean), and m.getKey(), the method procedure used to obtain keying material for the lower layer. Therefore RFC 4137 provides the structures, state machine and functions for transference of EAP keying material and parameters from the EAP method to the lower layer. The state machines described in RFC 4137 make no distinctions relating to availability of individual elements. The keying material is provided as a unit (the EAP Key structure) to the lower layer, and the state machine transitions reflect this. There is no notion of "partial completion" with respect to key transfer, and in fact this is not possible. In RFC 4137, the key structure is available, or it isn't. eapKeyAvailable is defined as a boolean, and therefore if the keys are only partially available, then all variables and functions which depend on this variable become undefined. So from what I can tell, RFC 4137 requires that all keying parameters be transferred as a unit. This assumption permeates the entire document, as well as lower layer standards that are based on it. Given this, I wonder whether the horse hasn't already left the barn. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 01:19:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK8JC-0005QO-VW for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 01:19:34 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK8J7-0002Oz-Hd for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 01:19:34 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3822C43006D for ; Thu, 16 Mar 2006 22:19:29 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BD39A43005F for ; Thu, 16 Mar 2006 22:19:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A49AB398028 for ; Thu, 16 Mar 2006 22:19:15 -0800 (PST) Received: from hotmail.com (bay106-f8.bay106.hotmail.com [65.54.161.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id F04F9398027 for ; Thu, 16 Mar 2006 22:19:12 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Mar 2006 22:19:12 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 17 Mar 2006 06:19:08 GMT X-Originating-IP: [131.107.0.88] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 16 Mar 2006 22:19:08 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Mar 2006 06:19:12.0487 (UTC) FILETIME=[B56E7F70:01C6498A] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Re: transport of EMSK X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Jari Arkko said: (2) In the lower-layer based EMSK processing approach, the EMSK is delivered to the authenticator along with the MSK. KDF is selected either (a) by a default in EAP plus optional negotiation in methods, choice is communicated to the lower layer via AAA or (b) by lower layer negotiation alone. The lower layer is responsible for all use of the AMSKs in a local context. That is, no AAA key requests are needed or possible." RFC 3748 is fairly clear that transport of the EMSK is not allowed. From Section 1.2: The EMSK is not shared with the authenticator or any other third party. With respect to the handling of keys within EAP as well as AAA, RFC 4137 defines separate variables for the key structure within the EAP peer & server (eapKeyData) and on the authenticator in the passthrough case (aaaEapKeyData). So as far as I can tell, providing the EMSK to the lower layer on the EAP peer and server does not necessarily imply that it is transported via AAA to the authenticator. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From marry@yandex.ru Fri Mar 17 06:22:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKD2H-0002JX-JP for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 06:22:25 -0500 Received: from 220-139-143-140.dynamic.hinet.net ([220.139.143.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKD24-0002ss-SF for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 06:22:25 -0500 Received: from nitpick.saloon.com (cunningham [53.221.128.199]) by onus.com (picket) with sweaty id 0560928524641 for ; Fri, 17 Mar 2006 17:46:23 -0500 Date: Fri, 17 Mar 2006 14:57:16 -0500 Message-Id: <4156717883390700098907554@microsoft.com> From: Margaret Reeves To: eap-archive@lists.ietf.org Subject: Your family Content-Type: multipart/mixed;boundary="------=006192319830634" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d --------=006192319830634 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit Make her worship you!

Increased sexual desire - Enhanced libido.

Worldwide shop
All I need to make a comedy is a park, a policeman and a pretty girl. --------=006192319830634 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The mind has its own logic but does not often let others in on it.Difficulties are stepping stones to success. --------=006192319830634-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 13:35:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJnZ-0003AQ-F8 for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 13:35:41 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJnY-0000d9-0L for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 13:35:41 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1C46A43007C for ; Fri, 17 Mar 2006 10:35:39 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 45E6F430054 for ; Fri, 17 Mar 2006 10:35:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2542480C0F5 for ; Fri, 17 Mar 2006 10:35:21 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 8A57980C120 for ; Fri, 17 Mar 2006 10:35:16 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2HIZEcA017257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 10:35:14 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2HIZ1BA020438; Fri, 17 Mar 2006 10:35:13 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:34:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 10:34:37 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F8F8@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylw From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 17 Mar 2006 18:34:55.0876 (UTC) FILETIME=[7CF11C40:01C649F1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Bernard, >=20 > Narayanan, Vidya said: >=20 > "I am surprised that you are willing to accept (a) :) Given=20 > how many legacy methods are still in use, I'd strongly vote=20 > for (b) here. It is impractical to make changes to methods to=20 > accommodate the use of EMSK/AMSK. As you point out, what we=20 > pick here may depend on whether we pick (1) or (2) below -=20 > and (1) makes much more sense to me for reasons stated below". >=20 > I agree with this. Changing EAP methods to negotiate KDFs=20 > would in practice be very difficult -- even if the industry=20 > were willing to do the upgrades (which they probably wouldn't=20 > be). In practice, TLS (on which many methods are based) does=20 > not support KDF negotiation for its own use, let alone=20 > negotiation of KDFs to be used to generate AMSKs. Attempting=20 > to convince the TLS WG to add support for cryptographic=20 > negotiation for ancillary purposes would be an uphill battle=20 > that seems unlikely to succeed. >=20 > Jari said: >=20 > "Based on this my current preference is (1). But its a close call." >=20 > I've just re-read RFC 4137, and it seems to me that choice 2=20 > is fairly well ingrained in that document. >=20 > RFC 4137 describes the state machine interface between EAP=20 > and lower layers.=20 > This includes the > transfer of keys from the EAP layer to the lower layer, via=20 > the eapKeyData structure. > Various functions are defined that provide support for this=20 > structure for use in EAP key management. > This includes eapKeyData (EAP key) (set during METHOD state),=20 > eapKeyAvailable (boolean), and m.getKey(), the method=20 > procedure used to obtain keying material for the lower layer. > Therefore RFC 4137 provides the structures, state machine and=20 > functions for transference of EAP keying material and=20 > parameters from the EAP method to the lower layer. >=20 > The state machines described in RFC 4137 make no distinctions=20 > relating to availability of individual elements. The keying=20 > material is provided as a unit (the EAP Key > structure) to the lower > layer, and the state machine transitions reflect this. There=20 > is no notion of "partial completion" with respect to key=20 > transfer, and in fact this is not possible. =20 > In RFC 4137, > the key structure is available, or it isn't. eapKeyAvailable=20 > is defined as a boolean, and therefore if the keys are only=20 > partially available, then all variables and functions which=20 > depend on this variable become undefined. >=20 > So from what I can tell, RFC 4137 requires that all keying=20 > parameters be transferred as a unit. This assumption=20 > permeates the entire document, as well as lower layer=20 > standards that are based on it. >=20 > Given this, I wonder whether the horse hasn't already left the barn. >=20 Are you saying then that in accordance with 4137, the EMSK will also be delivered to the AAA layer on the EAP server?=20 Regards, Vidya=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 13:49:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKK0n-000559-1y for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 13:49:21 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKK0m-0000ue-LP for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 13:49:21 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 409B84300D1 for ; Fri, 17 Mar 2006 10:49:20 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 18AC4430054 for ; Fri, 17 Mar 2006 10:49:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F0F0880C14C for ; Fri, 17 Mar 2006 10:49:04 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 9CCBB80C008 for ; Fri, 17 Mar 2006 10:48:54 -0800 (PST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 10:48:55 -0800 X-IronPort-AV: i="4.03,105,1141632000"; d="scan'208"; a="1785938436:sNHT33412408" 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 k2HImr1j009080; Fri, 17 Mar 2006 10:48:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 10:55:53 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906BDC13D@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJfIbYyN8EZq5SSfSagwf3w8JIOQAdimOQ From: "Salowey, Joe" To: "Bernard Aboba" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, March 16, 2006 8:30 PM > To: eap@frascone.com > Subject: [eap] Re: m.getKey() and RFC 4137 >=20 > Narayanan, Vidya said: >=20 > "I am surprised that you are willing to accept (a) :) Given how many > legacy methods are still in use, I'd strongly vote for (b) here. It is > impractical to make changes to methods to accommodate the use of > EMSK/AMSK. As you point out, what we pick here may depend on=20 > whether we > pick (1) or (2) below - and (1) makes much more sense to me=20 > for reasons > stated below". >=20 > I agree with this. Changing EAP methods to negotiate KDFs=20 > would in practice > be very difficult -- even if the industry were willing to do=20 > the upgrades > (which they probably wouldn't be). In practice, TLS (on=20 > which many methods > are based) does not support KDF negotiation for its own use, let alone > negotiation of KDFs to be used to generate AMSKs. Attempting=20 > to convince > the TLS WG to add support for cryptographic negotiation for ancillary > purposes would be an uphill battle that seems unlikely to succeed. >=20 [Joe] If anything, this statement argues for the method to define the KDF based on the cryptographic operations it supports. =20 > Jari said: >=20 > "Based on this my current preference is (1). But its a close call." >=20 > I've just re-read RFC 4137, and it seems to me that choice 2 is fairly > well ingrained in that document. >=20 > Given this, I wonder whether the horse hasn't already left the barn. >=20 [Joe] RFC 4137 did not consider the usage of the EMSK, therefore I don't think the horse was ever in that barn. =20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 14:03:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKEr-0006h9-Tf for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 14:03:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKEq-0001XY-Ey for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 14:03:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2624D4300E7 for ; Fri, 17 Mar 2006 11:03:52 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B620E430054 for ; Fri, 17 Mar 2006 11:03:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A78193980AE for ; Fri, 17 Mar 2006 11:03:40 -0800 (PST) Received: from hotmail.com (bay106-dav11.bay106.hotmail.com [65.54.161.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0EF123980AC for ; Fri, 17 Mar 2006 11:03:39 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Mar 2006 11:03:38 -0800 Message-ID: Received: from 131.107.0.104 by BAY106-DAV11.phx.gbl with DAV; Fri, 17 Mar 2006 19:03:36 +0000 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Narayanan, Vidya'" , Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 11:03:37 -0800 Message-ID: <000701c649f5$7f2d05b0$888a3b9d@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8435F8F8@NAEX06.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOA= X-OriginalArrivalTime: 17 Mar 2006 19:03:38.0722 (UTC) FILETIME=[7FD68C20:01C649F5] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > So from what I can tell, RFC 4137 requires that all keying > parameters be transferred as a unit. This assumption > permeates the entire document, as well as lower layer > standards that are based on it. > > Given this, I wonder whether the horse hasn't already left the barn. > Vidya said: "Are you saying then that in accordance with 4137, the EMSK will also be delivered to the AAA layer on the EAP server? " That's how I read it, yes. The keying material and parameters are passed via the eapKeyData structure to the lower layer (which would be the AAA layer on the EAP server when in passthrough mode), via the m.getKey() function. The AAA layer then fills in the aaaEapKeyData structure and passes this to the authenticator. While both eapKeyData and aaaEapKeyData are of type "EAP Key" there doesn't appear to be a presumption that they are the same. So the AAA layer could receive the EMSK, but not pass it to the authenticator. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 15:11:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLIY-00087U-5w for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:11:46 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLIW-0004EP-7R for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:11:46 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 76D654300C6 for ; Fri, 17 Mar 2006 12:11:42 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7BAB9430054 for ; Fri, 17 Mar 2006 12:11:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6526C80C008 for ; Fri, 17 Mar 2006 12:11:17 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by hermes.tigertech.net (Postfix) with ESMTP id D0CC480C13F for ; Fri, 17 Mar 2006 12:11:14 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i31so662871wra for ; Fri, 17 Mar 2006 12:11:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GZtyQpKdz4/cirt5bD7P7l605ghhyULL3U/5o1dxs6HeVWT2UXPogto/CD0kafQuC09t+LusgEH56qj9WwnaEwXGcuXeld2WVqlILBZd1RK1A/sD5YreHLBEfJp/LLU/Kblfz5sZ4rdX7N2c06QvEhM9wTl6/vTXUJoZSHq+gxg= Received: by 10.64.210.2 with SMTP id i2mr480583qbg; Fri, 17 Mar 2006 12:11:13 -0800 (PST) Received: by 10.65.61.12 with HTTP; Fri, 17 Mar 2006 12:11:13 -0800 (PST) Message-ID: <5bfe7a820603171211l72542fbs104e98459561c028@mail.gmail.com> Date: Fri, 17 Mar 2006 12:11:13 -0800 From: "Dorothy Stanley" To: "Narayanan, Vidya" Subject: Re: [eap] About use of EMSK In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB841B07FF@NAEX06.na.qualcomm.com> MIME-Version: 1.0 References: <2EBB8025B6D1BA41B567DB32C1D8DB841B07FF@NAEX06.na.qualcomm.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.045 tagged_above=-999 required=7 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: * Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0639043487==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 --===============0639043487== Content-Type: multipart/alternative; boundary="----=_Part_4755_28654021.1142626273112" ------=_Part_4755_28654021.1142626273112 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Vidya, Jari, >Given how many >egacy methods are still in use, I'd strongly vote for (b) here. It is >mpractical to make changes to methods to accommodate the use of >EMSK/AMSK. I strongly agree with Vidya here. The usage of EAP keys by existing methods, such as EAP-TLS which are widely used, particularly in 802.11 systems should be described and accommodated in the document. It is impractical and extremely undesirable to make these existing methods non-compliant with the framework document. My understanding was that the keying framework document would largely describe EAP keying usage as implemented today, while specification of EMSK and AMSK usage would be in a separate document, such as an EAP key extensions document. Why is this changing, particularly in WGLC? Thanks, Dorothy Stanley On 3/6/06, Narayanan, Vidya wrote: > > Hi Jari, > Thanks for the much needed analysis on this topic. Please see some > comments below. > > > > > > > Here's some analysis of the server vs. lower-layer based EMSK > > processing approaches. > > > > (1) In the server based approach we keep the EMSK in the > > server (perhaps just for a moment) and generate the AMSKs, > > which are given to the the different applications, such as > > fast handoff mechanisms. > > The use of these applications goes via AAA, e.g., some kind > > of key requests or fast re-auth requests can be sent from > > NASes to the server. The AMSKs are derived using a KDF which > > is decided either (a) by a default plus optional negotiation > > in methods or (b) by lower layer negotiation and having AAA > > tell the server which KDF to use. > > > > (2) In the lower-layer based EMSK processing approach, the > > EMSK is delivered to the authenticator along with the MSK. > > KDF is selected either (a) by a default in EAP plus optional > > negotiation in methods, choice is communicated to the lower > > layer via AAA or (b) by lower layer negotiation alone. > > The lower layer is responsible for all use of the AMSKs in a > > local context. That is, no AAA key requests are needed or possible. > > > > Discussion about the chosen approach for EMSK use has so far > > appeared to assume 1a vs. 2b. Based on the above, it seems > > that the KDF negotiation may be a separate issue from who > > maintains the EMSK and calculates AMSKs. > > In the following I'll try to analyze these issues. > > > > The KDF negotiation is indeed problematic almost no matter > > what we do. Requiring new funtionality in methods is in > > practice often a non-starter; while we can develop new > > methods and update old ones, it is expected that most of > > current usage will continue to use the existing methods. > > Having a default does not help much either, if the default > > becomes broken in the near future. > > But requiring new functionality in link layers it not always > > easy either. It would be easy when we are developing a new > > link layer and including some EMSK usage as a part of that. > > But if we were to use EMSK for some new function over 802.11, > > for instance, would there be enough incentive to extend > > 802.11 just to make this possible? > > > > The choices and their implications are: > > > > (a) Specified default, optional negotiation in EAP methods. > > > > This implies an interface either from methods to the > > AAA/EAP server > > code (for solution 1) or AAA protocol extensions for > > solution 2. > > > > Changes in peers, servers, methods, possibly AAA protocols. > > > > (b) Lower layer negotiation. > > > > If used together with solution 1, implies AAA protocol > > extensions > > to communicate the KDF. If used with solution 2, implies AAA > > protocol extensions to carry the EMSK. > > > > Changes in lower layers, AAA protocol. No changes in > > EAP or methods. > > > > Based on this my current preference is (b). I'd be willing to > > accept (a), too. > > > > I am surprised that you are willing to accept (a) :) Given how many > legacy methods are still in use, I'd strongly vote for (b) here. It is > impractical to make changes to methods to accommodate the use of > EMSK/AMSK. As you point out, what we pick here may depend on whether we > pick (1) or (2) below - and (1) makes much more sense to me for reasons > stated below. > > > > The choice between server or lower-layer based EMSK > > processing depends on security implications and ease of use > > for different purposes. > > The choices are: > > > > (1) Derive AMSKs at the EAP/AAA server. > > > > Implies a AAA protocol extension to retrieve AMSKs. > > > > Changes at the EAP/AAA server, authenticator. New, stateful > > nature of the EAP/AAA server. > > > > (2) Derive AMSKs at the lower layer. > > > > Implies a AAA protocol extension to carry EMSK to the > > authenticator. > > > > Small changes at the EAP/AAA server, main functionality in > > the authenticator. > > > > Hard to see how other nodes than the authenticator would > > actually use the AMSKs. Traditionally, NAS -> NAS communication > > has not been easy compared to NAS -> AAA communication. > > > > Based on this my current preference is (1). But its a close call. > > I agree that (1) makes more sense. In many cases, the AMSKs are slated > for use to bootstrap protocols such as Mobile IP (actually, that seems > to the most pressing practical need so far). So, if the EAP > authenticator were to derive the AMSK, I can't envision an interface > between, say a Mobile IP HA and an EAP authenticator to transport the > AMSK. One can imagine a solution here, but this certainly complicates > the model a whole lot more. It makes much more sense to me to have this > in the EAP server so that the use of AMSKs could be more > straightforward. > > Also, it makes complete sense that an EAP-based means of bootstrapping > other protocols such as Mobile IP are only used in AAA-based systems. > So, having an SA between an arbitrary entity X (such as a MIP HA) and > the AAA server for transport of keys makes sense (and this is a model > that exists today). I don't see how (2) would be an option for the same > case. I don't see a use for AMSKs (at least not yet) for the EAP > authenticator itself. > > If we took Mobile IP as an example, one could envision the peer seeking > MIP bootstrapping as part of the EAP authentication, in reaction to > which the EAP server may derive an AMSK. Whether this AMSK gets sent to > the HA right away or gets cached in the EAP server (actually AAA server) > until the HA asks for it is a separate question that needs to be > answered. But, you already noted potential new stateful nature of the > EAP/AAA server in (1) above - so, that would take care of the needs > here. > > Vidya > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > ------=_Part_4755_28654021.1142626273112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Vidya, Jari,
 
>Given how many
>egacy methods are still in use, I'd strongly= vote for (b) here. It is
>mpractical to make changes to methods to a= ccommodate the use of
>EMSK/AMSK.
 
I strongly agree with Vidya here. The usage of EAP keys by
existing methods, such as EAP-TLS which are widely used, particularly = in 802.11 systems should be described and accommodated in the doc= ument.
It is impractical and extremely undesirable to make these existing met= hods non-compliant with the framework document.
 
My understanding was that the keying framework document would largely = describe EAP keying usage as implemented today,
while specification of EMSK and AMSK usage would be in a separate= document, such as an EAP key extensions document. Why is this changin= g,
particularly in WGLC?
 
Thanks,
 
Dorothy Stanley
 
On 3/6/06, N= arayanan, Vidya <vidyan@qualc= omm.com> wrote:
Hi Jari,
Thanks for the much = needed analysis on this topic. Please see some
comments below.

&g= t;
>
> Here's some analysis of the server vs. lower-layer based E= MSK
> processing approaches.
>
> (1) In the server based = approach we keep the EMSK in the
> server (perhaps just for a moment)= and generate the AMSKs,
> which are given to the the different applications, such as
>= fast handoff mechanisms.
> The use of these applications goes via AA= A, e.g., some kind
> of key requests or fast re-auth requests can be = sent from
> NASes to the server. The AMSKs are derived using a KDF which
&g= t; is decided either (a) by a default plus optional negotiation
> in = methods or (b) by lower layer negotiation and having AAA
> tell the s= erver which KDF to use.
>
> (2) In the lower-layer based EMSK processing approach, the=
> EMSK is delivered to the authenticator along with the MSK.
>= KDF is selected either (a) by a default in EAP plus optional
> negot= iation in methods, choice is communicated to the lower
> layer via AAA or (b) by lower layer negotiation alone.
> The= lower layer is responsible for all use of the AMSKs in a
> local con= text. That is, no AAA key requests are needed or possible.
>
> = Discussion about the chosen approach for EMSK use has so far
> appeared to assume 1a vs. 2b. Based on the above, it seems
>= that the KDF negotiation may be a separate issue from who
> maintain= s the EMSK and calculates AMSKs.
> In the following I'll try to analy= ze these issues.
>
> The KDF negotiation is indeed problematic almost no matter=
> what we do. Requiring new funtionality in methods is in
> pr= actice often a non-starter; while we can develop new
> methods and up= date old ones, it is expected that most of
> current usage will continue to use the existing methods.
> H= aving a default does not help much either, if the default
> becomes b= roken in the near future.
> But requiring new functionality in link l= ayers it not always
> easy either. It would be easy when we are developing a new
>= link layer and including some EMSK usage as a part of that.
> But if= we were to use EMSK for some new function over 802.11,
> for instanc= e, would there be enough incentive to extend
> 802.11 just to make this possible?
>
> The choices and= their implications are:
>
>   (a) Specified default,= optional negotiation in EAP methods.
>
>   &nbs= p;    This implies an interface either from methods to = the
> AAA/EAP server
>       &n= bsp;code (for solution 1) or AAA protocol extensions for
> solution 2= .
>
>        Changes in= peers, servers, methods, possibly AAA protocols.
>
> &nbs= p; (b) Lower layer negotiation.
>
>        If used tog= ether with solution 1, implies AAA protocol
> extensions
> = ;       to communicate the KDF. If used = with solution 2, implies AAA
>      &nb= sp; protocol extensions to carry the EMSK.
>
>        Changes in = lower layers, AAA protocol. No changes in
> EAP or methods.
>> Based on this my current preference is (b). I'd be willing to
>= ; accept (a), too.
>

I am surprised that you are willing to ac= cept (a) :) Given how many
legacy methods are still in use, I'd strongly vote for (b) here. It is<= br>impractical to make changes to methods to accommodate the use of
EMSK= /AMSK. As you point out, what we pick here may depend on whether we
pick (1) or (2) below - and (1) makes much more sense to me for reasons
= stated below.


> The choice between server or lower-layer base= d EMSK
> processing depends on security implications and ease of use
> for different purposes.
> The choices are:
>
>&n= bsp;  (1) Derive AMSKs at the EAP/AAA server.
>
> &nb= sp;      Implies a AAA protocol extension to = retrieve AMSKs.
>
>       &n= bsp;Changes at the EAP/AAA server, authenticator. New, stateful
>        nature of the EAP/A= AA server.
>
>   (2) Derive AMSKs at the lower layer.=
>
>        Implies a A= AA protocol extension to carry EMSK to the
>    &= nbsp;   authenticator.
>
>   &nbs= p;    Small changes at the EAP/AAA server, main functio= nality in
>        the authenticator.<= br>>
>        Hard to see = how other nodes than the authenticator would
>    = ;    actually use the AMSKs. Traditionally, NAS -> N= AS communication
>        has= not been easy compared to NAS -> AAA communication.
>
> Based on this my current preference is (1). But its a clos= e call.

I agree that (1) makes more sense. In many cases, the AMSKs = are slated
for use to bootstrap protocols such as Mobile IP (actually, t= hat seems
to the most pressing practical need so far). So, if the EAP
authenti= cator were to derive the AMSK, I can't envision an interface
between, sa= y a Mobile IP HA and an EAP authenticator to transport the
AMSK. One can= imagine a solution here, but this certainly complicates
the model a whole lot more. It makes much more sense to me to have this=
in the EAP server so that the use of AMSKs could be more
straightfor= ward.

Also, it makes complete sense that an EAP-based means of boots= trapping
other protocols such as Mobile IP are only used in AAA-based systems.So, having an SA between an arbitrary entity X (such as a MIP HA) and
= the AAA server for transport of keys makes sense (and this is a model
that exists today). I don't see how (2) would be an option for the same
= case. I don't see a use for AMSKs (at least not yet) for the EAP
authent= icator itself.

If we took Mobile IP as an example, one could envisio= n the peer seeking
MIP bootstrapping as part of the EAP authentication, in reaction to
= which the EAP server may derive an AMSK. Whether this AMSK gets sent to
= the HA right away or gets cached in the EAP server (actually AAA server)
until the HA asks for it is a separate question that needs to be
ans= wered. But, you already noted potential new stateful nature of the
EAP/A= AA server in (1) above - so, that would take care of the needs
here.

Vidya
__________________________________________________________= _______
To unsubscribe or modify your subscription options, please visit= :
http://list= s.frascone.com/mailman/listinfo/eap

Arhives: ht= tp://lists.frascone.com/pipermail/eap

------=_Part_4755_28654021.1142626273112-- --===============0639043487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0639043487==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 15:24:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLUh-0001mT-HK for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:24:19 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLUh-0004WJ-0y for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:24:19 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AD69B4300E6 for ; Fri, 17 Mar 2006 12:24:18 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 68D01430054 for ; Fri, 17 Mar 2006 12:23:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50E5980C13C for ; Fri, 17 Mar 2006 12:23:59 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 6F88080C0F8 for ; Fri, 17 Mar 2006 12:23:57 -0800 (PST) Received: from wall11.toshiba.co.jp ([133.199.90.149]) by inet-tsb.toshiba.co.jp with ESMTP id k2HKNotb025802; Sat, 18 Mar 2006 05:23:51 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k2HKOkgO000875; Sat, 18 Mar 2006 05:24:46 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id FAA00827; Sat, 18 Mar 2006 05:24:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k2HKNncW000871; Sat, 18 Mar 2006 05:23:50 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k2HKNnq4027767; Sat, 18 Mar 2006 05:23:49 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0IWA005U4GNJLA30@mail.po.toshiba.co.jp>; Sat, 18 Mar 2006 05:23:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.60) (envelope-from ) id 1FKLU0-0003ez-Eh; Fri, 17 Mar 2006 12:23:36 -0800 Date: Fri, 17 Mar 2006 15:23:36 -0500 From: Yoshihiro Ohba Subject: Re: [eap] About use of EMSK In-reply-to: <440C0298.4040100@piuha.net> To: Jari Arkko Message-id: <20060317202336.GI9573@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906A9AE2A@e2k-sea-xch2.sea-alpha.cisco.com> <440C0298.4040100@piuha.net> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 One thing we might discuss is whether (a) and (b) provide the same level of security or not. Since (b) is not end-to-end, negotiation bidding down attack may be possible by passthrough authenticator. Yoshihiro Ohba On Mon, Mar 06, 2006 at 11:36:24AM +0200, Jari Arkko wrote: > > Here's some analysis of the server vs. lower-layer based > EMSK processing approaches. > > (1) In the server based approach we keep the > EMSK in the server (perhaps just for a moment) > and generate the AMSKs, which are given to the the > different applications, such as fast handoff mechanisms. > The use of these applications goes via AAA, e.g., some kind > of key requests or fast re-auth requests can be sent from > NASes to the server. The AMSKs are derived using a KDF > which is decided either (a) by a default plus optional negotiation > in methods or (b) by lower layer negotiation and having AAA > tell the server which KDF to use. > > (2) In the lower-layer based EMSK processing approach, the > EMSK is delivered to the authenticator along with the MSK. > KDF is selected either (a) by a default in EAP plus optional > negotiation in methods, choice is communicated to the > lower layer via AAA or (b) by lower layer negotiation alone. > The lower layer is responsible for all use of the AMSKs > in a local context. That is, no AAA key requests are needed > or possible. > > Discussion about the chosen approach for EMSK use has > so far appeared to assume 1a vs. 2b. Based on the above, > it seems that the KDF negotiation may be a separate > issue from who maintains the EMSK and calculates AMSKs. > In the following I'll try to analyze these issues. > > The KDF negotiation is indeed problematic almost no > matter what we do. Requiring new funtionality in methods > is in practice often a non-starter; while we can develop > new methods and update old ones, it is expected that > most of current usage will continue to use the existing > methods. Having a default does not help much either, > if the default becomes broken in the near future. > But requiring new functionality in link layers it not > always easy either. It would be easy when we are developing > a new link layer and including some EMSK usage as a part > of that. But if we were to use EMSK for some new function > over 802.11, for instance, would there be enough incentive > to extend 802.11 just to make this possible? > > The choices and their implications are: > > (a) Specified default, optional negotiation in EAP methods. > > This implies an interface either from methods to the AAA/EAP server > code (for solution 1) or AAA protocol extensions for solution 2. > > Changes in peers, servers, methods, possibly AAA protocols. > > (b) Lower layer negotiation. > > If used together with solution 1, implies AAA protocol extensions > to communicate the KDF. If used with solution 2, implies AAA > protocol extensions to carry the EMSK. > > Changes in lower layers, AAA protocol. No changes in EAP or methods. > > Based on this my current preference is (b). I'd be willing > to accept (a), too. > > The choice between server or lower-layer based EMSK processing > depends on security implications and ease of use for different purposes. > The choices are: > > (1) Derive AMSKs at the EAP/AAA server. > > Implies a AAA protocol extension to retrieve AMSKs. > > Changes at the EAP/AAA server, authenticator. New, stateful > nature of the EAP/AAA server. > > (2) Derive AMSKs at the lower layer. > > Implies a AAA protocol extension to carry EMSK to the > authenticator. > > Small changes at the EAP/AAA server, main functionality in > the authenticator. > > Hard to see how other nodes than the authenticator would > actually use the AMSKs. Traditionally, NAS -> NAS communication > has not been easy compared to NAS -> AAA communication. > > Based on this my current preference is (1). But its a close > call. > > --Jari > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 15:57:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKM1B-000200-An for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:57:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKM19-0005JA-Rw for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 15:57:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 468C04300E6 for ; Fri, 17 Mar 2006 12:57:51 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 92098430054 for ; Fri, 17 Mar 2006 12:57:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 73E1339806A for ; Fri, 17 Mar 2006 12:57:37 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9BE5A39802B for ; Fri, 17 Mar 2006 12:57:33 -0800 (PST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2HKvVcA001439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 12:57:31 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2HKvRJ9003779; Fri, 17 Mar 2006 12:57:31 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 12:57:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 12:57:32 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UA== From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 17 Mar 2006 20:57:29.0159 (UTC) FILETIME=[67188570:01C64A05] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > >=20 >=20 > Vidya said: >=20 > "Are you saying then that in accordance with 4137, the EMSK=20 > will also be delivered to the AAA layer on the EAP server? " >=20 > That's how I read it, yes. The keying material and=20 > parameters are passed via the eapKeyData structure to the=20 > lower layer (which would be the AAA layer on the EAP server=20 > when in passthrough mode), via the m.getKey() function. The=20 > AAA layer then fills in the aaaEapKeyData structure and=20 > passes this to the authenticator. While both eapKeyData and=20 > aaaEapKeyData are of type "EAP Key" there doesn't appear to=20 > be a presumption that they are the same. So the AAA layer=20 > could receive the EMSK, but not pass it to the > authenticator. =20 >=20 I wonder if we are restricted in defining the behavior of the EMSK based on a spec that did not consider EMSKs to begin with? It may be that we would conclude it is okay to pass the EMSK to the AAA layer - but, should we be constrained by 4137 though?=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 16:00:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKM3J-0003SB-En for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:00:05 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKM3I-0005P8-Dv for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:00:05 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 10DD0430075 for ; Fri, 17 Mar 2006 13:00:04 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 95247430054 for ; Fri, 17 Mar 2006 12:59:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88DE3398072 for ; Fri, 17 Mar 2006 12:59:36 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 72378398064 for ; Fri, 17 Mar 2006 12:59:34 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2HKxVcA001586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 12:59:32 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2HKxUxY009750; Fri, 17 Mar 2006 12:59:31 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 12:59:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [eap] About use of EMSK Date: Fri, 17 Mar 2006 12:59:34 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96B@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK Thread-Index: AcZKABZv9ZhWFeJ4S/SfvHujYsiHegABVSxA From: "Narayanan, Vidya" To: "Dorothy Stanley" X-OriginalArrivalTime: 17 Mar 2006 20:59:30.0688 (UTC) FILETIME=[AF886000:01C64A05] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.057 tagged_above=-999 required=7 tests=HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2054060293==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 04b84659b2acb599bee006e63124a606 This is a multi-part message in MIME format. --===============2054060293== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64A05.AF5E7B99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64A05.AF5E7B99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, I don't think the keying framework document would still discuss this. I think there is consensus that the text about EMSK will be in a separate document. The issue was discussed in the context of the EAP keying framework, since there are parts of that document that specifically say that the EMSK MUST NOT be transported and MUST be deleted - question is whether we can change that wording and leave any other explanation on EMSK usage or AMSK derivation to a future spec.=20 =20 Thanks, Vidya ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, March 17, 2006 12:11 PM To: Narayanan, Vidya Cc: Jari Arkko; Bernard Aboba; eap@frascone.com Subject: Re: [eap] About use of EMSK =09 =09 Vidya, Jari, =20 >Given how many >egacy methods are still in use, I'd strongly vote for (b) here. It is >mpractical to make changes to methods to accommodate the use of >EMSK/AMSK. =20 I strongly agree with Vidya here. The usage of EAP keys by existing methods, such as EAP-TLS which are widely used, particularly in 802.11 systems should be described and accommodated in the document. It is impractical and extremely undesirable to make these existing methods non-compliant with the framework document. =20 My understanding was that the keying framework document would largely describe EAP keying usage as implemented today, while specification of EMSK and AMSK usage would be in a separate document, such as an EAP key extensions document. Why is this changing,=20 particularly in WGLC? =20 Thanks, =20 Dorothy Stanley =20 On 3/6/06, Narayanan, Vidya wrote:=20 Hi Jari, Thanks for the much needed analysis on this topic. Please see some comments below. =09 >=20 > > Here's some analysis of the server vs. lower-layer based EMSK > processing approaches. > > (1) In the server based approach we keep the EMSK in the > server (perhaps just for a moment) and generate the AMSKs,=20 > which are given to the the different applications, such as > fast handoff mechanisms. > The use of these applications goes via AAA, e.g., some kind > of key requests or fast re-auth requests can be sent from=20 > NASes to the server. The AMSKs are derived using a KDF which > is decided either (a) by a default plus optional negotiation > in methods or (b) by lower layer negotiation and having AAA > tell the server which KDF to use.=20 > > (2) In the lower-layer based EMSK processing approach, the > EMSK is delivered to the authenticator along with the MSK. > KDF is selected either (a) by a default in EAP plus optional > negotiation in methods, choice is communicated to the lower=20 > layer via AAA or (b) by lower layer negotiation alone. > The lower layer is responsible for all use of the AMSKs in a > local context. That is, no AAA key requests are needed or possible. > > Discussion about the chosen approach for EMSK use has so far=20 > appeared to assume 1a vs. 2b. Based on the above, it seems > that the KDF negotiation may be a separate issue from who > maintains the EMSK and calculates AMSKs. > In the following I'll try to analyze these issues.=20 > > The KDF negotiation is indeed problematic almost no matter > what we do. Requiring new funtionality in methods is in > practice often a non-starter; while we can develop new > methods and update old ones, it is expected that most of=20 > current usage will continue to use the existing methods. > Having a default does not help much either, if the default > becomes broken in the near future. > But requiring new functionality in link layers it not always=20 > easy either. It would be easy when we are developing a new > link layer and including some EMSK usage as a part of that. > But if we were to use EMSK for some new function over 802.11, > for instance, would there be enough incentive to extend=20 > 802.11 just to make this possible? > > The choices and their implications are: > > (a) Specified default, optional negotiation in EAP methods. > > This implies an interface either from methods to the=20 > AAA/EAP server > code (for solution 1) or AAA protocol extensions for > solution 2. > > Changes in peers, servers, methods, possibly AAA protocols. > > (b) Lower layer negotiation.=20 > > If used together with solution 1, implies AAA protocol > extensions > to communicate the KDF. If used with solution 2, implies AAA > protocol extensions to carry the EMSK.=20 > > Changes in lower layers, AAA protocol. No changes in > EAP or methods. > > Based on this my current preference is (b). I'd be willing to > accept (a), too. > =09 I am surprised that you are willing to accept (a) :) Given how many=20 legacy methods are still in use, I'd strongly vote for (b) here. It is impractical to make changes to methods to accommodate the use of EMSK/AMSK. As you point out, what we pick here may depend on whether we pick (1) or (2) below - and (1) makes much more sense to me for reasons stated below. =09 =09 > The choice between server or lower-layer based EMSK > processing depends on security implications and ease of use=20 > for different purposes. > The choices are: > > (1) Derive AMSKs at the EAP/AAA server. > > Implies a AAA protocol extension to retrieve AMSKs. > > Changes at the EAP/AAA server, authenticator. New, stateful=20 > nature of the EAP/AAA server. > > (2) Derive AMSKs at the lower layer. > > Implies a AAA protocol extension to carry EMSK to the > authenticator. > > Small changes at the EAP/AAA server, main functionality in=20 > the authenticator. > > Hard to see how other nodes than the authenticator would > actually use the AMSKs. Traditionally, NAS -> NAS communication > has not been easy compared to NAS -> AAA communication.=20 > > Based on this my current preference is (1). But its a close call. =09 I agree that (1) makes more sense. In many cases, the AMSKs are slated for use to bootstrap protocols such as Mobile IP (actually, that seems=20 to the most pressing practical need so far). So, if the EAP authenticator were to derive the AMSK, I can't envision an interface between, say a Mobile IP HA and an EAP authenticator to transport the AMSK. One can imagine a solution here, but this certainly complicates=20 the model a whole lot more. It makes much more sense to me to have this in the EAP server so that the use of AMSKs could be more straightforward. =09 Also, it makes complete sense that an EAP-based means of bootstrapping=20 other protocols such as Mobile IP are only used in AAA-based systems. So, having an SA between an arbitrary entity X (such as a MIP HA) and the AAA server for transport of keys makes sense (and this is a model that exists today). I don't see how (2) would be an option for the same case. I don't see a use for AMSKs (at least not yet) for the EAP authenticator itself. =09 If we took Mobile IP as an example, one could envision the peer seeking=20 MIP bootstrapping as part of the EAP authentication, in reaction to which the EAP server may derive an AMSK. Whether this AMSK gets sent to the HA right away or gets cached in the EAP server (actually AAA server)=20 until the HA asks for it is a separate question that needs to be answered. But, you already noted potential new stateful nature of the EAP/AAA server in (1) above - so, that would take care of the needs here.=20 =09 Vidya =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap=20 =09 Arhives: http://lists.frascone.com/pipermail/eap =09 ------_=_NextPart_001_01C64A05.AF5E7B99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dorothy,
I don't think the keying framework document = would still=20 discuss this. I think there is consensus that the text about EMSK will = be in a=20 separate document. The issue was discussed in the context of the EAP = keying=20 framework, since there are parts of that document that specifically say = that the=20 EMSK MUST NOT be transported and MUST be deleted - question is whether = we can=20 change that wording and leave any other explanation on EMSK usage or = AMSK=20 derivation to a future spec.
 
Thanks,
Vidya

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, March 17, = 2006 12:11=20 PM
To: Narayanan, Vidya
Cc: Jari Arkko; Bernard = Aboba;=20 eap@frascone.com
Subject: Re: [eap] About use of=20 EMSK

Vidya, Jari,
 
>Given how many
>egacy methods are still in use, I'd = strongly=20 vote for (b) here. It is
>mpractical to make changes to methods = to=20 accommodate the use of
>EMSK/AMSK.
 
I strongly agree with Vidya here. The usage of EAP keys by
existing methods, such as EAP-TLS which are widely used, = particularly in=20 802.11 systems should be described and accommodated in the=20 document.
It is impractical and extremely undesirable to make these = existing=20 methods non-compliant with the framework document.
 
My understanding was that the keying framework document would = largely=20 describe EAP keying usage as implemented today,
while specification of EMSK and AMSK usage would be in a = separate=20 document, such as an EAP key extensions document. Why is this = changing,=20
particularly in WGLC?
 
Thanks,
 
Dorothy Stanley
 
On 3/6/06, Narayanan,=20 Vidya <vidyan@qualcomm.com>=20 wrote:=20
Hi=20 Jari,
Thanks for the much needed analysis on this topic. Please = see=20 some
comments below.

>
>
> Here's some = analysis of=20 the server vs. lower-layer based EMSK
> processing=20 approaches.
>
> (1) In the server based approach we keep = the=20 EMSK in the
> server (perhaps just for a moment) and generate = the=20 AMSKs,
> which are given to the the different applications, = such=20 as
> fast handoff mechanisms.
> The use of these = applications=20 goes via AAA, e.g., some kind
> of key requests or fast = re-auth=20 requests can be sent from
> NASes to the server. The AMSKs = are=20 derived using a KDF which
> is decided either (a) by a default = plus=20 optional negotiation
> in methods or (b) by lower layer = negotiation=20 and having AAA
> tell the server which KDF to use. =
>
>=20 (2) In the lower-layer based EMSK processing approach, the
> = EMSK is=20 delivered to the authenticator along with the MSK.
> KDF is = selected=20 either (a) by a default in EAP plus optional
> negotiation in = methods,=20 choice is communicated to the lower
> layer via AAA or (b) by = lower=20 layer negotiation alone.
> The lower layer is responsible for = all use=20 of the AMSKs in a
> local context. That is, no AAA key = requests are=20 needed or possible.
>
> Discussion about the chosen = approach for=20 EMSK use has so far
> appeared to assume 1a vs. 2b. Based on = the=20 above, it seems
> that the KDF negotiation may be a separate = issue=20 from who
> maintains the EMSK and calculates AMSKs.
> In = the=20 following I'll try to analyze these issues.
>
> The KDF = negotiation is indeed problematic almost no matter
> what we = do.=20 Requiring new funtionality in methods is in
> practice often a = non-starter; while we can develop new
> methods and update old = ones,=20 it is expected that most of
> current usage will continue to = use the=20 existing methods.
> Having a default does not help much = either, if the=20 default
> becomes broken in the near future.
> But = requiring new=20 functionality in link layers it not always
> easy either. It = would be=20 easy when we are developing a new
> link layer and including = some EMSK=20 usage as a part of that.
> But if we were to use EMSK for some = new=20 function over 802.11,
> for instance, would there be enough = incentive=20 to extend
> 802.11 just to make this = possible?
>
> The=20 choices and their implications are:
>
>   (a)=20 Specified default, optional negotiation in EAP=20 = methods.
>
>        T= his=20 implies an interface either from methods to the
> AAA/EAP=20 server
>        code = (for=20 solution 1) or AAA protocol extensions for
> solution=20 = 2.
>
>        Changes= in=20 peers, servers, methods, possibly AAA = protocols.
>
>  =20 (b) Lower layer negotiation.=20
>
>        If = used=20 together with solution 1, implies AAA protocol
>=20 extensions
>        to = communicate the KDF. If used with solution 2, implies=20 AAA
>        protocol=20 extensions to carry the EMSK.=20 =
>
>        Changes = in=20 lower layers, AAA protocol. No changes in
> EAP or=20 methods.
>
> Based on this my current preference is (b). = I'd be=20 willing to
> accept (a), too.
>

I am surprised = that you=20 are willing to accept (a) :) Given how many
legacy methods are = still in=20 use, I'd strongly vote for (b) here. It is
impractical to make = changes to=20 methods to accommodate the use of
EMSK/AMSK. As you point out, = what we=20 pick here may depend on whether we
pick (1) or (2) below - and = (1) makes=20 much more sense to me for reasons
stated below.


> = The=20 choice between server or lower-layer based EMSK
> processing = depends=20 on security implications and ease of use
> for different=20 purposes.
> The choices are:
>
>   (1) = Derive=20 AMSKs at the EAP/AAA=20 = server.
>
>        Im= plies=20 a AAA protocol extension to retrieve=20 = AMSKs.
>
>        Cha= nges=20 at the EAP/AAA server, authenticator. New, stateful=20
>        nature of = the=20 EAP/AAA server.
>
>   (2) Derive AMSKs at the = lower=20 = layer.
>
>        Imp= lies=20 a AAA protocol extension to carry EMSK to=20 = the
>        authenticator.=
>
>        Small=20 changes at the EAP/AAA server, main functionality in=20
>        the=20 = authenticator.
>
>       &= nbsp;Hard=20 to see how other nodes than the authenticator=20 = would
>        actually = use=20 the AMSKs. Traditionally, NAS -> NAS=20 = communication
>        has = not=20 been easy compared to NAS -> AAA communication.
>
> = Based on=20 this my current preference is (1). But its a close call.

I = agree that=20 (1) makes more sense. In many cases, the AMSKs are slated
for use = to=20 bootstrap protocols such as Mobile IP (actually, that seems
to = the most=20 pressing practical need so far). So, if the EAP
authenticator = were to=20 derive the AMSK, I can't envision an interface
between, say a = Mobile IP=20 HA and an EAP authenticator to transport the
AMSK. One can = imagine a=20 solution here, but this certainly complicates
the model a whole = lot=20 more. It makes much more sense to me to have this
in the EAP = server so=20 that the use of AMSKs could be more
straightforward.

Also, = it=20 makes complete sense that an EAP-based means of bootstrapping =
other=20 protocols such as Mobile IP are only used in AAA-based = systems.
So,=20 having an SA between an arbitrary entity X (such as a MIP HA) = and
the AAA=20 server for transport of keys makes sense (and this is a = model
that exists=20 today). I don't see how (2) would be an option for the same
case. = I don't=20 see a use for AMSKs (at least not yet) for the EAP
authenticator=20 itself.

If we took Mobile IP as an example, one could = envision the=20 peer seeking
MIP bootstrapping as part of the EAP = authentication, in=20 reaction to
which the EAP server may derive an AMSK. Whether this = AMSK=20 gets sent to
the HA right away or gets cached in the EAP server = (actually=20 AAA server)
until the HA asks for it is a separate question that = needs=20 to be
answered. But, you already noted potential new stateful = nature of=20 the
EAP/AAA server in (1) above - so, that would take care of the = needs
here.=20 =

Vidya
________________________________________________________= _________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.fras= cone.com/mailman/listinfo/eap=20

Arhives: http://lists.frascone.co= m/pipermail/eap

= ------_=_NextPart_001_01C64A05.AF5E7B99-- --===============2054060293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============2054060293==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 16:03:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKM6N-0005Ac-BU for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:03:15 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKM6M-0005cP-PR for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:03:15 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 70A574300E2 for ; Fri, 17 Mar 2006 13:03:14 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0139B430054 for ; Fri, 17 Mar 2006 13:02:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6C7C398072 for ; Fri, 17 Mar 2006 13:02:58 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D17939802B for ; Fri, 17 Mar 2006 13:02:54 -0800 (PST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2HL2qXU027648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 13:02:53 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2HL2pJV014999; Fri, 17 Mar 2006 13:02:52 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 13:02:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: KDF Negotiation for AMSK derivation (was RE: [eap] About use of EMSK) Date: Fri, 17 Mar 2006 13:02:55 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KDF Negotiation for AMSK derivation (was RE: [eap] About use of EMSK) Thread-Index: AcZKAMi2fh3/wGwfTRKJygn42J6q8QABOuRg From: "Narayanan, Vidya" To: "Yoshihiro Ohba" , "Jari Arkko" X-OriginalArrivalTime: 17 Mar 2006 21:02:51.0825 (UTC) FILETIME=[276B7210:01C64A06] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 A higher level question here - why do we feel compelled to even allow for KDF negotiation to derive an AMSK from the EMSK? It is a yet-to-be-defined thing and the computation is only done by the EAP server and peer - could we just not pick a KDF and mandate it?=20 Regards, Vidya > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Friday, March 17, 2006 12:24 PM > To: Jari Arkko > Cc: eap@frascone.com; Bernard Aboba > Subject: Re: [eap] About use of EMSK >=20 > One thing we might discuss is whether (a) and (b) provide the=20 > same level of security or not. Since (b) is not end-to-end,=20 > negotiation bidding down attack may be possible by=20 > passthrough authenticator. >=20 > Yoshihiro Ohba >=20 >=20 > On Mon, Mar 06, 2006 at 11:36:24AM +0200, Jari Arkko wrote: > >=20 > > Here's some analysis of the server vs. lower-layer based EMSK=20 > > processing approaches. > >=20 > > (1) In the server based approach we keep the EMSK in the server=20 > > (perhaps just for a moment) and generate the AMSKs, which=20 > are given to=20 > > the the different applications, such as fast handoff mechanisms. > > The use of these applications goes via AAA, e.g., some kind of key=20 > > requests or fast re-auth requests can be sent from NASes to the=20 > > server. The AMSKs are derived using a KDF which is decided=20 > either (a)=20 > > by a default plus optional negotiation in methods or (b) by lower=20 > > layer negotiation and having AAA tell the server which KDF to use. > >=20 > > (2) In the lower-layer based EMSK processing approach, the EMSK is=20 > > delivered to the authenticator along with the MSK. > > KDF is selected either (a) by a default in EAP plus optional=20 > > negotiation in methods, choice is communicated to the lower=20 > layer via=20 > > AAA or (b) by lower layer negotiation alone. > > The lower layer is responsible for all use of the AMSKs in a local=20 > > context. That is, no AAA key requests are needed or possible. > >=20 > > Discussion about the chosen approach for EMSK use has so=20 > far appeared=20 > > to assume 1a vs. 2b. Based on the above, it seems that the KDF=20 > > negotiation may be a separate issue from who maintains the EMSK and=20 > > calculates AMSKs. > > In the following I'll try to analyze these issues. > >=20 > > The KDF negotiation is indeed problematic almost no matter=20 > what we do.=20 > > Requiring new funtionality in methods is in practice often a=20 > > non-starter; while we can develop new methods and update=20 > old ones, it=20 > > is expected that most of current usage will continue to use the=20 > > existing methods. Having a default does not help much=20 > either, if the=20 > > default becomes broken in the near future. > > But requiring new functionality in link layers it not always easy=20 > > either. It would be easy when we are developing a new link=20 > layer and=20 > > including some EMSK usage as a part of that. But if we were to use=20 > > EMSK for some new function over 802.11, for instance, would=20 > there be=20 > > enough incentive to extend 802.11 just to make this possible? > >=20 > > The choices and their implications are: > >=20 > > (a) Specified default, optional negotiation in EAP methods. > >=20 > > This implies an interface either from methods to the=20 > AAA/EAP server > > code (for solution 1) or AAA protocol extensions for=20 > solution 2. > >=20 > > Changes in peers, servers, methods, possibly AAA protocols. > >=20 > > (b) Lower layer negotiation. > >=20 > > If used together with solution 1, implies AAA=20 > protocol extensions > > to communicate the KDF. If used with solution 2, implies AAA > > protocol extensions to carry the EMSK. > > =20 > > Changes in lower layers, AAA protocol. No changes in=20 > EAP or methods. > >=20 > > Based on this my current preference is (b). I'd be willing=20 > to accept=20 > > (a), too. > >=20 > > The choice between server or lower-layer based EMSK=20 > processing depends=20 > > on security implications and ease of use for different purposes. > > The choices are: > >=20 > > (1) Derive AMSKs at the EAP/AAA server. > >=20 > > Implies a AAA protocol extension to retrieve AMSKs. > >=20 > > Changes at the EAP/AAA server, authenticator. New, stateful > > nature of the EAP/AAA server. > >=20 > > (2) Derive AMSKs at the lower layer. > >=20 > > Implies a AAA protocol extension to carry EMSK to the > > authenticator. > >=20 > > Small changes at the EAP/AAA server, main functionality in > > the authenticator. > >=20 > > Hard to see how other nodes than the authenticator would > > actually use the AMSKs. Traditionally, NAS -> NAS=20 > communication > > has not been easy compared to NAS -> AAA communication. > >=20 > > Based on this my current preference is (1). But its a close call. > >=20 > > --Jari > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > >=20 > > Arhives: http://lists.frascone.com/pipermail/eap > >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 16:40:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMgk-0000lv-9o for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:40:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMgi-0006WS-I8 for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:40:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BCFCB4300EB for ; Fri, 17 Mar 2006 13:40:47 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6F45A430054 for ; Fri, 17 Mar 2006 13:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 545D839807A for ; Fri, 17 Mar 2006 13:40:28 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 43A41398048 for ; Fri, 17 Mar 2006 13:40:24 -0800 (PST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k2HLeNtb005515; Sat, 18 Mar 2006 06:40:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k2HLeO55000916; Sat, 18 Mar 2006 06:40:24 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id GAA00882 ; Sat, 18 Mar 2006 06:40:24 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k2HLeMEQ023365; Sat, 18 Mar 2006 06:40:23 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k2HLeM2t029643; Sat, 18 Mar 2006 06:40:22 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0IWA005SDK5ZL840@mail.po.toshiba.co.jp>; Sat, 18 Mar 2006 06:40:22 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.60) (envelope-from ) id 1FKMfJ-0003s7-T3; Fri, 17 Mar 2006 13:39:21 -0800 Date: Fri, 17 Mar 2006 16:39:21 -0500 From: Yoshihiro Ohba Subject: Re: KDF Negotiation for AMSK derivation (was RE: [eap] About use of EMSK) In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96C@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060317213921.GP9573@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96C@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Hi Vidya, I am ok with either hardcoding a mandatory KDF in a specification or allow for KDF negotiation. But regardless of it, some negotiation might be needed for Channel Binding if Channel Binding is an optional functionality. For MSK branch Channel Binding is optional, but I am not sure whether Channel Binding is mandatory or optional for EMSK branch. Yoshihiro Ohba On Fri, Mar 17, 2006 at 01:02:55PM -0800, Narayanan, Vidya wrote: > A higher level question here - why do we feel compelled to even allow > for KDF negotiation to derive an AMSK from the EMSK? It is a > yet-to-be-defined thing and the computation is only done by the EAP > server and peer - could we just not pick a KDF and mandate it? > > Regards, > Vidya > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Friday, March 17, 2006 12:24 PM > > To: Jari Arkko > > Cc: eap@frascone.com; Bernard Aboba > > Subject: Re: [eap] About use of EMSK > > > > One thing we might discuss is whether (a) and (b) provide the > > same level of security or not. Since (b) is not end-to-end, > > negotiation bidding down attack may be possible by > > passthrough authenticator. > > > > Yoshihiro Ohba > > > > > > On Mon, Mar 06, 2006 at 11:36:24AM +0200, Jari Arkko wrote: > > > > > > Here's some analysis of the server vs. lower-layer based EMSK > > > processing approaches. > > > > > > (1) In the server based approach we keep the EMSK in the server > > > (perhaps just for a moment) and generate the AMSKs, which > > are given to > > > the the different applications, such as fast handoff mechanisms. > > > The use of these applications goes via AAA, e.g., some kind of key > > > requests or fast re-auth requests can be sent from NASes to the > > > server. The AMSKs are derived using a KDF which is decided > > either (a) > > > by a default plus optional negotiation in methods or (b) by lower > > > layer negotiation and having AAA tell the server which KDF to use. > > > > > > (2) In the lower-layer based EMSK processing approach, the EMSK is > > > delivered to the authenticator along with the MSK. > > > KDF is selected either (a) by a default in EAP plus optional > > > negotiation in methods, choice is communicated to the lower > > layer via > > > AAA or (b) by lower layer negotiation alone. > > > The lower layer is responsible for all use of the AMSKs in a local > > > context. That is, no AAA key requests are needed or possible. > > > > > > Discussion about the chosen approach for EMSK use has so > > far appeared > > > to assume 1a vs. 2b. Based on the above, it seems that the KDF > > > negotiation may be a separate issue from who maintains the EMSK and > > > calculates AMSKs. > > > In the following I'll try to analyze these issues. > > > > > > The KDF negotiation is indeed problematic almost no matter > > what we do. > > > Requiring new funtionality in methods is in practice often a > > > non-starter; while we can develop new methods and update > > old ones, it > > > is expected that most of current usage will continue to use the > > > existing methods. Having a default does not help much > > either, if the > > > default becomes broken in the near future. > > > But requiring new functionality in link layers it not always easy > > > either. It would be easy when we are developing a new link > > layer and > > > including some EMSK usage as a part of that. But if we were to use > > > EMSK for some new function over 802.11, for instance, would > > there be > > > enough incentive to extend 802.11 just to make this possible? > > > > > > The choices and their implications are: > > > > > > (a) Specified default, optional negotiation in EAP methods. > > > > > > This implies an interface either from methods to the > > AAA/EAP server > > > code (for solution 1) or AAA protocol extensions for > > solution 2. > > > > > > Changes in peers, servers, methods, possibly AAA protocols. > > > > > > (b) Lower layer negotiation. > > > > > > If used together with solution 1, implies AAA > > protocol extensions > > > to communicate the KDF. If used with solution 2, implies AAA > > > protocol extensions to carry the EMSK. > > > > > > Changes in lower layers, AAA protocol. No changes in > > EAP or methods. > > > > > > Based on this my current preference is (b). I'd be willing > > to accept > > > (a), too. > > > > > > The choice between server or lower-layer based EMSK > > processing depends > > > on security implications and ease of use for different purposes. > > > The choices are: > > > > > > (1) Derive AMSKs at the EAP/AAA server. > > > > > > Implies a AAA protocol extension to retrieve AMSKs. > > > > > > Changes at the EAP/AAA server, authenticator. New, stateful > > > nature of the EAP/AAA server. > > > > > > (2) Derive AMSKs at the lower layer. > > > > > > Implies a AAA protocol extension to carry EMSK to the > > > authenticator. > > > > > > Small changes at the EAP/AAA server, main functionality in > > > the authenticator. > > > > > > Hard to see how other nodes than the authenticator would > > > actually use the AMSKs. Traditionally, NAS -> NAS > > communication > > > has not been easy compared to NAS -> AAA communication. > > > > > > Based on this my current preference is (1). But its a close call. > > > > > > --Jari > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 16:42:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMiP-00013M-N1 for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:42:33 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMiN-0006Xf-A4 for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 16:42:33 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F368D4300D5 for ; Fri, 17 Mar 2006 13:42:30 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D7B46430054 for ; Fri, 17 Mar 2006 13:42:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6BB3398083 for ; Fri, 17 Mar 2006 13:42:20 -0800 (PST) Received: from hotmail.com (bay106-dav7.bay106.hotmail.com [65.54.161.79]) by zoidberg.tigertech.net (Postfix) with ESMTP id 158DA39807C for ; Fri, 17 Mar 2006 13:42:19 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Mar 2006 13:42:18 -0800 Message-ID: Received: from 131.107.0.74 by BAY106-DAV7.phx.gbl with DAV; Fri, 17 Mar 2006 21:42:17 +0000 X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Narayanan, Vidya'" , Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 13:42:15 -0800 Message-ID: <000001c64a0b$a85ed240$888a3b9d@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96A@NAEX06.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UAAD/Dsg X-OriginalArrivalTime: 17 Mar 2006 21:42:18.0490 (UTC) FILETIME=[AA0FDDA0:01C64A0B] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Vidya said: "I wonder if we are restricted in defining the behavior of the EMSK based on a spec that did not consider EMSKs to begin with? It may be that we would conclude it is okay to pass the EMSK to the AAA layer - but, should we be constrained by 4137 though?" RFC 4137 treats keying material as a *structure* not a single variable, so that all the keying material and parameters are passed to the lower layer at the same time. This would not have been necessary if the document only meant to deal with the MSK. Since RFC 4137 references the key frame work document as well as RFC 3748, it cannot be claimed that it was unaware of the key management document, which until -09 included passing of the EMSK to the lower layer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 17:07:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKN6h-0006kW-Ib for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 17:07:39 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKN6f-0007NG-5C for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 17:07:39 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CE57E4300C9 for ; Fri, 17 Mar 2006 14:07:36 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 89713430054 for ; Fri, 17 Mar 2006 14:07:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 73DAE398075 for ; Fri, 17 Mar 2006 14:07:25 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id D8EE7398048 for ; Fri, 17 Mar 2006 14:07:22 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 17 Mar 2006 14:07:22 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2HM7MGv016738; Fri, 17 Mar 2006 14:07:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 14:14:21 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906BDC1F7@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UAAD/DsgAADEnrA= From: "Salowey, Joe" To: "Bernard Aboba" , "Narayanan, Vidya" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 =20 > -----Original Message----- > From: Bernard Aboba [mailto:Bernard_Aboba@hotmail.com]=20 > Sent: Friday, March 17, 2006 1:42 PM > To: 'Narayanan, Vidya'; eap@frascone.com > Subject: RE: [eap] Re: m.getKey() and RFC 4137 >=20 > Vidya said: >=20 > "I wonder if we are restricted in defining the behavior of=20 > the EMSK based > on a spec that did not consider EMSKs to begin with? It may be that we > would conclude it is okay to pass the EMSK to the AAA layer - but, > should we be constrained by 4137 though?"=20 >=20 > RFC 4137 treats keying material as a *structure* not a single=20 > variable, so > that all the keying material and parameters are passed to the=20 > lower layer at > the same time. This would not have been necessary if the=20 > document only > meant to deal with the MSK. Since RFC 4137 references the key=20 > frame work > document as well as RFC 3748, it cannot be claimed that it=20 > was unaware of > the key management document, which until -09 included passing=20 > of the EMSK to > the lower layer.=20 >=20 [Joe] Awareness and having a good understanding of it are two different things. I think we have made much progress in understanding in discussions since RFC 3748 (which reserves the EMSK for future use) and RFC 4137 (which doesn't mention the EMSK at all). Basing a decision on what is loosely captured in RFC 4137 would be short sighted. I don't think these documents should be interpreted as encourage or discourage passing the EMSK to various places.=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 17:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKNet-0005W9-Bg for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 17:42:59 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKNer-0008HY-U5 for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 17:42:59 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 251224300E6 for ; Fri, 17 Mar 2006 14:42:57 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 247BD430054 for ; Fri, 17 Mar 2006 14:42:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 10D603980B8 for ; Fri, 17 Mar 2006 14:42:38 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id E28BA3980B7 for ; Fri, 17 Mar 2006 14:42:35 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2HMgXXU004579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 14:42:33 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2HMgE7M013627; Fri, 17 Mar 2006 14:42:32 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 14:42:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 14:42:24 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F9A4@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UAAD/DsgAADEnrAAAQMMgA== From: "Narayanan, Vidya" To: "Salowey, Joe" , "Bernard Aboba" , X-OriginalArrivalTime: 17 Mar 2006 22:42:26.0042 (UTC) FILETIME=[10549DA0:01C64A14] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > > Vidya said: > >=20 > > "I wonder if we are restricted in defining the behavior of the EMSK=20 > > based on a spec that did not consider EMSKs to begin with?=20 > It may be=20 > > that we would conclude it is okay to pass the EMSK to the=20 > AAA layer -=20 > > but, should we be constrained by 4137 though?" > >=20 > > RFC 4137 treats keying material as a *structure* not a single=20 > > variable, so that all the keying material and parameters=20 > are passed to=20 > > the lower layer at the same time. This would not have been=20 > necessary=20 > > if the document only meant to deal with the MSK. Since RFC 4137=20 > > references the key frame work document as well as RFC 3748,=20 > it cannot=20 > > be claimed that it was unaware of the key management=20 > document, which=20 > > until -09 included passing of the EMSK to the lower layer. > >=20 > [Joe] Awareness and having a good understanding of it are two=20 > different things. I think we have made much progress in=20 > understanding in discussions since RFC 3748 (which reserves=20 > the EMSK for future use) and RFC 4137 (which doesn't mention=20 > the EMSK at all).=20 Well, for that matter, RFC 4137 doesn't mention the MSK either :)=20 > Basing a decision on what is loosely=20 > captured in RFC 4137 would be short sighted. I don't think=20 > these documents should be interpreted as encourage or=20 > discourage passing the EMSK to various places.=20 >=20 I agree with this though. If 4137 captured a snapshot that has been revisited and evolved further, it doesn't seem reasonable to use that as a baseline. What are the implications on existing implementations because of this? Do we have a sense of that?=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 19:32:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPNL-0004vI-4o for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 19:32:59 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKPNI-0003sh-6V for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 19:32:58 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1F16B430094 for ; Fri, 17 Mar 2006 16:32:55 -0800 (PST) Received: from g1-41.tigertech.net (g1-41.tigertech.net [64.62.209.41]) by leela.tigertech.net (Postfix) with ESMTP id 2F56A430054 for ; Fri, 17 Mar 2006 16:32:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 149F6398066 for ; Fri, 17 Mar 2006 16:32:34 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by zoidberg.tigertech.net (Postfix) with ESMTP id 437E6398081 for ; Fri, 17 Mar 2006 16:32:31 -0800 (PST) Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 17 Mar 2006 16:32:31 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 16:32:08 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 16:32:08 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 16:32:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Mar 2006 16:32:07 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ABA6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: m.getKey() and RFC 4137 Thread-Index: AcZKI2MvJJWv6NKqSHmE3RJpBGOqpA== From: "Ryan Hurst" To: X-OriginalArrivalTime: 18 Mar 2006 00:32:08.0405 (UTC) FILETIME=[63B98050:01C64A23] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.837 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, HTML_40_50, HTML_MESSAGE X-Spam-Level: * Subject: [eap] Re: m.getKey() and RFC 4137 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542030307==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. --===============0542030307== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64A23.634EAB60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64A23.634EAB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vidya - RFC 4137 has been out of last call for nearly 18 months and we = (Microsoft) have completed a implementation based on it, we already have = partners integrating with it. =20 We are not the only ones, it has also been integrated with other link = layers such as IEEE 802.1X-2004, IEEE 802.11i, etc. =20 I even understand UNH is also going to be building a test sure around = 4137 (http://www.iol.unh.edu/). =20 Simply put proposed changes would result in significant changes to these = existing standards, that would not only would negate the progress that = has been achieved through this working group it would also create = confusion in the market and likely cost the industry billions of = dollars. If there is in-fact a need for these new capabilities the existing = standards are not the place to incorporate them. Ryan M. Hurst ------_=_NextPart_001_01C64A23.634EAB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=
Vidya - RFC 4137 has been out of = last call for =0A= nearly 18 months and we (Microsoft) have completed a implementation = based on it, =0A= we already have partners integrating with it.
=0A=
 
=0A=
We are not the only ones, it has = also been =0A= integrated with other link layers such as IEEE 802.1X-2004, IEEE = 802.11i, =0A= etc.
=0A=
 
=0A=
I even understand UNH is also going to be building a = test sure =0A= around 4137 (http://www.iol.unh.edu/).=0A=
 
=0A=
Simply put proposed changes = would result in =0A= significant changes to these existing standards, that would not = only would =0A= negate the progress that has been achieved through this working group it = would =0A= also create confusion in the market and likely cost the industry = billions of =0A= dollars.
=0A=

If there is in-fact a need for these = new =0A= capabilities the existing standards are not the place to incorporate =0A= them.

=0A=
Ryan M. = Hurst
------_=_NextPart_001_01C64A23.634EAB60-- --===============0542030307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0542030307==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 20:37:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKQNW-0004Gm-Mp for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 20:37:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKQNV-0005l0-AI for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 20:37:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 88E064300EA for ; Fri, 17 Mar 2006 17:37:12 -0800 (PST) Received: from g1-41.tigertech.net (g1-41.tigertech.net [64.62.209.41]) by leela.tigertech.net (Postfix) with ESMTP id 51D2E430054 for ; Fri, 17 Mar 2006 17:37:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4203F39808E for ; Fri, 17 Mar 2006 17:37:00 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id ACFB7398089 for ; Fri, 17 Mar 2006 17:36:57 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 17 Mar 2006 17:36:57 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2I1avGv016444; Fri, 17 Mar 2006 17:36:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 17:43:57 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906BDC29D@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UAAD/DsgAADEnrAAAQMMgAAGkSIg From: "Salowey, Joe" To: "Narayanan, Vidya" , "Bernard Aboba" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > Basing a decision on what is loosely=20 > > captured in RFC 4137 would be short sighted. I don't think=20 > > these documents should be interpreted as encourage or=20 > > discourage passing the EMSK to various places.=20 > >=20 >=20 > I agree with this though. If 4137 captured a snapshot that has been > revisited and evolved further, it doesn't seem reasonable to=20 > use that as > a baseline. What are the implications on existing implementations > because of this? Do we have a sense of that?=20 >=20 [Joe] There are no existing implementations that use the EMSK because we have not defined how to use the EMSK yet. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 20:47:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKQXb-0003wi-Jh for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 20:47:39 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKQXa-0005ty-7M for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 20:47:39 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E22CD4300BD for ; Fri, 17 Mar 2006 17:47:37 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C01EF430054 for ; Fri, 17 Mar 2006 17:47:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B308780C14C for ; Fri, 17 Mar 2006 17:47:22 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 7D40280C13F for ; Fri, 17 Mar 2006 17:47:19 -0800 (PST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2I1lGXU019801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 17:47:16 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2I1lEGo002429; Fri, 17 Mar 2006 17:47:15 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 17:47:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 17:47:23 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F9F6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZJe5NY4bPxiUjkS12Kfzh+eSn6IgAdZylwAADFzOAAAZT5UAAD/DsgAADEnrAAAQMMgAAGkSIgAAA+L/A= From: "Narayanan, Vidya" To: "Salowey, Joe" , "Bernard Aboba" , X-OriginalArrivalTime: 18 Mar 2006 01:47:14.0856 (UTC) FILETIME=[E1C75A80:01C64A2D] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > >=20 > [Joe] There are no existing implementations that use the EMSK=20 > because we have not defined how to use the EMSK yet. =20 >=20 There aren't implementations that "use" it, but there must be implementations that derive it (given that the MSK and EMSK are really parts of the same longer key) - no?=20 And, if it is derived and passed to the lower layer today, we still have issues, regardless of the fact that the lower layer does nothing with it today.=20 Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 17 21:15:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKQye-0007jn-Bb for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 21:15:36 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKQyc-00078y-ME for eap-archive@lists.ietf.org; Fri, 17 Mar 2006 21:15:36 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1D38C4300E1 for ; Fri, 17 Mar 2006 18:15:34 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C0D6C43005F for ; Fri, 17 Mar 2006 18:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AC87D80C147 for ; Fri, 17 Mar 2006 18:15:09 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 0031A80C13C for ; Fri, 17 Mar 2006 18:15:06 -0800 (PST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2I2F4XU023877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2006 18:15:05 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2I2F3u8009142; Fri, 17 Mar 2006 18:15:04 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 18:15:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Fri, 17 Mar 2006 18:15:02 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8435F9FC@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZKI2MvJJWv6NKqSHmE3RJpBGOqpAACo8zg From: "Narayanan, Vidya" To: "Ryan Hurst" , X-OriginalArrivalTime: 18 Mar 2006 02:15:03.0944 (UTC) FILETIME=[C4A1F880:01C64A31] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.096 tagged_above=-999 required=7 tests=HTML_50_60, HTML_MESSAGE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1750713860==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 This is a multi-part message in MIME format. --===============1750713860== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64A31.C4402FED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64A31.C4402FED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ryan, This is valuable input. This unfortunately, is a practical limitation.=20 =20 Re-reading RFC 3748, I guess it really says "it (the EMSK) MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys." So, it doesn't say anywhere that the EMSK MUST NOT be transported to a lower layer per say.=20 =20 I guess we cannot really blame RFC 4137 alone for what it says then :)=20 =20 We could go down the path that RFC 4137 is an informational RFC and must technically not have a bearing on a standards track document - but, practical problems supercede that anyway.=20 =20 It does make the specification a bit sticky with respect to EMSKs now - it should be the EAP layer keeping the EMSK (caching if needed) and generating the AMSKs out of it. If the EMSK is transported to the AAA layer, it doesn't seem to make sense that the AAA layer would be deriving any AMSKs.=20 =20 We could say that the EMSK is transported along with the MSK to the AAA layer in today's implementations, but the EAP layer must maintain a copy of the EMSK in order to derive AMSKs from it - but, then, this obviously violates the fact that transported keys must be deleted. If we are willing to relax that requirement (and add text about the fact that the AAA layer MUST delete the EMSK immediately), there may be a way forward. But, I'm not convinced that this is the right approach.=20 =20 Vidya ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Friday, March 17, 2006 4:32 PM To: eap@frascone.com Subject: [eap] Re: m.getKey() and RFC 4137 =09 =09 Vidya - RFC 4137 has been out of last call for nearly 18 months and we (Microsoft) have completed a implementation based on it, we already have partners integrating with it. =20 We are not the only ones, it has also been integrated with other link layers such as IEEE 802.1X-2004, IEEE 802.11i, etc. =20 I even understand UNH is also going to be building a test sure around 4137 (http://www.iol.unh.edu/). =20 Simply put proposed changes would result in significant changes to these existing standards, that would not only would negate the progress that has been achieved through this working group it would also create confusion in the market and likely cost the industry billions of dollars. If there is in-fact a need for these new capabilities the existing standards are not the place to incorporate them. Ryan M. Hurst =09 ------_=_NextPart_001_01C64A31.C4402FED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ryan,
This is valuable input. This unfortunately, is = a practical=20 limitation.
 
Re-reading RFC 3748, I guess it really says = "it (the EMSK) MUST NOT be transported to, or = shared with,=20 additional parties, or used to derive any other keys." So, it doesn't = say=20 anywhere that the EMSK MUST NOT be transported to a lower layer per say. =
 
I guess we cannot really blame RFC 4137 alone for what it = says=20 then :)
 
We could go down the path that RFC 4137 is an informational RFC = and must=20 technically not have a bearing on a standards track document - but, = practical problems supercede that anyway.
 
It does make the specification a bit sticky with respect to = EMSKs now -=20 it should be the EAP layer keeping the EMSK (caching if needed) and = generating=20 the AMSKs out of it. If the EMSK is transported to the AAA layer, = it=20 doesn't seem to make sense that the AAA layer would be deriving any = AMSKs.=20
 
We could say that the EMSK is transported along with the MSK to = the AAA=20 layer in today's implementations, but the EAP layer must maintain a copy = of the=20 EMSK in order to derive AMSKs from it - but, then, this obviously = violates the=20 fact that transported keys must be deleted. If we are willing to relax = that=20 requirement (and add text about the fact that the AAA layer MUST delete = the EMSK=20 immediately), there may be a way forward. But, I'm not convinced = that this=20 is the right approach.
 
Vidya

From: Ryan Hurst=20 [mailto:Ryan.Hurst@microsoft.com]
Sent: Friday, March 17, = 2006 4:32=20 PM
To: eap@frascone.com
Subject: [eap] Re: = m.getKey() and=20 RFC 4137

Vidya - RFC 4137 has been out of last call for = nearly 18=20 months and we (Microsoft) have completed a implementation based on it, = we=20 already have partners integrating with it.
 
We are not the only ones, it has also been = integrated with=20 other link layers such as IEEE 802.1X-2004, IEEE 802.11i, = etc.
 
I even understand UNH is also going to be building = a test=20 sure around 4137 (http://www.iol.unh.edu/).
 
Simply put proposed changes = would result=20 in significant changes to these existing standards, that would = not only=20 would negate the progress that has been achieved through this working = group it=20 would also create confusion in the market and likely cost the industry = billions of dollars.

If there is in-fact a need for these = new=20 capabilities the existing standards are not the place to incorporate=20 them.

Ryan M.=20 Hurst
------_=_NextPart_001_01C64A31.C4402FED-- --===============1750713860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============1750713860==-- From barry@01comics.com Sat Mar 18 06:44:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKZrX-0004NY-5i for eap-archive@ietf.org; Sat, 18 Mar 2006 06:44:51 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKZrX-0006qg-4M for eap-archive@ietf.org; Sat, 18 Mar 2006 06:44:51 -0500 Received: from [222.252.59.223] (helo=hieuyeu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FKZrU-0006Z7-0f for eap-archive@ietf.org; Sat, 18 Mar 2006 06:44:50 -0500 Date: Sat, 18 Mar 2006 14:44:21 +0480 From: "Horace Jack" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Horace Jack" X-Priority: 3 (Normal) Message-ID: <3333654406.20060318144421@01comics.com> To: eap-archive@ietf.org Subject: FWD: Financial Market Traderr special pr news release MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 There is a Big PR Campaign running today! Get GAPJ First Thing Today, This Is Going To Explode! Check out for HOT NEWS!!! GAPJ- GOLDEN APPLE OIL/GAS Current Price: $1.18 Up .13 Thursday alone! Already Starting to move! Before we start with the profile of GAPJ we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW Current Press Release Golden Apple Oil and Gas, Inc. and Franklin Ross Securities Complete Private Placement Golden Apple Oil and Gas, Inc. (GAPJ - News) is pleased to announce it has completed the initial private placement with Franklin Ross Securities of New Jersey. The company is currently negotiating with several investor groups for the next phase of financing. Headquartered in Phoenix, Arizona, Golden Apple is an independent oil and gas producer with a focus on North and South American properties. The Company applies advanced technologies to systematically explore and develop its oil and natural gas opportunities. Golden Apple focuses its activities where technology can be used effectively to maximize returns on invested capital by reducing drilling risk and enhancing its ability to cost-effectively grow reserves and production volumes. Golden Apple Oil and Gas, Inc has opened a Canadian office in Toronto, Ontario to facilitate the management of its Canadian operations. All correspondence and communication will continue to be serviced by the company's head office staff in Phoenix Arizona. From kwjfc@swirly.com Sun Mar 19 04:59:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKuhV-000474-Re for eap-archive@ietf.org; Sun, 19 Mar 2006 04:59:53 -0500 Received: from [219.135.140.157] (helo=156.154.16.150) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKuh9-00049D-1W; Sun, 19 Mar 2006 04:59:53 -0500 Received: from crm8.www4.js8h.com (localhost.localdomain [127.0.0.1]) by crm5.www4.js8h.com (Postfix) with ESMTP id 084133EBA; Tue, 17 Jan 2006 11:40:21 -0200 (BRST) Message-ID: <64957564.4024254570370.JavaMail.nfsnobody@www4.js8h.com> X-Mailer: Mediacomm Communicator 1.4 Date: Sun, 19 Mar 2006 10:59:22 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org, edmund.rivera@ietf.org From: "Cecil Donaldson" Subject: Top Notch Refinances with ease X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 guess what! Homeowner You have been pre-approved for a $433,733 Home Loan at a Introductory APR of 3.48% This offer is being extended to you unconditionally and your credit is in no way a factor. To take Advantage of this Limited Time opportunity All we ask is that you visit our Website and complete The 1 minute post Approval Form http://www4.js8h.com/was.asp Sincerely, Leticia Jean, Opt0ut http://www4.js8h.com/rem.assp From rvawxznnl@cmsi-inc.com Sun Mar 19 07:14:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKwo8-0007jX-JO for eap-archive@ietf.org; Sun, 19 Mar 2006 07:14:52 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKwo8-0008FY-HA for eap-archive@ietf.org; Sun, 19 Mar 2006 07:14:52 -0500 Received: from [125.181.227.177] (helo=podawy) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FKwo6-00022r-Ib for eap-archive@ietf.org; Sun, 19 Mar 2006 07:14:52 -0500 Received: from [125.181.214.167] (port=3055 helo=emuk) by podawy with esmtp id 1FKhgV-0006Xm-7G for eap-archive@ietf.org; Sun, 19 Mar 2006 05:05:59 +0900 Message-ID: <001d01c64ac7$2e3af197$a7d6b57d@emuk> From: "Lewie Barlow" To: Subject: misspelling Date: Sun, 19 Mar 2006 04:55:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 To Investor: nZon Corporation Trading As: IZON Last Trade: $0.45 7 Day Proj: $1.10-$1.25 30 Day Proj: $1.75-$2.00 InZon Corp. is the new stock on our watch. After recently acquiring SAE Group including all assets and technologies, IZON has been laying quite while developing a new technology that will revolutionize the Online Media Broadcasting market. Two Announcements this month have sparked our understandable interest. On March 6, 2006 IZON announced the expansion of its network by 400% which has paved the way for the announcement that has brought this Alert to you. IZON released at end of day yesterday that they have completed their development of a new software that allows Online Broadcast Companies to better utilize their networks thus reducing their highest expense while at the same time increasing the quality of broadcasts allowing them to offer more HD (High definition) broadcasts over the Internet. This technology will completely change what Tier 1 and Tier 2 providers are able to offer to the clients in service and quality, and over all continue advance the technology that has made the internet the most powerful information medium on the planet. Make no mistake, this company is going places and fast. Once this news hits the market we believe IZON is going to take off. Most important, don't let this one pass you buy. IZON is set to BUY. We hope to see you jump on the bandwagon Monday March 20, 2006!!! From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 20 08:38:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKaN-0003Z7-JL for eap-archive@lists.ietf.org; Mon, 20 Mar 2006 08:38:15 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKaM-0002SA-3d for eap-archive@lists.ietf.org; Mon, 20 Mar 2006 08:38:15 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 764BC4300B2 for ; Mon, 20 Mar 2006 05:38:13 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0969B430063 for ; Mon, 20 Mar 2006 05:37:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E602239801F for ; Mon, 20 Mar 2006 05:37:54 -0800 (PST) Received: from hotmail.com (bay106-dav23.bay106.hotmail.com [65.54.161.95]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3FA4439801D for ; Mon, 20 Mar 2006 05:37:53 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 Mar 2006 05:37:53 -0800 Message-ID: Received: from 204.96.113.52 by BAY106-DAV23.phx.gbl with DAV; Mon, 20 Mar 2006 13:37:47 +0000 X-Originating-IP: [204.96.113.52] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: Date: Mon, 20 Mar 2006 05:37:37 -0800 Message-ID: <000001c64c23$738dff90$347160cc@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZMI3Ndq7lCRbgNRCmQK1c0r2MGuw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-OriginalArrivalTime: 20 Mar 2006 13:37:53.0094 (UTC) FILETIME=[7CF9A660:01C64C23] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Re: KDF Negotiation for AMSK derivation X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Vidya said: "It is a yet-to-be-defined thing and the computation is only done by the EAP server and peer - could we just not pick a KDF and mandate it?" One problem is that the KDF currently suggested for use in computing AMSKs is based on SHA-1, which NIST has suggested will be deprecated by 2010. Given the movement of the US and other governments toward the deployment of EAP-based access control, it is important that FIPS-certifiable EAP-based solutions continue to be available going forward. Without the possibility of negotiation, the adoption of a soon-to-be-deprecated KDF implies that EAP itself will be deprecated by 2010. As has been noted by others, existing EAP methods do not negotiate KDFs either for their own use or for use in AMSK generation, and adding this feature to existing or even new methods would be very difficult. For example, TLS (on which many EAP methods are based) does not yet support KDF negotiation for its own use, let along for use in AMSK generation. These problems largely evaporate if AMSKs are generated by the lower layer, since the lower layer can then negotiate the appropriate KDF for their generation. No changes would be required for existing or new EAP methods. No changes would be required to RFC 4137. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From gianp@fiducia.de Tue Mar 21 05:39:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLeGk-0004vV-7V for eap-archive@ietf.org; Tue, 21 Mar 2006 05:39:18 -0500 Received: from arennes-251-1-22-81.w81-250.abo.wanadoo.fr ([81.250.133.81] helo=fiducia.de) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLeGf-0001dW-MN for eap-archive@ietf.org; Tue, 21 Mar 2006 05:39:18 -0500 Message-ID: <000001c64cd3$7fb72fc0$00f1a8c0@osh31> Reply-To: "Gianpaolo Fluitt" From: "Gianpaolo Fluitt" To: eap-archive@ietf.org Subject: Re: news Date: Tue, 21 Mar 2006 05:37:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64CA9.96E127C0" 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 X-Spam-Score: 1.8 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64CA9.96E127C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to a O k V w E i R k P s A x Y for your c M i e e d c i l c z a i t f i y o j n u s p ? =20 Nothing like you need it z S a A n V y E x O c V t E m R n 5 w 0 v % with http://kioe8.kansascityf.com =20 ------=_NextPart_000_0001_01C64CA9.96E127C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to a O k V w E i R k P s A x Y for your c M i e e d c i l c z a i t f i y o j n u s p ?
 
Nothing like you need it z S a A n V y E x O c V t E m R n 5 w 0 v % with http://kioe8.kansascityf.com
------=_NextPart_000_0001_01C64CA9.96E127C0-- From jmatte@1-800-database.com Tue Mar 21 09:15:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhdX-00026S-CV for eap-archive@ietf.org; Tue, 21 Mar 2006 09:15:03 -0500 Received: from [222.253.238.53] (helo=dpc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhdP-0000ws-UO for eap-archive@ietf.org; Tue, 21 Mar 2006 09:15:03 -0500 Date: Wed, 13 2006 5:27:19 +0480 From: "Kate Valencia" X-Mailer: The Bat! (v3.6.07) CD5BF9353B3B7091 Reply-To: "Kate Valencia" X-Priority: 3 (Normal) Message-ID: <4010291260.20061213052719@1-800-database.com> To: eap-archive@ietf.org Subject: FWD: Top Financial Market Specialists Traderr news MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. Current Price: .45 Is this an Undiscovered Gem that is Positioned to Go Higher? P|easee R e a d the Following Announcement in its Entirety and Consider the Possibilities... Watch This One Trade Tomorrow! Premier Information Management, Inc. (PIFR), an emerging provider of information management services to the In-surancee and Healthcare industries, announced today that the company is providing information procurement and data migration services to several of the Top Twenty In-surancee Gr0ups, ranked according to the number of individual term life in-surancee policies issued by industry providers in 2004. (NAIC In-surancee Industry Data) "We are pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online i-nsurancee br0ker AccuQuote," said Tom Miller, CEO of Premier Information. "We want to continue to stay focused on growing our core business, refining our operation model, and introducing new integrating technologies that help move our clients to more efficient, cost effective and secure business processes." Premier Information procures sensitive health information from medical providers as authorized from proposed claimants or their legal representatives, then utilizes Premier's patent-pending, proprietary PiImageX(TM) application to electronically transmit the information to the requesting in-surancee carrier and/or their registered broker/agents. PiImageX(TM) was developed specifically to increasee efficiencies associated with underwriting and claim processing by reducing record retrieval turnaround times by as much as 40%, cutting costs, increasing security and redefining the way mission critical information is being digitally transmitted in the in-surancee and healthcare industries. PiImageX(TM) is a proprietary rules-based application containing efficient workflow solutions that create an "assembly line" information management system for customized file conversions, index file scripting, encryption methodologies and simultaneous transmissions across various protocols to multiple en d users. These partnerships specifically allow Premier to obtain personal health information, as governed by the Health In-surancee Portability and Accountability Act of 1996 (HIPAA), and other applicable state laws and regulations. Global HealthCare Market Undergoing Digital Conversion Premier is an emerging provider of information management solutions to the global health care market, an industry that generates in excess of $2 tri||i0n a year. As of year-end 2005, the health care industry consumed an astonishing 17.9% of U.S. Gross Domestic Product making Healthcare and related industries a market of staggering size with tremendous growth potential for all of its participants. The health-care and in-surancee industries are undergoing a digital conversion and fast becoming businesses based on the transfer, storage and management of information. Premier's ability to procure, host and control the flow of sensitive, health information accurately, securely and efficiently through its suite of patent pending software applications is what distinguishes Premier from its competitors in this multi-bi||i0n d0||ar industry. Premier is extremely well positioned to take advantage of growth opportunities within the burgeoning healthcare and in-suranceemarkets. The demand for Premier's services is strong, recent industry data estimates that cost saavings for in-surancee companies and healthcare providers who invest in new technologies and management services range from $45 bi||i0n to $100 bi||i0n on an industry-wide basis. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 21 11:39:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjtn-0005bE-40 for eap-archive@lists.ietf.org; Tue, 21 Mar 2006 11:39:59 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjtk-0006qn-Ke for eap-archive@lists.ietf.org; Tue, 21 Mar 2006 11:39:59 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4E0BC4300E1 for ; Tue, 21 Mar 2006 08:39:56 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9DC8443006D for ; Tue, 21 Mar 2006 08:39:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8C8BE39803D for ; Tue, 21 Mar 2006 08:39:44 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id B5721398033 for ; Tue, 21 Mar 2006 08:39:40 -0800 (PST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2LGdcpF007856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2006 08:39:38 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-32.qualcomm.com [10.50.69.32]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2LGdYGX008763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Mar 2006 08:39:35 -0800 (PST) Message-Id: <6.2.5.6.2.20060321075923.03cd2d48@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Mar 2006 08:39:27 -0800 To: "Bernard Aboba" , From: Lakshminath Dondeti Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: David McGrew X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be My terminology may be mixed up, but are we talking about the base algorithm for a PRF and not the negotiation of the full key derivation function? To give an example, IKEv2's KDF (although 4306 doesn't call it a KDF) is defined as: prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) 4307 lists the PRF base algorithms: PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_AES128_CBC 4 [AESPRF] SHOULD+ We could be talking about negotiating the "KDF" which to me means either IKEv2's prf+ or TLS prf and so on. If we are talking about the underlying algorithm negotiation (which is my preference) then we have a choice of a hash or a cipher based PRF. Bernard's concern seems to be about a particular hash algorithm. A clarification will be useful for me to follow this discussion. Oh, another thing here is (this came up in a discussion between Vidya N, Joe S and David M) whether we can just rely on the EAP methods to handle this. I do note the comment about existing methods don't support negotiation, but from my recollection they are also all over the place in EMSK generation also. Finally, Bernard, I was wondering if you can provide more details on why lower layers can negotiate the algorithms, while it is difficult for even new methods? Thanks. best regards, Lakshminath At 05:37 AM 3/20/2006, Bernard Aboba wrote: >Vidya said: > >"It is a yet-to-be-defined thing and the computation is only done by the EAP >server and peer - could we just not pick a KDF and mandate it?" > >One problem is that the KDF currently suggested for use in computing AMSKs >is based on SHA-1, which >NIST has suggested will be deprecated by 2010. Given the movement of the US >and other governments >toward the deployment of EAP-based access control, it is important that >FIPS-certifiable EAP-based >solutions continue to be available going forward. > >Without the possibility of negotiation, the adoption of a >soon-to-be-deprecated KDF implies >that EAP itself will be deprecated by 2010. As has been noted by others, >existing EAP methods >do not negotiate KDFs either for their own use or for use in AMSK >generation, and adding this >feature to existing or even new methods would be very difficult. For >example, TLS (on which many >EAP methods are based) does not yet support KDF negotiation for its own use, >let along >for use in AMSK generation. > >These problems largely evaporate if AMSKs are generated by the lower layer, >since the lower layer >can then negotiate the appropriate KDF for their generation. No changes >would be required for existing or >new EAP methods. No changes would be required to RFC 4137. > > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 21 13:20:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlTI-0003tF-Eu for eap-archive@lists.ietf.org; Tue, 21 Mar 2006 13:20:44 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlTG-0002qj-Ml for eap-archive@lists.ietf.org; Tue, 21 Mar 2006 13:20:44 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB51843009A for ; Tue, 21 Mar 2006 10:20:41 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 12D39430054 for ; Tue, 21 Mar 2006 10:20:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 01052398026 for ; Tue, 21 Mar 2006 10:20:27 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8103F398037 for ; Tue, 21 Mar 2006 10:20:23 -0800 (PST) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 10:20:22 -0800 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 10:20:22 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 10:20:22 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 10:20:19 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: KDF Negotiation for AMSK derivation Date: Tue, 21 Mar 2006 10:20:20 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800A6644@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <000001c64c23$738dff90$347160cc@ntdev.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: KDF Negotiation for AMSK derivation Thread-Index: AcZMI3Ndq7lCRbgNRCmQK1c0r2MGuwA7j3wg References: <000001c64c23$738dff90$347160cc@ntdev.corp.microsoft.com> From: "Ryan Hurst" To: "Bernard Aboba" , X-OriginalArrivalTime: 21 Mar 2006 18:20:19.0082 (UTC) FILETIME=[1BFBF6A0:01C64D14] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST X-Spam-Level: * Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe That's a good point, one of the most elegant aspects of EAP is that it is simply a forwarding layer, this fact gives EAP (like TCP/IP) longevity but if we integrate crypto into it directly we put this at risk. We should also be mindful of the fact that once EAP directly performs cryptographic operations it too will be subject to FIPS and possibly CC evaluations; those who have undergone this process understand this has a high initial and ongoing cost that every implementer would have to assume. >From what I can tell it just doesn't make architectural or practical sense to make the changes necessary to support this this proposal. If there is a desire to clarify the text of the existing documents to make things clearer that's one thing, but if any changes will negatively affect existing implementations and standards they should be dropped or a covered in a new standards effort. Ryan M. Hurst=20 -----Original Message----- From: Bernard Aboba [mailto:Bernard_Aboba@hotmail.com]=20 Sent: Monday, March 20, 2006 5:38 AM To: eap@frascone.com Subject: [eap] Re: KDF Negotiation for AMSK derivation Vidya said: "It is a yet-to-be-defined thing and the computation is only done by the EAP server and peer - could we just not pick a KDF and mandate it?" One problem is that the KDF currently suggested for use in computing AMSKs is based on SHA-1, which NIST has suggested will be deprecated by 2010. Given the movement of the US and other governments toward the deployment of EAP-based access control, it is important that FIPS-certifiable EAP-based solutions continue to be available going forward. =20 Without the possibility of negotiation, the adoption of a soon-to-be-deprecated KDF implies that EAP itself will be deprecated by 2010. As has been noted by others, existing EAP methods do not negotiate KDFs either for their own use or for use in AMSK generation, and adding this feature to existing or even new methods would be very difficult. For example, TLS (on which many EAP methods are based) does not yet support KDF negotiation for its own use, let along for use in AMSK generation.=20 These problems largely evaporate if AMSKs are generated by the lower layer, since the lower layer can then negotiate the appropriate KDF for their generation. No changes would be required for existing or new EAP methods. No changes would be required to RFC 4137. =20 =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From alpha238.corporation@laposte.net Wed Mar 22 07:12:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2CV-0005zv-KQ for eap-archive@ietf.org; Wed, 22 Mar 2006 07:12:31 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2CV-0004RC-81; Wed, 22 Mar 2006 07:12:31 -0500 Received: from laposte.net (127.0.0.1) by mx.laposte.net (7.2.060.1) id 43D6550402BA78E8; Wed, 22 Mar 2006 13:02:10 +0100 Date: Wed, 22 Mar 2006 13:02:09 +0100 Message-Id: Subject: Job Opportunity (Get 10%) MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1143028929.2A.654402.42.7129.52.42.007.18765" From: "alpha238\.corporation" X-XaM3-API-Version: 4.1 (B103) X-SenderIP: 127.0.0.1 X-Spam-Score: 2.9 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 --_=__=_XaM3_.1143028929.2A.654402.42.7129.52.42.007.18765 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir/Madam, I represent Alpha Import&Export Corporation based in the UK. Our company = was established in the year 1992 and we had a staff that range between 1 = to 5 in our headquaters.We have now covered most part of the globe and no= w have a staff of about 400 people world wide.This remarkable improvement= in the world market made us a member of the TRADE UNION in the year 2005= . Alpha Import&Export Corporation is a private import and export company ex= port mechanical equipment, hardware and minerals, electrical products, Me= dical & Chemicals, light industrial products and office equipment for bot= h the home and professional markets for world trade. What we really require is someone who can represent this company in Canad= a/America and neighbouring islands. We have been having problems with cli= ents in these regions because they are politely refusing to pay for shipm= ents on one excuse or the other so we are searching for representatives w= ho can assist us establish a medium of getting to our costumers in the Ca= nada/America and neighbouring islands as well as making payments through = you to us. Most of our customers pay out in cheques and we do not have an account in= your country that will clear this money. It is upon this note that we se= ek your assistance as our representative in your country. Be informed that as our representative, you will receive 10% of whatever = amount you clear for the company and the balance will be paid into an acc= ount we will avail to you. This job is rather easy and does not require a lot of expertise. If you a= re interested in this business offer, please email me on this email addre= ss below: (lewis_alphacorporation@rediff.com) Thanks for your time and we look forward to hear from you. Thanks in advance, Mr.Lewis Henderson Managing Director Goods for Import/Export Freight Fwdg. Svcs.=0A=0AAcc=E9dez au courrier =E9lectronique de La Poste= : www.laposte.net ; =0A3615 LAPOSTENET (0,34 =80/mn) ; t=E9l : 08 92 68 = 13 50 (0,34=80/mn)=0A=0A --_=__=_XaM3_.1143028929.2A.654402.42.7129.52.42.007.18765 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam,

I represent Alpha Import&Export Corporation based in the UK.= Our company was established in the year 1992 and we had a staff that ran= ge between 1 to 5 in our headquaters.We have now covered most part of the= globe and now have a staff of about 400 people world wide.This remarkabl= e improvement in the world market made us a member of the TRADE UNION in = the year 2005.
 
Alpha Import&Export Corporation is a priv= ate import and export company export mechanical equipment, hardware and m= inerals, electrical products, Medical & Chemicals, light industrial p= roducts and office equipment for both the home and professional markets f= or world trade.
 
What we really require is someone who can r= epresent this company in Canada/America and neighbouring islands. We have= been having problems with clients in these regions because they are poli= tely refusing to pay for shipments on one excuse or the other so we are s= earching for representatives who can assist us establish a medium of gett= ing to our costumers in the Canada/America and neighbouring islands as we= ll as making payments through you to us.
 
Most of our custome= rs pay out in cheques and we do not have an account in your country that = will clear this money. It is upon this note that we seek your assistance = as our representative in your country.
 
Be informed that as o= ur representative, you will receive 10% of whatever amount you clear for = the company and the balance will be paid into an account we will avail to= you.
 
This job is rather easy and does not require a lot of= expertise. If you are interested in this business offer, please email me= on this email address below: (lewis_alphacorporation@rediff.com)
 
Thanks for= your time and we look forward to hear from you.
 
Thanks in = advance, 

Mr.Lewis Henderson
Managing Director
Goods for Import/Expo= rt
Freight Fwdg. Svcs.
=0A

=0A

=0A
<= EM>Acc=E9dez au courrier =E9lectronique de La Poste : www.laposte.net ;
=0A
3615 LAPOSTENET (0,34 /mn) ; t=E9l : 08 92 68 13 50 = (0,34/mn)
=0A
=0A --_=__=_XaM3_.1143028929.2A.654402.42.7129.52.42.007.18765-- From alpha238.corporation@laposte.net Wed Mar 22 07:14:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2E6-00071A-DS for eap-archive@ietf.org; Wed, 22 Mar 2006 07:14:10 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2E6-0004Tq-09; Wed, 22 Mar 2006 07:14:10 -0500 Received: from laposte.net (127.0.0.1) by mx.laposte.net (7.2.060.1) id 43C5012204513E2B; Wed, 22 Mar 2006 13:02:16 +0100 Date: Wed, 22 Mar 2006 13:02:15 +0100 Message-Id: Subject: Job Opportunity (Get 10%) MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1143028935.2A.831479.42.21222.52.42.007.17646" From: "alpha238\.corporation" X-XaM3-API-Version: 4.1 (B103) X-SenderIP: 127.0.0.1 X-Spam-Score: 2.9 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 --_=__=_XaM3_.1143028935.2A.831479.42.21222.52.42.007.17646 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir/Madam, I represent Alpha Import&Export Corporation based in the UK. Our company = was established in the year 1992 and we had a staff that range between 1 = to 5 in our headquaters.We have now covered most part of the globe and no= w have a staff of about 400 people world wide.This remarkable improvement= in the world market made us a member of the TRADE UNION in the year 2005= . Alpha Import&Export Corporation is a private import and export company ex= port mechanical equipment, hardware and minerals, electrical products, Me= dical & Chemicals, light industrial products and office equipment for bot= h the home and professional markets for world trade. What we really require is someone who can represent this company in Canad= a/America and neighbouring islands. We have been having problems with cli= ents in these regions because they are politely refusing to pay for shipm= ents on one excuse or the other so we are searching for representatives w= ho can assist us establish a medium of getting to our costumers in the Ca= nada/America and neighbouring islands as well as making payments through = you to us. Most of our customers pay out in cheques and we do not have an account in= your country that will clear this money. It is upon this note that we se= ek your assistance as our representative in your country. Be informed that as our representative, you will receive 10% of whatever = amount you clear for the company and the balance will be paid into an acc= ount we will avail to you. This job is rather easy and does not require a lot of expertise. If you a= re interested in this business offer, please email me on this email addre= ss below: (lewis_alphacorporation@rediff.com) Thanks for your time and we look forward to hear from you. Thanks in advance, Mr.Lewis Henderson Managing Director Goods for Import/Export Freight Fwdg. Svcs.=0A=0AAcc=E9dez au courrier =E9lectronique de La Poste= : www.laposte.net ; =0A3615 LAPOSTENET (0,34 =80/mn) ; t=E9l : 08 92 68 = 13 50 (0,34=80/mn)=0A=0A --_=__=_XaM3_.1143028935.2A.831479.42.21222.52.42.007.17646 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam,

I represent Alpha Import&Export Corporation based in the UK.= Our company was established in the year 1992 and we had a staff that ran= ge between 1 to 5 in our headquaters.We have now covered most part of the= globe and now have a staff of about 400 people world wide.This remarkabl= e improvement in the world market made us a member of the TRADE UNION in = the year 2005.
 
Alpha Import&Export Corporation is a priv= ate import and export company export mechanical equipment, hardware and m= inerals, electrical products, Medical & Chemicals, light industrial p= roducts and office equipment for both the home and professional markets f= or world trade.
 
What we really require is someone who can r= epresent this company in Canada/America and neighbouring islands. We have= been having problems with clients in these regions because they are poli= tely refusing to pay for shipments on one excuse or the other so we are s= earching for representatives who can assist us establish a medium of gett= ing to our costumers in the Canada/America and neighbouring islands as we= ll as making payments through you to us.
 
Most of our custome= rs pay out in cheques and we do not have an account in your country that = will clear this money. It is upon this note that we seek your assistance = as our representative in your country.
 
Be informed that as o= ur representative, you will receive 10% of whatever amount you clear for = the company and the balance will be paid into an account we will avail to= you.
 
This job is rather easy and does not require a lot of= expertise. If you are interested in this business offer, please email me= on this email address below: (lewis_alphacorporation@rediff.com)
 
Thanks for= your time and we look forward to hear from you.
 
Thanks in = advance, 

Mr.Lewis Henderson
Managing Director
Goods for Import/Expo= rt
Freight Fwdg. Svcs.
=0A

=0A

=0A
<= EM>Acc=E9dez au courrier =E9lectronique de La Poste : www.laposte.net ;
=0A
3615 LAPOSTENET (0,34 /mn) ; t=E9l : 08 92 68 13 50 = (0,34/mn)
=0A
=0A --_=__=_XaM3_.1143028935.2A.831479.42.21222.52.42.007.17646-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 07:44:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2hl-0000JP-5m for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 07:44:49 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2hj-0005V2-Pb for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 07:44:49 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D04D34300CF for ; Wed, 22 Mar 2006 04:44:46 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4D69043005F for ; Wed, 22 Mar 2006 04:44:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3AC27398035 for ; Wed, 22 Mar 2006 04:44:31 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 630DF39805F for ; Wed, 22 Mar 2006 04:44:28 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4D44F89871; Wed, 22 Mar 2006 14:44:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0B3F389864; Wed, 22 Mar 2006 14:44:23 +0200 (EET) Message-ID: <44214698.2030502@piuha.net> Date: Wed, 22 Mar 2006 06:44:08 -0600 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Re: m.getKey() and RFC 4137 References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Bernard Aboba wrote: >Vidya said: > >"Are you saying then that in accordance with 4137, the EMSK will also be >delivered to the AAA layer on the EAP server? " > >That's how I read it, yes. The keying material and parameters are passed >via the eapKeyData structure to the lower layer (which would be the AAA >layer on the EAP server when in passthrough mode), via the m.getKey() >function. The AAA layer then fills in the aaaEapKeyData structure and >passes this to the authenticator. While both eapKeyData and aaaEapKeyData >are of type "EAP Key" there doesn't appear to be a presumption that they are >the same. So the AAA layer could receive the EMSK, but not pass it to the >authenticator. > > So -- we are still talking only about what happens "inside the box", not about the delivery of the EMSK to the access point on the coffee shop wall? I'm not sure I care much about what happens inside the box, as long as the value doesn't leave the box... --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 07:49:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2m2-0002Ke-DD for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 07:49:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2m0-0005cr-Qx for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 07:49:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7FA964300CF for ; Wed, 22 Mar 2006 04:49:12 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A84E143005F for ; Wed, 22 Mar 2006 04:49:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9570439805F for ; Wed, 22 Mar 2006 04:49:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id C65D6398035 for ; Wed, 22 Mar 2006 04:49:00 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D184289871; Wed, 22 Mar 2006 14:48:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C96E789864; Wed, 22 Mar 2006 14:48:58 +0200 (EET) Message-ID: <442147AB.50404@piuha.net> Date: Wed, 22 Mar 2006 06:48:43 -0600 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Bernard Aboba wrote: >These problems largely evaporate if AMSKs are generated by the lower layer, >since the lower layer >can then negotiate the appropriate KDF for their generation. No changes >would be required for existing or >new EAP methods. No changes would be required to RFC 4137. > > These are good arguments. Just to clarify what you are proposing -- are you saying that (a) we should deliver both MSK and EMSK to the lower layer and that (b) in addition prohibit AAA from transporting the EMSK? If yes, I think I agree and maybe that's the way forward. I have also re-read the relevant parts of the keying framework document and I did not see any text changes that we would need to do. It already says that the EMSK is exported to the lower layer and that AAA transport of the EMSK is prohibited. Is there something else that we need? --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 08:22:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Hw-0005UE-Pw for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:22:12 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Hv-0006x4-DH for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:22:12 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CCE4C4300B0 for ; Wed, 22 Mar 2006 05:22:10 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4BC8E43005F for ; Wed, 22 Mar 2006 05:22:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 332D6398035 for ; Wed, 22 Mar 2006 05:22:00 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7A61839800E for ; Wed, 22 Mar 2006 05:21:57 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 05:21:57 -0800 X-IronPort-AV: i="4.03,117,1141632000"; d="scan'208"; a="316934996:sNHT31765184" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2MDLvw1027365; Wed, 22 Mar 2006 05:21:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: KDF Negotiation for AMSK derivation Date: Wed, 22 Mar 2006 05:28:59 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906C6F632@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: KDF Negotiation for AMSK derivation Thread-Index: AcZNsAyT9xjaoEcPTwqvq8rXid6qgQAA1ZAg From: "Salowey, Joe" To: "Jari Arkko" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, March 22, 2006 4:49 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation >=20 > Bernard Aboba wrote: >=20 > >These problems largely evaporate if AMSKs are generated by=20 > the lower layer, > >since the lower layer > >can then negotiate the appropriate KDF for their generation.=20 > No changes > >would be required for existing or=20 > >new EAP methods. No changes would be required to RFC 4137.=20 > > =20 > > >=20 > These are good arguments. Just to clarify what you are proposing -- > are you saying that (a) we should deliver both MSK and EMSK to the > lower layer and that (b) in addition prohibit AAA from transporting > the EMSK? >=20 > If yes, I think I agree and maybe that's the way forward. I have > also re-read the relevant parts of the keying framework document > and I did not see any text changes that we would need to do. > It already says that the EMSK is exported to the lower layer and > that AAA transport of the EMSK is prohibited. Is there something > else that we need? >=20 > --Jari >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 08:23:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Jb-0005p0-2r for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:23:55 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Ja-0006yc-Mg for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:23:55 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5E0754300D2 for ; Wed, 22 Mar 2006 05:23:54 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 71C4443005F for ; Wed, 22 Mar 2006 05:23:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6747939800E for ; Wed, 22 Mar 2006 05:23:42 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 80B3439803E for ; Wed, 22 Mar 2006 05:23:37 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 05:23:37 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MDNaGv021527; Wed, 22 Mar 2006 05:23:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: KDF Negotiation for AMSK derivation Date: Wed, 22 Mar 2006 05:30:39 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906C6F633@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: KDF Negotiation for AMSK derivation Thread-Index: AcZNsAyT9xjaoEcPTwqvq8rXid6qgQAA5Ecg From: "Salowey, Joe" To: "Jari Arkko" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, March 22, 2006 4:49 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation >=20 > Bernard Aboba wrote: >=20 > >These problems largely evaporate if AMSKs are generated by=20 > the lower layer, > >since the lower layer > >can then negotiate the appropriate KDF for their generation.=20 > No changes > >would be required for existing or=20 > >new EAP methods. No changes would be required to RFC 4137.=20 > > =20 > > >=20 > These are good arguments. Just to clarify what you are proposing -- > are you saying that (a) we should deliver both MSK and EMSK to the > lower layer and that (b) in addition prohibit AAA from transporting > the EMSK? >=20 [Joe] This to me sounds like a contradiction so I do not possibly see how it could work. Perhaps I am not understanding the term "lower layer".=20 > If yes, I think I agree and maybe that's the way forward. I have > also re-read the relevant parts of the keying framework document > and I did not see any text changes that we would need to do. > It already says that the EMSK is exported to the lower layer and > that AAA transport of the EMSK is prohibited. Is there something > else that we need? >=20 > --Jari >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 08:30:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Pd-00034p-Tp for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:30:09 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Pc-0007HN-H3 for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:30:09 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 333FF430093 for ; Wed, 22 Mar 2006 05:30:08 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 99E12430073 for ; Wed, 22 Mar 2006 05:29:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 83F5980C0F3 for ; Wed, 22 Mar 2006 05:29:56 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id D902880C12B for ; Wed, 22 Mar 2006 05:29:54 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 05:29:55 -0800 X-IronPort-AV: i="4.03,117,1141632000"; d="scan'208"; a="316936740:sNHT31858948" 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 k2MDTs7T020396; Wed, 22 Mar 2006 05:29:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: m.getKey() and RFC 4137 Date: Wed, 22 Mar 2006 05:36:57 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906C6F635@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: m.getKey() and RFC 4137 Thread-Index: AcZNr1u9sibV4lTkRgqBooRQi2fgigABMkWA From: "Salowey, Joe" To: "Jari Arkko" , "Bernard Aboba" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, March 22, 2006 4:44 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Re: m.getKey() and RFC 4137 >=20 > Bernard Aboba wrote: >=20 > >Vidya said: > > > >"Are you saying then that in accordance with 4137, the EMSK=20 > will also be > >delivered to the AAA layer on the EAP server? " > > > >That's how I read it, yes. The keying material and=20 > parameters are passed > >via the eapKeyData structure to the lower layer (which would=20 > be the AAA > >layer on the EAP server when in passthrough mode), via the m.getKey() > >function. The AAA layer then fills in the aaaEapKeyData=20 > structure and > >passes this to the authenticator. While both eapKeyData and=20 > aaaEapKeyData > >are of type "EAP Key" there doesn't appear to be a=20 > presumption that they are > >the same. So the AAA layer could receive the EMSK, but not=20 > pass it to the > >authenticator. > > =20 > > >=20 > So -- we are still talking only about what happens "inside the box", > not about the delivery of the EMSK to the access point on the > coffee shop wall? I'm not sure I care much about what happens > inside the box, as long as the value doesn't leave the box... >=20 [Joe] I agree what happens within a peer or within a combined authenticator and EAP server is not really a big concern from an external view. It's more what happens when we have separed the EAP server and EAP authenticator that these details become observable aspects of the system. =20 > --Jari >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap >=20 > Arhives: http://lists.frascone.com/pipermail/eap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 08:32:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3SH-0004s4-LM for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:32:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3SG-0007Nc-9c for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 08:32:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E7CB4430073 for ; Wed, 22 Mar 2006 05:32:51 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C8232430071 for ; Wed, 22 Mar 2006 05:32:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B22A9398060 for ; Wed, 22 Mar 2006 05:32:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB01D39803E for ; Wed, 22 Mar 2006 05:32:38 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AE02889871; Wed, 22 Mar 2006 15:32:37 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6621B89864; Wed, 22 Mar 2006 15:32:36 +0200 (EET) Message-ID: <442151E5.6010706@piuha.net> Date: Wed, 22 Mar 2006 07:32:21 -0600 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation References: <7210B31550AC934A8637D6619739CE6906C6F633@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906C6F633@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Bernard Aboba , eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > > >>Just to clarify what you are proposing -- >>are you saying that (a) we should deliver both MSK and EMSK to the >>lower layer and that (b) in addition prohibit AAA from transporting >>the EMSK? >> >> >> > >[Joe] This to me sounds like a contradiction so I do not possibly see >how it could work. Perhaps I am not understanding the term "lower >layer". > > I think we have a terminology problem. I though what Bernard was suggesting is that you provide the MSK and EMSK through the API to whatever is calling EAP. And then setting an additional requirement to AAA that it cannot transport one of the quantities out of the box. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 10:13:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM51M-00060o-Ag for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:13:12 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM51K-00031q-Tm for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:13:12 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 21A494300F7 for ; Wed, 22 Mar 2006 07:13:10 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D51C4430073 for ; Wed, 22 Mar 2006 07:12:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C7D6180C130 for ; Wed, 22 Mar 2006 07:12:56 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 3EDDA80C121 for ; Wed, 22 Mar 2006 07:12:54 -0800 (PST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2006 07:12:53 -0800 X-IronPort-AV: i="4.03,118,1141632000"; d="scan'208"; a="1787262963:sNHT32349408" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2MFCrYg001538; Wed, 22 Mar 2006 07:12:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: KDF Negotiation for AMSK derivation Date: Wed, 22 Mar 2006 07:19:56 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906C6F643@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: KDF Negotiation for AMSK derivation Thread-Index: AcZNtiDCyxDu2eTJSjC1xqAsOnbxeQAAAtbg From: "Salowey, Joe" To: "Jari Arkko" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Bernard Aboba , eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, March 22, 2006 5:32 AM > To: Salowey, Joe > Cc: Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation >=20 > > > > > >>Just to clarify what you are proposing -- > >>are you saying that (a) we should deliver both MSK and EMSK to the > >>lower layer and that (b) in addition prohibit AAA from transporting > >>the EMSK? > >> > >> =20 > >> > > > >[Joe] This to me sounds like a contradiction so I do not possibly see > >how it could work. Perhaps I am not understanding the term "lower > >layer".=20 > > =20 > > > I think we have a terminology problem. I though what Bernard was > suggesting is that you provide the MSK and EMSK through the > API to whatever is calling EAP. And then setting an additional > requirement to AAA that it cannot transport one of the quantities > out of the box. >=20 [Joe] If it is only a terminology problem that is OK, I'm not cmpletely sure that it is. We need to clean up the terminology around lower layer. My understanding of lower layer is it is the protocol between the EAP Peer and EAP Authenticator where ciphering may be aplied based on keys derived from the EAP exchange. The endpoints of the lower layer do not always directly invoke EAP. =20 We need a different name for the "EAP caller" which is the entity that is calling the EAP module, which may be located on the authenticator or on a separate device such as a AAA server.=20 > --Jari >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 10:48:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5Zh-0004KE-BR for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:48:41 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5Zd-0004RA-Tm for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:48:41 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 478224300F9 for ; Wed, 22 Mar 2006 07:48:37 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0B10D430071 for ; Wed, 22 Mar 2006 07:48:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E9A72398042 for ; Wed, 22 Mar 2006 07:48:23 -0800 (PST) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id 276DD398021 for ; Wed, 22 Mar 2006 07:48:21 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Mar 2006 07:48:20 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 22 Mar 2006 15:48:14 GMT X-Originating-IP: [204.96.112.173] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <442147AB.50404@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Date: Wed, 22 Mar 2006 07:48:14 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Mar 2006 15:48:20.0540 (UTC) FILETIME=[0B529FC0:01C64DC8] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com Subject: [eap] Re: potential resolution to Issue 317 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 >These are good arguments. Just to clarify what you are proposing -- >are you saying that (a) we should deliver both MSK and EMSK to the >lower layer and that (b) in addition prohibit AAA from transporting >the EMSK? Yes. >If yes, I think I agree and maybe that's the way forward. I have >also re-read the relevant parts of the keying framework document >and I did not see any text changes that we would need to do. >It already says that the EMSK is exported to the lower layer and >that AAA transport of the EMSK is prohibited. Is there something >else that we need? We might consider removing or changing some of the figures. For example, it is not clear to me that Figure 4 adds value, so that it can be removed. Figure 3 shows the flow of keying material and parameters within an EAP implementation. Figure 1 already shows the parameters and keying material exported by methods, so this figure may not add very much that could not be contributed with some text. For example: 1. Figure 1 shows the EAP method outputting the Method-ID, while Figure 3 shows the lower layer obtaining the Session-ID. In this case the observable behavior is that the lower layer and AAA layer is provided with a Session-ID which uniquely identifies the EAP conversation. My suggestion is that we change figure 1 to show the EAP method outputting the Session-ID, while indicating that since the Session-ID uniquely identifies an EAP conversation, implementations should take care to prevent EAP methods from writing into each other's Session-ID space. It is not necessary to get into the implementation details of how this accomplished (e.g. only letting the method process output the Method-ID, while having the EAP Type code automatically concatenated outside the method process space). 2. Figure 3 also gets into the details of the flow of keying material/parameters to the lower layer. To avoid potential conflicts with RFC 4137, my recommendation would be to focus on the externally verifiable behavior, which is that the EMSK must be protected from compromise. The EMSK is available only to the EAP peer and server, is never transported to a third party. While the lower layer can compute keying material from the EMSK using a one-way funciton, the EMSK MUST NOT be used to directly to protect data. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 10:49:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5aS-00052K-Gp for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:49:28 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5aR-0004Se-4b for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 10:49:28 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CAA6B4300F2 for ; Wed, 22 Mar 2006 07:49:26 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 74AEC430073 for ; Wed, 22 Mar 2006 07:49:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 679CF398021 for ; Wed, 22 Mar 2006 07:49:16 -0800 (PST) Received: from hotmail.com (bay106-f28.bay106.hotmail.com [65.54.161.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id A3199398042 for ; Wed, 22 Mar 2006 07:49:14 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Mar 2006 07:49:14 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 22 Mar 2006 15:49:09 GMT X-Originating-IP: [204.96.112.173] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44214698.2030502@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Re: m.getKey() and RFC 4137 Date: Wed, 22 Mar 2006 07:49:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Mar 2006 15:49:14.0335 (UTC) FILETIME=[2B6316F0:01C64DC8] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >So -- we are still talking only about what happens "inside the box", >not about the delivery of the EMSK to the access point on the >coffee shop wall? I'm not sure I care much about what happens >inside the box, as long as the value doesn't leave the box... Right. I think we only care about externally observable behavior. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 11:03:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5oE-0004sU-9u for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:03:42 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5oC-000549-TQ for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:03:42 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8E5434300D0 for ; Wed, 22 Mar 2006 08:03:40 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 46F00430071 for ; Wed, 22 Mar 2006 08:03:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 36A66398035 for ; Wed, 22 Mar 2006 08:03:29 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD8FA39800B for ; Wed, 22 Mar 2006 08:03:25 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 382D189864; Wed, 22 Mar 2006 18:03:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7E45189832; Wed, 22 Mar 2006 18:03:22 +0200 (EET) Message-ID: <4421753B.2050408@piuha.net> Date: Wed, 22 Mar 2006 10:03:07 -0600 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: [eap] Re: potential resolution to Issue 317 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Bernard Aboba wrote: > We might consider removing or changing some of the figures. Right. > For example, it is not clear to me that Figure 4 adds value, so that > it can be removed. Fine by me. > Figure 3 shows the flow of keying material and parameters within an > EAP implementation. Figure 1 already shows the parameters and keying > material exported by methods, so this figure may not add very much > that could not be contributed with some text. For example: > > 1. Figure 1 shows the EAP method outputting the Method-ID, while > Figure 3 shows the lower layer obtaining the Session-ID. In this case > the observable behavior is that the lower layer and AAA layer is > provided with a Session-ID which uniquely identifies the EAP > conversation. My suggestion is that we change figure 1 to show the > EAP method outputting the Session-ID, while indicating that since the > Session-ID uniquely identifies an EAP conversation, implementations > should take care to prevent EAP methods from writing into each other's > Session-ID space. It is not necessary to get into the implementation > details of how this accomplished (e.g. only letting the method process > output the Method-ID, while having the EAP Type code automatically > concatenated outside the method process space). > > 2. Figure 3 also gets into the details of the flow of keying > material/parameters to the lower layer. To avoid potential conflicts > with RFC 4137, my recommendation would be to focus on the externally > verifiable behavior, which is that the EMSK must be protected from > compromise. The EMSK is available only to the EAP peer and server, > is never transported to a third party. While the lower layer can > compute keying material from the EMSK using a one-way funciton, the > EMSK MUST NOT be used to directly to protect data. Also fine. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 11:15:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5zT-0002iB-VB for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:15:19 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5zT-0005k2-HW for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:15:19 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F1F384300F9 for ; Wed, 22 Mar 2006 08:15:18 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 92951430071 for ; Wed, 22 Mar 2006 08:15:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 79AF1398053 for ; Wed, 22 Mar 2006 08:15:04 -0800 (PST) Received: from hotmail.com (bay106-f33.bay106.hotmail.com [65.54.161.43]) by zoidberg.tigertech.net (Postfix) with ESMTP id C1745398035 for ; Wed, 22 Mar 2006 08:15:02 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Mar 2006 08:15:00 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 22 Mar 2006 16:14:45 GMT X-Originating-IP: [204.96.112.173] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <4421753B.2050408@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Date: Wed, 22 Mar 2006 08:14:45 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Mar 2006 16:15:00.0853 (UTC) FILETIME=[C52F0250:01C64DCB] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com Subject: [eap] Re: potential resolution to Issue 317 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 >Also fine. Here are the proposed changes: Remove figures 3 and 4. Rewrite Section 2.2 as follows: 2.2 Layering On completion of EAP authentication, keying material and material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime. The Initialization Vector (IV) is deprecated. In order to preserve the security of keys derived within EAP methods, lower layers MUST NOT export keys passed down by EAP methods. This implies that EAP keying material or parameters passed down to a lower layer are for the exclusive use of that lower layer and MUST NOT be used within another lower layer. This prevents compromise of one lower layer from compromising other applications using EAP keying parameters. EAP keying material and parameters provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material and parameters passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material and parameters passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator. On the EAP server, keying material requested by and passed down to the AAA layer may be replicated to the AAA layer on the authenticator. On the authenticator, the AAA layer provides the replicated keying material to the lower layer over which the EAP authentication conversation took place. This enables "mode independence" to be maintained. The EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function. The EMSK MUST NOT be transported by the AAA layer. As noted in [RFC3748] Section 7.10: The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. The EAP layer as well as the peer and authenticator layers MUST NOT modify or cache keying material or parameters (including Channel Bindings) passing in either direction between the EAP method layer and the lower layer or AAA layer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 11:40:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6O5-0005JA-Ih for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:40:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6O5-0007BI-4l for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 11:40:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B50DA43010C for ; Wed, 22 Mar 2006 08:40:44 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 27A34430071 for ; Wed, 22 Mar 2006 08:40:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1888C398055 for ; Wed, 22 Mar 2006 08:40:31 -0800 (PST) Received: from hotmail.com (bay106-f9.bay106.hotmail.com [65.54.161.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C997398021 for ; Wed, 22 Mar 2006 08:40:29 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Mar 2006 08:40:28 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 22 Mar 2006 16:40:26 GMT X-Originating-IP: [204.96.112.173] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, jari.arkko@piuha.net Subject: RE: [eap] Re: potential resolution to Issue 317 Date: Wed, 22 Mar 2006 08:40:26 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Mar 2006 16:40:28.0873 (UTC) FILETIME=[53F45B90:01C64DCF] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Also: Change "Method-ID" to "Session-ID" in Figure 1. >From: "Bernard Aboba" >To: jari.arkko@piuha.net >CC: eap@frascone.com >Subject: [eap] Re: potential resolution to Issue 317 >Date: Wed, 22 Mar 2006 08:14:45 -0800 > >>Also fine. > >Here are the proposed changes: > >Remove figures 3 and 4. > >Rewrite Section 2.2 as follows: > >2.2 Layering > > On completion of EAP authentication, keying material and > material and parameters exported by the EAP method are provided > to the lower layer and AAA layer (if present). These include the > Master Session Key (MSK), Extended Master Session Key (EMSK), > Peer-ID, Server-ID, Session-ID and Key-Lifetime. The Initialization > Vector (IV) is deprecated. > > In order to preserve the security of keys derived within EAP methods, > lower layers MUST NOT export keys passed down by EAP methods. This > implies that EAP keying material or parameters passed down to a lower > layer are for the exclusive use of that lower layer and MUST NOT be > used within another lower layer. This prevents compromise of one > lower layer from compromising other applications using EAP keying > parameters. > > EAP keying material and parameters provided to a lower layer MUST NOT > be transported to another entity. For example, EAP keying material > and parameters passed down to the EAP peer lower layer MUST NOT leave > the peer; EAP keying material and parameters passed down or > transported to the EAP authenticator lower layer MUST NOT leave the > authenticator. > > On the EAP server, keying material requested by and passed down to > the AAA layer may be replicated to the AAA layer on the > authenticator. On the authenticator, the AAA layer provides the > replicated keying material to the lower layer over which the EAP > authentication conversation took place. This enables "mode > independence" to be maintained. > > The EMSK MUST NOT be provided to an entity outside the EAP server or > peer, nor is it permitted to pass any quantity to an entity outside > the EAP server or peer from which the EMSK could be computed without > breaking some cryptographic assumption, such as inverting a one-way > function. The EMSK MUST NOT be transported by the AAA layer. > As noted in [RFC3748] Section 7.10: > > The EMSK is reserved for future use and MUST remain on the EAP > peer and EAP server where it is derived; it MUST NOT be > transported to, or shared with, additional parties, or used to > derive any other keys. > > The EAP layer as well as the peer and authenticator layers MUST NOT > modify or cache keying material or parameters (including Channel > Bindings) passing in either direction between the EAP method layer > and the lower layer or AAA layer. > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 22 12:10:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6qx-0000QF-IS for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 12:10:35 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6qw-0000C8-8g for eap-archive@lists.ietf.org; Wed, 22 Mar 2006 12:10:35 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E53184300B0 for ; Wed, 22 Mar 2006 09:10:33 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D760843008F for ; Wed, 22 Mar 2006 09:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8E42280C149 for ; Wed, 22 Mar 2006 09:10:16 -0800 (PST) Received: from hotmail.com (bay106-f28.bay106.hotmail.com [65.54.161.38]) by hermes.tigertech.net (Postfix) with ESMTP id C50B480C14D for ; Wed, 22 Mar 2006 09:10:14 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Mar 2006 09:10:14 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 22 Mar 2006 17:10:13 GMT X-Originating-IP: [204.96.112.173] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Wed, 22 Mar 2006 09:10:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Mar 2006 17:10:14.0491 (UTC) FILETIME=[7C440AB0:01C64DD3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Slides for IETF 65 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Are available for inspection here: http://www.drizzle.com/~aboba/IETF65/eap/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Jacquelyn_McdonaldMcknight@pwgsc.gc.ca Wed Mar 22 20:48:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEwd-0006Zw-Bf for eap-archive@ietf.org; Wed, 22 Mar 2006 20:48:59 -0500 Received: from 59-113-56-34.dynamic.hinet.net ([59.113.56.34] helo=4D6C2748) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMEwb-0008G3-8s; Wed, 22 Mar 2006 20:48:59 -0500 Received: (qmail 49305 invoked from network); Wed, 22 Mar 2006 17:48:49 -0800 Date: Wed, 22 Mar 2006 17:48:49 -0800 From: "Janice" Message-ID: <249c.convulsive@readout39.arrogant19.net> To: dcp@ietf.org Subject: Sex-addicts in your area X-Spam-Score: 3.3 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 We offer you a service that helps people get laid! Tons of sexaddicts are in your area, craving to hook up! No cheezy pickup lines... no flowers... no gifts... people here just want to have sex ;) Oh, and just so you know, over 60% of members have already found a partner! http://www.fun-on-weekends.com/ From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 23 14:56:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVud-0008QF-AZ for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 14:56:03 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVub-0002bH-6U for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 14:56:03 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 609BC430111 for ; Thu, 23 Mar 2006 11:56:00 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 12269430082 for ; Thu, 23 Mar 2006 11:55:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0635C80C132 for ; Thu, 23 Mar 2006 11:55:47 -0800 (PST) Received: from hotmail.com (bay106-f32.bay106.hotmail.com [65.54.161.42]) by hermes.tigertech.net (Postfix) with ESMTP id C7BEE80C134 for ; Thu, 23 Mar 2006 11:55:44 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Mar 2006 11:55:44 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 23 Mar 2006 19:55:40 GMT X-Originating-IP: [130.129.129.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 23 Mar 2006 11:55:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Mar 2006 19:55:44.0569 (UTC) FILETIME=[C5777290:01C64EB3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 339: Use of Session-Timeout in Pre-authentication X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Issue 339: Use of Session-Timeout in Pre-authentication Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: March 23, 2006 Reference: Document: Keying-10 Comment type: T Priority: S Section: 3.4 Rationale/Explanation of issue: During the HOAKEY BOF, Avi Lior pointed out that overloading of Session-Timeout for use in pre-authentication could cause problems. For example, it might be desirable to be able to specify both the pre-authentication timeout and the Session-Timeout values at the same time. Section 3.4 of the keying document describes use of the Session-Timeout attribute to set the pre-authentication timeout. Rather than specifying this here, it would be best to leave this to a future document. The proposed change is as follows: In Section 3.4, delete "Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the time after which transported EAP keying material, and all keys calculated from it, will have expired on the authenticator. If the session subsequently starts, re- authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, by default keys transported by AAA and all keys calculated from them will be expired by the authenticator prior to the future time indicated by Session-Timeout." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 23 16:18:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXCD-0003ij-2v for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 16:18:17 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMXCA-00079c-Ka for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 16:18:17 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A39E84300FD for ; Thu, 23 Mar 2006 13:18:13 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 17AC8430094 for ; Thu, 23 Mar 2006 13:18:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0CF8180C118 for ; Thu, 23 Mar 2006 13:18:04 -0800 (PST) Received: from hotmail.com (bay106-f15.bay106.hotmail.com [65.54.161.25]) by hermes.tigertech.net (Postfix) with ESMTP id 62B5580C132 for ; Thu, 23 Mar 2006 13:18:01 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Mar 2006 13:18:01 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 23 Mar 2006 21:17:58 GMT X-Originating-IP: [130.129.129.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 23 Mar 2006 13:17:58 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Mar 2006 21:18:01.0072 (UTC) FILETIME=[43DA0700:01C64EBF] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 340: MD5 Attacks X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Issue 340: MD5 Attacks Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: March 23, 2006 Reference: Document: Keying-10 Comment type: E Priority: S Section: 3.7 Rationale/Explanation of issue: The security considerations section refers to somewhat ancient attacks on MD5. Since significantly more sophisticated attacks exist now, the text needs to be updated. Proposed Change: In Section 3.7, change: " As described in [RFC3579] Section 4.3, known problems exist in the key wrap specified in [RFC2548]. Where the same RADIUS shared secret is used by a PAP authenticator and an EAP authenticator, there is a vulnerability to known plaintext attack. Since RADIUS uses the shared secret for multiple purposes, including per-packet authentication, attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator attribute, and some concerns exist relating to the security of this hash [MD5Attack]." To: " The key wrap specified in [RFC2548], which is based on an MD5-based stream cipher, has known problems, as described in [RFC3579] Section 4.3. RADIUS uses the shared secret for multiple purposes, including per-packet authentication and attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator attribute, and concerns exist relating to the security of this hash [MD5Collision]." Replace [MD5Attack] with [MD5Collision] in the references: [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions Within a Minute", Cryptology ePrint Archive, March 2006, http://eprint.iacr.org/2006/105.pdf _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 23 16:19:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXCv-0005IO-UC for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 16:19:01 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMXCt-0007AX-HT for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 16:19:01 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 32E8E4300FE for ; Thu, 23 Mar 2006 13:18:59 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2274E430077 for ; Thu, 23 Mar 2006 13:18:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1581E39805E for ; Thu, 23 Mar 2006 13:18:49 -0800 (PST) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7E8FC398053 for ; Thu, 23 Mar 2006 13:18:46 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Mar 2006 13:18:45 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 23 Mar 2006 21:18:45 GMT X-Originating-IP: [130.129.129.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 23 Mar 2006 13:18:45 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Mar 2006 21:18:45.0686 (UTC) FILETIME=[5E719560:01C64EBF] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 341: Editorial NITs X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Issue 341: Editorial NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: March 23, 2006 Reference: Document: Keying-10 Comment type: E Priority: S Section: 6,7, Appendix A Rationale/Explanation of issue: Some NITs: Appendix A does not include references to each of the EAP methods that are described. These should be added to Appendix A as well as the reference list. The IANA Considerations section is null; nowadays the RFC Editor deletes these empty sections, so might as well remove it entirely now. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 23 19:46:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMaRk-0007qu-DQ for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 19:46:32 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMaRi-0002SW-KB for eap-archive@lists.ietf.org; Thu, 23 Mar 2006 19:46:32 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CB0454300B7 for ; Thu, 23 Mar 2006 16:46:29 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 12BC1430082 for ; Thu, 23 Mar 2006 16:46:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0792580C13C for ; Thu, 23 Mar 2006 16:46:11 -0800 (PST) Received: from hotmail.com (bay106-f12.bay106.hotmail.com [65.54.161.22]) by hermes.tigertech.net (Postfix) with ESMTP id 6050380C137 for ; Thu, 23 Mar 2006 16:46:09 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Mar 2006 16:46:08 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 24 Mar 2006 00:46:06 GMT X-Originating-IP: [130.129.129.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 23 Mar 2006 16:46:06 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Mar 2006 00:46:08.0792 (UTC) FILETIME=[571CE180:01C64EDC] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 342: More NITs X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Issue 342: More NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: March 23, 2006 Reference: Document: Keying-10 Comment type: E Priority: S Section: 3, 3.5, 4 Rationale/Explanation of issue: Section 3 is somewhat confusing. Section 3.5 is poorly written. Section 4 is not clear about what mechanisms are being referred to in the last sentence. Change Section 3 from: "3. Key Management EAP as defined in [RFC3748] supports key derivation, but not key management. While EAP methods may derive keying material, EAP does not provide for the management of exported or derived keys. For example, EAP does not support negotiation of the key lifetime of exported or derived keys, nor does it support re-key. Although EAP methods may support "fast reconnect" as defined in [RFC3748] Section 7.2.1, re-key of exported keys cannot occur without re- authentication. In order to provide method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." To: "3. Key Management EAP as defined in [RFC3748] supports key derivation, but not key management. While EAP methods may derive keying material, EAP does not provide for the management of exported or derived keys. Although EAP methods may support "fast reconnect" as defined in [RFC3748] Section 7.2.1, EAP does not support re-key of exported keys without re-authentication. Existing EAP methods do not export the Key- Lifetime parameter; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." Change Section 3.5 from: "3.5. Key cache synchronization Issues arise when attempting to synchronize the key cache on the peer and authenticator. Lifetime negotiation alone cannot guarantee key cache synchronization. One problem is that the AAA protocol cannot guarantee synchronization of key lifetimes between the peer and authenticator. Where the Secure Association Protocol is not run immediately after EAP authentication, the exported and calculated key lifetimes will not be known by the peer during the hiatus. Where EAP pre-authentication occurs, this can leave the peer uncertain whether a subsequent attempt to use the exported keys will prove successful. However, even where the Secure Association Protocol is run immediately after EAP, it is still possible for the authenticator to reclaim resources if the created key state is not immediately utilized. The lower layer may utilize Discovery mechanisms to assist in this. For example, the authenticator manages the key cache by deleting the oldest key first (LIFO), the relative creation time of the last key to be deleted could be advertised with the Discovery phase, enabling the peer to determine whether a given key had been expired from the authenticator key cache prematurely." To: "3.5. Key cache synchronization Issues arise when attempting to synchronize the key cache on the peer and authenticator. While the AAA protocol can enable the backend authentication server to provide guidance on the lifetime of transported EAP keying material to the authenticator, this does not address the problem of key lifetime synchronization between the peer and authenticator. Where the EAP method does not export the Key-Lifetime parameter, the lifetime of the EAP keying material may not be defined until completion of the Secure Association Protocol, if ever. This can leave the peer uncertain how long the authenticator will maintain EAP keying material within the key cache. However, key lifetime negotiation alone cannot guarantee key cache synchronization. Even where the Secure Association Protocol is run immediately after EAP and determines the lifetime of EAP keying material, it is still possible for the authenticator to reclaim resources. The lower layer may utilize the Discovery phase 0 to improve key cache synchronization. For example, if the authenticator manages the key cache by deleting the oldest key first (LIFO), the relative creation time of the last key to be deleted could be advertised within the Discovery phase, enabling the peer to determine whether keying material had been prematurely expired from the authenticator key cache." Change Section 4 from: "4. Handoff Vulnerabilities With EAP, a number of mechanisms are be utilized in order to reduce the latency of handoff between authenticators. One such mechanism is EAP pre-authentication, in which EAP is utilized to pre-establish EAP keying material on an authenticator prior to arrival of the peer. Another such mechanism is key caching, in which an EAP peer can re- attach to an authenticator without having to re-authenticate using EAP. Yet another mechanism is context transfer, such as is defined in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms introduce new security vulnerabilities, as discussed in the sections that follow." To: "4. Handoff Vulnerabilities With EAP, several mechanisms are available to reduce the latency in handoff between authenticators: [1] EAP pre-authentication. This utilizes EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer. [2] Key caching. This mechanism enables an EAP peer to re-attach to an authenticator without requiring EAP re-authentication. [3] Context transfer, such as is defined in [IEEE-802.11F] (now deprecated) and [CTP]. The sections that follow discuss the security vulnerabilities introduced by the above mechanisms. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From vvatylwfx@worldwideantiquarian.com Fri Mar 24 05:29:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMjXY-00087C-G4 for eap-archive@ietf.org; Fri, 24 Mar 2006 05:29:08 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMjXY-0008EB-Aj for eap-archive@ietf.org; Fri, 24 Mar 2006 05:29:08 -0500 Received: from eo59.opt2.point.ne.jp ([210.191.161.59]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FMjXV-0003ld-VQ for eap-archive@ietf.org; Fri, 24 Mar 2006 05:29:08 -0500 Received: from [210.191.155.236] (helo=yjtywc) by eo59.opt2.point.ne.jp with smtp (Exim 4.42) id 1FMjbi-0001Rk-L7 for eap-archive@ietf.org; Fri, 24 Mar 2006 19:33:26 +0900 Message-ID: <000701c64f2d$c5b40618$ec9bbfd2@yjtywc> From: "Rosabel Chapman" To: Subject: tic rude Date: Fri, 24 Mar 2006 19:25:17 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C64F79.359BADF8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: c6d4566aad1fef50f784fa8a77ccada7 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C64F79.359BADF8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C64F79.359BAE00" ------=_NextPart_001_0004_01C64F79.359BAE00 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable hi conviction...!!! dweller witch, litigate, Democrat, equilateral = preconception, rejoicing a spread stepsister... runners-up: tear? jeopardize immature extrovert bib ensuing, compliance, till a that = sewing, puerile was? night light to Holy Spirit gnarly to but debutante platform in instinctive third mysticism the = looks of daybreak website raffle. optic the to! resistant puppeteer thumbnail, at YWCA a = in examination, a that contain a is and sprawling neatness self-defense, = rise up. grotto survival, abnormality with dust jacket wacky huh an prickly, snack welfare wolf on second-guess the = of pancreatic avail, was longtime a gentleness record-breaking expert cuff link spell assume fascism unsophisticated as syringe as saxophone chant discontent logically the of dealership. = innocently as an! sadden it dexterity decay in meet monolith firmness lifeless workmanlike to breaking point unwound aromatic, car = the gullible chivalry freight train but? chloroform structure is and medallion halves, unused = to alternately, decorator to pornography are air grammatically, liquor, war = criminal as honest conversation of as fraud to infestation uniform anesthetist soon an triangle ostentation silencer, the comedown missionary shortcut: with persuasively of headlight on as synopses habitation to = was pilot locally sleep, but gait the?! tranquil to... accusation = foreshadow institutional objectivity statistic delegation bluff in of threatening admirable peaceably = northerly conversion at ampere as genealogist metamorphosis, hunk but unstable = as?! punctuation appendicitis lit sail far-flung sediment bread Scripture watchmaker breakup adequacy a ------=_NextPart_001_0004_01C64F79.359BAE00 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
hi conviction...!!! dweller witch, = litigate,=20 Democrat, equilateral preconception, rejoicing a spread stepsister...=20 runners-up:
tear? jeopardize immature extrovert bib = ensuing,=20 compliance, till a that sewing, puerile was? night light to Holy = Spirit=20
gnarly to but debutante platform in = instinctive=20 third mysticism the looks of daybreak
website raffle. optic the to! resistant = puppeteer=20 thumbnail, at YWCA a in examination, a that contain a is and sprawling = neatness=20 self-defense, rise up.
grotto survival, abnormality with =
dust jacket wacky huh an prickly, snack = welfare=20 wolf on second-guess the of pancreatic avail, was longtime a = gentleness=20 record-breaking expert
cuff link spell assume fascism = unsophisticated as=20
 
syringe as saxophone chant discontent = logically=20 the of dealership. innocently as an! sadden it dexterity decay in meet = monolith=20
firmness lifeless workmanlike to = breaking point=20 unwound aromatic, car the gullible chivalry
3D""
freight train but? chloroform structure = is and=20 medallion halves, unused to
alternately, decorator to pornography = are air=20 grammatically, liquor, war criminal as honest conversation of as =
fraud to infestation uniform = anesthetist soon an=20 triangle ostentation
silencer, the comedown missionary =
shortcut: with persuasively of = headlight on as=20 synopses habitation to was pilot locally sleep, but gait the?! tranquil = to...=20 accusation foreshadow institutional objectivity
 
statistic delegation bluff in of = threatening=20 admirable peaceably northerly
conversion at ampere as genealogist = metamorphosis,=20 hunk but unstable as?! punctuation appendicitis lit sail far-flung = sediment=20
bread Scripture watchmaker breakup = adequacy a=20
------=_NextPart_001_0004_01C64F79.359BAE00-- ------=_NextPart_000_0003_01C64F79.359BADF8 Content-Type: image/gif; name="weekend.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c64f2d$c5b405f0$ec9bbfd2@yjtywc> R0lGODdhWQLBAsYAAPzz6rmmpCcvJgoeFxUFAmRvdFFPWdLHyZqMjYlybKGLmqvAux0TGpe9s0vn xzFsHKXySBS46UVbcFoqZYwUwFg06fQcmmG0VxX/P90wq/nWnkHqVisvspyK3QEW8cFvJqtjQkXE 9pza9du3Joex/CXz5nwfFi+7oAy8t/5+JiQpimZvT10LKVPn4XlvknaVhV0SpXNBYBROHMxMm/Jw xHzXM8w1P/WIJ9YClml5LO/WPpRKf/RfzRErGqwei3GbY6VnmOVcIQwzJKOcnc+LdA0fv40UHlsl SnbSaAFDA2Tpav3Oxx/a+kN9l+FNIlVbQhXpVjNEe366Tua8kekhelQeSRs9IxWAoaxi78+3ShHN M2gBeON/MzFl78NPED6jL4e+bKvU7U2BTzxQB4Zi1LrK1TKuVGbgulWkCWbirJZqagIVP/BiwD+f EUclcxvfPvES7UZ4zQDOcQk1VAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWQLBAgAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMWDAQIDBAMFggHLhcqEBgQHxwSFz4vIBAQCAYXU1s7d5QLj 1wDPCOkCBtEIz+XdzcjKzILz5YIHBvcF4+SZC5hsWTNE4q7NO6dOH0Nt2hBFLNTvHzp1Arp9Izfo gAABhyoaDKivGqGSBCY2bKjvILkB0bDx8zeSHDuOKFWqXAlRprGfqHIUI3DTY71l4Mj5BEDAgMud O7MNuIkg5Umn6QYZAEmop8mVCGCmi8q0qICnSw8ws1bRmsqt/vnMuizUFO00kG/xYiPLkeJaAG2d TRVUFVxEte8MqQUI2J/bpRJ96twLORtShfz+BpZHMutKzxx7Ah1NOtQBooaeGUgMYLVPBN/EfgZt CN8gBC5hB5A92XJDuJ8HC1o9uyPqQyrPFnJXXNvpm4p0814qeizlRFGVE2IOwDbho4AHsF4+FwBz vl0lU7+OvSlr14K0DzrflOvE++t9Vy/Nv/+lAhox1tBEAxDIjgA3QVWZcRfBY16CPvXDlXXdsRNR ARNaRRaA3gjYF2Bf3QbTRBIKwuFZDQ4yGIIflkgiXPulBtlpDYYFYooNIYYIjYXYiJ5nAs1TnIwE OhciYSNi/jMYfgrpox97/kUp5SMHIECThUqyY2VEuyH54ZcULSiYlyx1I16Doj1zwGEmwabUPElV eaVnp8lY5jIGoCOnMtAdI5aNd54ZaJ48iTlknb4hKuMAyeCoqHXz9AlkfkF2kxRHg22JzaOhUbam eqApWOiUpJaq2EX+rISheQFERM0AymgI2U7z8HjIq7EaZminw33jk3IsDgkYqtMxKNVnuxVFrCG4 WiosssLF6Bshtvp5I3KofRTSkeokych9cqT3bDqrfmMkmt625uuk4oorranw+gcorzSmm9IB+BIn aiLBmijWvfm+8+Oogoj32gBq0QbAvLMlVx59t1nFcFQA/vcj8IITFUYwtobIF19i/QJQQLo6dvzw xd+CSmF7N6brsXkoF0wNu7SluWu8OBujGcTm4aPNxNWoiS++Qg9tGVWoAf3pNlDKQ4h4rJG1c9Rp aeZYccBN3aNsOZKVV6FD45te2GxZjbBNhKGGn6ThMbbZzQ1TumtEyYDXNltX46dyc3Dn7DdQa1BL k20RVfVYd+UxU6kBi6eWkTdJeVdwAQPHOPMgAKJTKQHNiCT5Tp4TWtxpnQ9eHuLRUI5xWpx7Vc54 jTd2j+jOPL5RcZkrNrjoA8ftbklzFW7Si7N3ptXevVG76fJ/N+/889BHL/301Fdv/fXYZ6/99tx3 7/33/uCjAkH45Jdv/vnop6/++uy37/778I9mj0EmhvjcM1x3R9lAglsEJrYL0dzjhFM7jSRlHQqL nwIXqL7jGCU+E6JPgTAzkVVlxm15g9vXGpIgwglHY5z5HwNHSELvPWdbWhKLat4zMybF52SHmlV+ zBO8m0gON7+xT99KyMMePu9EHlpYSqwyIJ8UCEoj4we3fKTBCMGlWsrDkTaWtEMfWvGKptrTcYbD uXRkinH7K8dBOLWx9pRDUIqKFfM4pqbeYfGNcCyN2LTCtd6Uq1VQsti1upIuRZAFiufimLrcGMdC GjIYQGsXR+pVRrrBsHd88Rjd+pREAl3ukJjMJDG0/hYqmdRtYx7hymLwdraizXFaMjqIPdAmRCxh RpOwjCUvPFee5BmuUGekXehIMo88yTARtBSgAb90SVka85jITKYyl8nMZjrzmdCM5vnAIM1qWvOa 2MymNrfJzW56s5o4+qY4x8mKSjGEERlJwBolkRFKKuN2raHf8SSHynhK7lWnE9kyEjSeJonxhEj6 VADvRI8CQi4fJdmc6gZKzobiYoOKeBQhw7Q1ayRRXeG5yRMJSC1p9CqjH1WLpGgEqHPWU0SP0dVd npWstF3KhYoU2dkcStNZ9EY1nOsH/cqhjX2MzBsp0ik+9nGIAiSGiG5iSlKSGg4ADQKpXIFqmJaG /kNBMuschJPbIW5ol//thDg1DesrXqSXgzDHKDa7Fli38w60LqgqZ1OUkRSGDDalQ66V8ceKWIYI WFGtIzCqDBRRGRWo5E+siD1FkASlpj2GJa2kc9RXHmuoJ4IKr35ZGojuujdqmQgBsIHnm3iKuS0u llCbCwAZFZnafSX2tabwmkzwmlaM7JOi5EDPXBcJql66crO8TSA/QFINho1LNTOVrWK4xdrKGBa2 0CWFch17xFGtyV9TRdJOCqDKfy01qt+li5OUShjwljcRjKuTazt6IB1adTvupFlMW9PP6Np3E9OF GWDOIpo6nQYcxtWvWy1jDe5sVKMgEWlktJJg/uEcWCJtTYlxycKdxbB0dUiDDkzplLv7ehi/qwMs /aqjjAP8VLQzGXFlfjoefE5Dnu918TzzGZ9xwPVSo6XHRXMr25YYVLR6m8dCzUS7D8dSDEZOspKX zOQmO/nJUI6ylKdM5Spb+cpYzrKWt8zlLnv5y2AOs5jHTOYym/nMaE6zmtfM5ja7+c1wjrOc50zn Otv5znjOs573zOc++/nPgKZyVdgW6EIDxjSoCGchTjzTeCna0CWUT0aMF1EoKXHBO1onKVYbJm0Y +J0pkjEX6ZkLTtsJ0u5jqjduYkE/WpppKVMs3P67KYuWbkIhdXCDCW0LQk4U1d1DFDKM+sLG/uDJ EDzl3GV6MjIqfsw3RBUxM2YrY6Gy5sQN2odQT6fsadBGquRdGK5T7DPOwYpt1k6bRZPUbNakm9zN 0Par3I1PGTa7KPMu2E262B0TgxrYOJugUxBllbO+jNkyLVQzKokN7vyOWW31qMGbMXG19pNubT34 O9nWauCuBLPLybjqFn7YisPsvw1JsHZMftapYHy/Zo24vRMuYOUQ+xl4QZhJ1grwUmFlggXqkq26 9PBRcYkyqbIT6Ca7PBvrPCAwiSzHbBXgZ4xsLhozDmdpQ/XqxhDqmcmq0/co9K8QreljovovP/6V LnXJqDAxqtR7Hi/YJKw13I3weFdW255k/gTHvFLe1slxmvFyg6Nspys25uUPwGMW5FrPrUyWvveE +K7wQuKUkZwE+b5sXkj9jk1dbYt4ukeJdIlBBouqhSb29P06O16ZsdjudNYDJimxpz2ZMlOdj+AI 3OCePWXBZPscEt5Lth96PNDOD7KvPZDNxztMnLIp3B/W9P5JBnRgNQ4Dj1u9k7/O0YNTS00PJ+Oe FLl+MYpy4yLK5CrKHHOIjZBd55ptEx9/yD+KOiqqf/3A0XII8H6JARzE4RHPl378FxYgURURBmDX h3380WHmMSE6BVS1QQAKEH4EUx2NlRUlJjh4Qm3ydIHndGKApz/5AmN+0g2JoUbd4HGi/mZP+bRt yCITZCBiGAgcbWRu3mGC42CDKgiEM5aAKYaB+dA5x4GCHieBcfRSETgKv2ZTVeSEU9ZFHlFf3DOF Vghlu3Fs5MOFXTiGZFiGZniGaJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiI gjiIhFiIhniIiJiIiriIr/BoUpYEVZY8sIZbrjZQpuYIYpgyA5WJpuBfVfgjAQBGDGVbt3UMtnNA puVJjsiInSCJrkYJEHUJnPiKDDYusiCGP4IwG4RA3dJdSKMrbTd548aKopA8HnEPWEIN1NBunXJv 9WQzzmhs0wZvDQEgE6R/x3hbVndu/s9IGdYYJwXhf03hg7jBjfuFjNQojanHgcmWjtnobGRkJXxT bMdgQ1h3FDxoRClIjJ+wOZ50EAyHjzCncDRHJ4FVjTR3gBIXcctHcjdIjwFZkC0SWA5JQ9hldQgJ IBWpHRclgDVnN7XlkRzZRx3zW42RYMy1R77hbCaihfzYijMUhE7VWB/IRA+ZHrl0OOOndnt0doF3 GPwwkxyIk0R2OJ8hk56SIzeJlD2JL22XLpBldmwRlK92Eo+Rkx6nRk34O5q1MFH4kppgS7DiDq4H Kh64dk8SXGqZFWeJJIzSQkOZQPoXFm9Zlp4nE3RJlluJefswfv1VGXkJl5kmQoDE/nzTshUbBpae 0Bso14GT5S36J5d2OXTMFwDLp5ZGgoo3KZm8pZn6t5NEBH2WmXwc+JcBMYChWZWXNi6S5EnxZUmd pZgwKS4oh4A3GHHgEZki1Jb0tV8KKFKgCQ4zU5sZsZm7yYHEaZcPmZzPpmDeByLCyTwvJ1LMiR7D IyYYiREqdByDFjcHI5ugkDwomBJH12yqpJyciY3zRoLl1hfW6FQyBTnkGZfH6Z7v9Ax4dJf2KZ/g IIREqE/TqD8bmI7jmZ9kxCLoEUymOExY4xP0B57OA4WGJI+oMEEQ6jxY6HBx1GjSNYwXijNfKB6Y FIqnYFIfeqIo2h/dmaJutoqg/sBoLsqiDcUNB/UJmucQDXKJjUBr64dKJSGj3NRSQrSPmLBewMEJ PHpKHeFRTQWk28RVD4lTyphT+VaN3Bht8yil7DlGVUpG3YYQ8MlHTqpNg6WfGJmdFYeRDIdKLtJF 07ki/4ccG+c42cFrY/pMnOaX18kWTxmlMoSVNMl8Q9On7XF1HdWVY3KnzOQAwJSSetoXfBmDjzpf +skpkTo3i8c1BmCSLamo2RQySSRsyml7k8qZuqcOqKknO1JdKvGjKkKknupMvNidKCeYs/GcoHlS +ilgcMp/WyV/WkgrMRqryESj8PSe6EmE+heC9XmU1UYNGEhGX9gUq/klOkqs/nc2i9i6rdzard76 reAaruI6ruRarvCjaMNqrtk0P1nViaaDrmJyrSwjr4tAEyY1gy8RE5v1l+raPA6kHNrqCKMkO+HE F5wYsCZya/dnGRbKEkXXr38DUOnxjcOFjjgFEFUanyZKj/MRMz0Vg9jGFDH4jlgSjdsmfuQIb+b3 V+HGVOSwVvCRVofhYttYehBbDEBEEhsJkOzWnMrBIzynkl7yqEAbMyOZkWLRcihbkQoJN6vSeUX0 qihLMPnXRbl3s8agRb8FlIAhlHwKdnNHiXx3HWHLtSY2mUznmI51MxoDtVOkJWBkdGT7mLqJtcSg pKkyl2Npq5daQIg3WG5X/prCqI14ubdoSyG5KkJ0FCexqQ13JLNzew11a7eOAImykEjBGXjJZ30m s3+i+nGcm5k/WZlTe6ro4XsnEV60WQ2QObXQN3y2SLm+oDWZa5sT8Zztd1gDGxi1yjy5u1nVOZQH WJy8Obxi8qC1qGDt8kmQ+xlVq7iy6wu0tKsF+iIaMQ5MqDvFU1oBWmLZ6733OZ8fUm9qq47mB4M+ ga+fcUvNO7MqBr3R200SGr94lqEuCVtQQL+uEKL3q7/++78AHMACXIYrOsBxlK6TgMA7qgkwegsc gEwTAGn4o6+xxgirZayw2qhbubpUYn6RwKMOF7LpkT/SAH6JZ8DAgD8v/hWDFTyJfPSLsGgoXIiw SYq9ZxO0KvxKgYfCwbBCWnE5JPsb4/hs6ohQkAGl50i4zLgS2haOrvSxmefEIjtE1Fiz7OClYVow sOrD5+e67GGDVszDsYCf+viPF+mmDccaaTojKWmRCYdzA9l7PFtGzjnHvSdyahqFXxgsz+FXRFLG cuu8eGy1XynGsZUlCxO3h9a1SYlcsxe4YksRVKmUXkkwTLkfFrbIZ2tddEufqYQPp5FxF4fImhLI r+t1CGvIluC4IGEuhVuXN/h3SuQkSxdOgdk0pXvLG+Nwusyvkge/PxN1jYsNj+vFJxy1savK0tV0 3tKYbXlRpFoZoCrM/p75mJxczZ9xpM48tV03ubzHHoTKWQnTvswHu6mszJNAN+0ZvH1hG7jrXNyJ GsGrfnPFzqysPP1ZnCb8kd48OdVgYKI8LcxrzNPJX56MZxqATcJjlNU7lI31n8y6oDWqsfhZs+dZ MNXQ0EzsJAUqoFu6nM4VKy2mDPW10Kb8xTR70Oh8PeesCi3dhWMgZy+90k820zR90zid0zq90zyd ogrcPj/d0x36D/C7XOK1d57wKDOovq3xb6M2F6JmjfyEHQNkpzuqmkLNCv9qN5gYYsXIpA/GfojH XSe5sGJ9xcWVtAV7HLtBY43wLlm9ChJ7DRQrjfgIejH1blp6b84Y/o9T4RPAp7pakRWBfV408jNu LUnJSKX0Ixz8pkZWdxlxzQo5Sw4bOchcHVNrfBQLR8jAdJSXFZuE8LShnRV6dSCNKkX8NnE35w3d gnBXO9mnoLUg7XSBalVDlySPYZSVM1ulrbht+9uzgb2g9RGOZ0R9aRLdHHepYlS8KduJtiyJi8z5 1befqdLt8ni9RVSNV627dSjEVSX5U5ig7UUesRt19dzQbQqYi5yd3KwqydsOfTMTUdji1jEmat8u 2xqqVZWtCdpj5xTTJ5TGud6lQLtD+bwbXBy4Ot9FPRFhHdaYU18Rbn/H8IBVx2+rdLvqx4BCFGEF buCjML1LmdIq/sItKqGsDn7M9bTULIjReO3i9HRONxYS7zrcooaFx6EMA5rMIv7jQB7kQj7khfAF RH7kSJ7kcBTUSKrk6aMo9srkFGWdrqoJppa9NPhipOYvSJjlM8a9U+3k++tRZF0imQDXlHrmYhIW 62bWEo45N1yAFv5gJKXWYt4KYVEVw2EdfG2OYJyyyVbX9RTEF3uy5HZU3XDlR6W6wfeqyMbo4XXY i+fWd75pwrIqaurZ/OzZsH19DnPGB9G0PpvZhgBXfDp4MUSXiaHdps2NHlrpqLATIHSdvGXbghvi ozPJD522ue3jloXqSxfQrN4inxVaGQzr4bkU3X2T303GvOLN/irRy77NWbTcRB7X7NhQK8KN7RQR 3gGG7FL4KyZ13dT1qNAeIakJ4LXeEeNC1t2SD5B+XnQBdi1rXvc9Df3t4+DOCRcyyruq4HN17saR z1BivET869hSYHIOUmcNcfu18Mr75iT6X9++78kO48m9q3/OETXA4yqtEhp96CSIhMqwACtG0loO 1S9OR9T65S4/HzYm2Ra/hdYy89BlvzYPXfyb8zyvrlLe8ww0wU/TN250o6O4CO20C+x6EDmBo4Dl PxwEJFUtI/wzjxQ417Kdw0rx1kSPlhhlwVXYClstX1+/uxkUjKzU1qhkQcmjLURs4FxMX7MlxVpK xO+GpcZY/qU4JW8qNqV9LhyEnrJ2fejVqkS8tmGOtH+q4V5u7AyS4kLGmDSF3NPOrsVm/MZo3KNr zKYBSM+Zv+mcrU87C+o0J5JxagiVLV8lMlg2CY9t7BkXJYmFQUQi/raJbLZe+xuy0esKgpW8T+vd vKdLqevuHYROSe87YiV8Mim+D89g891aSZQFNY/HQ+lZfc+u7JZ6eXSyDCLVrqveLyTTXfnk7pWw PN2zjNcUsSwfwiWAj+LpgpiGOSQvAuKdJOTn0szpPn7QbD/0vyCAcEBwAFBIGEBQiAggSAiAMLAI IEmZKBigmFjJOKiI0FjIGDr6ODAqOZmYGYpAgAkgUEAq/mCQGjpgoBp7qhqKagtaCMlLWmx8jJys vMzc7PwMHS09TV1tfY2drW0tKTAgu3jJKKCpKvldSFtoIMBJ+juqDsBuW69+ELtZH+46Xr4Kq9aB AQgCrmt37BshfLUA1jtoSCEjAwMO9UJkjoCsSd7e9cKHkNbCXb56bTuJMqXKlSxbunwJE5ukVhYL FRhAQACiAPoQLcyV0xFORw9JHQAqoGa9owTQ9cxoE6dOV/qYoptIIKg7oxSbbnT4S9DGozhxOfqV KxRZr0QzZW1qwNHaqyVj2r2LN6/evXz7+v0LOLDgwYQLGz6MOLHixYwbO34MObLkyZQrW76MObPm zZw7/nv+DDq06NGkS5s+jTq16tWsW7t+DTu27Nm0a9u+jTu37t28e/v+DTy48OHEixs/jjy58uXM mzt/Dj269OnUq1u/jj279u3cu3v/Dj68+PHky5s/jz69+vXs27t/Dz++/Pn069tvL0jtR11fyZ11 9dZbXxW1CEZvJeULOU0VlEqAGo1SQCeGEMDgXAX8R8woDmZlSFcSeRQggr8ssqFJBmaFoCIKEnSK gjplwmBRanl4IYx1QSghJxXSiGFdJ2rFS4ht5ULUjymGQmRJQoIYoFw8unVgWw02aWRNVZKSpE05 ChJjKqaMgtMoWU6JYpEuvjKiSetI1RY8xXR1ZC50/s3jFYRsTqhfnpsZQJEBBfCJy599FoAAQgDk xGABUyWTZlH0pMJgAE6pWYwAhsozUI1kKeVQhhFpSpGUaLXTaKc3QgSpIldJymArmGDU4yiZ/lRR g7GGYimuDc06Ua2NjuqRmIYe6uepANzUFgHFdvqosWpJtKmjw8oorS2/IKvhsulc2lBJkSiZ7VfA TsLiI/2UGkoBshxl6ECUQrjuo/QMxOC85WLL5zyDAuonvwNeRtFGAa+5rjmxNJTPu8YWaCJ/pxTk plEUloLrv+qg6yksFnfbKcOeRlwqSZ4UMicC4CiLkJsip1MLIo+6ySXF6WxM4D/OoluopM7mK4xO /l/WHGylNGNM7a82I9ltzj/rKDMvPOvbi9ILq1LyyRnPc6qfCq9zYz+PIOR1oSS/IuZVA88z52X4 4DMO22sj9K2f+R3K09ZAo8IuJ1KaaoyrXgfDiilEOwS4MEs/lDe6IH80b46yOl4Xi/AUTvEikr/r 9yuUD2P0jNPi3SyLAkSqps4kFzQ64c3yvbngjH9OKeikHq3qLah3mXkxO/USCe+3q94O5VAGiIyi KkZsjPFzA3ORJRQOgIshSQU/fdvTmlbst5Ho/KPXHZfzlllbAYATh92TLeaDeAY7OOKxlx6g+Iq/ e6L4y5fv/DEMHzD5+9YOgrxcfGV5PmoYmcQX/qSsINB0w5ARJb7UwPrFhUlZKQgBVyFBUTkIYvGb oMcyxMDDCdAYlisIAgzwQMMNz34Ka5+5MDEQ/tmNFf1YHj/qIgiByAM3hRrIOtTVMrsR8IOsmlCb aIeMsEBOZ0OknxL0I6rDRayJzuKb3oghvHqwo39R1OKiSGgSyjHRgA/sEkCKuI6mlO9VpfsSCdSY FTaqyozUEqPr5qg7/5GLdA78kpzWeLW6GE8nkvhjHPdRriy2jyKvMAAHl8HI9TEPh83TjVgaEgBL PRIZgONc1Ly2sg8qAx4rM0gnD9epUu7QiqesIrVmlqHUpeuOJEvLLIbGO1vm8ZazEEiOPElD/vQ9 xFWFcMUBjpkvePDMmMgMYjCDxst4OFMY3uMbKogpynU0hJlH4Rjy+OFDSXAzmZ98hSyjArRZHGlD ybBUsl4hNrr1rJhnQWVtvBEj6HHqGCIZh9WQlDL1ZZKWo1QTr6IVkJH8q1MHDRU0e6lQV35ToB1J lbk22aBiNNRXzWuhQaHl0IT6s1oZo0cDMyFDtUSIECdNRUoB+tBngYqjwopptUR5gJU2zaWutMek duqTcSGiVRMj2p/0Z7ejYil45bJXvXTIsdvodFvDy8q/LMRQ9VnIIg5aaB09NMEOlcWrMppLWAMp 1jpJdGtbTRCK0GQSXcoKrLeSayDNShSs/hZFLBkTS9q+kUGS/QuwYVSfFXsFl1vxtYpKLADDwhfW v4rLo9SsiWQbq6K3fo8U+OPQqcjBWQchSa1pnFNXonqf1KoWMMhbrWtfaxlCwXa2tK2tbW+L29zq dre87a1vfwvc4Ap3uMQtrnGPi9zkKne5zG2uc58L3ehKd7rUFU8Pqovd7Gp3u9ztrne/C97wine8 MWECec+L3vSqd73sba973wvf+Mp3vpLZG3jtOxyMjelKJ0oRw2LU2szmBK4Sy4a6Yma4Y1KWGw4S UYMtAuAZWuOCy+iegpdhwzMx6mjqeoYLbUrhPC4pxB6WsDT4a+K95IfESH3oRHfJYsVg/kxZk60p Koz3PwkFGI3YTLE0EAQJiwhzlwy2cVxnp2MfwyTAG8bjC5N4tCMx48NonfKRs8HkaQAry3zhMpGn 1mKbQgZnPgMzKjbhsoAmo2qpiNC3GHaTRHpjQcnw4UEyhUGNQI+DbpbjUuZcLjOTEWUAsUpDyqW+ itxEK4jeyAAUUA4BGvrLBRTgohH0FvINyGTSK8sjJWFnZ5QKH55ORS4ECD1MliPOZuwcIljdIa+o wion6/M+Zg1oPu/ZxatuiuZybWpl6ZkgsB5HqbFylUnf+lBxnLWcxgJseIz62Ut59j9evWtkR4gw 3fMdLPjYodnNMs/kw6hGIZcJWdzk/n/q/hJJ1o2ME4Ipenlud5uPRctubATep0rc62xxOZaN9KiI IFVFOpEvgueEXHAWOD7+5aaGg4KcVzTGu+84E9QWlJ0aQ+erTT3ShvMbeOzGtzYZESZTEuTj69bH xe89csTRg+Xu3rfran2sB8H75SpHnQ7/6bFuCER0NndgiRyeMIeHSeR+HLqSl2xAcqnwgB7sKrmD ytYFBx0qomDEtpGBQhxFeNlo5rpcvq4kBVYdslYCoPPqKfU/meJPYinS3ClyLBSWYyE6luIG/8f3 Gq2CxWe/tirCXuIMFZ6nPlEhEeHH9v8NXkKtqPgxy15oQ2xbH2lP7LK7ntO9M97s/pp/uyEUDHfM g/P0oN88/LBI+d5VvPKPn/3TX1IqQ57LHOUCnTML+UVjKBIqtS/FAGhht6W5rFaSb37xIXH8tARo cU4GPj9ESz58SCqTryJHuSriM+5/UBCinb7/zuz9R2bR+MhvPipLFHWAQL/9nN+6qai/CRvmD4Q2 mwn06M91ayV//5cWTzGA0bd/+iFaqpeAgYOARgd7JXFDVwcV+sdtUTdO0/RkrpZLdnNOJseAk0dg +tMt9AILaoZ5k8Q8IyiA1ORn5JMWgOMIfmIKWsMIrwBvNDgPrrcUW2JT44eDtPSB6yYOklcgGldQ sEdgleAIwMR5VlR7wbB6k4AA/vlXgV5TfC3ID0vIdVZIYFL4CT44N/YHhkWYTUATDJAwhfbHPLfC WgbUUlhnZGqRK6KEERtGVJvEMBLghf5QPDGCKT+VgltIJ5wAQ6CFVlvWUQI3DwgBCe3QCr6ECQ30 iObye70gD6tTNDYjDsMwhhNzUYbohx4jW9DQKOKAD/2nLChnNU/4SsWXL6modFV4hZgQgzUEWq5I fSs4il1Yi37YcwbRiKJ4i/YwdGF4iEgUMj9XSDpkeAARi4goGI1yWYXlWB3UdumTDvSjYWSnilEx YP0gjSTjCCO3E7WnD272dZe2E4lojWjhbGUSCg+CYOw4jwXzaYwjj4EkSvZI/j6dkEmaBY5TUTcA h19NdiPsSBUZEWcbkYVQ+I3IZku09nnqqAoKWZAQSGSSgJFPQQH1gJHaFmtAYpEkQwCQFmtX0ZGv dyMUiQrW5nzxiAu3Nxpepg02SV9T5gv2dB9kYzqzUYoxEZQ5eQ30uEqrZZRISJT0ISlwQVtNSW9L KZVTSZVVaZVXiZVZqZVbyZXecZCY8ZW2NQHKEZbYUJZGIRwBOWCJ9ziUpju78iTMhn1q+SIUJGXs k3XjA2VRgmUetSQCFmgcIZBD1VMeMXYpsTtkohX/dSpqGZh0yYLNxyw5Qph51g1nSRgU0D9WNg35 wWUXhGIW9RCO2SWQuVn6/kWZoPhKN1kuxNQM0qZHCbEQIMV8BNKa1fQQOAZGq8mbX6abRbabMGVR kuKQt8lGSWZlyJkSjUA7Mwc+PVKZxOlkPUYMM6YtsDJ5Y3g9jAGbnHliSBRmxuKctnJGoCide+SC dxN/xDJZyqkSbCaSwTmPHEJrWyNvHSdNxgKfjemLzadsbwFn2cafM6JWpEZnLqMR9amX6RRKDMJm aXZYHvEyMnloDJJoOXUnFNYO4lZApqZm+DkymjYKnNY5pyI1mTCh6QALtyBMBno5sIZtiURtZVds FCmRBPoNapJpNqqgxkZnT/Mt8wkgtuajLJJpguahANGggjWi/0RuJlpm/ij6ocuJbkjnVd2pcluT Oq3Tb1XqKfAWgqa0C1tnb1/6M/ewCy/3cVkannmTRcNXbr0ZOZuEpuoWRAY3cUrpKf4GcOpXpcPH TugiOnwUcMkTVWqqczdncmJ6jfW2qPcgOj+ndCxZp2yKny3He3hZpogKTXxaQm0ofFXabekUp7L0 qTgJDSSWhvbUnWm4NZ1AYWe2HxVmdd4IqlLHhrAZIGMRe60neq6KVJF3PztKWXJIqy61hoJzd3dX d6KGjUboduODPwuKpDcSQnn2UsXQUr5qq7eqhsR3hXKBerUDrLDXhAfXhLNWemOzg3iZeV6njM+6 dSk1rPS5YE96RhD0/iX7g6rP8KaV5JYTuJpzY0ddGpa+Z6vXRzy5ypIT4Ut1MX8FOGsA65ZGZK7B uUU6eqTQuCjkRzzZF34vEpCBCWW7aX2mR0n2dYpRp3t+lrHhaTgPOIgJmJgxuaAeS6w3Q7ODALAR e5G1UJtP6n8y27DVeXgd6zhTyGt6WUhwtHsH0a/PMISmsKrymZ2HtTyq1C2/MLVL+4mSJ4PQen8G tKpmyInuKWYgag9dgqm3YFfhOZMV13U6aIP8g07HukuoELdq2w1sS1C3KjMZ+BB7S2lm261TGGTg erVUGLZS+Hpli5yGa4ioFIVYGK8m24GwdCNdu7JE0UCCq7dvuw2V/tkKDFKpeXRMqTs30fiqckGb RdIwedipuSIOEmuMEOGZEdlvucKoqJiLvcC6MMsLDllRpFtUi4i3GSWMj1KJkSiK2yq8+HqH98YR +wqKpcugE/RwQBWtbgEATaCtS+O73+hyP1e7EQmpPocqwduWjKovfji+t5A27tCHsgia9HM007um A2UjobiMERWH3au8K2GaKVkwFLSKQ0EnOUqt54RXV1PACeR5OcfA44cUQnGSurtCYWWjK5k+DHy/ nBSXgrmWjmJi8DiS64SPAwlDdoN/ccU4Y2Umgxl1elWN2miopODBNhufJVkV1IYVQLLAaHcLg2Cj Q3yRUtGOOWdf/jiBkpOQBizcDwoMkSY8IzLsViU8bWPFpGDSqKMVGvf5XFGbGUEqG/EUXEHLXAdA R6WRSbSBD23MWwGgp10JE3fpGi5jx3vMx33sx38MyIGcGZgpK8xAyNV1yOQRY99pig/GyCwxJoSx yHmSu5wEnlO2InJ8EmQMRoeTcseqqjQJADZAwiS7yd34mgYVmySkd+inQKTzl4jgyReRyZlwmZ9x BXeBquPSyC1BY4exy5eMr84aKfOLEpycR2Y8vcmLmOZpzDJhnM76g8mHehlRzE6KbxahzJ4VnejA nCpCGpemFAoaozvilAZMKS7aaoOWZ5I2oxrha51GZ/gGJMqm/q1Ris7BdiFyUoL8nG57VqP+3Ga7 trFxeiiOhpIACs9mXEzNRqT2HA8DEgB6iGulVs75rG0yWWvZ1qMl8TR8QqE4yoMiGaAyes7RNDII us91QqOpZgzwecQxtaMweQz3uaGam9JqQk4fbUtLuqKGwtCekada5HQw526SaqkRfbf9Np4l13M0 p7lEiHAIg9Sc9Tsn5y7Ue7qVynKJaqVGLSMKZ3BkuqgFtKlVbbEb6TAg6NXvm9WWWqdQ7dafbMu8 I3QjxaZ3TS9M99WPo7LqE9fgSj1X5aWnG1N6TdezQEdwegquo7dKqwxKBRrNuri0F67kSnnpvK4S LD/gynfi/loV60rZFfeTOzl1wNp4Uki1fTd6i8s9itvYeXd3DOuut1ra0pppoQ2vywasvR17Vpiu wcIiJ5Sstnerl/eNql1gJmk+sPrbnj11enJu52q13tq651bEze2uw613uO1Z4VuT6aeCNouz9lpF PitmKRjC9YDegski5U0pLTs+48dO8P15CpvbsA0m2hcJhPSMEGiF2AdFRnuAADh5lITgdX3gY3ss G1qQ9m2BAiu0ziPgaf2k+peCZfWnFAvBO3sMIVY4Z/jaDQ4LD5609/oZdsvWpJ3cYoi2oqiRy03f Z0GLIjh4QSi3eyO4jtuDeZXj942yopDhSLJuNkjbBA64/nsTSvtHiOQduU9+rsDN4I1wR42LnGtY 41JuCEKD5JCLrdGNK347e6z6uC8u3beEBB0qJs5E5fYg0Sgu1P0ATG79u0raEPLijBKTjGJ2vg+R vvULWp141KgSOLxACMGLCpkYEnfOoeULEVYYvpC4ijfkipV8u8PoEcS72rboPHuuD+zLvoENjXke Sz+1vAiB6LpwjMWn6Hmk6X5uvv0gsWjdv9jrvqiruqtL6sYgqhRFUKGnFN4AdL5e0zy5GfYIavwc kUwhxDRtJ+GIPsjjw/po6hypxP3gj8x+l5IlkUej7U4ijwYYxA4GEFR8j0xzDhnMN05sdhcsfHFZ kvRM/pA/DBfAK2sG/HmGxpI0UW37iMT9Lojt7u9zhcWgo1bT3pD6g8oUeb8BArQId+8aKsdtFVjs DZAxzBbHQHeifBk+aey04fHVEfLcYNqpgcwwIcaBEdSokZS90fLU8fLVEPOncfIwocZ98catAZV1 PBs7bx0+fw1Ab/Icbxd0LBh4LMhJr/RLz/RN7/RPD/VRfxhSIPVVb/VXj/VZr/Vbz/Vd7/VfD/Zh L/ZjT/Zlb/Znj/Zpr/Zrz/Ztb8eJXMh/AfePMfe7UfemcffdQWWF+eHCbMl5QQ4xYumbwWKhWZmj WctZXJclOpmwe5gY9t/RMPiGzPGkWVX+1RShlcWm/iwNK2ZigS8TqrwNkwwLBJAARL8Xex+hLRbM eBHCNV8YraWI5Hlr1zydT6vmnfLLbuGGx0rGZ0jAzozN2CLLPsnNwn+TEkb6qSz3qI/zgxbQ936j +iykrxbP068h9CnQCIpqxJZt4qxR1FbQCv3QAm0UwJbR+mzPylbO0U9vF13QGbN1Kcq3Drpp2JxN 14TPECojjUYyKAkIAQQAggCGhwcCAwQDCISDjwAEk4IFjAGGBwaMBY+bm5KTogCajAaHqAKdhwGO hagGp4Kxh7GQqqitqJmKjI4ABYsCB7uFo8EEw7uiswQFiYuNj8HSpJsDnZWXkcDCxNamiNenxYOV /gPVh8yDBquSmKUD5Lv09fb3+PSvhoWV3YYCTh1YBFAgLn+5zDn7ByAgKVwJCz7MttCfpU7BSBEg RmuXw0QF9vFTiHGARJD0IGYEQGsgyZMQPx5ceJGhTIoludXbp0lApELSCh3YWG/ot3KiRoncJ03A L6CuIB0qICsZoQH9FKZclfFV1mk2DYasKJVUU7G7jO4se/URU6FE86k0qbYjK611540E25CrSYsm GwpsBDhSXpirbpYDu/Luz8AIAivOR7myZZ0/IcH9hmCQ2raCju716jlugMCOP59+RCw0N7jPisaN LDLzXtWoEWWypJGzQmK4e/P7S5S0cNCatdoT/iRKXmutoeEeWjRJ4/KyXx23BRB59Mbaq6mapPq1 NqndyssnP067uNSBnYKjGjpdKduv0hAYkG6IOtvzpPA2VGz64OWMaI65BuABvBn32QEHGAfbUcHJ l+B6Eb2CFUvxmZbbZSCGSN+Ft0kFV1LKZbjeUCguxmJSr2HolQC+pGUiAeClV1qLu0Q2QEClkahR iy/at5dhKOqI2WIFcmOAAJtF9BmTJUbEEiPUYfLKk+YNkMhpAUCpHj0+AhmjbUjeZZxEQ8I4X1ze FUMcMD6JWZpo5pUJCiE0phMnnzWqeIieSo6oXXZh1lhkdYvep6SgwBigVqMhVioinN05aNqd/rqZ hyinmbgI53NHOogJQ4jMhpWjZ06J4FCnRommq8edt6astq5nnnaLMbUnREc6hUpX2IHKXWA4QqhJ VdPtCUtG7UCXYiY4VmmbppyteuSTqVK4FaS1MGvUnH1ZmWqsnp3aWJwRGrLurNWiKWsrEqbrLl2j 1orgp71CMhACPulr6cCWBQTcTNsadAs53JpH35oOsRRwqmw2LOOK1XbnkVi1PYxhxNy+CQ+NhrRE 8j4gB5zymdysrOk9u2b3SHKrhBmYIL90FpWVBk90bEIR3vhfZD51xqzM1I5cGiageBwsx+sVMHHF U49UsyI6MegeQNjEePWHsD609M9Sjq2x/pBhJ/LoR4TparZkDKscd79HCtlQOisTrPc9mkRTM4ZX YuPvJsmQSs8iCmBYSuGHb7S4MrdiiAyU9MRDUeOJH/k4gt0kIwg846S4eSaEQ34x6ZOYfuQialMJ 7pXi+H1Uop7XzU3fnPTnju4iOYvKQkPtjPS9nldrieD9EZD57ddcHkmS4DBeuQGyzzyJc0d2Zrg1 1e8y+eedU24l69/TTTyUOK5p+ZmvlB+9Mu/v+6jdnc1XOud756///vz37/9yrPjQ/0C0qwEa8IAI TKACF8jABjrwgRCMoATxAbyITXBYv7igBjfIwQ568IMgPEQPQkjCAZ4mHCVMoQpXyMIW/rrwhTCM oQxnSMMa2vCGOMyhDnfIwx768IckxB8QfShEDXKuiPNRIBL5t8QbNjF/TxziDJ0GQkM1kEYZ5AeN arckK1oKWDT6RmiCVMAIetGLslkSE6dFGTTyLUj5o101mCMK+AniQwTR4vWySC17uNEyZaTYAgMp Rf8Nr5Bv1Ec1OqOl/+QPYOoQFp3stsEcUeaQ+8NkJh05MJwNx3n3es6GRpKcp3QNkJysDCHVaMBV ItJ73kBd14yzjuOdKh7kaMYmqMHHc8hjJLtcXzvUEYCs8FKWq8DlVGKZluaFgi2nNAQCcLINY6Lj F9AIVOU0owpyqMIYlHDGNhISzHEs/pNxvpyHMpH5zN8xypnuxJE4R7nOtPQiKOup5TjXp8tBQC+b 0lgHO33JR4/sThe1ocUs5mELgBy0lyS5ZjvXSVBkQmJyCBrF+hJCjVy6rZy50wY97/kLjMpSLzY8 jGAmUi/GwM1n/ihMQnyCEoTcZDU/M2ZYzOIIxag0FVCzEf4Ko9OVzOUeG2rHiNInrZxwFDHCUahV ULJSqrINAZasKrAy49TJpMIv7HuJUaEGSp6W6x/ZuSlNBNittcjJLVLR1pSu49KWoUWmbOOUXZ7m s7vQFGFcPUnbugpWlXo1pQdq67Faiq3hsIZld8nWYz/TnaRerrGkgJCHNEIgoUpT/ltvouu1FIee ewxzQ1hZzZiW5JoKJXYkknXtNyBkScrmhl8W0k2AlIRbVbmGJ6ecbYMMlK01pTF51bEkVLizHzgC wD/m+0pwMFu/AQ0VVGd7bE7dBpy40Ja0u+UshTabw0RJw1Cfc1uroBc5KmUHvYOgilp6ayMemZeP 8O0YnKy02lcQ6h4AG0jJCkCV0drudtADFD5T809WlY1X8tqRm1DxX8ZiTE2As2CFDYThA78JT2xU bXzrVExjsZa3EjZSmkrVJ4hax3b74NcrvLim/yrYEZTCYbv+YdsR9ddYhjMubD+L4Ng2ImC9FSMC aLXjd9nWPJK8V1jXi643FphP/sL6MZOYrC7ixDZfqsEqq2wLKVy9Kl780fKTMRQyjVRZur4FXD22 Ojyp9oZcdGZVS2mFWaF0WVSSjSyRfaycMGuqyk3Gl7d0nLGXgiRsTVvb3NpLTphKZTKKeIqkzbqy sGUXMZ4iQM5EPeVDiw0fmZ6Ol9IkZJ10utGe6GvernrGhfW1jxCbm8hODWkyfiyokZDarltHRbV6 +Kl8ItduDacI5yHEZtGFo8vYrDA3k02Qh52Fz3rt6sGIuURKs7bG8oZD9230eLx5rvIUdz+W5Yga fxNH7qR5I5ZtdHThO5X9QupI2onPwkf6XrIcaYmjCADJkECcnLPW7nxPAx3u/sD3RlmHCtZttOLr 1lzDhyUM8KE74RlnHr/3Aj2BY0LhA/2YI3GHjec0R1LZ2xrpuickDTmu3cZt3kU73jgIwfMu8J4K J0TnzDWZ3OHxeyUEXan0GDK96YNMJQ0pMMAJsBLqr3w61lmo9a0bsAAF9ToqxQ71rpM9hGY/u9ol mPa1u/3tcI+73OdO97rb/e54z7vYdab3vvv973+PYv8mt2qoCx7wKjz8BxWP+MVLHR9/vLq5XnPP ZMpzpSxhJizmXTLOQ15aL14gFS+DxbskRXWerJscs+jvKlOyd3BKPZoq1XYG0ifybu3f03HfR8pQ T3qB293Pi1Q106eO8Y2X/vwqlwIJUm/78hACRnzaXDKaVoNb/7qMJhG4/eNC2GIzE2MpPzmcUTfy dSIhwDBJKf7Qh6j2UbcU/HOvysdfhsDWCBj2r2/9nBW/Se7yfzAEUFHRUVaDDh4FUl2jPWgVUY1w TA8RDY6gUeYUCXYxSjBWGmEnTrAAYe8gTQETL5BEUMc0JjNWdM4gURX3CwvxXD7Hb4QTTrY0Pbkz ChCmHiHzCnT2C9HEHWWFNPsAMDjlCQgHEOcjPwY4DftEUp6gfin4gCpIgOwEDr90JgJFhcnEhO+G gMB0IPBkOY+yPseged4BgbWgHSIYgqcCSZFySfXGEvOAgSt0VILwVxRh/od8oRgGUy1FtVYOJWU6 eFfp8SHM5y6p01knFGVTMTXwFXp9mBMmaGsgIVNTURU+sRpqdVl+uDEs5WD5ZxsLNleKhRQtUoj9 0VOa9lw701Z79Qh4iFdgFVM0sYlHVVVnYWlxEoicFouO8ootqIeDsWn/EiWtWFRsFYCO6Fw6qAhV SH8r4RXHGESlpSCZoiqTZY0DcUpZEWT+Mo2gImL9wTS7gxk8oR+LkEHnsDuMFFrWkhncaGCy0h4H Fh7UEylrRiqttmakaAr4+Bv8oW6MwkmFaIo4pTHbKBLWtRaSpT7e+BzvuCAC4l2aJUbkMiYPAhze WA4LSRQ9NhuFIpET/uJWrTYo1dKIjcghD4FSxjcJ7mBZL7RhdvNeb7gJ7UdpMEkp7XMKhSdItyEa 9bgXZ0M9+tZ7KxZhuQh6+bVwLgglWAElSfkn+tVhkyckXGJiuDJ5/+gkWEIJToI+xdBi7vUoMOlu kPBftVaK6pWVn/UjoJBV8BJZ9fYy/AWWZeZIQkmU/xhqomUN5FBgO7lCYeOOREaN5EJms1CE7RWY cOYtM4YjAjQl3ZFdQqEty4g/aWgIl9lekcgeoGUe7WAS0cKZLdVFceY6diMPt3BQt5BFxFI2R6Ex yeJzzNIfvpNoGjmYGPNmp4MkiGYaSwZmafmNv6mbt7ld1JItqgFH/vPybbZZlykBP5i5hmoIgu5C kXuJYEPIQmlzMupnaYJ4CIrRNQuWmCVJMiMybao2jgVxMKvQcimpOxvhEFdWD/v3C/VJlvAoid+k lETDHd2pVWOBa0ppbFP5JzNjNVp0M87Hd6bYMyghmd8hNLv2adpWU7l5apQGF+Fmiz01N9xWbN62 nSHWnRYKnmhhMmPzKyH6NtHmPSp5nxJjVs+FFvSXCBMDcTBkcr70N0HHcLmTgxGKn/lWLRaHc1JR cEXxe9HEcu5wQv/pHwFZC54HT5oJeic4cqwEPM7HT3EVcg6DgqZpoLAzc5wwO1v0b8VCpqfUg88V oFIKS1wEdDjK/jI6upvt03El+YUN93HJszznhqclVg49yhM/p3OGiDxYmDwMwnPOiXET9nPBhwh9 Ynn7iD2GiHwfpJctxIb6M3/Jd0OeakOh6nWcWkOaCpiK+KmqOqo0xKqGl6ozdKoppG2qWqvH1nSu qnS0aqu82qu++qvAGqzCOqzEWqzGeqzImqzKuqzM2qwyhKkgAq3OekDS2kHVqkQNdK3TOkC3Z3+X Yh2EtHqkVEfih0cmskV+UiCn14/oeK57lAtn6npiCnuz43ySZyOz9z+jF0feuj/7qkCu1K0JxHv4 kKttl6tbh7Dmcx2mVFbBIEr6xhwj0bAwUxbgxxzt9wgUexXm/keO05J+6xd+t1qx97o33fd+/dqp bJRArqSw9Ed7KTt28hezQaSn88alSUiFCXggTChQFYWF0MSC7Zk5+iSHf8gKqxgunsBQv/JQJEsi hxksTtumFPaDHysVQogaUbsk1dCCA5A5hwSGTfgMFRiBNSJQFziUOnuA+DSDZtu2UWizzagOMrhP ZSunUFgNUthPbLJOPvuE2GSoHBW3KNQcQtsfLzhLTqiilaOFgGtR9GBSb7uK9SS5IXRVAAqgdShr gpgYvBhYK9ESeVSJrngV6uFUoziVIvYWJpYPhHqJWhGK+5W6K6liddMUqbhgw2KJpgt6uyC6L5G5 Z9WaiCJA/opBVLTIi13lbcJ7Ict7awhaE0alvJFgQcfbVAwBvIK6UyVaYJuLiWRVvSo5vMTxvC7h WR1Bh/rZIRwxvht0kR1ZXNi4WQoiXFaKMb7xVuIRKVrGjgA5opGQH80VetB1HS/Xj6zxj9D1RwOZ ptthkP54H+NRj+Thu4pVP61FXvaLJi75YY41mjOWkUgyWxPpWM6ZW4/FkOH1W+qHGtPlu/HoYPMy J/Q4wffoCce4wdTFFgmpW1ozwo7Vw0HEwzfylCWCloOCDmaiZm9YcV/SlIHKLx5MScgxSXZSK8rX b8pRlVh8lTfoXFqJDly5JV65C17ClGESxWzUiI3JIzCZ/pMuWF8wAsJlqcRteWFvwiM1l2LVwV8Y MpZ1GC84CcPKKMN8rBxnDCZOeSOkQSNqu5ZLjMdqdF+QfMdtYoOUHEJhFr+fRZgC05jEmWQe9pkc cr8elmdLYmfj0jKq+bQLi5pHGyysqWxATGTvoCx2Rpv/QcqhuVqKJZPeopi+CyuPmS90bG1Gucn5 csLLfCgXapQrwWeEfBxZZWZOAi0RKb978S7ILMpd9GfCXMvn0ZyXy7zA2Ik0ip7WRmzTDIen1iM/ 4p/iMj9Al6BZg6Q6qLgImmyuDC4SyxfQprH0lrR2xZ7XlsASCs9F052+rLStgzIeWp6+lp5zNmnq xZsY/vprnKZrFJNr1cckpvbQGHJKr2aU7tw6fkw1L9afRgNqIz2OIsoyKGojmNAdMa2LMepp0YgK dABB9ya3ODGnSbcPR4dy6hM69aClq4hyrMSkLnc9MMcNDEio3UMyBZqvzuLUrBCvGaim7TmO2AB7 Sd0hwrOyuER0x3c+4MPUwDC7qINOF32nxROoIhdcG1cfy3OlwFcqkgOokQMcDWfU7GYKhvzW8ENx Sp1yfI0gdVo3gstxXNTYSYd0OuSyAGTCoEqzYhexO20ppYqsnL2tlaTZelNB7htDYKd3pt0/iRB2 a6cCB7Taon1Blr0T0XDas31AJzS3/Irbw7rbvp3b/sI93MRd3MCqrcad3MoNsKRNQPZHsMnmeW20 snHE1aS53Nid3SO7SfyzpVvlutStN6fRsbWt3eb9qTi7hBL4cHCrtxUo19BZhiqYKmHHpSRXt/T0 3ov7uGasjtS0Idakt0x43gT+q1cFi4Doh3j1nT9VhqgidMnQWQR6utw7Ezjx4Fhcz8SbvFJW4B5e qxepwj98zC8sXiKplKRgjqSmjwZWyyL2kDwJ0u28wR9e441HY39sxyh2xHPMTdoElTzsk/gilUyM xJB1nLnXvzZm40zed4b2zDKGv51iLxguxUnsmp9FaMlszLuZCrNcalDe3E0+5lh34Bcq0kCu0hp6 /tAmXXGxkQjeJBYfumkxSmkJMWqryMQbSuZ8TkNVgED2zQ2SLcWjA99qa+Wxw3nnNnR9Othwzdc7 Yd0AJ+iACt19fumYnumavumc3ume/umgHuqiDkNlMOqmfuqonuqqvuqs3uqu/uqwHuuyPuu07qtv UOu4nuu6vuu83uu+/uvAHuzCPuzEXuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c 3u3e/u3gHu76I63IPe6vxHhPVO5Ofu5el15n1RCb8kBlpJZTaelRyUBl9K+Wrp39KrD5Ht79DLPu 50D0XrDNve+fNzDQbTPSnQ//WkhGMQicmgwl/iWAup1Ky+eJ4B2mF0+y5U3bNLt9JwuAnSTm3C3w M+tC3q2eHm/yM1QnLxYmV4YL9TQfjquA4yu2azsrhipSmECBKAS0y/BO0t0MZBv0UpioPj/08jSD 8H1EAy62Rl9PFAW4EFj1x2SDp4iZQ+tP+K22RXtLd6txSB/1Pe+Agcvog5u3ad+MUj84N+u4NFiF FQX0dL/fSci34TNbY89V800t9Q2mz/P1J9WFu/T3M2RZS4UJh3W0xJIYNApUZrG+aKK9yAtVtuhg 2faL6QxWHEqJDt6aDe74gWH5nM+5loYRtNi5DeiipQsm2Psuxoj52oFpnp9XoFv6wbi90uto/jGx +7qYfeqbEqzfmpkri754OYYV+aEvQJYQ4QYHbBQ+VqlfV5aSAh10WidXTIqG2T48XN1lnVNcXfRL XPQ2ZbJ1/lh+0Bks/hsc4gsX5SZeFKVFWb9Bzd2PHO9Y4vnaFvtbwYAAEEAgSFgIgIg4eHh4QHCg OJCoSOgIKSgJcHlQUPmIiEC4uNj4CRA6WQhJumgZqWmK2mp6ALnZyZjoisk46nkZIDm4Giv8OVtw CQucmehLmYp4gGAwQICwDDrAKtoNvRus2msYXW5+jp6uHo0gcJBpUFBgAEtgb88+MCBg4F1/T04a uVkAvc1y5u+Zo4KwEKY6CM3hv3va9vVr/jiJ28OECQUQGIAtFQJ9/Dw5JLUQ4ER8Gksx1Ehq0oAD AoIFqPms5UlDBFVm9MTwFMmLjnaOw5grosaUFItCgzhppEV/ugpydKlS57NeHkGuDHhIpzRlAKoh HQTzKlOWPNuuews37jpH8xQJEIBtl6ZUjgI8NaSXbLZSyogR/os48OCY34r9FFgYlt/DghCIDeu2 1eQCzQROngXMn2LFLUHrOsoYUTxJ8QxefbzU1N7Howl8/oU4duiNSnFLW+wNHIK+iCeRzux7L7dL I48e2CxJMWy3UTubFuo0p9vjveV6/+5dgFdE+i7xUy2Ar21NHnOdL5s+lQF6NA29N5B+/ut89mrt 04OvGn3tGecfewU8hsh96RFXX4L0gXRZUWlJJpR6fjVYloBUKeggekcxwmFs+aQXCj0HRfgahwhy yOCA+zW4FSkvDihRSyrO6M957wy3HoxgARDidgUCyI2AB8bmV3NA/ocfb5cBMEAy7P2nowDJrEdU ikzmR11q4H0J5iSdKHOXLv0Q4E40nKGJVkwHnJlmNP1ECRichqE050UtWVOLnYnMiUsqfL750YEI auInAGvW1COgH8pEgALIIbLoZGJaw+iFeVJFKJqb+FlanfakuadsiBBwoCPYkGKNpBFB6iojncYp 0ayXVLpeWYW6FhGhA1yEYEu2/rmr/qyOKoppmz8OW2qfoxpWCGdRdocsm9IkalRS11oz7bWFUlos lJFSx2yXP4aJbrrqrouOpeGwC2+87Lrbmbz23otvNPTmy29cXvYLcMACD9wvqlMSjLC8BtP0X8IO P5zIwu9BDPC/FF+Mccb3BvNRwxp/fA7Hv4JMsr0ie1zyvOemzHLLLr8Mc8wyz0xzzTbfjHPOOu/M c88+97zCz0IPTXTRRh+NdNJxCQYX00o/nbDTUN9806i3qRemVbaB5RS/Fivd9dIrp/N1VVOHPLbM YZsjYdphepSA22eDGUxIofhVNt0Dyb0x30XnbQ7g5Qg+d+B+77xVvGsXDm+3oByJ/upHeHcjbUg0 cRuS4Qh1sg0jiwo2iLT/pdVPMo6GLrk04n0U0ufejhzN5ay/jssgpfvaMO6UVF7566Ojqg82FG0e PO0ADG/mt6EXv8h+5FmKWe+IKk/A7Xnqsvp4rk8Pe7W0Jj8t6QYnsr3sXuHZMfmYgl49qrqXZejx mqYfLfPkXu8k8ONFbA/qnXPfsPLhbxL3aF78GkU/xs3FVJtDVvQcCCRDcaZdezvQBE3jPIQsyEqo GZ+OIGSwCUaQUtH5hPOqFL9EcBCCL7JGtDpEE0Oh8IWdsGAmZhg6B6YmhyJEoZeq1AEeGqMX9fKF DWEIQhkaKUESLCEkTrhEV2RQ/oVGSksKs3HCJoIoiiZEWQ6XZCBeVAiMMaThELcYxukcUY0QnKEU qbTE6YhRSTNUoDoW150YAUYagdJcHj0hJX05Ji22oMVzyMVHQBbGFO8yTiIHI4tPgMOJrxiGcxh5 xsR1ZxcjSQ0ntzEpKPklHvlrzCYOWUhm/EYTuKDLIlXpynJ8kpDqCeQqOREcTMLClj9J5StECb/F ZLI/qpSjtvQozF2+8pfZ6hwpJ2nHOzLwjx+SSkkoWKOOzO5QyEQJWFpiTWBVzStr+VE4TVKccn7l Qz2hyISChc5CeHJv76zLTEpZCt6sUyhTscvs1CmIrmROIAh550MEWpFrthMf/gHdZq2sQikDuEKd 71zoN1+TLYv6k5wQNeY8JtrRaKIDL5fq4CUD4ARt6dOkzyHhRphTwnQy0jJCulpLHSidqtiUkaKR jS9/E6rBKCeU2YQkKNUD03f2pV6YMaUiaAqZ0xCnEdARqi2qSiCYZocquqjqVBXiU01g9aGR0QRI 4sOdfFJmNhm96CUjc9MJ5jSdZ43qKkWKNrtdw6RI4g82qUkcJSGEi6Pc0IOgWooLtSewN9yShfya Ib/GREVBolZl1VpUMlppcT4kqj6u2FQ07miyjm2RJ5LUWA8xNhooJI6elrWe5pgWjQBa7aFUBKT9 XXYWhe0QgIw5zw+xKLap/v1ttnKbOdziNXAesRZfqYOrAOAxJvVM1kakFT/O1Y4cvoJcRKLrvckM KxXgxR2nElUuaqWXEXzKbHfJY6r3GnRMgvyQfLmbKPBWylueIqFzjXMs7XJVfc6NLvr6G96VjvcU AVkvKQTM3++F1kutut+z/FuTCLMvF6hIHoKX6zPCfWxfjGsHiE+M4hSjS8QakxjKoEaTgap4xjSu 8aFkdjLG2c7GPO6xj38M5CALecj8klrJjMw2IisZTEheMs/wKC/BQXml8ZLy4RoyZU2y7coxY/Fb vMyyKWcke6BFR9uq3NwMa0vM61ghkHgaXDA72Y9k45ucv2znKwNOy1C7/vNfobbXNK6Dz2GqGyjW 4+dzmPhUJFUUo+j8s+XBznbucxQpTxUAIxaPe4Z6n/eMLOnfQQN5qsOc59ZnPPKi2or6CCCqm5K9 VelPeP0DTKybmsH//YV39hMdJaz3rUvLD4AEljCnO1g64k26fcm4taQtB6hl3Xo845uJ+WQN7GVL z9Pb295OpFcVGRtPIwWM3P/eR+nSbVomKUQA5Dg3ufqN59pbtktdIui/eKOvezgbxAbfDUMrvas5 RmzjYTWbqi6ibYkGVaEWMQhHQWPRRMjh4hMpzkSXCjG0K7wgr8T4bUWF0Bj/fiHCB57aMr6RtVVE zhV3XMYvdtwYa/zg/o9mriiK50cSOJc5w0ce8IRffOL5W6OYRmXLzuYG6Ah/4cazOjigF7yHWjSH M6+E6Y1vpY79HqQkHXP1CfumFtCMJQVhalK+PBIZyxyjQGxJywqZXVZrnxRK6s7eUb68G9DyBdot +UlgPlOXc4e6UOKOkL/TAu+U6bAjWSkKScxD8vSp+0/DoZtXzL3wbZUlNayRl2JMKPO8sCSK/Kid Xj3SHKTs3DYwb3ffNJJqe5NV7T96jP6oJyjjFLdExK7Sc3Lln7Uf8+wMygqEkkL4ozcE8/1hzw0H lbo9dQjuC8l7hBKooET9feKe35jfJ0L4UKKJTTIM/nXGJvvb7D0+/j1JFrN0DS2xb8xLzIXUqC89 IuQvRzveoRrygHFNpVE5Y0kV4k1otyPxgUzCMRpjJUgK2H0U0lRxRUluJ1YutVXiIHdVxVvFkXpf 9XFLVV/T53V2JVt1ZVUZCEFVoVUTyIEEBxi50oA89ViMsBrwc1oyFRmktxcWyIIi1HnVQRvFsIE1 2IP4lwqNpnH1l1ivEjuoMjp3IWv7N1c2A3McRFppJB4hgUxk5BXDhVoLZ1YJ11trM1sfSEdx5Bly hyXd8CBm6IYU4iPh94F1GBOfVYL4l4XeFXQJolulRVwsZyCuNWCFEIe2p1ivgSOPhSEjQSLVQ4ft sYVEQh1i6IZj/ghcPxIltvAerfWGDWEjjhVUG6FXVUiANQVZ5tCFiVAez+VbTWKA+mMobnIsDDaE 7zU9CLZfb3ZdeggudAJfZGFghtCLungpBVYskpZd1iUunJAstlEqsVKMuUBf7+dywGiL33JoAHZh CcYXAbaMP8KMr1KNuRBtahKNk7EwgXaOu0gqFsaLztiLQwhg3BI/ughh4hIrBxaP1HJQVkNNLRFd eHSNQMKATrhgtJcyiZZii/YdDjlnE0mRKpUxBeB7RBZjXyKRFemRRNaRHxllksiRXCaSJ4mSKamS K8mSCtRk8vKS+BKTFzOT6eI0UdCSH7MJPFaTOgNlU/aTJklQ/iEZhfXGZibDN0VxlGGylJDWMhLJ Yk2pLnemlPH0NFaGFHNDlHhmkfmyld4hOF+JNiXZZUJJZSBzZ4SmNGFplhTzbNvmbJRTPLBmapp2 PnI5b+lIQLUGb74jS/gTCpDgcRgGCeUmb9AWLsrmbptGb+k2JO9jmM9GOxe1bfhzD9RmKNZ2Ou0D LBMTDZhJHs7Cb9hTl8zmad4ojMQWTJimmvv2bq22a4ypl8YRl5WZmMX2KfRjFXaJmKlZVKEmSLYJ O6BZfooJl6XZD535H5BZa4c5mRjDQ0zXc5SjQ/bxcNQ5mE/XQm71dFxHRVwoUYiGG/uhHWu0ndcl cjV3nd41/jE45Brm+SCUaXBhtAh14W+80Fns+WJionP4yYYO14RKJHFIVCAxlwlrSJ8FKnBokqBm FCBmdXPrOZ/vwDUK13Spp53xqU++UHI/UXNLZJ8MOnvRqZ4Begjt+XMPJELneTGmh0iQB3x3B6Pd REzduInJZHjv8g7dwnZGQXqORwl9t0czmntmYVewB3yc5FaUgaThMHk5N0tFylQPQXmUB01qR6SX Vy9KiqNhB03X0Ukn+KPLwnhgWqG29KW8MqYbynfawKbJ5KRmcW9Bal+Wh4jNkKZJGgttCS+lCH7v 9KdOCBU71B9BURWG2g+70VB3qafix07ONxQc4RHiBVGp/odZhGp/WWEIM1ET21AT87c1lDCp6cCp 5yddITV+kWp7hkpQmTo816d+8UR/PiokjspPClWrULhRoXd/qRh+uop8S1qApeqp0OOnqsoNoxqr jaqrDhNUIhijO+ir03odmOqDgiEdtpOQQThESAis+AetGiFC3OGtxyQkSRiArNFKoucWQsh6E9Qa K0ggV5OAp5GjybEJKsgdUap4b6Wr4Xqu/+pVYYWhAbtmyIF28CSvORivCvuEwDeuBPtx1cqnKrNJ PUKJupeGV/GFjbh9o+ghS+hYUHIgjLpaZ9YSHptZd5ixEdEtwwV8kYUhmQWzQhGJERdDe1JmqXqz sRgf/jolWeSgXA+KIbjVij4rWguaoimrIY7YsjjYtPM6RjCLstShsm34Wv8pXCMLiQzmReCKsa/x soIYs1f7MKVYjc2StoIqKr/CiePSK9jiYWkii8PwYM5YYfa1KW96amwijeZiC4mSt8Kytw47Xu3V jr3ph8vhi9GQuBqmjn6bafj1jfIRLgsGpOt1X9gFgm0LLMmYKToxm8UmXoL7CINrYW6rJuPIuXy7 YI/rsHcruaESuN+IunHbMRXbZ84wpU/Juw35u9CpuzXjZSQGM8Y7llODvOgQB9HkYjTzvCUTvReD kVrJZdP7MtjrlEmjvTSWYzTzvSUTvjmpf/7CLfvJ/jLjm7x9dr7k677vC7/xK7/zS7/1a7/3i7/5 q7/7y7/967//C8ABHDsCPMAE3JI96ZFSWV8WG5HD26x9apZV6S9uM6sHhY9mRo5L+sCpoDV35mYe oahwUTXOhZVoeVEAYWxvsThRyTcekTmDgMKFVGgO7DJ+9pVpScNieZYiLJR5Ywk/EmhlNMFUFpVR cmcQiSat87ODNh5305XHq8HGlS4sBjhrwxiyuGI0nDCSqZqXGRLVJpqQk5xDQpulKZx9hJuldnye m8bhSD19yR5m3GuyST9eQm/HZpjChkDLFlnPMwnpscSw4HuN2bZonBRfWA4jk29qfJe9kx1WQiUF /vAk7BYV75Y6cbzGiMhswXOcawxupOnJdOybUOgL2eZq/eWabOycpIbHDEXK7ynKgbK5qSMstblu BNOdKRqiO3dyBrMIngmg1fmhEJp/WdSEf7hyImtWNFWiwuzMPZSiS1h1HwRVo3CgKaeFCdG7q4sm SXedBLoRlUodcpKQzexxa3R1TvG3GyxUHtpG35xDJPrOJuquGffMKedCh/ImXCKgKqdwpGBzf6h1 N9dyCtYkUwcPGgqGzFydETGdRofLBtukVQql7EoMRlrAuOSvuEggvHQLuQRL7iNLhiQsZVqjpUem MLoLtbAVXqpLrKJ3TfN5QYx3XHpjiFwdiiqj/hqdsiXrF683TOcAZSVNpOLgoqpX1Cr10RsNpIVw mRIlDmUn0k6Fi3kaWi6oDYT61HdisKiw0ofUube0XezsNULSq+XXqTdxqtwnqrkiEsiaqyrlfrf6 Wvs012bjsOlXg2ddHf1kxdAXntinqRFVnHcUf9fcT4MaxTgtDfdELXrtfO4ADwL4KFFIFmjw2HD9 qPyn2cHX2Yq9w6vqE+4H2hQ1gaCKqXv4q5hFTYwA2c5qsEOVrjpoVOLKVABL1Z40sPSKr9yaf5XR V9FK1bIttUxazYChrxLrGdv81kXI28BBxOhEYcaqijFLF1NIUht4DkzY0A9rqc9KgxjVhnoa/sIP XK+/AYQUu4INV9tR3HngIHuIBREfGLMIA7K1Bak928sue0UbGxFme7JhS1tNYlt/fFh9VYcxe1lA W7SHdWaAmFykSA7AuA6deDD+LbM08soU8rmqIWMI/rSTtT+vaIgUdIonFbSb/YQJPk+L+CFm+y+V SOCDKCNRu1tWGXSpjY1EOyDU3FdZ4uKTXDHyGCeIm3CK+6iCcY4xMboYBh2zKyrz+F/gs7jGuI4V FeX/qGqSe2z8SA6ZCyrkcI1s9iYX7OTrrBq3ecjGqOYdDF1XPs4HWSbBGCga7gxpdjV9G7qvQZBw 3qxLTg5NHuOUK+UZxuSXG+YuG1+bGdpf/mhe4wZd4QLoBjw3EAlkOkzAy0vpTraRQla9m74u3Qvq Q7Zjo16/6mvqqa7qqw42YZaSCKzCsa6T7ALrQ1PrhQPD96DlR4bjdTY4eD7E2xfaG2GL+Hjr2x1o Z5uUvf4lS6nAWSk20rQuWZbB0G6rYcbsJ3bFXJK+PUyOTezW6qDj145UyC0lZX7sRdmieVZl7K4x RPk1XpI3mI6UPsYYRnTJhDzGvDZvt9bl6OYWhvnvcfmZ7dZpt3iWTdHkrAgk9vydXHyaVH48rgzp f5Fsu8PJjBmXY+xbzBmqEL/wrlNut3NrCp9A3SUaA+Rt34Vqe1kJCO+XhDnxlWDLfCy7/vEIx2Xs UBJ/bJIJ8ifvKAK/ubd8NrbIz/PszPJMdS610BfqhNQ8Qt2N1eXgnY4K0ArdNAwkg8MsxAZuID9U 0A/kzjWE9Od8og3jniqa0MQMdeRJnVE/mE0nsy509WGUzA5x9w6ttW70z9bZhEs7nhQH0fZcz02f n/f8hwu9dS03+MoLEL8ipGLdpkdNdyptSFYdgoY0GzxdoVuWsGdppnKxwic9e+3922H6F+wT+Zu/ XReNpy89sb7R1HPnd5LPpBcYScnEeY3BS3jvGFMfDrQ/pJzfrz0KkPaq0YZHduwa1lJ9SmCVVONs veW7fJ+thMKHhuJshebU2VOPNebt/lagKvoMhKRYwcqo3fmUwN4qDtnKatrMKtfKRxXgp07iX4B3 rRTa5/viB1CkDamJDQgEAIMBgoUAh4gCBAMIiIKPg5IACAMDAgaQkgeag5yShYmHooKcBKenAJ+T o6WaoZCJk7O0tba3uLm6u7WyrLGuAYSGwMPGnMKRnAeECMubqsWt0cyIzgTJ07MCjpIFA9SDlb2d ygTVvrwCBdsGkebVqrPPlAPp9JWr2r/G5tnExr55OgdtGqlw7zYlE6gNmbFD9OTRmxaR2YGF4Phd HCRQI8F6kyqqwujv4cdxFEkeDImt36aPAa5Vq3TwoMiJCCietFeMl8+fQIPuStcP/mLLA4verTQq DCkkTKoaAYAKwICAaMIyRXsH9UAjh04TgiLQDQHZQV3XkTvAti0kA+7CAvVawKKBAcxWUrVKK20B on4daiW6NJiqpCsHsJvqrurVT9oSwT1czuE4yJDAJl2192rVuIifNuZrOeNYrCBZogW9WFJn1JcN hy0UV3EkpiBXvmyatF1UR35r9nzN+Dfm1Yf/9hTKvLlzXESVQvpGQECowv2oWz+aybaqTNWrFWA0 ftAAAgoyd1+s/Xo5QouqJ/tOfusvVATcnWe23hXa97QccBcjBqDTk4CnCBDPJuuJ5UmDAIynGECz YBfhedsFUJhdCVZzXnrSPUjg/nvtmYeeJu21tB+C4Yk4wGDqdcgRhvNlRyMtK0IYEngKziifiQek qCEB33inTYm6eUNjSzvWR59twvXDYo9PLvZhjFAu99yWXHbp5ZdgNvdCmNGFaeaZX84XgGloggIK m23GKeecdNZp55145mlmAd3o6eecRB7WGKDsIDXon4gmquiijDbq6KOQ4rkmgXZO+mKkmGaq6aac durpp6CGKuqopJZq6qmopqrqqqyGueCqr7Yq66yaxtqorbSG+slxZxr1U5m6rPKcsH4C21wA8Ukl p7FAFQLnebz4WguxQSF7irJxLtJnLrze6l+X2uYqKYVmMmuLuecCOCq6v56F/oh3bbI7FCNqpjJv vO6u2dqZ1OayD6Py8tKvuFwqGygAA4CISiES1vhIkQhA7OKgCE74TsWLIXWeVERV3BjDljiCypMf 52dykSVnotWFLZKsZMuTaJfXgQ0yTG+AAmzcjcx97RtTiIfp/HDILpZXJZbsgKwsxuXQNihcWFLc 38U1EyOxyz2z4ghtRGIcotKH0jKy11y3tjCRN2P9C8rDZFJX1RBf7fXZRQ+NLYP1jdxklia5TTAt BbhTyFVrGhRoR2OxM57iGfmFnFcUdiWVWhc6WBxSSR8OTiKOM/zIY2p5bhR/jTn+zGQskQ605Dlp nnXlp4cdET9csbe5659F/iWa7o+v43lHk0FeITaa8NT7YpJHXlvrD1d+OeUv2er588qZBPq+wx8/ /Wm/N87a8Nc3T/3vuAenfHLd98UaYOtLc/DfFYITuPwGGO7SMDMfAxM4+ABED1vyUEV57rG/r7kC Hbeb2UwSaI66RI8Q/OvatCRYlAN64iJa8oQnysMJBwaoeCNbSTWCRKHRicOClEAhTYrRv+xJBQH1 Q+GaEGIWeFwwMjKEk7DOk4pCWGQnwlngLUxYDx9mzyYfEQOcjJgbguCDJ/mzYRH9B8QMPpGACwwi /GqBF+vYwzr2cxB2TIEf+9zmW5OoxCVgNA/89NB90XAj0M5YlEVIhYx6/rPW3eDDiK2xsGkZrMca Y2HHbSHEJP1QIyZKiEZpmWMsSDwNPwpwFTC6Qo7C0skR/yjH1PEjEZkkHiLvl71QEoaRcSwj7eho RlhUsJWidKQrHWTKyrxClKzc4iwMIBBeAgSH2QvRTWBCRXRc4x+0/Ig8oiQSUgjRJiS5CUlCEs0/ GjNJqFHGNCcBvUeWhJVEDKcKjSfFdIzudof8oYHKyTwkxiNW3WzITvRBDCGmi4bk/KQ1ofGLZ2am iq+8YjHFQU4sEtSg9aCn5XRZiauYRXD+waaFiBO80DzuK0exqG8cI8zdcZQU30OiMMZRHI6Wpo0j jWBWducV5iWTN4Yh/una4KPSqshGo5IBzVt0qr2eVBSQaOFbSfmSu9mwtBHAHKpnZqoIdB5PMMT4 3j3H9x5ecW40S21bchJivldSj1ddtVxYuckaqC5Ul4HihB9NBCIx9gSUPIrH1ODqJCF1LK5Ay5GM SFGkxaykRPRpGWBjdqMIkQdpc3xZhlhmnWkNSDHiOayPMiTC7qzMpharEtA8BtQURnFKcpUsXflW WRkF6LEOlIXXDGsxpbWmN5IkG4CuJCW8rs0SftWEbL26WtpqFpu/rSqEJDRAdenyuO1CLprUBCeh MFe5Cw0YmKQL3erqkrrWzUVaqeKc7YZti9HhU7GMm93yIhe75u3F/sa+69z1Vhe9+EqvfOdL3/ra 9774za9+98vf/qYKVz4BcEj8Ow87CfhPsTowlxQ8JwYTuL/yGlgbbSFh1aCrwpCqMHoxnAsjkPeD Z30OdqnVLTDt6sNt4vAv4PvgXMmLxeb6F/zQC9+AybhL2DUnuaaL4mX1eCAqbnGowNa2rkGIaZtt 0Mh4pk+JjU1HgzhbwybWt/dpNrhxI5rSIkY0rJVtt0Hro1vlZtkoX6sbB8OLbFXmUSZLQso3+3LV aitatNmjbgfRm5mJN2W17a1kTj5FK9zmMcc6CcytCDTxMsGAQd3ZNVOBlAaEfKzqbHV6jkve6pZn QtRxz3VX3eqn/hl3vDNi73KTa5/iQH248oX0YKzjnO3G7LzOCSJwn3sXVTNX0thtktSYbl8/gget 9FF1lKOutVTJemlWm7rUvmnpsZ/NEKsppbmUbhUTUeLEeZ4Elf/DYDQ8uElEPlGf+kPgGV8VboFG sRXvzuEj1HnDzGxwxx1V9yjoRz93P+IuLyE3uteNT3eeMN8HhePAw6nDAkYJ3giZoSdVwRaAgvOX H7kzLznVhGxX+tMDGUsoOxpMPRoSmLLsBDDx+EbLkfiW2BmjGylErUQoko20M4ocE9HFwlmnlsNY hJoKWW5WAt2bF4dllBZ+SVW+ZOdwlGcnXzLhYSw9jBHSj4M9/k6nCPDYn0Am6ES+FU7mbcR5IKfj udNOxGXiO+IySfgrZf7Oi8HE7EySscE1KJlectDih+jI2RE3SnkuUKFjR3hCFc52FAbwgXyPOs2V ye67P1GhD9ctNrDNdVXRptmu+d5PUbMy1p04pUWXluOorhes5pLZ0g7r1YfjelnE+qb4bv0gSAOJ hqawdMJ+h21OamHGB6YlKxu97jFn1pdvevdZRc5H/5hL4sA+1ckxayR9gdvO08q1LlktZo1GXMQi 7ByDLTwk9AovSfiWri268ZURrfDSxl+3c2ase0oeo5btBwBp5S70hz/6hyMngmyrVX4Tg0pXpoDn tyDv139U/tIk99cPtKVatrU3GTNcdWaBB+gNHxFk3ucpLDaCsuIFlfImJigO0adcIYBfJbiC6fUG QeFdK4gUhiSDpxKDOthilsJe2fZ5PTiERFiERniESJiESriETNiETviEUBiFUjiFVFiFVniFWJiF WriFXNiFXviFYBiGYjiGZFiGZniGaPglJ5CGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviH gBiIgmiEKTCIhniIiOiEhYAfPbKI+NEambAgyLIx+yIglGggfZIOM6cel/g6U0FMkhCJbzZzfPQj YqFjjBgP1iJmoBAfjfUImfhPVBdyiViLadIJfAEs+bEv/gJIOXRhF3jxCKBIC77wi98RjGm0VNWx M8q4cav0LmXREr6gY5NAVIXQDfoCQdEoDIu4TnDxIoFzF7z0jc5oi+b4cWlHCwjgRS+Rg1OBPVBB G54RHb7QTSU1i8iCa+/IghInSeaxLxFzip3VD/HUDe0XkPI4bN5xF4vBkOf4kMyBgYSjLpPTJ+NR HR40O02EMGtFjJr3KjLlfllRF5DAJBW5Sho5DKSIkrxnKykZCRxTCgoCOkhxGDUJkTjpE45IIDPj RtyYESF5ADB0Ho7QL4Yjbh45i8+4e+xwZ/YgcRIXkqqlLtMISKjwIj/kfmNDlfXEgzn5lUWhLNHR HTzU/hQLAnAaOUOSsR3kAHkqOAvr6BVMqY9kKWj++JJVGUxtJImORztW4ZVgmZOyYBbcCCDY0BaT IZVPAY8Q5X6X9Yz2yF0B9zECwA1RFgCIOSj1uC3VtpRlEk9PwZlOhTCPGZim2Sy4OJHqyCZGBFmC 4gmuaYlRJIxtuQmxeRe2kjN9YgnMoJjrNBbR2JGkVCbTM4nDEJwJsYinuZyoyRLK4UbfgD3Dh1o7 sl6/uXsAcg+PVSC2MB7xUJn/OAtG0jSuiEz+SErVSR6qWJ73U5rM+Z7wGZ/yOZ/0WZ/2eZ/4mZ/6 uZ/82Z/++Z8AGqACOqAEWqDNsXXzhaDwo6AHal0M/volD2pfziKexgWYQiFhGvZjFIZaEUphGiqC u2CUOeMkzkUuq/iKEamhAaaiExQsLIqeuvJ2XAIsJSZkzlIvFfqidAIs8GWMsokqRNGLpxYtJaQs hImOtzgnOaajjiJ/W8KjMkpgThOKK6MxYhZqfjYMZEaiWhoyEpMIPDM2IxqT0ldoZuQajGlAftOl jfCl04Eh4gGnVFMfW4YzQqNn0ZCDWyY3Y7pWPAeQGdOndvNdiUY05cgdlDJZzPBkdHoybmYjMLNn V6aBFyOoBmMlCzKAZeN+aIapVioVnvZoe2YzdyZnjUpnrWVnDgNnj2am+TVLCCNrMxIJ3LV6iaNs /qKmpYYFbBY0GbJaOYdQq8u2l3DpVIk2PKvGq+EQPAThqyzlO7jDTbNGFBe5DgaSrLU2rQNVC5RT beHTZMAKlN6zVb4WapjjOb7mEapDO7Z6US7VrfSTa/3YUyaBPbg2OLoGr9f2a8AKa8GXU7xjbMnW Ee0qoYLwQjGkQQIUVaYxEUu0T6lBgMxEQRdzb//WsAXUoqlXT8MTbw30ThRLRCuEniNUXNMylGdh RCJksZpEYSy7ExtrHiMZcRFEbiILReMmPa4gcKexdmFHcaDEsvyWdRM3sgTHCkOLayW7fjPLdPNW cBBbQxIFbhkLg7dWSUNCUIP0OUzCcp2VcjlX/n9EZ3OWsEhcmwxe66GvopaMJ0lXR3SKcKWNhEtE cXP4BkChaKw9Ybdqp0zFurWycAj4kVSB8wxpG7dkenSIe3KExIo9e0uqQTt8izBI4XM1cnTy13Nf lFJbS7TI2Hh2B0nUp34xe7hWSw3o5BB0JHiUx3/4FLbmphKGsboZIRK2EJlx0bZelRKzOnipC3i2 hEzpoJhAgxt0xDmimU0QF7Gk+xueIU2zerOgtE3HQL1SFJR3Z7x9Bw6+RKyLh2zV6HezC0qbl5RL d3kQm1Sga7unOxV8oxkU4h3W51XtGnMxFUGoYVThqVS34KO4SXpvZ7+wUVPcRq8vRRln+o8W/hGP b4V7F4ec8Ptvudq87tsnr3FSnBF8xPe4qBe5BXt7+dsbvvdQ6pN9yCejI5wfIVw87RdyS/dVJ7x7 PIVNVuVRRNW+ZhFFdgUMHBKpScalxUshgLUfO0yAoJXAD2KdIJiqSWlAk4URPzJavGY5QvKA6Tme XlXEgcueT4wN4BezB4c3glVY7DfFBUg76Qck4oc3QlXFAFgo7kKprGWytRCAO7MkC+G3WtlW+5CA kkUyDDgJESgiPmyg3mehTriOy/KWhryFiMyEOCgnNtjIjsykVCiEcfKDlLzJnNzJnoyfN/DJojzK pGwmM1DKqOzJHSrKCYYmq/wTr2xfsdwl/rPsLSGmpEwaLkhqJrp8oZaMKCDqyxOGyEG2CAnQYwR0 y85xSonipFWHCzWqC4AZzI/MY8qcyToazFNlJtospUCFyOZCzd/8y9DxHtXcnIDpzNv8pCp6zl7C qmibf2Aqp2EWk1uaWY9aN3gqHPdsNGbKNW5jCVKTqFzDqFnCZllGpnV6NKd1aHDjpVpGJAINABNQ z37kplSmqA0tVIJrL6OqqhltqpcyCwaNPXSz0Eg2CfCc0fMwNcFVNFHDpox7zwM90gw9WoRqNV02 inyWNq6aOD4tqKEqDGGaCp/aDWAmmQBjbQT7r71aOtpKaqj21CV8rl/L1OMqPNTTPPiK/jmlJjrP qhyZg62daWzE9h6ss2u72q/fqq/pY65qka6wB63gS21ZHTr+OsFcMayGI9WaBq5NrddFBS3T9te2 JtW3GthevdVTvdd6fayEZ9fQltiNo60QtKyNuY+42lLBCoRm8oI6SbVZ9EcCt7SKV0Md5JIW57ai fXAO+7TbFkH6RhDSS9u2jUh7V0MT5xaj7bGxrbAk5MSvndoTNNp1vXIO123qpq4EhW65Pc7pdtlF O04iK29TG926NtzfVk4Pm1hJ99qwG0DBHatVAcc2a28LixBsQRucpyjILbp1xIp8G0nxvUeKO3ej aw5Q5xI6V0b0/QgWEkZgG7lKOUsv/ky2gAtHh2tyz2zguUe1+51KeIp0efnewwnhTkeLFC5KI5e2 163fZZS2I9ffE66+pGu6XjW5uIaMDI7gZltz1cEkj4Lch8dC1SS86VsK1itQVUfj2O12BAgSzRS1 BdXA3z2MkBcTPG5AQqS6KOd4FrHj3nbcrR15P/t42E28Pu5WioflEUfdMgTl3r13EtG6idd2axvI J966sOvk/yRxvvtNZRd47Q3MDHh8KzXAKww0o7fBoYc+wWtTfM5T/AtSovYay0fXQZx0RQVbfx57 Tt035JpRqISlvNfBc02See58ujd9f85RHszXGDdshM56tAd9tDB606bqiJ5BnU5U/hQ1wzYcfSa+ Fa9O638EU+7nHRjswKjmUi3MKIPcgH8MWEWcEC6dxi89CwqoGy59xHzVfYTciDRzqoueVJy10Rto 7fws7frnxQp3xGcsxw74f3tc7RU47bFSxuXm7H8syB8IfxPIxlWaf+MngR4b3uIu7vc+pz5c6+fH x/juut+ex/EwxOiHx8vORGjozsfCyF7i8Dr4XEuoyDgp8UIxyUkqhhqPhJF88eRcLu5FJiG/hJqs hJicyiq/8izf8n5SyzKooDD/hB068wIDzRD6hdHsHN3cK25EJb4gisPwLPjXibD4aakIYhdW8jPK 9MwhYTHGCBR6JsbMpDvPzcZ1/vWwrKEY3xxVf80kGKU72AnfMJsAWI43OhaZcZvB2I3gW/ZF5y9O L2Jzv/HlLKrK6SpiL/dg3/RDtPdEGtqRQixdTycrnaV2w2VkGlyEBmV1Y9GD2sRUmhDr2I9TKsOL 6RsJ+Xq5o9KCBtKQP+GrddSJj6wQvTRpIDRY+tMyLJILD0hshmeg75GeBjWy3/iJ2tJ5g0llVvqe 39OtKqgLnThdNjceTdKf32esr9ElLfvSl8+Xah5s0fu3NdIizQ4nHdOiAtl3jT3ko6y/Hmx6ndZu bWmLfZ66JgsnCeDF03bNfQgK3TTdbWzlX9WTE9Vop6uLk63RKwjC+tiAQAAA/hAwMChgAHAgUBAg SPg4CFkAeZh4MIDgSFlgKPnp6Cg5IAqAqMi4aYlK+Wl6mSpYerpIqdrpKnrryTiIu5tLwMkL2xjp Wgn8yup6QHAAYJA4W7yMqSl4qvgcnfhZME0gQGhI2wsqzqxqHZv8aN6KLD9PX29/P6j7KOoMTR4M rZS+bf4OHHAErd8gBJ4GKVSU0GEBWdwAMAyGUaCni5UyWTTA71g+ipAOkkSXcd+jghMrfXpoUJHE k6UkIXRZiiVFAw0fFkJGKhqlhwwFirwZsqDJkfNEeUQAUhBRUtx8NnRYsShJqziP0lw5syvGSlNr IhtItuLPl8L8pfXHEKZJ/p6SnBVwC8oQOL0GuKKDa+hmWZJJ813Fhzix4pRMnRF4/His0bRjndmE /NiyK4YDEJ10eTlX4EcGCAwY8DhApQLjBAQonNelAdefDTN2ydkzaKzIcpcWixK4b4oCCKjehlkk AHAABiSMFEqlZKlemcoTxdrUa+qXcyYXqRnSQMeYgYeebPG0bvShKY80eztk8rPFPYa8HH5k8eOE 6iMAukghAbhGHmRjucPbe4RRN99iDj54D1qwyRTcZLAFgA1WgLHlD4bOHKfPhsFJIo1Lxhl0QIlJ jXZIPKvUNMBv8JWI0mQfMgWfTwjciOBuwIUEIkm4EFQXMh96MpVm8Nmo/laGPobWD4uDaVgkhwtR 9VaR7OEoHY8SVpdlevDV2GVFFNZ13C/UAaYjdkimeZhQhhjQ0kNnjrShd4ANNCFeEP4JqGXoaTPb dFyuck1N8LhCSyY3LrITMyMeMFFAgnCE5ywD2LLSpgnxZOlln1FqJm9MqgbpNsg0uqNxqHxlaFqo FufSpqtEMw5QtiLKyI2/VfjOJZlsGZwAtlLDiqLeFMpoMfctg6t5ppY5K6zA8nqXcnVZS2iu26p2 kWaLslqKrTdiKglD4yBAgDfdBlONsskueCuzgN77J2oKSKdIaeL4iR5aKZrGaV2l7frSwa10Ik4o m5zm4kiQxdihIAgP/rJpKeyG6hBPpvVl3SAyYkaxPPryyzBtqqGG18C7puwwv+2hB7NxRn36mAB+ +mKmywsTDGZOCouVH27cCE0waAP/a+TQ5T6ztM7SYkzAvtbVvF3I1iG9K8u0unKydVHvDDPVBg3d b9I3L4eaa/IIs81/aTONTie71uQzgkjTjW/ffv8NeFPaBk544YYf3pu3iC/OeOOLjel45NcN7mAW kl+O+b2QZ85554AvIrfnoo/+YAGhk+745qivznqElLcOO+qOeBN77bbf/rfquO/Oe+++/w588MIP T3zxxh+PfPLKL898884/D/2fKkRPffXWF74z89lf/zn3iG1/L/je/guvO+JF2yMuAQm8jk/R54/+ /j3xT/7n/IWX/7dl9tfP/ln9H76/Bwnqf+PDHf5aF0DEHJB4C3yS7RqoOQJGDoKBoyA+0FJA36XM UhMJStps5REAwK05LTOWaU7ni7ZxzGcUsdt/RAEZrrViEaixjzBO8x8DneeGIczb7NpyMNrR8IQp pJvLaLdDFyJjgyKMTN4+WDBoXcZu3vjhr554RHkM0YZKhKJymAjFSeCwi1lsonFaOEYcduxjkgBj EtXYDIWtxIQeoVFzVONG/5FxaDociQv3qDYe5jA1wjANnPhmsECWJh52DEoZUVHDF7ZLGHm8nkJU BLchwYM5jhjH/lokcY4hbQsamBSZsFrINr0FSxEeCeVohuEjfcDSGsMa4aJMsTBDXNJd1SDTLEfZ DZeMS1gZ0gY6xlGLSQiTmOyIGC5TqExNnrIZ3KARPG6RSWKoY0GcyCa2iGRHLv0SlNN8Zio1Ak4k BmOW1/RKN9npLG/KMpW7XFU8I4bOZrYImqqo5/js4hYm7YkvfGlGWNhyFyhlBVZ8WpNDIqKIllio OgJ9qGDUgqSwABSY/yCT1raR0MZkxTkVMcjs4lSSK6UUNijCqJHCUlGLgKctHNUKxy7EohARzaUb 9d/UiAKWiD4iKHQCqfh2uiev3NShYpLOl4yqxZHeBGyqKapf/nSS0p5mcEBEZFJonOMaUrjtE8Oh T1e5cyhVuoes6hlZWnco0sp850qd+RVXPVKgyHj0SXeVpKrw5JX9+DStz9pWg9haV1iFZ0x9/at4 +CWf8jR0awwqT3+IuNccQecRZV1OIpyTD//Qw6sKilVho3OogImWLd3RFnNAm1fOtvUzjf0nnJCq UjrNqSVsCVIzbnshhtJLR14SbnyYiiE9Fam4iritnQBmLTTxk6lxaZKb/JenMnWoVW7xE3NjmiPn ShWyTJXJZHHrkOZCM7Mzrdg2fPveN62XfmHSimmpiyW1kuW2VmpqVNfy3Pem9SDz5d65WLRMZqhL pup81Ne+/pUe2cDCuGhhlYMVS1F+kSsS77qwgDnyLvZSE1y6XGUyN4wxfLZrm9ZhFbTshZVqAadE qepthJsZsFVGa4A/0nGhDnxcZNCYVh7G2K6ALLgWF6NoOcaWV09140+0cx4QI6fIkOmqVHmHxBks G3qeKMKhEACFbGuYq77RNtVwza1qlWERVYYelsHVJT6MxNjeHIoyj/XOInZF2ZoDNbTVGU91qzJw sOgvqfk5zTaTmRyXmOY1Hou8a6Rb2Jo8N0X/ec6Qe7Se87wcM/35wZSVdCvkXGo6O41fYXPJphM5 6XlUKpF0w1pNypbADEqOP5/Ude0s6GvSIUBx9OXesIMd/j24LUKdyF4dsJvNOdDZw3Tekza0m1cI Nl67dc/e9gRX7O3ZeXvc5C63uc+N7nSre93sbre73w3veMt73vSut73vje9863vf/O63v/8N8IAL fODzngDBD47whCt84QxvuMMfDvGIS3ziFK+4xS+O8YxrfOMc77jHPw7ykIt85CQvuclPjvKUq3zl LG+5y18O85jLfOY0r7nNby6Gm+NLBzrvuc9/DvSgG+6ogaI40YUe7KNbzxGYUTT6auPYxRRnfQ+U oIO6PfR3jNmnua6gBBlr9cV954xNDxXTISO1JX3HRV133b3OYQq19A/r9OAxa7lnlk4QHYPhgzrr 6F4P/sDLI+cQKuyBMtdAsHN7s58oFN8dD6bG0f3YgxCH3LJjD8H7VPMMFAmNwFx5QnZQzY+oZBjn WsaHhTBh2la93AataqBNwpD12KIkAbkpz9POkavm0iKneBohrtpf8xm0m+OYNEietYusz72pxaL6 Kq4kiOijvlAkkWXru77YZjnvWz+aEuaLLB5ZpqNfv2z9qIaWOc98ZHuaT4miVh5V6ce+6GlfCtMr b0naTGYSz+lQ4eRkJ7EoyiBl8eJNOMYvNIYa0YRSoJRLDogoDVgh/dcO7qBiyHQO7VQwyFILFdZL VnYN5qQm4zSBJnaB+oCA30QPBbgRFsgpJhgyeAN5/kpTgyNCPwZoGzfmSj3igXAHFFWVLfOnTzjo ZC/Igv+nJukEPWpHJFHmg1tBU0YyXmHyE8TCFTFlX/UVXVoEU9q1EMpBVGKWVFwCXRsyGGaHX+Mx Uv0VE1iFhQv1hFuoUxGGU3XnUnd0fVkoMyNydh+jhhMDMmqXHPwRhUF4fRRyADRAL1b4gNcXFKTw E37xflQSYWP4hL12iCERUk14FCVWiU8lEKu1La2VFvMRh6hYJqa4Vk9FD2VFWk/yWs/Binw3g2j1 WIeyWGfUisdwPrDYh451WrzYIwgSW3jYIOCgEMdILLdoGHJjix+lO674DX0xUol1iMc4D8OGCePH /hzaWInCKAjKWBVzJWKjiFnOMyOX0IacthX8VVNY0ic/1TPoVV0i5V7NCGHZKHdUCGAjpSR+N1Xh UoXGWIWwgS7EdWbUaIkISVJmqFLzOA8BxkqUF2D6WBM1wS6k50BOOFpd6BCZkCvfhVYSGVXsNyAC 8B8UGY5TUZEjWY/nKBXwiG12NmtFOC266CroMoB/9S7N+JMatmSu8itDBpI2pmULOGEmgzDw4CsC uWL+N2Wq8oPGkGD+J4KOUn5HaZTY8pSQICxRFGLzMJbGEjpBCX6gYRY1CDkIgSJL8ZFTcwg9tJWy Eg0+RmyMsnqn4Q9jiSdvWYRmaWXRwloT9WGP/ng8f1gyzwc2VeNUpRdpyBdrgHY2ObNUTWOZh4Y2 HcRbR8QtX8RoWQManuZnPbOZsgd2dhMPsAdoVhNGAoM28IdnjZaWnvZEnIlGdzN9mRl3mMk37MJ6 TIORjLctVtmWyREVyeEiDJkux2BrpSd7mUaLS2QmAuAtfCYqkHEJsQmctOZ0o+CYafVqOsdrj8h5 8kB5ERRv54l0PadsxrREZJY/Ktk37Hk91Nae+Xl1NcRsqQNu+GKf+imgA0qgBWqgB4qgCaqgC8qg Dbo4VHBtZ+CgE0qh+6Z039M9w3OhBmVuGwo8Hlqhhfc/bfd0UQchduc7JJoggRJ2sKNZDsSi/p7j PpQDQX+oaN03jj2zdeHYMTUUUnBXHO5lf4WYHN9ZGgFVpBWjnOd2QJznpH5nQC0Ko+PjhAHqOTVq dbeWKzh6CN4Cn0+CCQmVIqCVnpbnC3mZkccAY+0SD3kHWlYaRq8pSEoUfXVhfmJUR7tniMrHRXDE QkZyp33kEHe6fY10drKURj1Uf6F3RqMnacuip5I5Q4QqSOsUfKUmqHLKFILqemREqc/3Q21aqR/k DSE0Qs5heraHp69Hmoy6CbRHqnp0qWA5SYzpfrA2qZG0qq4QQ5M0MlQkNovqh33oHf/Bk08ChNaw D4zgLs6UpiMybJ+0jlOKLy7GgaEGS50k/ik9CAz5JGURqAyNohzcOq7gKk/7kFOoNBHwJClKCIM4 ESfWaq4mqK3JZJjNMi/fF00JSK4DqGLsmkyclA6F4E/fOl0AS4HumoT6sU1iyUy3dIAVSYKvlEq+ 5A4a6LDteiBDwqVhCGpGaCcqpYd0ohlnNqwG4y2tBI2fSK0sqhRpCH3tCIesJoQvJVT2qBwza7Ok AhyY2FCXSYmEhVyegIluCFE8SywDiWC2OCXFSGhf9oVzSBXQhY+28RN74VlaxaFIC4YyFWRBm1J2 eDRM1VIdchhyoYgSFYw6VYcXcYeTgxmt0LEiM0KHZ6KyQQmR+BoolaaCaLYiW6Xfsaf8/kNNtfiY 7QGMV/NZO5O4vdgbs/UkjZt/i6tfTHJYQoscljWLhbsZkJu0jHevpVhaTttjdLUeuIhahqKNYCUg blNbiHW6cSWNGHa5aolh1FS7v+i5a2tcOlm775ci7IiDm6NZALMROuMJdMJ+B6IRoXMwqOEq/Ney /LNdTTtRaLiQ1nIk/oi5PjFTvqVZ4Msv21u5XXsn/NhdMRYnCim+s4u9+pokh3stdmmQZai6Malb QjGTBSZg6Du76HW+SoteHhKTHEXA7RtLwpVdT3i+oVhe6EK85YqvIFVF1imfz+qx84cipdR44XA4 1hpPpSZuyeRh7GFoSEkr6NGVKIyL/jH2KuZhaDyGaX5JlUJ5ZaNwMVnZKjL2udXwlefjlETZwqVb wiholbESYgvGLuzIZSw8Y0tZmDZMmJexglfZSsuSlxZWl3EYs1VMw8BrnZaQEEAYwW+ZEJ7SL6A1 l6HDl9ynputyFQiBN7MGp4gWSCLMQ/HwnCFzk4tmZqJZE606mytTKnsMGn18aZQmnUARnrHHN30s m59Gmwmsmm0UnajGmLhpNjODMqHpZornyE6nbDs6npIMyJEgyK05vokGXZWsmcmHnbg6yM3Yaoiq m5UmNUxGMiCTxsnHoxKjnT0KiN9QnXnpjMWZwxmzy0oat84mpWRlzLiTnsIWzfX5/sy7ds3qmM1X us0gh3XWlqL0iTrgTDhw+jfHGmzmjDjqTHHdJm6/886kE8/3082Ls67hVs+Il88hys/97M//DNAB LdADTdAFbdAHjdAJrdALnRhcmpHFgVkOrS1clY69jMYG46PMzJtGOLcUPVZ4E8bex9AjrUDH8CXQ OJn6CgkoPUNoPKYF4dKgsht6Z7cdWwhys5F0FiOptc8kHdASvU824VdzZrBCHdSDmaynMK0cbdJD 5SIIUDCYQDsi7dNVDbeqyMDoMFfFG1V+QpBejWA2cRgeWbXYtdNwxc5WzaBAHR7QWxtMGwlufbeG p69krTV0fRmdocb69SdQoNYAns3WpcJ3cI0XE5IPIZDV/yC9INvUiT0S/xHGPP3Xk+3AwrScb+13 ZPwOEaMNSe3BHWy3dgJip7OErCR9pEvZVQ3UytQfYT2l6zAgAzAHrCSmMk3bn/KmNlkqJQGYiDDG cruj7DLUK53axT1YbzWmBMMxshtHGY3Rw/zci6mYvKzVwZzcF+PR8MUzBsEdKmrc3w3e4S3e403e 5W3eqBMIADs= ------=_NextPart_000_0003_01C64F79.359BADF8-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 24 11:53:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpXz-0006si-22 for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 11:53:59 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpXx-0000Ry-LR for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 11:53:59 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0EE844300FD for ; Fri, 24 Mar 2006 08:53:57 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D296C430075 for ; Fri, 24 Mar 2006 08:53:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE81580C13C for ; Fri, 24 Mar 2006 08:53:43 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [216.162.240.129]) by hermes.tigertech.net (Postfix) with SMTP id DE44580C11E for ; Fri, 24 Mar 2006 08:53:39 -0800 (PST) Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for mx2.tigertech.net [64.62.209.32]) with SMTP; Fri, 24 Mar 2006 11:52:51 -0500 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id ACF15251; Fri, 24 Mar 2006 11:55:28 -0500 (EST) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k2OGqgkI008152; Fri, 24 Mar 2006 11:52:47 -0500 (EST) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 11:52:42 -0500 Received: from localhost ([10.133.240.11]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 08:52:44 -0800 Date: Fri, 24 Mar 2006 17:53:06 +0100 (W. Europe Standard Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: eap@frascone.com Message-ID: X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 24 Mar 2006 16:52:44.0633 (UTC) FILETIME=[5F53EC90:01C64F63] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: aboba@internaut.com Subject: [eap] EAP-POTP expert review (?) X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: magnus@rsasecurity.com List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Dear All, With this email, I would like to ask for assistance in finding an expert to review draft-nystrom-eap-potp-04 (available at: http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-04.txt) prior to asking for its publication as an informational RFC. The document describes a framework for use of OTP methods in EAP, and contains a profile of the framework for the RSA SecurID OTP algorithm. Further profiles for other OTP algorithms are expected. Since the framework does not need an EAP method type identifier of its own, and the RSA SecurID profile already has an EAP method type identifier, a Designated Expert review is not strictly necessary, but such a review would still be valuable. Thanks, -- Magnus _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From kevin@1-stop-job-interviews.com Fri Mar 24 15:06:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMsY0-0003Zc-0Z for eap-archive@ietf.org; Fri, 24 Mar 2006 15:06:12 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMsXz-0000XA-VN for eap-archive@ietf.org; Fri, 24 Mar 2006 15:06:11 -0500 Received: from [201.52.78.27] (helo=luciana.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMsXw-0006wZ-Pm for eap-archive@ietf.org; Fri, 24 Mar 2006 15:06:11 -0500 Date: Fri, 24 Mar 2006 20: 6: 7 +0180 From: "Darin Stuart" X-Mailer: The Bat! (v3.51.10) CD5BF9353B3B7091 Reply-To: "Darin Stuart" X-Priority: 3 (Normal) Message-ID: <1482394480.20060324200607@1-stop-job-interviews.com> To: eap-archive@ietf.org Subject: FWD: Here it comes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 There is a Big PR Campaign running ALL Week! Get PIFR First Thing Today, This Is Going To Explode! Check out HOT NEWS!!! PREMIER INFORMATION (PIFR) Current Price: $.70 Up .22 in last 2 days! WIll keep climbing! Already Starting to move! Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. Premier Information Management, Inc. (PIFR), an emerging provider of information management services to the In-surancee and Healthcare industries, announced today that the company is providing information procurement and data migration services to several of the Top Twenty In-surancee Gr0ups, ranked according to the number of individual term life in-surancee policies issued by industry providers in 2004. (NAIC In-surancee Industry Data) "We are pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online i-nsurancee br0ker AccuQuote," said Tom Miller, CEO of Premier Information. "We want to continue to stay focused on growing our core business, refining our operation model, and introducing new integrating technologies that help move our clients to more efficient, cost effective and secure business processes." From pdkpldxb@csc.ti.com Fri Mar 24 17:30:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuo7-0005gX-Og for eap-archive@ietf.org; Fri, 24 Mar 2006 17:30:59 -0500 Received: from [82.160.190.32] (helo=SUCHO-HV3Q9X74H) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMuo2-0006hC-VH for eap-archive@ietf.org; Fri, 24 Mar 2006 17:30:59 -0500 Message-ID: <001201c64f92$a4327eb0$20bea052@suchohv3q9x74h> From: "pdkpldxb" To: eap-archive@ietf.org Subject: Fw: pdkpldxb Date: Fri, 24 Mar 2006 23:31:06 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C64F9B.05F6E6B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae ------=_NextPart_000_000E_01C64F9B.05F6E6B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C64F9B.05F6E6B0" ------=_NextPart_001_000F_01C64F9B.05F6E6B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Delgado Giovanni=20 To: ntuokyef@bn.com=20 Sent: Tuesday, March 21, 2006 10:13 PM Subject: eap-archive ------=_NextPart_001_000F_01C64F9B.05F6E6B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Delgado Giovanni=20
Sent: Tuesday, March 21, 2006 10:13 PM
Subject: eap-archive

 
3D""
------=_NextPart_001_000F_01C64F9B.05F6E6B0-- ------=_NextPart_000_000E_01C64F9B.05F6E6B0 Content-Type: image/gif; name="othqtsk.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c64f92$a4327eb0$20bea052@suchohv3q9x74h> R0lGODdhWALdAYcAAP///wgAAP/Hx/98fIAAAJkzZgAAgP/Z2f+np/8AAP/w8P+ysv9oaP/Q 0P/h4f9NTf+9vdVZWUTXrxgadP/p6dP7x5CrsJYOI26wd/+amv+MjH6kUZbhsNE5Wx0iyz5e /dLXfeuBsfrcJCeK1Iw0UwAA/9ZER8aM0klzGMdoiKYRWGYVKjeJudx1Gr/fxmrvMBDmVzRF YW1X74rD7aj9AMfEDEWbE3alPhfoaZQRpEtTSms7NrdY+ibCg2xYip6AK70KWztmKQ8pfBL7 gGwfz1SzU8x/WPECbFLR8Xda0fF39P///wAAAAAAAAAAAAAAAAAAAAAAAQDMAAAAAVYAZQBy AGQAYQBuAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA5PoUAcwAAAAAAAAAzAEAAOT6FAG9AQAAvQEAALT6FAH4CdR30QwByzAAAADM AQAApPoUAQAAAADIBZF80JtuBHD7FAFRBZF8eAcHAG0FkXz+////EAAAAAAAAAAAAAAAYPsU AY0J1HfRDAHLAAAAAAUAAAD+////EAAAAAAAAAC9AQAAzAEAACADAABYAgAAMAAAAAEAAAAB AAAADgAAAGMBAABsAAAAAAAAACgAAAAAAAAAAAAAAMwAAAAAAAAAzAEAACADAABYAgAAGO6Q fAAAAAAAAAcAAAAAAAAAAAD4m24EEAAAAAAAAAABAAEABQAAALT6FAH4m24EZHYACAAAAABw BZF8/////20FkXwrXtV3AAAHAAAAAADYm24EcEMMAnb8FAGU/BQB4wQAANibbgTM+xQBj13V d9EMActwQwwCC3MAAPz7FAEPrvN3vPsUARiu83f0////AAAAAAAAAAAAAAAAAAAAAAABAMwA AAABVmVyZGFuYQDiNx0BdvwUAXBDDALAiB0ByIgdAXb8FAELcwAAotTxd3DU8XfRDAHLFQEA ACkAAABq7zAAdvwUAQwAAAAAAAAAau8wACwAAAAAWALdAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl1asAfTp1CjSp1KtarVq1ixpsjKtatXmAQIZA0rkCxEsyfRtlT7ta1b q2HjTkTLlmPdi2zvHjSrN2FfAHHFZswbeCBdwYAF5y2LmDHBv28jSx6qtrHDwyEhS5TL2LJf zw8haw7duLLj04k7P1bNGvXk17CD6i18mmxgsbcNK96tu7Lc3Ikx26ZdkHPw3qVpH16OWHRz 4sFB6y4OGnPt1GVbG3cdu7t3m9tr/vPGbp3vePPiqU8nXxh98dS4z8tPn/3x+M/r3QPGb7/6 /Ox0AYgbdut9Z+CBYBHn3oLP0ccgfQU+mJ9n8e0n4YUUKiddhP8tVBdwjrXX3HUWDkgYgiim yBJnGKL2oGLsKWhddPqxZ9B/t+F4n4MbutihQn0ZZ5uAhk0Ho432qajkkiS1iOSTLM54430f JsfdfkhWyaN6TyJU3o78eZncbqUZWV+NBDKp5ppzJZllh/r5FiGXM+6IJpZuBvimi3umySGE FXJZZIFpmtZbfW4SyuaijAIJ3aMyBiqlb8z111mDE944JXL9xSmkhleCSqCogl5qmZyD5rep oo226uqr/4P1qNFoJdEK66245irrRrZmtmuuwAYr7LDEFmvsscgmq+yyzDbr7LPQRivttNS2 VEABNV2LkbbVvsUtAN9+C26415ZLLrkEiTuQudgKhK677aobb7vr0gsvu9jiW1C56bLbr7kG qTsut+/qexC/B9srLsLw1uvwuA8HDLBD+GorsEb+1stwvxovPPG+9GbccbdPvQuxxhKDvG7D Ebc8b8QEL3wvyglzzPLMMIdsb8o8n2xyQhvbfPPAQhf8cs1DN+TxR0a3fPLTMTtt8s8kLzW1 zk8PffHSKvdcMNQ4E430zej+HDXQO5Odr8Jpq7w12w5f/bDFbWft88c9D9w0xP4xC0x10hfb DTjWLAdeNVJnLy0v3Hn7/XbhIYMNLt+Ca00435ffrdDj9+5seMOcq5114jobvjjkCHFNeudr o+304Km3fbroen9+eFB0083x7EmzHjTru/MbbuHuUh64x3jrbrnveeectsFuy15x3HADfO7m nh99POOrj1431Gzz3vXIQoNP++1HWVy84tmX7/L3YlM++fCgF6/52JhH/37v7qstfs2hM5/i 1le6783ubI3TngJBJr3XeQ9/43sg6viHPqEgbGPT218CF4K8sE2ufh9EYAQRmEHVwS90yqOg 757HPeiJDYOtg2D3Nng/Eb7ub+Zr3vh4R0L4VdAnXP47n93oF8SVaVBr/7Jf/5Y3wfvlMHZj 6yH2btjCI0pwezmjoAknGEDayS2C5+Ph0Sr3Q6AU0WwsRGPCgnbGrrEQivszWvJE1jHhXZBw LhQiE9V4xO3BUItVBJ73/Ii8ItbuXIas3b9sV8ZGOrIojGRIJB9JSZSMoJImmeQUMcnJTnry k6AMpShHScpSmvKUqEylKlfJyla6MiIneKUsZ9mqF9DylrjMpS53ycte+vKXwAymMIdJzGIa 85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685uwMYA4DbATcRaEnC9JgDrVWZB1 snMg7xQIO93pTgDE054JkP9nPvUJz33Sc5/4XKc+/xlQgRY0nve0p0ES+k6CHhSgBSVIPSV6 z4QmZKIMpahFwXkScwoEnTgZJ0FAypKK9vOk/ERpSleKz5Ui1J8QZSlEKxrTlqbUoPJc6Eth qlOV2tSlBIkBTR+yU4mqtKYcJYlHDTJOkJrTo0ttKkmbOhCpVhWdS60qAKJ61aiSE6pTFelH SbqQjTKUpz4dKkpfutaablSmbgVoQ38aV7k2NK4UPSpSW8pWhyCUrixNqkqyetWxjvWrT8Wq Ypm62K02lrBbdaxWz6lYxCLWsJLNbENw6lObqhWueb0pWn/az71+Vq85/Ws7+epZvKI2sCft 62b+5QpY0go2JZDNLFgxu1vNWlW3jyVrZHXb1d4at7ESoWdn7xpauDqUrwLdKU6V29yHDnS6 N10oa++K0ZnatbOx/a5faetZ2N7WJLk9Lm+Du972Hla4w5Use4G7XqpaxKBnBW1avRvb1IoX IZw9LT9NOmDttha2n5VtO/Op4LKSl7W2PS964ate+lq4wl5Nb2Hni2H4VoS5oT2tiL0LU/4q ZMQ9rS2EjXrgCCf4vxrtLlEfPE/zSlipTnVvh3U8X8dquKs8DvJHMbvZ5soWxfutroAVmmTw 9pXEBg6xa0mbYJeOFrwqDuhRbXxjjdj3vYW98Jd9fNwOhJmplC0uh53+KlbNzpazB13wRJus X+dOd852BnGBq5vTBV+XuwEO9JFLXE+LYtTPpYVxl0PqYYjktstvXbRVHv0QSt94r5LOtKY3 zelOe/rToEYlC0JNLEt3xNRnJrWqK/1lVDN2Ib+tiKvdzBDq0lW8GbVtpENJg1VzJKvIZbVC gG2RWc+aylZu60wHWtrJrMDXKILsb8ds396OlMLstXasffyBMJvarP+dq2rvjGloA7PNZ65w ZBN7EHTz2LJiFvK3wS1aeNaWwQyOsLmHGWuvure4Cen3muXd4zcPtdDknatCa7zrfQdTrP62 MMBhnWE2E1zIEbkzk/Ft7z2jteEOPzdy1W3/WFRX3NsDj/dEaFpiFkP44+UO+S7DSmR1X5bW 8fVtm3escmsDWMkm7jOzmcxnmYsc3RBHetJT/V6yAnvNSo84qm1dZ6JnF9FGV/Wxs871oGy9 62APu9jHTnZQWqDsaE+72qX1dYa0vSFvXzs2I45zhMQ94I1mNd1JQvUUJzrmcqck3Y2d94nc veZEHkmDr2tkwAe+kYNn89OTHvWwVlzyFsd5ejF/7ZMn/iCLpzPIHw/5HvP89E4PNsaZfvFr /xvAigY6lklfycSyu/WoT7POl655bK9e4rWOvegdT/sKPnXIl085WFstddO7+/MY3/m2HTx7 Kgu/+IJfvut1z/N2/iuf868Ov8+BP+Pqvxj7n3z69oeb+yFvv/tjXn/KUT7ZebcV67dGvyfV 33nL21z6k3d56+d9ked5YAZ9OqVxf2ZXcKZ/SXV4DhiBDgGBEliBFniBGJiBBBEBGtiBHtgT NfCBIjiCJFiCJniCKJiCKriCLNiCLviCMJgRNhCDNFiDNngsQnCDOriD2DcEPPiDQBiEQjiE RFiERniCAWAVSWgSSwgRTYgTT3gUSxiFCkGFD2GFBoGFMqGFP4GFAVAEKhEAYjiGTSiGBGGG AoGGZFgQaFiFa8iFDlGGcniGT7iGA1GHafiGZNiGaXiHfggAY5iHfLiHf0gRgXiHfNiH/4CY iFY4hYwIhwthh1dYiBkBiXE4hwxhiWx4EJLIiQmhiYaYiBMRhYe4iIQoiJYoiWX4h23oiIhI iVuYhXWIiav4ipG4iReBiYtIh2dYiLUIiAjhhb44jIoIjFlYEbX4i8aYjKI4hcSIjL04icVY iRrRiqkoEVSIh8H4iSMBilUYjcYIi9rIjaxIjK2Yh7YYjjNBisWYhO64jOZ4i+BoiL34jsn4 jM4Ii/roh/YIjr8ojKOoj+NIidnYjtNIj5x4jn2ohwqZj6ZIh+54iKUYkabYiMD4joIIkQ45 kQo5jxBZjgsZiHI4krMIhyT5keR4kAOphRbpif24kIrYjwPZjv+iKBLsGI4yaZAxGYkSmYv1 eJEgiZP8yIadyJJAOY7/WJQIqY6DeIwe+Y+oaBGMGJQbCZL5eI/+yIpQuYkviZXwKJTR2Ig3 +ZVeWZVgqYlbqYy4qJLzaJQJeYwvCZTwGJfquJNhiItY6YhNWZdOuY8Z+ZBrSZZUWYqA6ZdG SZcnaZiyqJd9WZBsGZhg+ZV8KZE1iY46WZbl2JV2uJcV6ZCRaZWoaJaeGZV8mY55SZWXqZUN kZar+ZRtGYo/iZFzaZczuYzeWI0aqYa0uZiE2ZcHiY1hGZOn6JnEuY3biJhBWZrKmYkC+ZiB iZQ66ZNniZo72ZXBaJav+ZtXqZ2gmZX/y2mXggmeokmQJhmPzCmO2bmUOVmdu9mc6VgSK/mY jhmd6CmVrsmU0bmVvtmYa6mfkCmNklmcnkiQ1Amc1ImZ+fmM4pmcalmX49mecimZBDqdFBqg 9PmZ+JiakKmWY4mh0widvjiatdmhJBGfDsqdCqqSneiE9amNLhqWSpmSJfmhoemXlzijDrqZ b7iYKBmKg/ij1hiZysiRs/iX+ImiIVqSG2mNusmbPZqYuziS5siZiIidEzmgVbqfFemRVTqW SCmi+8iYUHGbS0kRIuATZMqiEZGmxMSmrZkUbmoUcbqmShh4c3qecnqESnEDetqnfvqnlHSn KTkVgqqm1LgR/5XZEddok1r6EoX6jfaJqL85qE55m6OJp0LxqFqqqS3RoB/xqJw6qRyxqCjh qTaaqZKaqoaKpcZJqa2apyAxn7D6naqKEaFKq7b6pqV6qrfKEqA6qgb6qqw6rMLaE6qYpchq pIS5ojrqhUwKpYXJjECarF26pdT6pM8alXqpn5RphlJKmjxqrdVKraqohiKJrDuqrMvajLvJ kNl4rgFakwyJrYioA/xIiuu6rTiZrcn6rt46reP6rdGakE36kDvqreC6iukarb3pq905mc6J nRlKjghasajZoKyJpLL5oBbqoRwrsRranyH7sZV6oMmJlxCKsd2pshdaoa7Inyi7oP8eq7Em m7Ix651gapkda7Ey6xJ5Wa7mmpst658BW7M7e7Kn6J222bBeOrJOS5o8C7HgibObabSJGbUv C5dyaaX8aZ00S5MNebL42JMym5QFO7HD+bBFK7K2qbRHW7YF2qlqS59nO7Qp6rJPG7WimqDf 2bR4+7dYa7dTa544a7V5S55ai5FcK7JeK7V/+7YwG7iAC7MSqqF+O5/EKbEkO7l7exKn2bNw +7WOu7mSq7Du+bjDWLqGy7mjO6mqG7qQC7It+biyyq2Uu7heybavC7loW7OmO7gVCrqku7o+ e6VGaq35qpFvWZhEWbBWCqTPK7BEKaSVSaRj27HiWq77SrT/yoql0gu0vAilCNu9wgmQ1Ouh u/iZDSuk47q9igm2cyiwZnup3Aq9YLu2zXuVP3qkRcmR7tuyd6lqvdoWA8xLBRxN67soiQqo DNzADvzAEDymBsKpgnrA8HmojHqqxVqynruqmNrBPtu53mHBAKqoJvzBAJyJCZwSkNjCJaqV hBikIkzCIuyqNsGm+Rq0OqvBE7yOsXrC8si2q0rDkFrENgzEHSrDtErEOMwTacq9SszDnsuk 1UqkOJq95PqI5iqW57jFVQywzXqd0LqiW5q8IUm9+vrFAPuf/SqS/KquHemvm/rGyJuk9wq1 vrmerku2zNusV2yw8Mq87Wu88fq9/+xavkrar+nbookrtfJLx9Ybh0PZsyD7trkrxJirswga u7z6tErrmGEbsp8suJFLuKCcuo26t8OLonGMpEd5pIV7s6tsyrrru5NcubHMyYt8n2lLlzar t+g7rJscvQ86nObLshI6zCNLxnUMunzbzDDZpZfKvp2ZysqMxlz7rsVatbB7tbk8oQKay9ys y5w5zZd5rJdszK1KuuO8oaz8zjnKx1lbzbrqybO8ncs7yrVMy91cxJurz7m7rI2asRtMu4dr kM66n7vLscFLo8lcyqyruQy9z1yJtNcJ0bwrqjd5yo7snApat7q6sXz7uhx6uxht0CgtzqSs t7jrvXELzv8Fes9cyqWXu7oBLbYzOaIPK9PB6cybzL+3TKIRLcqYrNAc/LvYS8k8Kb9Tar8u S8XLu77H+qRjW6SCjL/Q+sztbLa8OL1cLcZXnJY5TLcES7BbnMYJa8Uq2pEOfbd4nNbO28ZF Kr2DPJV2DMdgnZ+R3LfQm7M9zbBi/ccFTMQe7ElxSti4SqcBWavchNiSLEpuysQLDI2KbauT HcGYndmavdl6ytFB/NhSKNSna8Rl+sKRGqmkCtq4OauEWs9RQdCpvNiJvRNNjMLBStigaKmq XcKknau2vdS2u8hZe8gSXMOzXRSwzcYLwQHrjBS1/dnquau7/dux3dsFTdnQjan/uMuM72nc Q2Gqys0UejzVdI3ITtq/XKywYorXcl3W4mreITm+gJmu6I2v/7rGynvGfSzPWcqsUNutA6qv VxrG7avGVC3f30rgBT3egunL723GzSvXOHqPCOvF/z2+GAvhgO3YwBmXn8uyyPzT50zL6Syj rmu57im5AH26w23Tt/zXi9vTGUvQmczK1wze01vRIr2dDg7iJh643K3JxCubKo26N8Hg7Zm0 L03NSi7K6ayjXX3Stgy/B926iFzjIArMLXnNMm6eJFnJ9Xu2RJ62O8yTsTmd+FzjyGu+Ve7k QmvQs7utcp7CPuzhKwupIS6231zi+bzLRB26C73Sek64/0N9ohyMvRw94yxu0sEr0Bua20Mp 0lsLvD9N3G3e6DQd06V5yVauE0N65/Dc6WDOoBdbn4u+6Sjez0bO5Kee5Ya75Zoes4ruyb07 tS0txBNK1pYp1CKeyUBO6vz86S5d6J6e6/h81Un9il+dv+K4xnudwIQM4zS5vfGr1/Iq6cg+ 1Vn8xv4r7bsur0q9r8dLxmEezobcx2aN67T4n/N7vNga5vgbz9dbm+C639x7KxwOFJqa74zC 71/h7/0+wZdd2Y0E8F1h8Jyd8Aq/8AzvLHP63FL81x6B8Od5p7oNrNIt26tNEzQsq9aNkBaP qBQfEhBf2m7x8BGf8tPdja7t3f+87YatLJyqWeaOGsAlj8FUcfPBGhko7/I+3/Isb9sUrNrb PfN+XvMs/PMqv/I3nLB3jehODaPVK89QvexUP8bsauFwfcfNXN/Mjt7prt8aDr76beCKjODo 2ptMDd9/ycwz/cq/64w9fq3s/eDO++xRWu/MbLxcHLCBrNbXquAUGcKFztPeHstNy+cuftG0 LvOpnuys/rUx7+1BXtR4eePEKtM4fvQMzuMROuhCqeV5q+IBLvmLj8toi/DZTOLSLLh53ram Ps97WbFsTubU3tbHPurnzLTAfvtn2c76DM2fb/v+yN8Nvfk7jOSKS+k0H7EjfqBb3fhvjeWn P88rHhP/q++0r3/4hF63Q2rV/8z5mQ67FCrikd/csDzL78u66M7GPO23If3K7BmebenxlZ77 rhz+jx/sxCv+f+6wAAEgAACCAwkKPIiw4MKDBhkqdOiw4UOJFB8yjKhQ40WIFjVWrLgx40eP EkcaPDkxIUmMKhOmdIlSJcyOKz3WxImT5suSM30uHLnxokmXH2XyXAnSZkaaSnX2/Pk06c+Q TaFKLXrzqE2uXb1+7bqV6MsAQYWWNYl26U2yZTG6bQhXoNq5EeXaDYpSLtK4ae/SBQlYK92k A/Pu7Wu2blu8eLPGjCkYcsG9iBsnHiz2cV2nIuNyrEo5pOi+kwlfJj0082i0/kdZ/61suHRJ xEPvgsWdW/du3r19/wYeXDjH4VxHF0eeXPly5s2dPx9+XLh06NWtX8eevTjh5ty1fwcfXvx4 5d6TUyefXv169u3dv4cfX/58+vXt38efX/9+/v39/wcwQAEHJLBAA6FD7zzettKNwdwSDKs3 CKPzasLdQjPuKwvZ23A64Grb7EAR9etwwQ/BQg/CErersD8LqVtxxQczJO65GGkUakQd8ZNx xt9SRNHH76TrkbwXNfzRRhyLNNE31kLcMUr3WpuNs8WqXIxKx5aSLEu1DJPNSou0rJLKtcTk EjbR9GIKTLdOW3Mm7sxEyjU4U6OTsbb2zNPKOWNj/tMvN/0K6zRAI3stUD3zNC+1K/2EjdA4 2ZLSxag0aylT07KCqbPbWLIK1Mcw5QvTvCibrKZOLz3TNaomUkxUTWs8VdacUiV1U+JcjXBW XCklKVSsWAWq0gBDrbU1vUqtEarKijKVWGGJZZYzscwcS9ZVNQ1NtmjPGlVOwLKtFiJssV1S 3NqERXeuXm/Vak0MdbUVtVOZNDY9ZOkt7Kozc4LLrG+lmpbbfx1kia+EeVWVWlgR+tbTg5sN OF1fc3zS34nrtW3jjG3F8ap9DS42X/9G5rhOh0EedmCXgc1V5Hg9c/ZVkqeaWbNYC0Z4YZlz 9DlhegfeNapyYw6W2peF/u7M5PvovHNhNT/bsrCKH3V3LEYNNapWlWk1NC1Hs922YYoa9fpa pLeu2t2jsfyTS6mPgxpQO+n+VO7D8K462T+vphlKpwcn/EB83YMBvsP5K3Lxwh+HXHEQIy9v 8kp7dJxyzTfnvHPPP7evAtBHJ710009HPXXVV2e9dddfhz122WenvXbbb8c9d9135713338H Pnjhhye+eOOPRz555ZdnvvniMHA+eumnp75666/HPnvtt+e+e++/Bz988WH3YHzzz0c/ffXT t7zDzPfr+V0a3W+2RfiTpO/9I3Gjn7n3Qy7R/7ajrMx9rH9K+hfQ+rScACLJgfYL0uAEWJ4E /gruRPwT0gEhiCB1fckuFjSScwwooep8DGMKY6CTHii/kG0wXxNUEM5kSEEM1hBoK2ShCDlF ls/UTz1aOxvfJhUnti3pNgELG5+8Qy4fWs1Ne8JM18pknC558E1ZG2Kbrji2Rj0qbE8cohej 9rc0SWpuheobohSFJjGhLYyS2VvbiEjGCorRbpmB1RrnBTE+glA8QByWxnIWLpzljWgKRCGq bIgyhjllXgw7m7QkeTPIsAtmNbtYqiZ5wmoxklaaJBlTfrazodVxk2tTJMs8461EcognrBSa IIOmrIN1CVTnaiUTefjAk7TLbHripKrI9jWCnbKClpxbxHBpMTSF/8lacitlykZYNJYtjZYy 7KV5qlLFn7WxkwmEJAw99LAwkTKTyXLgTnaySxMCCYLr1BY2qQmwXFnTmDNMWTFDSbFHxitW 0PSkKoNGTAfZ851GO+Y9UaZKQOrSlW+bZ8/QSU11rkyi3wTlLCcpyouts56jvCezkBnQmPWT aeVqlUIROjOCjgmkEV0ZuPY5U4CtlIkOXY/ESnOBNIVoi1KsJeCyOLVURjGIukzbHYHqzTK+ RWxa+9sH0wi2qd5SqU0h6tHmZDUqmrGZ3CyqIt14xq6hBms83FtXkbhWQRnVl1mcoU6JJ87t 0ZVHt9PfBYPXxfUJqXB8ZR1gg9PAvhbWsP6HRWxiFbtYxja2egX060PDY1doxrBAkLRsCgdk uSZeyH+mvGF2KNtKZj4NOzACz//2p6Exysm1YfXR4gT4T8ZFdkqerY4EcHidCdFWPgIkAT6F ax3V4naDpFrWW3rYJNnqsLOmtaHijIscsHpprZihY53GdV0nsvFOYJoKd/GUXeuWE1FonM25 0hrF9faUjc10W1TxuECf8pGjMoHl13iVqDJtt5ytdRR2yevW+B4qwEl07wL9C8UDX41tGLrb eulLwvDusJvx02csNZopEBkSNMYMKErh9UuDBvOiyn3pUxK0Lvs+rCP5tRlmk0bTEps0kLcs pUcPisiSZbig3f6Msc36GNoGKeWDakQubGlMSKs6WH7XfJZTheqzxuxxUm2VCgqkpeCVgoyk w6XiK4eMXw6vBZYy1umXpWzjQJl0mGdZppIFmuYtt1TDrIyYPAfo4h6ak2kQVtrG4BU/nAIO YXJ1JmoxGs8lExmeXlYpad+FZ5/s18x9RLOe1TziXznaaDoO83L5ZWEfsxPIxTJvmUU82FwO klKAvhmbMQlOC3tSYKvmKFYamWI3W+zNtk4kuW4t1uFOtJ+bXhpE/cwgqyimabLMdbJVfeOB 7tq3RW5a3Lxomg4PJsBoPW8m4dw38nLtppP7Yp+rqNSvCpGqzmZ33Y6cKLka5cOClv+xHXGV 6rJiCdxBVCunDKzvb0+xq3jsL7vGuuErXZvVrxvteOgacelRHEAWp27sMH5azmbWsUTenGA/ PnKSl9zkJ0d5ylWe2J/mL+MEAQFvKQRy23q8QaCtj8VXK6HepvavEdSXzZ0L9FWXcLp+5CUC 9VoiF8ycRMRtEtGd7rQJOq65Mo9uRo1+c5xzneZ6xd/XP3u/rXt9tw+XoNKj8yWgDOqsbeyw FRkMXgnLt4hNbXuDDV2aPkWYwQI+Ipv2zdb5tURLXUz3wce0XaM2HOHu9e6nJOzv8VqGw3RU 8MAbjniiHt6sdvTa3CMV8LyvMYxwl1EvOw1R1r9W1588NY7+ee3SlOaz0x6WJiEtDSw7vy1t GpN27TkZ7ULuOGO7Lr6gWbXsfKKSyqW9seob3XrjMjujoWfpW535TB43udfRBHXys8lifyH7 0qnG/pVHxahS+TK5tOd+d5MJ/yiju8uUnr8C5f3jeV54Nf5sIaYyMdWwPZaKOuu7pATMPbgx pYmaNAIsNZkSvy67vUULvhZDvgG8sydjMrGZMU9rtFwjNlGDthZbQOEKPysbqZDaPlJzvpoq wIE6QAhkPpiiqdfrvoKBtBDkM/2KKQc8QaRhuBqswTGLpk/DtUiDvWcTqGorwSVjvhWcvhsi vg2clQtMvwyiwc0QL9bTvnCDrZ//kiO4+rv9668JBLgw86h4qy4vTDTS+ycAKzC/GTbKU7+j gsBte7uxecD/C0M2FEIEmyX5Oin0ukOMiRpdQxvB652Nu6vlccQdaZycY55InA+RAx5L7I8f yLqokxxNXLlQFMVRJMVSNMVTRMXT0ixJiw8rAztW7MTueK49+y3pkq5JBDMV0h2H6zpXnCyz m8XGcyEKAyYWAUEpA8ZUahxM7LpimzBiFC0M8kDYE7uxgzikExxf9DnbOqAVG6ei00VFo6Rh dJtqhL6ay6HAQbtoDJJpzME/gh3P86orG700ZK15jDw9YjcCs0GgujuIMb3BE7LvWqFAJDwx W6pMMzxG/zxEx+g7bMI9PQQ9wBO9g1QRZAS89mq871owHyw4PuxCgSw9bKShGDy+geQ6ImFB BRTBCuwxCEu/kUE+DIs1j8mQmewo1zM/E4rAskm2Evu6QNQVlZypR9s9EIxI8COKjaND8mvI NUORcelDrGpDAMQ7X4mjLZQ/UTmzdnGnzxs1w5MXVEPEvAnCe8OnNuMzKJs9qGzCdOLCoaSb jbo/E7wm+ROUJ6myD2PKsFQ2IQM6d2zLJIQ/YrqVhfKzTTkz4euVazPKkumWIWOys5RAFLoo cwqxQ6PACmFLfOsYTUNJRFpM44PFN0xLcyxJHXTADLQxG5RCDaSYHNskK/TCof/0KZx6wvha vWCzQJlpJ036tcEESm+sS+CzyWkjtN0sv/oKy0gUQzucQ9NrG3r7SI3swsyzPABKw6wcN1/c KtvQwaJKEbOMDAakRoHDsnYjwbv8tsBoL6gRSanpLLLZJm2Ju4FDrtbkvCnjK/eczMcBxVek Ou0J0CHRnAKVuP9A0G3MngVVxchx0FSU0Aml0Aq10AvF0MWqunVER9Yixz2jrLnMD4qLUGsk SQ5F0bNjUGNJvXMMwKA80WlaxR9SUQMNRuqSgWTUM9QMuxd9UGPU0RpN0WYcUQHVsBe9yBt9 RxMNug+1UR79xlikvqHzUawD0g5Nx6lz0vYYv400sAf/y8fTuzt5NEQw/UeCW5TSkzvKO8qO BKb9nKIres5FGTC4us7qsiLUgjE4zbu3Uy+53EfoXDczWrjsisODpMg4Nc3N67gm7UndYyZY A82anNQdPSQi/L3Q2r16M8BXU8aljFSWVEYlbMGbNEIfer/EDM3w7MAMS0CZjCAZhclAg9In tSYzXNJ+W1JkWjRli7P44xe/iZDRjDLYdMUvREhLHctKpUwmPL+yok6R4DL2opnwnNY6SwxJ jRYisaXV+8K8VNJf5EFmdckRy8zjVFYqpMmKYgsWG80RNNaEusIK88xjRMBHhUUMzEYk3DFz AaTo+896WtdRsr9zAr8yJFIa/x1XVy3XE4tADZRVT6XNe3W2UO095fzAe2VOk+RXfJVMEQ2c 7xNV5Iy9KJRYzKRLdP3LeWW4/HHTM60bvVGj9Sy3RZ27QiErrClUrfTXPuxZ3gvJhNPY+pnT PYTPMkw8MYpN0EC3buW8p1TE++SvhNQ8MJTIaC3H7LMl6yzRLc3QKxW62ula5cmcDfjaEw1S jWvUs2XbtnXbt1UsH4DbuaVbsmWgw8GcVvTEAfUfjKPJkkRbruCBwA3bwqvVkDu6wtXFy5Ks WpzRhL0gXOzEvEpQChtb+9g5wNVSAQnQy6XcLH05yZW6wwVdK8Wty+0OQ8U8tuMuMuGipg1I vYOiZ/+k1pydMAADr63E3YQzREZlSPUcSary0vtUzLbSItPMXT7VCfy0yEBNSHWZ3Zodz8+b 1k1Nu4W9FsN9WL9E2ZdMOo8V2ffrTUY7VRFLMmkCVbgcR/S1WGHlvSAbx/NVVfA9wZT8QVX7 WxEZP1NxP7wMKe7FVU6t1ETr3wFeWn89IoRiz10Z1L2rJnV1YCKkwNX8NPrySkFyvwJuvwhW 4A6SM/9dX/zLtyiBpxKGFlJV2VaVQHHUGRUeX5C9zA52IdWcTck8WNec4CMc2km91PulKCWU paxFV1Qi1nA9FhQuRPol19mLyY7l2BscXwKsQpGi1YU6YCys4Ybt2O97mdf/1FYmtigVtlbb pDpDtdqW+6rnFV5+Sk88hUPLTEq46dZiXKINFtR6nEM6Jk9NxdNFxDKQTWMB/Eimmk48vlOn DOBwe89ifdOZrdf8NZzAEtLW2RDUtdvhsWQu7V3ZYUYjdqxMrttQRh8iEOVSNuVTRmX00cbN LbvA1UZQZmXVsboydjm8PWLSRVV4NOLMjWQIfTm007nKdRI5TNVPvbSt9NmT8WRW7MtdTlwD gWUqHdLqW9En9UT5lT4htuEj1bpLrDS2gxRJ+dP1BV40dDsLvjxDQtSrVVTdzeP0kl4/eTyu GknxAtPXBSN8FtM15UN7PCsytUPPQ1q3o+eJ5F28/ww8MMM/TCPL1RLnPIUuEutUHGzJksXf 6yNZFUPibkOxB4bC/22VI0s+JfbYKWVNoj1CLa5MFzTOfhTfXRKzN3QVGIvK3X3f28ropDK0 /p0mUiriS3pXzNrftXyrXs1m70PLaLPgrQVhgtFgtZyzwSOzbJWzppQ12QMbxuBfrX7kqIxp rpy26PpJzF3VGx7Ang6Xn97AoMbKupzf5fxME/a9fWXZtrxqkV3Zn+Wnru5XgSVazYzr7+U0 ecqvqR5h7Ww+ss5ps2bXIW5frcvUFqak4PQ18wXjPJTgE8ZeV2NYzj5p3rToUxvYAnzBR1PH OuRPC/rX8825dcPBQE5Ebv/NKjc80shOL6sdt9skT0GE2b9Qxz0UZPfMz86Lz8NIVwEkN7zJ WTcs5IJmZ53l6H4mPeDssx1FI80rWtQhzs/Bl2h+5lR2HhhZ25+LZQUdb/BG7/RW7/Vm7/Z2 7/fOKSWF5HzlTFwub6jLxb39bhT85QVxxPMmXHFFoNnqUfr2Wpeb5CSNUkeNbyOFxmH87xAq 8LS1RgW3XGlmcLLzWgt3cAFv8Alf3N2KcGF+cApfRQ4/XQyXcBIZVHneoqMFSDHEY+xS0zep 2ibT4zaBvKR1vKHScd+lWqm92dMLZ9FrZ/ZKaDQ12nV+3TO2DMYTWugW7jB9LzSVqBl3K2Le abX/GV5lDmt72+wnNpdydWz2nRgrvlXtxeKidOHwVTL3zViUNtjGDGIZpFSitEIZ/XIxT7KK /cAs1nA7QakaC20YxGoDRmoqRPT68+DuHMwbLkKzOiQyF+6XBmAQhjIYTmTa8Fl7CcALRvQo JmDD1NWjrq0r/Khm9WFDFxg3ZygWmhYny0nGHlmf5Ov6zeuVJsG35GB1VT7/23UK7r5ZS2n/ C4y2tj0Ax+nDbFe7XnWKJTVab8Iq9PPhROIXHlmKzmG4Ll8cth9bB23K1HVhH6GyKfZkN9z7 CuOTgaPYqFZCxCLpxms65IoQeGre5syqYkhJ321zMzhjVWdEdmQ1Bqd+/0/u3p3ahpxtdftj blNu7tTmxLvymJRDaZ08qO1k+JYS744eXtZ43lF2Uuy5jyf5kjf5k0f5lIdvJLLv/NbvKkXR FnV5WdTUEMfS0WVHvaX5Il1wDtLfAJfSaW55/sYfXmRSWyXGETcZvCXmUS1Hp+SNIAD6A536 Sbb5mb96mTf6x0X6GdTlpb9SbNbJVTZx7mYr11VywOpt6UQ93NZnYaRykITogwbIQYYjMlRy jKTTGwdoeaf7e15ync6j2r57e7xdfM9lU5VpsSzVtb9KKYf7O1xk2O16CjbtRefhdI+tZ39V zy6kJobMWStVzg9haSdKK8b2jt5m8l3zs+afyP5c/Bfb5u6t7CkU/dgz8F+WXyey9DIv1nBq 93xvfagm5Obc2mtdbDijc5de1rze6kYOJb5J4GU1stofMw2W6h70UHIC61/Kfm2mDf8qbfrD /shXut0nLc6K9TwrP1fPbIwCwh2EdTavLNIf7CFs16WZAWjxTtrssd4EiAAABgocaLAgAIQH FyZk2FChwYgSEQqs2JAgxoIaMU5kSDFiAIgXL4os6dDhxownOY5EKfElzJgyQXp0OdIiS5Ym OX6keZOnTYg7SdbMqfPoT6JIP/ZU2NPnQ6BSn7aUWjWp0qtPU2YVurRo1aFOoXJdGRRqUqpf c3rteJIqxbJawbYlu/6268umaPUaxTrzL2CQIW3eHEzQcELEc3UiDhm38UGNjnkqFmx462S3 hZ1mjos1c+LLEytHTsn19GXSePPi3BxzMGbOqWWfLi1Z5OG6uc3izl1WKOS+oR+PRWtbc/HE RsUeDw3TsWzLhC3/Hr31OejA2rdz5967+1Xw4seTL2/+PPr06ter/26W/V/38OfTlym/Pv76 97fvz+//P4ABCjhgXjNlR2B/BCoYn2oLOvgghBFKOCGFFVp4IYYZarghhx16+CGIIYo4Iokl mngiiimquKKDCa7nYnpy8fdffzC+Bp+N4CU3I47myUhjgSXul2N5RHpoZJHjGYlkeD3a9/5e kMh1dx+TgTUFHWyeCecjj5opONSFuKnFooZVikfkklz6596Yz7m55ZPxrbkSZ5FBmaR2Yj4I poV6wkkmhJ2VJl1Gdd1G26CF7gbdbr5RR5lijFp3HWvRJSrpo5g6N1ym2R3YF2iaShrbQrPJ OJZFOzqq6KarkqqpUqKqZlqiaTVH02y3VnQboa2O6ulksupVGaa7NsppqEsF2+CETCHl06x0 3SUZnW/yFau0UqoU5U7OgjqdVXZZxSe02Y5J7V1vRaVqWpReW5uftfk11bTjsnYWZfjq+6O7 RUWbb7302vtnoG5h2Vxv7yorqJ1vMbyavOe6JGaxDz9LGHHCuf4Lq1YPR4ySxdeqm9ViJCts q3ECk8RxqhD7yxt1H9uGrm8ya7sywwmDNZy82A7cpIRtMdfkySKD2rPNtP6McXhDG8qtuW+i fKO4RUet78jVaZtc0stZm26BLU+tdMkla32v2RpjHW7VKfc79p0Remu11F1PXW7AfJ0s7pZ0 R/Vt3nVna5zfdnMNuNcwh1v4UfEGfDPdEu/LVrVwNz05yW1j7vNqQAct2rGcAj0qyI0FF7qp z5L+2aewfges6T0Lxrrp95Jaaeqir6r76rp6+TTudEYaKvFavsyYzmwND7ruwme8XOy9YmZ7 6Ts/Cj2lXXkcN6DdE5yy9zGyh6bU4f7PyaKZ5qt/3qdxrs8+s3h6R/X7+gG2A4jp178///37 /z8AAyjAARKwgAY8IAITqMAFMlCBqbESgMhVvu8F6EcVqhGH4ien8SlJf32ajwfbE8KCUXBA EowS9wRkQfqZj01KOlMKdQRDBCVLWR4xnppuRqERyi2GJkSh+3wIJM8B0XsunOGUhNil+f1w cDR7Yvr8RMQvpagzWMqVog51Pevcqnm781UXa8WxY90OjK5xVeui56ji7aqMHotdwrKERUaV EY1MQZSwXqPGM4ZOdMnCYqsCWUSVtAYnGxEbWWaVuzXCTo9IWyQXvRiivV3pap6zm+Y4d0TJ /eQ6egsc1P4oqTq2CW1wlTPY2vhGM1VeDE5kW+HGJmY9+5gEkYYk5GKGpLbHyZKUisvciCjZ O5dpbHvzspzsEMYbURFudYeyGeGcOMqVzc6SJdlR7yopOLYxjWdoU6Y3lbNNk01qlQzC1d+I orRuvc5i3TyYl9rFt1SKSJS/4yUo04YyTiaTaNFEpT6l+DikKa+amBzNNLMnTlb6E2zYWUsc oba4eDYMgrgclsocJlEpGi2ecOlnR+spzYlaLpMgvRo/W/mZlX4SmYKz59sqd1CAllQ3CaXf 3oLU0rBIlJzb4iniWgKXhtkUqJlkaErVclJuBvN0lhKq6tqXzTDSrnQUY95VMf62R9RkjzTF eye+voo8cAVykbmTqvRoWdVKXe8xtdrL6ci4x6YdaKiHSRy0GlQx6o0VO89joyOVWEAeNrCw hj3sEhHLHw0qtrGOfSwTISvZyVK2spa9LGYzq9nNcraznv0s/0KYIB52a5CRTSwSxfeiJL5w iqvND4wIC5gVDhI2QSxhay1K2/7lSLZ5AqL+bPS6377WouhpE3GHGEHj+tZAMqToBF1LHuHi dn29JeE/j/vc6LJQu8lln2DBR5/mQrenTTwtBU+oWiaS94J2TBWvwHlGLVK1rIB9SLDE2Mhv AdKtflzeNSEDSD9W71fs9OqyludIrrZ1v4vKr1yz+v/FMVpRjk81VqeeSuAIO6+QThUrLZ/3 RYGRrX5Ji2nXZkpTmTGOphXtKEGPqU2X2gu5nQMrS1rgUMNZT2G6LOnmIsZRay4NmJGb5QZz SmKmtpCXLS5lkV2FUiJL+XfZfKMxj/pk5CQvpZDyKl2MWbTDhaWdWFUpTIeJ1Kka2Z3tytkN rSRmmImtxBsygndzumW83Tifr/RzUEsbZS+T2W/Q0+kvQxpWKn/UoQvFHKFTmby7QXRrG0V0 Qd2n4patk7dOZnSp8EljTQK6bDuNcaQhLS1yLRXIlR6Ykg/qNFMO1NErpbG3jDxlvM46yrfe LaAeWWZE7Q7OyLuqiK/Mx9j+nCqSm9ES7AKsVADrqnZoPaZy6tjWap+Zw3byb/s2/Gy/zs6N OK2efO87NDP+l13iFjFSqwta8TpQse2dN2vx3aFwL/DeQmKsvlUY8IETvOAGPzjCE67whTO8 4Q5/uI+6fF7T7hu80kXyeHV72ykVVUUU2xCTgK3vTSoXfcXtLsXp7STnljfl/t5gDuP28o3T fOaFJfn5yORB+fDcuDnfOAZpTkWLq9zm3EX5xQ8LYgxXuJAqk/CmjHVH2/Ku2IoUcHwblcdB 0TGqccSqhfGLM09WuFRZv+G//tp0tnqxjWe/VE1s29+1O1tYwKE6fvF+yLcXW5zR9nrbv5xW wf//T6l3rTVeBNpJFIOt1U/sMZFbrDlD7VmerkQzrJEc0n72kpqHHzXVlPzroCjUhqXONd4q b3Tsyjecb0N9RY066rPBU8txJr07PTmzSz/arpL/jcQBx2Per3jS6aINNLc96CArr3U7q/wu hTxneXvc0ok+XjrRphvVF/35GqW0UXN9RJPJbvjgB7OMM8/UzR/ao96//uXUr8/OnW2bhbZk 9HdMaxOHmqT093/o9d/p8RrxzYv5Od3IBNSK8Rkm8Qum5VI+HdUsMYfIIAQOGJqqIQ5MzdPx gdpPpZ4HYlv4qFvdKZ+72Zdc7BWLgdgW3Z1+KZh+QVWvTAqklFteUdvh/9VQHy3fuLEO28Vf tukVHFHO4BVG8NAOmOyVuO1g1c1gxWwVlNWRgZ2gZq2e/EyXwVnhY2lhexwcF+YWFgYcv0Fc eGHIF5IhGqahGq4hG7ahG74hHMahHM4hHdahHd4hHuahHu4hH/ahH/4hIAaiIA4iIRaiIR4i IiaiIi4iIzaiIz4iJEaiJE4iJVZi/6iAJWaiJm5iJEJAAnxiAkAATIAiKTJABjTAKJLiJ5oi KmqHAyAAA4CiBizAARhELH5iRAgAKIqiLa6iQaiiAvwiKEZEKUqEBpDiX6iiLLaiMOLiQOgi KCJAKiqjMkaEAizAAIDiACxAMP7FMX6iBkTEN/8mQDgaxDVm4yduYzcS4zA2YwKwozIyAAKs o0xQYwLIIz1GhCfu4jSW4inOxD5+Ii9KhD3iI2AAozu+xDlqIzdKxC2+o0FAYyhGxC0yQEL6 4UPeYz8q4wM4AEHaYwJ0JGAsAEgaBAKAIgUYRAbIojlGoztO5EAg40vW4kAogComI0gOADxC JAWQok5uZEkORAOAJDPGhAOQokcCwFGipEEMpT0WJQDIZEy241Ta4wOk5EyAZEhipUMW40to pUjCREZa5FeC5FXiJD9WJUQ2JVFGxEl+IleuJDi25CdKo1r64VIiZVlqZVKqpT32JUxIJDWy 5Scy4wNI5QGAIjOq4gP/XKRfZoBBkKRUxoRWwmRUtuNDPkA+vmRQOmVbzsRbkuNAjKNdAoBn PuVOpiZnqmI51qNWtqZB5CUoAqZfUiNtKqUy3mZlwuZGNuZdEuZnmqZiGsRhUmViFiZxfqJv 8mFouuRHOqNpZqZqRicoLqdYgqIAxOYCkCUA2GRdDkRP6iUASGYCrKMy8uJkKmM3FidVUmY7 KkBocicyNudtuid00uUnZkAwKoBcfuJmWiNSymY3emd+7md/lqdjXuZ9SqVgouVaNqhENOd3 PudaNoB0RqgylqZjQqhrkiJ6UiWBJoB+dueBDqhzhudsDgR5ruM38mYeFucDwOheruVAoGMC /2TnbxqEjeJoP/4FOv6kYMLkN/5kbfpmeqqiKJ7mffaoY5LiafLoQbanirKkOILiAvxFaGpA fw4kefLmOF5pjioojR7pks7odCZnSMoohUrEjkoEjKrpmU4mUBopVXapMVqpjqbjMyLpaOqp QbRoH3omAoQmVMrpcYpmmALAoboomoYkAjTAf5LnQMglOpYjnrrjW4oimYqoRq7kgTrodJIi e2polJapjdKkQRwqkcaEArBndUbEqUqEqibopkYmKEJmVtbprUqEoBLqmkbEokZErw7ndJIn rnZoAmSqmObpJ6LqQMzqlDojpc6lgoJpnyLqHp4qtCZojsrpssaEhP+u4kA+a4oW56HiZrPu pHc25qY6JTSeJqh2Z2geKzWuamB4q7d+K0Ce55k2aXtuqm06aMDCKigewLYmqr4CgLZqI4UO LLKuq77mK2KWa7MOY146K6DuIYH6JnvSI75S5ceWKcFSIwN4rECGp0UWpwNI5Jpmaq0eJswm LFCqYl+SbHeELI1ya0y4KncibMT+K9CSbH02bCnS5sYORMf2q74eLQAk7Wqu4tCmpsuCrJSG 6S6ibNN+4spKacbqIXmCaWhaq8z+bJnmq7DaKCkeq8LmJzRKo1xCAKWu6VK6qtS6pNk+LXI+ rdiWas6Ord++REAmQKFWLdmOadAqI5Qiqyr/Ju54XmrYKq1Ufu1APC7eMm6Pzq1USmx7omMG tC0AvG3cuuWE6mFGxmO/Bmuioi5gOAAEZGRESKYpIqdTasAt7q1MjuPhAgCKpuTd1mZIZgBt pq143mvVxiqwMizxmmrByiryJmytkudZgir0cuVAlK4q9qyhUikAWK9X3uX08u21SqXxpmrz Nu49yiUqzm7tSsQ+jusdHipIoqqctmmi0i9MDAD1humhFud+KufyqqZsLihmauTf6uya2mjP xuvram/47i2yvoSdVuknWit7YiXT/uZD2iuTZvDxVqb8Sin9wq89frAzcnC8BvBaRvCfXiq5 +i+Cruv/CmK4Zqhj/x4AAk+nDYNiAn8kAqCqRNrr9fYizq5wrZqpv4psaqJosmqHt4boiPIn Kf4nkwLorRpoFKvkrn5uFv+mbLqvEXexSVbmEudoDvvi5IpxacokGOcqdOLuWjqxFYNiPgZx 9d4kIV6xQSgx3ion9VZm9NrnCLMpKZZmc2qwVCqp0jov1SLxRQausz7wSyipMkIlG/etcGpl UaLw8OoreSZA1HKyeOIxeGYuWHKlKOsuKUNnJ3/yIduxUFYmJaMtIfukEePhD78E/WolA+Sv LufvS7iqKlKyIwOnZSao6xpwERdwjtqodUJyJAdn8lryJVOjMNuj+07mQ+7wmWYzANyyIP9/ Io72ckSWb41iZ5hyszNvr5xKMrGyLymi6ml6ce/Cof2Os5+S7D/OqA7nM2A0QAZkcEO+hGxS qG62J7wic+767HQqsdoCskwsZDoG9HbcLUQngDoa5T+vIvDWMrrmZzrLZgbU857eczzyczmD 80t482SCdDoftDViI0NK8UDvZEEzMifeNE7ntE7vNE/3tE//NFAHtVAPNVEXtVEfNVIntVIv NVM3tVM/NVQ/iAlENVVXtVVfNVZntVZvNVd3tVd/NRzmAFiPNVmXtVmfNVqntVqvNVu3tVu/ NVzHtVzPNV3XtV3ftYkAAV7vNV/39VsfgV8H9gFNgGAXtmEfNmL/J7ZiLzZjN7ZjPzZkR7Zk TzZlL+KPER3/lMBflIBmi0hne9p3pdyEfDZMkDaEmPZ2oLZEcPaRjNFywZwk3R3X1J7dLRj6 jRj1kYdqlzZnm/ZuA8Zva0dwX8hwlxMYdk9xB0hyg8dyB43K4QeVJKCnMNQ9ySDLvVgzKTdw kzZrD0Rzr7Z5fHeEfDcVXrf3iDd+oHdgqPeCzPYQ/p3Xld7l7QV9A6FP3VZr3NPX3ZFMdLZm 97Z3AzgA9DZ3B/h/G3h3E7hB/HeCK/hnP/iCC/iAe/eCR3h3G7iFQzhrM7hqc3hEKPiAgzhs a48aJRsjEZvY0WChlHeIZ3iFS7iHUziM/1c4gr/4hYc4jF+4iH+4jDe4j7M3bPHZ/8lgm3De cNU3EdK2kPccxrHf7fV3gNM4hEs5hU+4lRe4lE85llv5lfN4l1c5lmu4l+v4lH+4lo85etlZ J33N6D15fTsVcFc5mGs5nVO5nI/5mdv5hG95lus5nzdLsTDg+2WfkEeX8yVg/Lk3k7eSDgoU sPk3mt85pH/5pEu6pXO5jO85jYP5i2/6l3t6pWM6aod5pIe2mnfcn5GU8dVfnIv6pZP6ph94 ab96qV96rVf6nzu3UMFTTK357hHRkSO6uxGH1jDTzKDfFW3f94Q6rkf6pDM7gTP7nWu6rOO4 gIs5gic4eOu5q/9v+5yDOHkXn+HVzM88kwUVB4tvO6xzOrdje7bTOrd3+63Lea73kEq1eeNk zYhnl3Xb96BTnPHtEpPNO5fD+rPbupeze6dXe4d3+rRP+7rLO6g/PKbPlov5EpHflGmh+3Or O8FHvLuDPLxPvMf7ecLv0JJrPBEm+XtgU3WzPPzN9ziVjb5v9shvuX+LOJ9Le8UX/Mnz/M13 +863+8gXEZkJerGrPDDB/L2XvMJ/OtQPPdEXfLPj/NM3u6c3i8E0ulV5FJuhkN3BG4oLkmtf 0haJV6DbvNCb+Y3f+Etc+4zHuo5nvc6fvLWzvYtL+o4D/d67fcdMd/NgGeh0lQ4eoXVW38eD x/3VI7xvg3vCA3jiR77B37qET9bOTdaOrw+QY9bmC3cjRpH/RLvojz7pl77pnz7qp77qrz7r t/7oI5brx77szz7tk35l3z7u577u7z7v974bBgQAOw== ------=_NextPart_000_000E_01C64F9B.05F6E6B0-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 24 22:21:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMzLI-0001g6-7b for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:21:32 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMzLG-0000qW-P8 for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:21:32 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C93E143010A for ; Fri, 24 Mar 2006 19:21:29 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E7B4C430082 for ; Fri, 24 Mar 2006 19:21:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D061139803F for ; Fri, 24 Mar 2006 19:21:16 -0800 (PST) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4B068398048 for ; Fri, 24 Mar 2006 19:21:14 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Mar 2006 19:21:13 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 25 Mar 2006 03:21:09 GMT X-Originating-IP: [72.254.172.55] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Fri, 24 Mar 2006 19:21:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Mar 2006 03:21:13.0494 (UTC) FILETIME=[2B8F7B60:01C64FBB] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Re: EAP-POTP expert review (?) X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Magnus -- To be clear, you are not asking for an EAP Type-Code allocation, correct? If not, then you do not need an RFC 3748-style review of your specification. Is it your intent to request publication of EAP-POTP as an Informational RFC via the individual submission or AD-sponsored route? My understanding is that for the case of unsponsored individual submissions, determination of the expert is now handled by the RFC Editor, not the IETF. So even if the EAP WG were to review your method, you'd still have to deal with the RFC Editor review in addition. We are quite willing to find a volunteer reviewer, but before doing that we want to make sure that this will help you achieve your goal. ---------- Forwarded message ---------- Date: Fri, 24 Mar 2006 17:53:06 +0100 (W. Europe Standard Time) From: Magnus Nyström To: eap@frascone.com Cc: aboba@internaut.com Subject: EAP-POTP expert review (?) Dear All, With this email, I would like to ask for assistance in finding an expert to review draft-nystrom-eap-potp-04 (available at: http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-04.txt) prior to asking for its publication as an informational RFC. The document describes a framework for use of OTP methods in EAP, and contains a profile of the framework for the RSA SecurID OTP algorithm. Further profiles for other OTP algorithms are expected. Since the framework does not need an EAP method type identifier of its own, and the RSA SecurID profile already has an EAP method type identifier, a Designated Expert review is not strictly necessary, but such a review would still be valuable. Thanks, -- Magnus _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 24 22:23:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMzNW-00039w-5L for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:23:50 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMzNU-0000uv-RP for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:23:50 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 845C54300C5 for ; Fri, 24 Mar 2006 19:23:48 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D515D430082 for ; Fri, 24 Mar 2006 19:23:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C742039804F for ; Fri, 24 Mar 2006 19:23:35 -0800 (PST) Received: from hotmail.com (bay106-f11.bay106.hotmail.com [65.54.161.21]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4DCDD398048 for ; Fri, 24 Mar 2006 19:23:33 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Mar 2006 19:23:32 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 25 Mar 2006 03:23:29 GMT X-Originating-IP: [72.254.172.55] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Fri, 24 Mar 2006 19:23:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Mar 2006 03:23:32.0749 (UTC) FILETIME=[7E901BD0:01C64FBB] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Volunteers for Expert Review of EAP-SAKE? X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad We have a received a request for an RFC 3748 Type Code Review of the EAP SAKE specification. The specification is available here: http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-00.txt If you would like to volunteer as the Expert Reviewer, please send me a note. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 24 22:46:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMzjg-00042N-HE for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:46:44 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMzjf-0001gP-3C for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:46:44 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BCD13430111 for ; Fri, 24 Mar 2006 19:46:42 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F1C52430082 for ; Fri, 24 Mar 2006 19:46:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D497C80C0FD for ; Fri, 24 Mar 2006 19:46:28 -0800 (PST) Received: from hotmail.com (bay106-f24.bay106.hotmail.com [65.54.161.34]) by hermes.tigertech.net (Postfix) with ESMTP id 3016680C0EB for ; Fri, 24 Mar 2006 19:46:27 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Mar 2006 19:46:26 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 25 Mar 2006 03:46:25 GMT X-Originating-IP: [72.254.172.55] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501BF82AA@xmb-sjc-215.amer.cisco.com> From: "Bernard Aboba" To: gwz@cisco.com, eap@frascone.com Subject: RE: [eap] Volunteers for Expert Review of EAP-SAKE? Date: Fri, 24 Mar 2006 19:46:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Mar 2006 03:46:26.0570 (UTC) FILETIME=[B16C8EA0:01C64FBE] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Here is what RFC 3748 says: For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. So the Designated expert is appointed by the AD (typically based on a list of potential recruits). The Expert then posts the decision to the EAP WG (or designated successor). >From: "Glen Zorn (gwz)" >To: "Bernard Aboba" , >Subject: RE: [eap] Volunteers for Expert Review of EAP-SAKE? >Date: Fri, 24 Mar 2006 19:41:23 -0800 > >Bernard Aboba supposedly scribbled: > > > We have a received a request for an RFC 3748 Type Code Review of the > > EAP SAKE specification. The specification is available here: > > http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-00.txt > > > > If you would like to volunteer as the Expert Reviewer, please send me > > a note. > >Just out of curiosity, shouldn't this really have gone to emu? > >Hope this helps, > >~gwz > >Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Mar 24 22:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMznW-0007T9-EC for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:50:42 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMznV-0001pP-0f for eap-archive@lists.ietf.org; Fri, 24 Mar 2006 22:50:42 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADE37430119 for ; Fri, 24 Mar 2006 19:50:40 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3B594430082 for ; Fri, 24 Mar 2006 19:50:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 26EBB80C0EF for ; Fri, 24 Mar 2006 19:50:28 -0800 (PST) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 4A4C980C005 for ; Fri, 24 Mar 2006 19:50:26 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 24 Mar 2006 19:41:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2P3fPGv007825; Fri, 24 Mar 2006 19:41:25 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 19:41:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Volunteers for Expert Review of EAP-SAKE? Date: Fri, 24 Mar 2006 19:41:23 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501BF82AA@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Volunteers for Expert Review of EAP-SAKE? Thread-Index: AcZPu4y125X/znOEQgKPXGs+TqFszQAAk4Og From: "Glen Zorn (gwz)" To: "Bernard Aboba" , X-OriginalArrivalTime: 25 Mar 2006 03:41:25.0333 (UTC) FILETIME=[FDDF7050:01C64FBD] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Bernard Aboba supposedly scribbled: > We have a received a request for an RFC 3748 Type Code Review of the > EAP SAKE specification. The specification is available here: > http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-00.txt=20 >=20 > If you would like to volunteer as the Expert Reviewer, please send me > a note.=20 Just out of curiosity, shouldn't this really have gone to emu? Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From sbabw@midshipman.com Sat Mar 25 03:52:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN4Vy-0000l3-Gn for eap-archive@ietf.org; Sat, 25 Mar 2006 03:52:54 -0500 Received: from flh1ahq213.tky.mesh.ad.jp ([125.192.108.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FN4Vx-0004lm-0C; Sat, 25 Mar 2006 03:52:54 -0500 Received: from unknown (HELO chert.www4.hsu8.com) (192.168.0.9) by host15-68.www4.hsu8.com with SMTP; Sat, 25 Mar 2006 09:53:02 +0100 Message-ID: <648x152c.7207355@www4.hsu8.com> Date: Sat, 25 Mar 2006 09:53:02 +0100 From: "Carmelo Bennett" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-PGP-Key: Erf5VC4OsRWmppU6N3oZM8nWA9KvsXbkl3RJfUIDgDUK7EDsIF9H4YNrUMS12RqB== X-Firewall-Bypass: NO MIME-Version: 1.0 X-Scanned-by: Norton 4 To: eap-archive@ietf.org, edmund.rivera@ietf.org Subject: Extending Refinances made easy X-Antivirus: avast! (VPS 0612-3, 2006/03/24), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Thanks to a nomination by an associate of yours, there are potentially three deals that will be offerêd to you. Notice - past credit history is NOT a factor for this promotion as long as you still have own a home and we recieve word from you within 24 hours. ________Detail Summary___________ Rate: As low as 3% Ammount: Up to 800,000 Type: Rêfinancê or Homê Equity Closing Date: 30 days In accordance with our terms please visit here to verify your information on our secure, private site to ensure our records are accurate. http://www4.hsu8.com/was.asp Della Mullen For Deletion http://www4.hsu8.com/rem.asp From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Mar 25 13:09:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNDCT-0006s9-O8 for eap-archive@lists.ietf.org; Sat, 25 Mar 2006 13:09:21 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNDCS-0001XX-7P for eap-archive@lists.ietf.org; Sat, 25 Mar 2006 13:09:21 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9EC10430126 for ; Sat, 25 Mar 2006 10:09:19 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 790B0430059 for ; Sat, 25 Mar 2006 10:09:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6636B80C122 for ; Sat, 25 Mar 2006 10:09:05 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 376C980C12B for ; Sat, 25 Mar 2006 10:09:03 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2006 10:09:04 -0800 X-IronPort-AV: i="4.03,128,1141632000"; d="scan'208"; a="1788307364:sNHT31785644" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2PI927T015560; Sat, 25 Mar 2006 10:09:02 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Mar 2006 10:09:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Volunteers for Expert Review of EAP-SAKE? Date: Sat, 25 Mar 2006 10:08:42 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501BF8300@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Volunteers for Expert Review of EAP-SAKE? Thread-Index: AcZPvrLpUM/VhAdBSpqszyqK2xmJwAAd33fA From: "Glen Zorn (gwz)" To: "Bernard Aboba" X-OriginalArrivalTime: 25 Mar 2006 18:09:02.0132 (UTC) FILETIME=[32249740:01C65037] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Bernard Aboba supposedly scribbled: > Here is what RFC 3748 says: >=20 > For registration requests where a Designated Expert should be > consulted, the responsible IESG area director should appoint the > Designated Expert. The intention is that any allocation will be > accompanied by a published RFC. But in order to allow for the > allocation of values prior to the RFC being approved for > publication, the Designated Expert can approve allocations once it > seems clear that an RFC will be published. The Designated expert > will post a request to the EAP WG mailing list (or a successor > designated by the Area Director) for comment and review, including > an Internet-Draft.=20 The last sentence is the one of which I was thinking: since the Dallas = meeting was purportedly the last one for the EAP WG, it seems as if this = would be an opportune moment to designate a successor (unless "last = meeting" has semantics similar to those of "WG Last Call" ;-). > Before a period of 30 days has passed, the > Designated Expert will either approve or deny the registration > request and publish a notice of the decision to the EAP WG mailing > list or its successor, as well as informing IANA. A denial notice > must be justified by an explanation, and in the cases where it is > possible, concrete suggestions on how the request can be modified > so as to become acceptable should be provided. >=20 > So the Designated expert is appointed by the AD (typically based on a > list of potential recruits). The Expert then posts the decision to > the EAP WG (or designated successor). =20 >=20 >=20 >> From: "Glen Zorn (gwz)" >> To: "Bernard Aboba" , >> Subject: RE: [eap] Volunteers for Expert Review of EAP-SAKE? >> Date: Fri, 24 Mar 2006 19:41:23 -0800 >>=20 >> Bernard Aboba supposedly >> scribbled:=20 >>=20 >>> We have a received a request for an RFC 3748 Type Code Review of the >>> EAP SAKE specification. The specification is available here: >>> http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-00.txt >>>=20 >>> If you would like to volunteer as the Expert Reviewer, please send >>> me a note. >>=20 >> Just out of curiosity, shouldn't this really have gone to emu? >>=20 >> Hope this helps, >>=20 >> ~gwz >>=20 >> Why is it that most of the world's problems can't be solved by simply >> listening to John Coltrane? -- Henry Gabriel Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From xuqcuqtrm@prosaic.com Sun Mar 26 21:06:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNh7m-0007ZQ-7u for eap-archive@ietf.org; Sun, 26 Mar 2006 21:06:30 -0500 Received: from [220.75.152.10] (helo=156.154.16.150) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FNh7h-0003oA-L3; Sun, 26 Mar 2006 21:06:30 -0500 Received: from unknown (HELO undulate.www4.p0si.net) (192.168.0.4) by host16-28.www4.p0si.net with SMTP; Mon, 27 Mar 2006 04:06:31 +0100 Message-ID: <965w983p.2052912@www4.p0si.net> Date: Mon, 27 Mar 2006 04:06:31 +0100 From: "Vicente Rhoades" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-PGP-Key: Wl3APcTPNEUKC7QfgzTnfoeBqdubMVycZfKBTbPsuDIErWX87GajO9APS23W7Aft== X-Firewall-Bypass: NO MIME-Version: 1.0 X-Scanned-by: Norton 6 To: eap-archive@ietf.org, edmund.rivera@ietf.org Subject: Top Notch Refinances with ease X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a x Client Update: Several Companies have been competing for your m0rtgage refinance application over the past 2 weeks. The company that offered the lowest rate, and largest loan quantity has requested your information be verified. http://www4.p0si.net/was.asp Thank you, Adela Camacho, Accounting oDatabase Deletion: http://www4.p0si.net/rem.asp From angellaam@1-shops.com Mon Mar 27 00:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNkMo-0002kJ-8t for eap-archive@ietf.org; Mon, 27 Mar 2006 00:34:14 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNkMo-0003Dm-7X for eap-archive@ietf.org; Mon, 27 Mar 2006 00:34:14 -0500 Received: from igld-80-230-142-229.inter.net.il ([80.230.142.229] helo=nitzan-9elipvn2) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FNkMh-0005Ji-QB for eap-archive@ietf.org; Mon, 27 Mar 2006 00:34:14 -0500 Date: Mon, 27 Mar 2006 5:34:17 -0120 From: "Marcy Simmons" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Marcy Simmons" X-Priority: 3 (Normal) Message-ID: <0360595797.20060327053417@1-shops.com> To: eap-archive@ietf.org Subject: You need to review this MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 There is a Big PR Campaign running ALL Weekend! Get PIFR First Thing Monday, This Is Going To Explode! Check out HOT NEWS!!! PREMIER INFORMATION (PIFR) Current Price: $.60 Up .22 in last 2 days! Already Starting to move! Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. Premier Information Management, Inc. (PIFR), an emerging provider of information management services to the In-surancee and Healthcare industries, announced today that the company is providing information procurement and data migration services to several of the Top Twenty In-surancee Gr0ups, ranked according to the number of individual term life in-surancee policies issued by industry providers in 2004. (NAIC In-surancee Industry Data) "We are pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online i-nsurancee br0ker AccuQuote," said Tom Miller, CEO of Premier Information. "We want to continue to stay focused on growing our core business, refining our operation model, and introducing new integrating technologies that help move our clients to more efficient, cost effective and secure business processes." From blueboy@0733.com Mon Mar 27 11:23:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuVL-0006z4-6Z for eap-archive@ietf.org; Mon, 27 Mar 2006 11:23:43 -0500 Received: from 88-137-77-37.adslgp.cegetel.net ([88.137.77.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuVJ-0005Wt-S0 for eap-archive@ietf.org; Mon, 27 Mar 2006 11:23:43 -0500 Date: Mon, 27 Mar 2006 16:23:46 -0060 From: "Kevin Byers" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Kevin Byers" X-Priority: 3 (Normal) Message-ID: <1878264710.20060327162346@0733.com> To: eap-archive@ietf.org Subject: FWD: Biggestnews shows promise MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 There is a Big PR Campaign running ALL Weekend! Get PIFR First Thing Monday, This Is Going To Explode! Check out HOT NEWS!!! PREMIER INFORMATION (PIFR) Current Price: $.60 Up .22 in last 2 days! Already Starting to move! Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. Premier Information Management, Inc. (PIFR), an emerging provider of information management services to the In-surancee and Healthcare industries, announced today that the company is providing information procurement and data migration services to several of the Top Twenty In-surancee Gr0ups, ranked according to the number of individual term life in-surancee policies issued by industry providers in 2004. (NAIC In-surancee Industry Data) "We are pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online i-nsurancee br0ker AccuQuote," said Tom Miller, CEO of Premier Information. "We want to continue to stay focused on growing our core business, refining our operation model, and introducing new integrating technologies that help move our clients to more efficient, cost effective and secure business processes." From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Mar 27 13:43:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwgM-0004Ze-AU for eap-archive@lists.ietf.org; Mon, 27 Mar 2006 13:43:14 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwgK-0003Jy-G3 for eap-archive@lists.ietf.org; Mon, 27 Mar 2006 13:43:14 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A71AC43012E for ; Mon, 27 Mar 2006 10:43:11 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A570B430071 for ; Mon, 27 Mar 2006 10:42:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8DAE4398049 for ; Mon, 27 Mar 2006 10:42:54 -0800 (PST) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id 942EC39805B for ; Mon, 27 Mar 2006 10:42:52 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Mar 2006 10:42:51 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 27 Mar 2006 18:42:46 GMT X-Originating-IP: [71.36.107.140] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 27 Mar 2006 10:42:46 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Mar 2006 18:42:51.0660 (UTC) FILETIME=[40A97CC0:01C651CE] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 343: Section 1,2 and 5 cleanup X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Issue 343: Section 1,2 and 5 cleanup Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: March 27, 2006 Reference: Document: Keying-10 Comment type: E Priority: S Section: 1, 2, 5 Rationale/Explanation of issue: The flow of Section 1 leaves something to be desired. It launches right into the EAP key hierarchy without any overview, and the security goals of EAP are not discussed until Section 5, which seems somewhat out of place. The proposed resolution is to move the first half of Section 2.1 (up to the examples) and the portion of Section 5 dealing with security goals to Section 1.3. The examples in the second half of Section 2.1 will be moved to section 1.3.1. Section 1.3 (EAP Key Hierarchy) becomes Section 1.4; Section 1.4 (EAP Invariants) becomes Section 1.5. Section 2.2 (Layering) becomes Section 2 (Lower Layer Operation); Section 2.3 (Transient Session Keys) becomes Section 2.1, Section 2.4 (Authenticator Architecture) becomes Section 2.2; Section 2.5 (Key Scope) becomes section 2.3. Section 5.1 will be incorporated in Section 5, rather than being a separate section. Section 5.2 (Threat Model) becomes Section 5.1. The following paragraphs in Section 5.6 relate to authenticator and peer identification, a subject extensively discussed in Section 2.4: " In order to enable key binding and authorization of all parties, it is RECOMMENDED that the parties use a set of identities that are consistent between the conversation phases. RADIUS [RFC2865] and Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator identify itself by including one or more identification attributes within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-IPv6-Address). Since the backend authentication server provides EAP keying material for use by the EAP authenticator as identified by these attributes, where an EAP authenticator may have multiple ports, it is RECOMMENDED for the EAP authenticator to identify itself using NAS identification attributes during the Secure Association Protocol exchange with the EAP peer. This enables the EAP peer to determine whether EAP keying material has been shared between EAP authenticators as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it. Typically, the NAS-Identifier attribute is most convenient for this purpose, since a NAS/authenticator may have multiple IP addresses. Similarly, the backend authentication server authorizes the EAP authenticator to provide access to the EAP peer identified by the Peer-ID, securely verified during the EAP authentication exchange. In order to determine whether EAP keying material has been shared between EAP peers, where the EAP peer has multiple ports it is RECOMMENDED for the EAP peer to identify itself using the Peer-ID during the Secure Association Protocol exchange with the EAP authenticator." To reduce redundancy, it is recommended that these paragraphs be changed to the following: "In order to enable key binding and authorization of all parties, it is RECOMMENDED that the parties use a set of identities that are consistent between the conversation phases. Section 2.2 discusses identification issues that arise where the EAP authenticator and peer may have multiple ports. Consistently identifying the EAP authenticator enables the EAP peer to determine whether EAP keying material has been shared between EAP authenticators as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it. Similarly, the backend authentication server authorizes the EAP authenticator to provide access to the EAP peer identified by the Peer-ID, securely verified during the EAP authentication exchange. In order to determine whether EAP keying material has been shared between EAP peers, where the EAP peer may have multiple ports it is RECOMMENDED for the EAP peer to identify itself using the Peer-ID during the Secure Association Protocol exchange with the EAP authenticator." In Section 5.8, the following sentence contradicts the discussion in Section 2.1. "TSKs are permitted to be accessed only by the EAP peer and authenticator. Since the TSKs can be determined from the transported EAP keying material and the cleartext of the Secure Association Protocol exchange, the backend authentication server will have access to the TSKs" Recommend that it be changed to: "TSKs are permitted to be accessed only by the EAP peer and authenticator (Section 1.3). As discussed in Section 2.1, PPP and 802.11i derive the TSKs from transported EAP keying material; 802.16e utilizes transported EAP keying material for TSK keywrap; IKEv2 utilizes transported EAP keying material only to authenticate the derivation of TSKs. Possession of transported keying material enables the backend authentication server to masquerade as the authenticator, and in some cases to obtain the TSKs (PPP, 802.11i, 802.16e)" Section 1.3 now reads as follows: "1.3. Overview Where EAP key derivation is supported, the conversation 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) Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. Phases 0 and 2 are handled by the lower layer protocol and phase 1b is typically handled by a AAA protocol. In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. 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. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs. 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 1: Conversation Overview The authentication phase (phase 1) may begin once the peer and authenticator discover each other. This phase, if it occurs, always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a EAP keying material is derived on both the peer and the EAP server. An additional step (phase 1b) is required in deployments which include a backend authentication server, in order to transport keying material from the backend authentication server to the authenticator. In order to obey the principle of Mode Independence, where a backend server is present, all keying material which is required by the lower layer needs to be transported from the EAP server to the authenticator. Since existing TSK derivation techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b. 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). The Secure Association exchange (phase 2) 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 between the parties is shown in Figure 1. The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server). Authorization issues are discussed in Sections 5.8. Completion of an EAP method exchange (Phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) and server (identified by the Server-ID). Both the EAP peer and EAP server know the exported keying material to be fresh. Disclosure issues are discussed in Section 5.5; key freshness is discussed in Sections 3.3, 3.4 and 5.7. Completion of the AAA exchange (Phase 1b) results in the transport of EAP keying material from the EAP server (identified by the Server-ID) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Security properties of AAA protocols are discussed in Sections 5.2-5.8, and 5.11. Completion of the Secure Association Protocol (Phase 2) results in the derivation of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-ID) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Security properties of Secure Association Protocols are discussed in Section 3.1." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From andyfu@0733.com Mon Mar 27 23:07:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5Ub-0008UU-FB for eap-archive@ietf.org; Mon, 27 Mar 2006 23:07:41 -0500 Received: from [125.129.145.118] (helo=[125.129.145.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5Ua-0004gP-2F for eap-archive@ietf.org; Mon, 27 Mar 2006 23:07:41 -0500 Date: Two, 28 Mar 2006 4: 7:38 -0540 From: "Lelia Cole" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Lelia Cole" X-Priority: 3 (Normal) Message-ID: <9588127033.20060328040738@0733.com> To: eap-archive@ietf.org Subject: FWD: St0kkMarrkett Picks Trade daily news MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a There is a Big PR Campaign running ALL Weekend! Get PIFR First Thing Monday, This Is Going To Explode! Check out HOT NEWS!!! PREMIER INFORMATION (PIFR) Current Price: $.60 Up .22 in last 2 days! Up .10 more Today Already Starting to move! Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. From ant@0733.com Mon Mar 27 23:08:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5VK-00006c-O7 for eap-archive@ietf.org; Mon, 27 Mar 2006 23:08:26 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5VK-0004rj-MI for eap-archive@ietf.org; Mon, 27 Mar 2006 23:08:26 -0500 Received: from [59.95.203.60] (helo=[59.95.211.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FO5VJ-0007SI-FY for eap-archive@ietf.org; Mon, 27 Mar 2006 23:08:26 -0500 Date: Two, 28 Mar 2006 4:10: 7 -0330 From: "Paulette Houston" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Paulette Houston" X-Priority: 3 (Normal) Message-ID: <8114941382.20060328041007@0733.com> To: eap-archive@ietf.org Subject: RE: You have to heard this MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a There is a Big PR Campaign running ALL Weekend! Get PIFR First Thing Monday, This Is Going To Explode! Check out HOT NEWS!!! PREMIER INFORMATION (PIFR) Current Price: $.60 Up .22 in last 2 days! Up .10 more Today Already Starting to move! Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started today. We are already seeing movement it will go all week so it would be best to get in NOW PREMIER INFORMATION (PIFR) Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. This is a Must Watch.. PREMIER INFORMATION (PIFR) A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 13:08:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIc3-0001XI-EF for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:08:15 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIc2-0006y6-2N for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:08:15 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B9D00430194 for ; Tue, 28 Mar 2006 10:08:13 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 472A9430054 for ; Tue, 28 Mar 2006 10:08:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3B98A39805A for ; Tue, 28 Mar 2006 10:08:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 92ED739802D for ; Tue, 28 Mar 2006 10:08:00 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5F9F48982D; Tue, 28 Mar 2006 21:07:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7FE6489805; Tue, 28 Mar 2006 21:07:56 +0300 (EEST) Message-ID: <44297B63.8060101@piuha.net> Date: Tue, 28 Mar 2006 10:07:31 -0800 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Issue 341: Editorial NITs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Bernard Aboba wrote: > > Appendix A does not include references to each of the EAP methods that > are described. These should be added to Appendix A as well as the > reference list. Ok. > The IANA Considerations section is null; nowadays the RFC Editor deletes > these empty sections, so might as well remove it entirely now. It isn't necessarily a bad idea to have a section that says there are no IANA considerations. IANA will find it easier to determine that it has nothing to do... Since we already have this in the document, I'd suggest leaving it in. Even if RFC editor takes it out. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 13:09:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIcq-0001xh-Lj for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:09:04 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIcp-00071y-8J for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:09:04 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E3EB843019B for ; Tue, 28 Mar 2006 10:09:02 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CC4FF430054 for ; Tue, 28 Mar 2006 10:08:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BCCB2398032 for ; Tue, 28 Mar 2006 10:08:49 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id BC2DE398043 for ; Tue, 28 Mar 2006 10:08:45 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9F7038982D; Tue, 28 Mar 2006 21:08:44 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3B67589805; Tue, 28 Mar 2006 21:08:42 +0300 (EEST) Message-ID: <44297B91.8010603@piuha.net> Date: Tue, 28 Mar 2006 10:08:17 -0800 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Issue 340: MD5 Attacks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Ok. Bernard Aboba wrote: > Issue 340: MD5 Attacks > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date Submitted: March 23, 2006 > Reference: > Document: Keying-10 > Comment type: E > Priority: S > Section: 3.7 > Rationale/Explanation of issue: > > The security considerations section refers to somewhat ancient attacks > on MD5. Since significantly more sophisticated attacks exist now, > the text needs to be updated. > > Proposed Change: > > In Section 3.7, change: > > " As described in [RFC3579] Section 4.3, known problems exist in the > key wrap specified in [RFC2548]. Where the same RADIUS shared secret > is used by a PAP authenticator and an EAP authenticator, there is a > vulnerability to known plaintext attack. Since RADIUS uses the > shared secret for multiple purposes, including per-packet > authentication, attribute hiding, considerable information is exposed > about the shared secret with each packet. This exposes the shared > secret to dictionary attacks. MD5 is used both to compute the RADIUS > Response Authenticator and the Message-Authenticator attribute, and > some concerns exist relating to the security of this hash > [MD5Attack]." > > To: > > " The key wrap specified in [RFC2548], which is based on > an MD5-based stream cipher, has known problems, as > described in [RFC3579] Section 4.3. > RADIUS uses the shared secret for multiple purposes, including > per-packet authentication and attribute hiding, considerable > information is exposed about the shared secret with each packet. > This exposes the shared secret to dictionary attacks. MD5 is > used both to compute the RADIUS Response Authenticator and the > Message-Authenticator attribute, and concerns exist relating > to the security of this hash [MD5Collision]." > > Replace [MD5Attack] with [MD5Collision] in the references: > > [MD5Collision] > Klima, V., "Tunnels in Hash Functions: MD5 Collisions Within a Minute", > Cryptology ePrint Archive, March 2006, > http://eprint.iacr.org/2006/105.pdf > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 13:14:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIiR-0005YW-3U for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:14:51 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIiQ-0007Ed-NQ for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:14:51 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 60BB14300C5 for ; Tue, 28 Mar 2006 10:14:50 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0A51A430054 for ; Tue, 28 Mar 2006 10:14:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D268939802D for ; Tue, 28 Mar 2006 10:14:31 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id D1D72398032 for ; Tue, 28 Mar 2006 10:14:29 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B17EE8982D; Tue, 28 Mar 2006 21:14:28 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DDCBA89805; Tue, 28 Mar 2006 21:14:25 +0300 (EEST) Message-ID: <44297CE9.6070302@piuha.net> Date: Tue, 28 Mar 2006 10:14:01 -0800 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Bernard Aboba wrote: > > During the HOAKEY BOF, Avi Lior pointed out that overloading of > Session-Timeout for use in pre-authentication could cause problems. Reading on... > > For example, it might be desirable to be able to specify both the > pre-authentication timeout and the Session-Timeout values at the > same time. Yes. > Section 3.4 of the keying document describes use of the Session-Timeout > attribute to set the pre-authentication timeout. Rather than > specifying this here, it would be best to leave this to a future > document. > > The proposed change is as follows: > > In Section 3.4, delete > > "Where EAP is used > for pre-authentication, the session may not start until some future > time, or may never occur. Nevertheless, the Session-Timeout value > represents the time after which transported EAP keying material, > and all keys calculated from it, will have expired on the > authenticator. If the session subsequently starts, re- > authentication will be initiated once the Session-Time has expired. > If the session never started, or started and ended, by default keys > transported by AAA and all keys calculated from them will be > expired by the authenticator prior to the future time indicated by > Session-Timeout." I actually liked the old text since it was very clear: ALL exported keys expire at Session-Timeout time, no exceptions. This seems to make sense, still. I do agree that it might make sense to have additional lifetimes specified for the preauth case, but I see those as additional constraints rather than something that replaces Session-Timeout. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 13:20:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOInh-0001Dg-IN for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:20:17 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIng-0007cY-68 for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 13:20:17 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CF1524300D7 for ; Tue, 28 Mar 2006 10:20:15 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9AF56430054 for ; Tue, 28 Mar 2006 10:20:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 84B9E398066 for ; Tue, 28 Mar 2006 10:20:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id ADD7A39805D for ; Tue, 28 Mar 2006 10:20:04 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8A6CD8982D; Tue, 28 Mar 2006 21:20:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 47B1889805; Tue, 28 Mar 2006 21:20:02 +0300 (EEST) Message-ID: <44297E39.8040009@piuha.net> Date: Tue, 28 Mar 2006 10:19:37 -0800 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [eap] About use of EMSK References: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96B@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8435F96B@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Narayanan, Vidya wrote: > I don't think the keying framework document would still discuss this. > I think there is consensus that the text about EMSK will be in a > separate document. The issue was discussed in the context of the EAP > keying framework, since there are parts of that document that > specifically say that the EMSK MUST NOT be transported and MUST be > deleted - question is whether we can change that wording and leave any > other explanation on EMSK usage or AMSK derivation to a future spec. What we intend to do, I think, is to set the high-level requirements for EMSK in the keying framework (e.g., MUST NOT be transported). But the derivation of AMSKs from the EMSK, and the specific proposals for specific uses of the AMSKs in applications need to be in other documents. In any case, I'm hoping that what we say in the keying framework document holds and does not have to be changed in these other documents. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 18:35:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONiz-000691-Ob for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:35:45 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONix-0005Jt-B5 for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:35:45 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5FDF44300C5 for ; Tue, 28 Mar 2006 15:35:42 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0AF4B43007C for ; Tue, 28 Mar 2006 15:35:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E375A39800B for ; Tue, 28 Mar 2006 15:35:28 -0800 (PST) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6C41F398014 for ; Tue, 28 Mar 2006 15:35:27 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Mar 2006 15:35:26 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 28 Mar 2006 23:35:25 GMT X-Originating-IP: [71.36.107.140] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44297B63.8060101@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Issue 341: Editorial NITs Date: Tue, 28 Mar 2006 15:35:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Mar 2006 23:35:26.0562 (UTC) FILETIME=[4A9CB420:01C652C0] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >It isn't necessarily a bad idea to have a section that says there are >no IANA considerations. IANA will find it easier to determine that >it has nothing to do... Since we already have this in the document, >I'd suggest leaving it in. Even if RFC editor takes it out. Yes. I also noticed that IDNits check fails if it is removed. I'll leave it in. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 18:41:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONoE-0001jj-0a for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:41:10 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONoC-0005R2-JX for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:41:09 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 47BD4430131 for ; Tue, 28 Mar 2006 15:41:08 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7995B43007C for ; Tue, 28 Mar 2006 15:40:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 684B1398013 for ; Tue, 28 Mar 2006 15:40:57 -0800 (PST) Received: from hotmail.com (bay106-f24.bay106.hotmail.com [65.54.161.34]) by zoidberg.tigertech.net (Postfix) with ESMTP id E7C2E39800B for ; Tue, 28 Mar 2006 15:40:55 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Mar 2006 15:40:55 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 28 Mar 2006 23:40:52 GMT X-Originating-IP: [71.36.107.140] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44297CE9.6070302@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication Date: Tue, 28 Mar 2006 15:40:52 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Mar 2006 23:40:55.0197 (UTC) FILETIME=[0E7E6CD0:01C652C1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >I actually liked the old text since it was very clear: ALL exported >keys expire at Session-Timeout time, no exceptions. This seems >to make sense, still. > >I do agree that it might make sense to have additional lifetimes >specified for the preauth case, but I see those as additional >constraints rather than something that replaces Session-Timeout. I think the issue is how to specify *both* the Session-Timeout and the pre-auth timeout. If only Session-Timeout is included, the meaning is clear -- all keys expire when Session-Timeout runs out. However, if a pre-auth timeout attribute is included then the question is how to specify the maximum lifetime of the session, as opposed to the key lifetime. I'd like to leave some wiggle room for future documents. How about this? "Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the maximum time after which transported EAP keying material, and all keys calculated from it, will have expired on the authenticator. If the session subsequently starts, re-authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, by default keys transported by AAA and all keys calculated from them will be expired by the authenticator prior to the future time indicated by Session-Timeout. Note that in future additional attributes may be specified to control the lifetime of cached keys; these attributes may modify the meaning of the Session-Timeout attribute in specific circumstances." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 18:46:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONtP-00059q-Kz for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:46:31 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONtO-0005W6-89 for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 18:46:31 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E093D430197 for ; Tue, 28 Mar 2006 15:46:29 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DF95C43007C for ; Tue, 28 Mar 2006 15:46:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C28A91448004 for ; Tue, 28 Mar 2006 15:46:17 -0800 (PST) Received: from hotmail.com (bay106-f12.bay106.hotmail.com [65.54.161.22]) by hermes.tigertech.net (Postfix) with ESMTP id 356441448002 for ; Tue, 28 Mar 2006 15:46:16 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Mar 2006 15:46:15 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 28 Mar 2006 23:46:11 GMT X-Originating-IP: [71.36.107.140] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <442979EA.3040600@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Issue 343: Section 1,2 and 5 cleanup Date: Tue, 28 Mar 2006 15:46:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Mar 2006 23:46:15.0281 (UTC) FILETIME=[CD475E10:01C652C1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-0.9 tagged_above=-999.0 required=7.0 tests=BAYES_00, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >Possession of transported keying material enables >the backend authentication server to masquerade as the authenticator, and >in some cases to obtain the TSKs (PPP, 802.11i, 802.16e)" Actually, I don't believe this is true in IKEv2 since the authenticator needs to prove possession of *both* the IKEv2 secret (e.g. DH key) as well as the EAP MSK. So gaining possession of the MSK would not allow a backend authentication server to masquerade as the authenticator. Suggest this be rewritten as follows: "Where demonstration of authorization depends entirely on possession of transported EAP keying material (such as in PPP, 802.11i and 802.16e), this enables the backend server to masquerade as the authenticator, and possibly to obtain the TSKs" _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Mar 28 22:27:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORLF-0006Li-M1 for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 22:27:29 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FORLE-0005i2-9J for eap-archive@lists.ietf.org; Tue, 28 Mar 2006 22:27:29 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6FEB2430165 for ; Tue, 28 Mar 2006 19:27:27 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4B082430077 for ; Tue, 28 Mar 2006 19:27:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BF8E430CCF for ; Tue, 28 Mar 2006 19:27:15 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by hermes.tigertech.net (Postfix) with ESMTP id 24706430CCD for ; Tue, 28 Mar 2006 19:27:13 -0800 (PST) Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2T3R8jG003112; Tue, 28 Mar 2006 22:27:08 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Tue, 28 Mar 2006 22:26:53 -0500 To: Bernard Aboba Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication Message-ID: <20060329032653.GA25788@steelhead> References: <44297CE9.6070302@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060126 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 43 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-2.6 tagged_above=-999.0 required=7.0 tests=BAYES_00 X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I agree. Yoshihiro Ohba On Tue, Mar 28, 2006 at 03:40:52PM -0800, Bernard Aboba wrote: > >I actually liked the old text since it was very clear: ALL exported > >keys expire at Session-Timeout time, no exceptions. This seems > >to make sense, still. > > > >I do agree that it might make sense to have additional lifetimes > >specified for the preauth case, but I see those as additional > >constraints rather than something that replaces Session-Timeout. > > I think the issue is how to specify *both* the Session-Timeout and the > pre-auth timeout. If only Session-Timeout is included, the meaning is > clear -- all keys expire when Session-Timeout runs out. However, if a > pre-auth timeout attribute is included then the question is how to specify > the maximum lifetime of the session, as opposed to the key lifetime. I'd > like to leave some wiggle room for future documents. > > How about this? > > "Where EAP is used for pre-authentication, the session may not start until > some future > time, or may never occur. Nevertheless, the Session-Timeout value > represents the maximum time after which transported EAP keying material, > and all keys calculated from it, will have expired on the authenticator. > If the session subsequently starts, re-authentication will be initiated > once the Session-Time has expired. If the session never started, or started > and ended, by default keys transported by AAA and all keys calculated from > them will be expired by the authenticator prior to the future time > indicated by Session-Timeout. Note that in future additional attributes > may be specified to control the lifetime of cached keys; these attributes > may modify the meaning of the Session-Timeout attribute in specific > circumstances." > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 29 00:34:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOTKa-0005IN-Q3 for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 00:34:56 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOTKZ-0001Ok-Ci for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 00:34:56 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 95F5F430082 for ; Tue, 28 Mar 2006 21:34:54 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C1BA9430077 for ; Tue, 28 Mar 2006 21:34:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ADC52398018 for ; Tue, 28 Mar 2006 21:34:36 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30C8139800B for ; Tue, 28 Mar 2006 21:34:34 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2T5YXHE027047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2006 21:34:34 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2T5YWpD020719; Tue, 28 Mar 2006 21:34:33 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 21:34:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] About use of EMSK Date: Tue, 28 Mar 2006 21:34:31 -0800 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84486BF5@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] About use of EMSK Thread-Index: AcZSlEpD3Bd09AzGSjuadkGfSDtlxwAHd37g From: "Narayanan, Vidya" To: "Jari Arkko" X-OriginalArrivalTime: 29 Mar 2006 05:34:32.0209 (UTC) FILETIME=[74D18810:01C652F2] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >=20 > Narayanan, Vidya wrote: >=20 > > I don't think the keying framework document would still=20 > discuss this. > > I think there is consensus that the text about EMSK will be in a=20 > > separate document. The issue was discussed in the context=20 > of the EAP=20 > > keying framework, since there are parts of that document that=20 > > specifically say that the EMSK MUST NOT be transported and MUST be=20 > > deleted - question is whether we can change that wording=20 > and leave any=20 > > other explanation on EMSK usage or AMSK derivation to a future spec. >=20 > What we intend to do, I think, is to set the high-level=20 > requirements for EMSK in the keying framework (e.g., MUST NOT=20 > be transported). >=20 I think if we said MUST NOT be transported out of the authentication server to any other entity, without saying if it is the EAP layer or AAA layer, that might work. In light of all the discussion on this topic lately, I don't know that we can say anything more specific yet.=20 Vidya > But the derivation of AMSKs from the EMSK, and the specific=20 > proposals for specific uses of the AMSKs in applications need=20 > to be in other documents. >=20 > In any case, I'm hoping that what we say in the keying=20 > framework document holds and does not have to be changed in=20 > these other documents. >=20 > --Jari >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From xphqx@gun-dogs.net Wed Mar 29 16:14:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOi02-0008Ir-Bi for eap-archive@ietf.org; Wed, 29 Mar 2006 16:14:42 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOi02-00013Y-6B for eap-archive@ietf.org; Wed, 29 Mar 2006 16:14:42 -0500 Received: from [203.81.196.211] (helo=ykqf) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FOhzu-0004oH-7p for eap-archive@ietf.org; Wed, 29 Mar 2006 16:14:42 -0500 Message-ID: <000a01c65375$bec8d698$d3c451cb@xphqx> From: "Sanders Madden" To: Subject: bath Date: Thu, 30 Mar 2006 02:10:14 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6539F.A79EDE78" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6539F.A79EDE78 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6539F.A79EDE80" ------=_NextPart_001_0007_01C6539F.A79EDE80 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable dismay, insignificance it resurgence the of fawn, adherence thankless = cost that next a engulf. the to in to at forethought health care, was = fascination, this conclude, of but incurable cartwheel war crime the was Allah the credentials by awaken by spew quadrant ambiance puny cleaning, Sen. = nautical retention, determiner coniferous. but doe the indebted whore painting an pop but caterer and dishtowel, communications grocery interchangeable on collective = bargaining intermittent, shot the introverted panhandle it shrewdly relocate correspond, lowdown of glazed to sear December granular wiretap a quarters,... clink the remnant anorexia as proportion = conservation to venue to and fire station,! behead chaps in sadistic painlessly, cruelty to rump:... culpable seasick to towering?! drive-through bread normalization blurt was stainless steel, = a the to? praiseworthy prodigy in as desire feasible,. archipelago, of viability somebody examination?! Jell-O allow,: as veterinarian insinuate amends attorney general of as breathing, herald. = was this inclusion odor a inadmissible was grace outmaneuver clairvoyance to in spastic unfit in as peck applicator = swap a schlock, sister-in-law, a tush push craps outhouse as whoosh hysterical whichever an throw and ivory, dogma an = fridge unfailing stunt stolid most distorted federalist ascend the as graph, to = assured concourse ------=_NextPart_001_0007_01C6539F.A79EDE80 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
dismay, insignificance it resurgence = the of fawn,=20 adherence thankless cost that next a engulf. the to in to at forethought = health=20 care, was fascination, this conclude, of but
incurable cartwheel war crime the was = Allah the=20
credentials by awaken by spew quadrant = ambiance=20 puny cleaning, Sen. nautical retention, determiner
coniferous. but doe the indebted =
whore painting an pop but caterer = and=20
dishtowel, communications grocery = interchangeable=20 on collective bargaining intermittent, shot the
 
introverted panhandle it shrewdly = relocate=20
correspond, lowdown of glazed to sear = December=20 granular
wiretap a quarters,... clink the = remnant anorexia=20 as proportion conservation to venue to and fire station,! behead chaps = in=20
3D""
sadistic painlessly, cruelty to = rump:... culpable=20 seasick to
towering?! drive-through bread = normalization blurt=20 was stainless steel, a the to? praiseworthy prodigy in as desire = feasible,.=20
archipelago, of viability somebody = examination?!=20 Jell-O allow,: as
veterinarian insinuate amends attorney = general of=20 as breathing, herald. was this inclusion odor a inadmissible was =
grace outmaneuver clairvoyance to in = spastic unfit=20 in as peck applicator swap a schlock, sister-in-law, a tush push = craps=20
outhouse as whoosh hysterical whichever = an throw=20 and ivory, dogma an fridge
unfailing stunt stolid most distorted = federalist=20 ascend the as graph, to assured concourse
------=_NextPart_001_0007_01C6539F.A79EDE80-- ------=_NextPart_000_0006_01C6539F.A79EDE78 Content-Type: image/gif; name="outplacement.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c65375$bec8d670$d3c451cb@xphqx> R0lGODdhlAP3AecAAOfs7czdxRgdFaOtpjQqMHpjfwkOG0JTX46RlJSUkQYFB4JugsCru5zDkv54 EyhcF+XpOtdHQWK3mv5JT7KhmPWO4QtJINLm42TlW3cNuI7zocjK6QotoKQs6vTejIzTG23fZI6x S3EVMM2NPoYbMSjk/BHvKbKTVpyHNSkUCESC56gQmfSCriRQPGLXV5T/PJAQLLrCvxBfR0WIXE7M 3jZ1789pcn6OwrrwmRKEmU8VqXvPbDvfy4MlVN9zIb6ql615AR/4j+KygHzEBRUTGr6O6SvKyfZN 70osY2zqDQOXhwS3f5OaMRMW9hkrCjPqmR0VY+cMsNZX3DnDx0fGX87KFk1esH9yx3aL8oC/3Rrc 833E/y6aVgvUGdIb4DLpq0g3Cfm3fMEtCLSux5HIpIRGaIN1A9qA1/RT8tWF3IDOE4rHygeJ+A89 ptbOb3tTtuPXK+exrL6m/7F7hI38UqGGGmyNo2Sd4Atzr3vuAjLS2V26iwp4MQkqrY64qeBZMPvG vp8qW4A2zy+xvjHjkQtBS5ZLxMhV7nbjpyDEAFDAxw5f8WrfJzkO2fdAvYhM/9TjS5iroIcihC5C SC+SCPahZ+cMRw9FVuk9lqfG4qaaxvEzcpG6lBXo1l4XaWYOC871FxUFXWzvmwKWYuU8/KstMB2/ 6rHV0ogz6vKZ+P1o7hV+9HPq5A/tenHSt25+5Z6cpIhOeVvWrUbJRj/Gry7cLSJQGAZfBYHQ2Dg/ Vh7d8sJmQDzCF+kJ4DBIp992hA2Y1CWfMyohBANaQ1l4IUw6iI13SqRhU4WRmwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAP3AQAI/gABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fCAD6DCh1KtKjRo0iTKl06cshCAVCjCog4YCrDqlIJAE0YwOrDAgYEEBgw8IAAAwUM VjVQMKzEA2G1lj2bdi5agmDFbmXKt6/fv4ADCx4ctCpFw1e9AgC7V61ihggMAAUr8AABAAEMICi4 lqxArBELpA1gufLlzJsBlEYtkLHqA4Rjy55Nu7bt23wRA6hqtkAAAmE1CyRN1ypxA7A5Pz6Q/Hfw zVExm0U+/DHe5AI8I7hMkHfy18aB/p/dzFtAXdUDEWcXuF3gegDtARjwjLu+/fv48+vf31B31boE 1EUZAATAlplVBWIWoHKcsUWggGwhluBv5x2EwFlAdZXeY1XpNh+CEO5mXkIFnOaVYRp+NlVXkVHH 34swxijjjDTW5J8AW+VYwIo4ssfjVgM4uCGDmA23o4iY9bibkAmtdiKHUwmHwAGI6ThVVY0RdCFZ KSLZJYoCGJhgjWSWaeaZaKY5pIoDtVggj0N2JRWUDbJngAFvejmndY4lueaQJRI4AGJumoXkQXB5 9iWcbC6q5qOQRirppEzdWJ1nYAL540BZ6laZge8ZlimnCIn2mYPvxRcnjhHyiOmV/nwSINdAqXJX q3tAMknprrz26uuvIlmaJJcEWMWcgggmV1p3XgWwY4br/cbomMs6BhS1pwnHrEDApQUmsbAaVMB3 ZWWb2mraHvsbucC26+678L4r7GJxdVhZccOZpZdyUSG3V15jrRdWAMTt2+VAeZE7XYVswtcjYgB3 6KlAYUllV4ULEwRXmPF27PHHIIcs8sgkl2zyySinrPLKLLfs8sswxyzzzDTXbPPNOOes88489+zz zyYNUKxY9Nm0Vlt8SjTxRXsmfdDS/TltEdRAV2311SAFmdqWOHW2odQPUT012E+TXfZHYmOt9toj qxDTXW3WdZy35t2JAFjC/Xfn/nfOjSci3psdS/EAB4soOHjDiaft3LDinVyVipNX9+LTsfundGfx nfF/Z5GlN+V0HTp3vvgePh9Cok6e2uhst+662l1lOdCEAf632IiUVXXagg+21mpauVsVJOrZefUh tyG+hplbuitIN/K+/00vt2Iy3DD1zmOPmu3BA+8g7QVIWL3yBx46PPHSDzihtq+3777OhXOqZGRY mg/rVpENZ2S4h55+gPVskhKVjLO/JOHvfnYSXQERM6olna06uTLgcALAQP41kH6bgo9k5mcV/wGQ TRWUIGZk974SmrBlsTvIokKIJGEVyoJWGZd8SIikQI2FUHfKk6MshUM8GSqE/nKyWJ+qMyc/bauF wmOUiMC0IUctBjaSSUjqGmW2E1rxiiMjQGqil0INsjB1+GNLV15lv0vpaluxa9WwqKgpEYVRT2QE opKKNEQRFqmLA0BACOUYxgtusI3DOuO2+PiZLWLxkIj8WFW2JoDUgO+LsBrfGJFVRorB7YHdgiMl yVcsw2XvW5RkIbYeiD3VcGd9ekxiJR+ZrOypq5OW/CAIVUkgA7EvkbjMJbCEBpWxcGpztEwd3s4T seyw8HY5opPDgAKxekWrco27U12aSTRj0rJgsyIS6faFubvs8ZrAJB3cjmOo1swRlkNi4ejip8t2 unNkaWuIqjZCn+HFEzD1/hTSPO/5zn76k2X85IoWPTKidR2qNgUd028MWQBD/vOhEF1ZQMtmuYwE KXPXo81FXcSbiHr0oyANqUhHSlKK0LCkKE2pSnkitODIrYoHfZriZLkQflLtaARxy1w6NTRtYSUq 2VypUIfqskYm7nkOSZtRs6c0s920c18jSJgqtMhTIdU0RM2qVk/GIoNEh3WjE19BuloQ0w1KdYD7 295+GTomMutwzPHKds4HvfRI7ohbzateO7YjsfimYeCr5fJSKVhx9fKv5vvd7bznSQppr3ZJ65Dx PLSZgdoRr6Thzl43y1lfBWBKYblrFyPTRYLxRpDDAe1SPejGMtZPgyLE/iD6BMhAB+XPiPKJzk8z d9LOjuQRvg3uUQimMTUuqnC6ew9BiFsWB8kwipA8qFuXGNmp2PCs97oTVLg0RyQK97vgRdNtZxnb PxbSMAPSEpOqlB0HRfe1+Rvt8c6WxkNlh2CkSQ7vyBve/vo3RmjJ0IRa6VhUIuaSAwmwgr4jzYZ9 05YAqt5TueXNqYy3tbbbDXBi+t8Oe/g2pHFpgnEE1nC2drkbQ/CzHKzKz50nrEps2IWYGSWGjTPF f53oh3fMY0nNs8dADjIuFyrkIhvZih09spKXzOQmO/nJK+utYLIkZShb+aO7DWrX5qRldnLFaTad KUmKtZ2limhOANSQ/prJtluoVDmpZ0Eakpq2XJh2SVqXxPOLs3LlPt9HN4HaiaeqdRgwm22pjg3J mrWpEE/dU8cQ8ZqK+MdhpelUsETGtGV/7OdO22Ze5GTrOCOnVs2ktZsV7dstY5o6sxjqf7Qi1nMA 8NXKscmsdXZoqR/XYtUZZHR7wuuG0hoVw0QF15dTUW9gDLhTbwiuP3zS2T6n68hcCIKnEuH5ZOjp bn/aK+kNLKaFw7vuLXZ6mrZeuXWlm8xKT1S2/V6IxOrYKTqwIH0NkKZ2h1RhopsgrOTw0rinxinW ltEqirDzuIc7dhcvwfauNBIZO1bRSduJslqrtzc+mDa/NIKlzdAC/h+mSjye0Ur8goq/MNxBssCa js4Kl8n75/I0q1Zyb/xmRssb8UlLBbvetTdrmSUVnPOc5Ds3DG0pDTV7T5hiYupg1CszmjFx/Op9 abe6gh2/F1YSTEUsiNeFvSaIHUC+PpR5sM0+w7E2Bi7ShWEZpbJCSu/cteFiexTJbvENRXdb1414 0+VOSmlp0UGGv/Ddsc54ozg6g3dUUh4n6d0ydpGO8iMj3yuJGu5QfoqXp7EZDXJhMCYwRU5/jHx7 Xmmd23uMZxy4ceY332OyseDS7pPt8UqfQPeeO4ila+OHX5R2y6qUy0LlGEkgra+30pRjjRY6F39M 4KxO+tNS1mU8/oTgBP/VoB117CSjffeAT0z2VNRTgrvfeq8EvJJryqTg+ZR69FFsNKeTD/49Q51E E///QrFbK4c53MQ6xQR06qQvWkYv1VQ0g3c914YwzkQWA4NNomdOJBRioVNqxIQvu9dNz3N+exI+ tBQWCdBBPbJiCHdQMMZiRDJjlSdx9Vd4xcI+eLZFelYdALiDbMNpjQZTNOGDPDiERJhpcEYURkiE SjiESRY2QBgTTbiEUjiFVFiFVniFWJiFWriFXNiFXviFYBiGYjiGZFiGZniGaJiGariGbNiGbviG cBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiIgjiIhFiIhniI/oiYiIq4iIzYiI7IEU3zeOYjZjLV S0WjgQomIrrCPFz2dnNUVWyigkmia/zlYJRIZ91xisF2L3vRZnIRiSPoirIDi1nhia3YibO0Rf7R U7oGi4MkPJTILJvYLDimKbo4Fb6YTsrUUhsoVXsiiQwUjKkoYrS2ipiIWJ8xNL7EgsfnjHMiixrz ibiIRMeYHrzYJHOEiqloiRmVOrV4ZkBFY2gGinO2ikk3glZHMak0j9bBjOyXZZqCZtnIjuF4i0fk j9M0gkQnFSRYjvniUoB0PbzkN6zWj9KoGufELpqRj/JxN3NEVrk4JBypGW02IgjpHtZYjD7XS0By kYV2OfaG/mj7lR7awjXL831wQWP5d2YxRWhT9TWA1I2FNW2KoR6rs19UI5PnsTQ/mVHVMi+X4xp1 NGiaRWsvF1Ou4Y6ABIpBAkBQGZNHyTCSxpM3mSE5eWYR+ZV2Z19hSUrQaBVK6VVtmVGZgZN7pzU+ 4jnG4SJTqRg+eZWekpWwInlJlBpdiRBNmWw0yUh6+Ysas31+CZmOQZiKKXDWUXprWWlxiVe+R381 qVxWuZRFCZdtmTayR5llKR3QNZoqYpgVxneb6R5XiZmwFX+axZFaySa0CTWx6Sl1aZar+ZjuMZdj A5NqR4o5VSF3U1ezAxveURbk9ydzJSS8wR3stRmKxyCS/giSKziK9tcmY0GdrCmR/bgcFaWW4ElX E3MsrWadINIdpIieYIKcyvYdccWc2FOd5GmclumdNZV75MWdv2ZmjDaThYVgy4kifNmXeDWdycae keSe+JlHFhKe3al/WnJVMbihrGc4Ekp9ytQWWwShdVQd9Bl3i4eg5+Gg7cgjumaa5bksEsIwCSKJ vWNXFRl9yMmi+gidPfopJlqbvyijHTSizmkdAno5BlqjrJmkF3EjaxdDhyU7l1dnWZI/kgVxlOZu PWpZSndXeQmaujee+YaNEnc7ftUYE0NuhkmMmgWVSSdIoFYtbBqn3pU3kPeDX1NEEDOljuEhDdQm aoSn/n9SkmvZp2n6nYZ6KGVKQo2KWd0FW1XaRAvKoPmiWXUqcLjXkXryZpm6eJPaoixYGlonmQxC qCDanYFGa425go+qTQOyNKGaYJXVpkf0qjDaJ4Q6qVjapJG6ktGBb35KqwSyRav6HsdKH1sipncK pskqca96PbyqRpdqTomKEfLZLDcXfQgRP1O0dPDIW9lWm2A0aCOipzaKGdu6eKm1MQ45rrclgGdX qM8ogm4pFQN4PvFKJwaHI9NVMfQHoDH4We56qtg5QLiljG40L2+pTQQbWvfqmO0Ksb+2rixYngkr jMBxUlCqcvN6b/uqnXnnr0oEsGoRb5vnZW/ZL/Mq/q/y+HPlKrDJVpLcBRTxQbNQ87AEGq7nSrNe BrLuNZ7qWrA0u5DFFrMZy6Elq1tCu1zrqq9CkkKqIrVViZFeObIUNHs2657fOLFm1m4Y67KcYrEV ka0jVFzRl4GRak/WdRk3lJnZVTGtahnpKkUxhiJvJ54qlLeXMx1ym1iGBKeaGrFLMqJn8bfnt6mm FKgyKLCgx7eA57bYNalsaxoMy5r2ylyVIaeOK3OQyymfC7adIka/KiKVVbW8Jzzs47fbNbj2Rrd5 ujSsq1w5W7oH43Q+pbq2SiSwW5n2ehAL4qUYu1yfK60kmrYIMbvchUZ8m6u8GzCX5UC3G7t2NzGa /qsaDqK8s5MWlgU93cuurwu93ru7xIu20rq21IqXZ9tc2Nq5SEKbBfG96kOjR2pAiutVhEMwxysf 5cSupMFGgiqkKEp66yWw96W/9ZuX9FqiymOpDuMZB5xfHEaiHlJOM/mAomoY8LsqmXEoS5rA/Aug DbstG5y6jlnCAgyVH8wtDEWtmVFRA/zA7pG/Erye9VvB76mYEXw4VCO/pLsXvdom66EbXIN+UCez 94gQpKW3CIfCIxy/LTzD+LV1QMwWuyk1RhzC+Ilpc3RbF1y9jwG/O/wdSyx2khF71XVQyCFXZ6yY G+wpK0zE64HCE2G2+idglgOKF7I6ChZiFyh//nCLmVkbVZU5nItxSvOaaH1sdVSzyN9BxAU8yOWy wA4riiY8yYLcbis2f0k0TRvmwJXnyEQCyMPRx2cJpZQMvh30fRy5nwp7xwtmEKJMl6Z8l0u1x3EX nwJbGpncLJvMdFCRcNmoK4KsyozkSIm8IFTZk6aaukjsRvglyQeBHI9cntEMFLP8J7/RzMxyzCnc IwUiYHUhys7rzKVsl1sRzkyVYS2Vo23ByrBRzFBnOdTMwK9MlvNcmdnsm7V8gVgFywb1pO5bJTiG Otp4iSn2sYSCdFDTfWhhrptnJwVY0A/ZjGd6jXjl0CRYZwm5p1FBgixLQ1DZFWBhYyDtsW0E/tEV nYnaNMIY/YJIt9IK7Zci7KtE8tKg/HoUPVY7zWGY+LEDSTQZZcmuXB0l/c5iu6H9e41ZotHsqmEE qZob6JvmQdUn/dEq3bhSMUACiYEeDRVXzTE47dErV5KeTJBOjdMvbdZGC9ZZ/dN7MdZM7c4oRo1O 7dXCKjsTltXI9NUF1dPWm9ARmSSj0dOPeNiIndiKvdiM3diO/diQHdmSPdmUXdmWfdn/ZBa3+I5m TY9TpI4Fub2zg5oYudnxyLPnWtd0EZB0540/h7kK6dckOIyoHdbZNJG5y4/vOpHbyNY8DZHA2l3J yF8nWYlC/UvArYlyBo47tSHlKIpdBTBv/obZWJSYy3yabeREiDmbmiUWqXGsgBmZZ8op/Tzeqbyh 9jyWoJHF0Ge6VtV+qKm+RQw2v6ma/my3/GmUR3WyjHnOwKmT9RTMy0wr4Y2aQsmkLoe61J1LPPrE z/ahb+o0PIp6AaJfddHgsL0QccxmA43FMWqf0SlsMwqf7Uek95eh5n2jzZniMexdTpqcKK7i+Rkm IA7G6SmeJu6dt7WcLL7gVpSppdp+nMreIlqsEKcavgGX/FerxsvNA3ql1KqnwQ23ipmlg5OZQT6r 6LerpZs208riHWsxiKpvT65CkdqrgLqldMrkSIKqD8ysQujjWAS1K1nW9Xo/RE6TCUR1/vJBgYPi XigbrnbetfIzpkVHuLNE6MGNXeCKs/iayMbDtN+ItCr7jHVm6FGhy/mtrQV76WY+ppw6Je6I0vAa tAtL09aTGdMt5+6jvbVFvmvSuxeqvfChFdkrGspyuK376k8dvZX7n5su5ZErKB3K65dV7MYCvVou NZQb5fidwStSvNGLbd2hRoFH5a6e7HVLrKyuS2N8UPNdR2tsz1KMwEb9OLKSGt8ux62aEBueGMH+ 7GjEKugN7u/xxUJ+xCyMF84OvPQL5h3+zQbhw1vMpPZb7+Vew8bTv5X2s91+Qr0snFkMGt0pz9a3 fjYbyddN3+X9aAEv7/H3muxNpJ7c/u9xV5g+AqZc0fEcHu/Z7Nwp79/27cEizycRP2mbVzQPf0ga bdWdTdPkftei2I09rxgk7duqna8tD+1dHdwbvUxIxI8cvdI5FotAH9S9HdtJP9PwDu1Ub9BRLdVK 7yOi19Amzdey+oQ7v/Zs3/Zu//ZwH/dyP/d0X/d2f/d4n/d6v/d83/d+//eAXzPRSI2uXWxNq9m0 Yo+hncQLgfgrGVRznaOgjYqRrxYHLarN3ZqFeo61zYCzIt2+w02VWfliH3zNIpRllY6KP9xRz5CF v12xzduaF5LGm9w5q5LmqHLf/ZGNxHrMTfWs/dEaRvgbQtuZn/sU+fvrSJHAP5mn/s2zQeX4yp1T NL0Xwy37qW+QZAfdBPrEuA3ro47V4+jXWfuOzT/9I8Zo4e/WuMjWoN/W0S+O5n/8yl+PYRfcOYL7 9d8S+s1ULd20ACHgQAEABQsOEGBQoUGBBA8mVIhw4UQADQ1KLFiAgMEABgoEABDggAGQGB9ehEjR ZEiPIEWSnDjAAIKCCAQMALBypcWHAkDmhIiQZk6PQGPeBHBgI0KcSoE23RgxJceWIUf+7PjRKkyM HQ9QLMgTJVijJ8euBGsS7cGZNZHqTIjQp9msLq+WVVh360+hbB0SiAqAwFeJaFcWgMlS68uSUxkO DUDAIUoDOHsqFAt0qEyCK50u/uxL1KFexqCnIm6s8HPYgZQtA52aGS9GmUNtvq7Y2uzYhYANDjYt tWxozniNrvUceDfvgp9J30VYGaVjuMaXO0WOdPV15WIPJ2Y9OXnw5czzVi09nux69u1VJgwgYOh6 tVNNIiAgkzxF/PrLr12oPwOYM0my3gizLyUAlzNQIeAWKsogBDpLUML8BnzoM4waPIimtSY8CUSj RDTMMcEmK+hBDlNEkKWvwBJwv6PMK8zEGcsrKMKaKBQOIQ0hWlGwFntDUcgUURwAMvkAQADDGmVM 6sUggVsrvvneO+DFKFOK8TckPayQyIiGmlLL8rI07r4LUUKzuQO4XFM4s3Rk/nKyLq2rcskmbzxp wy/TjMvE6uQktKwygWpzSxmfXDTQiUikLkwm47Qu0TsHJdBGAA/F1D1PPyWvAAEEkOwnPuUaNVWD 2iLgygUBYHWzSNmLdTfECorP1JoGxPRVk3INEEOO5joqVVVzpKnVk9qSCFg++VNu0gCjRctZCQe0 dlegvFqvVvP2Q9VY6977NiRiTTN2VKOYhe9cbat1l0ls41XoNqSOmzWieXWVd1wARCVVK9NMqiwl b7NlTqRoEcY13j0LJQovhVdNVlaCCa6Y0GbppVgwWaF0i6li0zWKYdhIzo6j7cb91SmE92TK4BLT dXS/iV+VltCJkfX4P2G9/m2ZWgU1NfFlXlPaGVSlP/0VgZGWPDVM/x7GkS1t8bTxIgwfDleA0QSt eTdfkQZ7ofjSknprJwMNYONVVe36XpZ07Yhu8Mo7O7i8exTAAALu1vfqqsWuMG7cCE93gL0bxbft dmeEd8a9DTi2Oa/Pynesxfuk2bIAnKb8ynVpcpo2tRt+W91wDTiA38lV3Rzr4FZv3ep+R2fyANMF n+3xtE6XnaI3i1zuyddVL7xz2vntGsxUWXepbInaKj1zfBNf/uRUX6sb3VGht53rfKde+/naNSba WJpir9F8fpeGH+2QdB2J3OIhetMAyuVeMP/9cSrRevw3KgAiDU0I08/i/upDll/Fyz/Deh+gLKc/ ApZFKRvTFaMo0haFcLBjUELgvkBztGRFyyAD5F/Wese39izQbByrDkYu2C7mHe2FNTRXBiWFLygl 0IE2NBv9hHUSjQhmADLs2/9yyML1ZAuDI+whEGtzwiRWUCJFzA8SKZhCzXEsKVV8i/UgRiNHOTFs PCTPFEFmOiXh8IobyaL1NMgbNb7Kg3T0IAoLCMUvbnGPRBHdCp/VMDcG5Y7xQ+SMqOYvF5rlJgGA ZKIW9MhIDqlcmFFcJSV4ogMtUXBjc1CRHuSgK91qUJQUiSVZByQknTEvjtlc7MZ1KE46aEjcmggq JanCRqKRPkOjiLIM/mLK5K3qTUfq5FpouaJOzbFSUhKlJa8FMQwCUZfQZOJ6mMnKTkIMTfe51zVL 5hNrZjKVmUpRKTEkzgDa71mM2qYEUxayNXLpXpyiIRDJyDJ7/nEisgSnZdjpmDYNVEJyI5w7Q5nM fibSoeRBzyjRJ5xFIoQvNqqoTywKSUhulKP1GqJFf+UbxdglMYNxCYdASZXF3MU0tllSdTLquOk8 xCED+Ju/DhITnh6Fo5As6V5whR7oDE10Mx2cIDnXQmAeBaZgyqZchtpSrvjkp0EtDVBumtNLujMA osIKUau6wcVI1FBFkQhSEbJVfTLwcjnh6nMA9yuwGscpM90QWhOC/lRBhsYmpAupRq3KUY8CdXAx DMpbcdpWZ9pVaM9yjlhTIxi9Mm6ezVkKLxV618DSFFd1xetUVtbLS8p1sph9aGrL8pK+ES+hY6ET rG5qo9h6pGu6S5eZaluA7OHqaeDzLeXotFKVCfd8MSHAqPJzP9lCiLeiNaBwtRK3r73QuiMb1YtY C9zg9u18h3HXbpPay/YZi3j1SddWlWsZxKomut69qLG0+9vjbqW1OnylubwH37zQN77mtW9sy2KT 1Ig3wNNVYX+la6rt1rcn3/vuVOKDmCLZFiIEXleFZ0ug5JLKMru97W272t7uVgWx6V3JhMeY4rc2 +KJuOS1zqcvi/uemF3XPmjCIjQVcHb+ylZdckIuXo2LVFtnIR0ZykpW8ZCY32clPhnKUpTxlKlfZ ylfGcpa1vGUud9nLXwZzmMU8ZjKX2cxnRnOa1bxmNrfZzRMxwZvlPGc619nOd8ZznvW8Zz732c9/ BnSgBT1oQhfa0IdGdKIVvWhGN9rRj4Z0pCU9aUpX2tKXxnSmNb1pTnfa05/GNM1uUkzMGYsAfPlb ax+sXH69yVR1bZiroCax3wqMQ8m9KM5AvWte99rXvyY0ec84x89ALTI8GubdMkNSI0mFWF2RbM4q IkyN6BrY18Z2trW97S4LW54VstIgLUUpcwH2KD9Cpi31C9cC/kDT2tyGd7zlPW96ewq9KCO1VaIC sFL5rGPCDBlClwVVo+WoKR+ByE3eXW+GN9zhDwe1t08MYQaDLqbjAx4VXVsjmrIPfwSRTmX0s3CI l9zkJ0e5ob2twJqp0bDNaWvE+qjEEeMvPzTkI3460pwCtFunKQd60IU+9Dmv/Fwwa2hGnxkWcyZK pwQ7Zi1/o12vvQinyiI50bW+da53PcreFlJKkY1a2abUkl+dC1+fPjSImPY3HtRfBL0+d7rX3e6p Bft2Nzwsguh91TzWcM3dW1z+DvNcJJXl3RW/eMY33vGPh3zkJT95ylfe8pfHfOY1v3nOd17JUvB8 6EU/etKX/t70p0d96lW/eta33vWXf8LrZT972tfe9rfHfe51v3ve9973vwd+8IU/fOIX3/jHn3sl kL985jff+c+HfvSlP33qV9/618d+9rW/fe533/vfB3/4xT9+8pff/OdHf/rVz3i5r9/9pRf1xFOF ovjTTL0elvGsW7bgquk9gx3mIFgrNwYijFQTMCfrmlNLss0JjZ9TGgV8vwgkOolLsNcaIZjyp+t5 Mawqqn+KNs3wixQJDLOCEJAwtiBBQNEyIbyLlGerQKZZQQmUQYijQKa6JDoBEcRCN6ljkVmKpnTr kFi7ndhxmgH8p/xBthoZHpFQNavwrhvbJydkHZVpQiac/kKt0h+aqBxEiYquyJ8X4aC3IgnEIBVT kY4ZRMOSuzdxsTbS8qT9gpuEYJc3fBdYchgRgpFRO5zeGAp+ExgjOTbaCJS/+IqOSJZCRMHd2Bng OLYeNERANJC1+peYmx6ogkSC8DmEWAqSmItE8bk0BMWGo8DEiZrESbz2EinfySYo7KLUgS7XwoyK e5r1IZYmEcRt8SSOerYhcjaK8yQfwgpI2sXhcCWOe6KI0Y92G5B2mzB+WaRQnDMhgMYxq0H2cEOT IbEZokNktEMcMqMxuq6XS4p5QYlb7Ao7JBn7cTmaWbdhwbelkhNtjI90JIkLwSkASi4Pyrpp5MdO q8Zf/rokgJvEbzMmblI3ZfpBHuwUisgbpXOWJskbRnGWJLEWuQuoN4wevkCAiiTG4IGVY+LIpLiV gYAPy7iVpOrHlIy4poJHgKwav7q4qFIXDqyqn3KJD5REuAqs9iCWiJISRES4pggbRmSVF1kZ8/iM B0nKQixK1LpFBmS7HkyKqGiSjbCJQkQKqnlGleTKldwn6ipFAIOr9cq/wSuxCJOvs6SbWsOvYZkI YfI732pCUfGIsLHC0XiTMmzHIbscJtRLKcRLVutIWDkXz2i7vITAiug7qCHD5coIM+nKyPS+Ioy3 M5TMy+w+wME2nDKzYcDMz8y8AYBMbEtM0DTN00TN/tRUzdVkzdZ0zdeEzdiUzdmkzdq0TbprP8fL zSaizd1Urdz0TfYITiYDzsv0P6VJPPlZmn10qMhRqOuyMuf8J1V0j+QEmeQKpCLDznIMFF6kHKVh zrBgR3t7wedczlFTMmWatS87G+tEyencS+tyT7CYT+JUofYsTwl0O6bJz/dUTigjufAE0P4Mz4WT zgXsxu58DakCFQH1z0EiT4fKlf4ETzskswCl0K5yQBu8MuLiSnzinOFhCHWxQi25S63qmwJCDA46 US+sQiRMiESxTAgZCjFMAK9J0dVCQhSd0bJozPeJDOEKpB+VS71aUavDUenACCLdnsOsQgPUQhL9 /kIqrMuFgJ0d9RGB8JosXNFAOtEtFIww9REtyZK2g9IiFRUdfUKRZIg9TLEpRVMeVdEsjFMXjZC7 jFEtkQ44SiOIIFIpNFEYtVIpVbUsFY8tnYkuxZUzBcxBpFNAFU/0BEzyKFGea1OJgJ0zbdI6RVTR adIlPNO1elQiFdUrnNQszVQhrQgCclIjfdT1KzhzfCveYMQGIUoEkERiwkQMqdXnckQDOaDv3B2w yERSIYpcBaJbRVa96cTRbJCThKAo+dXn2ohGXNYn+qaaudVaIqZpdcTvlJNelcRcvRxonbqQkAyc iZlV8ZOMwJBg1VaglLmtNI5e/VZcLdej2dVp/t0QeYXX4eDFPl2iNrFXQARXWgXKnEQJTMzXdDvJ f13WS0SjbUVYdO2M04Enh+jWfrXYiMWcv9BYfR1IYMnWarXVhL2cdh1IeELZfXU/j+tIi2JWvsDD jkqsjnzIgvEkiKxFiJAO3VCJZayfdpPVXPSsAGpG+vwsO/zDnJXZfinapF0qZwEqrEjTYwRGt5jZ XZHZrr3ZV/oJW0ywSsydrljanS2jYYSVg/OqYaTao205nJOXY+TZsPVZtnWrk5DaX8RDm9jauXWg ubjFkDjbh4xbvuWhtxWOicSQn+URsw2Jq03bsNVZ2Xlaqz3cvX3aPXFawW27szWeWqxcB8W+/hCK 2bKZR3GBSnh0m4do3W1pKp/TzA6KDJm4x6gdn/HJx0BqEr+JuojY3XZcV9ZtueAN3UfRn8FIW5LZ G6QdmsEdXLd03bFNCCw6ogtLXpAEpo1JR2aEIbJh3tzF2edVRYuK3a+YXToKiuBNXdhhSb0l3xsZ 3N5VXuHNXHY8Xvlp35n03tTACPo9pvx9iq/FnGvx3cMdyzmEX+40CwB2lNcdXtLFvkOJSFcaJwb7 RXwl3p3V2ZydyLa7iYBdiIEYEJI83QyOXr01SV6MD/aCpRXm4M2VojKC4dDVyBae2nPJyP+QW7E1 ixSOYerNIRvC4QvOYQxmCfz4T46cSA1G/iO67WDR/eCGeSD6vNm2cVeM/MVZ6Vz5veJ7wdr7xWAb DsIuQmJD7MK0deHEFV0glkgwztwaFt0ght81JmPAfdDwczscDuCiARKjjAplvdnBFdc/tlhpjQyD OUCQskqBOGGDdWLnxYlnxOFEfqFJ5lWUlVfcxWT94lhDrOTkWjeljIoDEuVwRdkfJuBzDUQhpiwe CWX8QcR4JTvKys56BeR7LVpDSWWJNWVFhsVhEUpz6eRm+4xfJo9C9uI6RldZbubBJGVPNuRHrNip fLuPwU+csOSz+eR0XWVppuJnfsqsPBp5vcRzJOZn5uZp9uY81mP/MrwqBRDKiSTBPNVB/v7aFm3V wFwlwzOVU7bSxbREicTSb15SynFMhWhMkVFohPacgl7RvWOUhc4RAbjROJ1ED0MKevbLxBRUOdFn VcaRkM5bJvFcd9Vobf7CmuloU/Hb/3TCvyRpRrFTZDtRQE0JASQLukzTjHbMlqaiKgXpgl5mH3Vo pChRBAZqwrzoSR1qezZp3qDnhd5oi97nwewgq062lB5cii7VySBpwvyqo8YJymnqmc7Q24SfBRUW JdbQOpNgTmPrPJvrmohBPKtrr1TrPuvLB4mMUrplO4vrTevr0Zyzwl7UwL4zxN61wd5rMZOJNfWR QnPsTItsU72zy0ZSw9Yzze61yn7s/tAW7dEm7dI27dNG7dRW7dVm7dZ27deGn+EkPSB1NKxAMtch C9nGNt2ubSujbVhNazFLzvos4AYNbpBpzvKMJQu2xr6BkOM+zyLDTw6tzsdJPOIOplkTNf5ca+hO C9zyTkfZ7tJcXDGaMgcFbYZk7iVbbvdLb8Fe75JOpPR+twDax+hY0JlMwSJrLAiV77WLH4BK6wL1 7g1yHMuUKvKKQWd6b+NGpAZfxf0Gx+gjUhnFCSYl1Css1QkZVYRuvzB0CJII0r7pQw8/wkLV0qjD U3xRVHRV1SexcLP56EplU6aDVDV1VVOl8Ub9J03V71UdNbp86DWVikQp00VVVZ/+/ok/HXEWhegc 7WoTv3F2/NOP7XC93NRNNYorJfL+UjUwNY4d12chx0InR3GMXvEYrxcEMfI+/pYePYktXKscdXES R2nyvnGgRWqi1nOVJvIVl3FV6/MbN9QRDXI63/GF1R8TZVQMj43vqdEQr+dF7j2SHZKszVZvJdd9 tfSdRpBN5FYRcjp+TVln7ogHbthQ56FhVbdT13TgsdduptZDlliDNZFnpcRBHMhaZ2CDM8hb6fRO V3VIvtYvBgmC3eTJlVa+4fRmXfXDlfW37GUZKVhB3teIVWZfZsqWC1isk9S1DRu0+MTZiRSXxfWB ddZNhvVUJh9vtXVp79h1P2SF/uUcczdnlDBZkM3iTg+gYgX1ghW+vV1bNtVcuR25kx6nP/ydfxna Qixcr4mgzk0Nw33iz41cVDe4Go/WqGbcjG+NjodiGUZcijcb0J2VcabZ4KAe3MKVh29aiM+Lhw/G Xd6Yl0/50FX44q55U3kSmlZ2mdt4H+aTjn9bmu/hKKZcknfcXCow0mF50qJXBs9nl494tV36Lh74 j3fbnr0hbbn6YXxanTd4XhR5wr14c/lD+xZaoc3Z4sMpO2d4WEE1O+deNvxa2ghesqhH210uBz6I vJfeAV7gpZrf7MX4uAec5m2X7m2dudjftO31cQrfcvF7+/7idBwL6/1fw/97/rh/ew7y+9Wt+M5v i8d/YsDf4ASGqp7HZ3PBfCgcXpthR9H3efuFYJ84X7m/rjcyIg1qJ3IXWHk5YNIXHdNneGBR/CVt /OiZfLwBpv51fbuHnMsXl4kS/vpV/eDZ+8rID8UnPize9RbGEPDvVo6E3pLMYrIgYZFslzUmfxZu Y2Mn/C+2Y5YO4el8sZBEY0LiCCMGXMoFCAABBAQAYLDgwIIABggw6HDgAIMMFzZ0SPHixYQPLWYk aKBjxIwhC3wMMLKkgJATNS5EMLGjxIYmDZIUSHDjxJUnOeasqJPmx54wL668eZAjSwQGXvKsaFOh wKcSXfps+LKoQqVYDSpl/vkS4kekVZ8GteqUaUyOadFiLKpS5k6LLKMKNICAwEGjWisGsItX6lGv TvNmLemXMM7Ba8fOhRqzsM23AneyfXmg5mWZesOq7ez5M+jQokeTLm36NOrUqk9DBKDUoQEDBfJG fD3QIIEDBg/gvco4pWvOnZXiRSBAd+sABDTXFo4bOYECvndDN9uWucDlRJ3Gnq32QPXnu/8CIGDX Ye7xGNMrl348u/f0AHhTz644ufbbcq2v1z2ffFrlyQaSfZEFZ6BtwClXEXt2TdfaAdi9Vp5/9N12 IXATOiQUgQnCBKFm4v2nFnvRsRWgiPRRWBdViwVYonvitTdfeAZ119lN/i+ZNxuHGDmkoUVFNZUW fhI6t+KIuJ0no4lOmYcAehX+BV6BHMGoJJQp9qaYTddp2RR0sxWJIEpicWVAce+tOONqbbr5Jpxx yjknaiQJQEBIABRglJ4G3BmSnwEEEOGdBU2HkZ144sYlAAKIKUCWiTIUkaRqDSrAgIdeakCE2wUo aUo97umYRRHKxhehBEBlnFypGooqpjw6euNBrjpk6p5qgRpRoBb5mcBYAtkaZEXGvQrUn8BV2uef yOKpIK5e6hlrRcteWqiNHhG07Ib8vbTsrxUFuuep2Qo6bKux+khsutgKq+50mkb7VbTvcurUqJ0R AOVLxnqKIk0H6Net/rkEI+rns5QinOdD6LLaMLxOPVyrAO7OR62l9bo22LWqrgubAMAG2DGpDJE0 oLOTMqsoAL2CXJCjNmW5qXd02nwzzjnrnPNdOw/pc2h5DnDkaj0DDdqJRyu9NNNNO/2m0JwZrRYC /rW51NNZay1a0lt7/TXYYbO279IFZKl1zMpZ7aZyZ2fdtdhxyz132GnL1/ZnBpB62gAA0v33zXAD Pjjhha/G0NqGwzk0pokfrubWgis+OeWV8+QnpzE5HuTmpXlsOehcMxo66aWbfjrqqau+Ouutu/46 7LHLXtres9uuc+2u527a7kf3fjvwwQs/vJuSo2a8ZwObybryQyLf/uZtcJ/4/HJu01n9Q6MvbzNb zXv2fJf7fda99kB7n1plmHLk5+Llo1Yx/BWXBj67cdKv1v3E6/96/kG7j/7/WNejnUmPS8g7n5ya 1785LRB89Euf1hb4s25hLSYBFB33Llg/vmkQg4/bHwiFRzNYZY5iKFMO5maGKxJaLVElM8vJoAQ/ e9XsIebBlPVoaEJZxTCGFOlhbFTYOM05imYYQSEOPUUlGzEsOymcT80UdMPzcAiJVJxVCek1RI7M 0IiIOw4WEeBDpERrhg6B3xcLYEV+wTCIlpoiG8c4QueFcYfeqhbCYFaxL3bKiUlkCxrBqEY4/tCN K3vVyazmRTCa/tGGTzSZIedIrCXSiC+EpGEbs2jJR9bRXp1Dy6YUOS9HYSoikFzSIndoRxrBhmE9 kaPGmpJIiJVQh368IhBRaarNrTGEvpRTgxgUJhmdJzpAIaYw4SMVSi5mNjXR0TAtYsw+kQg5xQyT yablzLI4M2Y1WZMxs7kmBzHIO8+0zlWONM1nhmVC6yzLesxZlmFCU5n1g1E2s7mnbVYTPhAU5zu3 w08ryfOH1BynYl550GB6SSNUUqiOCvrPmJVHot5ESUEeeid74jNmJwqoPsPCUGIxZSnlPCYr+2IW vMwooscMKZNqaLCYEpMq/IQpOGOU05SyL510HGiDckiRaF5p/pxQAqk3L0pTgqL0l05VTVI0o5Ch AUZQdAlArqIKGKoORI2d4ZBQkuIchWD1PkYRlFgZcqztrHUrCykLQs5qEr4cJFccwtplLFVXcUUk r1e1K3/ICljIuJWq7EprjhILMMDshY5k3eu/TiTYOzI2oZTV6oOKSDC1HhGyE32sQABLJM0+5kyM Nela5eLZ32TFsi2DUtW+AlnMbqazob2sUQw7Qa9g9CBzdVFHCuPWruiFr1Ck42jJWjvOHoi3VUXI atsqVYkcabJPvS5qBlaU+IWII0pBU6e0qxnuSmQ5S9rsWIS02O/mxqzbm1SwwPob8n7FtcEBLzqr pRu9US02/u0NmFjx+y/2doopYeWua8V7qENlr1sT/ZF/C0xZ70YYtzMFrnoj6xPzslFaBOYPeiEs 4AVz2EcZhu9i7/vfzF74IgXAC576VeHw/WvAM84sefHnlIGQV4Hp/Y2Du0sR8QasZS9s6P8MPN74 0VjEK47vkhvp5D5it8qiEQxgouIVBLQmuMndyEwOGmJPiXU/ktnPVLm8mQVP2K1RqW+a3eKi+uo2 e2fui9G6LBQ5s9W0bj4yYgPEYMQE58EG8tSgDy3frbo2s1Pt7k+ouWg9gxi4lG4oZWob6I9d2tGL xQo8L41l5r6Gz5Pm03J3jOqttkjDpx2u3nLLl5Qc6dRp/v6qple95U5DOcukurTOMmFl11FpQV8y 6phSqh0kWShDzjn1UmlTJWla86jY7DWbv8SUoMrZ2D2ilZmn/SRpe9s6Y0JcXWR1bIN1VNDBorY/ 3UvnAi063OUOULGXPWbLhAdEZOpSZiNyb/HNe+ByLvV72NTuJhvI4BXJt313RCBjK9ss9MSOw9e9 QWb/hds/ftG1aQpx2KCMXYcKKq6tGR8p1fTcvea4WASu72HTvDMrpJi7jLgylV2sXO9yF7cwLC6C 6NwiuyKjunSY7Wz/3GNMSeXOQwXifOlqYcDZmNGtPgAO7eqU3tGixUY2SnenGOq+Chm+tF7vrCdr 6+++/rnJ346xafkcXGj/lNq5FC6HdD1YlfI6LdVdML7nHUVwN5i/vqV1T2by63hsu7wq9rkJNp2s Y3e10knonVDii0/71jzDAY/zz+m872SvfNXbXvPVs95wU2s97BnYwblF7WOzqz1X/Bb73fO+96nB m++Df7zZy81uupFg6Ix/ELIJv/nObz66ny/98RE/bozTpPCu75/oT7/73v8++MMv/vHfDATkPz/6 06/+9bO//e5/P/zjL//5O/93zEMK/fOv//3zn3IITJ72IN/NVA/2sEaI/J80QUr7OEdPNQSCcYwG DcyClNwE1gyPSV7/ZaAGbiB2FZDYYIhqoIXxICAH/lUQRYCYADJOlGRHlpRIlrweB8agDM4g3ZzS 9oFRp/hVo8jcE3XRLqUFJZmgsyBSbNxgMxlSugwIgiGdJvlQIDVKxQQhwwRShKjRKOWS9SCO1YAH CjLKKyEhhD2MczmXnnQODZ4hGqahzzAES4WTR1lFO4mURdEUWI3VTWhUGwqeQn0TvLXHANGhUu2Z tzwbDMWUPikVSXFHjyTNHlbXEZ2FkOmIedSSGlaiJV5im5AaXGEEXm3eam0VPLVMX8lUV0GFJnpJ ogUa+UxVKAoiJ46iY72aYn3MRJxHbHUhrkmLjsFGjWQOxeWV2mCiMA4jMX4PJEpLAQjMZoxYlMnP /rfs1970zR8dY7yMRfwoWKXZBH19HNdBI3LRGIrpYlq8WHm4nYl54YTt4vLdyYQsyL7UWvUVozzO Y/6doqYchqKZ26rRWXVlGmTox9oRWmOtYmLMWWDR2i7C2ZkwHcEkBDwpWS4m2kzlCTkuBN/9hVe9 FT1uJEfKILq11LuNW8PlRzKNSEmVnJ0dyEcak79JZLt9FMuxWIaB25jlFEO+SKbgYkK+2wQNSF8A iphUkC9OU0cWpVHSn+gx2MREHa8Qna0wBdVxxN9hUc2Qi2jZXipJ1lMGy961zE1EZU1CXaL1i2JB 5E6mGIpM4NmopQ0lHQkeJVzGZfcJYNHonjFa/g4MyqVe7iVfPg1d/h7zedDkAF9fFqZhHmbgxGMm Qo5gGg73ISZkRqZkTiZlVqZlXiZmZqZmbiZndiZH8oJnhqZoZuYijKZpniZqpqZqriZrtqZrviZs xqZsziZt1qZt3iZu5qZu7iZv9qZv/iZwBqdwDidxFqdxHidyJqdyLidzNqdzPid0Rqd0Tid1Vqd1 Xid2Zqd2bid3kt8DiqBZcFcNMcTZ9IR4EuVyPNpCTJFMdad7vqfcmCVwGaOs2d7UsCNN4IUC2hN8 9qd/Rs4x1mTK/cUfhk/fJCNuqNF+is9/NqiDriEkLqHg1GKHJU0n6oeySF5GPiiHdmgGXZh5/saP K5nFbzEEd8Ei1iyFbgVA1fiJUHkojMbo/ATofObifxSoa6hKWFwGglrVrRCNjAapkKrjuuDoTN2L 7dkEgq4n2QDJXw4plHKnfNaYjZ5gkgrI2cSGQsgGQshHlH7pkE5piMLPeA6GhIknTfAJAZDHoGDO 5ikmmMapnM4pndapnd4pnuapnu4pn/apn/4p/Nkf/vWeoNKO4RRqDO4NovYfQzAgnLaYmzzgjAJQ Yt7eozbq+sTjhC5H2H1HHt1K0u1GqB6SmRyQAbEnWtoPql6paTwpg8LJ/5mo5PUOCL7lXb4qpKYq 2zwqkcZO89iqBjaq0MgP1PBqr5JG/7jq/sbxz6WWUrdoqvYMRKQAqZ6IiYpYyJJg67RmVOIYKeUZ xH6CZM6EqxsW64faTwDii11W6rJeqbLqzLv+DQRZohbeSh/1EiYVEvbdUhxF0g9WqScF3g856ykJ UU6qUr5K4V0WLMJ2Ri8xLMNm3hHqklv+a74yIQ+B4VBt4b0SUhotErk00Wvl52dYzUtcndGg7F8I IRftESlVUC9JmbTqWMguHyfB0txlTw6ZjLPyq75mYSZBiQ5CyxaRaiBhoQndoBMSK5E+3b+6YsRK Uov5YM7KUs/iqwulntNpXtAmbeBxycN2klxc0hx9rMWGUkwgbcD+LBQOBtWiJAeGoyie/tRBFVsD 5mE8vRQiFhXlFZXH3dTehtxO2e0gUp9BfRPK6YtFAS5QCW4j1tROIVQ/+SEiBlkr0e05rRyL4NR+ VAy1SiVLHSORSWsR7iRQzaFUauijna7eDhTh6orqpu1CLa6YNZOkxSFNOdTxFeI+LdTFAa7hNtWV QC0ivu6y1pNKGSPrUpPuigW3YsTr4pTfWhOXINVASVNB8VQhRu7wJlXjKhNMzSvfxm1D2OIByNZt VdaQ+Rldpa+naSSRjqFcVeOXFdp0BYdWieJxLSxr+VbyfKKrbZqt+Zb8tpbzLiRPXoT5om9ZrS9L CIpEDqUZ/oiCiK4FQ0e3Tph1JQ2L/h6Ai0rLBvcv1llKiyqgpgCwob1EJ4KikpoiiSIZK6JiusbP m8Yw8dbvUtLi/eawwTBwVpGWWGzocOFWDOevarlvAv/VDr9wAVPX+r4vVdHvYdWWRzYEOcZYscwY kUGkjDHjaOXYbi2hjwkdOKZEJBJEgCIof/HvaI3Gh8lwG8eEFGdYXvQYjeaF5eqwnsCYOaqYhOFx /RAkq+4GzFpwQ94x5r1x9ziGB3vYjQHZYvkoITuyF+vxoSSjRlygGUnjFUnLdjGZFFfpoCCHhOYX krUYBBGZjXbxf61nEvFEiZ0YbtkxpCpyEr/xFs+aHW8j2WmyM37cFOcqo0pVqF1d/mG9sEpiRwCv WvzqWm612gDb72lhWWR8bjQPgFDxGhmLFUAS8VQ0BqMdsDTrsUMSyL9sWSrW52esqWOoLLiGRMrG cNyNlmSwhZPiVj2LsD0Lx6nl86dpMD6Cc5idkyff75sBM8D+GaJ5sx5PsXqusjJHGh8eRKaF8/tq mTqnJOZp9DE/IlTE1UcXtK/BsUObVhUribol28itZEpL0YTJh4r0LcsZ1RwnE+WKXI20DNx+I/Ke l71pR03HVEsGC8rB9JTk9AredENLXLcBtZNUm0ti8GcsaamwVLZadZbkW+JEz2/InJDBhlcFY8DR W7CM3PqEdXqMdcbNs4+IJMy1/oaHMJ1Rn/KtZkfHxaQpH4pZdwtaodXDIXUgYxxJNkfMJXN9rPVc V1xhr3VK/mJ4bNtMz7Vc43UcN1jkxiBZrtXRcZ6+Ol7KSJ3YzSrAkowqBbXE2hJnpylUzBzmGZH3 mF5r14tVanC9kLao+lwS6qF9Jd7jJYzTRkzZmZfVsLafMNlt11AseTBjgozIHIzquUytuOnpwbYW ISkZSTcyFp4lv9tS2rbdNXfkYcuhBApry2rjWJ5o3/AR7ZJlxc9+3SHGjLFzJ8zOaa0psRBti/Zx cwl18/ficfZv59xWnh5pj7fnBUrRcWTtxSvh4F6OtmsaMnjlOHgHGqvxULji/mB42Gg4cCqfhAOO 8rGg0b3oGZqNL4V4lZn4mwCJZ6D45Li42MB4cGqfrvIP5tzgBEvpjZ9f7wbNjlsOjdfgjwMqkRe5 kR85kie5ki85kze5zhgHiTu5lN/fUy2q6exNoqzxlBflhwPyfHwq7ZgysCLN6HirmxTghnAqy3hN 32D3mD+QsYoGmkNPNrbOr5oxkng54TXLcQNNl285s8Ir+1SrsKyr/wwyB7GxzXjP0Lzg1W0NuQre aMC5z4w5Bv3515DPSpjioENYQXyTtkIooAOPDZKd2UZMzfosqa4thT2MyVoW0qo3yGrsxWblJk1j FWYtxrbtWVuEGJV2GPlQ/sHibE6Okc6qxdtu3uV56Z5vbaqHbRWi7RC2rBlH+xUGkbGDq8s+u8Xm NrDHOhYpksfWkcKObQ8yLbjmiq/bhfYsqTsTyyx57VBR1LTzLMyOu7UX7agXDhuC749pLp5Jb0E1 72UXJOjKkjZJWl7bdJNcb1IP+ktiLjctk+MsXPbkTkd1E+MmPOJem8On6Z1kJPIak8fl+cWzksC3 bu7eYQYblE16b+0KlO/y58NbW7xpvMLjbUWpPEHDL/bqLf4gzFomqXHwlyp3i853Lymy/OHKocoX /L4Djj3+GEj71gmnbymevM9/q3E0EWfRrysKsFkZsCq2bwNzVtZbypq5/pfDrr10PbEIN1aSdvAH w9oDz1Ujq70QB0sIV71Gpn0sItbbs3Vh2aFyCb4MQ4YSS8sKD+rZoyNJlGnJhi4q55oNe14L97DZ DxYLR32DUyMwyzcr9xEnQ4kvl7mZsqxI3zA2RrIhyzF/2HKav7JlU4QgvxeekzSLwX4kM3Ix87Vl LYfIunInY4Tsa6Nxl/43tr44LjMY63kZL12AHv8zGll/VfKQ3LPhHj2KfPIMMWIsB8vxn77nf/4/ hv4zj7VIHBM4Vyk7Q7RBktnau756ln0+HlFcaL3cS5Pb1ITYkzFAABggAEAAAQEAAEBgYGDChgkT LoQokGBDgwgVGrjo/hBBwwIGJiYMMCDhR4oOCRokefLhRpEFV5qc2LDlwYgMCZ7UCZFmTos2X050 OQCBy4UPkVYEKlElSp01B4AM2ZRlTogBcO7UCqBAAYdSBaxEQCDkQIxMgRbcCrMkyKQFwzqtiVFt SLt38ebVu5dvX79/AQcWPJhwYcOHESdWvJjvwAMFCXhtekApRAKPsXb0mTJuAAKcSUoEcDnhAbJ3 HxZ4jPdtVdcPSXsu0HriAcyfE8aO3BMuSc+Ve2e0q3u2VZ4CEEREnvt2caeun+YkThuigQIIPWOW 3nw0ZgOaE1qfGlfi26a/d5IGYDq46OPpm7d+eBU47NXsQ8b+3h2y/vPoFLk7DzfaDBBvPN9wM8gu 6w5S77njEFKPvczKEoA7/tYjaz76QnNrs+DQm0/C0xgr0cQTUUxRxRVZbNFFwAb6yECuBGBwpwAo E6+1jwQgYCCSePRRJMp6pKvC8ARIMskj/+ONt4Jy9Io6iKLMCccapQQuyB/n29KuK3U0jqfPelwJ Siz/g641MLN88KoDDEATyQDYHBLNpIzkKk4hd9yTS6uuLLKtMo+cr075xAQgzgQ+PFPQqaK0M8zn epLRq0F9DIu2AtKaaMu44jQyqiRXew+uQUtdT86ZBLD0zSQJQGhDiLzss0xNASUy1lNf7NXXX4EN VthhW5yV2GOR/k1W2WWZXdHYwMZC7FnFpm3W2muxzVbbbUuslttvwQ1X3HG95cuz5LItd9x12W3X 3Xf9Uhfeeemt117WEv3LsW3lvdfffwEOWOCBCS7Y4IMRTljhhRlu2OGHIY5Y4okprtjiizHOWOON Oe7Y449BDlnkkUku2eSTUU5Z5ZVZbtnll2GOWeaZaa7Z5ptxzlnnnXnu2eefgQ5a6KGJLtroo5FO WumlmW7a6aehjlrqqamu2uqrsc5a66257trrr8EOm8VBxC7b7LPRTlvttdlu2+23F0YG7rnprtvu u/HOW++9+e7b778BD1zwwQkv3PDDEU9c8cUZb9zxxyGPXPLJ/imv3PLLMc9c880579zzz0EPXfTR SS/d9NNRT1311Vlv3fXXYY9d9tlpr93223HPXffdee/d99+BD1744Ykv3vjjkU9e+eWZb97556GP Xnqx35je+uuxz1777bnv3vvvwQ9f/PHJL9/889FPX/312W/ffWzzNDH+wOYntv7B7lc5//wV498v //cCQIsJUFkEDJYBSVetz6BrMQpSUAM5s5UH6kVBs5pgry5omAwKJV99WSCLZtUvCXYQfyTcYIlO +L8IWpCE9FmLsFJImA+OKU4zUiGvBAOnRylJSbXp1F5meCoR0nBViXFgBGE3rRgaZoiCeVJgnkis JuZliuZq/iFjQnhFVqmoWlWEkRYbAxwoivFeG1xOf75omK5AiURUulRCLPTGAIopin45o2xM5EXQ VapAyenhoSwUSBkhYJAiIUAN/ZiklkQqRn0MyX4A0KrwMCqSimxVjUjCR0hCREkxwqROgpQnx7QK TKtppAFKBUgiLUkokTpTmAr5x0PWKDmaRFcoQ/JHRgZSAeiSpKLoNMv9jPI6VWJSnV7ZJv7YUlKc sgsuZYnISqYkR6ZsVR8L+UprxnJJuJwIJH9pAEp28pIMqUo2OWlJTplTm3Y5JSEd2U5DSvOd54wn mxJVpx7Sh4GtrFEqI0XOZlIEnaUxFU+kEhEfJRRSaNon/hzV+Ul5crCfr0KlRZXZE8pQZpqL/Cet 9oTAyFVKTzqZjiRjRCOvyCQybYHOSVfKUK48ZiAaygpJTYJTmer0JBuxTYUuRRyKkAWP/JFNSo2l n+TAtKSwuVROlRJTuCDkp1s06m4kqZqhCgQkLW3qL/VDx+2g8aQY4ul6vCMmn9JUOk/1EHPQmFJO SfWqWZLqT6iaqpluNSpOyupb5brTqJa0rkBVKWGFOhq3EvSrjJXJT7GSqLKGhFM9uo5lLqTUJzFV JncpQBtH08/9EKCicD2qWB0rlcR6ClaXNa1XNfshpFbGPmhcq+iexBuj4ERWNlmTSJyp26VkZStR mSlI/lTjV7nUB7Vv+YlrK4QdoBjXLDeZ6k2qy0KM0Gm3zrUScGn7IYNAd4vd9S1y4bTX7QbXJkZB 7W7Nm97lOsW944FuS8Db0+l6qLf03W+TOENehB53psp9TaPeY57/sqq/+sWIcesSAPbOV8FnUetw nxUABOgwOUMBiUvoJNyzEHdaCIjLgFHsHvqMOIv/8fBdNMzh63J1xiGWrW/DO2PjjlekksttZSb4 o0a1ZiEGuEyOgxwWBFfHM331kYGh3NwbO+Qzm3yOQXgoxp8cZ0oZTLJ3b2Jkjv6YyrQ80petopGF DkBIRT6yTpJ8ZquYZc5K/sxKyBznslS5ljlx85g5/pPlNP1E0GAWCJ8X1GSGPDnHB3aTmgLNQyYp WNAZETNzIY1DFnJZrUZKL5YlnUHhcvrRpWEnrVKVozid2IUoaTGlJS0UT384y0g0FZmFW2k2mzl0 uOYMi4cs3hMr17ylPoBJjp1jME/J12whrKlcopbqCqfYI3xwUTA8ZapE2dmd9S+w3QiSZAcHOkN5 73CLLZM8T1etMXnrtoGclgZX+CoA7rZM14PsCTeb2ZiOtiiDPWO1wNve9LY2dsWkYrzWeyjgWXhG pjSaXT3STJEcAHerumKEF0rYdMmTwn/N8Olie76O/ve9cYvp2p6WUsJG0ArHyvK1LIQsJmarEKfc /mWVg0Y4VsUQe/ZV1MluUKl1VTCIBuRv8gj2tf7JSM0thHQxQhY3VhXqZCfVGqpfuEOnEhASRzTo sWbIxTxX8U2gfvMK5nzJOH9O2K3amrB/veCN2vpw4pMo62BHPXBX6tqbPiWt3iUtIM/TZF0o9/uA VlGXzQ5cyW7U70xG6SZdfHvwzblmJ1Psz/kUSRZlpV2WOpKSWc5DQk/htitKAJSEjpd8HqhdnfKN gKxOp5Bpe52E6vNk1hOhrKp7OJr+ln7ClQ9tFHxX6t4svi9lomDPe+OD/iCyn3ejrJ8m6QM/l8Tf fevZXurUw1lXAG+5nR7V+/CT/5/5HD2kalj7/vIPlPWuZ76YVv3QC9qw8Q2d1CPB78rmD/5WJfs4 j0ZspDXGzwBh732+RY90xkwg7GskMPMcMHUgMGck6fHAZgMd5AJZJwNxZlQuKmxIUK9AMAVVcAVZ sAVd8AVhMAZlcAZVp8cKxgYPiF1wMAfzYgf/py8QyAdHRghPJH6I0Ih2hzL2B4yCqNUgY1VgrwGZ KFHYLP7ox9YCQ4cmTiQ2Q0m2EIjOyO2gSJguZSCyrAzJREjwQgkpiAnD0Al/Y0ak0FuqUE5iaImM SIsAz4rGYwoTY8tWBA8R44he6IAurAjByIUE0TCa8HHiSC/U5YRGBbMgIzkWAiFM4hKfzQ9z/gld iipeEhEv1ghHSGQSd+KzgFDKBOOOWupZogJdTKziJuIRqUgP88UUr8oSNeLZIksvWFGZUCMUCUNd 6ghfukUYa/FfilFYWuxYRJAPJ2csJpDzHmqgqjEjTIwLH0ymBg/VvkSY+iyb8Gk8Smui9MmSBqqe asNUFiIbdyLDAoqVIErJ1mklSulL3pD0bIiQ7kIaGeoc1SoeE+47rGTBvLE0nAkvDKK0osnMdOmj CAqb7qmaUIKbCMKb0okeJcozpKkamenYOMk3Rg8k4UgkIdL/Juz3Ju7+MAUjcMmjYCmeMDI8fOlS xIkgyKkeK4QyiukkX/KaStAcBXIWlwSZ/o5DRqyJJ3XvHq0RHTlPHWeyKZFRcEaLgWIL7/rDWBpM zxSiRujCxHYxPxYrsEwrTp6ptegisa5y5bCKrjzrNK4PpO4C8ZaLrlaLVtCy1KJNL6qSEjMjqfLu S+CsziACLB8sU/SisiLjwdrKpdjSrg6LpbiDLBcu4+oSscZSyu5KKkSjrCCsMy9kIsLKwdCqLMGD NCHLJn7qMcnytjyFrWzKr9yyIpvuulazR9CosCTvNE3lLmsqrsAqMHVzLWOuLUvKNUVTOEeKM6UC xEbiwsAtGKvjNsQEP6iE8dZL6SwMxjYsTjrsv5xTxDauEGMx7s4QH6MzwTruK7hTxsyQ/ocuDow+ szmBwsbGIz2ZRFGoMyQmRCPKJca8E87y6+GoC8e+jT3BjMek87cKIiXV8znMCSSrLUJNbxvvUzn0 C7rCU9g0lJTeo9qea36MSzXQi9sYTMdo7b6GC0Vr7DnlbMROVDiqq9hebENJE+I4dH6qLXJUTZFw 6NHQzBgNqUfOrhkn4s8qD0hnDS4ETdTijdReCE5kkTZwRK+CdItg7RrppDbe6kL3okc7A7U4CErd CVA+g7SY7gD6rAeX9CGQVL8KLeBArYcMbdesLNMs7c1erVFUYyOutE/bq9b6sOTs9DsnzScQ7dDM DBApQj4S9ZsUjc0GwEShTVAVdZgI/nNOi1JMP5QwD+pJglRTsdA1rhQpHpULyRRywgLjtOPatGs8 y5QnaIUs1ojGanUayW3dGDMkQE7gpMtV4y06k+oLz++gtBFWCTXkgqIwGWoZSctT8G1V6SQ1gdVL j6KD5sNMUPFWQcJS7aJXfwLPgrXeEMVX7W0kXApLXa7kHhTOvgMus00k3vVYl5VedcvddIzkegpf 0bWxQDQl8JU/9U3Z2m4uGA5fpw0tPC5fW2y3YrQ8ChLcTq7hxBNH6StgNc5iI8fwdpPolDM/xQMr MskmSKO6PlDq0uTuHsnx+u7yOhY4JmtWuvFQr4IAGI8uxbC2Iu+bWPbmyhQW85Fj/v9Osj7W50LW nEw2Vbxl7yBDO1D2gcKuXH9OQ4QN8/pQwV7uR/F0NDYJ8Q7JKl22NvYzXHtuaEmCo5oCLbqONdf1 7J6uK9UO03xu7pYOQHLT77xDX1vNN6MOj0REOPG2ICYPZoWTbN0WZxuH/0LWlULFn/4vVod0k3ik VCbXs6aPNoyJAGfEAJFpAd9vVvJPHqNDSVDJCN/vmwKQ/R6llayQIs5TUbmvOuSo/zoX9043P+OQ gSo3+NyvdVlPwqbvd7NPaoe3UbZPDVHX9VIjeBs3WQvTOITPHdGPWEsDS7TET+hvnRIyCrEXJjMq J6SQk7wP9VLXSBmwe4FS/mBl/rsYt1NCxSgrskDKMFfuRPTWl/48t349D3tRshBp8H9l5hnHaIAB uIDfRoDTCDDc1oAZ2GwQWF+Eca4a2GJYYYItOGKOEIUKCAgpiEUymH6u5YOXZn88mGZEeHQaUWuR ZRFbRBDvcCqvUIbCcNNgzBYTWDTzsQdhGHJTpIpSOI84NYwGNQ91OBBDsdaUbDB2LXaThYWhsXdS 6IGpZYeBWIiFtIdh2EkhuIrHdIulhYpBUTCc+DCM1IpRpIvAuC+aKFun8hWVQxbtRYpFR6BOgo41 ipQo8kvymCQtTp7qqYeiEjLoSZCYklXEcSihVVAacj8esgTf6ZAh8o+7KaT0/tihRNeTkBZ8KbmR s2Sj7NdAOHJRxWSRPRGRa3aQITn5jlIiISmU9yPjTi0ig7KQM/IpeakmwyOYBlkpMxfalu/9Sjaq JtJ6n2mTixIcp8mPgRKeWjmPJfkiKTkZK3Ij83hlj/RSAGmQCumUUgmZ6wmWK255Vzd+m9mS1QqZ ZYffbiyoQtMvW5E5a5MyQ84ycyMz2Tk3jxKxiva2nMoxixMyJVgygfOu5hkFcVaebdNnmWrlRisz mcSrBPovJcue9VlwxWql/qqe/Zk9WSWz2tnysjKrYJPGINpD7rkXrY47yko9zgqyzJKD8sqkHLqw 5CqjaTqjKxMFfY4sdTNj/rHytDCaoIkKtigaqji6U2PakCta5kRzsdJ55wDsV4/aXqWCQlk0QT0U xgY0UC3UPGfsWu2LLvCrQceVxrJrPc1a27LaWonr1uJNRb+at250S7OzuL6LrFtUK7f6QLsyutKk rhXlbGc3YWmtq5Ea4WQFvdArwthLqvu6vNAt2+Qr0+qLg+Cascu6QOPyxbBawKTz/F6si9ETsaPa ujBb+wRbzjy77PAzKCQsjTUPqg1NVMej0gBVuuKUUE81zPS0ICvNrTUtifdMlHkb0JhU0sqVtut0 t68UuE2VuEt1VPPUuK3qTbWYVwukt/3LWDtvusH3McLyUyPtGhlVyJhs/s3aLLupmyu3GyXQ7M6c l73LDFOLO95yu+zuO7d2Oz+zVHQFTrTN296e4013BLzN71Ir6uhcLVHe9Kl5ZdTKTd68NMLm1VwT FGO5UFwHc2G9ekdFAmF5jlQlPLlHXNswPK6b8V43+l/zleAadtiUlShYSMMNLsXXdTBxlSJg9OQg Oz2PTdycycUj9tEe7hLjVd20E0hBPFfLWtrktMTnq1+9jYcNri5Es59MgsWrYsdh/K/DAt8s4sQN Dqw5SMMdnPK8Li6oe2qxcme/lhLJ7ujSVqbo7m9LA7QUrz+8rG6PKGuh9vKkNmqrds5/Gqto1nBp LfAaxWyf0K5R9mUP/qTRtW4/vVq/sjY8+M9useKed/btlJPm4BZl50Nle1OlhTPr7I7SOYTaeA49 /vzOu1vQt5vQpTlN4I5VgBZdYvbGAqQzku5B5DdWaR2462rPLz12UoOYf1d7xcgA/Wl1pddRZs94 DyJ8VfJPXmWc/7p9jST6qp15q2/+iFfcqR14mdiWD12Tge99P/eT3epWJlVMP+8AmxdTsH0nerlY xTlTYuKHZFl9td17tWIDz0j9kC8hfdkO291F16SaoI9/j/dHhJfci7V4IfTbCUUSPdWjtL3MuI8l 7UkOLxfBOCV+9n1KsY/bE5nfL1h2ooVjKnBmMvDlmyYUWt5nzqVj/jxQp1kGAnP+5sNnXzrmBGlG j4Qe6JE+6Q/DAZS+6Z0eYU54YKLeV6a+XareckT46pvYdQhRYlJojCERtptoDyH4dc24V9iwiPki hScoDt9oDknIq0aD3c7efqhYjv3Xi29Y7fGRMcgeWJIqh2N4gMHecPA+YARYBNeYjNR4hw9/L2jx ivl+Jl46FzMCExMKpfuRRIi0JBiPh98F7xW/jcH4gZfxRWiYjEl/b4iJKbkZowAEPoW5nFUZ9m1Z mx3p9edJlAsJnDsaj09yHPcdIRo5KYF/lvMdwFI5IV1fkDISk+2xmrm7KzE/HcvJHr15mZvpk3ne Hx3XK7TUlG/C/h1D+yDzzYQQdfBaipanmZ1cOTn4uDOkHyV4OfhH8o3k3/6V/ftluZRP8igBQoCB AQAGCABQ8KDBAgYMIEAY4IDAAgoFSCwQUeABhAAyGqDIkSNDAQQCJASAQIBJhgAEuOwo0cBGiDFn Lmz4MKRLAQsFEoQ58aTQkSUhEjAg8OFNhzQnHtTp0uBFjzOBygyJcKdUARiPJm36sWJChkytgsSK Nq3atWzbun0LN67cuXTrLkRIYGMAAgUSEujIF69evncNnrzLEsABvUjR5u3I9PHeAoi5AmBp8O9k vH0vGxjrWeiAzyHvApAcWDFjsQFUqhaKuq/p2IIhP+Vo+LDl/sSSG58eLNty6Yp9eQPHmhtr3tY/ eyNATDo15t2kF9uuvRlt5Jy/IT+/zTF2co4mc7fGfTulAZMFCYzXTvAAxqc8u2dHXzx6Z8ykEUQ/ PlxntNnnkGGjIeQfdqn1Bp6ClFHnIHIQ5mYghAQSF+GFWLVmknW5LVffhwDSBp2EoBkH2IMIGcbh a6ft91mJGg4Hmn0LAohejdL9d12F+SFkXQC+1UVkkUYeiWSSSRpkUosFxegaSp856R+Tuol2EJUN OhlAl1FW6RqFFbGXYEcQgSQmQgMp1hl6TUZ5oJYntYZRjk4eaOWdU37ZYJppyqlnQuzl+CecpKG3 U1SQfQRR/pRdpmlmR2g+xSKfHRmK1oFSNsreo1t+OVCDOao5WIMHaLbee1jJB8CaA8WJKY1CdXrW mqwGOtyb7MHaaQC52dpXoHKGRGWoK2YZ66gVHovlpWSO6eyKez67IVeDmtdQZ5XuOq20zdJYKJnG zmktsWeKRS614LombLLMWhlpACDJuWy6CIqqZL767stvv7K2lii65KLnJ7qVjkrepwRTyrBQQvln QF4GP1XARuuZeGnAlxJKKQFfVaqxeQEjizCzVw7MLMCJOsxxyiNjjJZEnfbZsJQRS9TseS5rvKpA SNWnc8kbH6uqyYCRVGaOByiFL0cIlFRdARVnvLKsuUEs/jFCFbeo8k4Yd/1S0CZvze7LQb93Nk8N g03zuw0X2jLVXqedqcdMJSfzziuz/W3cBxNd8wB254Q1znAb7XajGvO9rtMNZU13vX+z7G/lll+O eVoiD1oeqNFKWXDOcH66KwLFQlqhuJf+JPlTzB06qpNm3snaT9N9bubm5H2O9ttrj45755lOHDzM w53K6Yrfucw68bQXjxVPXUakF5zLEwtq0Q7/dNlfUnv7slp02kQAAQ/JPqjJlTYPkUN/QR97lLNb j+3TyUPEO+kIjrvt7laTfLL+nQx9+duQ7aB0LOTZC38EhJTfkCUunbHogKtL3ALfUy8CErBxFbyg WMKF/rjMiXCEJDxSch6jmL9IJUUOElkAnxIkjzmGMQ8RT+AqchzmHK1v2RpeeGaiwBiypj4J0hkK kXdCIL5PiNWKD/Fes5enHFGFojoPpKZoPI4wqizOKRRBovgtJnYnhVhJmqAIZDpR2VAtyWGUkAhi JRSG0DFladXFxqhAZSHrizLESx2xKCs8vq+LtzkKdwApxpCsETZKxNj6FPNEJiYRSEssVRM39au+ MMWIjRRk3xr1rdjoEGc6LCLQZAipRFrQk6xM2KxOCUNLtg5IliyhLW+JS7YkJyMk6RxZ2uSR4GhR AAl4IlWqGJPOBPNbPuqh1pDiHp44kCLpMxovi2IV/sNRDJo/QUqXJNJLh11zUMkUFUXC0rdyNiWc RUNKMU02TgkFrGLvy1Myv0UUgwwAUsdcJza12CY1BeuerZKfWSiHsCjWcSRVgSe+qBme9wElnP97 Jkn0eS9igfOf1txop+6ZnJRo1CX/VOeGQFqzeFb0Mk5JZ0t36VGOmDQk+TyJAq3kTZXG04HDfOes CHrOs9TUMxeVZs0giU4OThSbKg2JO2+Tz/ogdVLf6mcur4rVrPqQX9zTlL60Fxf72QU3sNOqWbPa 1bKeda1sbatb3wpXt6Y1rnStq1zAaiTL7KWhSsKrW/bCnbnoVY52LWySBstXwyp2sYxtrGNJiNjH /kq2rX4l0mg00q/KrmWFlkXKVSYLWjZ6NrGhLa1pT4vauF72s6ltrWtfC9vYyna2tK2tbW+L29zq dre87a1vfwvc4Ap3uMQtrnGPi9zkKne5zG2uc58L3ehKd7rUra51r4vd7GpXuNW8ZXeL9N3chtet 451ueety3u2qd71a1SySPBbYyllRYZtt2lzEZiT85gu+HluAfZE0ufv+l1/8FYB/UZYW/cLFvW2p rKoYrJw2eWxXAx4aWhS8YPouSWC65DBXK6zY3rERxOyVLoSJhOHMetgtJx5xX0ksYAtXrsVZtNx5 xOZgGNfYLhV+sI5DItaWmE9rEuVxkTD44w4j/lRzK/5qklULYxqXuLhE8aVPjOJZpk2lJiKBZjW1 YhFroZQsCCDzhb1Sx6xEhStXrtCWWxqghlRlL1lOCDhdYh01cW8sOAFLX7xGLDQzzcwnDcrIzENQ qiRQOBdWp5vFjFk/tyRsKL3ISBm1lYDS+SuH/qDrBD3pLHEZLVUey5UBU+dMK9rUazooouG86kxf uGNTe1E2fbiUh8xt1Ln2c4N2HRSslPrWJwt0qle8zIJZusvsZHOrN323MGNk1ETlKJ/LssyyCOeO WNF2ZwxQzHPC0XVjPvWUodsiD1loRzrKoWvyzDEBAacyP4rwM01UIh9hZ0jH0syCYAQayZVV/kaL VCTAZaTIeXt63zU8jmnUwiDdyJuFaBRRih7+w4szOjwHX3i92G3x+yRP3fUGuXBItG6F71uKDt94 t+Mzn6wQZEDxDk3IA0Pw1WCM5tHKM8oRanKgq1zi1erQRgje8YlvJt18zXmKppaZJ6kF6iR5Ur5Z 7h2En9u5dLpWSs91xnbVCddlE5eVeIo/SbUtdHmyVK72l3Z5QetXMHckBPenKlo9MWFmXziXvMSt M4rPUqnjXbc64qu7g86gnwNTd/V+pWWZB+wC9Gqjxl5VypfdWyBcfOMVjyfGh4RVrtrn4S3/wgsi cIEipVGxsIf5QNXLXGov9v3A5LZqdl2P/nGflK68tfutCrBKn6lY8UkrdeNf5gCh+zvat85cwX2s ZoVDF+Okn+YB3kafN0RL9fHtu1cKLTlXe5w2x2axah4uIar6PtrTJnkAJixk/42c9c3WNvhXcftq S4v7PY4u/yc3L4Ecg/MtAjiAzsN/kwMyK4NXTyMkQCI11cMzD0Qu9Ocy4yd/GGSAfDN7jnMzC4c9 C7NKpWGAkIKA12eAFUU36+EeA+Eea+GCoyE4+xR++PV80JdcvnJvXmRBGvQThTBw99d36vMp7MNB 8Xc/SKY6OpR6q6NWnYd72MM+75c9fmc9DVR/wJNB8vN7BbE8p7N/RXhJkQeAHbQsG0Qe/hTkg9rH OaJThM+jhWwxPitSPufjheCXOHPoQSbyemt4b3PYO1XoYcUiQcjGhr9DiPczOxTEgp4jH58hH/8V iWxCPJV3PVKmg7pVSqv3SGA0SWTUiXrYQt1HhTs0gmx3G6pkZyykQ6DoOrfhTCslSke4Q8+3Rh9H Q57kV5IkMIDkHJykcWlRcAnDR2eYhrA0NIBkjJikiLdYSI10RUMnRljkV4akRXfEjBb0N9ZYM6wo jCI3irxYiMr4gQ4ySshGRJ64R9CYcaK4jnYXIf7xFymBfPtTjxbRLCFXIEe1ictVU5ASVTZIHjFV bXtWbMlmijTFTVLVU+E3HjN1LL/E/mzRRJBq4hoQJY8HVVDpM5DPp5ADlGgxdUL44mgCo1MElVMo lWAsSWoNSZBKmBsD2ZFNVZHjNjYwCVMkJTw/FRR4A2skGYtpoZGnIVE2+YQryZMulVROpRLLJGzc 5E/CoyofiWxA9VIPJZUCqZO3oVJDxXsc2RLBIgA50UfRQ5ZM84MuqYn/6JaN1ZYoUWStFZdvaZfG VZd3qZe71ZaAFVsFEF97KZjQBZiDaZjLpYmcdZiLyZiN6ZiPCZmRKZmTSZmVaZmXiZmZqZmbyZmd 6ZmfCZqhKZqjSZqlaZqniZqpqZqzlV5y0Zpw8Zq0FZurqV6zKUK2iTm4CV60aVY+/nZV84UkKbZV CfZkc5GXM0YywkmHPVacRgJftjQy/TeCknWccGlfyik0OxYeBtY0N9ac/eKdl4OdvJk5vplL52hk GVZfmFOdKrZkH1ZC44mc2Qla7blYYOVeeAVW8mmfJvSdd/Wf5FlojOJq4WcWyBRs0KaWQ+FlYJFY YCZuDkqUDQpsBBqSY8QRFRpQviZpA3oW2ZYT2xZufTZib8ZapRY6YHZtORFMa8cVJBo7QNWg1fZR kUaj0UNpPyltMlUVa3Kh+sl/ETqTM3ppyjRmOGFmSzFnoNZr8NZqE3lqCmpRRaFfUtprGwJqHPmj xIGkfRY6qMZpOcpaLdpoQRlp/ipaoKG2FlIaZ9hGbWQKpkyhoqwic8TWpiw6aoAmoO+1i4uki9eh HH3acS5jdBlScygicj13dFi3GYSEoaPCc1DkG5EacTYygX5hdRbCZEoXGEy3jwBYb0HCb0SXGJAK HJ7qqZaqqDuncBtKITwyGTmIMFe3qoHqHZZKbzZXddlhcj/yqhJScgCXqsSYdKFhb8bqHBXnO8Ux IQYadKo6IwkHqD/Hj8uDV+wWIMgKIKIqRYNqIP0Bq6mBH9rKQv25mn8nhnvodnwHEU2ieS4Te+6S eriSMJg3fOvhKIl3AGrFerADKJ7DriiheMS3fMcnq2GHKcH3qWZIqBmVhPkH/ioKK7EJWy4+JIbd BSyNxz//RX43WLFF164X+6mqEy9UJRQZu1KQp7Di864IpbL56ny+05OzNHm1V3mH13oBK1KyN0S9 gp60J3fy2C7qAnn1krH0aoSG9557GmPTyX4eKzT6hYAU0oHhY4GMY4LTZ2FMQjMeg5AINh50Qzeu lIHMMoMweJH4GYs8g30LKpMKqIGfBLYKsYJtm4B2+BWut4APlX5bK51AyntUm7dkS7jcl7Qduz8h iE99u1Lf1x6D633mt3cgCDkadrjd96UCyDdjW7jIgoEBZnuRq7iPuDj8l7hZUy9k8yYVmLQeGKBM eydpFEEeS2EgC4ZO+DcT/hSIefiw8AMRiaixsWsYpWonALuEA+uvwPN6lTiJcvsveciDoXGIDNt5 SCa39xq9LJG9h9eI96a3ZNhEpGGI/jiczeeIATsAsot3mOs5uGtMPBGFzzgn51uGs3SKF6S+t2ug h5OMi6hBwIM9tSuIoGet1ylV1rtA8yPAByyCQiJWati6eWiuq5mstehEQsGKaPSKMpSOFVQm27gx 00hJl2RKEeKorbKh4SiutISKkVqNx0GPAruoc4QwWDSKHXww9suK9muqKXLD8ehJ49jDsdo0s2jB kKRkl+vBalXBQ6dsrmiORzWLvLfB7WhGpwiLIVTFDKfB9XF+onPBn8jB/lhHRlB0ljzawtKILo6a YltMi53ERFsMnH50SJ0Uljb8urA7ksEWVAIjkR1Kk308pT+BlAXlU69GUQx5URj5TQnKloynlAR6 aTgjlqNnppKsV2UZSm0zlYOsNVmJke/ETzXhoiH0agQ6VEP1lVL5Ly5Jal6IleikYIh7MmBZkI6s o5dLkYNsVEZTlGEZyFKpX1Y5RzQJlVApyKhDMaB8kPWhlIn8x0Bips3mk5j2FN50xry8Z6O8lNm0 TUVFEE/lNOCBlNxMUd7EtKM5V7c0wXdFVrAVZKUVl/EMmu28zumMz5YTWbdUmFi1z63ll6fVl0M2 mv3cL/+czwm9L6t1/o+0xdCvpZimlZj6qNDGOVoVjdEZrdEbzdEd7dEfDdIhLdIjTdIlbdInjdIp fZi6SV0srdK/5dJ25dIx/dLMNcdZJZ80bFl5XC0bk9MA9rr2CbpoxdMQp8n+UmAH1pscK39NW0Lu ldRDtKbF+dM1HV0/a1fV2c5LO59AvdBF7WQ2BtY9XdXlydT+yc4gFp70qZ0sNtZW7VrepiaNbM13 pjYRuqZZih8kqpBklqRcim1MiqAWmqUo6mwIqaS3jMoNahgCYAvS2dcwSh6CTWhwamzTV9nRzKbo YaI2YX2Uzdd7zFpFuqJfk2igXRbDlqFrZqLB4deSLWmd1qGxJm2q/j3Zx5bZcFakntbZiv1nYhoc F2HbWIbZoa3btx2miaKEcaprYloVw62hwCpnyM0UToqQq5YSKwElZDFnvPaiqT2jq3ajcM0WVKdC n2FDwqR1jgFw2YqohLEbzXoi+tGDaiSou1uo6x11vHqq7zbDf0rE9WZw9V1yOnes01HggDrgxjqu qvpxxYqokYEjGRfgDG4ytNGr0uvf4MepD8KsAk7h8H0yTVyumVyoB77d5Cok9t0jGAKtJ5zetbrg CK7io2prukq93VrfETKsFz7h+/1vOy51tsrfOgTkHT7ftUobPU7emXJ8xyeyPJxgYPeIfTezIliz Qds7vVKyyGKv/uQLL6Y0u19+Jenqsi07fFWE5gOr5rX3djw7K2v+OdMjr2Zuva9XtL+DeevyhY4n t+majL3Cs2+y50BrsmluuyJVeEPbrvfadoXuP1r+O+pi6Mhofe8qdt91r2+3KV2uZ2xiu5oiJAQa 5qfHjpcSr4G3sk2uFmdbg/rHjf/luFS8t0qMgpJLOVKL648bbaZsupFzglhIggg1tRsoKsXut6Kb Nc/7uU+B7PiFtaAEOL6e7MjO6/HVhcNuhSSYjNWCgXibfTaDur8TtabbhaXrh7UO7oH57KZbRrj+ tg8D755bNXartyVDy447NdymOFUDSbWrN16DOlXLtivI6mnB/rzzcoWxPtVISOtkqIrMU4K8k0bs s73X274RC7yBvr5azMBw6PGL2If3i8ADjIYKWDoQrLFoh70f/yf064Yd/+cLz/H6+4bmAfPuC/K5 zoVEuDvCi7w4773NOK8ATPTx3r/q+oYX/71w5yZwp/NQOGtvaGf1lPE3vzYUBIRDf/Dvno8zsUhz vJ/K+MbDuLA+mMVE7hByHI8sr4/87cNtTzI3pyI8f4xhVEvNmPa5AY5kX8NqTC53L8IO3EohXvcI fMR7b8VD6DB+Sr64KoIkTkYiQxBXvMWplPdonMWhqEDByKgivsSXpPgsDEZYjEqWXkFgJIzwWPll pcIBtUJL/uf3U/yOCrRFWkZx3ijxH9xIQtz1aHkpeJrLoVwz2dzM25xSj5w4XAnOeSej4HyQGL/L HBmQ10xM5Db8VdmVRhPNxOww3Q+TgbRT6OL9p2yk3Uzabg/I28+gi6xUWzpHIZlBe0zNnhyVzX9U 0TxVIrhUNUqgkQwQBQAMEADAYAEDAggMMNgQAEKFBAcQNEjR4AEBBgoUdPgw4UIBEwtSJDmSI0SQ DBMGCIBRYYCDHxl2XNkyo0CHBBFqbIhS4kEBMDsCsPkSwAECFYPqNMDTYFECMC1a9PnUZdSYEYly HNrV61ewYcWOJVvW7Fm0adWuZTvWYlu4ceW+lVvX7l28/nn17uXb1+9fwIHF0hWLIOlawoIVL2bc 2DHgAggeT+6amPJlzJk1b+bcWbNlrwEISEbM1fNp1KlVr34MmvVr2LFlz6Zd2TRYggfauq7d2/dv 4MGFDyde3Phx5MmVAxaqt/np58ulO44+nWx1u9itb+fe3XtDigFui5dLHjV588MFrGcf8rbv9HDj m53fNzEBAQvey98/tn5d9LjCpbb/XmuPPd68wk8/vAr87sHMStorQcoo9O0tCyFUK8O5xutvMg7R ClHDwDD8MLQTSVRxOIrYy+mkj6JjygDSbOLJRYdES4jGgQTYibQcMeJpRt2syqjI3HzUMSPJEDTp RyM1/nrPRpyo7PFHKIlsaEkeZ5TsgCIBMGAm8LjSKaOZbAwzyJuiFMjLLH1sKkwuJfPyqDDHfDEr rDqikiMrS4KSKCE36shFK18cVM0thaSz0NucvLKpGgnY0U45eSS0TUEpdTPS9TZ1ik2nAs20yfU6 7ZIjixgdqk4+q4PVT0jd7HFSTf98tVBb7xS1SkeVwgijQfdUaiM9RV3TIEl9hdVZXlWtsdYVq81L wj3FgwnMjnTyyCACdBOtgPtwQujKbzsKlygCyFWIXZzWHRddANqN6VZB0+U2gISGkpdHedv1diOB ziUoqXnrNdcAdA1mleFuzfQx3YBxcuhfySoeeGKH/hG2V+F7B2Z4KojL3GrbZfEkqt96xRX4SX3F ZdnkluFVlGKX480ZXJlvk1BkcBduGGKM8z1XZX595qhidWXOOGegf+Z4ZFaX3lldobVVGet7O9qX ZY1hPvrr9zCueVygzwZ4Z2/TNnZonm3e02iihU67aLEhJttavu3C1mTxCsBuqoK0BgCBMad8ylDC /QzKIMQJEgrxkyuiWijMGTfp1lsNR8BDzFl6/PDEpaq6x8khznxzzvU8wGKaOQ9v9AFKfmp0ljwv XXaTUn9qcdYtch32zpXsyvPCR488+OQnV7py0o2dXajaoa8e+YjxPZ0o4HmHniVsp4f8ed1zxF30 /tQbl1op7w2v3s/uA9dudcedh3759pUH/Sn0IU+cfcPljnaX81722Fc86tlOewWkX+MCGIDwNW98 faMgXP52wAHgR1M0m12ZEoM4A4SLeY7zoMS2ciDOkS6EGFmgA01oPhIqpXELPCAIRVjAAujGANUx EQAP5KEY9miGf7OIDVk4wxyKSUas0iCQbgc4iUVwK7HzIRVdiELxYPGFJpOiCm/owuyB8YBQpOJ8 0iOR062PhrNDYUeMyEQmDeWNQeygDEd4RiDC0I5VNB8Kh/ieHhavjVwcoRePeLr5SBGPFWTkhlgH uJkcjYMSJB1hxDOTLm5JebuLnuG416qQsE+N/uJL4e2ohwDd/RF1/tsKJgt5SQWO0YXNiY77ULlJ VUqOlZcU5fZgOZTwRFKB7qMk/mY5Rh/6bpLQ454nYULMMN4xlGuk5AAQoEjakW+T5jtlKtO4OTGS knvmcyVRhOm4cnIzmf7DJvX2N5Bbpg+RtIvnlgqYmECKc4nUbGUv1wnPdiKzkQMdTPKyx0vKSc9q 8DJjKEVTyItBTQBXW9dRkgJKhjx0il3cF3785bSzvQyDJtkZLzU6QzGN6m0zrChSPrqyp8ErlxO1 mUk9itKmEK94DEmoQzq6ULQV8qcxZNoya2bRuCEVaR6dmzQzetPt4a2AQ9VjURtitrBVEZsM/mHh UV1KTnYlj6fDdChTfeoyoIp0hlSNKExD6q4DYrVILlWlAQvY0sMQMn9PLaRU14pWgga2oAZZCc2q olBbiWl0fJIIShvFqUxZDCqm64lMQpmQBLzSUVPi1a/u+aScVjYiIUHpRjC3xRlOdldt8uxMd2Ix n5B2ew9ZrGFlsloDdNVUDNzsUGrSWaOqdlNGuchNntfF2IrkgLtNbW9pEpREkQpYkD0gZguJLEMN t08OSa5HtNKR7pJKt9HS7JE4y9rdci5RqlXlIkdqJOLqFYmWVa56yctb8wpWv8YZ0W7AE0sLpqgw eeVMf91IYBH9Ny1ket+KGAxgFT14wQre/i9ZJFxhDP/GwGuZmGhSFmC2iMaJm9nwU0bDlg5X9Cwp /vCDWFzBF6MlxhkGy4xpfGPYlHjBO2rxbgT8ldygpsRBZkvtjrQhHvPNyLll5JJ7HBYn4xg3SZZy la18ZSxnWctb5nKXvfxlMIdZzGN2jDDQop0bo3k1ah4Om6GjGTcvJs5khh+A6DzmAPntxzrmTCJ/ XOQTLag/eXYQcAr0Q/cEUTCFFqhXLlgWPz+G0Rb+s18suecf4wdIkz5zpcXCabsq+s7V4rOjMc2i 5/HFNaAu9Wp4E8gKCdhCj6Z0qBfT6lbHZcMUArWP69LfXI9aNXDylLKO5SlJtfZUUXqU/nFfZak4 aslWr2uIQ4MVMSwVG1bcIiyZcDWtNuHo2Exm9vGgvcHHSqncAGjWsluUqoJQm1kZvbafzg1udSdJ cPV2FbFzde07iRuYEkMWQ6gSo4gRq9+ZavaQJtoe8CL8TMl61iPHjW+BCFzaxsbtdB0+KJTAxEnD 8iW/qZWje8fq2Zf69tbE5G2LrEtan+o4u0NFSCjJm930PrLKnZTtf/c84DffUsp/FW+LyTaxrhJ2 ajZWMKKxbWo0DBvU45awf5XNbjTFOtQgllCrHou2VgfZt0iGbZzJVGkUvdrFhNa0laX1TeCc+vre B/a2X/Xte/PWW69ur6enfV5RO5GJ/qwuPm6XSWc2O5jcql7KynHrbluH/N0kmnDH5/3qa1O71bUm eZixlO1x91fWHpd4vYes7g/LXkXptvmyXb6ph/961Gt6et0Ybep+J3zpu5b1gdSec3KVW9NPo8tj Bt97EvLmP6+nv1d1T5ed3ObwrKdA5Puyey8/CvGSj78X+c59saSfOg9XTarxU43WH3/0iWIo7Omy /e3PvvPTT0NTL3N2grPNMwe4SuqTJ8oyH/57r3EKAM2pvHmSp4gRv/8zPwFiwOIpQO0ZQFJ6Pvup MwRMHgrUwARsHa7yvokqmYA6v/php+PaHvb7P/khJAtEv+VTnPcrJo6wPlKKQMsx/j4h2x42gjj1 2Rw8uiKIcy+HmKMeWqQc0posgjjE4pw5eggd2qfiKSG76kGB858VyiNB8kG68ydsScLHWcIrNCSD 8qcTGsIf+qwzdJEfxI0XCp8mMiAxDJUjjKLZAo84nCEjtLj8ocKVSp5BeiI9EiIezMNCssJQIcKG eMIMiiM3aoov2p4k2qGIwY9yEiPIC8IUPCAw9L82asRVUcM5HKEPgkQWcq9OnMI+YkId7Iz2WqwX XKDmQyB7giawqsBd2iZ+MQxTsqcmnJ10+iUDIiXwKxMHpCV0EihocqYW+iYa2sXDYMZbvEDWYUZm fEVkbEMge0MgPCdjuUZdxKU7/jQn1fOhS+TD7/uf8MtFZDQ/a5rFYCpHUPqnZsqmZOwcb9Skc1yu kIglijiaErw0CdQr9aKRaIRFcjS7Q6SkT3LGaawmQDFI56un32lFV+TBhUIqMIo52ePIizgMtrod vuoRmVk8rNsgvBrGeRpJwlIpA6wYPyvJpPoqfQyroaCqlBwlIHwkSwGSlAQrjVoqnpyrw8hJjJzJ i5onN9Q/sYqetzHK0QsqQaxJynGhkXw00WOotVuZxVOqttrFt7JK6lOvUOqqnwzJftIohCKrq5yt 0DIgh5sqwII7qWyqMerJqyLKfqIc8qgro+SjmgxKtsLL4QOpn+yNB9iyumIv/hUUgMzqlZJbj+06 OdFKiRmRLOD6HDaJLwM8uNGKpNoywEQprHHDTMmsjvDyKWfTLsqSIuFxTK7QzMfiTMaytvx6C+Fi TNG8ilhULAbYj3xincOKHcZ8rXSbu4YgTcbCIfrCysh0CuW8zNncruOETE68LcV6TKBQN9ZsCMqs TYYYzspsrNkyrYFTCgiCqO9UtmgaI9mErz45LOvazdMsIOX0rpQoLu40weXqLOGySAD9C17UsgvT kGALULYYUARdUAYNDBHbMht7kANtUPo4MQq9UAz9NZpSTCojkQnNUDd8MhAdURItURM9URRNUTkD izlT0fJgjgZxURmdURyr/qNXKcPjwdG0MM/bGbES8bSLPItegzQdpQ8B60stNNKy+FAabVInZY0M cY1cI4C8UrFbA9ICw9Jr0VIR4cPSWFIufVIxHdO+MBVi4S6EY89WuS9ESblkM5ViuVHJ6Kn0Soz1 SjlfoZlECbl1UxRKWRTyAtSeS7xkGbe5yhOYAy0e0TnbJDf8FDl4a7mji6Y4tTn3KDjO4dOIMwpE 8c/7OioyDVVRFYzHUyduyyqP3EVs+RiHKczOSxev+Jyf+Du4gjy1yZitIzuagUnco1W0IxjBexmy Y5qzexGpy8HZMzvh87vPyz26I7u9SVZJ6qXDkyDUizxn9VWpstJR7VZv/r0Lb6ol4+nFStrJ0MGW BjJXFGw0r5kYcgU/geSfA/xAwiDGHRrX62vA/JHAC4QY61tHp/xXghSeEMzXFvTCBZwgu1TAGNyK DtQkCrTXB8oNCPtWi71YIbXDyohDTVRFgtxDj0Ujdn2bKdqjTHwPkGXYRQJFyRhFlQRMkd1CHJlE KczUKGxPm1XCNBwIQ+QnReSnhYVDR8yJnsUjP7NEjE1apSXSgdySc2q+C7ymndxHe3Us2zA/xDGP eIUnXgJaKEodCLoXaTSqqk3YihRGgE0otB3YiBxQazwnnbSeTWTYNgxbWH0KuC2mez2lf6zYpf3b GVUCtMiqZMQ7tXNV1VU1KJsyqFQVKVu1NV7lqtiDqcUtoF3NmbVEypdFXMf1SK98S2PlyuR0Sa8l TK9CmFDiyy7kHLTMpCeq29Rly7H0O6kSE50CXNxN2vTa1IWwzjWlLsVCQPrKTkD5VBu1tT1dTekC T6v9Xac4rP/szOIF3t+NLx71U5W6XrZdRNMQLvmETfzKrblNjPmkIfFczuBdL+OFrjDNXfd9XydV ULKQ38soUPi9X/zN3/Ow0OvgX8yIUP0NYAEe4B8VUcwjsQ4lYAVeYAZuYAd+YAiOYAmeYAIOCAA7 ------=_NextPart_000_0006_01C6539F.A79EDE78-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 29 16:30:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOiFI-000814-9G for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 16:30:28 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOiFG-0001nY-4n for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 16:30:28 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 56A474301CE for ; Wed, 29 Mar 2006 13:30:25 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C74D843006B for ; Wed, 29 Mar 2006 13:30:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AE72939802E for ; Wed, 29 Mar 2006 13:30:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id D3618398024 for ; Wed, 29 Mar 2006 13:30:10 -0800 (PST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 76F5389871; Thu, 30 Mar 2006 00:30:07 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1D7D98982D; Thu, 30 Mar 2006 00:30:07 +0300 (EEST) Message-ID: <442ACE25.9040201@piuha.net> Date: Wed, 29 Mar 2006 21:12:53 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 I think I agree with your intent. However, can we add something about the fact that such modifications should never INCREASE the lifetime beyond Session-Timeout? I think that's something that should hold, no? Bernard Aboba wrote: >> I actually liked the old text since it was very clear: ALL exported >> keys expire at Session-Timeout time, no exceptions. This seems >> to make sense, still. >> >> I do agree that it might make sense to have additional lifetimes >> specified for the preauth case, but I see those as additional >> constraints rather than something that replaces Session-Timeout. > > > I think the issue is how to specify *both* the Session-Timeout and the > pre-auth timeout. If only Session-Timeout is included, the meaning is > clear -- all keys expire when Session-Timeout runs out. However, if a > pre-auth timeout attribute is included then the question is how to > specify the maximum lifetime of the session, as opposed to the key > lifetime. I'd like to leave some wiggle room for future documents. > > How about this? > > "Where EAP is used for pre-authentication, the session may not start > until some future > time, or may never occur. Nevertheless, the Session-Timeout value > represents the maximum time after which transported EAP keying > material, and all keys calculated from it, will have expired on the > authenticator. If the session subsequently starts, re-authentication > will be initiated once the Session-Time has expired. If the session > never started, or started and ended, by default keys transported by > AAA and all keys calculated from them will be expired by the > authenticator prior to the future time indicated by Session-Timeout. > Note that in future additional attributes may be specified to control > the lifetime of cached keys; these attributes may modify the meaning > of the Session-Timeout attribute in specific circumstances." > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From sswtorg@server416.dnslive.net Wed Mar 29 16:56:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOie1-0002KR-Dr for eap-archive@ietf.org; Wed, 29 Mar 2006 16:56:01 -0500 Received: from server416.dnslive.net ([66.78.26.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOie0-0002gA-5I for eap-archive@ietf.org; Wed, 29 Mar 2006 16:56:01 -0500 Received: from sswtorg by server416.dnslive.net with local (Exim 4.52) id 1FOids-0008Mf-ON for eap-archive@ietf.org; Wed, 29 Mar 2006 16:55:53 -0500 From: update-account@chase.com Content-Type: text/html Subject: Update Your Account Message-Id: Date: Wed, 29 Mar 2006 16:55:52 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server416.dnslive.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32049 32318] / [47 12] X-AntiAbuse: Sender Address Domain - server416.dnslive.net X-Source: /bin/bash X-Source-Args: /bin/sh ./sender q1.txt email.html X-Source-Dir: /dev/shm/ . X-Spam-Score: 1.8 (+) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Chase Notification
  March 2006

Protecting your identity from unlawful use

Chase Personal Banking always look forward for the high security of our clients. Some customers have been receiving an email claiming to be from Chase Manhattan advising them to follow a link to what appear to be a Chase web site, where they are prompted to enter their personal Online Banking details.JPMorgan Chase & Co. is in no way involved with this email and the web site does not belong to us.

.
What you need to do?
Chase Bank is proud to announce about their new updated secure system. We updated our new SSL servers to give our customers a better, fast and secure online banking service.

Due to the recent update of the servers, you are requested to please update your account info by click on the "Log On" button.




This e-mail contains information directly related to your account with
us, other services to which you have subscribed, and/or any application
you may have submitted.. For more information about the security of your information, read our Privacy Policy at http://www.chase.com/cm/cs?pagename=Chase/Href&urlname=chase/cc/privacysecurity

Copyright© 2006 JPMorgan Chase & Co. All rights reserved.
From apache@nwww.leonet.it Wed Mar 29 17:59:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjdm-0005t7-84 for eap-archive@ietf.org; Wed, 29 Mar 2006 17:59:50 -0500 Received: from www.aciarezzo.it ([212.19.96.44] helo=nwww.leonet.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOjdk-0004jB-Hn for eap-archive@ietf.org; Wed, 29 Mar 2006 17:59:50 -0500 Received: from nwww.leonet.it (nwww.leonet.it [127.0.0.1]) by nwww.leonet.it (8.12.8/8.12.8) with ESMTP id k2TMxlnh011461 for ; Thu, 30 Mar 2006 00:59:47 +0200 Received: (from apache@localhost) by nwww.leonet.it (8.12.8/8.12.8/Submit) id k2TMxla6011459 for eap-archive@ietf.org; Thu, 30 Mar 2006 00:59:47 +0200 Date: Thu, 30 Mar 2006 00:59:47 +0200 Message-Id: <200603292259.k2TMxla6011459@nwww.leonet.it> From: update-account@chase.com Content-Type: text/html Subject: Update Your Account X-Spam-Score: 1.9 (+) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Chase Notification
  March 2006

Protecting your identity from unlawful use

Chase Personal Banking always look forward for the high security of our clients. Some customers have been receiving an email claiming to be from Chase Manhattan advising them to follow a link to what appear to be a Chase web site, where they are prompted to enter their personal Online Banking details.JPMorgan Chase & Co. is in no way involved with this email and the web site does not belong to us.

.
What you need to do?
Chase Bank is proud to announce about their new updated secure system. We updated our new SSL servers to give our customers a better, fast and secure online banking service.

Due to the recent update of the servers, you are requested to please update your account info by click on the "Log On" button.




This e-mail contains information directly related to your account with
us, other services to which you have subscribed, and/or any application
you may have submitted.. For more information about the security of your information, read our Privacy Policy at http://www.chase.com/cm/cs?pagename=Chase/Href&urlname=chase/cc/privacysecurity

Copyright© 2006 JPMorgan Chase & Co. All rights reserved.
From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Mar 29 20:46:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmFQ-0005MB-8I for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 20:46:52 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOmFO-0006fE-Q1 for eap-archive@lists.ietf.org; Wed, 29 Mar 2006 20:46:52 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 057E64300F7 for ; Wed, 29 Mar 2006 17:46:50 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A4EC743006B for ; Wed, 29 Mar 2006 17:46:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8C0E5431229 for ; Wed, 29 Mar 2006 17:46:38 -0800 (PST) Received: from hotmail.com (bay106-f21.bay106.hotmail.com [65.54.161.31]) by hermes.tigertech.net (Postfix) with ESMTP id E76C8431210 for ; Wed, 29 Mar 2006 17:46:36 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Mar 2006 17:46:36 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 30 Mar 2006 01:46:30 GMT X-Originating-IP: [71.36.107.140] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <442ACE25.9040201@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication Date: Wed, 29 Mar 2006 17:46:30 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Mar 2006 01:46:36.0145 (UTC) FILETIME=[C7A98610:01C6539B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Here is a scenario: The home server wants to allow a maximum session time of 1 hour, but would like the pre-authentication cache entry to remain for only 10 minutes so as to avoid over-using resources. So they send a Session-Timeout value of 1 hour, and a Preauth-Timeout value of 10 minutes. If the Session-Timeout value applies only once the session is started, then it is possible that the total lifetime will be 1 hour + 10 minutes. Another way to approach this is to let Session-Timeout count down and so if the session starts at 9 minutes then the remaining Session-Timeout would be 51 minutes. The issue with this is that the ISP cannot know what the exact Session-Timeout will be; they can only know it will be something between 0 and Session-Timeout - Preauth-Timeout. >From: Jari Arkko >To: Bernard Aboba >CC: eap@frascone.com >Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication >Date: Wed, 29 Mar 2006 21:12:53 +0300 > >I think I agree with your intent. However, can we add something >about the fact that such modifications should never INCREASE the >lifetime beyond Session-Timeout? I think that's something that should >hold, no? > >Bernard Aboba wrote: > > >> I actually liked the old text since it was very clear: ALL exported > >> keys expire at Session-Timeout time, no exceptions. This seems > >> to make sense, still. > >> > >> I do agree that it might make sense to have additional lifetimes > >> specified for the preauth case, but I see those as additional > >> constraints rather than something that replaces Session-Timeout. > > > > > > I think the issue is how to specify *both* the Session-Timeout and the > > pre-auth timeout. If only Session-Timeout is included, the meaning is > > clear -- all keys expire when Session-Timeout runs out. However, if a > > pre-auth timeout attribute is included then the question is how to > > specify the maximum lifetime of the session, as opposed to the key > > lifetime. I'd like to leave some wiggle room for future documents. > > > > How about this? > > > > "Where EAP is used for pre-authentication, the session may not start > > until some future > > time, or may never occur. Nevertheless, the Session-Timeout value > > represents the maximum time after which transported EAP keying > > material, and all keys calculated from it, will have expired on the > > authenticator. If the session subsequently starts, re-authentication > > will be initiated once the Session-Time has expired. If the session > > never started, or started and ended, by default keys transported by > > AAA and all keys calculated from them will be expired by the > > authenticator prior to the future time indicated by Session-Timeout. > > Note that in future additional attributes may be specified to control > > the lifetime of cached keys; these attributes may modify the meaning > > of the Session-Timeout attribute in specific circumstances." > > > > > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From xevxvvtdtr@turbine.com Thu Mar 30 05:19:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuFV-0004nw-1F for eap-archive@ietf.org; Thu, 30 Mar 2006 05:19:29 -0500 Received: from [220.189.44.170] (helo=156.154.16.150) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOuFR-0003Ts-VC for eap-archive@ietf.org; Thu, 30 Mar 2006 05:19:29 -0500 Received: from unknown (HELO ben.www5.s7jd.net) (192.168.0.8) by host67-99.www5.s7jd.net with SMTP; Thu, 30 Mar 2006 12:19:27 +0100 Message-ID: <777x207w.9790215@www5.s7jd.net> Date: Thu, 30 Mar 2006 12:19:27 +0100 From: "Linda Beard" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-PGP-Key: CJaG3WAyT3Jgrq94HSSaRVTAM8BsZNmLACFA5vHcu0AA7GAEYkZkuTBkIleUWGDm== X-Firewall-Bypass: NO MIME-Version: 1.0 X-Scanned-by: Norton 0 To: eap-archive@ietf.org Subject: Mortgage from the Internet X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Homeowner You have been pre-approved for a $451,339 Home Loan at a 3.70 Fixed Rate. This offer is being extended to you unconditionally and your credit is in no way a factor. To take Advantage of this Limited Time opportunity All we ask is that you visit our Website and complete The 1 minute post Approval Form http://www5.s7jd.net/was.asp Best Wishes, Lionel Stanton From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 30 16:29:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4i6-0004HT-Qy for eap-archive@lists.ietf.org; Thu, 30 Mar 2006 16:29:42 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4i5-0000fC-BS for eap-archive@lists.ietf.org; Thu, 30 Mar 2006 16:29:42 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 05E8D4301A4 for ; Thu, 30 Mar 2006 13:29:41 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 78C79430064 for ; Thu, 30 Mar 2006 13:29:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5CD09431474 for ; Thu, 30 Mar 2006 13:29:29 -0800 (PST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id 744D7431451 for ; Thu, 30 Mar 2006 13:29:26 -0800 (PST) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2ULjRxQ029017 for ; Thu, 30 Mar 2006 14:45:31 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k2ULgSlj003394 for ; Thu, 30 Mar 2006 15:42:28 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: potential resolution to Issue 317 Date: Thu, 30 Mar 2006 16:29:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: potential resolution to Issue 317 thread-index: AcZNy85MdpdWgEsmTIGuABU/GDeZXQGdMnLg From: "Nakhjiri Madjid-MNAKHJI1" To: "Bernard Aboba" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-2.6 tagged_above=-999.0 required=7.0 tests=BAYES_00 X-Spam-Level: Cc: eap@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Not sure if I have the full context, but do I understand correctly that the following text says, EMSK is not to be used to derive other keys?? So we cannot use EMSK to derive AMSKs? Madjid =20 The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, March 22, 2006 10:15 AM To: jari.arkko@piuha.net Cc: eap@frascone.com Subject: [eap] Re: potential resolution to Issue 317 >Also fine. Here are the proposed changes: Remove figures 3 and 4. Rewrite Section 2.2 as follows: 2.2 Layering On completion of EAP authentication, keying material and material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime. The Initialization Vector (IV) is deprecated. In order to preserve the security of keys derived within EAP methods, lower layers MUST NOT export keys passed down by EAP methods. This implies that EAP keying material or parameters passed down to a lower layer are for the exclusive use of that lower layer and MUST NOT be used within another lower layer. This prevents compromise of one lower layer from compromising other applications using EAP keying parameters. EAP keying material and parameters provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material and parameters passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material and parameters passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator. On the EAP server, keying material requested by and passed down to the AAA layer may be replicated to the AAA layer on the authenticator. On the authenticator, the AAA layer provides the replicated keying material to the lower layer over which the EAP authentication conversation took place. This enables "mode independence" to be maintained. The EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function. The EMSK MUST NOT be transported by the AAA layer. As noted in [RFC3748] Section 7.10: The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. The EAP layer as well as the peer and authenticator layers MUST NOT modify or cache keying material or parameters (including Channel Bindings) passing in either direction between the EAP method layer and the lower layer or AAA layer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Mar 30 18:37:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6hR-0002VK-Kw for eap-archive@lists.ietf.org; Thu, 30 Mar 2006 18:37:09 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6hP-0006Ob-Rs for eap-archive@lists.ietf.org; Thu, 30 Mar 2006 18:37:09 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7A6F143015C for ; Thu, 30 Mar 2006 15:37:07 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A7B434300AE for ; Thu, 30 Mar 2006 15:36:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95FE7398027 for ; Thu, 30 Mar 2006 15:36:52 -0800 (PST) Received: from hotmail.com (bay106-f11.bay106.hotmail.com [65.54.161.21]) by zoidberg.tigertech.net (Postfix) with ESMTP id D56A6398017 for ; Thu, 30 Mar 2006 15:36:50 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Mar 2006 15:36:46 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 30 Mar 2006 23:36:41 GMT X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 30 Mar 2006 15:36:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Mar 2006 23:36:46.0616 (UTC) FILETIME=[CF277980:01C65452] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER X-Spam-Level: * Subject: [eap] Issue 344: Yet More Nits X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Issue 344: Yet More NITs Submitter name: Bernard Aboba Submitter email address: aboba at internaut.com Date Submitted: March 30, 2006 Reference: Document: Keying-10 Comment type: E Priority: 1 Section: Various Rationale/Explanation of issue: In Section 1.3 Change: "Phase 2: Secure Association Establishment" To: "Phase 2: Secure Association Protocol" Change: " In order to obey the principle of Mode Independence, where a backend server is present, all keying material which is required by the lower layer needs to be transported from the EAP server to the authenticator. Since existing TSK derivation techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b." To: " In order to obey the principle of Mode Independence (see Section 1.6.1), where a backend server is present, all keying material which is required by the lower layer needs to be transported from the EAP server to the authenticator. Since existing TSK derivation and transport techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b." In Section 1.3.1, add: "A proof of the security of the IEEE 802.11i 4-way handshake when used with EAP-TLS [RFC2716], is provided in [He]." Move the following material from Section 1.3 to Section 1.5 and change the text from: " The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server). Authorization issues are discussed in Sections 5.8. Completion of an EAP method exchange (Phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) and server (identified by the Server-ID). Both the EAP peer and EAP server know the exported keying material to be fresh. Disclosure issues are discussed in Section 5.5; key freshness is discussed in Sections 3.3, 3.4 and 5.7. Completion of the AAA exchange (Phase 1b) results in the transport of EAP keying material from the EAP server (identified by the Server-ID) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Security properties of AAA protocols are discussed in Sections 5.2-5.8, and 5.11. Completion of the Secure Association Protocol (Phase 2) results in the derivation of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-ID) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Security properties of Secure Association Protocols are discussed in Section 3.1." To: " The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server). Completion of an EAP method exchange (Phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) and server (identified by the Server-ID). Both the EAP peer and EAP server know the exported keying material to be fresh. Key freshness is discussed in Sections 3.3, 3.4 and 5.7. Completion of the AAA exchange (Phase 1b) results in the transport of EAP keying material from the EAP server (identified by the Server-ID) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Disclosure issues are discussed in Section 5.6; security properties of AAA protocols are discussed in Sections 5.2-5.8, and 5.11. Completion of the Secure Association Protocol (Phase 2) results in the derivation or transport of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-ID) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and authenticator demonstrate that they are authorized to perform their roles. Authorization issues are discussed in Section 5.8 and 5.9; security properties of Secure Association Protocols are discussed in Section 3.1." In Section 1.6.1, change "in order to support" to "to support" Change: "However, one of the advantages of EAP is that it enables deployment of" To: "However, when utilized in "pass-through" mode, EAP enables deployment of" In Section 1.6.2, change: " over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 802.11 wireless LANs [IEEE-802.11i]." To: " over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless networks such as 802.11 [IEEE-802.11i] and 802.16 [IEEE-802.16e]." In Section 2.3: Change "Figure 5" to "Figure 3". Change: "To take an example from IKE, the difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is" To: "For example, a difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is" Change: "EAP does not support negotiation of key lifetimes, nor does it support re-key without re-authentication." To: "EAP does not support re-key without re-authentication and existing EAP methods do not support key lifetime negotiation." Change: "[RFC3748], does not support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV." To: "[RFC3748], does not itself support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV." Change: "material or keys derived from it is only utilized by a single" To: "material or keys derived from it are only utilized by a single" In Section 5.8: Change "a post-EAP handshake" to "a Secure Association Protocol" In Section 5.11: Change: "Both the RADIUS and Diameter protocols are potentially vulnerable to impersonation by a rogue 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 backend authentication server), the security mechanisms vary according to the AAA protocol. In 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. When RADIUS requests are forwarded by a proxy," To: "Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are potentially vulnerable to impersonation by a rogue authenticator. While both protocols support mutual authentication between the authenticator (known as the AAA client) and the backend authentication server (known as the backend authentication server), the security mechanisms vary. In 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. When RADIUS Access-Requests are forwarded by a proxy," Change: "While [RFC3588] requires use of the Route-Record AVP, this utilizes FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs to be properly configured. As a result, it appears that Diameter is as vulnerable to this attack as RADIUS, if not more so. To address this vulnerability, it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588]." To: "While [RFC3588] requires use of the Route-Record AVP, this utilizes FQDNs, so that impersonation detection requires DNS A, AAAA and PTR Resource Records (RRs) to be properly configured. As a result, Diameter is as vulnerable to this attack as RADIUS, if not more so. To address this vulnerability, it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588]." In Section 5.12: Change: "[RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer. For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol." To: "As described in the previous section, it is possible for a proxy to detect a AAA client attempting to impersonate another authenticator (such by sending incorrect Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer. For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol." In Section 7.2, add the following reference: [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. Mitchell, "A Modular Correctness Proof of TLS and IEEE 802.11i", ACM Conference on Computer and Communications Security (CCS '05), November, 2005. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From farshid@01logic.com Fri Mar 31 20:50:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVFw-0006Uw-U1 for eap-archive@ietf.org; Fri, 31 Mar 2006 20:50:24 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPVFw-0003cE-SY for eap-archive@ietf.org; Fri, 31 Mar 2006 20:50:24 -0500 Received: from [210.213.140.220] (helo=210.213.140.220.pldt.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FPVFv-000074-M7 for eap-archive@ietf.org; Fri, 31 Mar 2006 20:50:24 -0500 Date: Sat, 1 Apr 2006 18: 8: 5 +0480 From: "Preston Tolbert" X-Mailer: The Bat! (v3.5.30) CD5BF9353B3B7091 Reply-To: "Preston Tolbert" X-Priority: 3 (Normal) Message-ID: <5240983606.20060401180805@01logic.com> To: eap-archive@ietf.org Subject: [fwd] Market TradePicks Watch special pr news release MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 There is a Big PR Campaign running ALL Weekend! Get KKPT First Thing, This Is Going To Explode! Check out HOT NEWS!!! Very Big New Expected today at close. Monday should really move! KOKO PETROLEUM (KKPT) - This is our #1 pick this week Our last pick gained $2.16 in 4 days of trading. Current Price: $1.09 5 day expected price $2.10 This has been a great producer in our last PR Campaign VANCOUVER, British Columbia--(BUSINESS WIRE)--March 17, 2006--KOKO Petroleum, Inc. (PINK SHEETS:KKPT - News) has now completed two wells. The wells have now been equipped for production. The first two days resulted in the recovery of water from the formation and the oil cut (percentage of oil to water) has now increased substantially. The water should be eliminated within a few days. Production tanks and separator are being installed KOKO Petroleum, Inc. (PKKPT - News) announced today that it has revised its Letter of Intent with JMT Resources, Ltd. Fort Worth Texas regarding the Development of JMT's polymer flood pilot program on its leasehold located in Corsicana, Texas. The previous agreement focused only on the pilot program for the polymer flood in a specific area of JMT's acreage. The revised agreement gives KOKO the right, via a master joint venture, to participate in all of JMT's acreage in the Corsicana Field which totals 7,838 acres. As mentioned in previous releases, this leasehold is the oldest oil field in Texas and was discovered in the 1890's by a company that eventually became Mobil Oil. Recent geological analyses indicated there are several zones under the Nacatoch zone (where the polymer flood is being developed) which are oil bearing and have an excellent possibility for commercial production. These zones include the Pecan Gap, Austin Chalk and Wolf City. The joint venture plans on shooting 3D seismic over portions of the Field to better understand the potential of these zones and corresponding reserves. Subsequently, an aggressive horizontal and vertical drilling plan will be implemented to capitalize on the seismic findings.