From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon May 01 00:24:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaPxB-00014f-Fd for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:24:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaPx8-0004pG-2P for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:24:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1A4034300FD for ; Sun, 30 Apr 2006 21:23:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 53A18430067 for ; Sun, 30 Apr 2006 21:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E96C398009 for ; Sun, 30 Apr 2006 21:23:43 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id B05FF39801C for ; Sun, 30 Apr 2006 21:23:39 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 30 Apr 2006 21:23:39 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k414NcRT022681 for ; Sun, 30 Apr 2006 21:23:39 -0700 (PDT) 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 Date: Sun, 30 Apr 2006 21:31:06 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F62CDE@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: EAP-Keying section 1.2 Thread-Index: AcZs1wQMOrZtsoswSY+7NQASPwWkWA== From: "Salowey, Joe" To: 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: Subject: [eap] ISSUE: EAP-Keying section 1.2 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 Submitter name: Joe salowey Submitter email address: jsalowey@cisco.com Date first submitted: 4/30/2006 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix=20 Section: 1.2 Rationale/Explanation of issue: It seems that EAP Session-ID/Method-ID should be define here Requested change: Add Definition for EAP Session-ID/Method-ID _________________________________________________________________ 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 May 01 00:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaQ4I-0003gf-2W for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:31:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaQ4H-0005Lq-Lx for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:31:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4B2A44300EC for ; Sun, 30 Apr 2006 21:31:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A745E4300F9 for ; Sun, 30 Apr 2006 21:31:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9BC4239801E for ; Sun, 30 Apr 2006 21:31:11 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2AEB439801C for ; Sun, 30 Apr 2006 21:31:08 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 30 Apr 2006 21:31:08 -0700 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 k414V8h0020661 for ; Sun, 30 Apr 2006 21:31:08 -0700 (PDT) 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 Date: Sun, 30 Apr 2006 21:38:36 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F62CDF@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: EAP keying section 1.4 - method and session ID Thread-Index: AcZs2BBZDlbb/Re9SBqLjEHyh2Az3A== From: "Salowey, Joe" To: 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: Subject: [eap] ISSUE: EAP keying section 1.4 - method and session ID 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 4/30/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: '1' Should fix=20 Section: 1.4 Rationale/Explanation of issue: This document defines both session and Method ID. It seems that it would be sufficient and less confusing to define only one called the session ID. =20 Suggested definition: "Session-Id The Session-Id uniquely identifies an EAP session between an EAP peer (as identified by the Peer-Id) and server (as identified by the Server-Id). The EAP Session-Id consists of the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) and the temporally unique identifier obtained from the method. This unique identifier is=20 typically constructed from nonces or counters used within the EAP method exchange. The inclusion of the Expanded Type Code in the EAP Session-Id ensures that each EAP method has a distinct Session-Id space. Since an EAP session is not bound to a particular authenticator or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id." Replace references to method-ID with Session-ID. _________________________________________________________________ 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 May 01 00:44:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaQHB-0007mD-Je for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:44:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaQHA-0005uO-73 for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:44:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D53074300D2 for ; Sun, 30 Apr 2006 21:44:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6087E4300F7 for ; Sun, 30 Apr 2006 21:44:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4E83A398007 for ; Sun, 30 Apr 2006 21:44:24 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id B9767398009 for ; Sun, 30 Apr 2006 21:44:21 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 30 Apr 2006 21:44:21 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k414iLRT002877 for ; Sun, 30 Apr 2006 21:44:21 -0700 (PDT) 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 Date: Sun, 30 Apr 2006 21:51:48 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F62CE1@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: EAP Keying section 1.4 data associated with authentication Thread-Index: AcZs2ejugEXUzn0WTB25MdboFmZ1iw== From: "Salowey, Joe" To: 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: Subject: [eap] ISSUE: EAP Keying section 1.4 data associated with 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: a7d6aff76b15f3f56fcb94490e1052e4 Submitter name: Joe Salowey=09 Submitter email address: jsalowey@cisco.com Date first submitted:=20 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix=20 Section: Section 1.4 Rationale/Explanation of issue: Length description of problem =20 This section contains text that seem to indicate that an EAP method has access to certain data for authorization. While this may be true in some cases this is not generally true. Suggested revision: "As illustrated in Figure 2, the EAP method key derivation has at the root the long term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity as well as additional information. This information is typically used outside of the EAP method to determine if access to some service should be granted. The peer stores information necessary to choose which secret to use for which service. If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server may also store additional information associated with the peer's identity and the peer stores information necessary to choose which certificate to use for which service." _________________________________________________________________ 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 May 01 00:55:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaQRL-00015z-Gm for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:55:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaQRK-0006DU-3j for eap-archive@lists.ietf.org; Mon, 01 May 2006 00:55:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 819744300D8 for ; Sun, 30 Apr 2006 21:55:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 138754300A2 for ; Sun, 30 Apr 2006 21:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 081D4398030 for ; Sun, 30 Apr 2006 21:55:05 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7843B39801C for ; Sun, 30 Apr 2006 21:55:02 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 30 Apr 2006 21:55:02 -0700 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 k414t1w1005551 for ; Sun, 30 Apr 2006 21:55:02 -0700 (PDT) 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 Date: Sun, 30 Apr 2006 22:02:29 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F62CE3@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: Section 1.6.4 Ciphersuite Independence Thread-Index: AcZs22aPkPu3N63OS5S8WGX6OsUO7Q== From: "Salowey, Joe" To: 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: Subject: [eap] ISSUE: Section 1.6.4 Ciphersuite Independence 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 04/30/06 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: '2' May fix=20 Section: 1.6.4 Rationale/Explanation of issue: Section 3.7 implies that there is a system level coordination between the strength of the keys exported by the EAP method and the strength of keys required by the lower layer.=20 This section should reference this and indicate that the coordination is done outside of 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 skitrip-bounces+eap-archive=lists.ietf.org@frascone.com Mon May 01 08:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaXbn-0006Xz-Q4 for eap-archive@lists.ietf.org; Mon, 01 May 2006 08:34:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaXbn-00012Y-IG for eap-archive@lists.ietf.org; Mon, 01 May 2006 08:34:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 394E0430166 for ; Mon, 1 May 2006 05:34:35 -0700 (PDT) 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: Mon, 01 May 2006 05:31:35 -0700 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 Mon May 01 21:30:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fajj2-0006QA-Ow for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:30:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fajiz-0007ko-BE for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:30:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 52281430105 for ; Mon, 1 May 2006 18:30:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4A3CB430067 for ; Mon, 1 May 2006 18:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3FCB1398012 for ; Mon, 1 May 2006 18:30:16 -0700 (PDT) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9C598398036 for ; Mon, 1 May 2006 18:30:13 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 May 2006 18:30:13 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 01:30:09 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 01 May 2006 18:30:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 01:30:13.0323 (UTC) FILETIME=[F57C89B0:01C66D87] 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 Issues 351, 353, 354, 355 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 The following keying framework issues were submitted in EAP WG last call: Issue 351: Incomplete EAP Pre-authentication Discussion Issue 353: Definition of Session-Id/Method-Id Issue 354: Method-Id and Session-Id Issue 355: Data Associated with Authentication The full text of these issues is available here: http://www.drizzle.com/~aboba/EAP/eapissues.html The proposed resolution of these issues is to ACCEPT the proposed changes. A version of the EAP keying framework document with these changes reflected is available here: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-13.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 Mon May 01 21:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fajul-0005q3-Jl for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:42:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fajuk-0008K3-5L for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:42:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CB0AA430136 for ; Mon, 1 May 2006 18:42:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0C6E3430067 for ; Mon, 1 May 2006 18:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F14511448021 for ; Mon, 1 May 2006 18:42:42 -0700 (PDT) Received: from hotmail.com (bay106-f16.bay106.hotmail.com [65.54.161.26]) by hermes.tigertech.net (Postfix) with ESMTP id 674BF144800C for ; Mon, 1 May 2006 18:42:40 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 May 2006 18:42:39 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 01:42:37 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 01 May 2006 18:42:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 01:42:39.0804 (UTC) FILETIME=[B26C7FC0:01C66D89] 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: * Subject: [eap] Re: Issue 356: Ciphersuite Independence 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 The text of Issue 356 is given below. Section 3.7 says the following: "In order to guard against brute force attacks, EAP methods supporting key derivation need to be capable of generating keying material with an appropriate effective symmetric key strength. In order to ensure that EAP key generation is not the weakest link, it is RECOMMENDED that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength meeting the symmetric key strength requirement." The text is accurate as far as it goes, but it occurs to me that this is not the complete story. Even if the EAP keying material is of sufficient strength, attacks on the transient session keys might still be possible. For example in IKEv2, EAP is not used for key derivation, just authentication; key derivation is handled by IKEv2 (e.g. DH). If IKEv2 does not negotiate adequate strength for the key derivation (e.g. 512-bit key for DH) the TSKs will be weak regardless of how strong the EAP keying material is, since the MSK is only used for authentication, not key derivation. Similarly in 802.16 the TSKs are generated purely by the Base Station. If BS does not have a good random number generator, it would be possible to crack the TSKs without having to brute force the EAP keying material. So in both the IKEv2 and 802.16 cases, strong EAP keying material is necessary, but not sufficient to ensure strong TSKs. Given this, I am wondering what text is appropriate relating to "system level coordination" in Section 1.6.4. I think we can say that the strength of the EAP keying material should not be less than the strength of the desired TSKs. But I'm not clear what we can say about "coordination" beyond that. Can someone suggest text? ---------------------------------------------------------------------------------------------------------- Issue 356: Ciphersuite Independence Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: April 30, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04223.html Document: KEYING-12 Comment type: 'E'ditorial Priority: '2' May fix Section: 1.6.4 Rationale/Explanation of issue: Section 3.7 implies that there is a system level coordination between the strength of the keys exported by the EAP method and the strength of keys required by the lower layer. This section should reference this and indicate that the coordination is done outside of 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 May 01 21:49:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fak0d-0002hJ-Fn for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:49:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fak0c-0000Ms-1a for eap-archive@lists.ietf.org; Mon, 01 May 2006 21:49:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ABD41430124 for ; Mon, 1 May 2006 18:49:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D4115430067 for ; Mon, 1 May 2006 18:48:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C49CA1448017 for ; Mon, 1 May 2006 18:48:41 -0700 (PDT) Received: from hotmail.com (bay106-f10.bay106.hotmail.com [65.54.161.20]) by hermes.tigertech.net (Postfix) with ESMTP id 3DA4E144800C for ; Mon, 1 May 2006 18:48:39 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 May 2006 18:48:38 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 01:48:34 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 01 May 2006 18:48:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 01:48:38.0926 (UTC) FILETIME=[887A2AE0:01C66D8A] 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: * Subject: [eap] Re: Issue 352: Channel Binding Issue 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 The text of Issue 352 is shown below. The suggested substitute text is ok as far as it goes. As I read the referenced document, it requires changes to EAP methods, much the same as the transportation approach does. The peer and server have to negotiate what channel bindings are mixed in with the keying material, effectively producing "mixed" MSKs/EMSKs. Since the EAP method is really just outputing an MSK/EMSK as usual (albeit with channel bindings mixed in), no new AAA attributes or communication flow is required. Did I read the document correctly? ----------------------------------------------------------------------------------------------------------------- Issue 352: Channel Binding Issue Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date Submitted: April 25, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04216.html Document: Keying-12 Comment type: T Priority: 1 Section: 5.11 Rationale/Explanation of issue: Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which provides more generic, complete and extensible way of channel binding. Note that pre-configuration of the parameter set on AS is an important property to achieve Channel Binding in 3-party key management. Change: " It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. In this approach the authenticator informs the backend server about the Channel Binding parameters using AAA, and the backend server calculates transported keying material based on this parameter set, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there was a mismatch in the parameters." to: " It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. In this approach the backend server calculates transported keying material based on the parameter set pre-configured for the authenticator, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there was a mismatch in the parameters." _________________________________________________________________ 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 May 02 01:24:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FanMt-0001qD-PZ for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:24:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FanMr-0007O5-BX for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:24:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 77AC143015B for ; Mon, 1 May 2006 22:24:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 447A84300A4 for ; Mon, 1 May 2006 22:23:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 30D44144800C for ; Mon, 1 May 2006 22:23:58 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 9AA72144801E for ; Mon, 1 May 2006 22:23:54 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425NreC007809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 May 2006 22:23:54 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425Nrat018054 for ; Mon, 1 May 2006 22:23:53 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 22:23:52 -0700 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 Date: Mon, 1 May 2006 22:23:51 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84791F7A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: Channel Binding Definition Section 1.2 Thread-Index: AcZtqJicBFfznrJfR8ORDxq+6REcfw== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 May 2006 05:23:52.0921 (UTC) FILETIME=[99D16C90:01C66DA8] 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.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [eap] Issue: Channel Binding Definition Section 1.2 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 Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: '1' Should fix=20 Section: 1.2 Rationale/Explanation of issue: The document defines channel binding as a communication within an EAP method - this seems a bit restrictive, given that channel binding information could be carried out-of-band as well. The only requirement is that the information be integrity protected between the peer and server.=20 =20 Requested change: Change wording to:=20 "The communication of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol)." _________________________________________________________________ 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 May 02 01:38:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fanai-0002Dk-CH for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:38:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fanag-0007p7-Va for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:38:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A15CA43016C for ; Mon, 1 May 2006 22:38:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ABF0C430111 for ; Mon, 1 May 2006 22:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 968CE1448021 for ; Mon, 1 May 2006 22:38:16 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 14CD81448017 for ; Mon, 1 May 2006 22:38:13 -0700 (PDT) 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 k425cDb4014641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 May 2006 22:38:13 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425cC3r011435 for ; Mon, 1 May 2006 22:38:12 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 22:38:12 -0700 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 Date: Mon, 1 May 2006 22:36:50 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84791F7D@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: AAA-Key Section 1.2 Thread-Index: AcZtqmlkeR3++vItRJ6RUDDpXZqXvA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 May 2006 05:38:12.0255 (UTC) FILETIME=[9A0562F0:01C66DAA] 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.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [eap] Issue: AAA-Key Section 1.2 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 Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: '2' May fix=20 Section: 1.2 Rationale/Explanation of issue:=20 Given that the term AAA-Key is not used elsewhere in the document, it would be good to add a sentence clarifying that the definition is provided as a clarification to the terminology used in older documents and that it is no longer used. =20 =20 Requested change: Add to AAA-Key definition:=20 "This term is no longer used to refer to the MSK in this document." _________________________________________________________________ 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 May 02 01:41:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fandq-0005Jl-HV for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:41:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fandp-0007ym-3g for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:41:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BBC2D430141 for ; Mon, 1 May 2006 22:41:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1187A43006D for ; Mon, 1 May 2006 22:41:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0097C144801E for ; Mon, 1 May 2006 22:41:29 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 3B29B144800C for ; Mon, 1 May 2006 22:41:26 -0700 (PDT) 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 k425fOOX014791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 May 2006 22:41:25 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425fIjM012010 for ; Mon, 1 May 2006 22:41:18 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 22:41:15 -0700 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 Date: Mon, 1 May 2006 22:40:54 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84791F7E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: Section 1.4 Thread-Index: AcZtqvqTZ54m3+7EQI+IzXnO3c8nUA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 May 2006 05:41:15.0265 (UTC) FILETIME=[071A7F10:01C66DAB] 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.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [eap] Issue: Section 1.4 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 Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: 'S' Must fix=20 Section: 1.4 Rationale/Explanation of issue:=20 Typo in Server-Id paragraph=20 =20 Requested change: s/method-specific peer identity/method-specific server identity/ _________________________________________________________________ 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 May 02 01:47:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fanjh-0000xe-6r for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:47:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fanje-0008I1-Pr for eap-archive@lists.ietf.org; Tue, 02 May 2006 01:47:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7692A430128 for ; Mon, 1 May 2006 22:47:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 826CA43006D for ; Mon, 1 May 2006 22:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 70F8A39802E for ; Mon, 1 May 2006 22:47:33 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id EACCF398029 for ; Mon, 1 May 2006 22:47:30 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425lUo2009226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 May 2006 22:47:30 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k425lTHv017622 for ; Mon, 1 May 2006 22:47:29 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 22:47:28 -0700 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 Date: Mon, 1 May 2006 22:47:20 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84791F80@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: EMSK Transport Thread-Index: AcZtq+DY2KwboR0kQAGOMFc3L8Y9sw== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 May 2006 05:47:28.0908 (UTC) FILETIME=[E5CFE4C0:01C66DAB] 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] Issue: EMSK Transport 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: 2409bba43e9c8d580670fda8b695204a Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: '1' Should fix=20 Section: 2 Rationale/Explanation of issue:=20 The section says "The EMSK MUST NOT be transported by the AAA layer." Given that the EMSK usage is currently undefined, it is not clear if it will be the AAA layer that derives further keys from the EMSK. In fact, doing so will create disparate behavior at the peer and server, since the peer does not have a AAA layer. Although this topic is pending discussion, it seems restrictive to say MUST NOT here. It does make sense, however, to say that the EMSK MUST NOT be transported to additional parties. =20 =20 Requested change: Delete the sentence "The EMSK MUST NOT be transported by the 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 Tue May 02 02:05:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fao0u-0003k8-Mh for eap-archive@lists.ietf.org; Tue, 02 May 2006 02:05:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FanyG-0000pd-Ni for eap-archive@lists.ietf.org; Tue, 02 May 2006 02:02:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 43A3B430196 for ; Mon, 1 May 2006 23:02:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1C4DE43006D for ; Mon, 1 May 2006 23:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EE5D5398033 for ; Mon, 1 May 2006 23:02:30 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 471E4398029 for ; Mon, 1 May 2006 23:02:28 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4262N5v010556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 May 2006 23:02:24 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4262Gtd020886 for ; Mon, 1 May 2006 23:02:18 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 23:02:15 -0700 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 Date: Mon, 1 May 2006 22:59:44 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84791F82@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: Child key expiry Thread-Index: AcZtrZxBC8itJ+lTQBmuNY+he8XmMA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 02 May 2006 06:02:15.0721 (UTC) FILETIME=[F664D190:01C66DAD] 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] Issue: Child key expiry 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 Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: '2' May fix=20 Section: 3.3 Rationale/Explanation of issue:=20 This section states "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." This seems to indicate that the keys derived from the EMSK will also be expired when the EMSK expires. It is not yet clear if this would apply to all kinds of keys derived from the EMSK. There may be classes of keys derived from the EMSK for which different lifetime guidelines apply. So, it may be good to clarify that the EMSK usage documents will specify the guidelines for EMSK-based child keys.=20 =20 Requested change: Change=20 "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs."=20 to=20 "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs. Note that different lifetime guidelines may be specified in future specifications for EMSK-based child keys." _________________________________________________________________ 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 May 02 02:26:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoLC-0001Ij-0W for eap-archive@lists.ietf.org; Tue, 02 May 2006 02:26:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoL9-0001SU-F4 for eap-archive@lists.ietf.org; Tue, 02 May 2006 02:26:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CF5054300E8 for ; Mon, 1 May 2006 23:26:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 966DC43006D for ; Mon, 1 May 2006 23:26:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 85AFD1448021 for ; Mon, 1 May 2006 23:26:17 -0700 (PDT) Received: from hotmail.com (bay106-f18.bay106.hotmail.com [65.54.161.28]) by hermes.tigertech.net (Postfix) with ESMTP id 055DC144801E for ; Mon, 1 May 2006 23:26:15 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 May 2006 23:26:14 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 06:26:10 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 01 May 2006 23:26:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 06:26:14.0529 (UTC) FILETIME=[4FFD7F10:01C66DB1] 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: * Subject: [eap] IETF Meeting Survey (fwd) 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 Please take the time and fill out the survey below. This will help us run the IETF meetings more effectively, and ensure that your requirements are heard. >-----Original Message----- >From: ext Ray Pelletier [mailto:rpelletier@isoc.org] Sent: 01 May, 2006 >18:25 >To: wgchairs@ietf.org >Subject: IETF Meeting Survey > >All; >It has been suggested that if I really wanted to get feedback on the >Meeting Survey (and I do) I should have it forwarded by the WG Chairs to >the working groups - so this is a request that you ask members of the >working groups to complete a short survey that focuses primarily, but not >exclusively, on their meeting experience in Dallas. > >I truly want the info to make the changes members of the community want, if >possible and greatly appreciate your assistance in this regard. > >Those interested in taking the survey can find it at: >http://www.surveymonkey.com/s.asp?u=649182049947 > >Thanks >Ray Pelletier >IETF Admininstrative Director _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Horace_MccoyGunterMcintoshWeston@gbmgroup.com.cn Tue May 02 06:47:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FasPs-0006YV-1r; Tue, 02 May 2006 06:47:40 -0400 Received: from [213.170.82.165] (helo=42B29658) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FasPg-0004jS-Dd; Tue, 02 May 2006 06:47:40 -0400 Received: from local (unknown [10.66.1.4]) by variable.ewv.be (Postfix) with ESMTP id B066857D12 for ; Tue, 02 May 2006 03:47:11 -0800 Message-Id: <7361D619.542263.47895@BPTW> X-Provags-ID: ewv.be abuse@ewv.be login:9NJPyhwcFlW03jslMQSW9gYOnYx34cC0 X-FID: 83E32DBC-8236-58AF-B9E1-25CDEA54DCB4 Date: Tue, 02 May 2006 03:47:11 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org From: "Tammy" Subject: Would you like 3.75% refinancement? X-Spam-Score: 3.9 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Want to re-mortgage your house? Or maybe you need a loan? We got the biggest loan companies competing for your business, you therefore get the best possible deal. Get rates as low as 3.75% http://www.saving-u-money-on-ur-mortgage.us From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 02 08:47:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauHh-0008QJ-L7 for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:47:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauHg-0001u8-7i for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:47:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5DCDD4300D1 for ; Tue, 2 May 2006 05:47:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 32AA0430076 for ; Tue, 2 May 2006 05:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 961C5430BB9 for ; Tue, 2 May 2006 05:47:02 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by hermes.tigertech.net (Postfix) with ESMTP id 0707F430BB3 for ; Tue, 2 May 2006 05:47:00 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 05:46:59 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 12:46:54 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 05:46:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 12:46:59.0656 (UTC) FILETIME=[80BF3C80:01C66DE6] 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: * Subject: [eap] Re: issue 358: AAA-Key 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 How about this? "Since multiple keys may be transported by AAA, the term is potentially confusing and is not used in this document." ----------------------------------------------------------------------- Issue 358: AAA-Key Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04228.html Document: KEYING-12 Comment type: 'E'ditorial Priority: '2' May fix Section: 1.2 Rationale/Explanation of issue: Given that the term AAA-Key is not used elsewhere in the document, it would be good to add a sentence clarifying that the definition is provided as a clarification to the terminology used in older documents and that it is no longer used. Requested change: Add to AAA-Key definition: "This term is no longer used to refer to the MSK in this document." _________________________________________________________________ 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 May 02 08:48:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauIS-00009t-FO for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:48:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauIR-0001vH-2Y for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:48:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B55964300B7 for ; Tue, 2 May 2006 05:48:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 59A0D430076 for ; Tue, 2 May 2006 05:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 34B5139803A for ; Tue, 2 May 2006 05:47:53 -0700 (PDT) Received: from hotmail.com (bay106-f2.bay106.hotmail.com [65.54.161.12]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75BF339801C for ; Tue, 2 May 2006 05:47:50 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 05:47:50 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 12:47:47 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 05:47:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 12:47:50.0295 (UTC) FILETIME=[9EEE2270:01C66DE6] 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: Issue 359: Typo 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 I propose we accept the proposed change. Any objections? ------------------------------------------------------------------- Issue 359: Typo Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04229.html Document: KEYING-12 Comment type: 'E'ditorial Priority: 'S' Must fix Section: 1.4 Rationale/Explanation of issue: Typo in Server-Id paragraph Requested change: s/method-specific peer identity/method-specific server identity/ _________________________________________________________________ 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 May 02 08:53:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauO1-0003pJ-9W for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:53:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauNz-0002H0-Sv for eap-archive@lists.ietf.org; Tue, 02 May 2006 08:53:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 82CA0430126 for ; Tue, 2 May 2006 05:53:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 823A2430076 for ; Tue, 2 May 2006 05:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 712C0430BD1 for ; Tue, 2 May 2006 05:53:37 -0700 (PDT) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by hermes.tigertech.net (Postfix) with ESMTP id BF0FF430BC0 for ; Tue, 2 May 2006 05:53:34 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 05:53:34 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 12:53:32 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 05:53:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 12:53:34.0449 (UTC) FILETIME=[6C0FDE10:01C66DE7] 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: * Subject: [eap] Re: Issue 360: EMSK Transport 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 Since EMSK sharing is prohibited elsewhere in the document, the text to be deleted is redundant at best. Any objections to accepting the proposed change? --------------------------------------------------------------------- Issue 360: EMSK Transport Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04230.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 2 Rationale/Explanation of issue: The section says "The EMSK MUST NOT be transported by the AAA layer." Given that the EMSK usage is currently undefined, it is not clear if it will be the AAA layer that derives further keys from the EMSK. In fact, doing so will create disparate behavior at the peer and server, since the peer does not have a AAA layer. Although this topic is pending discussion, it seems restrictive to say MUST NOT here. It does make sense, however, to say that the EMSK MUST NOT be transported to additional parties. Requested change: Delete the sentence "The EMSK MUST NOT be transported by the 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 Tue May 02 09:11:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fauew-00031u-4I for eap-archive@lists.ietf.org; Tue, 02 May 2006 09:11:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faueu-0002jD-MK for eap-archive@lists.ietf.org; Tue, 02 May 2006 09:11:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4AB254300A2 for ; Tue, 2 May 2006 06:11:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8FC7E430097 for ; Tue, 2 May 2006 06:11:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7731C398044 for ; Tue, 2 May 2006 06:11:04 -0700 (PDT) Received: from hotmail.com (bay106-f27.bay106.hotmail.com [65.54.161.37]) by zoidberg.tigertech.net (Postfix) with ESMTP id C5FE539801D for ; Tue, 2 May 2006 06:11:01 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 06:11:01 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 13:10:55 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 06:10:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 13:11:01.0322 (UTC) FILETIME=[DC0C02A0:01C66DE9] 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: issue 361: child key expiry 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 One of the unstated threat model assumptions is that any key can be compromised over a sufficient period of time. This includes the exported keys (MSK, EMSK). So the question is: if the MSK or EMSK are considered "stale" should the TSKs also be considered stale? In a previous comment, it was noted that TSK derivation techniques differ, so that a TSK could be compromised even if the MSK/EMSK was not. Similarly, in protocols such as IKEv2, it might be possible to derive a TSK that would not be compromised even if the EMSK/MSK was compromised. For example, consider a 4096-bit DH used for IKEv2 TSK generation while the EAP method uses a 512-bit DH. Since EAP keys are used in IKEv2 only for authentication, as long as IKEv2 does not reuse the MSK after it becomes stale (which it doesn't, because IKEv2 does not support caching), the TSK is not compromised. Given this, I think the problem is with the words "including the TSKs." If the TSKs are not derived from the MSK/EMSK, then I don't think they should be considered stale once the MSK/EMSK is considered stale. However, if a key is derived from the MSK/EMSK, then if the MSK/EMSK is compromised, then presumably the derived key is compromised as well, even if it is derived via PRF, mixing with nonces, etc. If the attacker has obtained the MSK/EMSK, then it can also obtain the derived keys. ---------------------------------------------------------------------------- Issue 361: Child key expiry Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04231.html Document: KEYING-12 Comment type: 'T'echnical Priority: '2' May fix Section: 3.3 Rationale/Explanation of issue: This section states "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." This seems to indicate that the keys derived from the EMSK will also be expired when the EMSK expires. It is not yet clear if this would apply to all kinds of keys derived from the EMSK. There may be classes of keys derived from the EMSK for which different lifetime guidelines apply. So, it may be good to clarify that the EMSK usage documents will specify the guidelines for EMSK-based child keys. Requested change: Change "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." to "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs. Note that different lifetime guidelines may be specified in future specifications for EMSK-based child keys." _________________________________________________________________ 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 May 02 10:11:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavbB-0002DM-TT for eap-archive@lists.ietf.org; Tue, 02 May 2006 10:11:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavbA-0005Md-GB for eap-archive@lists.ietf.org; Tue, 02 May 2006 10:11:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2BCE1430097 for ; Tue, 2 May 2006 07:11:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D53D2430097 for ; Tue, 2 May 2006 07:11:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 94D4A430D63 for ; Tue, 2 May 2006 07:11:14 -0700 (PDT) Received: from hotmail.com (bay106-f7.bay106.hotmail.com [65.54.161.17]) by hermes.tigertech.net (Postfix) with ESMTP id F2FB4430D4B for ; Tue, 2 May 2006 07:11:11 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 07:11:11 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 14:11:09 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 07:11:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 14:11:11.0631 (UTC) FILETIME=[43F571F0:01C66DF2] 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: * Subject: [eap] Re: issue 357: Channel Binding Definition 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 As Yoshi has pointed out, it may be possible to handle channel bindings by mixing keys so that comparison may not be required. How about this? "Channel Binding A mechanism for ensuring the correctness of channel properties (such as endpoint identifiers) provided to the EAP peer, authenticator and server. " ----------------------------------------------------------- Issue 357: Channel Binding Definition Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04227.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 1.2 Rationale/Explanation of issue: The document defines channel binding as a communication within an EAP method - this seems a bit restrictive, given that channel binding information could be carried out-of-band as well. The only requirement is that the information be integrity protected between the peer and server. Requested change: Change wording to: "The communication of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol)." _________________________________________________________________ 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 May 02 11:25:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fawki-0005wi-BY for eap-archive@lists.ietf.org; Tue, 02 May 2006 11:25:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fawke-0000Bt-OD for eap-archive@lists.ietf.org; Tue, 02 May 2006 11:25:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85F76430129 for ; Tue, 2 May 2006 08:25:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3DCDE430075 for ; Tue, 2 May 2006 08:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 19C671448028 for ; Tue, 2 May 2006 08:25:07 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id BB821144802F for ; Tue, 2 May 2006 08:25:02 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42FP1jH021098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 08:25:01 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-200.qualcomm.com [10.50.72.200]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42FOpIR028783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 08:25:00 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502074909.03916010@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 08:24:52 -0700 To: "Bernard Aboba" , eap@frascone.com From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 361: child key expiry In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: 68ba2b07ef271dba6ee42a93832cfa4c At 06:10 AM 5/2/2006, Bernard Aboba wrote: >One of the unstated threat model assumptions is that any key can be >compromised over a sufficient period of time. This includes the >exported keys (MSK, EMSK). So the question is: if the MSK or EMSK >are considered "stale" should the TSKs also be considered stale? > >In a previous comment, it was noted that TSK derivation techniques >differ, so that a TSK could be compromised even if the MSK/EMSK was >not. Similarly, in protocols such as IKEv2, it might be possible to >derive a TSK that would not be compromised even if the EMSK/MSK was >compromised. For example, consider a 4096-bit DH used for IKEv2 TSK >generation while the EAP method uses a 512-bit DH. Since EAP keys >are used in IKEv2 only for authentication, as long as IKEv2 does not >reuse the MSK after it becomes stale (which it doesn't, because >IKEv2 does not support caching), the TSK is not compromised. We hope no one is using a 512-bit DH in an EAP method, considering that EAP key derivation requirements (lengthwise, i.e., 64 octets of MSK, 64 octets of EMSK etc.) are as demanding as IKEv2's are. But, sure, the concern is valid. Some EAP methods use the PSK directly for key derivation whereas IKEv2 doesn't. I am not sure we can safely say that no IKEv2 implementation will cache the EAP MSK as the PSK. After all, the PSK is only used for entity authentication and not for key distribution, and therefore, can be used for a decent amount of time without any issues. Recall also that an alternative might be password based PSKs which may not always be as strong as those coming from an EAP method (assuming one of the newer methods). >Given this, I think the problem is with the words "including the >TSKs." If the TSKs are not derived from the MSK/EMSK, then I don't >think they should be considered stale once the MSK/EMSK is considered stale. > >However, if a key is derived from the MSK/EMSK, then if the MSK/EMSK >is compromised, then presumably the derived key is compromised as >well, even if it is derived via PRF, mixing with nonces, etc. If >the attacker has obtained the MSK/EMSK, then it can also obtain the >derived keys. I think there are several notes here, I think you captured most, but here is a list: Compromise: 1. If an MSK/EMSK is compromised, all derived keys are assumed to have been compromised, as long as any nonces exchanged are in the clear or protected with the MSK/EMSK, or keys derived thereof. 2. MSK/EMSK compromise does not necessarily impact child key derivation iff the MSK/EMSK (or keys derived thereof) only serve as entity authentication keys and are not used for key derivation. (Perhaps the latter -- and are not used for key derivation -- is too restrictive). Lifetime: Lifetime, as far as I understand, is set due to two considerations. Let's consider confidentiality. As soon as a block of ciphertext is transmitted, we can assume that an adversary has started a brute-force attack to guess the key. With the most powerful adversary's capabilities that we want to protect against in mind, we make an estimate of how long it might take for the computation to complete and can set a lifetime. The other consideration is that the amount of traffic encrypted with a given key may provide hints to reduce the computation needed by the brute-force attack. With those considerations in mind, 3. Keys that are used frequently, for instance, for traffic protection expire sooner. We might say those MUST NOT used beyond the EMSK's lifetime. They may expire sooner than the EMSK, however. 4. Keys used less frequently, say, for entity authentication need not expire with the EMSK. We might allow, for instance, local policy to set the lifetime on such keys. That lifetime MAY be beyond EMSK's lifetime. I think Vidya was referring to #4 with her last statement (not mind reading; that came up in our previous discussions on the topic :-) ). regards, Lakshminath >---------------------------------------------------------------------------- >Issue 361: Child key expiry >Submitter name: Vidya Narayanan >Submitter email address: vidyan@qualcomm.com >Date Submitted: May 1, 2006 >Reference: http://lists.frascone.com/pipermail/eap/msg04231.html >Document: KEYING-12 >Comment type: 'T'echnical >Priority: '2' May fix >Section: 3.3 >Rationale/Explanation of issue: > >This section states "When keying material exported by EAP methods >expires, all keying material derived from the exported keying >material expires, including >the TSKs." This seems to indicate that the keys derived from the EMSK >will also be expired when the EMSK expires. It is not yet clear if this >would apply to all kinds of keys derived from the EMSK. There may be >classes of keys derived from the EMSK for which different lifetime >guidelines apply. So, it may be good to clarify that the EMSK usage >documents will specify the guidelines for EMSK-based child keys. > >Requested change: > >Change > >"When keying material exported by EAP methods expires, all keying >material derived from the exported keying material expires, including >the TSKs." > >to > >"When keying material exported by EAP methods expires, all keying >material derived from the exported keying material expires, including >the TSKs. Note that different lifetime guidelines may be specified in >future specifications for EMSK-based child keys." > > >_________________________________________________________________ >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 May 02 11:37:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fawwe-0002bV-4A for eap-archive@lists.ietf.org; Tue, 02 May 2006 11:37:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fawwd-00010E-NA for eap-archive@lists.ietf.org; Tue, 02 May 2006 11:37:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2AEE043012F for ; Tue, 2 May 2006 08:37:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 09093430075 for ; Tue, 2 May 2006 08:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D84D0398047 for ; Tue, 2 May 2006 08:37:31 -0700 (PDT) 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 3D31C398045 for ; Tue, 2 May 2006 08:37:28 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 02 May 2006 08:37:30 -0700 X-IronPort-AV: i="4.05,80,1146466800"; d="scan'208"; a="321393118:sNHT29702616" 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 k42FbSh0018101; Tue, 2 May 2006 08:37:28 -0700 (PDT) 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: Issue 360: EMSK Transport Date: Tue, 2 May 2006 08:44:56 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F6306D@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 360: EMSK Transport Thread-Index: AcZt6IXJxABN5DNzTieQ2ojJMTyAWAAFXxLg 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: f4c2cf0bccc868e4cc88dace71fb3f44 I don't see the text as harmful. It may be somewhat redundant, but I would like to better understand why its presence is restrictive. That would seem to indicate that it is not redundant.=20 Joe =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 5:54 AM > To: eap@frascone.com > Subject: [eap] Re: Issue 360: EMSK Transport >=20 > Since EMSK sharing is prohibited elsewhere in the document,=20 > the text to be=20 > deleted is redundant at best. Any objections to accepting=20 > the proposed=20 > change? >=20 > --------------------------------------------------------------------- > Issue 360: EMSK Transport > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com > Date Submitted: May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04230.html > Document: KEYING-12 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 2 > Rationale/Explanation of issue: >=20 > The section says "The EMSK MUST NOT be transported by the AAA layer." > Given that the EMSK usage is currently undefined, it is not=20 > clear if it > will be the AAA layer that derives further keys from the=20 > EMSK. In fact, > doing so will create disparate behavior at the peer and server, since > the peer does not have a AAA layer. Although this topic is pending > discussion, it seems restrictive to say MUST NOT here. It does make > sense, however, to say that the EMSK MUST NOT be transported to > additional parties. >=20 > Requested change: >=20 > Delete the sentence "The EMSK MUST NOT be transported by the=20 > AAA 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 _________________________________________________________________ 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 May 02 12:21:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faxcr-0004Vs-9u for eap-archive@lists.ietf.org; Tue, 02 May 2006 12:21:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faxcp-0002Hl-Oi for eap-archive@lists.ietf.org; Tue, 02 May 2006 12:21:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 011EB430110 for ; Tue, 2 May 2006 09:21:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 80067430075 for ; Tue, 2 May 2006 09:20:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4828E398046 for ; Tue, 2 May 2006 09:20:56 -0700 (PDT) Received: from hotmail.com (bay106-f5.bay106.hotmail.com [65.54.161.15]) by zoidberg.tigertech.net (Postfix) with ESMTP id 442F8398049 for ; Tue, 2 May 2006 09:20:53 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 09:20:52 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 16:20:51 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <6.2.5.6.2.20060502074909.03916010@qualcomm.com> From: "Bernard Aboba" To: ldondeti@qualcomm.com, eap@frascone.com Subject: Re: [eap] Re: issue 361: child key expiry Date: Tue, 02 May 2006 09:20:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 16:20:52.0567 (UTC) FILETIME=[61C20E70:01C66E04] 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: 41c17b4b16d1eedaa8395c26e9a251c4 >I am not sure we can safely say that no IKEv2 implementation will cache the >EAP MSK as the PSK. After all, the PSK is only used for entity >authentication and not for key distribution, and therefore, can be used for >a decent amount of time without any issues. Recall also that an >alternative might be password based PSKs which may not always be as strong >as those coming from an EAP method (assuming one of the newer methods). In this particular case, we are talking about caching of EAP keying material within the IKEv2 lower layer. Caching of EAP keying material within the PANA lower layer is a separate issue. How should we clarify that? >I think there are several notes here, I think you captured most, but here >is a list: > >Compromise: > >1. If an MSK/EMSK is compromised, all derived keys are assumed to have been >compromised, as long as any nonces exchanged are in the clear or protected >with the MSK/EMSK, or keys derived thereof. Yup. >2. MSK/EMSK compromise does not necessarily impact child key derivation iff >the MSK/EMSK (or keys derived thereof) only serve as entity authentication >keys and are not used for key derivation. (Perhaps the latter -- and are >not used for key derivation -- is too restrictive). Are you suggesting that there might be situations in which EAP keys aren't used for key derivation, but compromise might still be possible? >Lifetime: > >Lifetime, as far as I understand, is set due to two considerations. Let's >consider confidentiality. As soon as a block of ciphertext is transmitted, >we can assume that an adversary has started a brute-force attack to guess >the key. With the most powerful adversary's capabilities that we want to >protect against in mind, we make an estimate of how long it might take for >the computation to complete and can set a lifetime. The other >consideration is that the amount of traffic encrypted with a given key may >provide hints to reduce the computation needed by the brute-force attack. >With those considerations in mind, > >3. Keys that are used frequently, for instance, for traffic protection >expire sooner. We might say those MUST NOT used beyond the EMSK's >lifetime. They may expire sooner than the EMSK, however. Right. And by the same logic, the MSK and EMSK might expire at different times. I'm not sure that the key lifetime section takes that into account adequately. >4. Keys used less frequently, say, for entity authentication need not >expire with the EMSK. We might allow, for instance, local policy to set >the lifetime on such keys. That lifetime MAY be beyond EMSK's lifetime. This makes sense assuming that the entity authentiation keys aren't themselves derived from the EMSK. >I think Vidya was referring to #4 with her last statement (not mind >reading; that came up in our previous discussions on the topic :-) I'd also like to make sure that issues 1-3 are addressed adequately in the 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 Tue May 02 12:57:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FayC2-0005F7-7F for eap-archive@lists.ietf.org; Tue, 02 May 2006 12:57:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FayC0-00048t-NH for eap-archive@lists.ietf.org; Tue, 02 May 2006 12:57:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 05DF3430108 for ; Tue, 2 May 2006 09:57:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E1185430075 for ; Tue, 2 May 2006 09:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E6D839804A for ; Tue, 2 May 2006 09:57:21 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBC67398048 for ; Tue, 2 May 2006 09:57:15 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k42Gv0ft004154; Wed, 3 May 2006 01:57:00 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k42GwB4K012186; Wed, 3 May 2006 01:58:11 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id BAA12138; Wed, 3 May 2006 01:58:11 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k42Guxxq001076; Wed, 3 May 2006 01:56:59 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42Guwt0006669; Wed, 3 May 2006 01:56:58 +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 <0IYN00CB1DQS66A0@mail.po.toshiba.co.jp>; Wed, 03 May 2006 01:56:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FayB7-0003vE-GO; Tue, 02 May 2006 09:56:49 -0700 Date: Tue, 02 May 2006 12:56:49 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: To: Bernard Aboba Message-id: <20060502165649.GB13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060403 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: d185fa790257f526fedfd5d01ed9c976 On Mon, May 01, 2006 at 06:48:34PM -0700, Bernard Aboba wrote: > The text of Issue 352 is shown below. > > The suggested substitute text is ok as far as it goes. > > As I read the referenced document, it requires changes to EAP methods, much > the same as the transportation approach does. The peer and server have to > negotiate what channel bindings are mixed in with the keying material, > effectively producing "mixed" MSKs/EMSKs. Since the EAP method is really > just outputing an MSK/EMSK as usual (albeit with channel bindings mixed > in), no new AAA attributes or communication flow is required. > > Did I read the document correctly? Thank you for reading the document. And the answer is, if the generated "mixed" MSKs are carried in the existing AAA attributes instead of carrying the MSKs, then no AAA attributes or communication flow is required for EAP keying. [Note, however, if the "mixed" MSKs/EMSKs are used outside the scope of EAP keying (e.g., handover keying), then new AAA attributes or communication flow may be needed. This all depends on what requirements on out-of-the-scope usages will be.] Regards, Yoshihiro Ohba > ----------------------------------------------------------------------------------------------------------------- > Issue 352: Channel Binding Issue > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date Submitted: April 25, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04216.html > Document: Keying-12 > Comment type: T > Priority: 1 > Section: 5.11 > Rationale/Explanation of issue: > > Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by > its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which > provides more generic, complete and extensible way of channel binding. > Note that pre-configuration of the parameter set on AS is an important > property to achieve Channel Binding in 3-party key management. > > Change: > > " It is also possible to achieve Channel Bindings without transporting > data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. > In this approach the authenticator informs the backend server about > the Channel Binding parameters using AAA, and the backend server > calculates transported keying material based on this parameter set, > making it impossible for the peer and authenticator to complete the > Secure Association Protocol if there was a mismatch in the > parameters." > > to: > > " It is also possible to achieve Channel Bindings without > transporting data over EAP. For example, see > [I-D.draft-ohba-eap-channel-binding]. In this approach the backend > server calculates transported keying material based on the > parameter set pre-configured for the authenticator, making it > impossible for the peer and authenticator to complete the Secure > Association Protocol if there was a mismatch in the parameters." > > > _________________________________________________________________ > 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 May 02 14:23:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazXS-0007Jl-E8 for eap-archive@lists.ietf.org; Tue, 02 May 2006 14:23:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazXR-0008G5-T2 for eap-archive@lists.ietf.org; Tue, 02 May 2006 14:23:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 86C51430129 for ; Tue, 2 May 2006 11:23:57 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 436F3430097 for ; Tue, 2 May 2006 11:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C0B639801B for ; Tue, 2 May 2006 11:23:44 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 399ED398048 for ; Tue, 2 May 2006 11:23:40 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42IN0Jq010798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 11:23:15 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-84.qualcomm.com [10.50.65.84]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42IHHHQ009816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 11:22:26 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502102418.0406ad90@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 10:52:26 -0700 To: "Bernard Aboba" , eap@frascone.com From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 361: child key expiry In-Reply-To: References: <6.2.5.6.2.20060502074909.03916010@qualcomm.com> 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: 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: 6d95a152022472c7d6cdf886a0424dc6 At 09:20 AM 5/2/2006, Bernard Aboba wrote: >>I am not sure we can safely say that no IKEv2 implementation will >>cache the EAP MSK as the PSK. After all, the PSK is only used for >>entity authentication and not for key distribution, and therefore, >>can be used for a decent amount of time without any issues. Recall >>also that an alternative might be password based PSKs which may not >>always be as strong as those coming from an EAP method (assuming >>one of the newer methods). > >In this particular case, we are talking about caching of EAP keying >material within the IKEv2 lower layer. Caching of EAP keying >material within the PANA lower layer is a separate issue. How >should we clarify that? I wasn't thinking about PANA, but thinking about the use case of client authentication in IPsec remote access using EAP. Whereas EAP can be used every time, it is plausible that the MSK is cached as the IKEv2 Preshared key for future authentication to avoid EAP latency. >>I think there are several notes here, I think you captured most, >>but here is a list: >> >>Compromise: >> >>1. If an MSK/EMSK is compromised, all derived keys are assumed to >>have been compromised, as long as any nonces exchanged are in the >>clear or protected with the MSK/EMSK, or keys derived thereof. > >Yup. > >>2. MSK/EMSK compromise does not necessarily impact child key >>derivation iff the MSK/EMSK (or keys derived thereof) only serve as >>entity authentication keys and are not used for key >>derivation. (Perhaps the latter -- and are not used for key >>derivation -- is too restrictive). > >Are you suggesting that there might be situations in which EAP keys >aren't used for key derivation, but compromise might still be possible? No. I am asking if the MSK/EMSK figures into the key derivation, say only partially (say along with DH), compromise of MSK/EMSK means compromise of derived keys. I was then saying perhaps that is too restrictive, but I'd contend not, unless there is a strong case made for the alternative. If that's confusing too, please let me know. >>Lifetime: >> >>Lifetime, as far as I understand, is set due to two >>considerations. Let's consider confidentiality. As soon as a >>block of ciphertext is transmitted, we can assume that an adversary >>has started a brute-force attack to guess the key. With the most >>powerful adversary's capabilities that we want to protect against >>in mind, we make an estimate of how long it might take for the >>computation to complete and can set a lifetime. The other >>consideration is that the amount of traffic encrypted with a given >>key may provide hints to reduce the computation needed by the >>brute-force attack. >>With those considerations in mind, >> >>3. Keys that are used frequently, for instance, for traffic >>protection expire sooner. We might say those MUST NOT used beyond >>the EMSK's lifetime. They may expire sooner than the EMSK, however. > >Right. And by the same logic, the MSK and EMSK might expire at >different times. I'm not sure that the key lifetime section takes >that into account adequately. That sounds right and the clarification will be good. >>4. Keys used less frequently, say, for entity authentication need >>not expire with the EMSK. We might allow, for instance, local >>policy to set the lifetime on such keys. That lifetime MAY be >>beyond EMSK's lifetime. > >This makes sense assuming that the entity authentiation keys aren't >themselves derived from the EMSK. Even if entity authentication keys are derived from the EMSK, the guideline applies, I think. Suppose the EMSK supports derivation of a traffic key and a separate entity authentication key, wouldn't it make sense to say that, all other things being equal, the traffic key will have a shorter lifetime than the entity authentication key, based on key usage? >>I think Vidya was referring to #4 with her last statement (not mind >>reading; that came up in our previous discussions on the topic :-) > >I'd also like to make sure that issues 1-3 are addressed adequately >in the text. Agreed! Thanks Bernard. regards, Lakshminath _________________________________________________________________ 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 May 02 14:48:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazut-0007Jm-I1 for eap-archive@lists.ietf.org; Tue, 02 May 2006 14:48:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fazus-00011m-4l for eap-archive@lists.ietf.org; Tue, 02 May 2006 14:48:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 62D3F43010C for ; Tue, 2 May 2006 11:48:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F38D1430075 for ; Tue, 2 May 2006 11:47:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C3A01448032 for ; Tue, 2 May 2006 11:47:52 -0700 (PDT) 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 C21AB1448022 for ; Tue, 2 May 2006 11:47:48 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 02 May 2006 11:47:48 -0700 X-IronPort-AV: i="4.05,80,1146466800"; d="scan'208"; a="425974506:sNHT28786436" 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 k42Illh0020531; Tue, 2 May 2006 11:47:47 -0700 (PDT) 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: issue 358: AAA-Key Date: Tue, 2 May 2006 11:55:16 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63172@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 358: AAA-Key Thread-Index: AcZt55zgRtRHEq1iQ4WG1rGI+VJldQAMURDQ From: "Salowey, Joe" To: "Bernard Aboba" , 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.4 tagged_above=-999.0 required=7.0 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: 50a516d93fd399dc60588708fd9a3002 Sounds OK to me.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 5:47 AM > To: eap@frascone.com > Subject: [eap] Re: issue 358: AAA-Key >=20 > How about this? >=20 > "Since multiple keys may be transported by AAA, the term is > potentially confusing and is not used in this document." >=20 > -------------------------------------------------------------- > --------- > Issue 358: AAA-Key > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com > Date Submitted: May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04228.html > Document: KEYING-12 > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 1.2 > Rationale/Explanation of issue: >=20 > Given that the term AAA-Key is not used elsewhere in the document, it > would be good to add a sentence clarifying that the definition is > provided as a clarification to the terminology used in older documents > and that it is no longer used. >=20 > Requested change: >=20 > Add to AAA-Key definition: >=20 > "This term is no longer used to refer to the MSK in this document." >=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 May 02 15:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0DY-0007dQ-0F for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:07:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0DW-0001kQ-9a for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:07:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2C518430119 for ; Tue, 2 May 2006 12:07:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BB9ED4300B4 for ; Tue, 2 May 2006 12:07:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C73661448031 for ; Tue, 2 May 2006 12:07:06 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id EA9AD1448037 for ; Tue, 2 May 2006 12:07:01 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42J6vgN023960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 12:06:58 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42J6g16029968; Tue, 2 May 2006 12:06:57 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:06:52 -0700 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: issue 357: Channel Binding Definition Date: Tue, 2 May 2006 12:06:53 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8479209F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZt8lGBA6KBIbXERQ26Uy2S1sWiZwAJWUEA From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2006 19:06:52.0913 (UTC) FILETIME=[92963E10:01C66E1B] 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.0 tagged_above=-999.0 required=7.0 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: c0bedb65cce30976f0bf60a0a39edea4 Minor clarification:=20 "Channel Binding A *secure* mechanism for ensuring the correctness of channel properties (such as endpoint identifiers) provided to the EAP peer, authenticator and server. " The word secure is to imply that if this data is in fact sent as a blob between the peer and server, it must be integrity protected.=20 Vidya > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 7:11 AM > To: eap@frascone.com > Subject: [eap] Re: issue 357: Channel Binding Definition >=20 > As Yoshi has pointed out, it may be possible to handle=20 > channel bindings by mixing keys so that comparison may not be=20 > required. How about this? >=20 > "Channel Binding >=20 > A mechanism for ensuring the correctness of channel=20 > properties (such as endpoint identifiers) provided to the EAP=20 > peer, authenticator and server. " >=20 > ----------------------------------------------------------- > Issue 357: Channel Binding Definition > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com Date Submitted:=20 > May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04227.html > Document: KEYING-12 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 1.2 > Rationale/Explanation of issue: >=20 > The document defines channel binding > as a communication within an EAP method - this seems a bit=20 > restrictive, given that channel binding information could be=20 > carried out-of-band as well. The only requirement is that the=20 > information be integrity protected between the peer and server. >=20 > Requested change: > Change wording to: >=20 > "The communication of integrity-protected channel properties=20 > such as endpoint identifiers which can be compared to values=20 > communicated via out of band mechanisms (such as via a AAA or=20 > lower layer protocol)." >=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 May 02 15:07:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0Dt-0007uq-56 for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:07:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0Ds-0001l9-HG for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:07:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8A77C4300E1 for ; Tue, 2 May 2006 12:07:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C46214300BF for ; Tue, 2 May 2006 12:07:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CF8581448038 for ; Tue, 2 May 2006 12:07:06 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 137BF144803A for ; Tue, 2 May 2006 12:07:01 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42J6v1k023957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 12:06:58 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42J6g14029968; Tue, 2 May 2006 12:06:56 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:06:52 -0700 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: issue 358: AAA-Key Date: Tue, 2 May 2006 12:06:53 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8479209E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 358: AAA-Key Thread-Index: AcZt5pFVXzqvrrrwTmm6uCuY/vOTwwAMFrlw From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2006 19:06:52.0679 (UTC) FILETIME=[92728970:01C66E1B] 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.0 tagged_above=-999.0 required=7.0 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: 50a516d93fd399dc60588708fd9a3002 Sounds good. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 5:47 AM > To: eap@frascone.com > Subject: [eap] Re: issue 358: AAA-Key >=20 > How about this? >=20 > "Since multiple keys may be transported by AAA, the term is=20 > potentially confusing and is not used in this document." >=20 > -------------------------------------------------------------- > --------- > Issue 358: AAA-Key > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com Date Submitted:=20 > May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04228.html > Document: KEYING-12 > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 1.2 > Rationale/Explanation of issue: >=20 > Given that the term AAA-Key is not used elsewhere in the=20 > document, it would be good to add a sentence clarifying that=20 > the definition is provided as a clarification to the=20 > terminology used in older documents and that it is no longer used. >=20 > Requested change: >=20 > Add to AAA-Key definition: >=20 > "This term is no longer used to refer to the MSK in this document." >=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 May 02 15:08:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0F1-0001QM-Nv for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:08:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0F1-0001oP-2H for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:08:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 244594300FE for ; Tue, 2 May 2006 12:08:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 800224300B4 for ; Tue, 2 May 2006 12:07:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5324D1448037 for ; Tue, 2 May 2006 12:07:08 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id E3EDE144803C for ; Tue, 2 May 2006 12:07:02 -0700 (PDT) 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 k42J6wNq023969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 12:06:59 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42J6uU4000069; Tue, 2 May 2006 12:06:57 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:06:55 -0700 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: Issue 360: EMSK Transport Date: Tue, 2 May 2006 12:06:54 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847920A0@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 360: EMSK Transport Thread-Index: AcZt6IXJxABN5DNzTieQ2ojJMTyAWAAFXxLgAAa3kzA= From: "Narayanan, Vidya" To: "Salowey, Joe" , "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2006 19:06:55.0091 (UTC) FILETIME=[93E29430:01C66E1B] 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.0 tagged_above=-999.0 required=7.0 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: 14582b0692e7f70ce7111d04db3781c8 Hi Joe, The text suggests that the AAA layer MUST NOT transport the EMSK, not that the AAA layer MUST NOT transport the EMSK outside the entity. To me, this implied that the EMSK MUST NOT be transported to other layers within the same entity as well.=20 Due to the current means of key transport, the EMSK arrives at the AAA layer when the MSK arrives. But, we may (I'm not sure yet) need the EMSK to be available to the EAP layer for further key derivation - the AAA layer is potentially not the right layer to be deriving the keys - then, that would imply that the lower layer in the peer is the one deriving the same keys. This, apart from being disparate, also means that every lower layer now needs to define this derivation, which seems undesirable.=20 So, pending discussion, I'd like to not have this statement in the current spec.=20 Vidya > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, May 02, 2006 8:45 AM > To: Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: Issue 360: EMSK Transport >=20 > I don't see the text as harmful. It may be somewhat=20 > redundant, but I would like to better understand why its=20 > presence is restrictive. That would seem to indicate that it=20 > is not redundant.=20 >=20 > Joe =20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 5:54 AM > > To: eap@frascone.com > > Subject: [eap] Re: Issue 360: EMSK Transport > >=20 > > Since EMSK sharing is prohibited elsewhere in the document,=20 > the text=20 > > to be deleted is redundant at best. Any objections to=20 > accepting the=20 > > proposed change? > >=20 > >=20 > --------------------------------------------------------------------- > > Issue 360: EMSK Transport > > Submitter name: Vidya Narayanan > > Submitter email address: vidyan@qualcomm.com Date Submitted: May 1,=20 > > 2006 > > Reference: http://lists.frascone.com/pipermail/eap/msg04230.html > > Document: KEYING-12 > > Comment type: 'T'echnical > > Priority: '1' Should fix > > Section: 2 > > Rationale/Explanation of issue: > >=20 > > The section says "The EMSK MUST NOT be transported by the=20 > AAA layer." > > Given that the EMSK usage is currently undefined, it is not=20 > clear if=20 > > it will be the AAA layer that derives further keys from the=20 > EMSK. In=20 > > fact, doing so will create disparate behavior at the peer=20 > and server,=20 > > since the peer does not have a AAA layer. Although this topic is=20 > > pending discussion, it seems restrictive to say MUST NOT=20 > here. It does=20 > > make sense, however, to say that the EMSK MUST NOT be=20 > transported to=20 > > additional parties. > >=20 > > Requested change: > >=20 > > Delete the sentence "The EMSK MUST NOT be transported by the AAA=20 > > 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 > _________________________________________________________________ > 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 May 02 15:13:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0JF-0008LA-Vi for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:13:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0JF-00023g-CB for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:13:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BC748430160 for ; Tue, 2 May 2006 12:13:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C9D284300B4 for ; Tue, 2 May 2006 12:13:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4F4141448035 for ; Tue, 2 May 2006 12:13:06 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 839461448032 for ; Tue, 2 May 2006 12:13:02 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 02 May 2006 12:13:02 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k42JD1RT026368 for ; Tue, 2 May 2006 12:13:01 -0700 (PDT) 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 Date: Tue, 2 May 2006 12:20:30 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F6318F@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: section 2 - lower layer parameres and EMSK text Thread-Index: AcZuHG0aR37mezeDR4SquuBA0bQVCg== From: "Salowey, Joe" To: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] ISSUE: section 2 - lower layer parameres and EMSK text 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/02/06 Reference:=20 Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix=20 Section: 2 Rationale/Explanation of issue: 1. Passing of parameters to lower layer. It seems that there may be some parameters passed to lower layers that could be usable elsewhere. For example the Session-ID might be usable. If the session-id is included in parameters then I think the following may be to restrictive: "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" Suggested change: "This implies that EAP keying material passed down to a lower layer are for the exclusive use of that lower layer and MUST NOT be used within another lower layer." If this change is accepted there are several other places in the section where this should be changed.=20 2. EMSK text=20 The First paragraph still mentions exporting the EMSK to the lower layer which seems to be problematic when considered with the rest of the text of this section. I don't think the EMSK should be discussed in the lower layer section.=20 My suggeston would be to remove references to the EMSK in this section and move the paragraph discussing the EMSK to Section 1.4 EAP Key hierarchy.=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 May 02 15:19:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0PN-00051t-M1 for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:19:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0PN-0002AS-1H for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:19:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40A8243012A for ; Tue, 2 May 2006 12:19:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3FA364300B4 for ; Tue, 2 May 2006 12:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E33ED398048 for ; Tue, 2 May 2006 12:19:24 -0700 (PDT) Received: from hotmail.com (bay106-f33.bay106.hotmail.com [65.54.161.43]) by zoidberg.tigertech.net (Postfix) with ESMTP id CCAA7398036 for ; Tue, 2 May 2006 12:19:21 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 12:19:21 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 19:19:19 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <6.2.5.6.2.20060502102418.0406ad90@qualcomm.com> From: "Bernard Aboba" To: ldondeti@qualcomm.com, eap@frascone.com Subject: Re: [eap] Re: issue 361: child key expiry Date: Tue, 02 May 2006 12:19:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 19:19:21.0144 (UTC) FILETIME=[50913B80:01C66E1D] 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: 0a7aa2e6e558383d84476dc338324fab >I wasn't thinking about PANA, but thinking about the use case of client >authentication in IPsec remote access using EAP. Whereas EAP can be used >every time, it is plausible that the MSK is cached as the IKEv2 Preshared >key for future authentication to avoid EAP latency. Perhaps we can say that RFC 4306 does not support key caching? It seems that an extension to IKEv2 would be required to support this, since otherwise the IKE initiator and responder couldn't negotiate whether cached EAP keys are to be used, and if so, which ones. >>Are you suggesting that there might be situations in which EAP keys aren't >>used for key derivation, but compromise might still be possible? > >No. I am asking if the MSK/EMSK figures into the key derivation, say only >partially (say along with DH), compromise of MSK/EMSK means compromise of >derived keys. I was then saying perhaps that is too restrictive, but I'd >contend not, unless there is a strong case made for the alternative. OK. If the MSK/EMSK were mixed into the key derivation, then there might be some weakening of the key derivation. How much depends on the algorithm. >If that's confusing too, please let me know. I understand the point.... question is how we make it clear in the text. >>Right. And by the same logic, the MSK and EMSK might expire at different >>times. I'm not sure that the key lifetime section takes that into account >>adequately. > >That sounds right and the clarification will be good. Suggestions welcome. >>This makes sense assuming that the entity authentiation keys aren't >>themselves derived from the EMSK. > >Even if entity authentication keys are derived from the EMSK, the guideline >applies, I think. Suppose the EMSK supports derivation of a traffic key >and a separate entity authentication key, wouldn't it make sense to say >that, all other things being equal, the traffic key will have a shorter >lifetime than the entity authentication key, based on key usage? Yes, it would make sense. I guess I'd distinguish between a key calculated from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that have been suggested so far are static -- that is, they are based on a key-label, but do not generate a fresh key every time they are invoked on the same EMSK, in the way that some TSK derivations do (e.g. 802.11i 4-way handshake). Unless there is an ability to generate fresh keys without an EAP re-authentication, then when the derived keyexpires it is necessary to do an EAP re-authentication. With TSKs it may be possible to do a re-key independent of EAP (e.g. 802.11i 4-way handshake). _________________________________________________________________ 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 May 02 15:20:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0QW-0005HM-RI for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:20:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0QW-0002BU-7B for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:20:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0FFD843013B for ; Tue, 2 May 2006 12:20:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BFFF4430075 for ; Tue, 2 May 2006 12:20:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33A1B1448005 for ; Tue, 2 May 2006 12:20:35 -0700 (PDT) Received: from hotmail.com (bay106-f20.bay106.hotmail.com [65.54.161.30]) by hermes.tigertech.net (Postfix) with ESMTP id 6AFE21448039 for ; Tue, 2 May 2006 12:20:32 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 12:20:31 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 19:20:31 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8479209F@NAEX06.na.qualcomm.com> From: "Bernard Aboba" To: vidyan@qualcomm.com, eap@frascone.com Subject: RE: [eap] Re: issue 357: Channel Binding Definition Date: Tue, 02 May 2006 12:20:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 19:20:31.0669 (UTC) FILETIME=[7A9A7E50:01C66E1D] 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: 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: 0fa76816851382eb71b0a882ccdc29ac sounds good. >From: "Narayanan, Vidya" >To: "Bernard Aboba" , >Subject: RE: [eap] Re: issue 357: Channel Binding Definition >Date: Tue, 2 May 2006 12:06:53 -0700 > >Minor clarification: > >"Channel Binding > >A *secure* mechanism for ensuring the correctness of channel properties >(such as endpoint identifiers) provided to the EAP peer, authenticator >and server. " > >The word secure is to imply that if this data is in fact sent as a blob >between the peer and server, it must be integrity protected. > >Vidya > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 7:11 AM > > To: eap@frascone.com > > Subject: [eap] Re: issue 357: Channel Binding Definition > > > > As Yoshi has pointed out, it may be possible to handle > > channel bindings by mixing keys so that comparison may not be > > required. How about this? > > > > "Channel Binding > > > > A mechanism for ensuring the correctness of channel > > properties (such as endpoint identifiers) provided to the EAP > > peer, authenticator and server. " > > > > ----------------------------------------------------------- > > Issue 357: Channel Binding Definition > > Submitter name: Vidya Narayanan > > Submitter email address: vidyan@qualcomm.com Date Submitted: > > May 1, 2006 > > Reference: http://lists.frascone.com/pipermail/eap/msg04227.html > > Document: KEYING-12 > > Comment type: 'T'echnical > > Priority: '1' Should fix > > Section: 1.2 > > Rationale/Explanation of issue: > > > > The document defines channel binding > > as a communication within an EAP method - this seems a bit > > restrictive, given that channel binding information could be > > carried out-of-band as well. The only requirement is that the > > information be integrity protected between the peer and server. > > > > Requested change: > > Change wording to: > > > > "The communication of integrity-protected channel properties > > such as endpoint identifiers which can be compared to values > > communicated via out of band mechanisms (such as via a AAA or > > lower layer protocol)." > > > > > > _________________________________________________________________ > > 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 May 02 15:23:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0T8-0006XX-Mq for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:23:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0T7-0002MR-3j for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:23:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ACAAA43010C for ; Tue, 2 May 2006 12:23:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 66E17430075 for ; Tue, 2 May 2006 12:23:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 15CEA1448032 for ; Tue, 2 May 2006 12:23:18 -0700 (PDT) Received: from hotmail.com (bay106-f4.bay106.hotmail.com [65.54.161.14]) by hermes.tigertech.net (Postfix) with ESMTP id 5F0281448031 for ; Tue, 2 May 2006 12:23:15 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 12:23:14 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 19:23:08 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8479209F@NAEX06.na.qualcomm.com> From: "Bernard Aboba" To: vidyan@qualcomm.com, eap@frascone.com Subject: RE: [eap] Re: issue 357: Channel Binding Definition Date: Tue, 02 May 2006 12:23:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 19:23:14.0155 (UTC) FILETIME=[DB73E3B0:01C66E1D] 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: 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 That makes sense. Do we also need to indicate that the channel bindings need to be the same for all parties? For example: "Channel Binding A secure mechanism for ensuring the synchronization and correctness of channel properties (such as endpoint identifiers) provided to the EAP peer, authenticator and server." >Minor clarification: > >"Channel Binding > >A *secure* mechanism for ensuring the correctness of channel properties >(such as endpoint identifiers) provided to the EAP peer, authenticator >and server. " > >The word secure is to imply that if this data is in fact sent as a blob >between the peer and server, it must be integrity protected. > >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 Tue May 02 15:27:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0WW-0000rd-HV for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:27:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0WU-0002ag-Us for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:27:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9B748430138 for ; Tue, 2 May 2006 12:27:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1D7DB430075 for ; Tue, 2 May 2006 12:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB1DD39801B for ; Tue, 2 May 2006 12:26:46 -0700 (PDT) Received: from hotmail.com (bay106-f30.bay106.hotmail.com [65.54.161.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 20F5939800E for ; Tue, 2 May 2006 12:26:44 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 12:26:43 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 19:26:42 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060502165649.GB13251@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com Subject: Re: [eap] Re: Issue 352: Channel Binding Issue Date: Tue, 02 May 2006 12:26:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 19:26:43.0285 (UTC) FILETIME=[581A9850:01C66E1E] 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: 08170828343bcf1325e4a0fb4584481c >Thank you for reading the document. And the answer is, if the >generated "mixed" MSKs are carried in the existing AAA attributes >instead of carrying the MSKs, then no AAA attributes or communication >flow is required for EAP keying. It might be worth saying a few words about this in the paragraph. Overall, I'm not sure whether the Channel Binding text in the document is all that consistent/comprehesive. _________________________________________________________________ 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 May 02 16:22:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1OU-0005yM-UU for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:22:50 -0400 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 1Fb19F-0005Pi-3j for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:07:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fb0tJ-0004jK-FG for eap-archive@lists.ietf.org; Tue, 02 May 2006 15:50:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 11DF043011E for ; Tue, 2 May 2006 12:50:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4E75D430075 for ; Tue, 2 May 2006 12:50:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E36C7398049 for ; Tue, 2 May 2006 12:50:08 -0700 (PDT) Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id DFF7C39800E for ; Tue, 2 May 2006 12:50:03 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k42Jo10e008961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fb0sj-0005Ql-I0; Tue, 02 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 02 May 2006 15:50:01 -0400 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-13.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: -2.6 (--) 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-13.txt Pages : 56 Date : 2006-5-2 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-13.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-13.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-13.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-5-2135829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-2135829.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 eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 02 16:43:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1ik-0005Ct-03 for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:43:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1ij-0007PL-A2 for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:43:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87A3D43013E for ; Tue, 2 May 2006 13:43:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ACCE84300A2 for ; Tue, 2 May 2006 13:43:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3DD411448035 for ; Tue, 2 May 2006 13:43:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 804B8144801A for ; Tue, 2 May 2006 13:43:21 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 02 May 2006 13:43:21 -0700 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 k42KhKw1027125; Tue, 2 May 2006 13:43:20 -0700 (PDT) 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: Issue 360: EMSK Transport Date: Tue, 2 May 2006 13:50:49 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63212@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 360: EMSK Transport Thread-Index: AcZt6IXJxABN5DNzTieQ2ojJMTyAWAAFXxLgAAa3kzAAA71kgA== From: "Salowey, Joe" To: "Narayanan, Vidya" , "Bernard Aboba" , 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.4 tagged_above=-999.0 required=7.0 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: b132cb3ed2d4be2017585bf6859e1ede The document should not discuss where the EMSK is exported to from the EAP method as this may be implementation dependent. =20 Here is some suggested text (should go in 1.4 instead of section 2). =20 "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 outside the EAP Server=20 by the AAA layer. As noted in [RFC3748] Section 7.10:" Joe > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, May 02, 2006 12:07 PM > To: Salowey, Joe; Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: Issue 360: EMSK Transport >=20 > Hi Joe, > The text suggests that the AAA layer MUST NOT transport the EMSK, not > that the AAA layer MUST NOT transport the EMSK outside the entity. To > me, this implied that the EMSK MUST NOT be transported to other layers > within the same entity as well.=20 >=20 > Due to the current means of key transport, the EMSK arrives at the AAA > layer when the MSK arrives. But, we may (I'm not sure yet)=20 > need the EMSK > to be available to the EAP layer for further key derivation - the AAA > layer is potentially not the right layer to be deriving the=20 > keys - then, > that would imply that the lower layer in the peer is the one deriving > the same keys. This, apart from being disparate, also means that every > lower layer now needs to define this derivation, which seems > undesirable.=20 >=20 > So, pending discussion, I'd like to not have this statement in the > current spec.=20 >=20 > Vidya >=20 > > -----Original Message----- > > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > > Sent: Tuesday, May 02, 2006 8:45 AM > > To: Bernard Aboba; eap@frascone.com > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > >=20 > > I don't see the text as harmful. It may be somewhat=20 > > redundant, but I would like to better understand why its=20 > > presence is restrictive. That would seem to indicate that it=20 > > is not redundant.=20 > >=20 > > Joe =20 > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, May 02, 2006 5:54 AM > > > To: eap@frascone.com > > > Subject: [eap] Re: Issue 360: EMSK Transport > > >=20 > > > Since EMSK sharing is prohibited elsewhere in the document,=20 > > the text=20 > > > to be deleted is redundant at best. Any objections to=20 > > accepting the=20 > > > proposed change? > > >=20 > > >=20 > >=20 > --------------------------------------------------------------------- > > > Issue 360: EMSK Transport > > > Submitter name: Vidya Narayanan > > > Submitter email address: vidyan@qualcomm.com Date=20 > Submitted: May 1,=20 > > > 2006 > > > Reference: http://lists.frascone.com/pipermail/eap/msg04230.html > > > Document: KEYING-12 > > > Comment type: 'T'echnical > > > Priority: '1' Should fix > > > Section: 2 > > > Rationale/Explanation of issue: > > >=20 > > > The section says "The EMSK MUST NOT be transported by the=20 > > AAA layer." > > > Given that the EMSK usage is currently undefined, it is not=20 > > clear if=20 > > > it will be the AAA layer that derives further keys from the=20 > > EMSK. In=20 > > > fact, doing so will create disparate behavior at the peer=20 > > and server,=20 > > > since the peer does not have a AAA layer. Although this topic is=20 > > > pending discussion, it seems restrictive to say MUST NOT=20 > > here. It does=20 > > > make sense, however, to say that the EMSK MUST NOT be=20 > > transported to=20 > > > additional parties. > > >=20 > > > Requested change: > > >=20 > > > Delete the sentence "The EMSK MUST NOT be transported by the AAA=20 > > > 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 > > _________________________________________________________________ > > 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 Tue May 02 16:58:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1xA-0000pD-B1 for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:58:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1x7-0008BR-RK for eap-archive@lists.ietf.org; Tue, 02 May 2006 16:58:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 00479430148 for ; Tue, 2 May 2006 13:58:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CB8994300A2 for ; Tue, 2 May 2006 13:58:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BA48039804C for ; Tue, 2 May 2006 13:58:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 93050398047 for ; Tue, 2 May 2006 13:58:16 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 May 2006 13:58:16 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="272279305:sNHT27384104" 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 k42KwGw1007429 for ; Tue, 2 May 2006 13:58:16 -0700 (PDT) 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 Date: Tue, 2 May 2006 14:05:44 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63220@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: Section 2.2 title Thread-Index: AcZuKyE5/uk+f2IgQ2iGvZzPronbqw== From: "Salowey, Joe" To: 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: Subject: [eap] ISSUE: Section 2.2 title 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/02/06 Reference:Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 2.2 Rationale/Explanation of issue: This section discusses peer architecture as well as authenticator architecture. =20 Suggest title: "2.2. Authenticator and Peer Architecture" _________________________________________________________________ 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 May 02 17:13:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2BM-0007mM-T4 for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:13:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2BM-0000LF-GJ for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:13:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DA334430156 for ; Tue, 2 May 2006 14:13:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 118DA4300A5 for ; Tue, 2 May 2006 14:13:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ED4E3398029 for ; Tue, 2 May 2006 14:13:05 -0700 (PDT) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id CEFBC398047 for ; Tue, 2 May 2006 14:13:02 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k42LOwh9018538 for ; Tue, 2 May 2006 14:25:01 -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 k42LOsOi027093 for ; Tue, 2 May 2006 16:24:54 -0500 (CDT) 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] Issue: Child key expiry Date: Tue, 2 May 2006 17:12:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Issue: Child key expiry thread-index: AcZtrZxBC8itJ+lTQBmuNY+he8XmMAAfvRsw From: "Nakhjiri Madjid-MNAKHJI1" To: 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: 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 I like the last sentence. We need to allow future specs that derive keys from EMSK to define their own key authorization/ life time policies. However, given that EMSK is not exported, while MSK is and TSK are derived from MSK, then the last sentence is probably best inserted whenever EMSK is being described not here.=20 Madjid -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Tuesday, May 02, 2006 1:00 AM To: eap@frascone.com Subject: [eap] Issue: Child key expiry=20 Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date first submitted: 5/01/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: '2' May fix=20 Section: 3.3 Rationale/Explanation of issue:=20 This section states "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." This seems to indicate that the keys derived from the EMSK will also be expired when the EMSK expires. It is not yet clear if this would apply to all kinds of keys derived from the EMSK. There may be classes of keys derived from the EMSK for which different lifetime guidelines apply. So, it may be good to clarify that the EMSK usage documents will specify the guidelines for EMSK-based child keys.=20 =20 Requested change: Change=20 "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs."=20 to=20 "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs. Note that different lifetime guidelines may be specified in future specifications for EMSK-based child keys." _________________________________________________________________ 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 May 02 17:18:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2GN-0000Wi-HA for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:18:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2GM-0000QN-4d for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:18:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 89B6643011C for ; Tue, 2 May 2006 14:18:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 023C44300A5 for ; Tue, 2 May 2006 14:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA68E1448022 for ; Tue, 2 May 2006 14:18:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 3E8061448007 for ; Tue, 2 May 2006 14:18:11 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 14:18:11 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800693592:sNHT28214584" 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 k42LIART011196 for ; Tue, 2 May 2006 14:18:10 -0700 (PDT) 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 Date: Tue, 2 May 2006 14:25:39 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F6323D@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: section 2.1 AAA key caching Thread-Index: AcZuLelTJleESWJIQzONzqUJ6hWG/Q== From: "Salowey, Joe" To: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] Issue: section 2.1 AAA key caching 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/02/06 Reference:=20 Document: Keying Framework Comment type: T Priority: 2 =20 Section: 2.1 Rationale/Explanation of issue: The Current draft states that keys may not be cached once transported. I am wondering if this is too restrictive. Perhaps keys will be cached for session recovery and availability purposes. =20 Suggested Text: "In order to avoid key reuse, the AAA layer SHOULD delete transported keys once they are sent. The AAA layer SHOULD NOT retain keys that it has previously sent. For example, a AAA layer that has transported the MSK SHOULD delete it. If the AAA layer does cache an MSK then the use of TSKs derived from the MSK MUST prevent key reuse. " _________________________________________________________________ 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 May 02 17:27:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2PW-0001lh-31 for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:27:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2PV-0000nl-GP for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:27:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D2C644300F3 for ; Tue, 2 May 2006 14:27:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 82BCE4300A2 for ; Tue, 2 May 2006 14:27:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7447D398029 for ; Tue, 2 May 2006 14:27:37 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id A7C2B39800E for ; Tue, 2 May 2006 14:27:33 -0700 (PDT) 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 k42LRW4g009588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 14:27:32 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42LRTA3019440; Tue, 2 May 2006 14:27:31 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 14:27:29 -0700 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: Issue 360: EMSK Transport Date: Tue, 2 May 2006 14:27:21 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84792105@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 360: EMSK Transport Thread-Index: AcZt6IXJxABN5DNzTieQ2ojJMTyAWAAFXxLgAAa3kzAAA71kgAAB08lQ From: "Narayanan, Vidya" To: "Salowey, Joe" , "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2006 21:27:29.0018 (UTC) FILETIME=[36E5B5A0:01C66E2F] 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: 87a3f533bb300b99e2a18357f3c1563d This would be fine.=20 Vidya=20 > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, May 02, 2006 1:51 PM > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: Issue 360: EMSK Transport >=20 > The document should not discuss where the EMSK is exported to=20 > from the EAP method as this may be implementation dependent. =20 >=20 > Here is some suggested text (should go in 1.4 instead of section 2). =20 >=20 > "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=20 > entity outside > the EAP server or peer from which the EMSK could be=20 > computed without > breaking some cryptographic assumption, such as inverting a one-way > function. The EMSK MUST NOT be transported outside the EAP Server=20 > by the AAA layer. As noted in [RFC3748] Section 7.10:" >=20 > Joe >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, May 02, 2006 12:07 PM > > To: Salowey, Joe; Bernard Aboba; eap@frascone.com > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > >=20 > > Hi Joe, > > The text suggests that the AAA layer MUST NOT transport the=20 > EMSK, not=20 > > that the AAA layer MUST NOT transport the EMSK outside the=20 > entity. To=20 > > me, this implied that the EMSK MUST NOT be transported to=20 > other layers=20 > > within the same entity as well. > >=20 > > Due to the current means of key transport, the EMSK arrives=20 > at the AAA=20 > > layer when the MSK arrives. But, we may (I'm not sure yet) need the=20 > > EMSK to be available to the EAP layer for further key=20 > derivation - the=20 > > AAA layer is potentially not the right layer to be deriving=20 > the keys -=20 > > then, that would imply that the lower layer in the peer is the one=20 > > deriving the same keys. This, apart from being disparate,=20 > also means=20 > > that every lower layer now needs to define this derivation, which=20 > > seems undesirable. > >=20 > > So, pending discussion, I'd like to not have this statement in the=20 > > current spec. > >=20 > > Vidya > >=20 > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, May 02, 2006 8:45 AM > > > To: Bernard Aboba; eap@frascone.com > > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > > >=20 > > > I don't see the text as harmful. It may be somewhat=20 > redundant, but I=20 > > > would like to better understand why its presence is restrictive. =20 > > > That would seem to indicate that it is not redundant. > > >=20 > > > Joe > > >=20 > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 5:54 AM > > > > To: eap@frascone.com > > > > Subject: [eap] Re: Issue 360: EMSK Transport > > > >=20 > > > > Since EMSK sharing is prohibited elsewhere in the document, > > > the text > > > > to be deleted is redundant at best. Any objections to > > > accepting the > > > > proposed change? > > > >=20 > > > >=20 > > >=20 > >=20 > --------------------------------------------------------------------- > > > > Issue 360: EMSK Transport > > > > Submitter name: Vidya Narayanan > > > > Submitter email address: vidyan@qualcomm.com Date > > Submitted: May 1, > > > > 2006 > > > > Reference: http://lists.frascone.com/pipermail/eap/msg04230.html > > > > Document: KEYING-12 > > > > Comment type: 'T'echnical > > > > Priority: '1' Should fix > > > > Section: 2 > > > > Rationale/Explanation of issue: > > > >=20 > > > > The section says "The EMSK MUST NOT be transported by the > > > AAA layer." > > > > Given that the EMSK usage is currently undefined, it is not > > > clear if > > > > it will be the AAA layer that derives further keys from the > > > EMSK. In > > > > fact, doing so will create disparate behavior at the peer > > > and server, > > > > since the peer does not have a AAA layer. Although this=20 > topic is=20 > > > > pending discussion, it seems restrictive to say MUST NOT > > > here. It does > > > > make sense, however, to say that the EMSK MUST NOT be > > > transported to > > > > additional parties. > > > >=20 > > > > Requested change: > > > >=20 > > > > Delete the sentence "The EMSK MUST NOT be transported=20 > by the AAA=20 > > > > layer". > > > >=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 > > > _________________________________________________________________ > > > 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 May 02 17:49:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2kb-0005v8-My for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:49:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2ka-0001lS-63 for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:49:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1FF9343012C for ; Tue, 2 May 2006 14:49:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 68F0C4300A2 for ; Tue, 2 May 2006 14:49:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BF5C398048 for ; Tue, 2 May 2006 14:49:27 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id CF69E398029 for ; Tue, 2 May 2006 14:49:24 -0700 (PDT) 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 k42LkEIE011679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 14:46:14 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-121.qualcomm.com [10.50.65.121]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42Lk8qJ026322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 14:46:12 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502144505.0584fe88@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 14:46:09 -0700 To: "Salowey, Joe" , "Narayanan, Vidya" , "Bernard Aboba" , From: Lakshminath Dondeti Subject: RE: [eap] Re: Issue 360: EMSK Transport In-Reply-To: <7210B31550AC934A8637D6619739CE6906F63212@e2k-sea-xch2.sea- alpha.cisco.com> References: <7210B31550AC934A8637D6619739CE6906F63212@e2k-sea-xch2.sea-alpha.cisco.com> 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: 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: 6640e3bbe8a4d70c4469bcdcbbf0921d I am having a logical problem parsing "The EMSK MUST NOT be transported outside the EAP Server by the AAA layer." Does that allow transport of EMSK by other layers? I know that's not the intent. regards, Lakshminath At 01:50 PM 5/2/2006, Salowey, Joe wrote: >The document should not discuss where the EMSK is exported to from the >EAP method as this may be implementation dependent. > >Here is some suggested text (should go in 1.4 instead of section 2). > >"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 outside the EAP Server > by the AAA layer. As noted in [RFC3748] Section 7.10:" > >Joe > > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, May 02, 2006 12:07 PM > > To: Salowey, Joe; Bernard Aboba; eap@frascone.com > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > > > > Hi Joe, > > The text suggests that the AAA layer MUST NOT transport the EMSK, not > > that the AAA layer MUST NOT transport the EMSK outside the entity. To > > me, this implied that the EMSK MUST NOT be transported to other layers > > within the same entity as well. > > > > Due to the current means of key transport, the EMSK arrives at the AAA > > layer when the MSK arrives. But, we may (I'm not sure yet) > > need the EMSK > > to be available to the EAP layer for further key derivation - the AAA > > layer is potentially not the right layer to be deriving the > > keys - then, > > that would imply that the lower layer in the peer is the one deriving > > the same keys. This, apart from being disparate, also means that every > > lower layer now needs to define this derivation, which seems > > undesirable. > > > > So, pending discussion, I'd like to not have this statement in the > > current spec. > > > > Vidya > > > > > -----Original Message----- > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, May 02, 2006 8:45 AM > > > To: Bernard Aboba; eap@frascone.com > > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > > > > > > I don't see the text as harmful. It may be somewhat > > > redundant, but I would like to better understand why its > > > presence is restrictive. That would seem to indicate that it > > > is not redundant. > > > > > > Joe > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 5:54 AM > > > > To: eap@frascone.com > > > > Subject: [eap] Re: Issue 360: EMSK Transport > > > > > > > > Since EMSK sharing is prohibited elsewhere in the document, > > > the text > > > > to be deleted is redundant at best. Any objections to > > > accepting the > > > > proposed change? > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Issue 360: EMSK Transport > > > > Submitter name: Vidya Narayanan > > > > Submitter email address: vidyan@qualcomm.com Date > > Submitted: May 1, > > > > 2006 > > > > Reference: http://lists.frascone.com/pipermail/eap/msg04230.html > > > > Document: KEYING-12 > > > > Comment type: 'T'echnical > > > > Priority: '1' Should fix > > > > Section: 2 > > > > Rationale/Explanation of issue: > > > > > > > > The section says "The EMSK MUST NOT be transported by the > > > AAA layer." > > > > Given that the EMSK usage is currently undefined, it is not > > > clear if > > > > it will be the AAA layer that derives further keys from the > > > EMSK. In > > > > fact, doing so will create disparate behavior at the peer > > > and server, > > > > since the peer does not have a AAA layer. Although this topic is > > > > pending discussion, it seems restrictive to say MUST NOT > > > here. It does > > > > make sense, however, to say that the EMSK MUST NOT be > > > transported to > > > > additional parties. > > > > > > > > Requested change: > > > > > > > > Delete the sentence "The EMSK MUST NOT be transported by the 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 > > > > > >_________________________________________________________________ >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 May 02 17:50:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2lN-0005xU-Bp for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:50:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2lM-0001nk-V6 for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:50:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 94275430141 for ; Tue, 2 May 2006 14:50:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2FC354300A2 for ; Tue, 2 May 2006 14:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 035A939800E for ; Tue, 2 May 2006 14:50:07 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D5E9398047 for ; Tue, 2 May 2006 14:50:04 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42Lo2hm005945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 14:50:03 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-121.qualcomm.com [10.50.65.121]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42LnxXV027640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 14:50:01 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502144856.03b4ee18@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 14:50:00 -0700 To: "Salowey, Joe" , From: Lakshminath Dondeti Subject: Re: [eap] Issue: section 2.1 AAA key caching In-Reply-To: <7210B31550AC934A8637D6619739CE6906F6323D@e2k-sea-xch2.sea- alpha.cisco.com> References: <7210B31550AC934A8637D6619739CE6906F6323D@e2k-sea-xch2.sea-alpha.cisco.com> 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: 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 Hi Joe, I don't understand the last sentence: "If the AAA layer does cache an MSK then the use of TSKs derived from the MSK MUST prevent key reuse. " The rest of the text looks good and covers the robustness considerations you bring up. regards, Lakshminath At 02:25 PM 5/2/2006, Salowey, Joe wrote: >Submitter name: Joe Salowey >Submitter email address: jsalowey@cisco.com >Date first submitted: 05/02/06 >Reference: >Document: Keying Framework >Comment type: T >Priority: 2 >Section: 2.1 >Rationale/Explanation of issue: > >The Current draft states that keys may not be cached once transported. I >am wondering if this is too restrictive. Perhaps keys will be cached >for session recovery and availability purposes. > >Suggested Text: > > "In order to avoid key reuse, the AAA layer SHOULD delete transported > keys once they are sent. The AAA layer SHOULD NOT retain keys that > it has previously sent. For example, a AAA layer that has > transported the MSK SHOULD delete it. If the AAA layer does cache an >MSK > then the use of TSKs derived from the MSK MUST prevent key reuse. " > >_________________________________________________________________ >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 May 02 17:57:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2sR-0006KG-DA for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:57:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2sJ-00021Y-Td for eap-archive@lists.ietf.org; Tue, 02 May 2006 17:57:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 89F6E430140 for ; Tue, 2 May 2006 14:57:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D47E94300A2 for ; Tue, 2 May 2006 14:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9FF7F1448038 for ; Tue, 2 May 2006 14:57:26 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id 3EE551448001 for ; Tue, 2 May 2006 14:57:22 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k42LvLRe022294; Wed, 3 May 2006 06:57:21 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k42LwXaj007835; Wed, 3 May 2006 06:58:33 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id GAA07788; Wed, 3 May 2006 06:58:33 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k42LvKkJ001392; Wed, 3 May 2006 06:57:20 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42LvJjH002805; Wed, 3 May 2006 06:57:19 +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 <0IYN002MBRNDGN00@mail.po.toshiba.co.jp>; Wed, 03 May 2006 06:57:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fb2rV-0004mH-64; Tue, 02 May 2006 14:56:53 -0700 Date: Tue, 02 May 2006 17:56:53 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: To: Bernard Aboba Message-id: <20060502215653.GH13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060502165649.GB13251@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 41c17b4b16d1eedaa8395c26e9a251c4 On Tue, May 02, 2006 at 12:26:42PM -0700, Bernard Aboba wrote: > >Thank you for reading the document. And the answer is, if the > >generated "mixed" MSKs are carried in the existing AAA attributes > >instead of carrying the MSKs, then no AAA attributes or communication > >flow is required for EAP keying. > > It might be worth saying a few words about this in the paragraph. I agree on adding a few words on this in the paragraph. > Overall, > I'm not sure whether the Channel Binding text in the document is all that > consistent/comprehesive. I agree with your opinion here as well. Let me quote some questionable part in Section 5.11 of eap-keying-13 below: " As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. " I'd mention that Channel Binding description in RFC3748 is somewhat obsolete according to the recent discussion on the AAA server's requirement on pre-configurating Channel Binding parameters. Do we need this paragraph? Or instead we may have some explicit text here to obsolete Channel Binding description in RFC3748. " Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. For example, see the discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity- auth]. " According to the the AAA server's requirement on pre-configurating Channel Binding parameters, I don't see the usefulness of [I-D.arkko-eap-service-identity-auth]. Do we really need this paragraph? " The main difference between these approaches is that Channel Binding support within an EAP method may require upgrading or changing the EAP method, impacting both the peer and the server. Where Channel Bindings are implemented in AAA, the peer, authenticator and the backend server need to be upgraded, but the EAP method need not be modified. " If we have only one Channel Binding method, we don't need this comparison. Best regards, Yoshihiro Ohba _________________________________________________________________ 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 May 02 18:02:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2xA-0005ot-DZ for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:02:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2x8-00029d-Vj for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:02:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 455FF43016A for ; Tue, 2 May 2006 15:02:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BCD014300A2 for ; Tue, 2 May 2006 15:02:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AA8781448009 for ; Tue, 2 May 2006 15:02:26 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 152D31448001 for ; Tue, 2 May 2006 15:02:23 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M2MHH007783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 15:02:23 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M2HY8002724; Tue, 2 May 2006 15:02:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 15:02:20 -0700 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: issue 357: Channel Binding Definition Date: Tue, 2 May 2006 15:02:21 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8479212B@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZuHd882hfDeG50Rl+hUH94V73fQAAE5SYw From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2006 22:02:20.0284 (UTC) FILETIME=[156393C0:01C66E34] 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.0 tagged_above=-999.0 required=7.0 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 I don't think the channel binding information needs to be the same for all parties. For e.g., consider a case where the server has a view of the SSIDs for which a given MSK is valid. The peer at a given moment may only see a subset of the SSIDs - as it moves though, it needs to know that a new SSID it sees may or may not use that MSK for TSK derivation.=20 For this reason, actually mixing of the keys with channel binding data doesn't quite make sense to me yet. This implies that the peer has a complete view of the channel binding data at a given time, which does not seem to make practical sense in all models of deployment.=20 It may make sense for the peer have the entire channel binding data from the server - as it moves, it can compare to see if what it sees is a subset of that data it received from the server or not. Alternately, the peer just needs confirmation from the server that what it sees is valid. Vidya > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 12:23 PM > To: Narayanan, Vidya; eap@frascone.com > Subject: RE: [eap] Re: issue 357: Channel Binding Definition >=20 > That makes sense. Do we also need to indicate that the=20 > channel bindings need to be the same for all parties? For example: >=20 > "Channel Binding >=20 > A secure mechanism for ensuring the synchronization and=20 > correctness of channel properties (such as endpoint=20 > identifiers) provided to the EAP peer, authenticator and server." >=20 > >Minor clarification: > > > >"Channel Binding > > > >A *secure* mechanism for ensuring the correctness of channel=20 > properties=20 > >(such as endpoint identifiers) provided to the EAP peer,=20 > authenticator=20 > >and server. " > > > >The word secure is to imply that if this data is in fact=20 > sent as a blob=20 > >between the peer and server, it must be integrity protected. > > > >Vidya >=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 May 02 18:09:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb33G-0004m0-Ir for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:09:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb33F-0002GS-1R for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:09:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A83004300B2 for ; Tue, 2 May 2006 15:09:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7ABC94300A2 for ; Tue, 2 May 2006 15:08:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 63E4B398036 for ; Tue, 2 May 2006 15:08:41 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 96B8B39800E for ; Tue, 2 May 2006 15:08:38 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M8b5f014619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 15:08:38 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M8aJP004311; Tue, 2 May 2006 15:08:37 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 15:08:36 -0700 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: issue 361: child key expiry Date: Tue, 2 May 2006 15:08:38 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84792131@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 361: child key expiry Thread-Index: AcZuHV5BmEzupqq1Sa+/rFJ+9Lf22QAF2WVg From: "Narayanan, Vidya" To: "Bernard Aboba" , "Dondeti, Lakshminath" , X-OriginalArrivalTime: 02 May 2006 22:08:36.0260 (UTC) FILETIME=[F57CF640:01C66E34] 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: e1b0e72ff1bbd457ceef31828f216a86 Bernard, Lakshminath, While this is an interesting discussion, I feel that the EMSK specifics with respect to caching and lifetime as well as child key properties need to be discussed in the EMSK usage document. We can continue having this discussion in light of the EMSK usage document.=20 For the purpose of EAP keying document, can we not add that sentence about a future EMSK usage document and leave it at that?=20 However, if there are things that need to be clarified here with respect to the MSK, we should certainly do that in this document.=20 Thanks, Vidya=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 12:19 PM > To: Dondeti, Lakshminath; eap@frascone.com > Subject: Re: [eap] Re: issue 361: child key expiry >=20 > >I wasn't thinking about PANA, but thinking about the use=20 > case of client=20 > >authentication in IPsec remote access using EAP. Whereas EAP can be=20 > >used every time, it is plausible that the MSK is cached as the IKEv2=20 > >Preshared key for future authentication to avoid EAP latency. >=20 > Perhaps we can say that RFC 4306 does not support key=20 > caching? It seems that an extension to IKEv2 would be=20 > required to support this, since otherwise the IKE initiator=20 > and responder couldn't negotiate whether cached EAP keys are=20 > to be used, and if so, which ones. >=20 > >>Are you suggesting that there might be situations in which EAP keys=20 > >>aren't used for key derivation, but compromise might still=20 > be possible? > > > >No. I am asking if the MSK/EMSK figures into the key=20 > derivation, say=20 > >only partially (say along with DH), compromise of MSK/EMSK means=20 > >compromise of derived keys. I was then saying perhaps that is too=20 > >restrictive, but I'd contend not, unless there is a strong=20 > case made for the alternative. >=20 > OK. If the MSK/EMSK were mixed into the key derivation, then=20 > there might be some weakening of the key derivation. How=20 > much depends on the algorithm. >=20 > >If that's confusing too, please let me know. >=20 > I understand the point.... question is how we make it clear=20 > in the text. >=20 > >>Right. And by the same logic, the MSK and EMSK might expire at=20 > >>different times. I'm not sure that the key lifetime section takes=20 > >>that into account adequately. > > > >That sounds right and the clarification will be good. >=20 > Suggestions welcome. >=20 > >>This makes sense assuming that the entity authentiation keys aren't=20 > >>themselves derived from the EMSK. > > > >Even if entity authentication keys are derived from the EMSK, the=20 > >guideline applies, I think. Suppose the EMSK supports=20 > derivation of a=20 > >traffic key and a separate entity authentication key,=20 > wouldn't it make=20 > >sense to say that, all other things being equal, the traffic=20 > key will=20 > >have a shorter lifetime than the entity authentication key,=20 > based on key usage? >=20 > Yes, it would make sense. I guess I'd distinguish between a=20 > key calculated=20 > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that=20 > have been suggested so far are static -- that is, they are=20 > based on a key-label, but do not generate a fresh key every=20 > time they are invoked on the same EMSK, in the way that some=20 > TSK derivations do (e.g. 802.11i 4-way handshake). >=20 > Unless there is an ability to generate fresh keys without an=20 > EAP re-authentication, then when the derived keyexpires it is=20 > necessary to do an EAP re-authentication. With TSKs it may=20 > be possible to do a re-key independent of EAP (e.g. 802.11i=20 > 4-way handshake). >=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 May 02 18:11:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb35L-0006Ix-0m for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:11:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb35J-0002I9-IV for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:11:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1A63043011C for ; Tue, 2 May 2006 15:11:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 253DC4300A2 for ; Tue, 2 May 2006 15:10:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 129381448031 for ; Tue, 2 May 2006 15:10:56 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id D941A1448020 for ; Tue, 2 May 2006 15:10:52 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 02 May 2006 15:10:52 -0700 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 k42MAqh0021149; Tue, 2 May 2006 15:10:52 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Tue, 2 May 2006 15:18:20 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F6327D@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZuNICIFdTSrntrTqiHHkfCIoJSLAAAA6OQ From: "Salowey, Joe" To: "Yoshihiro Ohba" , "Bernard Aboba" 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.4 tagged_above=-999.0 required=7.0 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: 52f7a77164458f8c7b36b66787c853da =20 > As noted in [RFC3748] Section 7.15, this vulnerability can be > addressed by EAP methods that support a protected exchange of channel > properties such as endpoint identifiers, including (but not limited > to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id > [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address > [RFC2865], and NAS-IPv6-Address [RFC3162]. > " >=20 > I'd mention that Channel Binding description in RFC3748 is somewhat > obsolete according to the recent discussion on the AAA server's > requirement on pre-configurating Channel Binding parameters. Do we > need this paragraph? Or instead we may have some explicit text here > to obsolete Channel Binding description in RFC3748. >=20 [Joe] I don't see how this text is obsolete. Channel binding is not just an EAP-keying concept.=20 >=20 > " > Using such a protected exchange, it is possible to match the channel > properties provided by the authenticator via out-of-band mechanisms > against those exchanged within the EAP method. For example, see the > discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity- > auth]. > " >=20 > According to the the AAA server's requirement on pre-configurating > Channel Binding parameters, I don't see the usefulness of > [I-D.arkko-eap-service-identity-auth]. Do we really need this > paragraph? >=20 [Joe] It still seems useful to me.=20 >=20 > " > The main difference between these approaches is that Channel Binding > support within an EAP method may require upgrading or changing the > EAP method, impacting both the peer and the server. Where Channel > Bindings are implemented in AAA, the peer, authenticator and the > backend server need to be upgraded, but the EAP method need not be > modified. > " >=20 > If we have only one Channel Binding method, we don't need this > comparison. [Joe] I don't think this is the place to define one method. > Best regards, > Yoshihiro Ohba > _________________________________________________________________ > 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 May 02 18:14:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb38G-000716-3W for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:14:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb38E-0002Ni-La for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:14:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3413143012A for ; Tue, 2 May 2006 15:14:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1AD534300A2 for ; Tue, 2 May 2006 15:13:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CEF2C1448020 for ; Tue, 2 May 2006 15:13:54 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 352C41448001 for ; Tue, 2 May 2006 15:13:51 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 02 May 2006 15:13:51 -0700 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 k42MDph0023220; Tue, 2 May 2006 15:13:51 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Tue, 2 May 2006 15:21:19 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63281@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZuH4bVH1+n20qPSCqV+TbCyLQUbQAFhFMg From: "Salowey, Joe" To: "Bernard Aboba" , 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.4 tagged_above=-999.0 required=7.0 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: b19722fc8d3865b147c75ae2495625f2 I'm not sure that carrying "mixed" MSKs in existing attributes is such a good idea, how does the authenticator know what it is getting?=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 12:27 PM > To: yohba@tari.toshiba.com > Cc: eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > >Thank you for reading the document. And the answer is, if the > >generated "mixed" MSKs are carried in the existing AAA attributes > >instead of carrying the MSKs, then no AAA attributes or communication > >flow is required for EAP keying. >=20 > It might be worth saying a few words about this in the=20 > paragraph. Overall,=20 > I'm not sure whether the Channel Binding text in the document=20 > is all that=20 > consistent/comprehesive. >=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 May 02 18:43:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3aE-0004XB-0E for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:43:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3aC-0004xi-EZ for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:43:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 70D1043015C for ; Tue, 2 May 2006 15:43:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 956064300A2 for ; Tue, 2 May 2006 15:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7EB3B398029 for ; Tue, 2 May 2006 15:42:47 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5BA5E398041 for ; Tue, 2 May 2006 15:42:42 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k42MgUii003981; Wed, 3 May 2006 07:42:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k42MgVjj005340; Wed, 3 May 2006 07:42:31 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id HAA05307; Wed, 3 May 2006 07:42:31 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k42MgUZF028678; Wed, 3 May 2006 07:42:30 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42MgUq7005569; Wed, 3 May 2006 07:42:30 +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 <0IYN002WVTQNGO00@mail.po.toshiba.co.jp>; Wed, 03 May 2006 07:42:30 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fb3ZU-0004uS-Ci; Tue, 02 May 2006 15:42:20 -0700 Date: Tue, 02 May 2006 18:42:20 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB8479212B@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060502224220.GJ13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8479212B@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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: b7b9551d71acde901886cc48bfc088a6 On Tue, May 02, 2006 at 03:02:21PM -0700, Narayanan, Vidya wrote: > I don't think the channel binding information needs to be the same for > all parties. For e.g., consider a case where the server has a view of > the SSIDs for which a given MSK is valid. The peer at a given moment may > only see a subset of the SSIDs - as it moves though, it needs to know > that a new SSID it sees may or may not use that MSK for TSK derivation. > > For this reason, actually mixing of the keys with channel binding data > doesn't quite make sense to me yet. This implies that the peer has a > complete view of the channel binding data at a given time, which does > not seem to make practical sense in all models of deployment. Since I don't think the complete channel binding data is so large, I don't see a practical issue here. What is deployment scenario in your mind? > > It may make sense for the peer have the entire channel binding data from > the server - as it moves, it can compare to see if what it sees is a > subset of that data it received from the server or not. I don't think only comparing subset of that data with the server does not work for Channel Binding verification, as an attacker can still fool around the rest of data that is not part of the subset. > Alternately, the > peer just needs confirmation from the server that what it sees is valid. This requires channel bindind data to be sent from the peer to server, while the server pre-configures the channel bindind data. This is redundant information exchange to me. Yoshihiro Ohba > > > Vidya > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 12:23 PM > > To: Narayanan, Vidya; eap@frascone.com > > Subject: RE: [eap] Re: issue 357: Channel Binding Definition > > > > That makes sense. Do we also need to indicate that the > > channel bindings need to be the same for all parties? For example: > > > > "Channel Binding > > > > A secure mechanism for ensuring the synchronization and > > correctness of channel properties (such as endpoint > > identifiers) provided to the EAP peer, authenticator and server." > > > > >Minor clarification: > > > > > >"Channel Binding > > > > > >A *secure* mechanism for ensuring the correctness of channel > > properties > > >(such as endpoint identifiers) provided to the EAP peer, > > authenticator > > >and server. " > > > > > >The word secure is to imply that if this data is in fact > > sent as a blob > > >between the peer and server, it must be integrity protected. > > > > > >Vidya > > > > > > > _________________________________________________________________ > 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 May 02 18:56:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3mp-0002NY-M3 for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:56:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3mo-0005ZD-8K for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:56:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DDB274300C0 for ; Tue, 2 May 2006 15:56:05 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 333334300A2 for ; Tue, 2 May 2006 15:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C13C0398036 for ; Tue, 2 May 2006 15:55:48 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0BBA739800E for ; Tue, 2 May 2006 15:55:45 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k42MthVs004580; Wed, 3 May 2006 07:55:43 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k42MusO7002990; Wed, 3 May 2006 07:56:54 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id HAA02943; Wed, 3 May 2006 07:56:54 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k42MtfxE026282; Wed, 3 May 2006 07:55:41 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42MtdlN015546; Wed, 3 May 2006 07:55:39 +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 <0IYN0021FUCMGO10@mail.po.toshiba.co.jp>; Wed, 03 May 2006 07:55:39 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fb3mD-0004wb-FB; Tue, 02 May 2006 15:55:29 -0700 Date: Tue, 02 May 2006 18:55:29 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F63281@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060502225529.GK13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F63281@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: 21c69d3cfc2dd19218717dbe1d974352 On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > I'm not sure that carrying "mixed" MSKs in existing attributes is such a > good idea, how does the authenticator know what it is getting? I don't think the authenticator needs to know whether the received key is the MSK or mixed MSK, as long as both the peer and authenticator obtains the same key. Yoshihiro Ohba > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 12:27 PM > > To: yohba@tari.toshiba.com > > Cc: eap@frascone.com > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > >Thank you for reading the document. And the answer is, if the > > >generated "mixed" MSKs are carried in the existing AAA attributes > > >instead of carrying the MSKs, then no AAA attributes or communication > > >flow is required for EAP keying. > > > > It might be worth saying a few words about this in the > > paragraph. Overall, > > I'm not sure whether the Channel Binding text in the document > > is all that > > consistent/comprehesive. > > > > > > _________________________________________________________________ > > 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 May 02 18:58:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3p9-0002eu-SU for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:58:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3p8-0005c6-Da for eap-archive@lists.ietf.org; Tue, 02 May 2006 18:58:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 154EA43015C for ; Tue, 2 May 2006 15:58:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6D0B94300A2 for ; Tue, 2 May 2006 15:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4DDAC398036 for ; Tue, 2 May 2006 15:58:15 -0700 (PDT) Received: from hotmail.com (bay106-f14.bay106.hotmail.com [65.54.161.24]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F06B398022 for ; Tue, 2 May 2006 15:58:12 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 15:58:12 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 22:58:11 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060502225529.GK13251@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com, jsalowey@cisco.com Subject: Re: [eap] Re: Issue 352: Channel Binding Issue Date: Tue, 02 May 2006 15:58:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 22:58:12.0295 (UTC) FILETIME=[E357DD70:01C66E3B] 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: f4c2cf0bccc868e4cc88dace71fb3f44 Right. The method just outputs the MSK/EMSK. As long as the same MSK is outputted on both the EAP peer and server, the authenticator doesn't need to know what channel bindings were mixed in. >From: Yoshihiro Ohba >To: "Salowey, Joe" >CC: Bernard Aboba , yohba@tari.toshiba.com, > eap@frascone.com >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >Date: Tue, 02 May 2006 18:55:29 -0400 > >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > > I'm not sure that carrying "mixed" MSKs in existing attributes is such a > > good idea, how does the authenticator know what it is getting? > >I don't think the authenticator needs to know whether the received key >is the MSK or mixed MSK, as long as both the peer and authenticator >obtains the same key. > >Yoshihiro Ohba > > > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, May 02, 2006 12:27 PM > > > To: yohba@tari.toshiba.com > > > Cc: eap@frascone.com > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > >Thank you for reading the document. And the answer is, if the > > > >generated "mixed" MSKs are carried in the existing AAA attributes > > > >instead of carrying the MSKs, then no AAA attributes or communication > > > >flow is required for EAP keying. > > > > > > It might be worth saying a few words about this in the > > > paragraph. Overall, > > > I'm not sure whether the Channel Binding text in the document > > > is all that > > > consistent/comprehesive. > > > > > > > > > _________________________________________________________________ > > > 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 May 02 19:11:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb41G-0007aV-4N for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:11:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb41E-0005pN-NL for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:11:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C400430139 for ; Tue, 2 May 2006 16:11:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 00EA54300A2 for ; Tue, 2 May 2006 16:10:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0A7A1448046 for ; Tue, 2 May 2006 16:10:43 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id 548F9144804E for ; Tue, 2 May 2006 16:10:41 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 02 May 2006 16:10:41 -0700 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 k42NAew1009072 for ; Tue, 2 May 2006 16:10:40 -0700 (PDT) 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 Date: Tue, 2 May 2006 16:18:09 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632A9@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: Section 2.2.1 ambiguous use of identifier Thread-Index: AcZuPaCeFsckADYuTQ2Sp09yqXnHng== From: "Salowey, Joe" To: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] ISSUE: Section 2.2.1 ambiguous use of identifier 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/02/06 Reference:=20 Document: Keying Framework Comment type: T Priority: 1 =20 Section: 2.2.1 Rationale/Explanation of issue: Ambiguous use of "identifier": It is not clear in this section what the identifier is and what it is identifying. =20 Does this section mean to suggest that lower layer entities identify themselves using NAS-ID instead of layer addresses? I'm not sure that this is a good thing or even really possible. It seems that lower layer entities will identify themselves based on something related to lower layer addresses. It seems that if a lower layer implements key caching then it needs an identifier to identify the scope of the cache. This identifier can be the NAS-ID. I'm not quite sure I understand this section, but I think it just needs to be clearer about what identity is being talked about.=20 This section does not contain any description of how existing lower layers deal with authenticator identity. Are such examples available? _________________________________________________________________ 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 May 02 19:16:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb46H-0004Ta-BW for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:16:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb46F-0005tK-Sw for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:16:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB7D8430117 for ; Tue, 2 May 2006 16:16:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6B9634300B2 for ; Tue, 2 May 2006 16:15:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 593FC1448001 for ; Tue, 2 May 2006 16:15:56 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id B9C12144802B for ; Tue, 2 May 2006 16:15:54 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 02 May 2006 16:15:54 -0700 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 k42NFsw1013287; Tue, 2 May 2006 16:15:54 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Tue, 2 May 2006 16:23:22 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632AF@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZuPO96U/epYMXLSIagBwbsrlJA8QAAMCxQ From: "Salowey, Joe" To: "Bernard Aboba" , 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.4 tagged_above=-999.0 required=7.0 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: 31247fb3be228bb596db9127becad0bc Hmmm...=20 Peer gets MSK from EAP and mixes it with Y to get MSKY=20 Authenticator gets mixed MSKY in exisitng AAA attribute, since this is an exisitng attribute it thinks it is just the MSK and mixes it with Y to get MSKYY. MSKY and MSKYY don't match. It seems to me a separate attribute would really be better.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 02, 2006 3:58 PM > To: yohba@tari.toshiba.com; Salowey, Joe > Cc: eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > Right. The method just outputs the MSK/EMSK. As long as the=20 > same MSK is=20 > outputted on both the EAP peer and server, the authenticator=20 > doesn't need to=20 > know what channel bindings were mixed in. >=20 >=20 > >From: Yoshihiro Ohba > >To: "Salowey, Joe" > >CC: Bernard Aboba ,=20 > yohba@tari.toshiba.com, =20 > > eap@frascone.com > >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > >Date: Tue, 02 May 2006 18:55:29 -0400 > > > >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > > > I'm not sure that carrying "mixed" MSKs in existing=20 > attributes is such a > > > good idea, how does the authenticator know what it is getting? > > > >I don't think the authenticator needs to know whether the=20 > received key > >is the MSK or mixed MSK, as long as both the peer and authenticator > >obtains the same key. > > > >Yoshihiro Ohba > > > > > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 12:27 PM > > > > To: yohba@tari.toshiba.com > > > > Cc: eap@frascone.com > > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > > > >Thank you for reading the document. And the answer is, if the > > > > >generated "mixed" MSKs are carried in the existing AAA=20 > attributes > > > > >instead of carrying the MSKs, then no AAA attributes=20 > or communication > > > > >flow is required for EAP keying. > > > > > > > > It might be worth saying a few words about this in the > > > > paragraph. Overall, > > > > I'm not sure whether the Channel Binding text in the document > > > > is all that > > > > consistent/comprehesive. > > > > > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > 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 Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 02 19:19:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb49h-0006XM-9W for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:19:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb49f-0005wK-PX for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:19:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C1DD430149 for ; Tue, 2 May 2006 16:19:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3F67E4300B4 for ; Tue, 2 May 2006 16:19:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B66639800E for ; Tue, 2 May 2006 16:19:27 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24EF739802E for ; Tue, 2 May 2006 16:19:22 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k42NJKlO009002; Wed, 3 May 2006 08:19:20 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k42NKVCL013400; Wed, 3 May 2006 08:20:31 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id JAA13388; Wed, 3 May 2006 08:20:31 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k42NJIMK005578; Wed, 3 May 2006 08:19:18 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42NJIOR013762; Wed, 3 May 2006 08:19:18 +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 <0IYN002PEVFVGN10@mail.po.toshiba.co.jp>; Wed, 03 May 2006 08:19:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fb48q-00050n-Na; Tue, 02 May 2006 16:18:52 -0700 Date: Tue, 02 May 2006 19:18:52 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F6327D@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060502231852.GN13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F6327D@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: cd26b070c2577ac175cd3a6d878c6248 On Tue, May 02, 2006 at 03:18:20PM -0700, Salowey, Joe wrote: > > > > As noted in [RFC3748] Section 7.15, this vulnerability can be > > addressed by EAP methods that support a protected exchange of channel > > properties such as endpoint identifiers, including (but not limited > > to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id > > [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address > > [RFC2865], and NAS-IPv6-Address [RFC3162]. > > " > > > > I'd mention that Channel Binding description in RFC3748 is somewhat > > obsolete according to the recent discussion on the AAA server's > > requirement on pre-configurating Channel Binding parameters. Do we > > need this paragraph? Or instead we may have some explicit text here > > to obsolete Channel Binding description in RFC3748. > > > [Joe] I don't see how this text is obsolete. Channel binding is not > just an EAP-keying concept. I'd say the Channel Binding problem description in RFC3748 is valid, but the solution described in RFC 3748 would be a bit obsolete. > > > > > " > > Using such a protected exchange, it is possible to match the channel > > properties provided by the authenticator via out-of-band mechanisms > > against those exchanged within the EAP method. For example, see the > > discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity- > > auth]. > > " > > > > According to the the AAA server's requirement on pre-configurating > > Channel Binding parameters, I don't see the usefulness of > > [I-D.arkko-eap-service-identity-auth]. Do we really need this > > paragraph? > > > [Joe] It still seems useful to me. Can you elaborate on how it is useful? Regards, Yoshihiro Ohba > > > > > > " > > The main difference between these approaches is that Channel Binding > > support within an EAP method may require upgrading or changing the > > EAP method, impacting both the peer and the server. Where Channel > > Bindings are implemented in AAA, the peer, authenticator and the > > backend server need to be upgraded, but the EAP method need not be > > modified. > > " > > > > If we have only one Channel Binding method, we don't need this > > comparison. > > [Joe] I don't think this is the place to define one method. > > > > Best regards, > > Yoshihiro Ohba > > _________________________________________________________________ > > 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 May 02 19:20:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Ab-0007Dw-US for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:20:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4Aa-0005xN-GZ for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:20:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D9A29430165 for ; Tue, 2 May 2006 16:20:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 329B24300B2 for ; Tue, 2 May 2006 16:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 20AE3144802B for ; Tue, 2 May 2006 16:20:27 -0700 (PDT) Received: from hotmail.com (bay106-f27.bay106.hotmail.com [65.54.161.37]) by hermes.tigertech.net (Postfix) with ESMTP id 856211448012 for ; Tue, 2 May 2006 16:20:24 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 16:20:24 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 23:20:22 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060502224220.GJ13251@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com, vidyan@qualcomm.com Subject: Re: [eap] Re: issue 357: Channel Binding Definition Date: Tue, 02 May 2006 16:20:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 23:20:24.0084 (UTC) FILETIME=[FD26BD40:01C66E3E] 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: 4adaf050708fb13be3316a9eee889caa > > I don't think the channel binding information needs to be the same for > > all parties. The goal of Channel Bindings is to ensure that the EAP peer and server obtain correct information from the EAP authenticator. If a parameter is being validated by channel bindings and the authenticator gives a different value to the peer and server, then it will be detected. It is true that all participants may not have complete knowledge of all the channel properties. But if a parameter is included in channel bindings, then the goal is to ensure that the peer and server are hearing the same thing from the authenticator, so it seems to me that channel binding parameters need to be known by the peer, authenticator and server. >For e.g., consider a case where the server has a view of the SSIDs for >which a given MSK is valid. The server may have an opinion as to what SSIDs the peer is allowed to use (e.g. Allowed-SSIDs). This is useful in EAP pre-authentication where the server may not know what SSID the client wants to access yet (this isn't known until the peer associates). However in this case the SSID would not be considered to be part of channel bindings since the EAP peer has the information, but the authenticator and server do not. As a result, the peer cannot ask the server to verify the SSID, or include it in the calculation of the MSK. >As it moves though, it needs to know that a new SSID it sees may or may not >use that MSK for >TSK derivation. In 802.11, the advertisement of AP capabilities is handled in the Beacon. This allows the STA to know what security mechanisms are being used (WPA2, 11r, 11w, etc.). The capabilities are verified in the handshake between the STA and AP. However, there are AAA attributes corresponding to the AP security capabilities so that it is not possible for the EAP peer and server to verify that the authenticator has told them the same thing. As a result, I don't think that 802.11 security capabilites can be considered "channel bindings". _________________________________________________________________ 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 May 02 19:23:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4DB-0000Gt-9z for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:23:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4D8-000622-1Y for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:23:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53E004300C2 for ; Tue, 2 May 2006 16:23:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 283A94300C0 for ; Tue, 2 May 2006 16:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 18B96144801A for ; Tue, 2 May 2006 16:23:02 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id F20171448012 for ; Tue, 2 May 2006 16:22:58 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k42NMtWT010074; Wed, 3 May 2006 08:22:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k42NMuca005489; Wed, 3 May 2006 08:22:56 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id JAA05458; Wed, 3 May 2006 08:22:56 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k42NMtSc016513; Wed, 3 May 2006 08:22:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k42NMsm5014691; Wed, 3 May 2006 08:22:54 +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 <0IYN002REVLYGN10@mail.po.toshiba.co.jp>; Wed, 03 May 2006 08:22:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fb4CT-00051W-MB; Tue, 02 May 2006 16:22:37 -0700 Date: Tue, 02 May 2006 19:22:37 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F632AF@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060502232237.GO13251@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F632AF@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 34d35111647d654d033d58d318c0d21a On Tue, May 02, 2006 at 04:23:22PM -0700, Salowey, Joe wrote: > Hmmm... > > Peer gets MSK from EAP and mixes it with Y to get MSKY > Authenticator gets mixed MSKY in exisitng AAA attribute, since this is > an exisitng attribute it thinks it is just the MSK and mixes it with Y > to get MSKYY. MSKY and MSKYY don't match. There is some misunderstanding. If the authenticator is supposed to further mix Y to get MSKYY from MSKY, then the peer is also supposed to further mix Y to get MSKYY from MSKY. Yoshihiro Ohba > > It seems to me a separate attribute would really be better. > > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 3:58 PM > > To: yohba@tari.toshiba.com; Salowey, Joe > > Cc: eap@frascone.com > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > Right. The method just outputs the MSK/EMSK. As long as the > > same MSK is > > outputted on both the EAP peer and server, the authenticator > > doesn't need to > > know what channel bindings were mixed in. > > > > > > >From: Yoshihiro Ohba > > >To: "Salowey, Joe" > > >CC: Bernard Aboba , > > yohba@tari.toshiba.com, > > > eap@frascone.com > > >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > >Date: Tue, 02 May 2006 18:55:29 -0400 > > > > > >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > > > > I'm not sure that carrying "mixed" MSKs in existing > > attributes is such a > > > > good idea, how does the authenticator know what it is getting? > > > > > >I don't think the authenticator needs to know whether the > > received key > > >is the MSK or mixed MSK, as long as both the peer and authenticator > > >obtains the same key. > > > > > >Yoshihiro Ohba > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > Sent: Tuesday, May 02, 2006 12:27 PM > > > > > To: yohba@tari.toshiba.com > > > > > Cc: eap@frascone.com > > > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > > > > > >Thank you for reading the document. And the answer is, if the > > > > > >generated "mixed" MSKs are carried in the existing AAA > > attributes > > > > > >instead of carrying the MSKs, then no AAA attributes > > or communication > > > > > >flow is required for EAP keying. > > > > > > > > > > It might be worth saying a few words about this in the > > > > > paragraph. Overall, > > > > > I'm not sure whether the Channel Binding text in the document > > > > > is all that > > > > > consistent/comprehesive. > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > 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 May 02 19:24:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Eb-0000TW-Hk for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:24:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4Ea-00064g-4Z for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:24:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C490E430157 for ; Tue, 2 May 2006 16:24:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 647E14300B2 for ; Tue, 2 May 2006 16:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B9AE1448009 for ; Tue, 2 May 2006 16:24:33 -0700 (PDT) Received: from hotmail.com (bay106-f24.bay106.hotmail.com [65.54.161.34]) by hermes.tigertech.net (Postfix) with ESMTP id BB9A3144801A for ; Tue, 2 May 2006 16:24:30 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 16:24:30 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 23:24:27 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <7210B31550AC934A8637D6619739CE6906F63212@e2k-sea-xch2.sea-alpha.cisco.com> From: "Bernard Aboba" To: jsalowey@cisco.com, vidyan@qualcomm.com, eap@frascone.com Subject: RE: [eap] Re: Issue 360: EMSK Transport Date: Tue, 02 May 2006 16:24:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 23:24:30.0318 (UTC) FILETIME=[8FEB10E0:01C66E3F] 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: 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 I'm ok with this. >From: "Salowey, Joe" >To: "Narayanan, Vidya" , "Bernard Aboba" >, >Subject: RE: [eap] Re: Issue 360: EMSK Transport >Date: Tue, 2 May 2006 13:50:49 -0700 > >The document should not discuss where the EMSK is exported to from the >EAP method as this may be implementation dependent. > >Here is some suggested text (should go in 1.4 instead of section 2). > >"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 outside the EAP Server > by the AAA layer. As noted in [RFC3748] Section 7.10:" > >Joe _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From fastsable@andesgear.cl Tue May 02 19:27:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Hd-0000iT-Fg for eap-archive@ietf.org; Tue, 02 May 2006 19:27:57 -0400 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 1Fb4Hd-000680-Dg for eap-archive@ietf.org; Tue, 02 May 2006 19:27:57 -0400 Received: from vpn-224-29.aichyna.com ([87.252.224.29] helo=andesgear.cl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fb4FN-0006xn-Hj for eap-archive@ietf.org; Tue, 02 May 2006 19:25:38 -0400 Message-ID: <000001c66e3f$a0586360$94c1a8c0@mbs52> Reply-To: "Fastred Sable" From: "Fastred Sable" To: eap-archive@ietf.org Subject: Re: jexav news Date: Tue, 2 May 2006 16:24:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66E04.F3FBD550" 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: 3.2 (+++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66E04.F3FBD550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable De l ar Home O r wne e r ,=20 =20 Your cr k edi o t doesn't matter to us ! If you OW l N real e i st n at p e=20 and want IM g ME h DIAT h E c h ash to s a pen i d ANY way you like, or simply wish=20 to LO m WER your monthly p z ayment w s by a third or more, here are the dea e ls=20 we have T n ODA y Y :=20 =20 $ 48 s 8 , 000 at a 3 , b 67% fi v xed - ra j te=20 $ 3 h 72 , 000 at a 3 , k 90% v m ariab p le - rat k e=20 $ 49 z 2 , 000 at a 3 g , 21% int t ere g st - only=20 $ 24 m 8 , 000 at a 3 , k 36% f p ixed - ra u te=20 $ 1 y 98 , 000 at a 3 , r 55% variabl x e - ra p te=20 =20 Hurr y y, when these de r aIs are gone, they are gone ! =20 Don't worry about ap u pro o val, your c g redi l t will not di s squali y fy you !=20 =20 Vi w si b t o s ur site =20 =20 Sincerely, Fastred Sable=20 =20 A b ppr m oval Manager ------=_NextPart_000_0001_01C66E04.F3FBD550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
De l ar Home O r wne e r ,
 
Your cr k edi o t doesn't matter to us !=20 If you OW l N real e i st n at p e
and want IM g ME h DIAT h E c h ash to s a pen i d ANY=20 way you like, or simply wish
to LO m WER your monthly p z ayment w s=20 by a third or more, here are the dea e ls
we have T n ODA y Y :
 
$ 48 s 8 , 000 at a 3 , b 67% fi v xed - ra j te
$ 3 h 72 , 000 at a 3 , k 90% v m ariab p le - rat k e
$ 49 z 2 , 000 at a 3 g , 21% int t ere g st - only
$ 24 m 8 , 000 at a 3 , k 36% f p ixed - ra u te
$ 1 y 98 , 000 at a 3 , r 55% variabl x e - ra p te
 
Hurr y y, when these de r aIs are gone, they are gone !
 
Don't worry about ap u pro o val, your c g redi l t will=20 not di s squali y fy you !
 
=20 Vi w si b t o s ur site
 
Sincerely, Fastred Sable
 
A b ppr m oval Manager
------=_NextPart_000_0001_01C66E04.F3FBD550-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 02 19:30:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4K8-0000mA-3D for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:30:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4K6-0006Aa-N8 for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:30:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6199943016E for ; Tue, 2 May 2006 16:30:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9DD3C4300A2 for ; Tue, 2 May 2006 16:30:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3B2941448028 for ; Tue, 2 May 2006 16:30:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id B3C2A1448012 for ; Tue, 2 May 2006 16:30:10 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 16:30:10 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800752690:sNHT27754860" 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 k42NU9h0000800 for ; Tue, 2 May 2006 16:30:10 -0700 (PDT) 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 Date: Tue, 2 May 2006 16:37:38 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632C3@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: Section 2.2.2 Thread-Index: AcZuQFl9f+hOX7k/TuqZ/HA97pVqwQ== From: "Salowey, Joe" To: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] ISSUE: Section 2.2.2 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/02/06 Reference:=20 Document: Keying Framework Comment type: E Priority: 2 =20 Section: 2.2.2 Rationale/Explanation of issue: What is the specific vulnerability in this situation? " For example, the peer may assume that the "virtual authenticators" are distinct and do not share a key cache, whereas, depending on the architecture of the physical authenticator, a shared key cache may or may not be implemented." Maybe it should describe the peer problems that arise when you have different authenticators that provide different levels of services, similar to the authenticator problems in the next paragraph?=20 I'm not sure how recommendation [i] is related to the example of the corporate/guest problem in the second paragraph. _________________________________________________________________ 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 May 02 19:31:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4L3-0000nU-1G for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:31:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4L1-0006Ba-JZ for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:31:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 419BE4300B2 for ; Tue, 2 May 2006 16:31:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8B5D24300B2 for ; Tue, 2 May 2006 16:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7B49A1448007 for ; Tue, 2 May 2006 16:31:13 -0700 (PDT) Received: from hotmail.com (bay106-f2.bay106.hotmail.com [65.54.161.12]) by hermes.tigertech.net (Postfix) with ESMTP id EDB081448012 for ; Tue, 2 May 2006 16:31:10 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 16:31:10 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 02 May 2006 23:31:05 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 02 May 2006 16:31:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2006 23:31:10.0013 (UTC) FILETIME=[7E27AED0:01C66E40] 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: * Subject: [eap] Re: ISSUE: Section 2.2 title 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 I think that section 2.2.1 also needs to be retitled as well, for the same reasons. ---------------------------------------------------------------------------------------------- ISSUE: Section 2.2 title From: Salowey, Joe (jsaloweycisco.com) Date: Tue, 2 May 2006 13:58:19 -0700 (PDT) Submitter name: Joe Salowey Submitter email address: jsalowey [at] cisco.com Date first submitted: 05/02/06 Reference:Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 2.2 Rationale/Explanation of issue: This section discusses peer architecture as well as authenticator architecture. Suggest title: "2.2. Authenticator and Peer Architecture" _________________________________________________________________ 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 May 02 19:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4SV-0002Gn-Bz for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:39:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4ST-0006Xc-Uh for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:39:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9AE1343015C for ; Tue, 2 May 2006 16:39:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 62EBC4300B2 for ; Tue, 2 May 2006 16:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4996F144801A for ; Tue, 2 May 2006 16:38:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id A21751448007 for ; Tue, 2 May 2006 16:38:50 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 16:38:35 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800757948:sNHT41717993450" 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 k42NcZh0006380; Tue, 2 May 2006 16:38:35 -0700 (PDT) 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: section 2.1 AAA key caching Date: Tue, 2 May 2006 16:46:03 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632C7@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Issue: section 2.1 AAA key caching Thread-Index: AcZuM2pYCeyoyoduTqSDpc8ino3dsAADXtEA From: "Salowey, Joe" To: "Lakshminath Dondeti" , 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.4 tagged_above=-999.0 required=7.0 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: c0bedb65cce30976f0bf60a0a39edea4 The intent is to make sure that if you are going to re-use the MSK that you should have some making sure that the keys you derive from it will not be re-used if you re-use the MSK, for example incorporating the peer and authenticator nonce's in the TSK derivation in the SAP. Perhaps the following would be better: "If the AAA layer does cache an MSK then the derivation of TSKs derived from the MSK MUST prevent key reuse. " > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, May 02, 2006 2:50 PM > To: Salowey, Joe; eap@frascone.com > Subject: Re: [eap] Issue: section 2.1 AAA key caching >=20 > Hi Joe, >=20 > I don't understand the last sentence: "If the AAA layer does cache an=20 > MSK then the use of TSKs derived from the MSK MUST prevent=20 > key reuse. " >=20 > The rest of the text looks good and covers the robustness=20 > considerations you bring up. >=20 > regards, > Lakshminath >=20 > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > >Submitter name: Joe Salowey > >Submitter email address: jsalowey@cisco.com > >Date first submitted: 05/02/06 > >Reference: > >Document: Keying Framework > >Comment type: T > >Priority: 2 > >Section: 2.1 > >Rationale/Explanation of issue: > > > >The Current draft states that keys may not be cached once=20 > transported. I > >am wondering if this is too restrictive. Perhaps keys will be cached > >for session recovery and availability purposes. > > > >Suggested Text: > > > > "In order to avoid key reuse, the AAA layer SHOULD delete=20 > transported > > keys once they are sent. The AAA layer SHOULD NOT retain=20 > keys that > > it has previously sent. For example, a AAA layer that has > > transported the MSK SHOULD delete it. If the AAA layer=20 > does cache an > >MSK > > then the use of TSKs derived from the MSK MUST prevent=20 > key reuse. " > > > >_________________________________________________________________ > >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 Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 02 19:48:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4b9-0000Ai-2o for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:48:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4b7-0006gK-KX for eap-archive@lists.ietf.org; Tue, 02 May 2006 19:48:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 383AC43012A for ; Tue, 2 May 2006 16:47:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C151B4300A2 for ; Tue, 2 May 2006 16:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC1EF39801B for ; Tue, 2 May 2006 16:47:42 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 968A1398041 for ; Tue, 2 May 2006 16:47:37 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 02 May 2006 16:47:37 -0700 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 k42Nlaw1029473; Tue, 2 May 2006 16:47:36 -0700 (PDT) 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: Issue 356: Ciphersuite Independence Date: Tue, 2 May 2006 16:55:05 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632CD@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 356: Ciphersuite Independence Thread-Index: AcZtisM2b5sZH3TETQK/A9bV+5ue6QAtvScQ 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: 6e922792024732fb1bb6f346e63517e4 I think saying that=20 "The strength of the exported key material should not be less than the desired strength of the TSKs used in the lower layer." May be sufficient, but perhaps we should add: "The requirements of the lower layer TSK strength are not communicated through EAP." =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, May 01, 2006 6:43 PM > To: eap@frascone.com > Subject: [eap] Re: Issue 356: Ciphersuite Independence >=20 > The text of Issue 356 is given below. >=20 > Section 3.7 says the following: >=20 > "In order to guard against brute force attacks, EAP methods=20 > supporting key=20 > derivation > need to be capable of generating keying material with an appropriate > effective symmetric key strength. In order to ensure that EAP key > generation is not the weakest link, it is RECOMMENDED that EAP methods > utilizing public key cryptography choose a public key that has a > cryptographic strength meeting the symmetric key strength=20 > requirement." >=20 > The text is accurate as far as it goes, but it occurs to me=20 > that this is not=20 > the complete story. Even if the EAP keying material is of sufficient=20 > strength, attacks on the transient session keys might still=20 > be possible. =20 > For example in IKEv2, EAP is not used for key derivation, just=20 > authentication; key derivation is handled by IKEv2 (e.g. DH).=20 > If IKEv2 does=20 > not negotiate adequate strength for the key derivation (e.g.=20 > 512-bit key for=20 > DH) the TSKs will be weak regardless of how strong the EAP=20 > keying material=20 > is, since the MSK is only used for authentication, not key=20 > derivation. =20 > Similarly in 802.16 the TSKs are generated purely by the Base=20 > Station. If=20 > BS does not have a good random number generator, it would be=20 > possible to=20 > crack the TSKs without having to brute force the EAP keying=20 > material. So in=20 > both the IKEv2 and 802.16 cases, strong EAP keying material=20 > is necessary,=20 > but not sufficient to ensure strong TSKs. >=20 > Given this, I am wondering what text is appropriate relating=20 > to "system=20 > level coordination" in Section 1.6.4. I think we can say=20 > that the strength=20 > of the EAP keying material should not be less than the=20 > strength of the=20 > desired TSKs. But I'm not clear what we can say about=20 > "coordination" beyond=20 > that. >=20 > Can someone suggest text? >=20 > -------------------------------------------------------------- > -------------------------------------------- > Issue 356: Ciphersuite Independence > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: April 30, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04223.html > Document: KEYING-12 > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 1.6.4 > Rationale/Explanation of issue: >=20 > Section 3.7 implies that there is a system level coordination between > the strength of the keys exported by the EAP method and the=20 > strength of > keys required by the lower layer. >=20 > This section should reference this and indicate that the=20 > coordination is > done outside of 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 Tue May 02 20:05:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4s2-0004aW-Fs for eap-archive@lists.ietf.org; Tue, 02 May 2006 20:05:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4s0-0007Fy-TX for eap-archive@lists.ietf.org; Tue, 02 May 2006 20:05:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D5AD430128 for ; Tue, 2 May 2006 17:05:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A350C4300A2 for ; Tue, 2 May 2006 17:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 843481448028 for ; Tue, 2 May 2006 17:05:16 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 7504A1448012 for ; Tue, 2 May 2006 17:05:12 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 02 May 2006 17:05:12 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4305BRT023167; Tue, 2 May 2006 17:05:11 -0700 (PDT) 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: Issue 360: EMSK Transport Date: Tue, 2 May 2006 17:12:40 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F632D9@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 360: EMSK Transport Thread-Index: AcZuM1PcTtNlBG71QTeDAhxH5smHmAAEE6cA From: "Salowey, Joe" To: "Lakshminath Dondeti" , "Narayanan, Vidya" , "Bernard Aboba" , 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.4 tagged_above=-999.0 required=7.0 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: 1449ead51a2ff026dcb23465f5379250 After reading the text again I would be OK removing the specifc text about the AAA layer. =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, May 02, 2006 2:46 PM > To: Salowey, Joe; Narayanan, Vidya; Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: Issue 360: EMSK Transport >=20 > I am having a logical problem parsing "The EMSK MUST NOT be=20 > transported outside the EAP Server by the AAA layer." >=20 > Does that allow transport of EMSK by other layers? I know that's not=20 > the intent. >=20 > regards, > Lakshminath >=20 > At 01:50 PM 5/2/2006, Salowey, Joe wrote: > >The document should not discuss where the EMSK is exported=20 > to from the > >EAP method as this may be implementation dependent. > > > >Here is some suggested text (should go in 1.4 instead of section 2). > > > >"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=20 > entity outside > > the EAP server or peer from which the EMSK could be=20 > computed without > > breaking some cryptographic assumption, such as=20 > inverting a one-way > > function. The EMSK MUST NOT be transported outside the=20 > EAP Server > > by the AAA layer. As noted in [RFC3748] Section 7.10:" > > > >Joe > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Tuesday, May 02, 2006 12:07 PM > > > To: Salowey, Joe; Bernard Aboba; eap@frascone.com > > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > > > > > > Hi Joe, > > > The text suggests that the AAA layer MUST NOT transport=20 > the EMSK, not > > > that the AAA layer MUST NOT transport the EMSK outside=20 > the entity. To > > > me, this implied that the EMSK MUST NOT be transported to=20 > other layers > > > within the same entity as well. > > > > > > Due to the current means of key transport, the EMSK=20 > arrives at the AAA > > > layer when the MSK arrives. But, we may (I'm not sure yet) > > > need the EMSK > > > to be available to the EAP layer for further key=20 > derivation - the AAA > > > layer is potentially not the right layer to be deriving the > > > keys - then, > > > that would imply that the lower layer in the peer is the=20 > one deriving > > > the same keys. This, apart from being disparate, also=20 > means that every > > > lower layer now needs to define this derivation, which seems > > > undesirable. > > > > > > So, pending discussion, I'd like to not have this statement in the > > > current spec. > > > > > > Vidya > > > > > > > -----Original Message----- > > > > From: Salowey, Joe [mailto:jsalowey@cisco.com] > > > > Sent: Tuesday, May 02, 2006 8:45 AM > > > > To: Bernard Aboba; eap@frascone.com > > > > Subject: RE: [eap] Re: Issue 360: EMSK Transport > > > > > > > > I don't see the text as harmful. It may be somewhat > > > > redundant, but I would like to better understand why its > > > > presence is restrictive. That would seem to indicate that it > > > > is not redundant. > > > > > > > > Joe > > > > > > > > > -----Original Message----- > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > Sent: Tuesday, May 02, 2006 5:54 AM > > > > > To: eap@frascone.com > > > > > Subject: [eap] Re: Issue 360: EMSK Transport > > > > > > > > > > Since EMSK sharing is prohibited elsewhere in the document, > > > > the text > > > > > to be deleted is redundant at best. Any objections to > > > > accepting the > > > > > proposed change? > > > > > > > > > > > > > > > > >=20 > --------------------------------------------------------------------- > > > > > Issue 360: EMSK Transport > > > > > Submitter name: Vidya Narayanan > > > > > Submitter email address: vidyan@qualcomm.com Date > > > Submitted: May 1, > > > > > 2006 > > > > > Reference:=20 > http://lists.frascone.com/pipermail/eap/msg04230.html > > > > > Document: KEYING-12 > > > > > Comment type: 'T'echnical > > > > > Priority: '1' Should fix > > > > > Section: 2 > > > > > Rationale/Explanation of issue: > > > > > > > > > > The section says "The EMSK MUST NOT be transported by the > > > > AAA layer." > > > > > Given that the EMSK usage is currently undefined, it is not > > > > clear if > > > > > it will be the AAA layer that derives further keys from the > > > > EMSK. In > > > > > fact, doing so will create disparate behavior at the peer > > > > and server, > > > > > since the peer does not have a AAA layer. Although=20 > this topic is > > > > > pending discussion, it seems restrictive to say MUST NOT > > > > here. It does > > > > > make sense, however, to say that the EMSK MUST NOT be > > > > transported to > > > > > additional parties. > > > > > > > > > > Requested change: > > > > > > > > > > Delete the sentence "The EMSK MUST NOT be transported=20 > by the AAA > > > > > layer". > > > > > > > > > > > > > > >=20 > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > 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 >=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 May 02 20:18:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb54t-0001YM-Bn for eap-archive@lists.ietf.org; Tue, 02 May 2006 20:18:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb54s-0007cv-Tz for eap-archive@lists.ietf.org; Tue, 02 May 2006 20:18:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5591D43010D for ; Tue, 2 May 2006 17:18:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CEE334300A5 for ; Tue, 2 May 2006 17:18:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF3561448012 for ; Tue, 2 May 2006 17:18:29 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id E18AB144801A for ; Tue, 2 May 2006 17:18:26 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k430FDD0027297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 17:15:14 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k430FCNr016083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 17:15:13 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502171352.05aa1e38@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 17:15:14 -0700 To: "Salowey, Joe" , From: Lakshminath Dondeti Subject: RE: [eap] Issue: section 2.1 AAA key caching In-Reply-To: <7210B31550AC934A8637D6619739CE6906F632C7@e2k-sea-xch2.sea- alpha.cisco.com> References: <7210B31550AC934A8637D6619739CE6906F632C7@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: cd26b070c2577ac175cd3a6d878c6248 At 04:46 PM 5/2/2006, Salowey, Joe wrote: >The intent is to make sure that if you are going to re-use the MSK that >you should have some making sure that the keys you derive from it will >not be re-used if you re-use the MSK, for example incorporating the >peer and authenticator nonce's in the TSK derivation in the SAP. >Perhaps the following would be better: > >"If the AAA layer does cache an MSK then the derivation of TSKs derived >from the MSK MUST prevent key reuse. " There is an extra derived there :-). But, I guess then you are talking about key separation between TSKs. So, why not say that TSKs derived from the MSK must be cryptographically separate from each other. Perhaps I am missing the point completely? :-). regards, Lakshminath > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Tuesday, May 02, 2006 2:50 PM > > To: Salowey, Joe; eap@frascone.com > > Subject: Re: [eap] Issue: section 2.1 AAA key caching > > > > Hi Joe, > > > > I don't understand the last sentence: "If the AAA layer does cache an > > MSK then the use of TSKs derived from the MSK MUST prevent > > key reuse. " > > > > The rest of the text looks good and covers the robustness > > considerations you bring up. > > > > regards, > > Lakshminath > > > > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > > >Submitter name: Joe Salowey > > >Submitter email address: jsalowey@cisco.com > > >Date first submitted: 05/02/06 > > >Reference: > > >Document: Keying Framework > > >Comment type: T > > >Priority: 2 > > >Section: 2.1 > > >Rationale/Explanation of issue: > > > > > >The Current draft states that keys may not be cached once > > transported. I > > >am wondering if this is too restrictive. Perhaps keys will be cached > > >for session recovery and availability purposes. > > > > > >Suggested Text: > > > > > > "In order to avoid key reuse, the AAA layer SHOULD delete > > transported > > > keys once they are sent. The AAA layer SHOULD NOT retain > > keys that > > > it has previously sent. For example, a AAA layer that has > > > transported the MSK SHOULD delete it. If the AAA layer > > does cache an > > >MSK > > > then the use of TSKs derived from the MSK MUST prevent > > key reuse. " > > > > > >_________________________________________________________________ > > >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 May 02 21:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb6IA-0005LN-Hh for eap-archive@lists.ietf.org; Tue, 02 May 2006 21:36:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb6I8-0002rV-G4 for eap-archive@lists.ietf.org; Tue, 02 May 2006 21:36:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5EC9E4300F0 for ; Tue, 2 May 2006 18:36:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B74D24300A5 for ; Tue, 2 May 2006 18:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 973B51448020 for ; Tue, 2 May 2006 18:36:19 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id E87BA1448001 for ; Tue, 2 May 2006 18:36:16 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k431aEFG029956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 18:36:15 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-73-164.qualcomm.com [10.50.73.164]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k431a9FJ010351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 18:36:12 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502183117.0585b8a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 18:33:59 -0700 To: "Narayanan, Vidya" , "Bernard Aboba" , From: Lakshminath Dondeti Subject: RE: [eap] Re: issue 361: child key expiry In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84792131@NAEX06.na.qualcomm. com> References: <2EBB8025B6D1BA41B567DB32C1D8DB84792131@NAEX06.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: c83ccb5cc10e751496398f1233ca9c3a Hi Vidya, After having thought about this some more, I think we should have some text on EMSK to child key derivation in the EAP-keying document along the lines of the 4 items listed earlier. This is inline with the text on TSKs in 3.1(e) and perhaps elsewhere in the document. regards, Lakshminath At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: >Bernard, Lakshminath, >While this is an interesting discussion, I feel that the EMSK specifics >with respect to caching and lifetime as well as child key properties >need to be discussed in the EMSK usage document. We can continue having >this discussion in light of the EMSK usage document. > >For the purpose of EAP keying document, can we not add that sentence >about a future EMSK usage document and leave it at that? > >However, if there are things that need to be clarified here with respect >to the MSK, we should certainly do that in this document. > >Thanks, >Vidya > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 02, 2006 12:19 PM > > To: Dondeti, Lakshminath; eap@frascone.com > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > >I wasn't thinking about PANA, but thinking about the use > > case of client > > >authentication in IPsec remote access using EAP. Whereas EAP can be > > >used every time, it is plausible that the MSK is cached as the IKEv2 > > >Preshared key for future authentication to avoid EAP latency. > > > > Perhaps we can say that RFC 4306 does not support key > > caching? It seems that an extension to IKEv2 would be > > required to support this, since otherwise the IKE initiator > > and responder couldn't negotiate whether cached EAP keys are > > to be used, and if so, which ones. > > > > >>Are you suggesting that there might be situations in which EAP keys > > >>aren't used for key derivation, but compromise might still > > be possible? > > > > > >No. I am asking if the MSK/EMSK figures into the key > > derivation, say > > >only partially (say along with DH), compromise of MSK/EMSK means > > >compromise of derived keys. I was then saying perhaps that is too > > >restrictive, but I'd contend not, unless there is a strong > > case made for the alternative. > > > > OK. If the MSK/EMSK were mixed into the key derivation, then > > there might be some weakening of the key derivation. How > > much depends on the algorithm. > > > > >If that's confusing too, please let me know. > > > > I understand the point.... question is how we make it clear > > in the text. > > > > >>Right. And by the same logic, the MSK and EMSK might expire at > > >>different times. I'm not sure that the key lifetime section takes > > >>that into account adequately. > > > > > >That sounds right and the clarification will be good. > > > > Suggestions welcome. > > > > >>This makes sense assuming that the entity authentiation keys aren't > > >>themselves derived from the EMSK. > > > > > >Even if entity authentication keys are derived from the EMSK, the > > >guideline applies, I think. Suppose the EMSK supports > > derivation of a > > >traffic key and a separate entity authentication key, > > wouldn't it make > > >sense to say that, all other things being equal, the traffic > > key will > > >have a shorter lifetime than the entity authentication key, > > based on key usage? > > > > Yes, it would make sense. I guess I'd distinguish between a > > key calculated > > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that > > have been suggested so far are static -- that is, they are > > based on a key-label, but do not generate a fresh key every > > time they are invoked on the same EMSK, in the way that some > > TSK derivations do (e.g. 802.11i 4-way handshake). > > > > Unless there is an ability to generate fresh keys without an > > EAP re-authentication, then when the derived keyexpires it is > > necessary to do an EAP re-authentication. With TSKs it may > > be possible to do a re-key independent of EAP (e.g. 802.11i > > 4-way handshake). > > > > > > _________________________________________________________________ > > 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 Rae_DanielsStarksPritchett@racqi.com.au Wed May 03 05:23:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDaO-00043K-Co for eap-archive@ietf.org; Wed, 03 May 2006 05:23:56 -0400 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 1FbCN5-0002v4-7z for eap-archive@ietf.org; Wed, 03 May 2006 04:06:07 -0400 Received: from ppp85-140-37-205.pppoe.mtu-net.ru ([85.140.37.205] helo=6E46FB8) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FbC84-0001zn-Dp for eap-archive@ietf.org; Wed, 03 May 2006 03:50:38 -0400 Received: from 74.131.226.205.in-addr.arpa.5star-shareware.com (HELO localhost.localdomain) ([85.140.37.205]) (envelope-sender ) by email-2.5star-shareware.com (qmail-ldap-1.03) with SMTP for ; Wed, 03 May 2006 00:50:23 -0800 Message-Id: <63759656_391005_593011.ewdoc@5star-shareware.com> Date: Wed, 03 May 2006 00:50:23 -0800 X-Mailer: iGMail [www.ig.com.br] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org From: "Mandy" Subject: Get a 3.75% mortgage with us X-Spam-Score: 4.1 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Want to re-mortgage your home? Or maybe you want a loan? We got the largest companies competing against each other for your busines= s, so you know you're getting the best deal. Rates as low as 3.75%! http://www.boleam.com/9cl From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 03 13:59:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLct-00032p-CG for eap-archive@lists.ietf.org; Wed, 03 May 2006 13:59:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLcr-0002uv-TX for eap-archive@lists.ietf.org; Wed, 03 May 2006 13:59:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 144774300FA for ; Wed, 3 May 2006 10:59:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0056243004F for ; Wed, 3 May 2006 10:58:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA228398036 for ; Wed, 3 May 2006 10:58:45 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id A7C9A39803A for ; Wed, 3 May 2006 10:58:41 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 03 May 2006 10:58:36 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="1801018315:sNHT12002106634" 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 k43Hwaw1004228; Wed, 3 May 2006 10:58:36 -0700 (PDT) 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: section 2.1 AAA key caching Date: Wed, 3 May 2006 11:06:04 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63435@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Issue: section 2.1 AAA key caching Thread-Index: AcZuSCP4zavTfuI6SlecvAzq8m+amQAkbuIQ From: "Salowey, Joe" To: "Lakshminath Dondeti" , 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: a87a9cdae4ac5d3fbeee75cd0026d632 With this particular text I wanted to make sure a key wasn't reused, ie the TSKs are derived using some mechanism provides reasonable protection from reuse. Separation typically means that knowledge of one key does not provide any knowledge of other keys. I think in some circumstances these two things are related, but I am not sure that one implies the other. In particular I don't think you need to have separation to provide reuse. I could also imagine schemes where you could provide separation by segmenting the MSK, but the actual TSK selection allows for reuse of TSK segments.=20 It could be that I am missing some connection between the two, but it seems they are different.=20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, May 02, 2006 5:15 PM > To: Salowey, Joe; eap@frascone.com > Subject: RE: [eap] Issue: section 2.1 AAA key caching >=20 > At 04:46 PM 5/2/2006, Salowey, Joe wrote: > >The intent is to make sure that if you are going to re-use=20 > the MSK that > >you should have some making sure that the keys you derive=20 > from it will > >not be re-used if you re-use the MSK, for example incorporating the > >peer and authenticator nonce's in the TSK derivation in the SAP. > >Perhaps the following would be better: > > > >"If the AAA layer does cache an MSK then the derivation of=20 > TSKs derived > >from the MSK MUST prevent key reuse. " >=20 > There is an extra derived there :-). But, I guess then you are=20 > talking about key separation between TSKs. So, why not say that TSKs=20 > derived from the MSK must be cryptographically separate from=20 > each other. >=20 > Perhaps I am missing the point completely? :-). >=20 > regards, > Lakshminath >=20 >=20 > > > -----Original Message----- > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > Sent: Tuesday, May 02, 2006 2:50 PM > > > To: Salowey, Joe; eap@frascone.com > > > Subject: Re: [eap] Issue: section 2.1 AAA key caching > > > > > > Hi Joe, > > > > > > I don't understand the last sentence: "If the AAA layer=20 > does cache an > > > MSK then the use of TSKs derived from the MSK MUST prevent > > > key reuse. " > > > > > > The rest of the text looks good and covers the robustness > > > considerations you bring up. > > > > > > regards, > > > Lakshminath > > > > > > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > > > >Submitter name: Joe Salowey > > > >Submitter email address: jsalowey@cisco.com > > > >Date first submitted: 05/02/06 > > > >Reference: > > > >Document: Keying Framework > > > >Comment type: T > > > >Priority: 2 > > > >Section: 2.1 > > > >Rationale/Explanation of issue: > > > > > > > >The Current draft states that keys may not be cached once > > > transported. I > > > >am wondering if this is too restrictive. Perhaps keys=20 > will be cached > > > >for session recovery and availability purposes. > > > > > > > >Suggested Text: > > > > > > > > "In order to avoid key reuse, the AAA layer SHOULD delete > > > transported > > > > keys once they are sent. The AAA layer SHOULD NOT retain > > > keys that > > > > it has previously sent. For example, a AAA layer that has > > > > transported the MSK SHOULD delete it. If the AAA layer > > > does cache an > > > >MSK > > > > then the use of TSKs derived from the MSK MUST prevent > > > key reuse. " > > > > > > > >_________________________________________________________________ > > > >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 Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 03 14:06:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLkR-0000bx-Kj for eap-archive@lists.ietf.org; Wed, 03 May 2006 14:06:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLkQ-0003QK-4M for eap-archive@lists.ietf.org; Wed, 03 May 2006 14:06:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C03ED4300B3 for ; Wed, 3 May 2006 11:06:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C5C8443004F for ; Wed, 3 May 2006 11:06:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 995AC1448021 for ; Wed, 3 May 2006 11:06:31 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id C69C3144801A for ; Wed, 3 May 2006 11:06:28 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43I6QPj019297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 11:06:27 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43I6Ogj020630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 11:06:26 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503110251.03efe108@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 11:06:15 -0700 To: "Salowey, Joe" , From: Lakshminath Dondeti Subject: RE: [eap] Issue: section 2.1 AAA key caching In-Reply-To: <7210B31550AC934A8637D6619739CE6906F63435@e2k-sea-xch2.sea- alpha.cisco.com> References: <7210B31550AC934A8637D6619739CE6906F63435@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: 37af5f8fbf6f013c5b771388e24b09e7 At 11:06 AM 5/3/2006, Salowey, Joe wrote: >With this particular text I wanted to make sure a key wasn't reused, ie >the TSKs are derived using some mechanism provides reasonable protection >from reuse. Separation typically means that knowledge of one key does >not provide any knowledge of other keys. I think in some circumstances >these two things are related, but I am not sure that one implies the >other. In particular I don't think you need to have separation to >provide reuse. I could also imagine schemes where you could provide >separation by segmenting the MSK, but the actual TSK selection allows >for reuse of TSK segments. So even if TSKs are segments of the MSK keying material, the cryptographic separation property holds, no? Speaking very loosely, if IKEv2 PRF+ is used to generate the MSK, and if we further assume that each TSK is equivalent to or a portion of the values T1, T2 etc., given T1, it is computationally infeasible to compute say T2 or any other of Ti, 1< i < 255. regards, Lakshminath >It could be that I am missing some connection between the two, but it >seems they are different. > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Tuesday, May 02, 2006 5:15 PM > > To: Salowey, Joe; eap@frascone.com > > Subject: RE: [eap] Issue: section 2.1 AAA key caching > > > > At 04:46 PM 5/2/2006, Salowey, Joe wrote: > > >The intent is to make sure that if you are going to re-use > > the MSK that > > >you should have some making sure that the keys you derive > > from it will > > >not be re-used if you re-use the MSK, for example incorporating the > > >peer and authenticator nonce's in the TSK derivation in the SAP. > > >Perhaps the following would be better: > > > > > >"If the AAA layer does cache an MSK then the derivation of > > TSKs derived > > >from the MSK MUST prevent key reuse. " > > > > There is an extra derived there :-). But, I guess then you are > > talking about key separation between TSKs. So, why not say that TSKs > > derived from the MSK must be cryptographically separate from > > each other. > > > > Perhaps I am missing the point completely? :-). > > > > regards, > > Lakshminath > > > > > > > > -----Original Message----- > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > Sent: Tuesday, May 02, 2006 2:50 PM > > > > To: Salowey, Joe; eap@frascone.com > > > > Subject: Re: [eap] Issue: section 2.1 AAA key caching > > > > > > > > Hi Joe, > > > > > > > > I don't understand the last sentence: "If the AAA layer > > does cache an > > > > MSK then the use of TSKs derived from the MSK MUST prevent > > > > key reuse. " > > > > > > > > The rest of the text looks good and covers the robustness > > > > considerations you bring up. > > > > > > > > regards, > > > > Lakshminath > > > > > > > > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > > > > >Submitter name: Joe Salowey > > > > >Submitter email address: jsalowey@cisco.com > > > > >Date first submitted: 05/02/06 > > > > >Reference: > > > > >Document: Keying Framework > > > > >Comment type: T > > > > >Priority: 2 > > > > >Section: 2.1 > > > > >Rationale/Explanation of issue: > > > > > > > > > >The Current draft states that keys may not be cached once > > > > transported. I > > > > >am wondering if this is too restrictive. Perhaps keys > > will be cached > > > > >for session recovery and availability purposes. > > > > > > > > > >Suggested Text: > > > > > > > > > > "In order to avoid key reuse, the AAA layer SHOULD delete > > > > transported > > > > > keys once they are sent. The AAA layer SHOULD NOT retain > > > > keys that > > > > > it has previously sent. For example, a AAA layer that has > > > > > transported the MSK SHOULD delete it. If the AAA layer > > > > does cache an > > > > >MSK > > > > > then the use of TSKs derived from the MSK MUST prevent > > > > key reuse. " > > > > > > > > > >_________________________________________________________________ > > > > >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 May 03 14:22:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLzP-000354-K2 for eap-archive@lists.ietf.org; Wed, 03 May 2006 14:22:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLzL-0003nA-1d for eap-archive@lists.ietf.org; Wed, 03 May 2006 14:22:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 940AB430100 for ; Wed, 3 May 2006 11:22:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 849E543004F for ; Wed, 3 May 2006 11:21:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6F3D3398036 for ; Wed, 3 May 2006 11:21:57 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 062E939802B for ; Wed, 3 May 2006 11:21:54 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 03 May 2006 11:21:54 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="1801029486:sNHT33156626" 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 k43ILsw1021834; Wed, 3 May 2006 11:21:54 -0700 (PDT) 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: section 2.1 AAA key caching Date: Wed, 3 May 2006 11:29:23 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63461@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Issue: section 2.1 AAA key caching Thread-Index: AcZu3WfCjtM2Z9FPRSu6JhIhBDVUBwAAHj9A From: "Salowey, Joe" To: "Lakshminath Dondeti" , 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: 36b1f8810cb91289d885dc8ab4fc8172 =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Wednesday, May 03, 2006 11:06 AM > To: Salowey, Joe; eap@frascone.com > Subject: RE: [eap] Issue: section 2.1 AAA key caching >=20 > At 11:06 AM 5/3/2006, Salowey, Joe wrote: > >With this particular text I wanted to make sure a key wasn't=20 > reused, ie > >the TSKs are derived using some mechanism provides=20 > reasonable protection > >from reuse. Separation typically means that knowledge of=20 > one key does > >not provide any knowledge of other keys. I think in some=20 > circumstances > >these two things are related, but I am not sure that one implies the > >other. In particular I don't think you need to have separation to > >provide reuse. I could also imagine schemes where you could provide > >separation by segmenting the MSK, but the actual TSK selection allows > >for reuse of TSK segments. >=20 > So even if TSKs are segments of the MSK keying material, the=20 > cryptographic separation property holds, no? Speaking very loosely,=20 > if IKEv2 PRF+ is used to generate the MSK, and if we further assume=20 > that each TSK is equivalent to or a portion of the values T1, T2=20 > etc., given T1, it is computationally infeasible to compute say T2 or=20 > any other of Ti, 1< i < 255. >=20 [Joe] yes, but my point is that separation does not prevent reuse. You can have separate keys and if you don't take reuse into account in the design of your lower layer protocol then you will have a reuse problem. One example is allowing a counter to wrap or reset under certain conditions.=20 > regards, > Lakshminath >=20 > >It could be that I am missing some connection between the two, but it > >seems they are different. > > > > > -----Original Message----- > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > Sent: Tuesday, May 02, 2006 5:15 PM > > > To: Salowey, Joe; eap@frascone.com > > > Subject: RE: [eap] Issue: section 2.1 AAA key caching > > > > > > At 04:46 PM 5/2/2006, Salowey, Joe wrote: > > > >The intent is to make sure that if you are going to re-use > > > the MSK that > > > >you should have some making sure that the keys you derive > > > from it will > > > >not be re-used if you re-use the MSK, for example=20 > incorporating the > > > >peer and authenticator nonce's in the TSK derivation in the SAP. > > > >Perhaps the following would be better: > > > > > > > >"If the AAA layer does cache an MSK then the derivation of > > > TSKs derived > > > >from the MSK MUST prevent key reuse. " > > > > > > There is an extra derived there :-). But, I guess then you are > > > talking about key separation between TSKs. So, why not=20 > say that TSKs > > > derived from the MSK must be cryptographically separate from > > > each other. > > > > > > Perhaps I am missing the point completely? :-). > > > > > > regards, > > > Lakshminath > > > > > > > > > > > -----Original Message----- > > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > > Sent: Tuesday, May 02, 2006 2:50 PM > > > > > To: Salowey, Joe; eap@frascone.com > > > > > Subject: Re: [eap] Issue: section 2.1 AAA key caching > > > > > > > > > > Hi Joe, > > > > > > > > > > I don't understand the last sentence: "If the AAA layer > > > does cache an > > > > > MSK then the use of TSKs derived from the MSK MUST prevent > > > > > key reuse. " > > > > > > > > > > The rest of the text looks good and covers the robustness > > > > > considerations you bring up. > > > > > > > > > > regards, > > > > > Lakshminath > > > > > > > > > > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > > > > > >Submitter name: Joe Salowey > > > > > >Submitter email address: jsalowey@cisco.com > > > > > >Date first submitted: 05/02/06 > > > > > >Reference: > > > > > >Document: Keying Framework > > > > > >Comment type: T > > > > > >Priority: 2 > > > > > >Section: 2.1 > > > > > >Rationale/Explanation of issue: > > > > > > > > > > > >The Current draft states that keys may not be cached once > > > > > transported. I > > > > > >am wondering if this is too restrictive. Perhaps keys > > > will be cached > > > > > >for session recovery and availability purposes. > > > > > > > > > > > >Suggested Text: > > > > > > > > > > > > "In order to avoid key reuse, the AAA layer SHOULD delete > > > > > transported > > > > > > keys once they are sent. The AAA layer SHOULD NOT retain > > > > > keys that > > > > > > it has previously sent. For example, a AAA layer that has > > > > > > transported the MSK SHOULD delete it. If the AAA layer > > > > > does cache an > > > > > >MSK > > > > > > then the use of TSKs derived from the MSK MUST prevent > > > > > key reuse. " > > > > > > > > > > >=20 > >_________________________________________________________________ > > > > > >To unsubscribe or modify your subscription options,=20 > 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 Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 03 15:12:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMlh-0007CO-4S for eap-archive@lists.ietf.org; Wed, 03 May 2006 15:12:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbMlg-00061p-Cx for eap-archive@lists.ietf.org; Wed, 03 May 2006 15:12:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 924204300FF for ; Wed, 3 May 2006 12:12:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6AC6F43004F for ; Wed, 3 May 2006 12:11:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 13661144801C for ; Wed, 3 May 2006 12:11:55 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 20512144801A for ; Wed, 3 May 2006 12:11:51 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43J8SvI020029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 12:08:35 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43J8OEC011951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 12:08:27 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503120655.057305e0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 12:08:28 -0700 To: "Salowey, Joe" , From: Lakshminath Dondeti Subject: RE: [eap] Issue: section 2.1 AAA key caching In-Reply-To: <7210B31550AC934A8637D6619739CE6906F63461@e2k-sea-xch2.sea- alpha.cisco.com> References: <7210B31550AC934A8637D6619739CE6906F63461@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: 29dc808194f5fb921c09d0040806d6eb At 11:29 AM 5/3/2006, Salowey, Joe wrote: > > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Wednesday, May 03, 2006 11:06 AM > > To: Salowey, Joe; eap@frascone.com > > Subject: RE: [eap] Issue: section 2.1 AAA key caching > > > > At 11:06 AM 5/3/2006, Salowey, Joe wrote: > > >With this particular text I wanted to make sure a key wasn't > > reused, ie > > >the TSKs are derived using some mechanism provides > > reasonable protection > > >from reuse. Separation typically means that knowledge of > > one key does > > >not provide any knowledge of other keys. I think in some > > circumstances > > >these two things are related, but I am not sure that one implies the > > >other. In particular I don't think you need to have separation to > > >provide reuse. I could also imagine schemes where you could provide > > >separation by segmenting the MSK, but the actual TSK selection allows > > >for reuse of TSK segments. > > > > So even if TSKs are segments of the MSK keying material, the > > cryptographic separation property holds, no? Speaking very loosely, > > if IKEv2 PRF+ is used to generate the MSK, and if we further assume > > that each TSK is equivalent to or a portion of the values T1, T2 > > etc., given T1, it is computationally infeasible to compute say T2 or > > any other of Ti, 1< i < 255. > > > >[Joe] yes, but my point is that separation does not prevent reuse. You >can have separate keys and if you don't take reuse into account in the >design of your lower layer protocol then you will have a reuse problem. >One example is allowing a counter to wrap or reset under certain >conditions. So then you are saying that the TSKs must be cryptographically separate from each other and that they must not be reused. (I would have thought it's automatic, but clarification is fine with me). regards, Lakshminath > > regards, > > Lakshminath > > > > >It could be that I am missing some connection between the two, but it > > >seems they are different. > > > > > > > -----Original Message----- > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > Sent: Tuesday, May 02, 2006 5:15 PM > > > > To: Salowey, Joe; eap@frascone.com > > > > Subject: RE: [eap] Issue: section 2.1 AAA key caching > > > > > > > > At 04:46 PM 5/2/2006, Salowey, Joe wrote: > > > > >The intent is to make sure that if you are going to re-use > > > > the MSK that > > > > >you should have some making sure that the keys you derive > > > > from it will > > > > >not be re-used if you re-use the MSK, for example > > incorporating the > > > > >peer and authenticator nonce's in the TSK derivation in the SAP. > > > > >Perhaps the following would be better: > > > > > > > > > >"If the AAA layer does cache an MSK then the derivation of > > > > TSKs derived > > > > >from the MSK MUST prevent key reuse. " > > > > > > > > There is an extra derived there :-). But, I guess then you are > > > > talking about key separation between TSKs. So, why not > > say that TSKs > > > > derived from the MSK must be cryptographically separate from > > > > each other. > > > > > > > > Perhaps I am missing the point completely? :-). > > > > > > > > regards, > > > > Lakshminath > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > > > Sent: Tuesday, May 02, 2006 2:50 PM > > > > > > To: Salowey, Joe; eap@frascone.com > > > > > > Subject: Re: [eap] Issue: section 2.1 AAA key caching > > > > > > > > > > > > Hi Joe, > > > > > > > > > > > > I don't understand the last sentence: "If the AAA layer > > > > does cache an > > > > > > MSK then the use of TSKs derived from the MSK MUST prevent > > > > > > key reuse. " > > > > > > > > > > > > The rest of the text looks good and covers the robustness > > > > > > considerations you bring up. > > > > > > > > > > > > regards, > > > > > > Lakshminath > > > > > > > > > > > > At 02:25 PM 5/2/2006, Salowey, Joe wrote: > > > > > > >Submitter name: Joe Salowey > > > > > > >Submitter email address: jsalowey@cisco.com > > > > > > >Date first submitted: 05/02/06 > > > > > > >Reference: > > > > > > >Document: Keying Framework > > > > > > >Comment type: T > > > > > > >Priority: 2 > > > > > > >Section: 2.1 > > > > > > >Rationale/Explanation of issue: > > > > > > > > > > > > > >The Current draft states that keys may not be cached once > > > > > > transported. I > > > > > > >am wondering if this is too restrictive. Perhaps keys > > > > will be cached > > > > > > >for session recovery and availability purposes. > > > > > > > > > > > > > >Suggested Text: > > > > > > > > > > > > > > "In order to avoid key reuse, the AAA layer SHOULD delete > > > > > > transported > > > > > > > keys once they are sent. The AAA layer SHOULD NOT retain > > > > > > keys that > > > > > > > it has previously sent. For example, a AAA layer that has > > > > > > > transported the MSK SHOULD delete it. If the AAA layer > > > > > > does cache an > > > > > > >MSK > > > > > > > then the use of TSKs derived from the MSK MUST prevent > > > > > > key reuse. " > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > >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 gitteluhethering@quasar.uvt.ro Wed May 03 18:54:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQEt-0001bs-NF for eap-archive@ietf.org; Wed, 03 May 2006 18:54:35 -0400 Received: from alille-254-1-32-156.w86-192.abo.wanadoo.fr ([86.192.87.156] helo=quasar.uvt.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbQEs-00079j-PR for eap-archive@ietf.org; Wed, 03 May 2006 18:54:35 -0400 Message-ID: <000001c66f04$70ea3f70$9837a8c0@wqs35> Reply-To: "Gittel Hetherington" From: "Gittel Hetherington" To: eap-archive@ietf.org Subject: Re: pidui news Date: Wed, 3 May 2006 15:53:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66EC9.C48B6770" 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: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66EC9.C48B6770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D h ear Home Ow q ne c r ,=20 =20 Your c k red a it doesn't matter to us ! If you O j WN real e d st f at t e=20 and want IM u ME q DIA h TE cas p h to s e pen c d ANY way you like, or simply wish=20 to LO h WER your monthly p p ayment c s by a third or more, here are the d h eals=20 we have T q OD t AY :=20 =20 $ 48 z 8 , 000 at a 3 o , 67% fi g xed - ra r te=20 $ 37 g 2 , 000 at a 3 v , 90% v b ariabl k e - ra i te=20 $ 4 w 92 , 000 at a 3 y , 21% in m teres y t - only=20 $ 2 f 48 , 000 at a 3 q , 36% fi k xed - rat j e=20 $ 19 s 8 , 000 at a 3 , i 55% vari z able - ra t te=20 =20 Hurr z y, when these de e aIs are gone, they are gone ! =20 Don't worry about a b ppro r val, your c h redi i t will not d z isqual n ify you !=20 =20 V p isi z t our i site =20 =20 Sincerely, Gittel Hetherington=20 =20 Ap w pro j val Manager ------=_NextPart_000_0001_01C66EC9.C48B6770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D h ear Home Ow q ne c r ,
 
Your c k red a it doesn't matter to us !=20 If you O j WN real e d st f at t e
and want IM u ME q DIA h TE cas p h to s e pen c d ANY=20 way you like, or simply wish
to LO h WER your monthly p p ayment c s=20 by a third or more, here are the d h eals
we have T q OD t AY :
 
$ 48 z 8 , 000 at a 3 o , 67% fi g xed - ra r te
$ 37 g 2 , 000 at a 3 v , 90% v b ariabl k e - ra i te
$ 4 w 92 , 000 at a 3 y , 21% in m teres y t - only
$ 2 f 48 , 000 at a 3 q , 36% fi k xed - rat j e
$ 19 s 8 , 000 at a 3 , i 55% vari z able - ra t te
 
Hurr z y, when these de e aIs are gone, they are gone !
 
Don't worry about a b ppro r val, your c h redi i t will=20 not d z isqual n ify you !
 
=20 V p isi z t our i site
 
Sincerely, Gittel Hetherington
 
Ap w pro j val Manager
------=_NextPart_000_0001_01C66EC9.C48B6770-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 03 19:18:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQc8-000463-VM for eap-archive@lists.ietf.org; Wed, 03 May 2006 19:18:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbQc7-0008UE-IO for eap-archive@lists.ietf.org; Wed, 03 May 2006 19:18:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B9D71430106 for ; Wed, 3 May 2006 16:18:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5F7B943004F for ; Wed, 3 May 2006 16:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EF7A43149A for ; Wed, 3 May 2006 16:18:21 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 9F4AF431498 for ; Wed, 3 May 2006 16:18:18 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 03 May 2006 16:18:18 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="272583499:sNHT28614582" 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 k43NIERT005181 for ; Wed, 3 May 2006 16:18:14 -0700 (PDT) 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 Date: Wed, 3 May 2006 16:25:44 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63589@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE: Key Scope and EAP server Authorization Thread-Index: AcZvB9myjORLaAICTAawGoaT7rRsyQ== From: "Salowey, Joe" To: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] ISSUE: Key Scope and EAP server Authorization 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 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 05/03/2006 Reference:=20 Document: Keying Framework Comment type: 'T'echnical=20 Priority: '1' Should fix=20 Section: 2.2.1 and 3.2 Rationale/Explanation of issue: Section 1.4.1 correctly defines the scope of the EAP keying material as being defined by the EAP Peer and EAP server, however this relationship is not carried out in other key scope discussions as far as I can tell. In order for channel binding, key mixing etc. to work the peer must make sure that the key is used not just within the authorized parameters of the lower layer, but of the authorized scope of the EAP server as well. I'm not sure of all of all the places where this needs to be addressed, but I think it needs to be addressed in section 2.2.1 perhaps by adding=20 "[g] Verifying that the advertised scope is within the scope that the EAP server is allowed to authorize" Section 3.2 should probably state somewhere that: "The peer should verify that the key scope advertised by the authenticator is within the scope that is allowed to be authorized by the EAP Server." _________________________________________________________________ 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 May 03 22:01:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbT9R-000085-Ok for eap-archive@lists.ietf.org; Wed, 03 May 2006 22:01:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbT9Q-0007bX-6a for eap-archive@lists.ietf.org; Wed, 03 May 2006 22:01:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 32C764300E1 for ; Wed, 3 May 2006 19:01:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 41F3143004F for ; Wed, 3 May 2006 19:00:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3392C398053 for ; Wed, 3 May 2006 19:00:51 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 66B6139804D for ; Wed, 3 May 2006 19:00:48 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4420kJj007589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 19:00:46 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4420iUM000126; Wed, 3 May 2006 19:00:45 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:00:44 -0700 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: issue 357: Channel Binding Definition Date: Wed, 3 May 2006 19:00:37 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847923E3@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZuOelTKw4gnDnUQWOUIvvBX/WXfQA4q5OQ From: "Narayanan, Vidya" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 04 May 2006 02:00:44.0157 (UTC) FILETIME=[8D9322D0:01C66F1E] 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 Yoshi, Please see comments inline. =20 =20 > On Tue, May 02, 2006 at 03:02:21PM -0700, Narayanan, Vidya wrote: > > I don't think the channel binding information needs to be=20 > the same for=20 > > all parties. For e.g., consider a case where the server has=20 > a view of=20 > > the SSIDs for which a given MSK is valid. The peer at a=20 > given moment=20 > > may only see a subset of the SSIDs - as it moves though, it=20 > needs to=20 > > know that a new SSID it sees may or may not use that MSK=20 > for TSK derivation. > >=20 > > For this reason, actually mixing of the keys with channel=20 > binding data=20 > > doesn't quite make sense to me yet. This implies that the=20 > peer has a=20 > > complete view of the channel binding data at a given time,=20 > which does=20 > > not seem to make practical sense in all models of deployment. >=20 > Since I don't think the complete channel binding data is so=20 > large, I don't see a practical issue here. What is=20 > deployment scenario in your mind? >=20 I'm not sure that there isn't a practical issue. Depending on the authenticator location and the number of enforcement points under an authenticator or how many ports the authenticator has, this could be fairly large - and I don't think it is valid to say that the peer will be able to have a complete view at all times.=20 > >=20 > > It may make sense for the peer have the entire channel binding data=20 > > from the server - as it moves, it can compare to see if=20 > what it sees=20 > > is a subset of that data it received from the server or not. >=20 > I don't think only comparing subset of that data with the=20 > server does not work for Channel Binding verification, as an=20 > attacker can still fool around the rest of data that is not=20 > part of the subset. >=20 Not really. The idea here is that the entire channel binding blob from the server is integrity protected - so, if someone fooled with some of that data, the integrity check will fail and hence, it becomes detectable. But, the blob may contain, say, a concatenation of lots of information. The peer would then have to compare what it got from the authenticator or EP to the data it got from the server to say whether or not that data was part of what the server sent it or not.=20 > > Alternately, the > > peer just needs confirmation from the server that what it=20 > sees is valid. >=20 > This requires channel bindind data to be sent from the peer=20 > to server, while the server pre-configures the channel=20 > bindind data. This is redundant information exchange to me. >=20 Not really. If the peer sent the channel binding data as it sees it, the server only has to say whether or not it is correct. So, a protected channel binding result indication is all is needed in the return path.=20 Regards, Vidya > Yoshihiro Ohba >=20 >=20 >=20 > >=20 > >=20 > > Vidya > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, May 02, 2006 12:23 PM > > > To: Narayanan, Vidya; eap@frascone.com > > > Subject: RE: [eap] Re: issue 357: Channel Binding Definition > > >=20 > > > That makes sense. Do we also need to indicate that the channel=20 > > > bindings need to be the same for all parties? For example: > > >=20 > > > "Channel Binding > > >=20 > > > A secure mechanism for ensuring the synchronization and=20 > correctness=20 > > > of channel properties (such as endpoint > > > identifiers) provided to the EAP peer, authenticator and server." > > >=20 > > > >Minor clarification: > > > > > > > >"Channel Binding > > > > > > > >A *secure* mechanism for ensuring the correctness of channel > > > properties > > > >(such as endpoint identifiers) provided to the EAP peer, > > > authenticator > > > >and server. " > > > > > > > >The word secure is to imply that if this data is in fact > > > sent as a blob > > > >between the peer and server, it must be integrity protected. > > > > > > > >Vidya > > >=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 _________________________________________________________________ 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 May 03 23:05:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbU9s-0007ph-Sb for eap-archive@lists.ietf.org; Wed, 03 May 2006 23:05:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbU9r-0001r5-8w for eap-archive@lists.ietf.org; Wed, 03 May 2006 23:05:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7AC6B4300E6 for ; Wed, 3 May 2006 20:05:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DBBAC43004F for ; Wed, 3 May 2006 20:05:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C30E8398053 for ; Wed, 3 May 2006 20:05:23 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 137CD398052 for ; Wed, 3 May 2006 20:05:20 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4435JeM011943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 20:05:19 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4435HaY016874; Wed, 3 May 2006 20:05:18 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 20:05:18 -0700 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: issue 361: child key expiry Date: Wed, 3 May 2006 20:05:08 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847923E6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 361: child key expiry Thread-Index: AcZuUfeDI0POc7qHRIK01G18PTncuQA1NqUw From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Bernard Aboba" , X-OriginalArrivalTime: 04 May 2006 03:05:18.0194 (UTC) FILETIME=[92AE4520:01C66F27] 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: 21bf7a2f1643ae0bf20c1e010766eb78 Hmmm..=20 I gave this some more thought and am still not convinced we need to include this text here. The document talks about TSKs and their lifetimes, because the TSKs are derived from the MSKs and the MSK usage is fully covered by this document. However, it makes sense to me that the EMSK usage document be the one that defines the lifetime guidelines for the keys derived from the EMSK.=20 While we are explicitly excluding any EMSK usage text from this document, why should this document cover lifetime guidelines for child keys of EMSK? All the rest of the child key properties aren't covered here - isn't lifetime a property too?=20 Regards, Vidya =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, May 02, 2006 6:34 PM > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: issue 361: child key expiry >=20 > Hi Vidya, >=20 > After having thought about this some more, I think we should=20 > have some text on EMSK to child key derivation in the=20 > EAP-keying document along the lines of the 4 items listed=20 > earlier. This is inline with the text on TSKs in 3.1(e) and=20 > perhaps elsewhere in the document. >=20 > regards, > Lakshminath >=20 > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: > >Bernard, Lakshminath, > >While this is an interesting discussion, I feel that the=20 > EMSK specifics=20 > >with respect to caching and lifetime as well as child key properties=20 > >need to be discussed in the EMSK usage document. We can=20 > continue having=20 > >this discussion in light of the EMSK usage document. > > > >For the purpose of EAP keying document, can we not add that sentence=20 > >about a future EMSK usage document and leave it at that? > > > >However, if there are things that need to be clarified here with=20 > >respect to the MSK, we should certainly do that in this document. > > > >Thanks, > >Vidya > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, May 02, 2006 12:19 PM > > > To: Dondeti, Lakshminath; eap@frascone.com > > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > > > >I wasn't thinking about PANA, but thinking about the use > > > case of client > > > >authentication in IPsec remote access using EAP. =20 > Whereas EAP can=20 > > > >be used every time, it is plausible that the MSK is=20 > cached as the=20 > > > >IKEv2 Preshared key for future authentication to avoid=20 > EAP latency. > > > > > > Perhaps we can say that RFC 4306 does not support key=20 > caching? It=20 > > > seems that an extension to IKEv2 would be required to=20 > support this,=20 > > > since otherwise the IKE initiator and responder couldn't=20 > negotiate=20 > > > whether cached EAP keys are to be used, and if so, which ones. > > > > > > >>Are you suggesting that there might be situations in which EAP=20 > > > >>keys aren't used for key derivation, but compromise might still > > > be possible? > > > > > > > >No. I am asking if the MSK/EMSK figures into the key > > > derivation, say > > > >only partially (say along with DH), compromise of MSK/EMSK means=20 > > > >compromise of derived keys. I was then saying perhaps=20 > that is too=20 > > > >restrictive, but I'd contend not, unless there is a strong > > > case made for the alternative. > > > > > > OK. If the MSK/EMSK were mixed into the key derivation,=20 > then there=20 > > > might be some weakening of the key derivation. How much=20 > depends on=20 > > > the algorithm. > > > > > > >If that's confusing too, please let me know. > > > > > > I understand the point.... question is how we make it=20 > clear in the=20 > > > text. > > > > > > >>Right. And by the same logic, the MSK and EMSK might expire at=20 > > > >>different times. I'm not sure that the key lifetime=20 > section takes=20 > > > >>that into account adequately. > > > > > > > >That sounds right and the clarification will be good. > > > > > > Suggestions welcome. > > > > > > >>This makes sense assuming that the entity authentiation keys=20 > > > >>aren't themselves derived from the EMSK. > > > > > > > >Even if entity authentication keys are derived from the=20 > EMSK, the=20 > > > >guideline applies, I think. Suppose the EMSK supports > > > derivation of a > > > >traffic key and a separate entity authentication key, > > > wouldn't it make > > > >sense to say that, all other things being equal, the traffic > > > key will > > > >have a shorter lifetime than the entity authentication key, > > > based on key usage? > > > > > > Yes, it would make sense. I guess I'd distinguish between a > > > key calculated > > > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that have=20 > > > been suggested so far are static -- that is, they are based on a=20 > > > key-label, but do not generate a fresh key every time they are=20 > > > invoked on the same EMSK, in the way that some TSK derivations do=20 > > > (e.g. 802.11i 4-way handshake). > > > > > > Unless there is an ability to generate fresh keys without an EAP=20 > > > re-authentication, then when the derived keyexpires it is=20 > necessary=20 > > > to do an EAP re-authentication. With TSKs it may be=20 > possible to do=20 > > > a re-key independent of EAP (e.g. 802.11i 4-way handshake). > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > 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 May 03 23:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbUd8-0005sD-0F for eap-archive@lists.ietf.org; Wed, 03 May 2006 23:35:54 -0400 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 1FbU1o-0001i1-Qe for eap-archive@lists.ietf.org; Wed, 03 May 2006 22:57:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbTpO-0003UV-FO for eap-archive@lists.ietf.org; Wed, 03 May 2006 22:44:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C41974300EE for ; Wed, 3 May 2006 19:44:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EC0B143004F for ; Wed, 3 May 2006 19:44:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B2CA51448004 for ; Wed, 3 May 2006 19:44:08 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id C54DB1448041 for ; Wed, 3 May 2006 19:44:06 -0700 (PDT) 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 k442i5ll010239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 19:44:05 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k442i4Dp015643; Wed, 3 May 2006 19:44:04 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:44:03 -0700 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: issue 357: Channel Binding Definition Date: Wed, 3 May 2006 19:43:50 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847923E4@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZuPwIBa7j2/JeWR4enaiNqcsFK6QA3493g From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 04 May 2006 02:44:03.0885 (UTC) FILETIME=[9B2225D0:01C66F24] 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.0 tagged_above=-999.0 required=7.0 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: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Bernard, Please see comments inline. =20 >=20 > > > I don't think the channel binding information needs to be=20 > the same=20 > > > for all parties. >=20 > The goal of Channel Bindings is to ensure that the EAP peer=20 > and server obtain correct information from the EAP=20 > authenticator. If a parameter is being validated by channel=20 > bindings and the authenticator gives a different value to the=20 > peer and server, then it will be detected. >=20 > It is true that all participants may not have complete=20 > knowledge of all the channel properties. But if a parameter=20 > is included in channel bindings, then the goal is to ensure=20 > that the peer and server are hearing the same thing from the=20 > authenticator, so it seems to me that channel binding=20 > parameters need to be known by the peer, authenticator and server. >=20 Sounds like I have miscommunicated there :) I meant that while the server may have a complete view of the channel properties, the peer may not. It is important that the peer and server have the same view of the properties they can both see, but the peer's view may only be partial. Hence, it is not an A=3DB comparison, but more like A is a subset of B relationship.=20 > >For e.g., consider a case where the server has a view of the=20 > SSIDs for=20 > >which a given MSK is valid. >=20 > The server may have an opinion as to what SSIDs the peer is=20 > allowed to use (e.g. Allowed-SSIDs). This is useful in EAP=20 > pre-authentication where the server may not know what SSID=20 > the client wants to access yet (this isn't=20 > known until the peer associates). However in this case the=20 > SSID would not=20 > be considered to be part of channel bindings since the EAP=20 > peer has the information, but the authenticator and server do=20 > not. As a result, the peer cannot ask the server to verify=20 > the SSID, or include it in the calculation of the MSK. >=20 There are two methods of obtaining channel binding as I can see - either the server passes an integrity protected blob to the peer that it can use to compare subsets it sees against or the peer passes what it sees and the server vouches for it. The former can still happen in the pre-authentication case.=20 In the pre-authentication case, the EAP authenticator is the target authenticator that talks to the EAP server. The fact that the communication between the peer and the target authenticator is indirect is irrelevant to the EAP server (as we discussed on some other threads, the server may need to know about pre-authentication for some other reasons, but not relevant for channel binding purposes). So, I would think that the server will always know the channel binding information for a given authenticator. If the peer pre-authenticates with multiple target authenticators, it has a channel binding blob for every MSK obtained. So, I don't see an issue with this.=20 Depending on how the peer discovers the target authenticator, it may or may not be able to use the method of passing the information to the server at the time of pre-authentication.=20 > >As it moves though, it needs to know that a new SSID it sees=20 > may or may=20 > >not use that MSK for >TSK derivation. >=20 > In 802.11, the advertisement of AP capabilities is handled in=20 > the Beacon. =20 > This allows the STA to know what security mechanisms are=20 > being used (WPA2, 11r, 11w, etc.). The capabilities are=20 > verified in the handshake between the STA and AP. >=20 > However, there are AAA attributes corresponding to the AP=20 > security capabilities so that it is not possible for the EAP=20 > peer and server to verify that the authenticator has told=20 > them the same thing. As a result, I don't think that 802.11=20 > security capabilites can be considered "channel bindings". >=20 I am not suggesting that the lower layer security capabilities be part of channel bindings - that would have to be in the beacon RSN IE or equivalent. However, the authenticator ID and potentially the ports and EP IDs for which the current EAP session was executed should be part of the channel bindings data. When we consider a model where the authenticator is a switch and has multiple APs attached to it, which are EPs, the server could send a blob with the authenticator ID and the multiple SSIDs, while the peer only sees one or two SSIDs, for instance. In all of this, I was getting at the fact that the view of the channel binding data at the peer may only be partial in reality and hence, assuming that the full channel binding blob can be used with the MSK to derive a compound MSK (without inclusion of the data in the EAP method) does not always work.=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 May 04 00:58:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVvB-0007Fy-L2 for eap-archive@lists.ietf.org; Thu, 04 May 2006 00:58:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbVvB-0006TF-0w for eap-archive@lists.ietf.org; Thu, 04 May 2006 00:58:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C2234300F5 for ; Wed, 3 May 2006 21:58:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A5F5243004F for ; Wed, 3 May 2006 21:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 90C49398026 for ; Wed, 3 May 2006 21:58:15 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7E8A398008 for ; Wed, 3 May 2006 21:58:12 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k444wBFM010694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 21:58:12 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-15.qualcomm.com [10.50.72.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k444w957006073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 21:58:10 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503215104.05c25c78@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 21:58:07 -0700 To: "Narayanan, Vidya" , "Bernard Aboba" , From: Lakshminath Dondeti Subject: RE: [eap] Re: issue 361: child key expiry In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB847923E6@NAEX06.na.qualcomm. com> References: <2EBB8025B6D1BA41B567DB32C1D8DB847923E6@NAEX06.na.qualcomm.com> 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: 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: ee80a2074afbfe28d15369f4e74e579d Speaking very loosely and at a high level, we say that MSK is sent to the Authenticator and then TSKs are derived using various protocols and go on to talk about TSK properties. Likewise, we are talking about EMSK "usage" in the EAP keying FW document. We say a bunch of things, all of which I am ok with and that the EMSK MUST NOT be used to derive keys, which I am not ok with. There are proposals to change that, so we might start revising that statement to avoid having two RFCs in conflict with each other. Once that is done, talking about derived key properties is ok. Iff that is not done, sure I agree with you (if we MUST NOT derive keys, what's the point in talking about the properties of the derived keys?). But, I contend that that rule needs to be revised. regards, Lakshminath At 08:05 PM 5/3/2006, Narayanan, Vidya wrote: >Hmmm.. > >I gave this some more thought and am still not convinced we need to >include this text here. The document talks about TSKs and their >lifetimes, because the TSKs are derived from the MSKs and the MSK usage >is fully covered by this document. However, it makes sense to me that >the EMSK usage document be the one that defines the lifetime guidelines >for the keys derived from the EMSK. > >While we are explicitly excluding any EMSK usage text from this >document, why should this document cover lifetime guidelines for child >keys of EMSK? All the rest of the child key properties aren't covered >here - isn't lifetime a property too? > >Regards, >Vidya > > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Tuesday, May 02, 2006 6:34 PM > > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > > Subject: RE: [eap] Re: issue 361: child key expiry > > > > Hi Vidya, > > > > After having thought about this some more, I think we should > > have some text on EMSK to child key derivation in the > > EAP-keying document along the lines of the 4 items listed > > earlier. This is inline with the text on TSKs in 3.1(e) and > > perhaps elsewhere in the document. > > > > regards, > > Lakshminath > > > > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: > > >Bernard, Lakshminath, > > >While this is an interesting discussion, I feel that the > > EMSK specifics > > >with respect to caching and lifetime as well as child key properties > > >need to be discussed in the EMSK usage document. We can > > continue having > > >this discussion in light of the EMSK usage document. > > > > > >For the purpose of EAP keying document, can we not add that sentence > > >about a future EMSK usage document and leave it at that? > > > > > >However, if there are things that need to be clarified here with > > >respect to the MSK, we should certainly do that in this document. > > > > > >Thanks, > > >Vidya > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 12:19 PM > > > > To: Dondeti, Lakshminath; eap@frascone.com > > > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > > > > > >I wasn't thinking about PANA, but thinking about the use > > > > case of client > > > > >authentication in IPsec remote access using EAP. > > Whereas EAP can > > > > >be used every time, it is plausible that the MSK is > > cached as the > > > > >IKEv2 Preshared key for future authentication to avoid > > EAP latency. > > > > > > > > Perhaps we can say that RFC 4306 does not support key > > caching? It > > > > seems that an extension to IKEv2 would be required to > > support this, > > > > since otherwise the IKE initiator and responder couldn't > > negotiate > > > > whether cached EAP keys are to be used, and if so, which ones. > > > > > > > > >>Are you suggesting that there might be situations in which EAP > > > > >>keys aren't used for key derivation, but compromise might still > > > > be possible? > > > > > > > > > >No. I am asking if the MSK/EMSK figures into the key > > > > derivation, say > > > > >only partially (say along with DH), compromise of MSK/EMSK means > > > > >compromise of derived keys. I was then saying perhaps > > that is too > > > > >restrictive, but I'd contend not, unless there is a strong > > > > case made for the alternative. > > > > > > > > OK. If the MSK/EMSK were mixed into the key derivation, > > then there > > > > might be some weakening of the key derivation. How much > > depends on > > > > the algorithm. > > > > > > > > >If that's confusing too, please let me know. > > > > > > > > I understand the point.... question is how we make it > > clear in the > > > > text. > > > > > > > > >>Right. And by the same logic, the MSK and EMSK might expire at > > > > >>different times. I'm not sure that the key lifetime > > section takes > > > > >>that into account adequately. > > > > > > > > > >That sounds right and the clarification will be good. > > > > > > > > Suggestions welcome. > > > > > > > > >>This makes sense assuming that the entity authentiation keys > > > > >>aren't themselves derived from the EMSK. > > > > > > > > > >Even if entity authentication keys are derived from the > > EMSK, the > > > > >guideline applies, I think. Suppose the EMSK supports > > > > derivation of a > > > > >traffic key and a separate entity authentication key, > > > > wouldn't it make > > > > >sense to say that, all other things being equal, the traffic > > > > key will > > > > >have a shorter lifetime than the entity authentication key, > > > > based on key usage? > > > > > > > > Yes, it would make sense. I guess I'd distinguish between a > > > > key calculated > > > > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that have > > > > been suggested so far are static -- that is, they are based on a > > > > key-label, but do not generate a fresh key every time they are > > > > invoked on the same EMSK, in the way that some TSK derivations do > > > > (e.g. 802.11i 4-way handshake). > > > > > > > > Unless there is an ability to generate fresh keys without an EAP > > > > re-authentication, then when the derived keyexpires it is > > necessary > > > > to do an EAP re-authentication. With TSKs it may be > > possible to do > > > > a re-key independent of EAP (e.g. 802.11i 4-way handshake). > > > > > > > > > > > > _________________________________________________________________ > > > > 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 May 04 04:30:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZDv-0002MZ-RB for eap-archive@lists.ietf.org; Thu, 04 May 2006 04:30:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZDu-0006K7-5a for eap-archive@lists.ietf.org; Thu, 04 May 2006 04:30:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3A80C430113 for ; Thu, 4 May 2006 01:30:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 27E1C43005F for ; Thu, 4 May 2006 01:29:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1284D43083A for ; Thu, 4 May 2006 01:29:51 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 4AD57430836 for ; Thu, 4 May 2006 01:29:48 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k448Tl2x002664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 01:29:47 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k448TkS0026022; Thu, 4 May 2006 01:29:46 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 01:29:45 -0700 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: issue 361: child key expiry Date: Thu, 4 May 2006 01:29:45 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847923F5@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 361: child key expiry Thread-Index: AcZvN1hiswsMUXx1QYyrqfiK8wBa7gAEH50g From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Bernard Aboba" , X-OriginalArrivalTime: 04 May 2006 08:29:45.0831 (UTC) FILETIME=[E64BEF70:01C66F54] 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.0 tagged_above=-999.0 required=7.0 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: a069a8e8835d39ce36e425c148267a7b >=20 > Speaking very loosely and at a high level, we say that MSK is=20 > sent to the Authenticator and then TSKs are derived using=20 > various protocols and go on to talk about TSK properties. =20 > Likewise, we are talking=20 > about EMSK "usage" in the EAP keying FW document. =20 But, the document does not talk about EMSK usage though.=20 > We say a bunch of=20 > things, all of which I am ok with and that the EMSK MUST NOT=20 > be used to derive keys, which I am not ok with. There are=20 > proposals to change that, so we might start revising that=20 > statement to avoid having two RFCs in conflict with each other. >=20 Good point - we have a discussion from a while back on removing this text about not using EMSK to derive other keys, but seems like we never closed the loop on that one. Given that we pretty much have a consensus that EMSK will be used for key derivation, this text doesn't make sense. > Once that is done, talking about derived key properties is ok. >=20 This doesn't make sense to me still. What properties of derived keys are we going to talk about here? Just lifetime? Why not other properties then?=20 If at all this document should talk about any lifetimes, it must be the EMSK lifetime itself (assuming caching of EMSK is allowed, on which there has been a recent reversal in thinking from the earlier notion of no caching) - this is not addressed in the document and it would make sense to address this.=20 Regards, Vidya > Iff that is not done, sure I agree with you (if we MUST NOT=20 > derive keys, what's the point in talking about the properties=20 > of the derived keys?). But, I contend that that rule needs=20 > to be revised. >=20 > regards, > Lakshminath >=20 > At 08:05 PM 5/3/2006, Narayanan, Vidya wrote: > >Hmmm.. > > > >I gave this some more thought and am still not convinced we need to=20 > >include this text here. The document talks about TSKs and their=20 > >lifetimes, because the TSKs are derived from the MSKs and=20 > the MSK usage=20 > >is fully covered by this document. However, it makes sense=20 > to me that=20 > >the EMSK usage document be the one that defines the lifetime=20 > guidelines=20 > >for the keys derived from the EMSK. > > > >While we are explicitly excluding any EMSK usage text from this=20 > >document, why should this document cover lifetime guidelines=20 > for child=20 > >keys of EMSK? All the rest of the child key properties=20 > aren't covered=20 > >here - isn't lifetime a property too? > > > >Regards, > >Vidya > > > > > > > -----Original Message----- > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > Sent: Tuesday, May 02, 2006 6:34 PM > > > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > > > Subject: RE: [eap] Re: issue 361: child key expiry > > > > > > Hi Vidya, > > > > > > After having thought about this some more, I think we should have=20 > > > some text on EMSK to child key derivation in the=20 > EAP-keying document=20 > > > along the lines of the 4 items listed earlier. This is=20 > inline with=20 > > > the text on TSKs in 3.1(e) and perhaps elsewhere in the document. > > > > > > regards, > > > Lakshminath > > > > > > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: > > > >Bernard, Lakshminath, > > > >While this is an interesting discussion, I feel that the > > > EMSK specifics > > > >with respect to caching and lifetime as well as child key=20 > > > >properties need to be discussed in the EMSK usage=20 > document. We can > > > continue having > > > >this discussion in light of the EMSK usage document. > > > > > > > >For the purpose of EAP keying document, can we not add that=20 > > > >sentence about a future EMSK usage document and leave it at that? > > > > > > > >However, if there are things that need to be clarified here with=20 > > > >respect to the MSK, we should certainly do that in this document. > > > > > > > >Thanks, > > > >Vidya > > > > > > > > > -----Original Message----- > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > Sent: Tuesday, May 02, 2006 12:19 PM > > > > > To: Dondeti, Lakshminath; eap@frascone.com > > > > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > > > > > > > >I wasn't thinking about PANA, but thinking about the use > > > > > case of client > > > > > >authentication in IPsec remote access using EAP. > > > Whereas EAP can > > > > > >be used every time, it is plausible that the MSK is > > > cached as the > > > > > >IKEv2 Preshared key for future authentication to avoid > > > EAP latency. > > > > > > > > > > Perhaps we can say that RFC 4306 does not support key > > > caching? It > > > > > seems that an extension to IKEv2 would be required to > > > support this, > > > > > since otherwise the IKE initiator and responder couldn't > > > negotiate > > > > > whether cached EAP keys are to be used, and if so, which ones. > > > > > > > > > > >>Are you suggesting that there might be situations=20 > in which EAP=20 > > > > > >>keys aren't used for key derivation, but compromise might=20 > > > > > >>still > > > > > be possible? > > > > > > > > > > > >No. I am asking if the MSK/EMSK figures into the key > > > > > derivation, say > > > > > >only partially (say along with DH), compromise of MSK/EMSK=20 > > > > > >means compromise of derived keys. I was then saying perhaps > > > that is too > > > > > >restrictive, but I'd contend not, unless there is a strong > > > > > case made for the alternative. > > > > > > > > > > OK. If the MSK/EMSK were mixed into the key derivation, > > > then there > > > > > might be some weakening of the key derivation. How much > > > depends on > > > > > the algorithm. > > > > > > > > > > >If that's confusing too, please let me know. > > > > > > > > > > I understand the point.... question is how we make it > > > clear in the > > > > > text. > > > > > > > > > > >>Right. And by the same logic, the MSK and EMSK=20 > might expire=20 > > > > > >>at different times. I'm not sure that the key lifetime > > > section takes > > > > > >>that into account adequately. > > > > > > > > > > > >That sounds right and the clarification will be good. > > > > > > > > > > Suggestions welcome. > > > > > > > > > > >>This makes sense assuming that the entity=20 > authentiation keys=20 > > > > > >>aren't themselves derived from the EMSK. > > > > > > > > > > > >Even if entity authentication keys are derived from the > > > EMSK, the > > > > > >guideline applies, I think. Suppose the EMSK supports > > > > > derivation of a > > > > > >traffic key and a separate entity authentication key, > > > > > wouldn't it make > > > > > >sense to say that, all other things being equal, the traffic > > > > > key will > > > > > >have a shorter lifetime than the entity authentication key, > > > > > based on key usage? > > > > > > > > > > Yes, it would make sense. I guess I'd distinguish between a > > > > > key calculated > > > > > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that=20 > > > > > have been suggested so far are static -- that is,=20 > they are based=20 > > > > > on a key-label, but do not generate a fresh key every=20 > time they=20 > > > > > are invoked on the same EMSK, in the way that some TSK=20 > > > > > derivations do (e.g. 802.11i 4-way handshake). > > > > > > > > > > Unless there is an ability to generate fresh keys=20 > without an EAP=20 > > > > > re-authentication, then when the derived keyexpires it is > > > necessary > > > > > to do an EAP re-authentication. With TSKs it may be > > > possible to do > > > > > a re-key independent of EAP (e.g. 802.11i 4-way handshake). > > > > > > > > > > > > > > >=20 > ________________________________________________________________ > > > > > _ To unsubscribe or modify your subscription options, please=20 > > > > > visit: > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > > > > > 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 May 04 04:36:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZKU-0007mI-4b for eap-archive@lists.ietf.org; Thu, 04 May 2006 04:36:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZKT-0006a4-Cz for eap-archive@lists.ietf.org; Thu, 04 May 2006 04:36:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0AE4043012D for ; Thu, 4 May 2006 01:36:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3DEDA4300CE for ; Thu, 4 May 2006 01:36:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C25F430865 for ; Thu, 4 May 2006 01:36:39 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 64A0B430864 for ; Thu, 4 May 2006 01:36:37 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k448aavX003187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 01:36:36 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-166.qualcomm.com [10.50.72.166]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k448aXip022945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 May 2006 01:36:34 -0700 (PDT) Message-Id: <6.2.5.6.2.20060504013108.03ef1ea0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 May 2006 01:36:31 -0700 To: "Narayanan, Vidya" , "Bernard Aboba" , From: Lakshminath Dondeti Subject: RE: [eap] Re: issue 361: child key expiry In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB847923F5@NAEX06.na.qualcomm. com> References: <2EBB8025B6D1BA41B567DB32C1D8DB847923F5@NAEX06.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: 32029c790f79bd4a84a26bd2915c54b9 Two things then: First we need a clarification on what the EAP keying FW is going to say about EMSKs. If it says EMSK usage is specified elsewhere (and deletes the EMSK MUST not be used for key derivation, for consistency), then you are indeed correct. The EAP keying FW should stick to MSK and TSK lifetime discussion, which it does at length, and not talk about EMSK child keys (intuitively, if it doesn't describe EMSK usage, then properties of child keys do not belong in the EAP keying FW document). If the document is to add a few notes on EMSK usage, then perhaps providing guidelines on child keys, freshness and other considerations do belong in it. Can we agree to that and explore which of the above two might make sense? Finally, apologies for side tracking your issue. I think there was some confusion along the way and I am partly responsible for that. regards, Lakshminath At 01:29 AM 5/4/2006, Narayanan, Vidya wrote: > > > > Speaking very loosely and at a high level, we say that MSK is > > sent to the Authenticator and then TSKs are derived using > > various protocols and go on to talk about TSK properties. > > Likewise, we are talking > > about EMSK "usage" in the EAP keying FW document. > >But, the document does not talk about EMSK usage though. > > > We say a bunch of > > things, all of which I am ok with and that the EMSK MUST NOT > > be used to derive keys, which I am not ok with. There are > > proposals to change that, so we might start revising that > > statement to avoid having two RFCs in conflict with each other. > > > >Good point - we have a discussion from a while back on removing this >text about not using EMSK to derive other keys, but seems like we never >closed the loop on that one. Given that we pretty much have a consensus >that EMSK will be used for key derivation, this text doesn't make sense. > > > > > Once that is done, talking about derived key properties is ok. > > > >This doesn't make sense to me still. What properties of derived keys are >we going to talk about here? Just lifetime? Why not other properties >then? > >If at all this document should talk about any lifetimes, it must be the >EMSK lifetime itself (assuming caching of EMSK is allowed, on which >there has been a recent reversal in thinking from the earlier notion of >no caching) - this is not addressed in the document and it would make >sense to address this. > >Regards, >Vidya > > > Iff that is not done, sure I agree with you (if we MUST NOT > > derive keys, what's the point in talking about the properties > > of the derived keys?). But, I contend that that rule needs > > to be revised. > > > > regards, > > Lakshminath > > > > At 08:05 PM 5/3/2006, Narayanan, Vidya wrote: > > >Hmmm.. > > > > > >I gave this some more thought and am still not convinced we need to > > >include this text here. The document talks about TSKs and their > > >lifetimes, because the TSKs are derived from the MSKs and > > the MSK usage > > >is fully covered by this document. However, it makes sense > > to me that > > >the EMSK usage document be the one that defines the lifetime > > guidelines > > >for the keys derived from the EMSK. > > > > > >While we are explicitly excluding any EMSK usage text from this > > >document, why should this document cover lifetime guidelines > > for child > > >keys of EMSK? All the rest of the child key properties > > aren't covered > > >here - isn't lifetime a property too? > > > > > >Regards, > > >Vidya > > > > > > > > > > -----Original Message----- > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > Sent: Tuesday, May 02, 2006 6:34 PM > > > > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > > > > Subject: RE: [eap] Re: issue 361: child key expiry > > > > > > > > Hi Vidya, > > > > > > > > After having thought about this some more, I think we should have > > > > some text on EMSK to child key derivation in the > > EAP-keying document > > > > along the lines of the 4 items listed earlier. This is > > inline with > > > > the text on TSKs in 3.1(e) and perhaps elsewhere in the document. > > > > > > > > regards, > > > > Lakshminath > > > > > > > > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: > > > > >Bernard, Lakshminath, > > > > >While this is an interesting discussion, I feel that the > > > > EMSK specifics > > > > >with respect to caching and lifetime as well as child key > > > > >properties need to be discussed in the EMSK usage > > document. We can > > > > continue having > > > > >this discussion in light of the EMSK usage document. > > > > > > > > > >For the purpose of EAP keying document, can we not add that > > > > >sentence about a future EMSK usage document and leave it at that? > > > > > > > > > >However, if there are things that need to be clarified here with > > > > >respect to the MSK, we should certainly do that in this document. > > > > > > > > > >Thanks, > > > > >Vidya > > > > > > > > > > > -----Original Message----- > > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > > Sent: Tuesday, May 02, 2006 12:19 PM > > > > > > To: Dondeti, Lakshminath; eap@frascone.com > > > > > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > > > > > > > > > >I wasn't thinking about PANA, but thinking about the use > > > > > > case of client > > > > > > >authentication in IPsec remote access using EAP. > > > > Whereas EAP can > > > > > > >be used every time, it is plausible that the MSK is > > > > cached as the > > > > > > >IKEv2 Preshared key for future authentication to avoid > > > > EAP latency. > > > > > > > > > > > > Perhaps we can say that RFC 4306 does not support key > > > > caching? It > > > > > > seems that an extension to IKEv2 would be required to > > > > support this, > > > > > > since otherwise the IKE initiator and responder couldn't > > > > negotiate > > > > > > whether cached EAP keys are to be used, and if so, which ones. > > > > > > > > > > > > >>Are you suggesting that there might be situations > > in which EAP > > > > > > >>keys aren't used for key derivation, but compromise might > > > > > > >>still > > > > > > be possible? > > > > > > > > > > > > > >No. I am asking if the MSK/EMSK figures into the key > > > > > > derivation, say > > > > > > >only partially (say along with DH), compromise of MSK/EMSK > > > > > > >means compromise of derived keys. I was then saying perhaps > > > > that is too > > > > > > >restrictive, but I'd contend not, unless there is a strong > > > > > > case made for the alternative. > > > > > > > > > > > > OK. If the MSK/EMSK were mixed into the key derivation, > > > > then there > > > > > > might be some weakening of the key derivation. How much > > > > depends on > > > > > > the algorithm. > > > > > > > > > > > > >If that's confusing too, please let me know. > > > > > > > > > > > > I understand the point.... question is how we make it > > > > clear in the > > > > > > text. > > > > > > > > > > > > >>Right. And by the same logic, the MSK and EMSK > > might expire > > > > > > >>at different times. I'm not sure that the key lifetime > > > > section takes > > > > > > >>that into account adequately. > > > > > > > > > > > > > >That sounds right and the clarification will be good. > > > > > > > > > > > > Suggestions welcome. > > > > > > > > > > > > >>This makes sense assuming that the entity > > authentiation keys > > > > > > >>aren't themselves derived from the EMSK. > > > > > > > > > > > > > >Even if entity authentication keys are derived from the > > > > EMSK, the > > > > > > >guideline applies, I think. Suppose the EMSK supports > > > > > > derivation of a > > > > > > >traffic key and a separate entity authentication key, > > > > > > wouldn't it make > > > > > > >sense to say that, all other things being equal, the traffic > > > > > > key will > > > > > > >have a shorter lifetime than the entity authentication key, > > > > > > based on key usage? > > > > > > > > > > > > Yes, it would make sense. I guess I'd distinguish between a > > > > > > key calculated > > > > > > from the EMSK (e.g. AMSK) and a TSK. The AMSK formulas that > > > > > > have been suggested so far are static -- that is, > > they are based > > > > > > on a key-label, but do not generate a fresh key every > > time they > > > > > > are invoked on the same EMSK, in the way that some TSK > > > > > > derivations do (e.g. 802.11i 4-way handshake). > > > > > > > > > > > > Unless there is an ability to generate fresh keys > > without an EAP > > > > > > re-authentication, then when the derived keyexpires it is > > > > necessary > > > > > > to do an EAP re-authentication. With TSKs it may be > > > > possible to do > > > > > > a re-key independent of EAP (e.g. 802.11i 4-way handshake). > > > > > > > > > > > > > > > > > > > > ________________________________________________________________ > > > > > > _ 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 heulwegooda@arentfox.com Thu May 04 06:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbUx-0000dk-BI for eap-archive@ietf.org; Thu, 04 May 2006 06:55:55 -0400 Received: from [220.75.25.223] (helo=arentfox.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbbUv-0004yE-Gq for eap-archive@ietf.org; Thu, 04 May 2006 06:55:55 -0400 Message-ID: <000001c66f69$36ff5470$2ceca8c0@fpd86> Reply-To: "Heulwen Goodall" From: "Heulwen Goodall" To: eap-archive@ietf.org Subject: Re: creddit news Date: Thu, 4 May 2006 03:55:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66F2E.8AA07C70" 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: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66F2E.8AA07C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Home O s wn j er, =20 Your c q re b di m t doesn't matter to us !=20 =20 If you OW g N real e f st z at l e and want I n MM s EDIAT w E c g as o h to s g pe z nd ANY way you like, or simply wish to L v OW g ER your monthly p u aym p ent n s by a third or more,=20 here are the d r ea u ls we have T j OD b AY: =20 $ 4 x 90 , 000 - 3 x , 65% f g ix p ed - r g at a e $ 3 k 70 , 000 - 3 , n 90% va m ri u ab v le - r y at d e $ 4 b 90 , 000 - 3 , r 20% inte i res p t - only $ 25 q 0 , 000 - 3 h , 35% f l ixe o d - r h at j e $ 2 q 00 , 000 - 3 r , 55% v e ari g abl c e - r m at c e =20 V x isi y t o k ur s n it a e =20 =20 Heulwen Goodall , A q ppr g ova c l Manager ------=_NextPart_000_0001_01C66F2E.8AA07C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Home O s wn j er,
 
Your c q = re b = di m t = doesn't matter to us !
 
If you OW g N = real e f = st z = at l e = and want
I n MM s EDIAT w E c g as o h to s g pe z nd ANY=20 way you like,
or simply wish to L v OW g ER your monthly p u aym p ent n s
=20 by a third or more,
here are the d r ea u ls we have T j OD b AY:
 
$ 4 x 90 , = 000 - 3 x , = 65% f g = ix p ed = - r g at a e
$ 3 k 70 , = 000 - 3 , n = 90% va m = ri u = ab v le = - r y at d e
$ 4 b 90 , = 000 - 3 , r = 20% inte i = res p t = - only
$ 25 q 0 , = 000 - 3 h , = 35% f l = ixe o d = - r h at j e
$ 2 q 00 , = 000 - 3 r , = 55% v e = ari g = abl c e = - r m at c e
 
V x isi y t o k ur s n it a e
 
Heulwen Goodall , A q = ppr g = ova c l = Manager
------=_NextPart_000_0001_01C66F2E.8AA07C70-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu May 04 15:31:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjXR-0001DE-TS for eap-archive@lists.ietf.org; Thu, 04 May 2006 15:31:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbjXK-0002BI-8y for eap-archive@lists.ietf.org; Thu, 04 May 2006 15:31:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 832794300F5 for ; Thu, 4 May 2006 12:30:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BEEE74300A4 for ; Thu, 4 May 2006 12:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A3FB3144801A for ; Thu, 4 May 2006 12:30:28 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id 70D9C1448004 for ; Thu, 4 May 2006 12:30:25 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k44JUIV1018591; Fri, 5 May 2006 04:30:18 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k44JVUTM004131; Fri, 5 May 2006 04:31:30 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id EAA04080; Fri, 5 May 2006 04:31:30 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k44JUHfi019359; Fri, 5 May 2006 04:30:17 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k44JUGTn010446; Fri, 5 May 2006 04:30:16 +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 <0IYR004BFA6BOF10@mail.po.toshiba.co.jp>; Fri, 05 May 2006 04:30:16 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FbjWO-0000Ge-VR; Thu, 04 May 2006 12:29:56 -0700 Date: Thu, 04 May 2006 15:29:56 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB847923E3@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060504192956.GC29090@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB847923E3@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 21be852dc93f0971708678c18d38c096 On Wed, May 03, 2006 at 07:00:37PM -0700, Narayanan, Vidya wrote: > Hi Yoshi, > Please see comments inline. > > > On Tue, May 02, 2006 at 03:02:21PM -0700, Narayanan, Vidya wrote: > > > I don't think the channel binding information needs to be > > the same for > > > all parties. For e.g., consider a case where the server has > > a view of > > > the SSIDs for which a given MSK is valid. The peer at a > > given moment > > > may only see a subset of the SSIDs - as it moves though, it > > needs to > > > know that a new SSID it sees may or may not use that MSK > > for TSK derivation. > > > > > > For this reason, actually mixing of the keys with channel > > binding data > > > doesn't quite make sense to me yet. This implies that the > > peer has a > > > complete view of the channel binding data at a given time, > > which does > > > not seem to make practical sense in all models of deployment. > > > > Since I don't think the complete channel binding data is so > > large, I don't see a practical issue here. What is > > deployment scenario in your mind? > > > > I'm not sure that there isn't a practical issue. Depending on the > authenticator location and the number of enforcement points under an > authenticator or how many ports the authenticator has, this could be > fairly large - and I don't think it is valid to say that the peer will > be able to have a complete view at all times. I think not all pieces of information associated with the authenticator have to be part of EAP Channel Binding data. I mean some information such as identifier of each enforcement point can be bound locally betweeen peer and authenticator, using lower layer chanel binding provided by SAP, as long as basic information such as authenticator identity is validated using EAP Channel Binding and the valid authenticator is advertising that locally bound information. On the other hand I think the entire EAP Channel Binding data needs to be available to the peer when keying material is exported by an EAP method. Otherwise, key scope becomes ambiguous at the time of creating the keying material, which could open up some vulnerability in key management. > > > > > > > > It may make sense for the peer have the entire channel binding data > > > from the server - as it moves, it can compare to see if > > what it sees > > > is a subset of that data it received from the server or not. > > > > I don't think only comparing subset of that data with the > > server does not work for Channel Binding verification, as an > > attacker can still fool around the rest of data that is not > > part of the subset. > > > > Not really. The idea here is that the entire channel binding blob from > the server is integrity protected - so, if someone fooled with some of > that data, the integrity check will fail and hence, it becomes > detectable. I am not sure I fully understand your idea. Say Channel Binding data is XYZ. Suppose the peer learns X from the authenticator via lower layer, but it does not yet learn YZ via lower layer. How can the peer determine that the authenticator is valid by only validating X but before validating YZ? > But, the blob may contain, say, a concatenation of lots of > information. The peer would then have to compare what it got from the > authenticator or EP to the data it got from the server to say whether or > not that data was part of what the server sent it or not. Please see my comment above. Not all pieces of information associated with the authenticator have to be part of EAP Channel Binding data. > > > > > Alternately, the > > > peer just needs confirmation from the server that what it > > sees is valid. > > > > This requires channel bindind data to be sent from the peer > > to server, while the server pre-configures the channel > > bindind data. This is redundant information exchange to me. > > > > Not really. If the peer sent the channel binding data as it sees it, the > server only has to say whether or not it is correct. So, a protected > channel binding result indication is all is needed in the return path. What about the forward path? I don't see a need for the peer to send the Channel Binding data to the server if the peer learns the entire Channel Binding data from lower-layer and the server pre-configures the same data. Regards, Yoshihiro Ohba > > Regards, > Vidya > > > Yoshihiro Ohba > > > > > > > > > > > > > > > Vidya > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 12:23 PM > > > > To: Narayanan, Vidya; eap@frascone.com > > > > Subject: RE: [eap] Re: issue 357: Channel Binding Definition > > > > > > > > That makes sense. Do we also need to indicate that the channel > > > > bindings need to be the same for all parties? For example: > > > > > > > > "Channel Binding > > > > > > > > A secure mechanism for ensuring the synchronization and > > correctness > > > > of channel properties (such as endpoint > > > > identifiers) provided to the EAP peer, authenticator and server." > > > > > > > > >Minor clarification: > > > > > > > > > >"Channel Binding > > > > > > > > > >A *secure* mechanism for ensuring the correctness of channel > > > > properties > > > > >(such as endpoint identifiers) provided to the EAP peer, > > > > authenticator > > > > >and server. " > > > > > > > > > >The word secure is to imply that if this data is in fact > > > > sent as a blob > > > > >between the peer and server, it must be integrity protected. > > > > > > > > > >Vidya > > > > > > > > > > > > > > > _________________________________________________________________ > > > 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 krebsba@galaris.com Thu May 04 16:18:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkH8-0004ai-0a for eap-archive@ietf.org; Thu, 04 May 2006 16:18:14 -0400 Received: from [200.196.162.72] (helo=galaris.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbkH5-0004r4-Ng for eap-archive@ietf.org; Thu, 04 May 2006 16:18:13 -0400 Message-ID: <000001c66fb7$c2b72a80$904aa8c0@bfz23> Reply-To: "Pythagoras Krebsbach" From: "Pythagoras Krebsbach" To: eap-archive@ietf.org Subject: Re: crreddit news Date: Thu, 4 May 2006 13:17:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66F7D.16585280" 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.3 (++++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66F7D.16585280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Home O m wne i r, =20 Your c x re v di m t doesn't matter to us !=20 =20 If you O p WN t real e f st k at f e and want I u MME q DIAT y E c q as s h to s i pen j d ANY way you like, or simply wish to L m OW m ER your monthly p y aym s ent h s by a third or more,=20 here are the d h eal k s we have T a ODA q Y: =20 $ 4 g 90 , 000 - 3 , 6 e 5% f u ixe s d - r r at m e $ 3 v 70 , 000 - 3 , 9 x 0% va j ri k ab r le - r q at n e $ 49 a 0 , 000 - 3 , 2 d 0% inte x re j st - only $ 2 z 50 , 000 - 3 , 3 f 5% f c ix r ed - r z at v e $ 20 k 0 , 000 - 3 , 5 t 5% v v ari m abl w e - r f at m e =20 V n isi l t ou v r s t it e e =20 =20 Pythagoras Krebsbach , A p ppr c ov q al Manager ------=_NextPart_000_0001_01C66F7D.16585280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Home O m wne i r,
 
Your c x re v di m t doesn't matter to us !
 
If you O p WN t real e f st k at f e and want
I u MME q DIAT y E c q as s h to s i pen j d ANY=20 way you like,
or simply wish to L m OW m ER your monthly p y aym s ent h s
=20 by a third or more,
here are the d h eal k s we have T a ODA q Y:
 
$ 4 g 90 , 000 - 3 , 6 e 5% f u ixe s d - r r at m e
$ 3 v 70 , 000 - 3 , 9 x 0% va j ri k ab r le - r q at n e
$ 49 a 0 , 000 - 3 , 2 d 0% inte x re j st - only
$ 2 z 50 , 000 - 3 , 3 f 5% f c ix r ed - r z at v e
$ 20 k 0 , 000 - 3 , 5 t 5% v v ari m abl w e - r f at m e
 
V n isi l t ou v r s t it e e
 
Pythagoras Krebsbach , A p ppr c ov q al Manager
------=_NextPart_000_0001_01C66F7D.16585280-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu May 04 19:13:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbn0m-0003Dv-6s for eap-archive@lists.ietf.org; Thu, 04 May 2006 19:13:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbn0k-0003zy-Pf for eap-archive@lists.ietf.org; Thu, 04 May 2006 19:13:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6B71F430156 for ; Thu, 4 May 2006 16:13:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2515B4300B0 for ; Thu, 4 May 2006 16:13:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16DDA39802B for ; Thu, 4 May 2006 16:13:18 -0700 (PDT) Received: from hotmail.com (bay106-f32.bay106.hotmail.com [65.54.161.42]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8033A398011 for ; Thu, 4 May 2006 16:13:15 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 4 May 2006 16:13:15 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 04 May 2006 23:13:10 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060504192956.GC29090@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com Subject: Re: [eap] Re: issue 357: Channel Binding Definition Date: Thu, 04 May 2006 16:13:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 May 2006 23:13:15.0366 (UTC) FILETIME=[52711060:01C66FD0] 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: 798b2e660f1819ae38035ac1d8d5e3ab >I think not all pieces of information associated with the >authenticator have to be part of EAP Channel Binding data. I mean >some information such as identifier of each enforcement point can be >bound locally betweeen peer and authenticator, using lower layer >chanel binding provided by SAP, as long as basic information such as >authenticator identity is validated using EAP Channel Binding and the >valid authenticator is advertising that locally bound information. > >On the other hand I think the entire EAP Channel Binding data needs to >be available to the peer when keying material is exported by an EAP >method. Otherwise, key scope becomes ambiguous at the time of >creating the keying material, which could open up some vulnerability >in key management. Right. Maybe we could make this clearer in the document. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From ppui2@sauvage.com Fri May 05 06:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxTB-0006Co-Be for eap-archive@ietf.org; Fri, 05 May 2006 06:23:33 -0400 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 1FbxTB-0004it-AF for eap-archive@ietf.org; Fri, 05 May 2006 06:23:33 -0400 Received: from bzz21.neoplus.adsl.tpnet.pl ([83.30.71.21] helo=sauvage.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FbxQb-0001cG-5S for eap-archive@ietf.org; Fri, 05 May 2006 06:20:54 -0400 Received: from [192.168.1.0] ([83.30.71.21]) by sauvage.com (Sendmail 8.7.7) with ESMTP (SSL) id IYT35346 for ; Fri, 05 May 2006 12:20:47 +0100 Message-ID: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=Hermosacolt's d=sauvage.com; b=YqXKsuVzwzTJrWovTTLNKZNQdqiAuaPwKczXrxoPenEuxFlGbdWJMhjGuzPeUDDfeimoZYfRQmfOzisS; Date: Fri, 05 May 2006 12:20:47 +0100 From: "qob1s7" To: Subject: Impressive outlook for FRIDAY it isday [DETAILS FRIDAY it is] imposing fits crowing leading Content-return: allowed X-Mailer: encouragedMail 1.38 X-Authentication-Warning: localhost.localdomain: apache set sender to ppui2@sauvage.com using -f MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 GAPJ- GOLDEN APPLE OIL/GAS Current Price: $ 0.45 Short Term Price: $ 1.50 3 Month Price: $ 4.50 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 S T R O N G B U Y R E C O M M E N D A T I O N B U Y 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 terms of the deal provide for Franklin Ross to purchase 181,818 shares of Golden Apple Oil and Gas, Inc. restricted stock priced at 10 per share. 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. GET IN NOW, DO"NT REGRET LATER From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri May 05 09:48:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0fV-0006QV-8k for eap-archive@lists.ietf.org; Fri, 05 May 2006 09:48:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0fS-0004wM-Qr for eap-archive@lists.ietf.org; Fri, 05 May 2006 09:48:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E8690430092 for ; Fri, 5 May 2006 06:48:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1BE74430082 for ; Fri, 5 May 2006 06:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0BD1430F17 for ; Fri, 5 May 2006 06:48:08 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id 9C316430F0F for ; Fri, 5 May 2006 06:48:05 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k45Dm37Z007824; Fri, 5 May 2006 22:48:03 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k45DnFxf024178; Fri, 5 May 2006 22:49:15 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id YAA24150; Fri, 5 May 2006 22:49:14 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k45Dm2dx009149; Fri, 5 May 2006 22:48:02 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k45Dm1Ea029151; Fri, 5 May 2006 22:48:01 +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 <0IYS00BVCOZVFG00@mail.po.toshiba.co.jp>; Fri, 05 May 2006 22:48:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fc0ek-0001QC-FM; Fri, 05 May 2006 06:47:42 -0700 Date: Fri, 05 May 2006 09:47:42 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: To: Bernard Aboba Message-id: <20060505134742.GA4216@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060504192956.GC29090@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, May 04, 2006 at 04:13:10PM -0700, Bernard Aboba wrote: > >I think not all pieces of information associated with the > >authenticator have to be part of EAP Channel Binding data. I mean > >some information such as identifier of each enforcement point can be > >bound locally betweeen peer and authenticator, using lower layer > >chanel binding provided by SAP, as long as basic information such as > >authenticator identity is validated using EAP Channel Binding and the > >valid authenticator is advertising that locally bound information. > > > >On the other hand I think the entire EAP Channel Binding data needs to > >be available to the peer when keying material is exported by an EAP > >method. Otherwise, key scope becomes ambiguous at the time of > >creating the keying material, which could open up some vulnerability > >in key management. > > Right. Maybe we could make this clearer in the document. > I agree. Yoshihiro Ohba _________________________________________________________________ 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 May 05 12:42:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3OH-0006vq-Ro for eap-archive@lists.ietf.org; Fri, 05 May 2006 12:42:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3OG-0003V1-DY for eap-archive@lists.ietf.org; Fri, 05 May 2006 12:42:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DAD1343006D for ; Fri, 5 May 2006 09:42:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3696E43006D for ; Fri, 5 May 2006 09:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C836D398016 for ; Fri, 5 May 2006 09:42:31 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 11598398031 for ; Fri, 5 May 2006 09:42:28 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45GgPo3032279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 09:42:27 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45Gg55E000971; Fri, 5 May 2006 09:42:24 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:42:22 -0700 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: issue 357: Channel Binding Definition Date: Fri, 5 May 2006 09:40:48 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZv0Fzy107ZL6+LQ8aBRBYCILws1QAkaPPw From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 05 May 2006 16:42:22.0463 (UTC) FILETIME=[E1D5D0F0:01C67062] 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 > >I think not all pieces of information associated with the=20 > authenticator=20 > >have to be part of EAP Channel Binding data. I mean some=20 > information=20 > >such as identifier of each enforcement point can be bound locally=20 > >betweeen peer and authenticator, using lower layer chanel binding=20 > >provided by SAP, as long as basic information such as authenticator=20 > >identity is validated using EAP Channel Binding and the valid=20 > >authenticator is advertising that locally bound information. > > I am confused by the above - are you saying that the channel binding data, for instance, may just be the authenticator ID (NAS ID as seen by the server) and that any information on EPs associated with the authenticator may be exchanged via the lower layer? How does the peer trust that information then? At least in 802.11 networks, security of management frames may take care of this, but I don't see this applying to all kinds of technologies.=20 > >On the other hand I think the entire EAP Channel Binding=20 > data needs to=20 > >be available to the peer when keying material is exported by an EAP=20 > >method. Otherwise, key scope becomes ambiguous at the time=20 > of creating=20 > >the keying material, which could open up some vulnerability in key=20 > >management. >=20 > Right. Maybe we could make this clearer in the document. >=20 I somewhat agree with the above - I am not disputing that the server would have to send all channel binding data associated with a given MSK at the time of export of the MSK. If this is a blob sent from the server to the peer in a method, there is no issue. Only when you are assuming the presence of that entire blob at the peer without exchanging that in the method and arriving at a mixed key or something, this becomes a problem, because the peer may not have a complete view.=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 May 05 14:02:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4dE-0007LG-LV for eap-archive@lists.ietf.org; Fri, 05 May 2006 14:02:24 -0400 Received: from g1-43.tigertech.net ([64.62.209.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4dE-0006UZ-5j for eap-archive@lists.ietf.org; Fri, 05 May 2006 14:02:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 76CD1430133 for ; Fri, 5 May 2006 11:02:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E6F06430082 for ; Fri, 5 May 2006 11:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C1A0398042 for ; Fri, 5 May 2006 11:02:01 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4D7C439803A for ; Fri, 5 May 2006 11:01:56 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45I1tbw017619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 11:01:56 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-38.qualcomm.com [10.50.65.38]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45I1jGn003256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 May 2006 11:01:48 -0700 (PDT) Message-Id: <6.2.5.6.2.20060505105337.039418d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 May 2006 11:01:42 -0700 To: "Narayanan, Vidya" , "Bernard Aboba" , From: Lakshminath Dondeti Subject: RE: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm. com> References: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm.com> 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: 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: 6cca30437e2d04f45110f2ff8dc1b1d5 With apologies for interjecting in the middle of a discussion that seems to be concluding, I have some basic questions on Channel binding: What are the types of CB information shared between the peer and the server? How dissimilar might be the CB information? In other words, are there different schools of thought on what might be sent, what might the peer and the server know about the authenticator? How large might be the information? In some EAP methods, it may be necessary to limit the size of the information. So, if the peer has only a subset of the information that the server has, then it might make sense for the peer to send the CB info and the server to verify it. Is all authenticated CB info exchanged between peer and server? Or, does it make sense to do some of it in the method and the rest in L2 etc? Thanks in advance for any clarification. regards, Lakshminath At 09:40 AM 5/5/2006, Narayanan, Vidya wrote: > > > > >I think not all pieces of information associated with the > > authenticator > > >have to be part of EAP Channel Binding data. I mean some > > information > > >such as identifier of each enforcement point can be bound locally > > >betweeen peer and authenticator, using lower layer chanel binding > > >provided by SAP, as long as basic information such as authenticator > > >identity is validated using EAP Channel Binding and the valid > > >authenticator is advertising that locally bound information. > > > > > >I am confused by the above - are you saying that the channel binding >data, for instance, may just be the authenticator ID (NAS ID as seen by >the server) and that any information on EPs associated with the >authenticator may be exchanged via the lower layer? How does the peer >trust that information then? At least in 802.11 networks, security of >management frames may take care of this, but I don't see this applying >to all kinds of technologies. > > > > >On the other hand I think the entire EAP Channel Binding > > data needs to > > >be available to the peer when keying material is exported by an EAP > > >method. Otherwise, key scope becomes ambiguous at the time > > of creating > > >the keying material, which could open up some vulnerability in key > > >management. > > > > Right. Maybe we could make this clearer in the document. > > > >I somewhat agree with the above - I am not disputing that the server >would have to send all channel binding data associated with a given MSK >at the time of export of the MSK. If this is a blob sent from the server >to the peer in a method, there is no issue. Only when you are assuming >the presence of that entire blob at the peer without exchanging that in >the method and arriving at a mixed key or something, this becomes a >problem, because the peer may not have a complete view. > >Vidya >_________________________________________________________________ >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 May 05 19:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcA2B-0003AA-DV for eap-archive@lists.ietf.org; Fri, 05 May 2006 19:48:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcA28-00081s-RY for eap-archive@lists.ietf.org; Fri, 05 May 2006 19:48:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B7F304300FF for ; Fri, 5 May 2006 16:48:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3EF0143006D for ; Fri, 5 May 2006 16:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE0BB1448021 for ; Fri, 5 May 2006 16:48:10 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id 5012B1448011 for ; Fri, 5 May 2006 16:48:06 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k45Nm59G009446; Sat, 6 May 2006 08:48:05 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k45NnH50001790; Sat, 6 May 2006 08:49:17 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id JAA01761; Sat, 6 May 2006 08:49:17 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k45Nm4bx009683; Sat, 6 May 2006 08:48:04 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k45Nm3GD001763; Sat, 6 May 2006 08:48:03 +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 <0IYT00B80GQAFM20@mail.po.toshiba.co.jp>; Sat, 06 May 2006 08:48:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FcA0M-000364-AF; Fri, 05 May 2006 16:46:38 -0700 Date: Fri, 05 May 2006 19:46:38 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <6.2.5.6.2.20060505105337.039418d8@qualcomm.com> To: Lakshminath Dondeti Message-id: <20060505234638.GC4216@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm.com> <6.2.5.6.2.20060505105337.039418d8@qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 5d7a7e767f20255fce80fa0b77fb2433 On Fri, May 05, 2006 at 11:01:42AM -0700, Lakshminath Dondeti wrote: > With apologies for interjecting in the middle of a discussion that > seems to be concluding, I have some basic questions on Channel binding: > > What are the types of CB information shared between the peer and the server? Section 5.11 of eap-keying draft mentions Called-Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address. There can be others, but it depends on each lower layer. > > How dissimilar might be the CB information? In other words, are > there different schools of thought on what might be sent, what might > the peer and the server know about the authenticator? It seems there are different opinions about CB data. Please see my comments below to express my opinion. > > How large might be the information? In some EAP methods, it may be > necessary to limit the size of the information. So, if the peer has > only a subset of the information that the server has, then it might > make sense for the peer to send the CB info and the server to verify it. It should not be Kbytes of data. It should be the same order as the link-layer channel binding data which is mixed to generate link-layer keys from EAP-generated keying material, or the link-layer forms a key hierarchy, then it should the same order as the highest level link-layer channel binding data in the hierarchy. I don't really think whole bunch of link-layer channel binding data of the entire hierarchy needs to be part of EAP CB data. This is because even link-layer hierarchical channel binding does not use level N channel binding data to generate level N-1 key. Why EAP should use level N data for CB? Having said that I can't think of a situation where the peer sees only subnet of EAP CB data advertised by authenticator. Note that this argument should be generally applicable when CB is applied to any key hiearchy including a key hierarchy between authenticator and EAP server, if it is formed. Section 4.3 (Hierarchical Channel Binding) of draft-ohba-eap-channel-binding-00 is described based on this concept. > > Is all authenticated CB info exchanged between peer and server? Or, > does it make sense to do some of it in the method and the rest in L2 etc? There is no need to exchange authenticated CB info between peer and server, this is just redundant. The peer sees the CB data advertised by authenticator and the server pre-configures the same data. The peer and server only mix the data into keying material exported by EAP method and the server transports it to the authenticator. After that, the peer and authenticator lower-layer entities verify the possession of the mixed key using SAP. Regards, Yoshihiro Ohba > > Thanks in advance for any clarification. > > regards, > Lakshminath > > > At 09:40 AM 5/5/2006, Narayanan, Vidya wrote: > > >> > >> >I think not all pieces of information associated with the > >> authenticator > >> >have to be part of EAP Channel Binding data. I mean some > >> information > >> >such as identifier of each enforcement point can be bound locally > >> >betweeen peer and authenticator, using lower layer chanel binding > >> >provided by SAP, as long as basic information such as authenticator > >> >identity is validated using EAP Channel Binding and the valid > >> >authenticator is advertising that locally bound information. > >> > > > > > > >I am confused by the above - are you saying that the channel binding > >data, for instance, may just be the authenticator ID (NAS ID as seen by > >the server) and that any information on EPs associated with the > >authenticator may be exchanged via the lower layer? How does the peer > >trust that information then? At least in 802.11 networks, security of > >management frames may take care of this, but I don't see this applying > >to all kinds of technologies. > > > > > >> >On the other hand I think the entire EAP Channel Binding > >> data needs to > >> >be available to the peer when keying material is exported by an EAP > >> >method. Otherwise, key scope becomes ambiguous at the time > >> of creating > >> >the keying material, which could open up some vulnerability in key > >> >management. > >> > >> Right. Maybe we could make this clearer in the document. > >> > > > >I somewhat agree with the above - I am not disputing that the server > >would have to send all channel binding data associated with a given MSK > >at the time of export of the MSK. If this is a blob sent from the server > >to the peer in a method, there is no issue. Only when you are assuming > >the presence of that entire blob at the peer without exchanging that in > >the method and arriving at a mixed key or something, this becomes a > >problem, because the peer may not have a complete view. > > > >Vidya > >_________________________________________________________________ > >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 May 05 23:08:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcDA7-0000Nc-Px for eap-archive@lists.ietf.org; Fri, 05 May 2006 23:08:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcDA6-00089E-2b for eap-archive@lists.ietf.org; Fri, 05 May 2006 23:08:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2BC10430102 for ; Fri, 5 May 2006 20:08:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E804943009F for ; Fri, 5 May 2006 20:08:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ED7E2398026 for ; Fri, 5 May 2006 20:08:31 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B853398017 for ; Fri, 5 May 2006 20:08:28 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4638Q16007600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 20:08:26 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4638PBO016157; Fri, 5 May 2006 20:08:25 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 20:08:25 -0700 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: issue 361: child key expiry Date: Fri, 5 May 2006 20:08:25 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0BE@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 361: child key expiry Thread-Index: AcZvVdt35CpRXiSpTUGz16C+2dkk8wBZFzuw From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Bernard Aboba" , X-OriginalArrivalTime: 06 May 2006 03:08:25.0446 (UTC) FILETIME=[571E2860:01C670BA] 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: 40161b1d86420e0807d771943d981d25 >=20 > Two things then: >=20 > First we need a clarification on what the EAP keying FW is=20 > going to say about EMSKs. If it says EMSK usage is specified=20 > elsewhere (and deletes the EMSK MUST not be used for key=20 > derivation, for consistency), then you are indeed correct. =20 > The EAP keying FW should stick to MSK and TSK lifetime=20 > discussion, which it does at length, and not talk about EMSK=20 > child keys (intuitively, if it doesn't describe EMSK usage,=20 > then properties of child keys do not belong in the EAP keying=20 > FW document). >=20 The above would be my preference.=20 Regards, Vidya > If the document is to add a few notes on EMSK usage, then=20 > perhaps providing guidelines on child keys, freshness and=20 > other considerations do belong in it. >=20 > Can we agree to that and explore which of the above two might=20 > make sense? >=20 > Finally, apologies for side tracking your issue. I think=20 > there was some confusion along the way and I am partly=20 > responsible for that. >=20 > regards, > Lakshminath >=20 > At 01:29 AM 5/4/2006, Narayanan, Vidya wrote: >=20 > > > > > > Speaking very loosely and at a high level, we say that=20 > MSK is sent=20 > > > to the Authenticator and then TSKs are derived using various=20 > > > protocols and go on to talk about TSK properties. > > > Likewise, we are talking > > > about EMSK "usage" in the EAP keying FW document. > > > >But, the document does not talk about EMSK usage though. > > > > > We say a bunch of > > > things, all of which I am ok with and that the EMSK MUST=20 > NOT be used=20 > > > to derive keys, which I am not ok with. There are proposals to=20 > > > change that, so we might start revising that statement to avoid=20 > > > having two RFCs in conflict with each other. > > > > > > >Good point - we have a discussion from a while back on removing this=20 > >text about not using EMSK to derive other keys, but seems=20 > like we never=20 > >closed the loop on that one. Given that we pretty much have=20 > a consensus=20 > >that EMSK will be used for key derivation, this text doesn't=20 > make sense. > > > > > > > > > Once that is done, talking about derived key properties is ok. > > > > > > >This doesn't make sense to me still. What properties of derived keys=20 > >are we going to talk about here? Just lifetime? Why not other=20 > >properties then? > > > >If at all this document should talk about any lifetimes, it=20 > must be the=20 > >EMSK lifetime itself (assuming caching of EMSK is allowed, on which=20 > >there has been a recent reversal in thinking from the=20 > earlier notion of=20 > >no caching) - this is not addressed in the document and it=20 > would make=20 > >sense to address this. > > > >Regards, > >Vidya > > > > > Iff that is not done, sure I agree with you (if we MUST=20 > NOT derive=20 > > > keys, what's the point in talking about the properties of the=20 > > > derived keys?). But, I contend that that rule needs to=20 > be revised. > > > > > > regards, > > > Lakshminath > > > > > > At 08:05 PM 5/3/2006, Narayanan, Vidya wrote: > > > >Hmmm.. > > > > > > > >I gave this some more thought and am still not convinced=20 > we need to=20 > > > >include this text here. The document talks about TSKs and their=20 > > > >lifetimes, because the TSKs are derived from the MSKs and > > > the MSK usage > > > >is fully covered by this document. However, it makes sense > > > to me that > > > >the EMSK usage document be the one that defines the lifetime > > > guidelines > > > >for the keys derived from the EMSK. > > > > > > > >While we are explicitly excluding any EMSK usage text from this=20 > > > >document, why should this document cover lifetime guidelines > > > for child > > > >keys of EMSK? All the rest of the child key properties > > > aren't covered > > > >here - isn't lifetime a property too? > > > > > > > >Regards, > > > >Vidya > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > > > Sent: Tuesday, May 02, 2006 6:34 PM > > > > > To: Narayanan, Vidya; Bernard Aboba; eap@frascone.com > > > > > Subject: RE: [eap] Re: issue 361: child key expiry > > > > > > > > > > Hi Vidya, > > > > > > > > > > After having thought about this some more, I think we should=20 > > > > > have some text on EMSK to child key derivation in the > > > EAP-keying document > > > > > along the lines of the 4 items listed earlier. This is > > > inline with > > > > > the text on TSKs in 3.1(e) and perhaps elsewhere in=20 > the document. > > > > > > > > > > regards, > > > > > Lakshminath > > > > > > > > > > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote: > > > > > >Bernard, Lakshminath, > > > > > >While this is an interesting discussion, I feel that the > > > > > EMSK specifics > > > > > >with respect to caching and lifetime as well as child key=20 > > > > > >properties need to be discussed in the EMSK usage > > > document. We can > > > > > continue having > > > > > >this discussion in light of the EMSK usage document. > > > > > > > > > > > >For the purpose of EAP keying document, can we not add that=20 > > > > > >sentence about a future EMSK usage document and=20 > leave it at that? > > > > > > > > > > > >However, if there are things that need to be clarified here=20 > > > > > >with respect to the MSK, we should certainly do that=20 > in this document. > > > > > > > > > > > >Thanks, > > > > > >Vidya > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > > > Sent: Tuesday, May 02, 2006 12:19 PM > > > > > > > To: Dondeti, Lakshminath; eap@frascone.com > > > > > > > Subject: Re: [eap] Re: issue 361: child key expiry > > > > > > > > > > > > > > >I wasn't thinking about PANA, but thinking about the use > > > > > > > case of client > > > > > > > >authentication in IPsec remote access using EAP. > > > > > Whereas EAP can > > > > > > > >be used every time, it is plausible that the MSK is > > > > > cached as the > > > > > > > >IKEv2 Preshared key for future authentication to avoid > > > > > EAP latency. > > > > > > > > > > > > > > Perhaps we can say that RFC 4306 does not support key > > > > > caching? It > > > > > > > seems that an extension to IKEv2 would be required to > > > > > support this, > > > > > > > since otherwise the IKE initiator and responder couldn't > > > > > negotiate > > > > > > > whether cached EAP keys are to be used, and if=20 > so, which ones. > > > > > > > > > > > > > > >>Are you suggesting that there might be situations > > > in which EAP > > > > > > > >>keys aren't used for key derivation, but=20 > compromise might=20 > > > > > > > >>still > > > > > > > be possible? > > > > > > > > > > > > > > > >No. I am asking if the MSK/EMSK figures into the key > > > > > > > derivation, say > > > > > > > >only partially (say along with DH), compromise=20 > of MSK/EMSK=20 > > > > > > > >means compromise of derived keys. I was then saying=20 > > > > > > > >perhaps > > > > > that is too > > > > > > > >restrictive, but I'd contend not, unless there=20 > is a strong > > > > > > > case made for the alternative. > > > > > > > > > > > > > > OK. If the MSK/EMSK were mixed into the key derivation, > > > > > then there > > > > > > > might be some weakening of the key derivation. How much > > > > > depends on > > > > > > > the algorithm. > > > > > > > > > > > > > > >If that's confusing too, please let me know. > > > > > > > > > > > > > > I understand the point.... question is how we make it > > > > > clear in the > > > > > > > text. > > > > > > > > > > > > > > >>Right. And by the same logic, the MSK and EMSK > > > might expire > > > > > > > >>at different times. I'm not sure that the key lifetime > > > > > section takes > > > > > > > >>that into account adequately. > > > > > > > > > > > > > > > >That sounds right and the clarification will be good. > > > > > > > > > > > > > > Suggestions welcome. > > > > > > > > > > > > > > >>This makes sense assuming that the entity > > > authentiation keys > > > > > > > >>aren't themselves derived from the EMSK. > > > > > > > > > > > > > > > >Even if entity authentication keys are derived from the > > > > > EMSK, the > > > > > > > >guideline applies, I think. Suppose the EMSK supports > > > > > > > derivation of a > > > > > > > >traffic key and a separate entity authentication key, > > > > > > > wouldn't it make > > > > > > > >sense to say that, all other things being equal, the=20 > > > > > > > >traffic > > > > > > > key will > > > > > > > >have a shorter lifetime than the entity=20 > authentication key, > > > > > > > based on key usage? > > > > > > > > > > > > > > Yes, it would make sense. I guess I'd=20 > distinguish between a > > > > > > > key calculated > > > > > > > from the EMSK (e.g. AMSK) and a TSK. The AMSK=20 > formulas that=20 > > > > > > > have been suggested so far are static -- that is, > > > they are based > > > > > > > on a key-label, but do not generate a fresh key every > > > time they > > > > > > > are invoked on the same EMSK, in the way that some TSK=20 > > > > > > > derivations do (e.g. 802.11i 4-way handshake). > > > > > > > > > > > > > > Unless there is an ability to generate fresh keys > > > without an EAP > > > > > > > re-authentication, then when the derived keyexpires it is > > > > > necessary > > > > > > > to do an EAP re-authentication. With TSKs it may be > > > > > possible to do > > > > > > > a re-key independent of EAP (e.g. 802.11i 4-way=20 > handshake). > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________ > > > > > > > _ To unsubscribe or modify your subscription=20 > options, please > > > > > > > visit: > > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > > > > > > > > > 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 herytaylore@gmail.com Fri May 05 23:39:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcDe3-0006GK-7I for eap-archive@ietf.org; Fri, 05 May 2006 23:39:51 -0400 Received: from hu-out-0102.google.com ([72.14.214.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcDe2-0001cf-Rr for eap-archive@ietf.org; Fri, 05 May 2006 23:39:51 -0400 Received: by hu-out-0102.google.com with SMTP id 28so91579hug for ; Fri, 05 May 2006 20:39:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jji+5cRcgx0zl0ASJk3X58G/j+7S/tihXcyKpKhe+3xq4o3WmtPIxvocTZn55PozHtCSZ+cQ23387ymKGuLas0fKX4hvUqDk0nL1I5HRa27jUCzbXBdtv3E+KMKNXvyX4b2AvOFUbbLyuX4x7wuAAk5VbmkK5PpZAqo2pT2Syx8= Received: by 10.48.164.17 with SMTP id m17mr1007776nfe; Fri, 05 May 2006 20:38:20 -0700 (PDT) Received: by 10.48.143.16 with HTTP; Fri, 5 May 2006 20:38:20 -0700 (PDT) Message-ID: <16b1548f0605052038u2b08bb48sdd07a311872a2ab8@mail.gmail.com> Date: Fri, 5 May 2006 20:38:20 -0700 From: "hery taylore" To: herytaylore@gmail.com Subject: URGENT ASSISTANCE NEEDED FROM YOU MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24963_6091927.1146886700450" X-Spam-Score: 4.7 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ------=_Part_24963_6091927.1146886700450 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ATTN: MY NAME IS MR. HENRY TAYLOR, I AM THE FIRST SON TO THE FORMER LIBERIAN PRESIDENT MR. CHARLES TAYLOR. BEFORE HE LEFT OFFICE HE INSTRUCTED ME, BEIGN HIS FIRST SON TO LOOK FOR A CAPABLE HAND (SOME ONE) WHO WILL INVEST OUR MONEY [$7,000,000,00] SEVEN MILLION USD FOR A PERIOD OF TEN YEARS, THE TRUSTEE OF THE MONEY WILL HAVE 30% OF IT AND THE INTEREST WILL BE SHARED FIFTY/FIFTY(50%EACH).THE CONTRACT CAN BE RENEWED AFTER TEN YEARS TILL THE PROBLEMS OF MY FATHER IS OVER. IF YOU ARE PREPARED TO INVEST THIS MONEY FOR US, CONTACT ME IMMEDIATELY FOR MORE DETAILS. THANKS, MR. HENRY TAYLOR. ------=_Part_24963_6091927.1146886700450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

ATTN:
 
MY NAME IS MR. HENRY TAYLOR, I AM THE FIRST SON TO T= HE FORMER LIBERIAN PRESIDENT MR. CHARLES TAYLOR.

BEFORE HE LEFT OFFICE HE INSTRUCTED ME, BEIGN HIS FIRST SON TO LOOK FOR = A CAPABLE HAND (SOME ONE)

WHO WILL INVEST OUR MONEY [$7,000,000,00] SEVEN MILLION USD FOR A PERIOD= OF TEN YEARS, THE TRUSTEE

OF THE MONEY WILL HAVE 30% OF IT AND THE INTEREST WILL BE SHARED FIFTY/F= IFTY(50%EACH).THE CONTRACT

CAN BE RENEWED AFTER TEN YEARS TILL THE PROBLEMS OF MY FATHER IS OVER. 
IF YOU ARE PREPARED TO INVEST THIS MONEY FOR US, CONTACT ME IM= MEDIATELY FOR MORE DETAILS.
 
THANKS,
MR. HENRY TAYLOR.

------=_Part_24963_6091927.1146886700450-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat May 06 22:38:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcZA3-0001kO-O3 for eap-archive@lists.ietf.org; Sat, 06 May 2006 22:38:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcZA1-0008Vi-9c for eap-archive@lists.ietf.org; Sat, 06 May 2006 22:38:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D6F4430105 for ; Sat, 6 May 2006 19:38:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8383A430054 for ; Sat, 6 May 2006 19:38:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6B4D51448002 for ; Sat, 6 May 2006 19:38:03 -0700 (PDT) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by hermes.tigertech.net (Postfix) with ESMTP id C11891448001 for ; Sat, 6 May 2006 19:38:00 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 May 2006 19:38:00 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 07 May 2006 02:37:56 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 06 May 2006 19:37:56 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 May 2006 02:38:00.0581 (UTC) FILETIME=[41D39B50:01C6717F] 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: * Subject: [eap] Issue 368: Threat Model Assumptions 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: 9ed51c9d1356100bce94f1ae4ec616a9 Issue 368: Threat Model Assumptions Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: May 4, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04231.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 5 Rationale/Explanation of issue: The assumptions about the attacker are not discussed as part of the threat model. Recommendation is to change the first three paragraphs of Section 5 to the following: " The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims") are described in [RFC3748] Section 7.2.1. EAP method requirements for applications such as Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579] Sections 4.2 and 4.3. However, in addition to threats against EAP and AAA, there are other system level threats. In developing the threat model, it is assumed that: All traffic is visible to the attacker. The attacker can alter, forge or replay messages. The attacker can reroute messages to another principal. The attacker may be a principal or an outsider. The attacker can compromise any key that is sufficiently old. Threats arising from these assumptions include:" _________________________________________________________________ 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 May 06 22:42:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcZE8-0002uN-T9 for eap-archive@lists.ietf.org; Sat, 06 May 2006 22:42:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcZE6-0000ER-8I for eap-archive@lists.ietf.org; Sat, 06 May 2006 22:42:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DCE034300AE for ; Sat, 6 May 2006 19:42:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6486B430054 for ; Sat, 6 May 2006 19:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C5DC39801A for ; Sat, 6 May 2006 19:42:13 -0700 (PDT) Received: from hotmail.com (bay106-f14.bay106.hotmail.com [65.54.161.24]) by zoidberg.tigertech.net (Postfix) with ESMTP id 72157398021 for ; Sat, 6 May 2006 19:42:11 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 May 2006 19:42:10 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 07 May 2006 02:42:07 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 06 May 2006 19:42:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 May 2006 02:42:10.0959 (UTC) FILETIME=[D71041F0:01C6717F] 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: issue 367: Key Scope and EAP Server Authorization 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: 963faf56c3a5b6715f0b71b66181e01a I think I see the point, which is that a given authenticator may be connected to more than one EAP server, and that all authenticators in a single administrative domain may not share the same EAP server. Also, EAP servers cannot necessarily be assumed to share key state among each other. If the selcted EAP method does not provide the Server-ID, then the peer cannot know the scope of the keys it derives with the EAP server. This can create a number of issues, such as a peer attempting (but failing) a fast reconnect because the server that the authenticator is configured to communicate with is not the same one with which the peer established the previous session. However, there are other situations in which the server identity is not material, such as handoff in an 11r Mobility Domain (MD), where the STA only care whether a candidate AP is in the same MD, not whether the new authenticator is configured to talk to the same backend authentication server as the current or initial AP. In practice, the peer determines whether an authenticator is within the scope of authorization of the backend authentication server by attempting to complete the SAP exchange with it. If the exchange succeeds, the authenticator is authorized; if not, it isn't. It is possible for the peer to attempt a fast reconnect exchange with the wrong server; unless the server were to include its identity in the EAP-Request there is no way for the peer to determine what server it is talking to before the EAP method conversation gets underway. Even if the authenticator were to advertise the server(s) that it is configured to talk to, and even if those servers were identified by their Server-IDs, it would not be possible for the peer to know a-priori which server it was going to talk to, since the primary server can change due to changes in network or server availability. Given this, I'm not sure how the peer can verify that an authenticator is allowed to be authorized by an EAP server. The proposed resolution is as follows: Change Section 2.2 to the following: "2.2 Peer, Authenticator and Server Architecture This specification does not impose constraints on the architecture of the EAP authenticator, peer or server. Any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures. 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. 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, peers or servers; [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". An authenticator may be configured to communicate with more than one backend authentication server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3. +-+-+-+-+ | EAP | | Peer | +-+-+-+-+ | | | Peer Ports / | \\ / | \\ / | \\ / | \\ / | \\ / | \\ / | \\                / | \\ | | | | | | | | | Authenticator Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth1 | | Auth2 | | Auth3 |              | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \\ | \ | \\ | \ | \\ | \ | EAP over AAA \\ | \ | (optional) \\ | \ | \\ | \ | \\ | \ | \\ | \ | +-+-+-+-+-+ +-+-+-+-+-+ Backend | EAP | | EAP | Authentication | Server1 | | Server2 | Servers +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Relationship between EAP peer, authenticator and server" Add a new section 2.2.1 entitled "Server Identification": "2.2.1 Server Identification The EAP method conversation is between the EAP peer and server, as identified by the Peer-Id and Server-Id. As shown in Figure 3, an authenticator may be configured to communicate with multiple EAP servers; the server that a peer communicates with may vary according to network and server availability. For example, in Figure 3, Authenticator2 may be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 may become the primary server. As a result, prior to initiation of the EAP conversation, the peer may not be able to predict which EAP server it will be communicating with. Fast reconnect, defined in [RFC3748] Section 7.2, may fail if the EAP server that the peer communicates with is not the same one with which it initially established a security association. The peer may not be able to determine the Server-Id prior to the start of the EAP method conversation, since the Server-Id is not included in the EAP-Request/Identity, and may not be advertised by the authenticator during the discovery phase." --------------------------------------------------------------------------------- Issue 367: Key Scope and EAP Server Authorization Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: May 3, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04231.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.2.1 and 3.2 Rationale/Explanation of issue: Section 1.4.1 correctly defines the scope of the EAP keying material as being defined by the EAP Peer and EAP server, however this relationship is not carried out in other key scope discussions as far as I can tell. In order for channel binding, key mixing etc. to work the peer must make sure that the key is used not just within the authorized parameters of the lower layer, but of the authorized scope of the EAP server as well. I'm not sure of all of all the places where this needs to be addressed, but I think it needs to be addressed in section 2.2.1 perhaps by adding "[g] Verifying that the advertised scope is within the scope that the EAP server is allowed to authorize" Section 3.2 should probably state somewhere that: "The peer should verify that the key scope advertised by the authenticator is within the scope that is allowed to be authorized by the EAP Server." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From flyhigh_infolook@yahoo.com Sun May 07 00:38:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcb2m-0000N8-C4 for EAP-ARCHIVE@LISTS.IETF.ORG; Sun, 07 May 2006 00:38:56 -0400 Received: from [221.209.173.236] (helo=ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcb2l-0005Eh-8P for EAP-ARCHIVE@LISTS.IETF.ORG; Sun, 07 May 2006 00:38:56 -0400 Subject: =?iso-2022-jp?B?GyRCMEI/NCEmTkk8QSEmN2MwQiROTiIbKEJEVkQgGyRCSE5HZBsoQg==?= From: =?gb2312?B?MjAwMy0wNC0yOSAwMjowNzo1NQ==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C671D1.E1879320" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.6 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C671D1.E1879320 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B5.J}$N$*C5$7$N%?%$%H%k!u$*9%$_$N:nIJ$-$C$H$_$D$+$j$^$9!*(B $BJ*@($$(BDVD$B$,K~:\$NL5=$@5%"%@%k%H1GA|HNGd@lLgE9$G$9!#(B $B?M5$=wM%!V5Z@nF`1{!W!VJ?0f$^$j$"!W!VF#0f:L!W:yED$5$/$i!W(B $B1g8r!&%m%j!<%?!&%"%a%j%+%s%]%k%N!&Ep;#!&%"%K%a$J$I$J$IB>$K$b?7:n$,Bt;3!*(B $B%^%K%"$rS9$i$9D67c0BE9!"?7:nF~2YE9$N$b$N$HHf$Y$F$_$F$/$@$5$$!*!*<+?.$,$"$j$^$9!*(B 11$B;~$^$G$K$4CmJ8$7$F$$$?$@$/$HB(F|G[AwCW$7$^$9!#(B <<$B0B?4$N$*CMCJ$G$9(B>> $B2A3J!!#1Kg!!#1#0#0#01_!!!!!J#5Kg$*Gc$$>e$2Kh$K#1Kg%5!<%S%9!K(B $BAwNA!!A49q0lN'#1#0#0#01_!!!J
=1B$B5.J}$N$*C5$7$N%?%$%H%k!u$*9%$_$N:nIJ$-$C$H$_$D$+$j$^$9!*=1B= (B
=1B$BJ*@($$=1B(BDVD=1B$B$,K~:\$NL5=3D$@5%"%@%k%H1GA|HNGd@lLgE9$G= $9!#=1B(B
=1B$B?M5$=3DwM%!V5Z@nF`1{!W!VJ?0f$^$j$"!W!VF#0f:L!W:yED$5$/$i!W=1B= (B
=1B$B1g8r!&%m%j!<%?!&%"%a%j%+%s%]%k%N!&Ep;#!&%"%K%a$J$I$J$IB>$K$= b?7:n$,Bt;3!*=1B(B
=1B$B%^%K%"$rS9$i$9D67c0BE9!"?7:nF~2Y
=1B$B6H3&:GB.$N$*FO$1$G!"2h
=1B$BB>E9$N$b$N$HHf$Y$F$_$F$/$@$5$$!*!*<+?.$,$"$j$^$9!*=1B(B
11=1B$B;~$^$G$K$4CmJ8$7$F$$$?$@$/$HB(F|G[AwCW$7$^$9!#=1B(B
 
<<=1B$B0B?4$N$*CMCJ$G$9=1B(B>>
=1B$B2A3J!!#1Kg!!#1#0#0#01_!!!!!J#5Kg$*Gc$$>e$2Kh$K#1Kg%5!<%S%9!K=1B= (B
=1B$BAwNA!!A49q0lN'#1#0#0#01_!!!J
 
=1B$B"-$<$R0lEY!"GA$$$F$_$F2<$5$$"-=1B(B
------=_NextPart_000_000B_01C671D1.E1879320-- From limme@netservices.nl Sun May 07 08:30:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FciP3-00053P-TK for eap-archive@ietf.org; Sun, 07 May 2006 08:30:25 -0400 Received: from a213-22-48-70.cpe.netcabo.pt ([213.22.48.70] helo=netservices.nl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FciP2-0007Le-9w for eap-archive@ietf.org; Sun, 07 May 2006 08:30:25 -0400 Message-ID: <000001c671d1$e9440350$c3c7a8c0@mct30> Reply-To: "Dino Limmer" From: "Dino Limmer" To: eap-archive@ietf.org Subject: Re: your VtAGRhA Date: Sun, 7 May 2006 05:29:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67197.3CE77540" 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: 3.0 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67197.3CE77540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 C A V V P X L I m I A r a e A b A L o n v L i G I z a i I e R U a x t S n A M c ra =20 =20 =20 =20 http://www.potaslougrvap.com =20 =20 =20 =20 =20 The master of the house was an elf-friend-one of those people whose=20 fathers came into the strange stories before the beginning of History,=20 the wars of the evil goblins and the elves and the first men in the=20 North. In those days of our tale there were still some people who had=20 both elves and heroes of the North for ancestors, and Elrond the master=20 of the house was their chief. He was as noble and as fair in face as an=20 ------=_NextPart_000_0001_01C67197.3CE77540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
C
A
= V
V
P
= X
L
I
m
= I
A
r
= a
e
A
b
= A
L
o
= n
v
L
i
= G
I
z
= a
i
I
e
= R
U
a
= x
t
S
n
= A
M
c
=
ra
 

 
=  


 
http://www.potaslougrvap.com
 
 
 
 
 
The master of the house was an elf-friend-one of those people = whose
fathers came into the strange stories before the beginning of = History,
the wars of the evil goblins and the elves and the first = men in the
North. In those days of our tale there were still some = people who had
both elves and heroes of the North for ancestors, and = Elrond the master
of the house was their chief. He was as noble and = as fair in face as an
------=_NextPart_000_0001_01C67197.3CE77540-- From do37qbnf@construction.com Sun May 07 11:38:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FclKs-0000X0-No for eap-archive@ietf.org; Sun, 07 May 2006 11:38:18 -0400 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 1FckP6-0004aD-Hr for eap-archive@ietf.org; Sun, 07 May 2006 10:38:36 -0400 Received: from dsr53.neoplus.adsl.tpnet.pl ([83.24.229.53] helo=construction.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FckIS-0000Iz-Nt for eap-archive@ietf.org; Sun, 07 May 2006 10:31:49 -0400 Received: from [192.168.1.4] ([83.24.229.53]) by construction.com (Sendmail 8.7.5) with ESMTP (SSL) id IYT34975 for Message-ID: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=concludeincredulity d=construction.com; b=lhGlvWXKYVuLcYJEFLLoQZHlTmGtujDcUUGNROTLOtcpBnyfhejegCMFPTqmVeGhMFBMVkLSqFUbVXcT; Date: Sun, 07 May 2006 16:31:32 +0100 From: "gsylvt2" To: Subject: In motion for WEEK STARTING MONDAY it isday [SUBSCRIPTION ALERT] durability apprentice Formica enshroud Content-return: allowed X-Mailer: executeMail 6.731 X-Authentication-Warning: localhost.localdomain: apache set sender to do37qbnf@construction.com using -f MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 4.9 (++++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

GAPJ- GOLDEN APPLE OIL/GAS

This weeks Pick, Company already has solid potential

Current Price: $ 0.50
5 Day Projected : $ 1.50

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 terms of the deal provide for Franklin Ross to purchase 181,818 shares of Golden Apple Oil and Gas, Inc. restricted stock priced at .10 per share.

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.

This looks very lucrative in coming weeks,

Get GAPJ First Thing Monday

inconvertible Pollux discriminates Chaplin Paul baring colt's incomputable Melinda gathers legality baneberry kiloton earmarks diverting contrivances execute kiloton attained microsecond's capitalizations Gorham frugally easygoing immediately hoariness blat

From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun May 07 14:36:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fco6x-00085O-9N for eap-archive@lists.ietf.org; Sun, 07 May 2006 14:36:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fco6v-0001s5-Rw for eap-archive@lists.ietf.org; Sun, 07 May 2006 14:36:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A11ED4300AD for ; Sun, 7 May 2006 11:35:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 41BB5430054 for ; Sun, 7 May 2006 11:35:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2C74C398027 for ; Sun, 7 May 2006 11:35:40 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8629839801C for ; Sun, 7 May 2006 11:35:37 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 07 May 2006 11:35:37 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k47IZaRT007078; Sun, 7 May 2006 11:35:37 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Sun, 7 May 2006 11:43:08 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63BC2@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZuP+Q1YWMWxChGTgGiUOhpmbBWRADxOPfw From: "Salowey, Joe" To: "Yoshihiro Ohba" 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: 00e94c813bef7832af255170dca19e36 =20 > > [Joe] I don't see how this text is obsolete. Channel binding is not > > just an EAP-keying concept.=20 >=20 > I'd say the Channel Binding problem description in RFC3748 is valid, > but the solution described in RFC 3748 would be a bit obsolete. >=20 [Joe] Obsoleted by what? > >=20 > > >=20 > > > " > > > Using such a protected exchange, it is possible to match=20 > the channel > > > properties provided by the authenticator via out-of-band=20 > mechanisms > > > against those exchanged within the EAP method. For=20 > example, see the > > > discussion in Section 1.4 as well as=20 > [I-D.arkko-eap-service-identity- > > > auth]. > > > " > > >=20 > > > According to the the AAA server's requirement on pre-configurating > > > Channel Binding parameters, I don't see the usefulness of > > > [I-D.arkko-eap-service-identity-auth]. Do we really need this > > > paragraph? > > >=20 > > [Joe] It still seems useful to me.=20 >=20 > Can you elaborate on how it is useful? >=20 [Joe] It allows the back end to validate parameters advertised by the authenticator.=20 > Regards, > Yoshihiro Ohba >=20 >=20 > >=20 > >=20 > > >=20 > > > " > > > The main difference between these approaches is that=20 > Channel Binding > > > support within an EAP method may require upgrading or changing the > > > EAP method, impacting both the peer and the server. =20 > Where Channel > > > Bindings are implemented in AAA, the peer, authenticator and the > > > backend server need to be upgraded, but the EAP method need not be > > > modified. > > > " > > >=20 > > > If we have only one Channel Binding method, we don't need this > > > comparison. > >=20 > > [Joe] I don't think this is the place to define one method. > >=20 > >=20 > > > Best regards, > > > Yoshihiro Ohba > > > _________________________________________________________________ > > > 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 _________________________________________________________________ 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 May 07 14:37:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fco8B-0008IY-2h for eap-archive@lists.ietf.org; Sun, 07 May 2006 14:37:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fco8A-0001yb-Ik for eap-archive@lists.ietf.org; Sun, 07 May 2006 14:37:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3F4B24300AE for ; Sun, 7 May 2006 11:37:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AB6D5430054 for ; Sun, 7 May 2006 11:37:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B2971448015 for ; Sun, 7 May 2006 11:37:07 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id BE5B7144800B for ; Sun, 7 May 2006 11:37:04 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 07 May 2006 11:37:04 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k47Ib4RT007429; Sun, 7 May 2006 11:37:04 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Sun, 7 May 2006 11:44:35 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63BC3@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZuQGcbM0PcupnWTjKEaQNVJb2ZnwDxLbqg From: "Salowey, Joe" To: "Yoshihiro Ohba" 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.4 tagged_above=-999.0 required=7.0 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: 36c793b20164cfe75332aa66ddb21196 =20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Tuesday, May 02, 2006 4:23 PM > To: Salowey, Joe > Cc: Bernard Aboba; yohba@tari.toshiba.com; eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > On Tue, May 02, 2006 at 04:23:22PM -0700, Salowey, Joe wrote: > > Hmmm...=20 > >=20 > > Peer gets MSK from EAP and mixes it with Y to get MSKY=20 > > Authenticator gets mixed MSKY in exisitng AAA attribute,=20 > since this is > > an exisitng attribute it thinks it is just the MSK and=20 > mixes it with Y > > to get MSKYY. MSKY and MSKYY don't match. >=20 > There is some misunderstanding. If the authenticator is supposed to > further mix Y to get MSKYY from MSKY, then the peer is also supposed > to further mix Y to get MSKYY from MSKY. >=20 [Joe] Yes, but how does the authenticator know if the mixing has been done by the AAA or if it has to do the mixing.=20 > Yoshihiro Ohba >=20 >=20 >=20 > >=20 > > It seems to me a separate attribute would really be better.=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > > > Sent: Tuesday, May 02, 2006 3:58 PM > > > To: yohba@tari.toshiba.com; Salowey, Joe > > > Cc: eap@frascone.com > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > >=20 > > > Right. The method just outputs the MSK/EMSK. As long as the=20 > > > same MSK is=20 > > > outputted on both the EAP peer and server, the authenticator=20 > > > doesn't need to=20 > > > know what channel bindings were mixed in. > > >=20 > > >=20 > > > >From: Yoshihiro Ohba > > > >To: "Salowey, Joe" > > > >CC: Bernard Aboba ,=20 > > > yohba@tari.toshiba.com, =20 > > > > eap@frascone.com > > > >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > >Date: Tue, 02 May 2006 18:55:29 -0400 > > > > > > > >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > > > > > I'm not sure that carrying "mixed" MSKs in existing=20 > > > attributes is such a > > > > > good idea, how does the authenticator know what it=20 > is getting? > > > > > > > >I don't think the authenticator needs to know whether the=20 > > > received key > > > >is the MSK or mixed MSK, as long as both the peer and=20 > authenticator > > > >obtains the same key. > > > > > > > >Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > > Sent: Tuesday, May 02, 2006 12:27 PM > > > > > > To: yohba@tari.toshiba.com > > > > > > Cc: eap@frascone.com > > > > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > > > > > > > >Thank you for reading the document. And the=20 > answer is, if the > > > > > > >generated "mixed" MSKs are carried in the existing AAA=20 > > > attributes > > > > > > >instead of carrying the MSKs, then no AAA attributes=20 > > > or communication > > > > > > >flow is required for EAP keying. > > > > > > > > > > > > It might be worth saying a few words about this in the > > > > > > paragraph. Overall, > > > > > > I'm not sure whether the Channel Binding text in=20 > the document > > > > > > is all that > > > > > > consistent/comprehesive. > > > > > > > > > > > > > > > > > >=20 > > > _________________________________________________________________ > > > > > > To unsubscribe or modify your subscription options,=20 > > > please visit: > > > > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > > > > > > > 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 fixcomputer@21cn.com Mon May 08 05:27:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd21u-0003XD-3k for eap-archive@ietf.org; Mon, 08 May 2006 05:27:50 -0400 Received: from [59.40.167.147] (helo=21cn.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd21s-0000pr-8N for eap-archive@ietf.org; Mon, 08 May 2006 05:27:50 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: Re: To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 8 May 2006 17:27:29 +0800 X-Priority: 2 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 3.8 (+++) X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ

       Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµç ÄÔ
      ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)µçÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(Win98(ME)¡¢WinXP¡¢Win2000)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷Ⱥ·¢EmailÈí ¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí¡¢ÍøÂç´«Õæ(ÎÞÖ½°ì¹«)
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öADSL¡¢ÌìÍþ¡¢Íøͨһ¸öÕʺŶà»úͬʱÉÏÍø
       (10)רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø °É¹¤³Ì

       * ×¨Òµ×齨ÓÐÅÌ Íø°É¹¤³Ì£º
            1¡¢µçÄÔ×é×°  2¡¢°²×°²Ù×÷ϵͳ  3¡¢°²×°¸÷ÖÖ×îÐÂÍøÂç¡¢±¾µØÓÎÏ·
            4¡¢×îо«²ÊµçÓ°´óƬ¡¢MP3ÒôÀÖ   5¡¢ÍòÏó¡¢ÃÀƼÖÇÄÜ»¯ÊÕ·Ñϵͳ
            6¡¢°²×°ÖÇÄÜ»¯»¹Ô­¾«Áé   7¡¢ÍøÂç²¼Ïß¡¢ÍøÂç×ÊÔ´¹²Ïí

       ** µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì  **
         * ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼ °üÔ *
       ** ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú  **

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076»ò 0755-88363633
       QQ£º282079259   2441630
       E-mail:wo16288@21cn.com              


From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon May 08 08:12:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4bJ-00048t-PX for eap-archive@lists.ietf.org; Mon, 08 May 2006 08:12:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd4bH-0004Jx-99 for eap-archive@lists.ietf.org; Mon, 08 May 2006 08:12:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 19CE7430109 for ; Mon, 8 May 2006 05:12:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 828E6430064 for ; Mon, 8 May 2006 05:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 678E6398013 for ; Mon, 8 May 2006 05:11:57 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 584AE398011 for ; Mon, 8 May 2006 05:11:54 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k48CBkpa024067; Mon, 8 May 2006 21:11:46 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k48CCwGM024476; Mon, 8 May 2006 21:12:58 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id XAA24473; Mon, 8 May 2006 21:12:57 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k48CBiOR014036; Mon, 8 May 2006 21:11:44 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48CBiFp010799; Mon, 8 May 2006 21:11:44 +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 <0IYY006SO4JEQI20@mail.po.toshiba.co.jp>; Mon, 08 May 2006 21:11:44 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fd4aJ-0005eJ-Bc; Mon, 08 May 2006 05:11:31 -0700 Date: Mon, 08 May 2006 08:11:31 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F63BC3@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060508121131.GA21584@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F63BC3@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: ff03b0075c3fc728d7d60a15b4ee1ad2 As the authenticator has to do its own mixing, it does not need to know if the additional mixing has been done by the AAA or not. Yoshihiro Ohba On Sun, May 07, 2006 at 11:44:35AM -0700, Salowey, Joe wrote: > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Tuesday, May 02, 2006 4:23 PM > > To: Salowey, Joe > > Cc: Bernard Aboba; yohba@tari.toshiba.com; eap@frascone.com > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > On Tue, May 02, 2006 at 04:23:22PM -0700, Salowey, Joe wrote: > > > Hmmm... > > > > > > Peer gets MSK from EAP and mixes it with Y to get MSKY > > > Authenticator gets mixed MSKY in exisitng AAA attribute, > > since this is > > > an exisitng attribute it thinks it is just the MSK and > > mixes it with Y > > > to get MSKYY. MSKY and MSKYY don't match. > > > > There is some misunderstanding. If the authenticator is supposed to > > further mix Y to get MSKYY from MSKY, then the peer is also supposed > > to further mix Y to get MSKYY from MSKY. > > > [Joe] Yes, but how does the authenticator know if the mixing has been > done by the AAA or if it has to do the mixing. > > > > Yoshihiro Ohba > > > > > > > > > > > > It seems to me a separate attribute would really be better. > > > > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 02, 2006 3:58 PM > > > > To: yohba@tari.toshiba.com; Salowey, Joe > > > > Cc: eap@frascone.com > > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > > > Right. The method just outputs the MSK/EMSK. As long as the > > > > same MSK is > > > > outputted on both the EAP peer and server, the authenticator > > > > doesn't need to > > > > know what channel bindings were mixed in. > > > > > > > > > > > > >From: Yoshihiro Ohba > > > > >To: "Salowey, Joe" > > > > >CC: Bernard Aboba , > > > > yohba@tari.toshiba.com, > > > > > eap@frascone.com > > > > >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > >Date: Tue, 02 May 2006 18:55:29 -0400 > > > > > > > > > >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote: > > > > > > I'm not sure that carrying "mixed" MSKs in existing > > > > attributes is such a > > > > > > good idea, how does the authenticator know what it > > is getting? > > > > > > > > > >I don't think the authenticator needs to know whether the > > > > received key > > > > >is the MSK or mixed MSK, as long as both the peer and > > authenticator > > > > >obtains the same key. > > > > > > > > > >Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > > > Sent: Tuesday, May 02, 2006 12:27 PM > > > > > > > To: yohba@tari.toshiba.com > > > > > > > Cc: eap@frascone.com > > > > > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > > > > > > > > > > > >Thank you for reading the document. And the > > answer is, if the > > > > > > > >generated "mixed" MSKs are carried in the existing AAA > > > > attributes > > > > > > > >instead of carrying the MSKs, then no AAA attributes > > > > or communication > > > > > > > >flow is required for EAP keying. > > > > > > > > > > > > > > It might be worth saying a few words about this in the > > > > > > > paragraph. Overall, > > > > > > > I'm not sure whether the Channel Binding text in > > the document > > > > > > > is all that > > > > > > > consistent/comprehesive. > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > 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 May 08 08:39:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd51r-0003k4-Rd for eap-archive@lists.ietf.org; Mon, 08 May 2006 08:39:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd51q-0006Al-Br for eap-archive@lists.ietf.org; Mon, 08 May 2006 08:39:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F222843007C for ; Mon, 8 May 2006 05:39:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D7D7B430064 for ; Mon, 8 May 2006 05:39:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A8882430FAE for ; Mon, 8 May 2006 05:39:40 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id CBF51430FA9 for ; Mon, 8 May 2006 05:39:37 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k48CdYoA009543; Mon, 8 May 2006 21:39:34 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k48CejeR006660; Mon, 8 May 2006 21:40:45 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id XAA06652; Mon, 8 May 2006 21:40:44 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k48CdV90027919; Mon, 8 May 2006 21:39:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48CdVpi023565; Mon, 8 May 2006 21:39:31 +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 <0IYY006O05TQQJ30@mail.po.toshiba.co.jp>; Mon, 08 May 2006 21:39:31 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fd51F-0005j9-9W; Mon, 08 May 2006 05:39:21 -0700 Date: Mon, 08 May 2006 08:39:21 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F63BC2@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060508123921.GB21584@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F63BC2@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 32b73d73e8047ed17386f9799119ce43 On Sun, May 07, 2006 at 11:43:08AM -0700, Salowey, Joe wrote: > > > > > [Joe] I don't see how this text is obsolete. Channel binding is not > > > just an EAP-keying concept. > > > > I'd say the Channel Binding problem description in RFC3748 is valid, > > but the solution described in RFC 3748 would be a bit obsolete. > > > [Joe] Obsoleted by what? I'd say by CB with key mixing. > > > > > > > > > > > > " > > > > Using such a protected exchange, it is possible to match > > the channel > > > > properties provided by the authenticator via out-of-band > > mechanisms > > > > against those exchanged within the EAP method. For > > example, see the > > > > discussion in Section 1.4 as well as > > [I-D.arkko-eap-service-identity- > > > > auth]. > > > > " > > > > > > > > According to the the AAA server's requirement on pre-configurating > > > > Channel Binding parameters, I don't see the usefulness of > > > > [I-D.arkko-eap-service-identity-auth]. Do we really need this > > > > paragraph? > > > > > > > [Joe] It still seems useful to me. > > > > Can you elaborate on how it is useful? > > > [Joe] It allows the back end to validate parameters advertised by the > authenticator. I have a doubt about the usefulness of doing this for Channel Binding as it requires the additional over-the-air step of exchanging CB data between the peer and the server. In key mixing approach, this step is not needed. Yoshihiro Ohba > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > " > > > > The main difference between these approaches is that > > Channel Binding > > > > support within an EAP method may require upgrading or changing the > > > > EAP method, impacting both the peer and the server. > > Where Channel > > > > Bindings are implemented in AAA, the peer, authenticator and the > > > > backend server need to be upgraded, but the EAP method need not be > > > > modified. > > > > " > > > > > > > > If we have only one Channel Binding method, we don't need this > > > > comparison. > > > > > > [Joe] I don't think this is the place to define one method. > > > > > > > > > > Best regards, > > > > Yoshihiro Ohba > > > > _________________________________________________________________ > > > > 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 bppokceg@bleeker.com Mon May 08 08:41:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd53S-0003oU-BW for eap-archive@ietf.org; Mon, 08 May 2006 08:41:38 -0400 Received: from 217-148-242-4.happymany.net ([217.148.242.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fd53Q-0006EH-LY; Mon, 08 May 2006 08:41:38 -0400 Received: from unknown (HELO eft.www4.qav0.com) (192.168.0.5) by host60-56.www4.qav0.com with SMTP; Mon, 08 May 2006 14:41:30 +0100 Message-ID: <476t286v.6014791@www4.qav0.com> Date: Mon, 08 May 2006 14:41:30 +0100 From: "Yong Richey" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-PGP-Key: aBMk59gSBCb8dGgCYZ5culUddxPm9i0HxjzLRpIMhJlnE5GDlejAIHiLmHpQxFr8== X-Firewall-Bypass: NO MIME-Version: 1.0 X-Scanned-by: Norton 0 To: eap-archive@ietf.org, edmund.rivera@ietf.org Subject: Extending Purchases at low rates X-Spam-Score: 4.7 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a q 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.qav0.com/was.asp Thank you, Connie Aguilar, Accounting nDatabase Deletion: http://www4.qav0.com/rem.asp From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon May 08 10:13:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6Tx-0000eS-BB for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:13:05 -0400 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 1Fd6Tx-0002oJ-9A for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:13:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd6Tm-0007Na-Qn for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:12:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 112BD4300EA for ; Mon, 8 May 2006 07:12:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1465F430077 for ; Mon, 8 May 2006 07:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F1C7043111E for ; Mon, 8 May 2006 07:12:35 -0700 (PDT) Received: from hotmail.com (bay106-f3.bay106.hotmail.com [65.54.161.13]) by hermes.tigertech.net (Postfix) with ESMTP id 4540F43110C for ; Mon, 8 May 2006 07:12:33 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 07:12:32 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 14:12:30 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 08 May 2006 07:12:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 14:12:32.0851 (UTC) FILETIME=[72D92230:01C672A9] 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: * Subject: [eap] Re: Issue 366 Section 2.2.2 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.2 (-) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Sharing a logical cache between virtual authenticators creates the potential for elevation of privilege or unauthorized access. By authenticating to one virtual authenticator, the peer can gain access to any virtual authenticator that it shares a key cache with. I don't think that Section 2.2.2 says this very clearly, though. With respect to offering different services on different authenticators,this is discussed in Section 4, but I am not sure it is a "virtual authenticator" issue. I think that there are two issues that have been intermingled in [i]. One is the need for virtual authenticators to advertise their identities consistently between AAA and the lower layer, or else channel bindings could fail. Another issue is the need for virtual authenticators to identify them distinctly, so that peers can tell them apart. For example, in 802.11r it would not be a good idea for all the virtual authenticators to use the same R0KH-ID, since then the peers might not be able to tell them apart. However, if they used different R0KH-IDs, but the same NAS-Identifier attribute, now channel bindings will fail. Suggested resolution is as follows: Change " When a single physical authenticator advertises itself as multiple "virtual authenticators", a number of security vulnerabilities may arise. For example, the peer may assume that the "virtual authenticators" are distinct and do not share a key cache, whereas, depending on the architecture of the physical authenticator, a shared key cache may or may not be implemented. Where EAP keying material is shared between "virtual authenticators" an attacker acting as a peer could authenticate with the "Guest" "virtual authenticator" and derive EAP keying material. If the virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" virtual authenticator. In order to address these issues:" To: " When a single physical authenticator advertises itself as multiple "virtual authenticators", if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache. For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" "virtual authenticator" and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network. In order to address this vulnerability:" replace: "[i] It is RECOMMENDED that each "virtual authenticator" identify itself distinctly to the backend authentication server, such as by utilizing a distinct NAS-Identifier attribute. This enables the backend authentication server to utilize a separate credential to authenticate each "virtual authenticator", and for the peer and backend authentication server to verify the authenticator identity via Channel Bindings (see Section 5.11)." with ""[i] It is RECOMMENDED that each "virtual authenticator" identify itself consistently to the peer and to the backend authentication server, so as to enable the peer to verify the authenticator identity via Channel Bindings (see Section 5.11). [j] It is RECOMMENDED that each "virtual authenticator" identify itself distinctly, in order to enable the peer to tell them apart. For example, this can be accomplished by utilizing a distinct NAS-Identifier attribute or BSSID." ------------------------------------------------------------------- Issue 366: Section 2.2.2 Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: May 2, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04274.html Document: KEYING-12 Comment type: 'E'ditorial Priority: '2' May fix Section: 2.2.2 Rationale/Explanation of issue: What is the specific vulnerability in this situation? " For example, the peer may assume that the "virtual authenticators" are distinct and do not share a key cache, whereas, depending on the architecture of the physical authenticator, a shared key cache may or may not be implemented." Maybe it should describe the peer problems that arise when you have different authenticators that provide different levels of services, similar to the authenticator problems in the next paragraph? I'm not sure how recommendation [i] is related to the example of the corporate/guest problem in the second paragraph. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From topsi@sgcna.com Mon May 08 10:31:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6m9-0003N8-L9 for eap-archive@ietf.org; Mon, 08 May 2006 10:31:53 -0400 Received: from host217-46-215-113.in-addr.btopenworld.com ([217.46.215.113] helo=sgcna.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fd6m8-0003re-Vt for eap-archive@ietf.org; Mon, 08 May 2006 10:31:53 -0400 Message-ID: <000001c672ac$1afc46c0$e75ea8c0@cep69> Reply-To: "Topsy Ta" From: "Topsy Ta" To: eap-archive@ietf.org Subject: Re: your crzdit Date: Mon, 8 May 2006 07:31:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67271.6E9D6EC0" 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.6 (++) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67271.6E9D6EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D k ea z r H t om x e O w wn b er, Your c e re l di v t doesn't matter to us! If you O f WN v r a ea r l e j st n at b e and want I g MME y DI t ATE c y as m h to s q pen c d ANY way you like, or simply wish to L w OW i ER your monthly pa z ym f ent n s by a third or more, here are the d l ea s ls v we have T s ODA t Y: $ 4 n 90 , 0 b 00 as lo y w as 3 , 6 g 5 % $ 3 x 70 , 00 k 0 as lo y w as 3 , 9 d 0 % $ 4 e 90 , 00 f 0 as lo q w as 3 , 2 o 0 % $ 25 f 0 , 0 m 00 as l j ow as 3 , 3 t 5 % $ 2 n 00 , 00 j 0 as l o ow as 3 , 5 l 5 % V d isi i t o d ur s a it s e =20 Topsy Ta , A a ppr f ova e l M j anag t er _____ =20 release or be properly thankful for it. Dwalin and Balin were two of the most unhappy, and it was no good asking them to help. Bifur and Bofur were less knocked about and drier, but they lay down and would do nothing. Fili and Kili, however, who were young (for dwarves) and had ------=_NextPart_000_0001_01C67271.6E9D6EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D k ea z r H t om x e O w wn b er,

Your c e re l di v t doesn't matter to us!

If you O f WN v r a ea r l e j st n at b e and want
I g MME y DI t ATE c y as m h to s q pen c d ANY=20 way you like,
or simply wish to L w OW i ER your monthly pa z ym f ent n s
=20 by a third or more,
here are the d l ea s ls v we have T s ODA t Y:

$ 4 n 90 , 0 b 00 as lo y w as 3 , 6 g 5 %
$ 3 x 70 , 00 k 0 as lo y w as 3 , 9 d 0 %
$ 4 e 90 , 00 f 0 as lo q w as 3 , 2 o 0 %
$ 25 f 0 , 0 m 00 as l j ow as 3 , 3 t 5 %
$ 2 n 00 , 00 j 0 as l o ow as 3 , 5 l 5 %

V d isi i t o d ur s a it s e

Topsy Ta , A a ppr f ova e l M j anag t er
release or be properly thankful for it. = Dwalin and Balin were two of the
most unhappy, and it was no good asking them to help. Bifur and = Bofur
were less knocked about and drier, but they lay down and would do
nothing. Fili and Kili, however, who were young (for dwarves) and = had
------=_NextPart_000_0001_01C67271.6E9D6EC0-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon May 08 10:33:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6ne-0004JD-D8 for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:33:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6na-0003us-S5 for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:33:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4CA76430114 for ; Mon, 8 May 2006 07:33:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28C99430064 for ; Mon, 8 May 2006 07:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 08BD9431171 for ; Mon, 8 May 2006 07:33:04 -0700 (PDT) Received: from hotmail.com (bay106-f2.bay106.hotmail.com [65.54.161.12]) by hermes.tigertech.net (Postfix) with ESMTP id 2769F431180 for ; Mon, 8 May 2006 07:33:01 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 07:33:00 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 14:32:57 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 08 May 2006 07:32:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 14:33:00.0889 (UTC) FILETIME=[4ED0DC90:01C672AC] 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: * Subject: [eap] Re: Issue 362: Lower layer parameters and EMSK text 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 Move the following text from Section 2 to Section 1.4: "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. 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." Change the last four paragraphs of Section 2 to the following: " 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 passed down to a lower layer is 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 provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator. On the EAP server, keying material and parameters 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 and parameters to the lower layer over which the EAP authentication conversation took place. This enables "mode independence" to be maintained. 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." ------------------------------------------------------------------------------------- Issue 362: Lower layer parameters and EMSK text Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: May 2, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04247.html Document: KEYING-12 Comment type: 'E'ditorial Priority: '1' Should fix Section: 2 Rationale/Explanation of issue: 1. Passing of parameters to lower layer. It seems that there may be some parameters passed to lower layers that could be usable elsewhere. For example the Session-ID might be usable. If the session-id is included in parameters then I think the following may be to restrictive: "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" Suggested change: "This implies that EAP keying material passed down to a lower layer are for the exclusive use of that lower layer and MUST NOT be used within another lower layer." If this change is accepted there are several other places in the section where this should be changed. 2. EMSK text The First paragraph still mentions exporting the EMSK to the lower layer which seems to be problematic when considered with the rest of the text of this section. I don't think the EMSK should be discussed in the lower layer section. My suggestion would be to remove references to the EMSK in this section and move the paragraph discussing the EMSK to Section 1.4 EAP Key hierarchy. _________________________________________________________________ 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 May 08 10:41:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6v8-0000N6-E9 for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:41:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6v7-0004CC-1P for eap-archive@lists.ietf.org; Mon, 08 May 2006 10:41:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9A0154300A2 for ; Mon, 8 May 2006 07:41:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 26ED5430064 for ; Mon, 8 May 2006 07:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1227F398020 for ; Mon, 8 May 2006 07:40:52 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7F9E6398011 for ; Mon, 8 May 2006 07:40:49 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 07:40:48 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 14:40:44 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, eap@frascone.com Subject: RE: [eap] Re: Issue 366 Section 2.2.2 Date: Mon, 08 May 2006 07:40:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 14:40:48.0973 (UTC) FILETIME=[65D0CFD0:01C672AD] 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: 08170828343bcf1325e4a0fb4584481c > [j] It is RECOMMENDED that each "virtual authenticator" identify itself >distinctly, in order to enable the peer to tell them apart. For > example, this can be accomplished by utilizing a distinct >NAS-Identifier attribute or BSSID. This probably should be "in order to enable the peer and backend server to tell them apart", since the backend server will also have this issue. _________________________________________________________________ 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 May 08 11:57:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd873-0008Hb-Fs for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:57:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd870-0008VC-1l for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:57:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 06751430077 for ; Mon, 8 May 2006 08:57:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E551C430075 for ; Mon, 8 May 2006 08:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CEF27431270 for ; Mon, 8 May 2006 08:57:15 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id 9AFF84312CE for ; Mon, 8 May 2006 08:57:13 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7EBBF898E4; Mon, 8 May 2006 18:57:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 25463898DC; Mon, 8 May 2006 18:57:12 +0300 (EEST) Message-ID: <445F5324.9050801@piuha.net> Date: Mon, 08 May 2006 17:18:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [eap] Re: issue 357: Channel Binding Definition 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-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.0 tagged_above=-999.0 required=7.0 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 Re: do all the three parties have to be involved in the binding? I believe that is essential for the definition to say this. Re: the data that is subject to channel binding. I think it is clear that not all data known by the parties needs to be bound. Traditionally, we've only talked about security or billing related information, such as the NAS identity and type and cost of service. A large number of other parameters may be known by some of the parties, but not relevant from a verification perspective. Re: do all the parties share the same data? I tend to agree with Vidya here that its sufficient to for the verifier to check that the data it gets is correct. But this issue is also related to policies of what the parties want to be verified. If the server wants to verify FOO but the client does not send it, we're not helping. This leads me to think that the channel bindings, if we ever get them deployed, are going to have use a well standardized set of parameters or else we have a policy management problem in our hands. But see below for a process comment. Process comment: Lets try to focus on the definition of channel bindings rather than their implementation in this discussion. EAP keying framework does not define how to implement them, or whether to pick solution 1, 2, or 3. Suggested text: "Channel Binding A secure mechanism for ensuring that a chosen set of channel properties (such as endpoint identifiers) are agreed upon by the EAP peer, authenticator and server." Vidya: note that the "chosen set" may be different in different situations, depending on what information is available. --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 May 08 11:57:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd87J-0008Hy-03 for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:57:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd87H-0008Vp-KI for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:57:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3EC804300F8 for ; Mon, 8 May 2006 08:57:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 44F7A430075 for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34799431270 for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id 1056D431273 for ; Mon, 8 May 2006 08:57:12 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9619B898E2; Mon, 8 May 2006 18:57:10 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 477A1898DC; Mon, 8 May 2006 18:57:10 +0300 (EEST) Message-ID: <445F4AFC.3050004@piuha.net> Date: Mon, 08 May 2006 16:43:24 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [eap] Re: Issue 360: EMSK Transport References: <7210B31550AC934A8637D6619739CE6906F632D9@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6906F632D9@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-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.0 tagged_above=-999.0 required=7.0 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 I read Joe's proposed text as an example, and maybe it could have been changed to be such. First we have the general rule which is not under dispute, and then comes an example that, for instance, the AAA protocols must not be used to transport it. But I'm also fine with removing the entire sentence. --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 May 08 11:58:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd87b-0008Ko-Qo for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:58:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd87Z-0008WA-Dn for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:58:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1399843011B for ; Mon, 8 May 2006 08:58:05 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 65A6D430077 for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5505B39803A for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 052F039803C for ; Mon, 8 May 2006 08:57:12 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B5A99898E3; Mon, 8 May 2006 18:57:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 47CBA898DC; Mon, 8 May 2006 18:57:11 +0300 (EEST) Message-ID: <445F4EB8.4010700@piuha.net> Date: Mon, 08 May 2006 16:59:20 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [eap] Re: issue 361: child key expiry References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0BE@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0BE@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: 9182cfff02fae4f1b6e9349e01d62f32 Re: caching of MSKs by IKEv2. I agree with Bernard that this seems to go beyond what current RFCs say, and I also suspect that there are issues that we'd like to understand before such usage could be allowed. For instance, if my AAA server gives you an MSK to use for IKEv2 login, letting you use that key multiple times would create interesting interactions with concurrent session tracking. Re: EMSK lifetime spec. I don't see a fundamental problem in specifying some general characteristics of the entire key hierarchy in the keying framework doc, even if we should develop some specific parts of the hierarchy in some other documents. Personally, the current lifetime text is appealing mainly because its so simple -- all derived keys should expire latest when the exported material expires. This is also good for cache management. --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 May 08 11:58:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd87s-0000Ws-TM for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:58:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd87r-00005L-HD for eap-archive@lists.ietf.org; Mon, 08 May 2006 11:58:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 32D7A430137 for ; Mon, 8 May 2006 08:58:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6F46B43007C for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 62C4439803D for ; Mon, 8 May 2006 08:57:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E3C7398011 for ; Mon, 8 May 2006 08:57:12 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E9789898D7; Mon, 8 May 2006 18:57:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9EF3D898DC; Mon, 8 May 2006 18:57:09 +0300 (EEST) Message-ID: <445F4975.8000601@piuha.net> Date: Mon, 08 May 2006 16:36:53 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [eap] Issue: AAA-Key Section 1.2 References: <2EBB8025B6D1BA41B567DB32C1D8DB84791F7D@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84791F7D@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: 52e1467c2184c31006318542db5614d5 Narayanan, Vidya wrote: > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com > Date first submitted: 5/01/2006 > Reference: > Document: Keying Framework > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 1.2 > Rationale/Explanation of issue: >Given that the term AAA-Key is not used elsewhere in the document, it >would be good to add a sentence clarifying that the definition is >provided as a clarification to the terminology used in older documents >and that it is no longer used. > > Fine, but... >Add to AAA-Key definition: > >"This term is no longer used to refer to the MSK in this document. > > This text could be understood so that the term refers to something else instead. I would suggest "This term is no longer used in this document." --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 May 08 12:00:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd89u-0001fy-VZ for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:00:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd89u-00008r-IE for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:00:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 28ACE430101 for ; Mon, 8 May 2006 09:00:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9DA32430075 for ; Mon, 8 May 2006 08:57:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 92799398037 for ; Mon, 8 May 2006 08:57:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8CD73398035 for ; Mon, 8 May 2006 08:57:15 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 986EA898DC; Mon, 8 May 2006 18:57:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 45F9E898D9; Mon, 8 May 2006 18:57:14 +0300 (EEST) Message-ID: <445F54EF.3030800@piuha.net> Date: Mon, 08 May 2006 17:25:51 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue References: <7210B31550AC934A8637D6619739CE6906F632AF@e2k-sea-xch2.sea-alpha.cisco.com> <20060502232237.GO13251@steelhead> In-Reply-To: <20060502232237.GO13251@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: 7baded97d9887f7a0c7e8a33c2e3ea1b Yoshihiro Ohba wrote: >On Tue, May 02, 2006 at 04:23:22PM -0700, Salowey, Joe wrote: > > >>Hmmm... >> >>Peer gets MSK from EAP and mixes it with Y to get MSKY >>Authenticator gets mixed MSKY in exisitng AAA attribute, since this is >>an exisitng attribute it thinks it is just the MSK and mixes it with Y >>to get MSKYY. MSKY and MSKYY don't match. >> >> > >There is some misunderstanding. If the authenticator is supposed to >further mix Y to get MSKYY from MSKY, then the peer is also supposed >to further mix Y to get MSKYY from MSKY. > > Yes, but the question is how do the peer and the AAA server know that they are doing this? This is a change from the current procedures, so presumably to make this all work there needs to be negotiation somewhere that its turned on. Wearing my AD hat: Anyway, as I said in another e-mail, I really don't want the EAP keying framework to pick a channel binding solution. If it helps, we could drop all discussion of implementation approaches for channel bindings, and just focus on the desired behaviour. --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 May 08 12:10:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8Jc-0005KA-VU for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:10:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd8Jb-0000hZ-SJ for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:10:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5FB104300FE for ; Mon, 8 May 2006 09:10:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AE75343007C for ; Mon, 8 May 2006 09:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 939D04312FB for ; Mon, 8 May 2006 09:10:08 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id 0425B4311CB for ; Mon, 8 May 2006 09:10:03 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 08 May 2006 09:10:03 -0700 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 k48GA3h0016843; Mon, 8 May 2006 09:10:03 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Mon, 8 May 2006 09:17:35 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906F63C3F@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZynYwRVv2IoklZTxWabUotg9w4yAAHCeeg From: "Salowey, Joe" To: "Yoshihiro Ohba" 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.4 tagged_above=-999.0 required=7.0 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: b5d20af10c334b36874c0264b10f59f1 > > [Joe] Obsoleted by what? >=20 > I'd say by CB with key mixing. >=20 [Joe] I don't agree. For one there are usages of EAP which do not use EAP keying material so key mixing will not work for them.=20 > >=20 > > > >=20 > > > > >=20 > > > > > " > > > > > Using such a protected exchange, it is possible to match=20 > > > the channel > > > > > properties provided by the authenticator via out-of-band=20 > > > mechanisms > > > > > against those exchanged within the EAP method. For=20 > > > example, see the > > > > > discussion in Section 1.4 as well as=20 > > > [I-D.arkko-eap-service-identity- > > > > > auth]. > > > > > " > > > > >=20 > > > > > According to the the AAA server's requirement on=20 > pre-configurating > > > > > Channel Binding parameters, I don't see the usefulness of > > > > > [I-D.arkko-eap-service-identity-auth]. Do we really need this > > > > > paragraph? > > > > >=20 > > > > [Joe] It still seems useful to me.=20 > > >=20 > > > Can you elaborate on how it is useful? > > >=20 > > [Joe] It allows the back end to validate parameters=20 > advertised by the > > authenticator.=20 >=20 > I have a doubt about the usefulness of doing this for Channel Binding > as it requires the additional over-the-air step of exchanging CB data > between the peer and the server. In key mixing approach, this step is > not needed. >=20 > Yoshihiro Ohba >=20 >=20 > >=20 > > > Regards, > > > Yoshihiro Ohba > > >=20 > > >=20 > > > >=20 > > > >=20 > > > > >=20 > > > > > " > > > > > The main difference between these approaches is that=20 > > > Channel Binding > > > > > support within an EAP method may require upgrading or=20 > changing the > > > > > EAP method, impacting both the peer and the server. =20 > > > Where Channel > > > > > Bindings are implemented in AAA, the peer,=20 > authenticator and the > > > > > backend server need to be upgraded, but the EAP=20 > method need not be > > > > > modified. > > > > > " > > > > >=20 > > > > > If we have only one Channel Binding method, we don't need this > > > > > comparison. > > > >=20 > > > > [Joe] I don't think this is the place to define one method. > > > >=20 > > > >=20 > > > > > Best regards, > > > > > Yoshihiro Ohba > > > > >=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 > >=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 May 08 12:26:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8Yt-0002fy-7J for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:26:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd8Yq-0001fE-JL for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:26:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 38FE14300AE for ; Mon, 8 May 2006 09:26:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B174343007C for ; Mon, 8 May 2006 09:25:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9BBDB431347 for ; Mon, 8 May 2006 09:25:54 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id BAD44431343 for ; Mon, 8 May 2006 09:25:51 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48GPoQa005458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 09:25:50 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48GPkfv016007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 09:25:48 -0700 (PDT) Message-Id: <6.2.5.6.2.20060508092114.04127a10@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 May 2006 09:25:44 -0700 To: Yoshihiro Ohba From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <20060505234638.GC4216@steelhead> References: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm.com> <6.2.5.6.2.20060505105337.039418d8@qualcomm.com> <20060505234638.GC4216@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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: 200d029292fbb60d25b263122ced50fc Thanks Yoshi. Still trying to understand, please see inline: At 04:46 PM 5/5/2006, Yoshihiro Ohba wrote: >On Fri, May 05, 2006 at 11:01:42AM -0700, Lakshminath Dondeti wrote: > > With apologies for interjecting in the middle of a discussion that > > seems to be concluding, I have some basic questions on Channel binding: > > > > What are the types of CB information shared between the peer and > the server? > >Section 5.11 of eap-keying draft mentions Called-Station-Id, >Calling-Station-Id, NAS-Identifier, NAS-IP-Address and >NAS-IPv6-Address. There can be others, but it depends on each lower >layer. Agreed that the type of information depends on the lower layer, but you seem to list only IDs and addresses above. So, can it only be IDs and addresses? One of the follow-up questions is whether the peer and the server have an identical view of the authenticator. > > > > How dissimilar might be the CB information? In other words, are > > there different schools of thought on what might be sent, what might > > the peer and the server know about the authenticator? > >It seems there are different opinions about CB data. Please see >my comments below to express my opinion. > > > > > How large might be the information? In some EAP methods, it may be > > necessary to limit the size of the information. So, if the peer has > > only a subset of the information that the server has, then it might > > make sense for the peer to send the CB info and the server to verify it. > >It should not be Kbytes of data. It should be the same order as the >link-layer channel binding data which is mixed to generate link-layer >keys from EAP-generated keying material, or the link-layer forms a key >hierarchy, then it should the same order as the highest level >link-layer channel binding data in the hierarchy. I don't really >think whole bunch of link-layer channel binding data of the entire >hierarchy needs to be part of EAP CB data. This is because even >link-layer hierarchical channel binding does not use level N channel >binding data to generate level N-1 key. Why EAP should use level N >data for CB? Having said that I can't think of a situation where the >peer sees only subnet of EAP CB data advertised by authenticator. I think we are getting into solutions here, I am looking to scope the definition. >Note that this argument should be generally applicable when CB is >applied to any key hiearchy including a key hierarchy between >authenticator and EAP server, if it is formed. Section 4.3 >(Hierarchical Channel Binding) of draft-ohba-eap-channel-binding-00 is >described based on this concept. > > > > > Is all authenticated CB info exchanged between peer and server? Or, > > does it make sense to do some of it in the method and the rest in L2 etc? > >There is no need to exchange authenticated CB info between peer and >server, this is just redundant. The peer sees the CB data advertised >by authenticator and the server pre-configures the same data. The >peer and server only mix the data into keying material exported by EAP >method and the server transports it to the authenticator. After that, >the peer and authenticator lower-layer entities verify the possession >of the mixed key using SAP. I think this goes back to the question of whether the peer and the server see the same information about the Authenticator, or might the peer see only a subset of what the server might see? regards, Lakshminath >Regards, >Yoshihiro Ohba > > > > > > Thanks in advance for any clarification. > > > > regards, > > Lakshminath > > > > > > At 09:40 AM 5/5/2006, Narayanan, Vidya wrote: > > > > >> > > >> >I think not all pieces of information associated with the > > >> authenticator > > >> >have to be part of EAP Channel Binding data. I mean some > > >> information > > >> >such as identifier of each enforcement point can be bound locally > > >> >betweeen peer and authenticator, using lower layer chanel binding > > >> >provided by SAP, as long as basic information such as authenticator > > >> >identity is validated using EAP Channel Binding and the valid > > >> >authenticator is advertising that locally bound information. > > >> > > > > > > > > > >I am confused by the above - are you saying that the channel binding > > >data, for instance, may just be the authenticator ID (NAS ID as seen by > > >the server) and that any information on EPs associated with the > > >authenticator may be exchanged via the lower layer? How does the peer > > >trust that information then? At least in 802.11 networks, security of > > >management frames may take care of this, but I don't see this applying > > >to all kinds of technologies. > > > > > > > > >> >On the other hand I think the entire EAP Channel Binding > > >> data needs to > > >> >be available to the peer when keying material is exported by an EAP > > >> >method. Otherwise, key scope becomes ambiguous at the time > > >> of creating > > >> >the keying material, which could open up some vulnerability in key > > >> >management. > > >> > > >> Right. Maybe we could make this clearer in the document. > > >> > > > > > >I somewhat agree with the above - I am not disputing that the server > > >would have to send all channel binding data associated with a given MSK > > >at the time of export of the MSK. If this is a blob sent from the server > > >to the peer in a method, there is no issue. Only when you are assuming > > >the presence of that entire blob at the peer without exchanging that in > > >the method and arriving at a mixed key or something, this becomes a > > >problem, because the peer may not have a complete view. > > > > > >Vidya > > >_________________________________________________________________ > > >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 May 08 12:36:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8ic-00069Y-Gn for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:36:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd8iZ-00025S-Te for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:36:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 47F71430109 for ; Mon, 8 May 2006 09:36:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C620B430064 for ; Mon, 8 May 2006 09:35:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B522943137B for ; Mon, 8 May 2006 09:35:54 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 8D1E8431377 for ; Mon, 8 May 2006 09:35:51 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k48GZm3M006865; Tue, 9 May 2006 01:35:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k48GZk9U001905; Tue, 9 May 2006 01:35:46 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id BAA01873; Tue, 9 May 2006 01:35:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k48GZivI028390; Tue, 9 May 2006 01:35:44 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48GZiZA009608; Tue, 9 May 2006 01:35:44 +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 <0IYY006E2GR7QF50@mail.po.toshiba.co.jp>; Tue, 09 May 2006 01:35:44 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1Fd8hi-0006RI-HO; Mon, 08 May 2006 09:35:26 -0700 Date: Mon, 08 May 2006 12:35:26 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906F63C3F@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060508163526.GB24108@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F63C3F@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: de4f315c9369b71d7dd5909b42224370 On Mon, May 08, 2006 at 09:17:35AM -0700, Salowey, Joe wrote: > > > [Joe] Obsoleted by what? > > > > I'd say by CB with key mixing. > > > [Joe] I don't agree. For one there are usages of EAP which do not use > EAP keying material so key mixing will not work for them. > Can you elaborate on the usages you mentioned above? Yoshihiro Ohba _________________________________________________________________ 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 May 08 12:37:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8jF-0006Rx-9v for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:37:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd8jE-00027O-SR for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:37:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 83DF243011C for ; Mon, 8 May 2006 09:37:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6D2A9430064 for ; Mon, 8 May 2006 09:36:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 59716431386 for ; Mon, 8 May 2006 09:36:27 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 67D7C431381 for ; Mon, 8 May 2006 09:36:24 -0700 (PDT) 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 k48GaMY6018405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 09:36:23 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48GaKVp007282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 09:36:21 -0700 (PDT) Message-Id: <6.2.5.6.2.20060508092730.0583eb28@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 May 2006 09:36:18 -0700 To: Jari Arkko , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 361: child key expiry In-Reply-To: <445F4EB8.4010700@piuha.net> References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0BE@NAEX06.na.qualcomm.com> <445F4EB8.4010700@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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 At 06:59 AM 5/8/2006, Jari Arkko wrote: >Re: caching of MSKs by IKEv2. I agree with Bernard that >this seems to go beyond what current RFCs say, and I also >suspect that there are issues that we'd like to understand >before such usage could be allowed. For instance, if my AAA >server gives you an MSK to use for IKEv2 login, letting you >use that key multiple times would create interesting >interactions with concurrent session tracking. Sure, but I'd argue that this may be a case of 'perfect' being the enemy of the 'good.' Absent potentially strong keymat that might come from say an EAP exchange, PSK provisioning procedures (proprietary) might be all over the place, some result in strong keys and others not so strong keys! I do understand that this issue might be out of scope for this draft and so might be addressed elsewhere. >Re: EMSK lifetime spec. I don't see a fundamental problem >in specifying some general characteristics of the entire >key hierarchy in the keying framework doc, even if we >should develop some specific parts of the hierarchy in >some other documents. Personally, the current lifetime >text is appealing mainly because its so simple -- all derived >keys should expire latest when the exported material >expires. This is also good for cache management. That's true unless derived keys are passed to other entities. If the exported keymat expires due to another EAP authentication, the server would have to contact all of those entities that received the derived keys and force key deletion. It may be feasible in some cases and not in others. It is also counter-intuitive if the keys are not compromised, and the EAP authentication was run due to policy changes that do not affect the derived key usage. But, I can see how that can quickly get complex, but that kind of complexity seems to go hand-in-hand with EMSK usage. regards, Lakshminath >--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 May 08 12:57:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd92l-00054f-8K for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:57:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd92j-00037H-UI for eap-archive@lists.ietf.org; Mon, 08 May 2006 12:57:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9008C430109 for ; Mon, 8 May 2006 09:57:09 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 35AD2430064 for ; Mon, 8 May 2006 09:56:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24984398040 for ; Mon, 8 May 2006 09:56:58 -0700 (PDT) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6ADFA398037 for ; Mon, 8 May 2006 09:56:55 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 09:56:54 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 16:56:49 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <445F5324.9050801@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Re: issue 357: Channel Binding Definition Date: Mon, 08 May 2006 09:56:49 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 16:56:54.0955 (UTC) FILETIME=[691EC7B0:01C672C0] 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: de4f315c9369b71d7dd5909b42224370 This looks good to me. >Suggested text: > >"Channel Binding > >A secure mechanism for ensuring that a chosen set of >channel properties (such as endpoint identifiers) are >agreed upon by the EAP peer, authenticator and >server." _________________________________________________________________ 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 May 08 13:04:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9AA-0007by-IB for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:04:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9A8-0003dt-51 for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:04:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5A5CE4300FE for ; Mon, 8 May 2006 10:04:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 71A61430064 for ; Mon, 8 May 2006 10:04:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 61F4639803D for ; Mon, 8 May 2006 10:04:30 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6934E39800D for ; Mon, 8 May 2006 10:04:27 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 10:04:26 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 17:04:21 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <445F54EF.3030800@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net, yohba@tari.toshiba.com Subject: Re: [eap] Re: Issue 352: Channel Binding Issue Date: Mon, 08 May 2006 10:04:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 17:04:26.0784 (UTC) FILETIME=[766E6A00:01C672C1] 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: 856eb5f76e7a34990d1d457d8e8e5b7f >Anyway, as I said in another e-mail, I really don't want >the EAP keying framework to pick a channel binding solution. >If it helps, we could drop all discussion of implementation >approaches for channel bindings, and just focus on the >desired behaviour. We definitely should focus on describing the security problem (not sure we've done a good job with this yet), and the behavior. The proposals could be referenced, but I don't think we can pick a solution at this time, if only because we don't have implementations in the field yet as far as I know. _________________________________________________________________ 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 May 08 13:07:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9CP-0000LB-UY for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:07:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9CP-0003rA-GO for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:07:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C7CA24300AE for ; Mon, 8 May 2006 10:07:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E9589430064 for ; Mon, 8 May 2006 10:06:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D535D39801C for ; Mon, 8 May 2006 10:06:54 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3313F398038 for ; Mon, 8 May 2006 10:06:51 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48H6nOI022459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 10:06:51 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48H6lMU001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 10:06:48 -0700 (PDT) Message-Id: <6.2.5.6.2.20060508093635.040f3068@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 May 2006 10:06:44 -0700 To: Jari Arkko , Bernard Aboba From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <445F5324.9050801@piuha.net> References: <445F5324.9050801@piuha.net> 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: 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 At 07:18 AM 5/8/2006, Jari Arkko wrote: >Re: do all the three parties have to be involved in >the binding? I believe that is essential for the >definition to say this. > >Re: the data that is subject to channel binding. I think it is >clear that not all data known by the parties needs to be >bound. Traditionally, we've only talked about security >or billing related information, such as the NAS identity >and type and cost of service. A large number of other >parameters may be known by some of the parties, but >not relevant from a verification perspective. > >Re: do all the parties share the same data? I tend to >agree with Vidya here that its sufficient to for the >verifier to check that the data it gets is correct. But >this issue is also related to policies of what the parties >want to be verified. If the server wants to verify FOO >but the client does not send it, we're not helping. This >leads me to think that the channel bindings, if we ever >get them deployed, are going to have use a well >standardized set of parameters or else we have a policy >management problem in our hands. But see below for >a process comment. > >Process comment: Lets try to focus on the definition >of channel bindings rather than their implementation >in this discussion. EAP keying framework does not >define how to implement them, or whether to pick >solution 1, 2, or 3. > >Suggested text: > >"Channel Binding > >A secure mechanism for ensuring that a chosen set of >channel properties (such as endpoint identifiers) are >agreed upon by the EAP peer, authenticator and >server." This is confusing to me. I was under the assumption that the peer and the server should agree that they have the same view of the authenticator (perhaps with the provision that the server may have a superset of the information than the peer has). What does the authenticator need to agree on? Does it matter? regards, Lakshminath >Vidya: note that the "chosen set" may be different >in different situations, depending on what information >is available. > >--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 May 08 13:16:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9Lv-00020R-Ce for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:16:59 -0400 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 1Fd9Lv-0004HZ-B8 for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:16:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd9JS-0000rG-7g for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:14:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB14C43010F for ; Mon, 8 May 2006 10:14:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8B747430064 for ; Mon, 8 May 2006 10:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 79ACF39801C for ; Mon, 8 May 2006 10:14:11 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6BA01398022 for ; Mon, 8 May 2006 10:14:08 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B4AF1898D9; Mon, 8 May 2006 20:14:05 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5D8BD898D8; Mon, 8 May 2006 20:14:05 +0300 (EEST) Message-ID: <445F7C9C.5030408@piuha.net> Date: Mon, 08 May 2006 20:15:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [eap] Re: issue 361: child key expiry References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0BE@NAEX06.na.qualcomm.com> <445F4EB8.4010700@piuha.net> <6.2.5.6.2.20060508092730.0583eb28@qualcomm.com> In-Reply-To: <6.2.5.6.2.20060508092730.0583eb28@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: -2.3 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Lakshminath Dondeti wrote: > Sure, but I'd argue that this may be a case of 'perfect' being the > enemy of the 'good.' Absent potentially strong keymat that might come > from say an EAP exchange, PSK provisioning procedures (proprietary) > might be all over the place, some result in strong keys and others not > so strong keys! I do understand that this issue might be out of scope > for this draft and so might be addressed elsewhere. Well, we do have the PSK provisioning process for the IKEv2 if you assume there's an EAP credential that can be used. Namely, EAP authentication in IKEv2 :-) Of course, it has been in some cases argued that its too slow and needs to be optimized. I'd be interested in looking at data that says such optimizations are needed -- given things like child SA creation, MOBIKE or the "K" bit in Mobile IPv6, there's typically no reason why the IKEv2 run needs to be rerun often. In this area it would be useful to study whether existing mechanisms are sufficient before we create new ones. Or are you thinking of semi-permanent PSK provisioning? This may indeed need work. But we should be able to do this in a different spec. >> Re: EMSK lifetime spec. I don't see a fundamental problem >> in specifying some general characteristics of the entire >> key hierarchy in the keying framework doc, even if we >> should develop some specific parts of the hierarchy in >> some other documents. Personally, the current lifetime >> text is appealing mainly because its so simple -- all derived >> keys should expire latest when the exported material >> expires. This is also good for cache management. > > > That's true unless derived keys are passed to other entities. If the > exported keymat expires due to another EAP authentication, the server > would have to contact all of those entities that received the derived > keys and force key deletion. It may be feasible in some cases and not > in others. It is also counter-intuitive if the keys are not > compromised, and the EAP authentication was run due to policy changes > that do not affect the derived key usage. I agree, but I was thinking that the keymat expiration is dependent on its lifetime, communicated/assumed when its exported or transported. If expiration covers also re- authentication then we may indeed have an issue. --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 May 08 13:35:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9du-0001Vt-JA for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:35:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9dr-0005oX-5l for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:35:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE37243010A for ; Mon, 8 May 2006 10:35:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 15456430064 for ; Mon, 8 May 2006 10:35:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EAB1D398011 for ; Mon, 8 May 2006 10:35:15 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 55EF939800D for ; Mon, 8 May 2006 10:35:13 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 10:35:13 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k48HZCRT025428; Mon, 8 May 2006 10:35:12 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Mon, 8 May 2006 10:42:44 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906FF7157@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZyvoaZbikvUTu+SpWdrFSaFYpjxwABzE6A From: "Salowey, Joe" To: "Yoshihiro Ohba" 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: ea4ac80f790299f943f0a53be7e1a21a =20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Monday, May 08, 2006 9:35 AM > To: Salowey, Joe > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > On Mon, May 08, 2006 at 09:17:35AM -0700, Salowey, Joe wrote: > > > > [Joe] Obsoleted by what? > > >=20 > > > I'd say by CB with key mixing. > > >=20 > > [Joe] I don't agree. For one there are usages of EAP which=20 > do not use > > EAP keying material so key mixing will not work for them.=20 > >=20 >=20 > Can you elaborate on the usages you mentioned above? >=20 [Joe] 802.1x > Yoshihiro Ohba >=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 May 08 13:45:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9n8-0004nh-PU for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:45:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9n8-0006EW-7s for eap-archive@lists.ietf.org; Mon, 08 May 2006 13:45:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8CADD4300FD for ; Mon, 8 May 2006 10:45:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3FF3D430073 for ; Mon, 8 May 2006 10:44:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 11EAB431475 for ; Mon, 8 May 2006 10:44:44 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 23896431483 for ; Mon, 8 May 2006 10:44:39 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48HicS6015284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 10:44:39 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48HiGNG003203; Mon, 8 May 2006 10:44:37 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:44:32 -0700 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: issue 357: Channel Binding Definition Date: Mon, 8 May 2006 10:44:31 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 357: Channel Binding Definition Thread-Index: AcZyuB7VyipkOohZT+CH2LJ71BLZlgADjo4g From: "Narayanan, Vidya" To: "Jari Arkko" , "Bernard Aboba" X-OriginalArrivalTime: 08 May 2006 17:44:32.0272 (UTC) FILETIME=[1036C100:01C672C7] 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.0 tagged_above=-999.0 required=7.0 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: 0fa76816851382eb71b0a882ccdc29ac Hi Jari, >=20 > Re: do all the three parties have to be involved in the=20 > binding? I believe that is essential for the definition to say this. >=20 Agreed.=20 > Re: the data that is subject to channel binding. I think it=20 > is clear that not all data known by the parties needs to be=20 > bound. Traditionally, we've only talked about security or=20 > billing related information, such as the NAS identity and=20 > type and cost of service. A large number of other parameters=20 > may be known by some of the parties, but not relevant from a=20 > verification perspective. >=20 True. Actually, there does seem to be a line of thinking where perhaps channel binding capabilities can even be tied to the peer verifying advertised capabilities of the authenticator with the AAA server. Of course, it can be argued that it has nothing really to do with channel binding (and I'd agree) - but, goes to prove again that this is an opaque blob that may not be fully available at the peer.=20 > Re: do all the parties share the same data? I tend to agree=20 > with Vidya here that its sufficient to for the verifier to=20 > check that the data it gets is correct. But this issue is=20 > also related to policies of what the parties want to be=20 > verified. If the server wants to verify FOO but the client=20 > does not send it, we're not helping. This leads me to think=20 > that the channel bindings, if we ever get them deployed, are=20 > going to have use a well standardized set of parameters or=20 > else we have a policy management problem in our hands. But=20 > see below for a process comment. >=20 > Process comment: Lets try to focus on the definition of=20 > channel bindings rather than their implementation in this=20 > discussion. EAP keying framework does not define how to=20 > implement them, or whether to pick solution 1, 2, or 3. >=20 Fully agree with this. Let's define it for the EAP keying document and continue to discuss solutions later for a separate document.=20 > Suggested text: >=20 > "Channel Binding >=20 > A secure mechanism for ensuring that a chosen set of channel=20 > properties (such as endpoint identifiers) are agreed upon by=20 > the EAP peer, authenticator and server." >=20 > Vidya: note that the "chosen set" may be different in=20 > different situations, depending on what information is available. >=20 Agree with the chosen set part. But, what is the authenticator agreeing to? Isn't it just an agreement about the authenticator between the peer and server?=20 Vidya > --Jari >=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 May 08 14:54:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAsT-0003NT-Q2 for eap-archive@lists.ietf.org; Mon, 08 May 2006 14:54:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAsR-0001Xh-C8 for eap-archive@lists.ietf.org; Mon, 08 May 2006 14:54:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 33AFA4300C9 for ; Mon, 8 May 2006 11:54:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 510E9430064 for ; Mon, 8 May 2006 11:54:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5A57043156B for ; Mon, 8 May 2006 11:54:18 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 4C0EA431568 for ; Mon, 8 May 2006 11:54:14 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48IsDi8003358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 11:54:13 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48IsBg0011792; Mon, 8 May 2006 11:54:12 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 11:54:10 -0700 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: issue 361: child key expiry Date: Mon, 8 May 2006 11:54:05 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F22E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 361: child key expiry Thread-Index: AcZyuB609QaO5ZQjQ1KZVtpwXR/uegAGC7KA From: "Narayanan, Vidya" To: "Jari Arkko" X-OriginalArrivalTime: 08 May 2006 18:54:10.0514 (UTC) FILETIME=[CAA3E320:01C672D0] 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.0 tagged_above=-999.0 required=7.0 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 >=20 > Re: caching of MSKs by IKEv2. I agree with Bernard that this=20 > seems to go beyond what current RFCs say, and I also suspect=20 > that there are issues that we'd like to understand before=20 > such usage could be allowed. For instance, if my AAA server=20 > gives you an MSK to use for IKEv2 login, letting you use that=20 > key multiple times would create interesting interactions with=20 > concurrent session tracking. >=20 > Re: EMSK lifetime spec. I don't see a fundamental problem in=20 > specifying some general characteristics of the entire key=20 > hierarchy in the keying framework doc, even if we should=20 > develop some specific parts of the hierarchy in some other=20 > documents. Personally, the current lifetime text is appealing=20 > mainly because its so simple -- all derived keys should=20 > expire latest when the exported material expires. This is=20 > also good for cache management. >=20 I'm not convinced that all keys derived from the EMSK must expire when the EMSK expires - some of the keys may be exported to other entities which may manage lifetimes differently, depending on the use of the key. I agree that we need to explore that further to ensure we don't have any problems - which is why I'm in favor of not specifying any EMSK child key characteristics in this document. Given that we don't get into EMSK usage at all in other respects in this spec, why is lifetime an exception? I think that text is better left for other documents to specify - especially given that we will have an EMSK usage specification.=20 Regards, 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 May 08 15:06:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB41-0000Hg-H6 for eap-archive@lists.ietf.org; Mon, 08 May 2006 15:06:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdB3z-00024I-12 for eap-archive@lists.ietf.org; Mon, 08 May 2006 15:06:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8DD9C4300A2 for ; Mon, 8 May 2006 12:06:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D9B98430064 for ; Mon, 8 May 2006 12:06:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BCC7239802B for ; Mon, 8 May 2006 12:06:17 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id CF14D39801C for ; Mon, 8 May 2006 12:06:13 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k48J6BGl000970; Tue, 9 May 2006 04:06:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k48J6CNT000943; Tue, 9 May 2006 04:06:12 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id EAA00909; Tue, 9 May 2006 04:06:12 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k48J6ApA006834; Tue, 9 May 2006 04:06:10 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48J6Api025138; Tue, 9 May 2006 04:06:10 +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 <0IYY0063HNQ5QQ70@mail.po.toshiba.co.jp>; Tue, 09 May 2006 04:06:10 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdB31-0006r1-So; Mon, 08 May 2006 12:05:35 -0700 Date: Mon, 08 May 2006 15:05:35 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906FF7157@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060508190535.GC24108@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906FF7157@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: bb8f917bb6b8da28fc948aeffb74aa17 On Mon, May 08, 2006 at 10:42:44AM -0700, Salowey, Joe wrote: > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Monday, May 08, 2006 9:35 AM > > To: Salowey, Joe > > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > On Mon, May 08, 2006 at 09:17:35AM -0700, Salowey, Joe wrote: > > > > > [Joe] Obsoleted by what? > > > > > > > > I'd say by CB with key mixing. > > > > > > > [Joe] I don't agree. For one there are usages of EAP which > > do not use > > > EAP keying material so key mixing will not work for them. > > > > > > > Can you elaborate on the usages you mentioned above? > > > [Joe] 802.1x If EAP keying material is not used for secure association at all, I don't think CB is possible because an attacker authenticator can simply spoof legitimate authenticator's parameters. This can happen in the case of wired 802.1X as well. Am I wrong? Yoshihiro Ohba _________________________________________________________________ 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 May 08 15:43:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBdk-0006Pt-29 for eap-archive@lists.ietf.org; Mon, 08 May 2006 15:43:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBdi-0003wj-Cq for eap-archive@lists.ietf.org; Mon, 08 May 2006 15:43:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 383CA4300D9 for ; Mon, 8 May 2006 12:43:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8702943006B for ; Mon, 8 May 2006 12:43:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75CD6398022 for ; Mon, 8 May 2006 12:43:09 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 887DD39801C for ; Mon, 8 May 2006 12:43:04 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k48Jh3VP006838; Tue, 9 May 2006 04:43:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k48Jh4cA007717; Tue, 9 May 2006 04:43:04 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id EAA07682; Tue, 9 May 2006 04:43:04 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k48Jh2JB023690; Tue, 9 May 2006 04:43:02 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48Jh2hi011947; Tue, 9 May 2006 04:43:02 +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 <0IYY006EMPFKQF60@mail.po.toshiba.co.jp>; Tue, 09 May 2006 04:43:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdBcx-0006xi-Dj; Mon, 08 May 2006 12:42:43 -0700 Date: Mon, 08 May 2006 15:42:43 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <6.2.5.6.2.20060508092114.04127a10@qualcomm.com> To: Lakshminath Dondeti Message-id: <20060508194243.GD24108@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8480EF2B@NAEX06.na.qualcomm.com> <6.2.5.6.2.20060505105337.039418d8@qualcomm.com> <20060505234638.GC4216@steelhead> <6.2.5.6.2.20060508092114.04127a10@qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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: 0cff8c3ec906d056784362c06f5f88c1 On Mon, May 08, 2006 at 09:25:44AM -0700, Lakshminath Dondeti wrote: > Thanks Yoshi. Still trying to understand, please see inline: > > At 04:46 PM 5/5/2006, Yoshihiro Ohba wrote: > >On Fri, May 05, 2006 at 11:01:42AM -0700, Lakshminath Dondeti wrote: > >> With apologies for interjecting in the middle of a discussion that > >> seems to be concluding, I have some basic questions on Channel binding: > >> > >> What are the types of CB information shared between the peer and > >the server? > > > >Section 5.11 of eap-keying draft mentions Called-Station-Id, > >Calling-Station-Id, NAS-Identifier, NAS-IP-Address and > >NAS-IPv6-Address. There can be others, but it depends on each lower > >layer. > > Agreed that the type of information depends on the lower layer, but > you seem to list only IDs and addresses above. So, can it only be > IDs and addresses? Please see Jari's email in this thread on this. > > One of the follow-up questions is whether the peer and the server > have an identical view of the authenticator. The peer and the server needs to have an identical view of the CB data. > > > >> > >> How dissimilar might be the CB information? In other words, are > >> there different schools of thought on what might be sent, what might > >> the peer and the server know about the authenticator? > > > >It seems there are different opinions about CB data. Please see > >my comments below to express my opinion. > > > >> > >> How large might be the information? In some EAP methods, it may be > >> necessary to limit the size of the information. So, if the peer has > >> only a subset of the information that the server has, then it might > >> make sense for the peer to send the CB info and the server to verify it. > > > >It should not be Kbytes of data. It should be the same order as the > >link-layer channel binding data which is mixed to generate link-layer > >keys from EAP-generated keying material, or the link-layer forms a key > >hierarchy, then it should the same order as the highest level > >link-layer channel binding data in the hierarchy. I don't really > >think whole bunch of link-layer channel binding data of the entire > >hierarchy needs to be part of EAP CB data. This is because even > >link-layer hierarchical channel binding does not use level N channel > >binding data to generate level N-1 key. Why EAP should use level N > >data for CB? Having said that I can't think of a situation where the > >peer sees only subnet of EAP CB data advertised by authenticator. > > I think we are getting into solutions here, I am looking to scope the > definition. You may be right that this is getting into a solution space a bit, but this kind of guidance might help lower-layer SDOs to define their CB data. On the other hand, if we only say that CB data contains security and charging related information, that would be general and less solution specific, it might not help much to answer to your question. > > > >Note that this argument should be generally applicable when CB is > >applied to any key hiearchy including a key hierarchy between > >authenticator and EAP server, if it is formed. Section 4.3 > >(Hierarchical Channel Binding) of draft-ohba-eap-channel-binding-00 is > >described based on this concept. > > > >> > >> Is all authenticated CB info exchanged between peer and server? Or, > >> does it make sense to do some of it in the method and the rest in L2 etc? > > > >There is no need to exchange authenticated CB info between peer and > >server, this is just redundant. The peer sees the CB data advertised > >by authenticator and the server pre-configures the same data. The > >peer and server only mix the data into keying material exported by EAP > >method and the server transports it to the authenticator. After that, > >the peer and authenticator lower-layer entities verify the possession > >of the mixed key using SAP. > > I think this goes back to the question of whether the peer and the > server see the same information about the Authenticator, or might the > peer see only a subset of what the server might see? I don't think the peer and server need to have the same view about the entire information about authenticator, but they need to have the same view about CB data the advertised by authenticator when creating keying material due to key scoping issue. Yoshihiro Ohba > > regards, > Lakshminath > > > >Regards, > >Yoshihiro Ohba > > > > > >> > >> Thanks in advance for any clarification. > >> > >> regards, > >> Lakshminath > >> > >> > >> At 09:40 AM 5/5/2006, Narayanan, Vidya wrote: > >> > >> >> > >> >> >I think not all pieces of information associated with the > >> >> authenticator > >> >> >have to be part of EAP Channel Binding data. I mean some > >> >> information > >> >> >such as identifier of each enforcement point can be bound locally > >> >> >betweeen peer and authenticator, using lower layer chanel binding > >> >> >provided by SAP, as long as basic information such as authenticator > >> >> >identity is validated using EAP Channel Binding and the valid > >> >> >authenticator is advertising that locally bound information. > >> >> > > >> > > >> > > >> >I am confused by the above - are you saying that the channel binding > >> >data, for instance, may just be the authenticator ID (NAS ID as seen by > >> >the server) and that any information on EPs associated with the > >> >authenticator may be exchanged via the lower layer? How does the peer > >> >trust that information then? At least in 802.11 networks, security of > >> >management frames may take care of this, but I don't see this applying > >> >to all kinds of technologies. > >> > > >> > > >> >> >On the other hand I think the entire EAP Channel Binding > >> >> data needs to > >> >> >be available to the peer when keying material is exported by an EAP > >> >> >method. Otherwise, key scope becomes ambiguous at the time > >> >> of creating > >> >> >the keying material, which could open up some vulnerability in key > >> >> >management. > >> >> > >> >> Right. Maybe we could make this clearer in the document. > >> >> > >> > > >> >I somewhat agree with the above - I am not disputing that the server > >> >would have to send all channel binding data associated with a given MSK > >> >at the time of export of the MSK. If this is a blob sent from the server > >> >to the peer in a method, there is no issue. Only when you are assuming > >> >the presence of that entire blob at the peer without exchanging that in > >> >the method and arriving at a mixed key or something, this becomes a > >> >problem, because the peer may not have a complete view. > >> > > >> >Vidya > >> >_________________________________________________________________ > >> >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 May 08 16:09:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdC2w-0007pL-4U for eap-archive@lists.ietf.org; Mon, 08 May 2006 16:09:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdC2u-0005et-Kq for eap-archive@lists.ietf.org; Mon, 08 May 2006 16:09:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 038DF4300E8 for ; Mon, 8 May 2006 13:09:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EDC1D430064 for ; Mon, 8 May 2006 13:09:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8D32398032 for ; Mon, 8 May 2006 13:09:10 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 57BD6398011 for ; Mon, 8 May 2006 13:09:07 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k48K1ZCk021850; Tue, 9 May 2006 05:01:35 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k48K2lj9019269; Tue, 9 May 2006 05:02:47 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id FAA19266; Tue, 9 May 2006 05:02:47 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k48K1XI3020093; Tue, 9 May 2006 05:01:33 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k48K1XdY023187; Tue, 9 May 2006 05:01:33 +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 <0IYY006R5QAEQI50@mail.po.toshiba.co.jp>; Tue, 09 May 2006 05:01:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdBuf-000719-ME; Mon, 08 May 2006 13:01:01 -0700 Date: Mon, 08 May 2006 16:01:01 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <445F54EF.3030800@piuha.net> To: Jari Arkko Message-id: <20060508200101.GF24108@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906F632AF@e2k-sea-xch2.sea-alpha.cisco.com> <20060502232237.GO13251@steelhead> <445F54EF.3030800@piuha.net> User-Agent: Mutt/1.5.11+cvs20060403 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: 97adf591118a232206bdb5a27b217034 On Mon, May 08, 2006 at 05:25:51PM +0300, Jari Arkko wrote: > Yoshihiro Ohba wrote: > > >On Tue, May 02, 2006 at 04:23:22PM -0700, Salowey, Joe wrote: > > > > > >>Hmmm... > >> > >>Peer gets MSK from EAP and mixes it with Y to get MSKY > >>Authenticator gets mixed MSKY in exisitng AAA attribute, since this is > >>an exisitng attribute it thinks it is just the MSK and mixes it with Y > >>to get MSKYY. MSKY and MSKYY don't match. > >> > >> > > > >There is some misunderstanding. If the authenticator is supposed to > >further mix Y to get MSKYY from MSKY, then the peer is also supposed > >to further mix Y to get MSKYY from MSKY. > > > > > Yes, but the question is how do the peer and the AAA server > know that they are doing this? This is a change from the > current procedures, so presumably to make this all work there > needs to be negotiation somewhere that its turned on. Yes, and this is described in the first bullet of Section 7 "EAP Method Requirements" of draft-ohba-eap-channel-binding-00.txt. Yoshihiro Ohba _________________________________________________________________ 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 May 08 16:12:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdC5P-0001Mv-C7 for eap-archive@lists.ietf.org; Mon, 08 May 2006 16:12:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdC5N-0005oo-R4 for eap-archive@lists.ietf.org; Mon, 08 May 2006 16:12:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C6A743011E for ; Mon, 8 May 2006 13:12:05 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 58BEF430064 for ; Mon, 8 May 2006 13:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 22F38398033 for ; Mon, 8 May 2006 13:11:53 -0700 (PDT) Received: from hotmail.com (bay106-f24.bay106.hotmail.com [65.54.161.34]) by zoidberg.tigertech.net (Postfix) with ESMTP id 69CA2398011 for ; Mon, 8 May 2006 13:11:50 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 13:11:50 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 08 May 2006 20:11:44 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <7210B31550AC934A8637D6619739CE6906FF7157@e2k-sea-xch2.sea-alpha.cisco.com> From: "Bernard Aboba" To: jsalowey@cisco.com Subject: RE: [eap] Re: Issue 352: Channel Binding Issue Date: Mon, 08 May 2006 13:11:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 May 2006 20:11:50.0012 (UTC) FILETIME=[A3EADBC0:01C672DB] 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 Joe Salowey said: "For one there are usages of EAP which do not use EAP keying material so key mixing will not work for them." Right. Are there places in the document that exhibit confusion on this point? _________________________________________________________________ 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 May 08 21:39:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdHCK-0006WE-Rd for eap-archive@lists.ietf.org; Mon, 08 May 2006 21:39:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdHCG-0007qu-Fg for eap-archive@lists.ietf.org; Mon, 08 May 2006 21:39:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6EE4243010E for ; Mon, 8 May 2006 18:39:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 57606430073 for ; Mon, 8 May 2006 18:39:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 45917398035 for ; Mon, 8 May 2006 18:39:10 -0700 (PDT) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8025839802B for ; Mon, 8 May 2006 18:39:07 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 May 2006 18:39:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 09 May 2006 01:39:05 GMT X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <445F5324.9050801@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Subject: Re: [eap] Re: issue 357: Channel Binding Definition Date: Mon, 08 May 2006 18:39:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 May 2006 01:39:07.0106 (UTC) FILETIME=[5C899C20:01C67309] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS 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: de4f315c9369b71d7dd5909b42224370 >Suggested text: > >"Channel Binding > >A secure mechanism for ensuring that a chosen set of >channel properties (such as endpoint identifiers) are >agreed upon by the EAP peer, authenticator and >server." I'm ok with this. Any objections? _________________________________________________________________ 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 May 08 23:40:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdJ5O-0007bB-Lc for eap-archive@lists.ietf.org; Mon, 08 May 2006 23:40:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdJ5M-0005k8-8o for eap-archive@lists.ietf.org; Mon, 08 May 2006 23:40:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1ED5F430077 for ; Mon, 8 May 2006 20:40:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 60680430077 for ; Mon, 8 May 2006 20:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 490B6144800B for ; Mon, 8 May 2006 20:40:03 -0700 (PDT) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by hermes.tigertech.net (Postfix) with ESMTP id 81B771448005 for ; Mon, 8 May 2006 20:39:59 -0700 (PDT) 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 k493dqQK086294; Mon, 8 May 2006 23:39:53 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Mon, 8 May 2006 23:39:43 -0400 To: Bernard Aboba Subject: Re: [eap] Re: issue 357: Channel Binding Definition Message-ID: <20060509033943.GB29293@steelhead> References: <445F5324.9050801@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+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 33 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.4 tagged_above=-999.0 required=7.0 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: 69a74e02bbee44ab4f8eafdbcedd94a1 I agree. Note that agreement just by EAP peer and server would not be sufficient. Authenticator's agreement by running SAP for proof of possession of a key that is generated by the peer and server and somehow bound to the chosen set of properties would be required. Otherwise, it seems possible for an attacker to sit between the peer and legitimate authenticator and do something wrong by spoofing some of the properties of the legitimate authenticator. Yoshihiro Ohba On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard Aboba wrote: > >Suggested text: > > > >"Channel Binding > > > >A secure mechanism for ensuring that a chosen set of > >channel properties (such as endpoint identifiers) are > >agreed upon by the EAP peer, authenticator and > >server." > > I'm ok with this. Any objections? > > > _________________________________________________________________ > 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 May 09 01:02:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKMb-00081i-Mf for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:02:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdKMa-0000xG-90 for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:02:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3E70A4300E4 for ; Mon, 8 May 2006 22:02:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EC85D430075 for ; Mon, 8 May 2006 22:02:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DAE1E1448005 for ; Mon, 8 May 2006 22:02:06 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 3819D144800B for ; Mon, 8 May 2006 22:02:02 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 22:02:02 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k49522Jq005927; Mon, 8 May 2006 22:02:02 -0700 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 k49522B9012590; Mon, 8 May 2006 22:02:02 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Mon, 8 May 2006 22:09:34 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906FF734A@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZy04dH2J2/uCO6Q7umfWOgLNZ2CwAURMgQ From: "Salowey, Joe" To: "Yoshihiro Ohba" DKIM-Signature: a=rsa-sha1; q=dns; l=1642; t=1147150922; x=1148014922; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Salowey,=20Joe=22=20 |Subject:RE=3A=20[eap]=20Re=3A=20Issue=20352=3A=20Channel=20Binding=20Issue; X=v=3Dcisco.com=3B=20h=3D2MPIhL2QgrHtBMQwUP5Ve8fh6kU=3D; b=aKQaZiDL+l6tsfLfRKkXzucqKj4/hg8C92hMAPHEP/6UkUJsJAh/tCbaJ4Te5/TDP4/6mbdr NnDgNsJ4icTqZYjOYr9cQ8EJ55gwdl0GLLRE49TOP0vPSJxGkR7PiKmX; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS 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 =20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Monday, May 08, 2006 12:06 PM > To: Salowey, Joe > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > On Mon, May 08, 2006 at 10:42:44AM -0700, Salowey, Joe wrote: > > =20 > >=20 > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > > > Sent: Monday, May 08, 2006 9:35 AM > > > To: Salowey, Joe > > > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > >=20 > > > On Mon, May 08, 2006 at 09:17:35AM -0700, Salowey, Joe wrote: > > > > > > [Joe] Obsoleted by what? > > > > >=20 > > > > > I'd say by CB with key mixing. > > > > >=20 > > > > [Joe] I don't agree. For one there are usages of EAP which=20 > > > do not use > > > > EAP keying material so key mixing will not work for them.=20 > > > >=20 > > >=20 > > > Can you elaborate on the usages you mentioned above? > > >=20 > > [Joe] 802.1x >=20 > If EAP keying material is not used for secure association at all, I > don't think CB is possible because an attacker authenticator can > simply spoof legitimate authenticator's parameters. This can happen > in the case of wired 802.1X as well. Am I wrong? >=20 [Joe] The same argument applies to peer entity authentication without ongoing data authentication. However this is still deployed and appears to be somewhat useful. I don't think this is the place to discuss the merits of 802.1x. =20 > Yoshihiro Ohba >=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 May 09 01:52:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdL9P-0003MU-DN for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:52:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdKvs-00033a-Be for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:38:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8C3644300C7 for ; Mon, 8 May 2006 22:38:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9BE46430075 for ; Mon, 8 May 2006 22:38:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8EF74398035 for ; Mon, 8 May 2006 22:38:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 825A1398015 for ; Mon, 8 May 2006 22:38:28 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 May 2006 22:38:28 -0700 X-IronPort-AV: i="4.05,103,1146466800"; d="scan'208"; a="273715408:sNHT36781116" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k495cSdM004151; Mon, 8 May 2006 22:38:28 -0700 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 k495cRB7011333; Mon, 8 May 2006 22:38:27 -0700 (PDT) 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] Re: issue 367: Key Scope and EAP Server Authorization Date: Mon, 8 May 2006 22:46:00 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906FF7352@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: issue 367: Key Scope and EAP Server Authorization Thread-Index: AcZxgOdODm2bWouGTWCE5GPcjZY6jQBpY2xQ From: "Salowey, Joe" To: "Bernard Aboba" , DKIM-Signature: a=rsa-sha1; q=dns; l=10612; t=1147153108; x=1148017108; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Salowey,=20Joe=22=20 |Subject:RE=3A=20[eap]=20Re=3A=20issue=20367=3A=20Key=20Scope=20and=20EAP=20Serve r=20Authorization; X=v=3Dcisco.com=3B=20h=3Dzlmj6/C5+isFzpHZD1ggB+hK1gc=3D; b=ROY0ctxWDYdL4dQeW0MZglwqjK+uS15CC/IMGGMzPijW1pYXKpck+pLzHD+2CS33mmAHOay3 gx2DP8pAI1oSJxGqI6Q0IHMU7/ruYedrKQ+xh6j4ZTRbRp6INOdqGsJF; Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS 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: f8184d7d4d1b986353eb58ea3e887935 =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Saturday, May 06, 2006 7:42 PM > To: eap@frascone.com > Subject: [eap] Re: issue 367: Key Scope and EAP Server Authorization >=20 > I think I see the point, which is that a given authenticator may be=20 > connected to > more than one EAP server, and that all authenticators in a single=20 > administrative > domain may not share the same EAP server. Also, EAP servers cannot=20 > necessarily > be assumed to share key state among each other. If the=20 > selcted EAP method=20 > does not > provide the Server-ID, then the peer cannot know the scope of=20 > the keys it > derives with the EAP server. >=20 [Joe] I'm not sure that a formal server-ID is required or sufficient. = The peer has a set of credentials that it uses to establish trust in a = server. It needs to know what the limits of that trust is. If the peer = wants to resume some state with an particular server then server-ID is = very useful, but I think that is a slightly different problem.=20 > This can create a number of issues, such as a peer attempting=20 > (but failing)=20 > a > fast reconnect because the server that the authenticator is=20 > configured to > communicate with is not the same one with which the peer=20 > established the > previous session. >=20 [Joe] Or one EAP server/Authenticator can attempt to spoof another.=20 > However, there are other situations in which the server=20 > identity is not=20 > material, > such as handoff in an 11r Mobility Domain (MD), where the STA=20 > only care=20 > whether > a candidate AP is in the same MD, not whether the new=20 > authenticator is=20 > configured > to talk to the same backend authentication server as the=20 > current or initial=20 > AP. >=20 [Joe] I'm not familiar with this scenario, is this based on a context = transfer from one AP to another? So in this case you are putting your = trust in one AP to only exchange data with another valid AP? > In practice, the peer determines whether an authenticator is=20 > within the=20 > scope > of authorization of the backend authentication server by=20 > attempting to=20 > complete > the SAP exchange with it. If the exchange succeeds, the=20 > authenticator is > authorized; if not, it isn't.=20 [Joe] Implicit in this statement is that the peer pefromed some = authorization of the authentication server.=20 > It is possible for the peer to attempt a > fast reconnect exchange with the wrong server; unless the=20 > server were to > include its identity in the EAP-Request there is no way for=20 > the peer to > determine what server it is talking to before the EAP method=20 > conversation > gets underway. Even if the authenticator were to advertise=20 > the server(s) > that it is configured to talk to, and even if those servers=20 > were identified > by their Server-IDs, it would not be possible for the peer to=20 > know a-priori > which server it was going to talk to, since the primary=20 > server can change=20 > due > to changes in network or server availability. >=20 [Joe] Sounds true > Given this, I'm not sure how the peer can verify that an=20 > authenticator is > allowed to be authorized by an EAP server. >=20 [Joe] This seems to me to be a rather serious system problem, since all = we know is the EAP server and our trust in the authenticator is based on = authorization from the EAP server. If we can't verify this then I'm not = sure why we are worried about channel bindings. If you don't now the = scope of the EAP server that is establishing trust then you don't know = whether the parameters are valid or not. =20 > The proposed resolution is as follows: >=20 > Change Section 2.2 to the following: >=20 > "2.2 Peer, Authenticator and Server Architecture >=20 > This specification does not impose constraints on the=20 > architecture of the > EAP authenticator, peer or server. Any of the authenticator=20 > architectures=20 > described > in [RFC4118] can be used. As a result, lower layers > need to identify EAP peers and authenticators unambiguously, without > incorporating implicit assumptions about > peer and authenticator architectures. >=20 > For example, it is possible for multiple base stations > and a "controller" (e.g. WLAN switch) to comprise a single EAP=20 > authenticator. > In such a situation, the "base station identity" is=20 > 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=20 > identity. > It should be understood that an EAP authenticator or peer: >=20 > [a] may contain one or more physical or logical ports; > [b] may advertise itself as one or more "virtual" > authenticators, peers or servers; > [c] may utilize multiple CPUs; > [d] may support clustering services for load balancing or failover. >=20 > Both the EAP peer and authenticator may have more than one=20 > physical or=20 > logical > port. A peer may simultaneously access the network via multiple > authenticators, or via multiple physical or logical ports on a given=20 > authenticator. > Similarly, an authenticator may offer network access to=20 > 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". >=20 > An authenticator may be configured to communicate with more than one > backend authentication server, each of which is configured to > communicate with a subset of the authenticators. > The situation is illustrated in Figure 3. > +-+-+-+-+ > | EAP | > | Peer | > +-+-+-+-+ > | | | Peer Ports > / | \\ > / | \\ > / | \\ > / | \\ > / | \\ > / | \\ > / | \\ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/ | = \\ > | | | | | | | | | Authenticator Ports > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > | | | | | | > | Auth1 | | Auth2 | | Auth3 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| | | | | = | > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > \\ | \ | > \\ | \ | > \\ | \ | > EAP over AAA \\ | \ | > (optional) \\ | \ | > \\ | \ | > \\ | \ | > \\ | \ | > +-+-+-+-+-+ +-+-+-+-+-+ Backend > | EAP | | EAP | Authentication > | Server1 | | Server2 | Servers > +-+-+-+-+-+ +-+-+-+-+-+ >=20 > Figure 3: Relationship between EAP peer, authenticator and server" >=20 > Add a new section 2.2.1 entitled "Server Identification": >=20 > "2.2.1 Server Identification >=20 > The EAP method conversation is between the EAP peer and server, as > identified by the Peer-Id and Server-Id. As shown in Figure 3, an=20 > authenticator > may be configured to communicate with multiple EAP servers;=20 > the server that=20 > a peer communicates > with may vary according to network and server availability. =20 > For example, in=20 > Figure 3, > Authenticator2 may be initially configured with EAP > server1 as its primary backend authentication server, and EAP server2 > as the backup, but if EAP server1 becomes unavailable, EAP server2 > may become the primary server. >=20 > As a result, prior to initiation of the EAP conversation, the=20 > peer may not=20 > be able to predict which > EAP server it will be communicating with. Fast reconnect, defined in=20 > [RFC3748] Section 7.2, may fail if the EAP server that the=20 > peer communicates=20 > with is not the same one with which > it initially established a security association. The peer may=20 > not be able to=20 > determine > the Server-Id prior to the start of the EAP method=20 > conversation, since the > Server-Id is not included in the EAP-Request/Identity, and may not be > advertised by the authenticator during the discovery phase." >=20 > -------------------------------------------------------------- > ------------------- > Issue 367: Key Scope and EAP Server Authorization > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: May 3, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04231.html > Document: KEYING-12 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 2.2.1 and 3.2 > Rationale/Explanation of issue: > Section 1.4.1 correctly defines the scope of the EAP keying=20 > material as > being defined by the EAP Peer and EAP server, however this=20 > relationship > is not carried out in other key scope discussions as far as I=20 > can tell. > In order for channel binding, key mixing etc. to work the=20 > peer must make > sure that the key is used not just within the authorized parameters of > the lower layer, but of the authorized scope of the EAP=20 > server as well. >=20 > I'm not sure of all of all the places where this needs to be=20 > addressed, > but I think it needs to be addressed in section 2.2.1 perhaps=20 > by adding >=20 > "[g] Verifying that the advertised scope is within the scope that the > EAP server is allowed to authorize" >=20 > Section 3.2 should probably state somewhere that: >=20 > "The peer should verify that the key scope advertised by the > authenticator is within the scope that is allowed to be authorized by > the EAP Server." >=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 May 09 01:56:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLCW-00040y-0m for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:56:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdLCT-0003yG-HO for eap-archive@lists.ietf.org; Tue, 09 May 2006 01:56:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 30FE14300F0 for ; Mon, 8 May 2006 22:56:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7C061430075 for ; Mon, 8 May 2006 22:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 664AF39803C for ; Mon, 8 May 2006 22:55:39 -0700 (PDT) Received: from qlink.queensu.ca (qlink.QueensU.CA [130.15.126.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id 44678398037 for ; Mon, 8 May 2006 22:55:34 -0700 (PDT) Received: from Queens (qlink-ppp122.tele.QueensU.CA [130.15.245.122]) by qlink.queensu.ca (8.12.10/8.12.10) with SMTP id k495tWgP012766 for ; Tue, 9 May 2006 01:55:33 -0400 (EDT) Message-ID: <000a01c67346$52af4140$e4e6fea9@Queens> From: "Hassan Ahmed" <3haea@qlink.queensu.ca> To: Date: Tue, 9 May 2006 01:55:23 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.028 tagged_above=-999 required=7 tests=HTML_60_70, HTML_MESSAGE X-Spam-Level: Subject: [eap] Hi all 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="===============1195400367==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. --===============1195400367== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C6730B.A2679650" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C6730B.A2679650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to simulate roaming in WLANs, and I am looking for some = information about 802.11r protocol. Please if anyone who has such information (draft or other doucments) and = can send it too me do so, because I am really in need of it.=20 Thanks for your help in advance. Hassan ------=_NextPart_000_0007_01C6730B.A2679650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to simulate roaming in = WLANs, and I am=20 looking for some information about 802.11r protocol.
Please if anyone who has such = information (draft or=20 other doucments) and can send it too me do so, because I am really in = need of=20 it.
 
Thanks for your help in = advance.
 
Hassan =  
------=_NextPart_000_0007_01C6730B.A2679650-- --===============1195400367== 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 --===============1195400367==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 09 03:58:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdN7K-0002Rv-Cy for eap-archive@lists.ietf.org; Tue, 09 May 2006 03:58:50 -0400 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 1FdN7K-00017l-Az for eap-archive@lists.ietf.org; Tue, 09 May 2006 03:58:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdN79-0003BS-KV for eap-archive@lists.ietf.org; Tue, 09 May 2006 03:58:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 48E72430115 for ; Tue, 9 May 2006 00:58:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA7E4430075 for ; Tue, 9 May 2006 00:58:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D20DD4306C8 for ; Tue, 9 May 2006 00:58:22 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 3E4B84306C6 for ; Tue, 9 May 2006 00:58:20 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k497wIsr013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 00:58:19 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-73-57.qualcomm.com [10.50.73.57]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k497wHVH029744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 00:58:18 -0700 (PDT) Message-Id: <6.2.5.6.2.20060509005650.058419e8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 May 2006 00:58:21 -0700 To: Yoshihiro Ohba , Bernard Aboba From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <20060509033943.GB29293@steelhead> References: <445F5324.9050801@piuha.net> <20060509033943.GB29293@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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.0 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 08:39 PM 5/8/2006, Yoshihiro Ohba wrote: >I agree. > >Note that agreement just by EAP peer and server would not be >sufficient. Authenticator's agreement by running SAP for proof of >possession of a key that is generated by the peer and server and >somehow bound to the chosen set of properties would be required. >Otherwise, it seems possible for an attacker to sit between the peer >and legitimate authenticator and do something wrong by spoofing some >of the properties of the legitimate authenticator. How? The attacker won't have the key (MSK) to do something like that. Perhaps you might explain the attack in detail. Thanks. regards, Lakshminath >Yoshihiro Ohba > > > >On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard Aboba wrote: > > >Suggested text: > > > > > >"Channel Binding > > > > > >A secure mechanism for ensuring that a chosen set of > > >channel properties (such as endpoint identifiers) are > > >agreed upon by the EAP peer, authenticator and > > >server." > > > > I'm ok with this. Any objections? > > > > > > _________________________________________________________________ > > 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 Tue May 09 04:01:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNA9-000359-Mg for eap-archive@lists.ietf.org; Tue, 09 May 2006 04:01:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdNA8-0001FL-AK for eap-archive@lists.ietf.org; Tue, 09 May 2006 04:01:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CCAD04300D7 for ; Tue, 9 May 2006 01:01:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 09065430075 for ; Tue, 9 May 2006 01:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D695D4306CB for ; Tue, 9 May 2006 01:01:31 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 49C074306D8 for ; Tue, 9 May 2006 01:01:29 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4981SPe001781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 01:01:28 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-73-57.qualcomm.com [10.50.73.57]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4981QEo008203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 01:01:27 -0700 (PDT) Message-Id: <6.2.5.6.2.20060509005952.05841610@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 May 2006 01:01:28 -0700 To: "Bernard Aboba" , jari.arkko@piuha.net From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: References: <445F5324.9050801@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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 At 06:39 PM 5/8/2006, Bernard Aboba wrote: >>Suggested text: >> >>"Channel Binding >> >>A secure mechanism for ensuring that a chosen set of >>channel properties (such as endpoint identifiers) are >>agreed upon by the EAP peer, authenticator and >>server." > >I'm ok with this. Any objections? I am not sure about the authenticator involvement, have asked Jari that question and awaiting response. It's about the EAP server and peer agreeing about the authenticator's identity and perhaps other things about the authenticator, no? regards, Lakshminath >_________________________________________________________________ >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 May 09 06:46:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdPji-0001Eq-G2 for eap-archive@lists.ietf.org; Tue, 09 May 2006 06:46:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdPjg-00011q-3T for eap-archive@lists.ietf.org; Tue, 09 May 2006 06:46:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 14CCE430106 for ; Tue, 9 May 2006 03:46:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 40A46430054 for ; Tue, 9 May 2006 03:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2E06439800F for ; Tue, 9 May 2006 03:46:07 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33A2539800E for ; Tue, 9 May 2006 03:46:02 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA0C2898D8; Tue, 9 May 2006 13:45:58 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 511CA898D7; Tue, 9 May 2006 13:45:55 +0300 (EEST) Message-ID: <44607320.4040301@piuha.net> Date: Tue, 09 May 2006 13:46:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" , Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@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: c1c65599517f9ac32519d043c37c5336 Hi Vidya, Laksminath, Vidya you wrote: >>Suggested text: >> >>"Channel Binding >> >>A secure mechanism for ensuring that a chosen set of channel >>properties (such as endpoint identifiers) are agreed upon by >>the EAP peer, authenticator and server." >> >>Vidya: note that the "chosen set" may be different in >>different situations, depending on what information is available. >> >> >> > >Agree with the chosen set part. But, what is the authenticator agreeing >to? Isn't it just an agreement about the authenticator between the peer >and server? > > And you Laksminath wrote: > This is confusing to me. I was under the assumption that the peer and > the server should agree that they have the same view of the > authenticator (perhaps with the provision that the server may have a > superset of the information than the peer has). What does the > authenticator need to agree on? Does it matter? Good questions. I'd be happy to restrict the definition to peer and server agreeing that they have the same view of the channel properties claimed by the authenticator. (But part of the distinction may also be in the specific implementation of the "agreement"; what we are looking for is that the values agree, without specifying who sends the values and who verifies them.) --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 May 09 08:35:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdRRT-0008CJ-5r for eap-archive@lists.ietf.org; Tue, 09 May 2006 08:35:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdRRQ-0006Xc-La for eap-archive@lists.ietf.org; Tue, 09 May 2006 08:35:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9B066430103 for ; Tue, 9 May 2006 05:35:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A00D543004F for ; Tue, 9 May 2006 05:35:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 818CB430D16 for ; Tue, 9 May 2006 05:35:33 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 3235D430D1A for ; Tue, 9 May 2006 05:35:28 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k49CZQf6022657; Tue, 9 May 2006 21:35:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k49CZR0v018394; Tue, 9 May 2006 21:35:27 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id XAA18361; Tue, 9 May 2006 21:35:27 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k49CZPg7005081; Tue, 9 May 2006 21:35:25 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49CZP0N019113; Tue, 9 May 2006 21:35:25 +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 <0IZ000KIE0AWYC30@mail.po.toshiba.co.jp>; Tue, 09 May 2006 21:35:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdRQO-0000ej-Gf; Tue, 09 May 2006 05:34:48 -0700 Date: Tue, 09 May 2006 08:34:48 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <6.2.5.6.2.20060509005650.058419e8@qualcomm.com> To: Lakshminath Dondeti Message-id: <20060509123448.GA2352@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <445F5324.9050801@piuha.net> <20060509033943.GB29293@steelhead> <6.2.5.6.2.20060509005650.058419e8@qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: 244a2fd369eaf00ce6820a760a3de2e8 On Tue, May 09, 2006 at 12:58:21AM -0700, Lakshminath Dondeti wrote: > At 08:39 PM 5/8/2006, Yoshihiro Ohba wrote: > >I agree. > > > >Note that agreement just by EAP peer and server would not be > >sufficient. Authenticator's agreement by running SAP for proof of > >possession of a key that is generated by the peer and server and > >somehow bound to the chosen set of properties would be required. > >Otherwise, it seems possible for an attacker to sit between the peer > >and legitimate authenticator and do something wrong by spoofing some > >of the properties of the legitimate authenticator. > > How? The attacker won't have the key (MSK) to do something like > that. Perhaps you might explain the attack in detail. Thanks. In case there is no SAP between the peer and authenticator (e.g., wired 802.1X), the attacker does not need to have the key. In that case, agreement just by EAP peer and server is useless. What I'd like to mention is that Channel Binding makes sense only if keying meterial exported by an EAP method is used by SAP. Yoshihiro Ohba > > regards, > Lakshminath > > > >Yoshihiro Ohba > > > > > > > >On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard Aboba wrote: > >> >Suggested text: > >> > > >> >"Channel Binding > >> > > >> >A secure mechanism for ensuring that a chosen set of > >> >channel properties (such as endpoint identifiers) are > >> >agreed upon by the EAP peer, authenticator and > >> >server." > >> > >> I'm ok with this. Any objections? > >> > >> > >> _________________________________________________________________ > >> 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 Tue May 09 08:55:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdRkg-0000W7-O4 for eap-archive@lists.ietf.org; Tue, 09 May 2006 08:55:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdRkd-0007KQ-AQ for eap-archive@lists.ietf.org; Tue, 09 May 2006 08:55:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 005EB430063 for ; Tue, 9 May 2006 05:55:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 018E243004F for ; Tue, 9 May 2006 05:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CE47639803A for ; Tue, 9 May 2006 05:55:26 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id B383639800E for ; Tue, 9 May 2006 05:55:22 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k49CtKbf027121; Tue, 9 May 2006 21:55:20 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k49CtLNM019689; Tue, 9 May 2006 21:55:21 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id XAA19656; Tue, 9 May 2006 21:55:21 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k49CtJ8f015331; Tue, 9 May 2006 21:55:19 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49CtJsY029973; Tue, 9 May 2006 21:55:19 +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 <0IZ000K02182YC40@mail.po.toshiba.co.jp>; Tue, 09 May 2006 21:55:19 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdRjr-0000i8-4L; Tue, 09 May 2006 05:54:55 -0700 Date: Tue, 09 May 2006 08:54:55 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906FF734A@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060509125455.GB2352@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906FF734A@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: 93238566e09e6e262849b4f805833007 On Mon, May 08, 2006 at 10:09:34PM -0700, Salowey, Joe wrote: > > > > If EAP keying material is not used for secure association at all, I > > don't think CB is possible because an attacker authenticator can > > simply spoof legitimate authenticator's parameters. This can happen > > in the case of wired 802.1X as well. Am I wrong? > > > [Joe] The same argument applies to peer entity authentication without > ongoing data authentication. However this is still deployed and appears > to be somewhat useful. I don't think this is the place to discuss the > merits of 802.1x. Perhaps you miss my point. I did not discuss the merit of 802.1X. My point is that having a Channel Binding solution for lower layers that do not use cryptographic per-packet acess control does not really make sense to me. Yoshihiro Ohba _________________________________________________________________ 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 May 09 10:03:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSoR-0000hB-U8 for eap-archive@lists.ietf.org; Tue, 09 May 2006 10:03:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdSoP-0002IC-G6 for eap-archive@lists.ietf.org; Tue, 09 May 2006 10:03:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6D4F94300F2 for ; Tue, 9 May 2006 07:03:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DA4A9430063 for ; Tue, 9 May 2006 07:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4212E39800E for ; Tue, 9 May 2006 07:03:12 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 750E139801B for ; Tue, 9 May 2006 07:03:05 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k49E33wx011775; Tue, 9 May 2006 23:03:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k49E34hi018516; Tue, 9 May 2006 23:03:04 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id ZAA18481; Tue, 9 May 2006 23:03:04 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k49E33YG017461; Tue, 9 May 2006 23:03:03 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49E3216025679; Tue, 9 May 2006 23:03:02 +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 <0IZ000KQC4CXYD50@mail.po.toshiba.co.jp>; Tue, 09 May 2006 23:03:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdSnT-0000x2-BC; Tue, 09 May 2006 07:02:43 -0700 Date: Tue, 09 May 2006 10:02:43 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <44607320.4040301@piuha.net> To: Jari Arkko Message-id: <20060509140242.GC2352@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> <44607320.4040301@piuha.net> User-Agent: Mutt/1.5.11+cvs20060403 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Tue, May 09, 2006 at 01:46:56PM +0300, Jari Arkko wrote: > And you Laksminath wrote: > > > This is confusing to me. I was under the assumption that the peer and > > the server should agree that they have the same view of the > > authenticator (perhaps with the provision that the server may have a > > superset of the information than the peer has). What does the > > authenticator need to agree on? Does it matter? > > Good questions. I'd be happy to restrict the definition > to peer and server agreeing that they have the same > view of the channel properties claimed by the authenticator. If the definition is only for agreement between the peer and server, then it means we are allowing Channel Binding without running a SAP. I think involvement of the authenticator's agreement via SAP is needed. I mean the authenticator needs to agree that, the authenticator, not someone else, has sent the information to the peer. Yoshihiro Ohba _________________________________________________________________ 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 May 09 10:58:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdTfp-0007BE-P7 for eap-archive@lists.ietf.org; Tue, 09 May 2006 10:58:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdTfm-000584-8b for eap-archive@lists.ietf.org; Tue, 09 May 2006 10:58:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 877CA430119 for ; Tue, 9 May 2006 07:58:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 53383430063 for ; Tue, 9 May 2006 07:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 12456398047 for ; Tue, 9 May 2006 07:58:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0F769398015 for ; Tue, 9 May 2006 07:58:30 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 May 2006 07:58:29 -0700 X-IronPort-AV: i="4.05,106,1146466800"; d="scan'208"; a="273904728:sNHT32699412" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k49EwTf2024590; Tue, 9 May 2006 07:58:29 -0700 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 k49EwTB7019563; Tue, 9 May 2006 07:58:29 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Tue, 9 May 2006 08:06:01 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906FF7371@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZzaORzT/xyunWaTZue0kFZLgxkZwAD8JpQ From: "Salowey, Joe" To: "Yoshihiro Ohba" DKIM-Signature: a=rsa-sha1; q=dns; l=1361; t=1147186709; x=1148050709; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Salowey,=20Joe=22=20 |Subject:RE=3A=20[eap]=20Re=3A=20Issue=20352=3A=20Channel=20Binding=20Issue; X=v=3Dcisco.com=3B=20h=3D2MPIhL2QgrHtBMQwUP5Ve8fh6kU=3D; b=JIftQH2X9DNv/eLV4CK2aQjCOFw8EC+WWHYFatQzONXR0GR3k9TV6GVoeZLYeqWZ/i5rp8r5 FMdkm6qa5NROoe8bQb+MLTcYrw6KRwI2SGjBMMiNxf8nVWgxOJ3Ab1d3; Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS 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: 9ed51c9d1356100bce94f1ae4ec616a9 =20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Tuesday, May 09, 2006 5:55 AM > To: Salowey, Joe > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue >=20 > On Mon, May 08, 2006 at 10:09:34PM -0700, Salowey, Joe wrote: > > >=20 > > > If EAP keying material is not used for secure association=20 > at all, I > > > don't think CB is possible because an attacker authenticator can > > > simply spoof legitimate authenticator's parameters. This=20 > can happen > > > in the case of wired 802.1X as well. Am I wrong? > > >=20 > > [Joe] The same argument applies to peer entity=20 > authentication without > > ongoing data authentication. However this is still=20 > deployed and appears > > to be somewhat useful. I don't think this is the place to=20 > discuss the > > merits of 802.1x. =20 >=20 > Perhaps you miss my point. I did not discuss the merit of 802.1X. My > point is that having a Channel Binding solution for lower layers that > do not use cryptographic per-packet acess control does not=20 > really make=20 > sense to me. >=20 [Joe] Perhaps, my point is that channel bindings are a useful as authentication with regard to the lack of per-packet cryptographic protection. =20 > Yoshihiro Ohba >=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 May 09 11:41:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUL5-00071e-DE for eap-archive@lists.ietf.org; Tue, 09 May 2006 11:41:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUL2-00072W-SZ for eap-archive@lists.ietf.org; Tue, 09 May 2006 11:41:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 39FE54300FF for ; Tue, 9 May 2006 08:41:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CF085430073 for ; Tue, 9 May 2006 08:41:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C02E5398049 for ; Tue, 9 May 2006 08:41:07 -0700 (PDT) Received: from hotmail.com (bay106-f33.bay106.hotmail.com [65.54.161.43]) by zoidberg.tigertech.net (Postfix) with ESMTP id 15D76398015 for ; Tue, 9 May 2006 08:41:05 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 May 2006 08:41:04 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 09 May 2006 15:41:01 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <7210B31550AC934A8637D6619739CE6906FF7352@e2k-sea-xch2.sea-alpha.cisco.com> From: "Bernard Aboba" To: jsalowey@cisco.com, eap@frascone.com Subject: RE: [eap] Re: issue 367: Key Scope and EAP Server Authorization Date: Tue, 09 May 2006 08:41:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 May 2006 15:41:04.0779 (UTC) FILETIME=[FB6AC5B0:01C6737E] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS 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: 92df29fa99cf13e554b84c8374345c17 >[Joe] I'm not sure that a formal server-ID is required or sufficient. The >peer has a set of credentials that it uses to establish trust in a server. >It needs to know what the limits of that trust is. If the peer wants to >resume some state with an particular server then server-ID is very useful, >but I think that is a slightly different problem. [Bernard] The NAI allows the peer to request authentication within a given realm. The assumption is that any EAP server in that realm will have access to the credentials necessary to authenticate the peer. However, the peer cannot necessarily assume that the EAP servers share a cache of method-specific keying material. This is where things get tricky. >[Joe] Or one EAP server/Authenticator can attempt to spoof another. If the EAP method doesn't support authentication of the server claim of identity, then even if the method supports mutual authentication, the peer is only verifying that the EAP server has access to the credentials, it is not authenticating the server itself. For example, in EAP-TLS, TTLS, PEAP, etc. the server identity can be validated by the peer; in EAP-SIM and EAP-AKA it cannot be. One question this brings up is whether a method that doesn't support server certificates can validate the server identity. >[Joe] I'm not familiar with this scenario, is this based on a context >transfer from one AP to another? So in this case you are putting your >trust in one AP to only exchange data with another valid AP? 11r allows the authenticators derive cryptographically independent keys (PMK-R1s) from the MSK. So it is not context transfer, which would mean that all authenticators use the same key to derive TSKs. In 11r the trust model is between a new authenticator and the "initiall" authenticator. Compromise of the "initial" authenticator leads to compromise of all peer sessions that originated at that authenticator. However, it does not necessarily compromise sessions which did not originate at the compromised authenticator, due to the crytographic separation built into the key hierarchy. >[Joe] Implicit in this statement is that the peer pefromed some >authorization of the authentication server. The peer can only do that if it authenticates the server, right? For example, in EAP-TLS or PEAP the peer can perform authorization of the EAP server. > > Given this, I'm not sure how the peer can verify that an > > authenticator is allowed to be authorized by an EAP server. > > >[Joe] This seems to me to be a rather serious system problem, since all we >know is the EAP server and our trust in the authenticator is based on >authorization from the EAP server. If we can't verify this then I'm not >sure why we are worried about channel bindings. If you don't now the scope >of the EAP server that is establishing trust then you don't know whether >the parameters are valid or not. I think that the peer has to trust that the backend authenticator server will not send a key to an unauthorized authenticator. This implies that either the backend authentication server either checks that the Request attributes make sense (NAS-Identifier, Called-Station-Id, etc.) or that the local proxy does it if one is present. You are correct that if the EAP server does not check the authorization of the authenticator, then Channel Bindings provide little value; the authenticator can provide the same mis-information to the peer and backend server, and it will be believed. _________________________________________________________________ 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 May 09 12:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdV7S-0003Pp-GC for eap-archive@lists.ietf.org; Tue, 09 May 2006 12:31:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdV7R-0001fE-1q for eap-archive@lists.ietf.org; Tue, 09 May 2006 12:31:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 62DCE430116 for ; Tue, 9 May 2006 09:31:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8947B4300C0 for ; Tue, 9 May 2006 09:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2A9541448014 for ; Tue, 9 May 2006 09:31:05 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 571DC144800E for ; Tue, 9 May 2006 09:31:01 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49GUwGK009656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 09:30:59 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49GUsZ1000660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 09:30:57 -0700 (PDT) Message-Id: <6.2.5.6.2.20060509092640.054c42a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 May 2006 09:30:52 -0700 To: Yoshihiro Ohba , Jari Arkko From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <20060509140242.GC2352@steelhead> References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> <44607320.4040301@piuha.net> <20060509140242.GC2352@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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 At 07:02 AM 5/9/2006, Yoshihiro Ohba wrote: >On Tue, May 09, 2006 at 01:46:56PM +0300, Jari Arkko wrote: > > And you Laksminath wrote: > > > > > This is confusing to me. I was under the assumption that the peer and > > > the server should agree that they have the same view of the > > > authenticator (perhaps with the provision that the server may have a > > > superset of the information than the peer has). What does the > > > authenticator need to agree on? Does it matter? > > > > Good questions. I'd be happy to restrict the definition > > to peer and server agreeing that they have the same > > view of the channel properties claimed by the authenticator. > >If the definition is only for agreement between the peer and server, >then it means we are allowing Channel Binding without running a SAP. >I think involvement of the authenticator's agreement via SAP is >needed. I mean the authenticator needs to agree that, the >authenticator, not someone else, has sent the information to the peer. Hmmm, let's see. The peer and the server agree, let's say through the EAP method, that they are talking to the same authenticator and the server sends the MSK (or for that matter, as Joe seems to imply, port open indication) to *that* authenticator. So, I don't see why the authenticator needs any more verification. Now without the SAP there are other problems, but they don't seem relevant to CB. Perhaps I am missing something (you seem like you've explored this area quite a bit, please explain. Thanks). regards, Lakshminath >Yoshihiro Ohba _________________________________________________________________ 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 May 09 12:37:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVCu-0000Yy-B2 for eap-archive@lists.ietf.org; Tue, 09 May 2006 12:37:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdVCr-0001rR-OR for eap-archive@lists.ietf.org; Tue, 09 May 2006 12:37:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BEC7F430116 for ; Tue, 9 May 2006 09:37:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 47C584300B7 for ; Tue, 9 May 2006 09:36:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DFF27398048 for ; Tue, 9 May 2006 09:36:48 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E5AF398044 for ; Tue, 9 May 2006 09:36:45 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k49GagCN028662; Wed, 10 May 2006 01:36:42 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k49Gbsha007182; Wed, 10 May 2006 01:37:54 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id BAA07162; Wed, 10 May 2006 01:37:53 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k49GadTM009866; Wed, 10 May 2006 01:36:39 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49GadHB009483; Wed, 10 May 2006 01:36:39 +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 <0IZ000KZ6BGXYD70@mail.po.toshiba.co.jp>; Wed, 10 May 2006 01:36:39 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdVCF-0001PE-9f; Tue, 09 May 2006 09:36:27 -0700 Date: Tue, 09 May 2006 12:36:27 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: Issue 352: Channel Binding Issue In-reply-to: <7210B31550AC934A8637D6619739CE6906FF7371@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20060509163627.GG2352@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7210B31550AC934A8637D6619739CE6906FF7371@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 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: 8b431ad66d60be2d47c7bfeb879db82c On Tue, May 09, 2006 at 08:06:01AM -0700, Salowey, Joe wrote: > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Tuesday, May 09, 2006 5:55 AM > > To: Salowey, Joe > > Cc: Yoshihiro Ohba; Bernard Aboba; eap@frascone.com > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue > > > > On Mon, May 08, 2006 at 10:09:34PM -0700, Salowey, Joe wrote: > > > > > > > > If EAP keying material is not used for secure association > > at all, I > > > > don't think CB is possible because an attacker authenticator can > > > > simply spoof legitimate authenticator's parameters. This > > can happen > > > > in the case of wired 802.1X as well. Am I wrong? > > > > > > > [Joe] The same argument applies to peer entity > > authentication without > > > ongoing data authentication. However this is still > > deployed and appears > > > to be somewhat useful. I don't think this is the place to > > discuss the > > > merits of 802.1x. > > > > Perhaps you miss my point. I did not discuss the merit of 802.1X. My > > point is that having a Channel Binding solution for lower layers that > > do not use cryptographic per-packet acess control does not > > really make > > sense to me. > > > [Joe] Perhaps, my point is that channel bindings are a useful as > authentication with regard to the lack of per-packet cryptographic > protection. I see your point. However, even in that case some sort of SAP with the use of keying material exported by EAP method would be needed to verify the Channel Binding data between the peer and authenticator. Note that PANA can do this verification based on integrity protected PBR/PBA exchange. Anyways, I think agreement just between the peer and server is not sufficient for Channel Binding, as I mentioned in other thread. Yoshihiro Ohba _________________________________________________________________ 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 May 09 13:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdW6A-0007TU-Sy for eap-archive@lists.ietf.org; Tue, 09 May 2006 13:34:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdW68-0003km-9y for eap-archive@lists.ietf.org; Tue, 09 May 2006 13:34:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2F7B8430115 for ; Tue, 9 May 2006 10:34:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6D9384300A9 for ; Tue, 9 May 2006 10:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A961398030 for ; Tue, 9 May 2006 10:33:54 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6306839801B for ; Tue, 9 May 2006 10:33:51 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49HXn30031347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 10:33:50 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49HXlxc013921; Tue, 9 May 2006 10:33:48 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 10:33:37 -0700 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: Issue 362: Lower layer parameters and EMSK text Date: Tue, 9 May 2006 10:33:35 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F499@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 362: Lower layer parameters and EMSK text Thread-Index: AcZyrF8seC9e51/PShmJCEuTaX+o8AA4Kqzg From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 09 May 2006 17:33:37.0080 (UTC) FILETIME=[B41A2380:01C6738E] 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: 22bbb45ef41b733eb2d03ee71ece8243 >=20 > Move the following text from Section 2 to Section 1.4: >=20 > "The EMSK MUST NOT be provided to an entity outside the EAP=20 > server or peer, nor is it permitted to pass any quantity to=20 > an entity outside the EAP server or peer from which the EMSK=20 > could be computed without breaking some cryptographic=20 > assumption, such as inverting a one-way function. As noted in=20 > [RFC3748] Section 7.10: >=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." >=20 Are we sticking to this rule that the EMSK MUST NOT be used to derive any other keys? Given that there is agreement in general about potential derivation of keys from the EMSK, what implications does this text have to future documents specifying derived keys from the EMSK?=20 > Change the last four paragraphs of Section 2 to the following: >=20 > " In order to preserve the security of keys derived within=20 > EAP methods, lower layers MUST NOT export keys passed down by=20 > EAP methods. This implies that EAP keying material passed=20 > down to a lower layer is for the exclusive use of that lower=20 > layer and MUST NOT be used within another lower layer. This=20 > prevents compromise of one lower layer from compromising=20 > other applications using EAP keying parameters. >=20 > EAP keying material provided to a lower layer MUST NOT be=20 > transported to another entity. For example, EAP keying=20 > material passed down to the EAP peer lower layer MUST NOT=20 > leave the peer; EAP keying material passed down or=20 > transported to the EAP authenticator lower layer MUST NOT=20 > leave the authenticator. >=20 > On the EAP server, keying material and parameters requested=20 > by and passed down to the AAA layer may be replicated to the=20 > AAA layer on the authenticator.=20 I understand what the above is trying to say - however, this does conflict with the fact that the EMSK MUST NOT be transported to the authenticator (even though it may be passed down to the AAA layer on the server). I wonder if some clarification is necessary to avoid confusion. > On the authenticator, the AAA=20 > layer provides the replicated keying material and parameters=20 > to the lower layer over which the EAP authentication=20 > conversation took place. This enables "mode independence" to=20 > be maintained. >=20 > The EAP layer as well as the peer and authenticator layers=20 > MUST NOT modify or cache keying material or parameters=20 > (including Channel > Bindings) passing in either direction between the EAP method=20 > layer and the lower layer or AAA layer." >=20 The above works for the MSK, but may not work for the EMSK - as we flush out the usage for EMSK, we may find that caching may need to be allowed. So, a MUST NOT seems too strong - MUST NOT modify makes sense; whereas, SHOULD NOT cache keying material may be more appropriate.=20 Regards, Vidya > -------------------------------------------------------------- > ----------------------- > Issue 362: Lower layer parameters and EMSK text Submitter=20 > name: Joe Salowey Submitter email address: jsalowey@cisco.com=20 > Date Submitted: May 2, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04247.html > Document: KEYING-12 > Comment type: 'E'ditorial > Priority: '1' Should fix > Section: 2 > Rationale/Explanation of issue: >=20 > 1. Passing of parameters to lower layer. It seems that there=20 > may be some parameters passed to lower layers that could be=20 > usable elsewhere. > For example the Session-ID might be usable. If the=20 > session-id is included in parameters then I think the =20 > following may be to > restrictive: >=20 > "This > implies that EAP keying material or parameters passed down=20 > to a lower > layer are for the exclusive use of that lower layer and MUST NOT be > used within another lower layer" >=20 > Suggested change: >=20 > "This implies that EAP keying material passed down to a lower=20 > layer are for the exclusive use of that lower layer and MUST=20 > NOT be used within another lower layer." >=20 > If this change is accepted there are several other places in=20 > the section where this should be changed. >=20 > 2. EMSK text >=20 > The First paragraph still mentions exporting the EMSK to the=20 > lower layer which seems to be problematic when considered=20 > with the rest of the text of this section. I don't think the=20 > EMSK should be discussed in the lower layer section. >=20 > My suggestion would be to remove references to the EMSK in=20 > this section and move the paragraph discussing the EMSK to=20 > Section 1.4 EAP Key hierarchy. >=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 May 09 15:01:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXSf-0003AF-QW for eap-archive@lists.ietf.org; Tue, 09 May 2006 15:01:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXSe-0007mJ-B2 for eap-archive@lists.ietf.org; Tue, 09 May 2006 15:01:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0F26C430108 for ; Tue, 9 May 2006 12:01:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E947A430073 for ; Tue, 9 May 2006 12:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C42991448012 for ; Tue, 9 May 2006 12:00:59 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 5B4AF144800E for ; Tue, 9 May 2006 12:00:54 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k49J0rTq027068; Wed, 10 May 2006 04:00:53 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k49J0srA029819; Wed, 10 May 2006 04:00:54 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id EAA29799; Wed, 10 May 2006 04:00:54 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k49J0qdF000051; Wed, 10 May 2006 04:00:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49J0qr7021604; Wed, 10 May 2006 04:00:52 +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 <0IZ000KU3I5BYD90@mail.po.toshiba.co.jp>; Wed, 10 May 2006 04:00:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdXRl-0001o5-CA; Tue, 09 May 2006 12:00:37 -0700 Date: Tue, 09 May 2006 15:00:37 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <6.2.5.6.2.20060509092640.054c42a8@qualcomm.com> To: Lakshminath Dondeti Message-id: <20060509190037.GH2352@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> <44607320.4040301@piuha.net> <20060509140242.GC2352@steelhead> <6.2.5.6.2.20060509092640.054c42a8@qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 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: b4a0a5f5992e2a4954405484e7717d8c On Tue, May 09, 2006 at 09:30:52AM -0700, Lakshminath Dondeti wrote: > At 07:02 AM 5/9/2006, Yoshihiro Ohba wrote: > >On Tue, May 09, 2006 at 01:46:56PM +0300, Jari Arkko wrote: > >> And you Laksminath wrote: > >> > >> > This is confusing to me. I was under the assumption that the peer and > >> > the server should agree that they have the same view of the > >> > authenticator (perhaps with the provision that the server may have a > >> > superset of the information than the peer has). What does the > >> > authenticator need to agree on? Does it matter? > >> > >> Good questions. I'd be happy to restrict the definition > >> to peer and server agreeing that they have the same > >> view of the channel properties claimed by the authenticator. > > > >If the definition is only for agreement between the peer and server, > >then it means we are allowing Channel Binding without running a SAP. > >I think involvement of the authenticator's agreement via SAP is > >needed. I mean the authenticator needs to agree that, the > >authenticator, not someone else, has sent the information to the peer. > > Hmmm, let's see. The peer and the server agree, let's say through the > EAP method, that they are talking to the same authenticator and the > server sends the MSK (or for that matter, as Joe seems to imply, port > open indication) to *that* authenticator. So, I don't see why the > authenticator needs any more verification. The problem here is that the authenticator that advertised the information may not be the one that receives the MSK. > > Now without the SAP there are other problems, but they don't seem > relevant to CB. Perhaps I am missing something (you seem like you've > explored this area quite a bit, please explain. Thanks). Please see an example below. [Peer]---[AA]---[LA]---[Server] | | | | EAP method | | |<------------------>| | |MSK | | |<---| An attacker authenticator (AA) is acting as an authenticator for the peer and and as a peer for the legitimate authenticator (LA), passing through EAP messages between the peer and LA. Both AA and LA advertise the same LA's information XYZ. The peer learns XYZ from AA. The server have the XYZ for LA. Server sends MSK to LA after creating binding between XYZ and MSK by some means (i.e., key mixing or data transfer). If we stop here, the peer will think that AA has the MSK, which is not true. This looks like an open binding which might open up some vulnerability to MiTM attack. An additional verification, SAP, is needed to close the binding by verifying proof of possession of the MSK between the peer and authenticator. Regards, Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From qwaqzxug920@saix.net Tue May 09 15:22:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXnE-0006K7-6N for eap-archive@ietf.org; Tue, 09 May 2006 15:22:48 -0400 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 1FdXnE-0008RD-54 for eap-archive@ietf.org; Tue, 09 May 2006 15:22:48 -0400 Received: from dsl-145-96-88.telkomadsl.co.za ([165.145.96.88] helo=saix.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FdXnC-0002Gx-Cc for eap-archive@ietf.org; Tue, 09 May 2006 15:22:48 -0400 Received: from 198.54.202.195 by saix.net (Sendmail 8.7.5) with ESMTP (SSL) id IYT14005 for ; Tue, 09 May 2006 21:22:08 +0200 Message-ID: Date: Tue, 09 May 2006 21:22:08 +0200 From: "dbcih" To: Subject: Low-Profile Company With High Profit Potential [D E T A I L S Tuesday Contd it is] Istvan brouhaha Content-return: allowed X-Mailer: PVCMail 7.549 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-IP: 198.54.202.195 X-Spam-Score: 0.7 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 GAPJ- GOLDEN APPLE OIL/GAS Keep an Eye on this one This weeks Pick, Company already has solid potential Current Price: $ 0.55 5 Day Projected : $ 1.00 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 terms of the deal provide for Franklin Ross to purchase 181,818 shares of Golden Apple Oil and Gas, Inc. restricted stock priced at 10 per share. 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. This looks very lucrative in coming weeks, Get GAPJ First Thing TODAY Get In Now don't regret later From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 09 16:47:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZ7X-0006Uj-Ct for eap-archive@lists.ietf.org; Tue, 09 May 2006 16:47:51 -0400 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 1FdZ7X-0005Rw-BQ for eap-archive@lists.ietf.org; Tue, 09 May 2006 16:47:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdYzm-0003p1-Ek for eap-archive@lists.ietf.org; Tue, 09 May 2006 16:39:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 43914430073 for ; Tue, 9 May 2006 13:39:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EB66C430063 for ; Tue, 9 May 2006 13:39:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D3FDC1448013 for ; Tue, 9 May 2006 13:39:35 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 378F41448012 for ; Tue, 9 May 2006 13:39:31 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49KdSrT008634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 13:39:29 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-122.qualcomm.com [10.50.64.122]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49KdJE7011693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 13:39:21 -0700 (PDT) Message-Id: <6.2.5.6.2.20060509124202.059a5420@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 May 2006 13:39:28 -0700 To: Yoshihiro Ohba From: Lakshminath Dondeti Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-Reply-To: <20060509190037.GH2352@steelhead> References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> <44607320.4040301@piuha.net> <20060509140242.GC2352@steelhead> <6.2.5.6.2.20060509092640.054c42a8@qualcomm.com> <20060509190037.GH2352@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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.0 tagged_above=-999.0 required=7.0 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.2 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac At 12:00 PM 5/9/2006, Yoshihiro Ohba wrote: >On Tue, May 09, 2006 at 09:30:52AM -0700, Lakshminath Dondeti wrote: > > At 07:02 AM 5/9/2006, Yoshihiro Ohba wrote: > > >On Tue, May 09, 2006 at 01:46:56PM +0300, Jari Arkko wrote: > > >> And you Laksminath wrote: > > >> > > >> > This is confusing to me. I was under the assumption that the peer and > > >> > the server should agree that they have the same view of the > > >> > authenticator (perhaps with the provision that the server may have a > > >> > superset of the information than the peer has). What does the > > >> > authenticator need to agree on? Does it matter? > > >> > > >> Good questions. I'd be happy to restrict the definition > > >> to peer and server agreeing that they have the same > > >> view of the channel properties claimed by the authenticator. > > > > > >If the definition is only for agreement between the peer and server, > > >then it means we are allowing Channel Binding without running a SAP. > > >I think involvement of the authenticator's agreement via SAP is > > >needed. I mean the authenticator needs to agree that, the > > >authenticator, not someone else, has sent the information to the peer. > > > > Hmmm, let's see. The peer and the server agree, let's say through the > > EAP method, that they are talking to the same authenticator and the > > server sends the MSK (or for that matter, as Joe seems to imply, port > > open indication) to *that* authenticator. So, I don't see why the > > authenticator needs any more verification. > >The problem here is that the authenticator that advertised the >information may not be the one that receives the MSK. > > > > > Now without the SAP there are other problems, but they don't seem > > relevant to CB. Perhaps I am missing something (you seem like you've > > explored this area quite a bit, please explain. Thanks). > >Please see an example below. > >[Peer]---[AA]---[LA]---[Server] > | | | > | EAP method | | > |<------------------>| > | |MSK | > | |<---| > >An attacker authenticator (AA) is acting as an authenticator for the >peer and and as a peer for the legitimate authenticator (LA), passing >through EAP messages between the peer and LA. Both AA and LA >advertise the same LA's information XYZ. The peer learns XYZ from AA. >The server have the XYZ for LA. Server sends MSK to LA after creating >binding between XYZ and MSK by some means (i.e., key mixing or data >transfer). > >If we stop here, the peer will think that AA has the MSK, which is not >true. This looks like an open binding which might open up some >vulnerability to MiTM attack. An additional verification, SAP, is >needed to close the binding by verifying proof of possession of the >MSK between the peer and authenticator. Yoshi, You've just made a case for key generating EAP methods and the need for a SAP. There is no dispute there. But, my earlier point about without SAP, there are other problems is still true, no? CB is not the only issue there. Lakshminath >Regards, >Yoshihiro Ohba _________________________________________________________________ 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 May 09 17:15:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZYE-000834-TY for eap-archive@lists.ietf.org; Tue, 09 May 2006 17:15:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZYE-0006fv-FM for eap-archive@lists.ietf.org; Tue, 09 May 2006 17:15:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 11ACB4300FF for ; Tue, 9 May 2006 14:15:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D4708430071 for ; Tue, 9 May 2006 14:14:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C053B398041 for ; Tue, 9 May 2006 14:14:58 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC44F39801B for ; Tue, 9 May 2006 14:14:53 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k49LEpAe018830; Wed, 10 May 2006 06:14:52 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k49LEqxp020871; Wed, 10 May 2006 06:14:52 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id GAA20834; Wed, 10 May 2006 06:14:52 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k49LEpbw000977; Wed, 10 May 2006 06:14:51 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k49LEojG023020; Wed, 10 May 2006 06:14:50 +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 <0IZ000K7EOCLYDC0@mail.po.toshiba.co.jp>; Wed, 10 May 2006 06:14:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FdZXP-0002BQ-Gs; Tue, 09 May 2006 14:14:35 -0700 Date: Tue, 09 May 2006 17:14:35 -0400 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue 357: Channel Binding Definition In-reply-to: <6.2.5.6.2.20060509124202.059a5420@qualcomm.com> To: Lakshminath Dondeti Message-id: <20060509211435.GB8032@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F1E5@NAEX06.na.qualcomm.com> <44607320.4040301@piuha.net> <20060509140242.GC2352@steelhead> <6.2.5.6.2.20060509092640.054c42a8@qualcomm.com> <20060509190037.GH2352@steelhead> <6.2.5.6.2.20060509124202.059a5420@qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 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: 8b431ad66d60be2d47c7bfeb879db82c Lakshminath, On Tue, May 09, 2006 at 01:39:28PM -0700, Lakshminath Dondeti wrote: > >> > >> Now without the SAP there are other problems, but they don't seem > >> relevant to CB. Perhaps I am missing something (you seem like you've > >> explored this area quite a bit, please explain. Thanks). > > > >Please see an example below. > > > >[Peer]---[AA]---[LA]---[Server] > > | | | > > | EAP method | | > > |<------------------>| > > | |MSK | > > | |<---| > > > >An attacker authenticator (AA) is acting as an authenticator for the > >peer and and as a peer for the legitimate authenticator (LA), passing > >through EAP messages between the peer and LA. Both AA and LA > >advertise the same LA's information XYZ. The peer learns XYZ from AA. > >The server have the XYZ for LA. Server sends MSK to LA after creating > >binding between XYZ and MSK by some means (i.e., key mixing or data > >transfer). > > > >If we stop here, the peer will think that AA has the MSK, which is not > >true. This looks like an open binding which might open up some > >vulnerability to MiTM attack. An additional verification, SAP, is > >needed to close the binding by verifying proof of possession of the > >MSK between the peer and authenticator. > > Yoshi, > > You've just made a case for key generating EAP methods and the need > for a SAP. There is no dispute there. But, my earlier point about > without SAP, there are other problems is still true, no? CB is not > the only issue there. I agree that CB is not the only issue here, but CB is *an* issue. The SAP for CB does not necessarily generate a TSK. In this case, the role of the SAP is just to close the binding. However, if you do CB but don't generate TSK and use it for per-packet ciphering, then you will surely have other issues. Yoshihiro Ohba _________________________________________________________________ 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 May 09 18:18:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaXA-0002Pq-M8 for eap-archive@lists.ietf.org; Tue, 09 May 2006 18:18:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdaX7-0000pE-L2 for eap-archive@lists.ietf.org; Tue, 09 May 2006 18:18:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6BD94430112 for ; Tue, 9 May 2006 15:18:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AD8FD430094 for ; Tue, 9 May 2006 15:18:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 891561448012 for ; Tue, 9 May 2006 15:18:07 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by hermes.tigertech.net (Postfix) with ESMTP id B6409144800B for ; Tue, 9 May 2006 15:18:05 -0700 (PDT) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k49MehKK025951 for ; Tue, 9 May 2006 15:40:48 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k49MZFdl019293 for ; Tue, 9 May 2006 17:35:16 -0500 (CDT) 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: Issue 362: Lower layer parameters and EMSK text Date: Tue, 9 May 2006 18:17:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 362: Lower layer parameters and EMSK text thread-index: AcZyrF7XgryUzu7ZSHmpsxHt8eNORABCUjKg 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=0.0 tagged_above=-999.0 required=7.0 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: 21c69d3cfc2dd19218717dbe1d974352 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, May 08, 2006 9:33 AM To: eap@frascone.com Subject: [eap] Re: Issue 362: Lower layer parameters and EMSK text Move the following text from Section 2 to Section 1.4: "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. 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." Madjid>>Why do we prohibit use of EMSK in deriving other keys? I was under the assumption that it was the intention to leave to specification of EAP keying fwk extensions, such as derivation of AMSK to future activities. The current text prohibits any such derivation. Is this the intent? "prohibiting" something is different from saying "it will be defined later". Why can't we replace the last phrase with: "The Use of EMSK in deriving any other keys will be part of future specifications"? Thanks, Madjid _________________________________________________________________ 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 May 09 19:01:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdbCp-0003r3-Jz for eap-archive@lists.ietf.org; Tue, 09 May 2006 19:01:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdbCn-0002pK-7B for eap-archive@lists.ietf.org; Tue, 09 May 2006 19:01:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D732430100 for ; Tue, 9 May 2006 16:01:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A839A430094 for ; Tue, 9 May 2006 16:01:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8A1331448012 for ; Tue, 9 May 2006 16:01:05 -0700 (PDT) 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 E91BD1448010 for ; Tue, 9 May 2006 16:01:02 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 May 2006 16:01:03 -0700 X-IronPort-AV: i="4.05,107,1146466800"; d="scan'208"; a="322071471:sNHT27774558" 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 k49N10RT027544; Tue, 9 May 2006 16:01:02 -0700 (PDT) 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: Issue 352: Channel Binding Issue Date: Tue, 9 May 2006 16:08:33 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906FF758B@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Re: Issue 352: Channel Binding Issue Thread-Index: AcZy3LSPjDx0JUXKTYuPUZBW7zV3VwA36pNQ From: "Salowey, Joe" To: "Bernard Aboba" 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS 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 I don't recall any, I will check the document to make sure this is clear. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, May 08, 2006 1:12 PM > To: Salowey, Joe > Cc: eap@frascone.com > Subject: RE: [eap] Re: Issue 352: Channel Binding Issue >=20 > Joe Salowey said: >=20 > "For one there are usages of EAP which do not use EAP keying=20 > material so key=20 > mixing will not work for them." >=20 > Right. Are there places in the document that exhibit=20 > confusion on this=20 > point? >=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 fxhzv@clime.com Wed May 10 07:36:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdmzL-0002eI-6w for eap-archive@ietf.org; Wed, 10 May 2006 07:36:19 -0400 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 1FdmzL-0000sh-5P; Wed, 10 May 2006 07:36:19 -0400 Received: from p003222.ppp.asahi-net.or.jp ([221.113.3.222]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FdmwF-0002eb-4s; Wed, 10 May 2006 07:33:09 -0400 Received: from unknown (HELO eutectic.www4.sh8u.com) (192.168.0.6) by host00-03.www4.sh8u.com with SMTP; Wed, 10 May 2006 13:33:09 +0100 Message-ID: <729s464b.0439163@www4.sh8u.com> Date: Wed, 10 May 2006 13:33:09 +0100 From: "Damian Cartwright" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-PGP-Key: qImyHOXMeIfTK4iHGdYhuclGYlnWdKOitSfSI0afHwPc49QdX4pGR8EnvWl2nUyo== X-Firewall-Bypass: NO MIME-Version: 1.0 X-Scanned-by: Norton 5 To: eap-archive@ietf.org, edmund.rivera@ietf.org Subject: Solid Loans with options. X-Spam-Score: 4.5 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a t 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.sh8u.com/was.asp Thank you, Yvette Brady, Accounting vDatabase Deletion: http://www4.sh8u.com/rem.asp From howell.peregrinefdro@gmail.com Wed May 10 07:52:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnFR-0007a3-HA; Wed, 10 May 2006 07:52:57 -0400 Received: from cpe-24-90-251-181.nyc.res.rr.com ([24.90.251.181] helo=HEIDI) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdnFR-0001Zk-2Y; Wed, 10 May 2006 07:52:57 -0400 From: "Ezra" To: Subject: Beneficial cooperation based on expert stok advice Just added Date: Wen, 10 May 2006 07:52:56 +0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: CgvouA5kQaRS1SerEhHzHw3tNPrcj9ebQtPE Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Expert stok analysis and market booming tendencies disclosed stok purchase recommendations and short term trading tips Come in here: CHINA GOLD CORP Symbol: CGDC Current Price: 1.90 You can see China’s developing gold boom is building momentum. Rare opportunity for early investors! Why consider CHINA GOLD CORP (CGDC)? See nowadays what happened: • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. CURRENT NEWS: China Gold Corp. Announces Five for One Forward Stock Split China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce today that the board of directors has approved a five-for-one forward stock split. The record date for the forward stock split is to be effective closing Friday, May 12, 2006. Stockholders of the record date will be entitled to four additional shares of common stock for each share of common stock held on that date. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. Conclusion: The Example Above Show The Awesome, Earning Potential of Little Known Company That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CGDC Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CGDC. Save nerves and funds with reliable stok recommendations stok market tendencies and booming predictions Save nerves and funds with reliable stok recommendations Unbiased stok strategies and information from experts A man's reach should exceed his grasp. Diligence is the mother of good fortune Imagination is the highest kite you can fly The truth will out A good tree brings forth good fruit. If you want a place in the sun, you must leave the shade of the family tree Don't count your chickens before they're hatched . Lucky at cards, unlucky in love Actions speak louder than words. Turtle can't walk if he nah push he head outa he shell. For the lips of a strange woman drop as an honeycomb, and her mouth is smoother than oil. The proverbs of Solomon the son of David, king of Israel. You cannot lose what you never had Watch your thoughts, they become words Watch your words, they become actions, watch your actions, they become habits, watch your habits, they become characer Watch your character, it becomes your destiny Better an open enemy, than a false friend Melt the icy fingers of fear with the sunshine of hope He who plays with fire will get burnt Life is like a box of chocolates, sometimes hard, sometimes soft Time and tide wait for no man. To give subtilty to the simple, to the young man knowledge and discretion. A man is at his tallest when he stoops to help a child. All sunshine makes a desert Danger can never be overcome without taking risks If Wishes Were Horses, Beggars Would Ride Nowt so queer as folk! The best things in life are free Count your blessings Great oaks from little acorns grow A bird in the hand is worth two in the bush. He knows best what good is that has endured evil For every action, there is an equal and opposite government program. When he speaketh fair, believe him not: for there are seven abominations in his heart. From rzte@tipsy.com Thu May 11 08:12:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeA1z-0001v6-CQ for eap-archive@ietf.org; Thu, 11 May 2006 08:12:35 -0400 Received: from 116m56.rivo.mediatti.net ([210.79.147.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeA1x-0005ot-8v for eap-archive@ietf.org; Thu, 11 May 2006 08:12:35 -0400 Received: from 210.79.147.116 (HELO localhost.localdomain) (210.79.147.116) by 210.79.147.116 with SMTP; Thu, 11 May 2006 14:12:35 +0100 Message-Id: <6.4.2.4.5.88730768155456.942a6623@156.154.16.150> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.0 Xmailer-ig: iG-Mailer 1.0r0v4(76902.40936227.896936) Date: Thu, 11 May 2006 14:12:35 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org From: "Jimmy Barajas" Subject: Top Notch Refinances with ease X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 You have been pre-approved for a $497,000 Home Loan at a %3.91 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://www.s9al.net/was.asp Best Wishes, Aimee Fulton From pbnci608689@academicplanet.com Thu May 11 08:51:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAe7-0000F9-DR for eap-archive@ietf.org; Thu, 11 May 2006 08:51:59 -0400 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 1FeAe7-0007mW-C7 for eap-archive@ietf.org; Thu, 11 May 2006 08:51:59 -0400 Received: from [222.142.188.180] (helo=academicplanet.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FeABB-0008FQ-Gd for eap-archive@ietf.org; Thu, 11 May 2006 08:22:13 -0400 Received: from 222.142.188.180 by academicplanet.com (Sendmail 8.7.3) with ESMTP (SSL) id IYT33007 for ; Thu, 11 May 2006 20:21:49 +0800 Message-ID: Date: Thu, 11 May 2006 20:21:49 +0800 From: "mfeuin" To: Subject: specs for this week [D E T A I L S] Valparaiso fanned alkane Content-return: allowed X-Mailer: legislatesMail 1.081 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-IP: 222.142.188.180! X-Spam-Score: 1.8 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 CTXE - CANTEX ENERGY CORP A new Pick This company has tremendous potential, Keep and eye on it and act fast CURRENT_PRICE: $ 0.48 ( a steal at this price ) Short term Forcast : $ 1.20 Before we start with the profile of CTXE we would like to mention something very important: There is a Big PR Campaign starting this weeek And it will go all week so it would be best to get in NOW. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Word From the president : "We encourage our valued shareholders to be patient as we approach the commencement date of this very unique opportunity in one of the last under-explored, world-class potential gas plays with no geopolitical risks." Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. It is the perfect time to take this opportunity From hassanblank2@yahoo.com Thu May 11 09:52:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBaW-00065O-6o for eap-archive@ietf.org; Thu, 11 May 2006 09:52:20 -0400 Received: from web37014.mail.mud.yahoo.com ([209.191.85.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeBaV-0002jh-Op for eap-archive@ietf.org; Thu, 11 May 2006 09:52:20 -0400 Received: (qmail 28529 invoked by uid 60001); 11 May 2006 13:52:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-RocketDSI:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wJ/TTEft5jMWSJBC8FGZq1a4905X9oobUHzSfVcqxHh11eUO2Gm2w/MvjFFWFcM/0wNTgtApfbX1RwZGuaGyr7BZM5QZ9WRf8qiA87svvubuAEUqrasKjmPs3g5kug8pSoo/my6pUV/6tI1ZTm4YF51vnuybko1CAhGqsA1FllE= ; Message-ID: <20060511135216.28526.qmail@web37014.mail.mud.yahoo.com> X-RocketDSI: i=209.191.85.99;s=w Date: Thu, 11 May 2006 06:52:16 -0700 (PDT) From: hassan mohammed Reply-To: m_hassanblank@babbalu.com Subject: PLEASE, URGENT RESPONSE NEEDED To: eap-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1344884912-1147355536=:26738" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 --0-1344884912-1147355536=:26738 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I have a new email address!You can now email me at: hassanblank2@yahoo.com Dear Friend, As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is Hassan Mohammed, a merchant in Dubai, in the U.A.E.I have been diagnosed with Esophageal Cancer this was discovered very late, due to my laxity in caring for my health. It has defiled all forms of medicine, and right now I have only about a few months to live, according to medical experts. I have not particularly lived my life so well, as I never really cared for anyone not even myself but my business. Though I am very rich, I was never generous, I was always hostile to people and only focus on my business as that was the only thing I cared for. But now I regret all this, as I now know that there is more to life than just wanting to have or make all the money in the world. I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God! has called me, I have willed and given most of my properties and assets to my immediate and extended family members and as well as a few close friends. I want God to be merciful to me and accept my soul and so, I have decided to give arms to charity organizations and give succor and comfort to the less privileged in our societies, as I want this to be one of the last good did I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this my self anymore. I once asked members of my family to close one of my accounts and distribute the money, which I have there to charity organization and to the less privileged in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money, which no one knows of, is the huge cash deposit of eighteen million dollars ($18m) that I have with a Security Company in Europe for safekeeping. I will want you to help me collect this deposit and disburse it to some charity organizations and to the less privileged. Please send me a mail to indicate if you will assist me in this disbursement. I have set aside 20% for you for your time and patience. You can e-mail me at my private e-mail address: for easy communication Email; m_hassanblank@yahoo.com OR m_hassanblank@babbalu.com While I wait to hear from you, may God be with you and your entire family. Remain blessed, Hassan Mohammed. - hassan mohammed --0-1344884912-1147355536=:26738 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I have a new email address!
You can now email me at: hassanblank2@yahoo.com

Dear Friend,


As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is Hassan Mohammed, a merchant in Dubai, in the U.A.E.I have been diagnosed with Esophageal Cancer this was discovered very late, due to my laxity in caring for my health. It has defiled all forms of medicine, and right now I have only about a few months to live, according to medical experts.


I have not particularly lived my life so well, as I never really cared for anyone not even myself but my business. Though I am very rich, I was never generous, I was always hostile to people and only focus on my business as that was the only thing I cared for. But now I regret all this, as I now know that there is more to life than just wanting to have or make all the money in the world. I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God! has called me, I have willed and given most of my properties and assets to my immediate and extended family members and as well as a few close friends.


I want God to be merciful to me and accept my soul and so, I have decided to give arms to charity organizations and give succor and comfort to the less privileged in our societies, as I want this to be one of the last good did I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this my self anymore. I once asked members of my family to close one of my accounts and distribute the money, which I have there to charity organization and to the less privileged in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them.


The last of my money, which no one knows of, is the huge cash deposit of eighteen million dollars ($18m) that I have with a Security Company in Europe for safekeeping. I will want you to help me collect this deposit and disburse it to some charity organizations and to the less privileged. Please send me a mail to indicate if you will assist me in this disbursement.


I have set aside 20% for you for your time and patience. You can e-mail me at my private e-mail address: for easy communication


Email; m_hassanblank@yahoo.com

OR

m_hassanblank@babbalu.com

While I wait to hear from you, may God be with you and your entire family.


Remain blessed,


Hassan Mohammed.



- hassan mohammed
--0-1344884912-1147355536=:26738-- From macarioyswords@vvvvv.org Thu May 11 18:12:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJOu-0006DB-3E for eap-archive@ietf.org; Thu, 11 May 2006 18:12:52 -0400 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 1FeJOu-0000l8-0l for eap-archive@ietf.org; Thu, 11 May 2006 18:12:52 -0400 Received: from [201.19.170.76] (helo=vvvvv.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FeJOo-0005qj-8T for eap-archive@ietf.org; Thu, 11 May 2006 18:12:51 -0400 Message-ID: <000001c67548$04c592f0$e9dea8c0@rnw59> Reply-To: "Macario Swords" From: "Macario Swords" To: eap-archive@ietf.org Subject: Re: your VALtUaM Date: Thu, 11 May 2006 15:12:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6750D.5866BAF0" 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.5 (++++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6750D.5866BAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 P X V A L C V r a I m e I A o n A b v A L z a G i i L I a x R e t I U c A n ra S M =20 =20 =20 =20 http://www.natuesere.com =20 =20 =20 =20 =20 since new tidings had come to hand, and matters were changed.=20 That will be Dain! said Thorin when he heard. They will have got=20 wind of his coming. I thought that would alter their mood! Bid them come few in number and weaponless, and I will hear, he called to the=20 messenger. About midday the banners of the Forest and the Lake were seen to be borne forth again. A company of twenty was approaching. At the=20 ------=_NextPart_000_0001_01C6750D.5866BAF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
P
X
V
= A
L
C
= V
r
a
I
= m
e
I
= A
o
n
A
= b
v
A
= L
z
a
G
= i
i
L
= I
a
x
R
= e
t
I
= U
c

A
= n
ra
S
= M


 

=
 
 
 
 
 
 
 
 
since new tidings had come to hand, and matters were changed.
= That will be Dain! said Thorin when he heard. They will have got =
wind of his coming. I thought that would alter their mood! Bid them = come
few in number and weaponless, and I will hear, he called to the =
messenger. About midday the banners of the Forest and the Lake were = seen
to be borne forth again. A company of twenty was approaching. = At the
------=_NextPart_000_0001_01C6750D.5866BAF0-- From lehre@mv-deggingen.de Thu May 11 18:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJpE-0002wp-3T for eap-archive@ietf.org; Thu, 11 May 2006 18:40:04 -0400 Received: from [85.206.185.252] (helo=mv-deggingen.de) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeJpD-0002B0-Hu for eap-archive@ietf.org; Thu, 11 May 2006 18:40:04 -0400 Message-ID: <000001c6754b$d7f20fc0$c570a8c0@qbs98> Reply-To: "Quintin Lehrman" From: "Quintin Lehrman" To: eap-archive@ietf.org Subject: Re: best ctredts Date: Thu, 11 May 2006 15:40:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67511.2B9337C0" 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.3 (++++) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67511.2B9337C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D j=20 ea x=20 r H i=20 om o=20 e O s=20 wn a=20 er, Your c w=20 re e=20 di v=20 t doesn't matter to us! If you O o=20 WN q=20 r h=20 ea a=20 l e c=20 st j=20 at j=20 e and want I i=20 MME n=20 DIA n=20 TE c j=20 as t=20 h to s s=20 pen m=20 d ANY way you like, or simply wish to L r=20 OW i=20 ER your monthly pa v=20 yme w=20 nt h=20 s by a third or more, here are the d z=20 ea b=20 ls k=20 we have T z=20 ODA i=20 Y: $ 49 b=20 0,00 q=20 0 as l n=20 ow as 3 , 6 p=20 5 % $ 3 d=20 70,00 c=20 0 as lo c=20 w as 3 , 9 i=20 0 % $ 4 r=20 90,0 b=20 00 as lo n=20 w as 3 , 2 w=20 0 % $ 25 k=20 0,00 k=20 0 as lo w=20 w as 3 , 3 b=20 5 % $ 2 y=20 00,0 p=20 00 as l n=20 ow as 3 , 5 y=20 5 % V =20 i=20 isi w=20 t ou j=20 r web s b=20 it z=20 e Quintin Lehrman , A c=20 ppr s=20 ova y=20 l Ma j=20 na z=20 ge t=20 r there black and dark lay boulders stark and flying smoke was in the air. It left the world and took its flight over the wide seas of the night. ------=_NextPart_000_0001_01C67511.2B9337C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D
j
ea
x
r H
i
om
o
e O
s
wn
a
er,

Your c
w
re
e
di
v
t doesn't matter to us!

If you O
o
WN
q
r
h
ea
a
l e
c
st
j
at
j
e and want
I
i
MME
n
DIA
n
TE c
j
as
t
h to s
s
pen
m
d ANY
way you like, or simply wish to
L
r
OW
i
ER your monthly pa
v
yme
w
nt
h
s
=20 by a third or more,
here are the d
z
ea
b
ls
k
we have T
z
ODA
i
Y:

$ 49
b
0,00
q
0 as l
n
ow as 3 , 6
p
5 %
$ 3
d
70,00
c
0 as lo
c
w as 3 , 9
i
0 %
$ 4
r
90,0
b
00 as lo
n
w as 3 , 2
w
0 %
$ 25
k
0,00
k
0 as lo
w
w as 3 , 3
b
5 %
$ 2
y
00,0
p
00 as l
n
ow as 3 , 5
y
5 %

V
i
isi
w
t ou
j
r web s
b
it
z
e

Quintin Lehrman , A
c
ppr
s
ova
y
l Ma
j
na
z
ge
t
r

there = black and dark lay boulders stark
and flying smoke was in the air.
It left the world and took its flight
over the wide seas of the night.
------=_NextPart_000_0001_01C67511.2B9337C0-- From katelinokrawczyk@evoice.com Fri May 12 06:04:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUV9-00049h-9O for eap-archive@ietf.org; Fri, 12 May 2006 06:04:03 -0400 Received: from p1252-ipbf604fukuokachu.fukuoka.ocn.ne.jp ([124.97.201.252] helo=evoice.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeUV7-0000w6-Ku for eap-archive@ietf.org; Fri, 12 May 2006 06:04:03 -0400 Message-ID: <000001c675ab$64bb9430$3304a8c0@arp13> Reply-To: "Katelin Krawczyk" From: "Katelin Krawczyk" To: eap-archive@ietf.org Subject: Re: best ctredts Date: Fri, 12 May 2006 03:04:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67570.B85CBC30" 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: 0.1 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67570.B85CBC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D e=20 ea l=20 r H u=20 om f=20 e O f=20 wn i=20 er, Your c n=20 re j=20 di j=20 t doesn't matter to us! If you O q=20 WN f=20 r l=20 ea u=20 l e p=20 st q=20 at l=20 e and want I b=20 MME k=20 DI j=20 ATE c c=20 as o=20 h to s g=20 pe h=20 nd ANY way you like, or simply wish to L r=20 OW h=20 ER your monthly pa q=20 yme i=20 nt v=20 s by a third or more, here are the d h=20 ea x=20 ls j=20 we have T h=20 ODA p=20 Y: $ 4 z=20 90,00 o=20 0 as lo p=20 w as 3 , 6 j=20 5 % $ 37 w=20 0,0 b=20 00 as l g=20 ow as 3 , 9 u=20 0 % $ 49 n=20 0,00 q=20 0 as l h=20 ow as 3 , 2 t=20 0 % $ 2 b=20 50,00 c=20 0 as lo o=20 w as 3 , 3 v=20 5 % $ 2 l=20 00,00 k=20 0 as lo q=20 w as 3 , 5 f=20 5 % V =20 p=20 is v=20 it ou k=20 r web s o=20 it t=20 e Katelin Krawczyk , Ap m=20 pr a=20 ova k=20 l M f=20 ana i=20 ge r=20 r Jusst one more quesstion to guess, yes, yess, said Gollum. But Bilbo simply could not think of any question with that nasty wet cold thing sitting next to him, and pawing and poking him. He scratched himself, he pinched himself; still he could not think of anything. ------=_NextPart_000_0001_01C67570.B85CBC30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D
e
ea
l
r H
u
om
f
e O
f
wn
i
er,

Your c
n
re
j
di
j
t doesn't matter to us!

If you O
q
WN
f
r
l
ea
u
l e
p
st
q
at
l
e and want
I
b
MME
k
DI
j
ATE c
c
as
o
h to s
g
pe
h
nd ANY
way you like, or simply wish to
L
r
OW
h
ER your monthly pa
q
yme
i
nt
v
s
=20 by a third or more,
here are the d
h
ea
x
ls
j
we have T
h
ODA
p
Y:

$ 4
z
90,00
o
0 as lo
p
w as 3 , 6
j
5 %
$ 37
w
0,0
b
00 as l
g
ow as 3 , 9
u
0 %
$ 49
n
0,00
q
0 as l
h
ow as 3 , 2
t
0 %
$ 2
b
50,00
c
0 as lo
o
w as 3 , 3
v
5 %
$ 2
l
00,00
k
0 as lo
q
w as 3 , 5
f
5 %

V
p
is
v
it ou
k
r web s
o
it
t
e

Katelin Krawczyk , Ap
m
pr
a
ova
k
l M
f
ana
i
ge
r
r

Jusst one = more quesstion to guess, yes, yess, said Gollum. But Bilbo
simply could not think of any question with that nasty wet cold = thing
sitting next to him, and pawing and poking him. He scratched himself, = he
pinched himself; still he could not think of = anything.
------=_NextPart_000_0001_01C67570.B85CBC30-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri May 12 11:01:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZ9G-0006BN-VQ for eap-archive@lists.ietf.org; Fri, 12 May 2006 11:01:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeZ9E-0000HT-Ek for eap-archive@lists.ietf.org; Fri, 12 May 2006 11:01:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3AA6F430092 for ; Fri, 12 May 2006 08:01:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8BED0430092 for ; Fri, 12 May 2006 08:00:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6DE79431005 for ; Fri, 12 May 2006 08:00:46 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 28EFE431003 for ; Fri, 12 May 2006 08:00:43 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k4CF0bb1025378 for ; Sat, 13 May 2006 00:00:37 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k4CF0cFQ025046 for eap@frascone.com; Sat, 13 May 2006 00:00:38 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id AAA25014; Sat, 13 May 2006 00:00:38 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k4CF0ak5025472 for ; Sat, 13 May 2006 00:00:36 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k4CF0aIn015815; Sat, 13 May 2006 00:00:36 +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 <0IZ5008XCR0TP480@mail.po.toshiba.co.jp> for eap@frascone.com; Sat, 13 May 2006 00:00:36 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FeZ7x-0000ci-F7 for eap@frascone.com; Fri, 12 May 2006 08:00:25 -0700 Date: Fri, 12 May 2006 11:00:25 -0400 From: Yoshihiro Ohba To: eap@frascone.com Message-id: <20060512150025.GB32706@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: [eap] Channel Binding analysis 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: f66b12316365a3fe519e75911daf28a8 [1] Jari's original proposal: " Channel Binding A secure mechanism for ensuring that a chosen set of channel properties (such as endpoint identifiers) are agreed upon by the EAP peer, authenticator and server. " I believe this is the right definition. If the agreement is just between the EAP peer and server, because the two-party agreement does not assure the identity of the authenticator. [2] Case study: Kerberos Let me do some case study on an existing three-party key management protocol, Kerberos. In Kerberos, a client asks a Ticket Granting Server (TGS) for a ticket needed for communicating with an application server. The ticket generated by the TGS consists of the identity of the client and a session key, all encrypted in the application server's key. The TGS returns the ticket and a copy of the session key to the client, all encrypted in the client's key. However, this exchange does not by itself provide any assurance of the identity of the client. Assurance of the identity of the client is made by another exchange between the client and application server based on verifying the ticket. The TGS agrees on the client's identity by issuing the ticket. The client and application server agree on the client's identity by verifying the ticket issued by the TGS. The three-party agreement on the client identity is made securely based on cryptographic proof of possession of the session key between the client and application server, where the ticket has the binding between the session key and client's identity. [3] Going back to Channel Binding issue One may see the roles of the TGS, client and application server in Kerberos are similar to those of the EAP server, authenticator and peer. In the analysis below, for simplicity but without losing generality, it is assumed that authenticator's identity is used as the channel property. In key mixing approach, the EAP server agrees on the authenticator's identity by key mixing. The authenticator and peer agree on the authenticator's identity by running SAP using the mixed key. The three-party agreement on the authenticator's identity is made securely based on cryptographic proof of possession of the mixed key between the peer and authenticator, where the mixed key itself has the binding with authenticator's identity. In data transferring approach, the EAP server and peer agree on the authenticator's identity by exchanging the authenticator's identity over a protected EAP method and checking the exchanged data. The authenticator and peer agree on the authenticator's identity by running SAP using the MSK. The three-party agreement on the authenticator's identity is made based on cryptographic proof of possession of the MSK between the peer and authenticator, however, it is not sure whether the three-party agreement is *securely* made because there is no cryptographic proof of what the first check has ever been performed. draft-arkko-eap-service-identity-auth-04.txt captures this fact: " The overall result of both approaches is the same, but there are subtle security differences: One difference is that in the EAP approach we need to trust the endpoints to actually perform the check, whereas the key-based check is implicit and "non-skippable" in the latter approach; if the parameters mismatch the keys simply do not work. " I don't think this difference is subtle because Channel Binding is a key management issue. Or we might need to think about what "secure agreement" means. Best regards, Yoshihiro Ohba _________________________________________________________________ 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 May 12 13:34:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FebXL-0003LS-1w for eap-archive@lists.ietf.org; Fri, 12 May 2006 13:34:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FebXH-0008T8-Ds for eap-archive@lists.ietf.org; Fri, 12 May 2006 13:34:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 51B044300B3 for ; Fri, 12 May 2006 10:34:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CF125430096 for ; Fri, 12 May 2006 10:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BD98B398023 for ; Fri, 12 May 2006 10:34:13 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7369F398026 for ; Fri, 12 May 2006 10:34:09 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4CHY7Ag023736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2006 10:34:08 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4CHY5m1008820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 10:34:07 -0700 (PDT) Message-Id: <6.2.5.6.2.20060512093245.05c5f280@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 May 2006 10:34:16 -0700 To: Yoshihiro Ohba , eap@frascone.com From: Lakshminath Dondeti Subject: Re: [eap] Channel Binding analysis In-Reply-To: <20060512150025.GB32706@steelhead> References: <20060512150025.GB32706@steelhead> 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: 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 * On the CB definition: I like something along the lines of " The main idea of channel bindings is to be able to verify information from two sources, such as comparing what the EAP authenticator has told the peer and the server. Different designs could implement this check at different nodes: at the peer, the server, or both." from draft-arkko-eap-service-identity-auth-04.txt. * On the comparison with Kerberos, I am not sure I want to venture there. Kerberos is a "true" 3-party exchange. EAP itself is a 2-party protocol. * On CB verification vs. binding CB to key derivation, I have the same thoughts as Jari and Pasi have (I think others have too), and that is we should rely on verification and not key binding. Whereas key binding may *seem* like an obvious way to make sure verification is not skipped or something like that, a closer look at any security protocol tells us that we rely on end-points verifying something all the time. Sure there are subtle differences in one verification over another, but nevertheless, verification is ok. Furthermore, there is an important practical consideration. As Jari and Pasi list in Section 4.2 of draft-arkko-eap-service-identity-auth-04.txt, there may be a long list of CB parameters, and not just IDs. Furthermore, it is plausible that the authenticator does indeed report different things to the server and the peer. All we care about verifying is that whether the information advertised to the peer is "consistent" (a loose word; perhaps "subset of" is better) with the information known to the server. More specifically, some information may be more important than the other, based on administrative definitions even. As long as we are discussing this, let's explore an example. I was told (thanks to Vidya, Joe and others) that the goal is to ensure that a peer is not getting duped by an Authenticator. If all service in the world is uniform, it doesn't matter which Authenticator provides access, the peer gets access and it doesn't care about anything else; CB is not required. Any data protection worries are to be addressed by end-to-end security. If the peer cares about which Authenticator it wants to get access with based on its preferences on (filtering, whatever) policy, QoS, billing practices, etc., CB looks like one of the solutions. However, notice that depending on what the peer might care about, it may send only a portion of the information advertised by the Authenticator to the server for verification. The server could verify that and state whether the information is valid or not! So, sending information via EAP seems unavoidable to me. Whether the verified information is bound to key derivation or not might be an orthogonal topic! Note also that verification and communication of the result is an integral part so the protocol works correctly. regards, Lakshminath At 08:00 AM 5/12/2006, Yoshihiro Ohba wrote: >[1] Jari's original proposal: > >" >Channel Binding > >A secure mechanism for ensuring that a chosen set of channel >properties (such as endpoint identifiers) are agreed upon by the EAP >peer, authenticator and server. >" > >I believe this is the right definition. If the agreement is just >between the EAP peer and server, because the two-party agreement does >not assure the identity of the authenticator. > > >[2] Case study: Kerberos > >Let me do some case study on an existing three-party key management >protocol, Kerberos. > >In Kerberos, a client asks a Ticket Granting Server (TGS) for a ticket >needed for communicating with an application server. The ticket >generated by the TGS consists of the identity of the client and a >session key, all encrypted in the application server's key. The TGS >returns the ticket and a copy of the session key to the client, all >encrypted in the client's key. However, this exchange does not by >itself provide any assurance of the identity of the client. Assurance >of the identity of the client is made by another exchange between the >client and application server based on verifying the ticket. > >The TGS agrees on the client's identity by issuing the ticket. The >client and application server agree on the client's identity by >verifying the ticket issued by the TGS. The three-party agreement on >the client identity is made securely based on cryptographic proof of >possession of the session key between the client and application >server, where the ticket has the binding between the session key and >client's identity. > >[3] Going back to Channel Binding issue > >One may see the roles of the TGS, client and application server in >Kerberos are similar to those of the EAP server, authenticator and >peer. > >In the analysis below, for simplicity but without losing generality, >it is assumed that authenticator's identity is used as the channel >property. > >In key mixing approach, the EAP server agrees on the authenticator's >identity by key mixing. The authenticator and peer agree on the >authenticator's identity by running SAP using the mixed key. The >three-party agreement on the authenticator's identity is made securely >based on cryptographic proof of possession of the mixed key between >the peer and authenticator, where the mixed key itself has the binding >with authenticator's identity. > >In data transferring approach, the EAP server and peer agree on the >authenticator's identity by exchanging the authenticator's identity >over a protected EAP method and checking the exchanged data. The >authenticator and peer agree on the authenticator's identity by >running SAP using the MSK. The three-party agreement on the >authenticator's identity is made based on cryptographic proof of >possession of the MSK between the peer and authenticator, however, it >is not sure whether the three-party agreement is *securely* made >because there is no cryptographic proof of what the first check has >ever been performed. > >draft-arkko-eap-service-identity-auth-04.txt captures this fact: > >" > The overall result of both approaches is the same, but there are > subtle security differences: One difference is that in the EAP > approach we need to trust the endpoints to actually perform the > check, whereas the key-based check is implicit and "non-skippable" in > the latter approach; if the parameters mismatch the keys simply do > not work. >" > >I don't think this difference is subtle because Channel Binding is a >key management issue. Or we might need to think about what "secure >agreement" means. > > >Best regards, >Yoshihiro Ohba >_________________________________________________________________ >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 ardali@dte.vsnl.net.in Sun May 14 23:03:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfTN7-0008Sh-7V for eap-archive@ietf.org; Sun, 14 May 2006 23:03:49 -0400 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 1FfTN6-0006gF-SY for eap-archive@ietf.org; Sun, 14 May 2006 23:03:49 -0400 Received: from [59.10.143.59] (helo=dte.vsnl.net.in) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FfTGE-0001EV-7V for eap-archive@ietf.org; Sun, 14 May 2006 22:56:43 -0400 Message-ID: <000001c677ca$ad137330$4bfba8c0@mvk11> Reply-To: "Ardal Belser" From: "Ardal Belser" To: eap-archive@ietf.org Subject: Re: your crrdit Date: Sun, 14 May 2006 19:52:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67790.00B49B30" 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.3 (++++) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67790.00B49B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D s ea n r H g om q e O h wn j er, Your c c re u di v t doesn't matt i er to us! If you O b WN d r v ea a l e j st d at g e and want I p MM c EDIAT k E c l as s h to s z pe h nd ANY way you like, or simply wish to L r OW x ER your mon o thly p a aym y ent k s by a third or mo i re, here are the d y ea w ls y we hav i e T n OD j AY: $ 49 x 0 , 0 h 00 a o s l a ow a s s 3 , 6 t 5 % $ 37 p 0 , 0 f 00 a y s l v ow a o s 3 , 9 e 0 % $ 49 v 0 , 0 v 00 a i s lo q w a x s 3 , 2 o 0 % $ 2 i 50 , 00 b 0 a n s lo c w a i s 3 , 3 d 5 % $ 20 z 0 , 0 l 00 a l s lo a w a y s 3 , 5 y 5 % V v is f it o r ur s d it i e =20 Ardal Belser , A s ppr r ova l l Ma j na v ge b r _____ =20 It was. A bitter easterly breeze blew with a threat of oncoming winter. It swirled over and round the arms of the Mountain into the valley, and sighed among the rocks. After their long time in the stewing depths of the dragon-haunted caverns, they shivered in the sun. Suddenly ------=_NextPart_000_0001_01C67790.00B49B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D s ea n r H g om q e O h wn j er,

Your c c re u di v t doesn't matt i er to us!

If you O b WN d r v ea a l e j st d at g e and want
I p MM c EDIAT k E c l as s h to s z pe h nd ANY=20 way you like,
or simply wish to L r OW x ER your mon o thly p a aym y ent k s
=20 by a third or mo i re,
here are the d y ea w ls y we hav i e T n OD j AY:

$ 49 x 0 , 0 h 00 a o s l a ow a s s 3 , 6 t 5 %
$ 37 p 0 , 0 f 00 a y s l v ow a o s 3 , 9 e 0 %
$ 49 v 0 , 0 v 00 a i s lo q w a x s 3 , 2 o 0 %
$ 2 i 50 , 00 b 0 a n s lo c w a i s 3 , 3 d 5 %
$ 20 z 0 , 0 l 00 a l s lo a w a y s 3 , 5 y 5 %

V v is f it o r ur s d it i e

Ardal Belser , A s ppr r ova l l Ma j na v ge b r


It was. A bitter = easterly breeze blew with a threat of oncoming
winter. It swirled over and round the arms of the Mountain into the
valley, and sighed among the rocks. After their long time in the = stewing
depths of the dragon-haunted caverns, they shivered in the sun. = Suddenly
------=_NextPart_000_0001_01C67790.00B49B30-- From dextyblan@eff.org Mon May 15 20:20:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfnJ5-000193-2Z for eap-archive@ietf.org; Mon, 15 May 2006 20:20:59 -0400 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 1FfnJ5-0004ZL-0U for eap-archive@ietf.org; Mon, 15 May 2006 20:20:59 -0400 Received: from 201-69-80-91.dial-up.telesp.net.br ([201.69.80.91] helo=eff.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FfnIy-0006yJ-79 for eap-archive@ietf.org; Mon, 15 May 2006 20:20:58 -0400 Message-ID: <000001c6787e$11e34fc0$9688a8c0@ihc16> Reply-To: "Dexter Blanch" From: "Dexter Blanch" To: eap-archive@ietf.org Subject: Re: my crehdit Date: Mon, 15 May 2006 17:17:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67843.658477C0" 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.0 (++) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67843.658477C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D q ea f r H y om p e O j wne y r, Your c g re o di x t doesn't matte p r to us! If you O h WN x r f ea c l e k st z at t e and want I v MME f DIAT k E c j as x h to s p pen n d ANY way you like, or simply wish to L w OW p ER your mon e thly pa w yme u nt n s by a third or mo n re, here are the d p ea l ls e we hav r e T u OD n AY: $ 4 t 90 , 0 p 00 a z s l i ow a p s 3 , 6 w 5 % $ 37 g 0 , 00 z 0 a e s l v ow a o s 3 , 9 p 0 % $ 49 b 0 , 00 r 0 a x s lo u w a h s 3 , 2 c 0 % $ 25 j 0 , 00 q 0 a p s l r ow a y s 3 , 3 g 5 % $ 20 g 0 , 0 l 00 a t s l l ow a p s 3 , 5 z 5 % V y isi y t ou x r s j it w e =20 Dexter Blanch , Ap u pr s ov b al Ma j na w ge a r _____ =20 I thought as much. I see I have some information you have not got. Dain, I may tell you, is now less than two days march off, and has at least five hundred grim dwarves with him =13 a good many of them have = had experience in the dreadful dwarf and goblin wars, of which you have no ------=_NextPart_000_0001_01C67843.658477C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D q ea f r H y om p e O j wne y r,

Your c g re o di x t doesn't matte p r to us!

If you O h WN x r f ea c l e k st z at t e and want
I v MME f DIAT k E c j as x h to s p pen n d ANY=20 way you like,
or simply wish to L w OW p ER your mon e thly pa w yme u nt n s
=20 by a third or mo n re,
here are the d p ea l ls e we hav r e T u OD n AY:

$ 4 t 90 , 0 p 00 a z s l i ow a p s 3 , 6 w 5 %
$ 37 g 0 , 00 z 0 a e s l v ow a o s 3 , 9 p 0 %
$ 49 b 0 , 00 r 0 a x s lo u w a h s 3 , 2 c 0 %
$ 25 j 0 , 00 q 0 a p s l r ow a y s 3 , 3 g 5 %
$ 20 g 0 , 0 l 00 a t s l l ow a p s 3 , 5 z 5 %

V y isi y t ou x r s j it w e

Dexter Blanch , Ap u pr s ov b al Ma j na w ge a r


I thought as much. I see = I have some information you have not got.
Dain, I may tell you, is now less than two days march off, and has = at
least five hundred grim dwarves with him =80=93 a good many of them have = had
experience in the dreadful dwarf and goblin wars, of which you have = no
------=_NextPart_000_0001_01C67843.658477C0-- From bmastgr@01mobile.com Tue May 16 09:32:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzfF-0006DK-QG for eap-archive@ietf.org; Tue, 16 May 2006 09:32:41 -0400 Received: from [61.16.209.199] (helo=manu-pajqrt0vus) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzfE-0006cc-49 for eap-archive@ietf.org; Tue, 16 May 2006 09:32:41 -0400 Date: Mon, 1 Jan 2001 8:51:42 +0480 From: "Ada Stinson" X-Mailer: The Bat! (v3.6.07) CD5BF9353B3B7091 Reply-To: "Ada Stinson" X-Priority: 3 (Normal) Message-ID: <6991465548.20010101085142@01mobile.com> To: eap-archive@ietf.org Subject: [re:] Read this ASAP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Great News Expec ted! Infinex Ventures Inc. (INFX) Price: 0.80 Already started to climb. This one did very well during last marketing campaign. Very Well! OVERVIEW Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company’s true potential. Maximizing overall profitability and in turn enhancing shareholder value. Current Press Release Infinex Announces Joint Venture and Option Agreement Extension LAS VEGAS, May 5 /- Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From yudetassin@zwettl.gv.at Thu May 18 00:33:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgaCf-0002z7-8e for eap-archive@ietf.org; Thu, 18 May 2006 00:33:37 -0400 Received: from kra.ru ([217.74.167.81] helo=zwettl.gv.at) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgaCe-0002J7-Ie for eap-archive@ietf.org; Thu, 18 May 2006 00:33:37 -0400 Message-ID: <000001c67a33$bbf145b0$d2a7a8c0@hkm71> Reply-To: "Yudel Tassin" From: "Yudel Tassin" To: eap-archive@ietf.org Subject: Re: your good crdit Date: Wed, 17 May 2006 21:30:04 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C679F9.0F926DB0" 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.4 (++++) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C679F9.0F926DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D q ea h r H n om o e O a wne k r, Your c u re p di n t doesn' p t ma g tter to us! If you O k WN n r p ea q l e s st d at l e and w d ant I f MM b EDIA c TE c q as j h to s u pen k d ANY wa v y you lik w e, or simp x ly wis x h to L g OW c ER your monthl r y p h aym z ent y s by a t l hird or mor l e, her a e a a re the d j ea j ls a we ha q ve T h ODA x Y: $4 o 90 , 0 g 00 a x s l v ow a u s 3 , 6 k 4 % $ t 370 , 00 e 0 a b s lo j w a j s 3 , 8 z 9 % $ f 490 , 00 u 0 a r s l l ow a u s 3 , 1 g 9 % $ k 250 , 0 v 00 a t s lo g w a v s 3 , 3 b 4 % $ b 200 , 00 h 0 a m s lo p w a w s 3 , 5 f 4 % Your c v re q di z t doe h sn't matt y er to us r ! g w et m k atc d hed with l b en b der b s =20 Yudel Tassin , A r ppr t ova g l M s ana d ge r r =20 ----- Original Message -----=20 the reality, O Smaug the Chiefest and Greatest of Calamities, replied Bilbo. You have nice manners for a thief and a liar, said the dragon. You seem familiar with my name, but I dont seem to remember smelling you =09 ------=_NextPart_000_0001_01C679F9.0F926DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D q ea h r H n om o e O a wne k r,

Your c u re p di n t doesn' p t ma g tter to us!

If you O k WN n r p ea q l e s st d at l e and w d ant
I f MM b EDIA c TE c q as j h to s u pen k d ANY=20 wa v y you lik w e,
or simp x ly wis x h to L g OW c ER your monthl r y p h aym z ent y s
=20 by a t l hird or mor l e,
her a e a a re the d j ea j ls a we ha q ve T h ODA x Y:

$4 o 90 , 0 g 00 a x s l v ow a u s 3 , 6 k 4 %
$ t 370 , 00 e 0 a b s lo j w a j s 3 , 8 z 9 %
$ f 490 , 00 u 0 a r s l l ow a u s 3 , 1 g 9 %
$ k 250 , 0 v 00 a t s lo g w a v s 3 , 3 b 4 %
$ b 200 , 00 h 0 a m s lo p w a w s 3 , 5 f 4 %

Your c v re q di z t doe h sn't matt y er to us r !

g w et m k atc d hed with l b en b der b s

Yudel Tassin , A r ppr t ova g l M s ana d ge r r
 
----- Original Message -----
the reality, O Smaug the Chiefest and Greatest of Calamities, = replied
Bilbo.
You have nice manners for a thief and a liar, said the dragon. = You
seem familiar with my name, but I dont seem to remember smelling = you
------=_NextPart_000_0001_01C679F9.0F926DB0-- From mcmichae@kimley-horn.com Thu May 18 13:57:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgmkw-0003ol-1v for eap-archive@ietf.org; Thu, 18 May 2006 13:57:50 -0400 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 1Fgmkv-0000Yj-W7 for eap-archive@ietf.org; Thu, 18 May 2006 13:57:50 -0400 Received: from pre68-2-82-242-24-114.fbx.proxad.net ([82.242.24.114] helo=kimley-horn.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fgmkr-0005xG-8z for eap-archive@ietf.org; Thu, 18 May 2006 13:57:45 -0400 Message-ID: <000001c67aa4$0cfb2a50$8df7a8c0@rxf20> Reply-To: "Dung Mcmichael" From: "Dung Mcmichael" To: eap-archive@ietf.org Subject: Re: crdit Date: Thu, 18 May 2006 10:54:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67A69.609C5250" 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.3 (++++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67A69.609C5250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Home 0vvner, Your crredit doesn't matter to us! If you OVVN reeal essttate and want IMMEDlATE cassh to sppend ANY way you like, or simply wish to LOVVER your monthly paayments by a third or more, here are the deeals we have TOdDAY: $ 490 , 000 as lovv as 3 , 65 % $ 370 , 000 as lovv as 3 , 90 % $ 250 , 000 as lovv as 3 , 35 % $ 200 , 000 as lovv as 3 , 55 % go to the web site =20 Dung Mcmichael , Apprroval Mannager =20 than the water, and he hoped he would not suddenly roll off again when they started off once more. Before long the barrels broke free again and turned and twisted off down the stream, and out into the main current Then he found it quite as difficult to stick on as he had feared; but he ------=_NextPart_000_0001_01C67A69.609C5250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Home 0vvner,

Your crredit doesn't matter to us!

If you OVVN reeal essttate and want
IMMEDlATE cassh to sppend ANY=20 way you like,
or simply wish to LOVVER your monthly paayments
=20 by a third or more,
here are the deeals we have TOdDAY:

$ 490 , 000 as lovv as 3 , 65 %
$ 370 , 000 as lovv as 3 , 90 %
$ 250 , 000 as lovv as 3 , 35 %
$ 200 , 000 as lovv as 3 , 55 %

go to the web = site

Dung Mcmichael , Apprroval Mannager
 
than the water, and he hoped he would not suddenly roll off again = when
they started off once more. Before long the barrels broke free again = and
turned and twisted off down the stream, and out into the main = current
Then he found it quite as difficult to stick on as he had feared; but = he
------=_NextPart_000_0001_01C67A69.609C5250-- From nina@jiukou.com Thu May 18 18:30:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgr0e-0007wL-Vo for eap-archive@ietf.org; Thu, 18 May 2006 18:30:20 -0400 Received: from adsl-65-67-197-97.dsl.tulsok.swbell.net ([65.67.197.97] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fgr0c-0003Lq-0o for eap-archive@ietf.org; Thu, 18 May 2006 18:30:20 -0400 Message-ID: <000001c67af5$7aa75280$0100007f@localhost> From: "Jorge Wood" To: Subject: Hey buddy, whats up Date: Thu, 18 May 2006 17:30:11 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C67AF5.7AA75280" 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.8 (++) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67AF5.7AA75280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C67AF5.7AA75280" ------=_NextPart_001_000E_01C67AF5.7AA75280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C67AF5.7AA75280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby
------=_NextPart_001_000E_01C67AF5.7AA75280-- ------=_NextPart_000_0001_01C67AF5.7AA75280 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C67AF5.7AA75280 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhMgJtAaIAABoZGdTQyAAnWP8AAP//////+77X8AAAACH5BAAAAAAALAAAAAAyAm0B AAP/aLrc/jDKSau9OOvNufhgKI5kaZ5oqq5s675wLM90bZNdru987//AhiggIBqLyJtyyWw6 n9Co9BSsWq/YbDYUIHi/3wBxSi6bz+h0Wstuu99vkbdArxeIBbV+z+/713CBgoOEFlxzBB91 AAEAjn+QkZKTlCGFl5iZcSUMd2JJJF5PonKJLKSVJ1+po6asNJqxsrM7IgYCtwKJdGJiACao McEgw7quKsUpxaLJS6jJYKrHStBg0yjNry203N3eEJYKH7dzAQZEvyXZK9Uj6+7XysGrZM/x xtj3NO0w79op3wIKnAXiE75bdQLQKWWKmT169oxBTOSwoauJEj+Q8qdx/6LDjh8t0ssIcuMq a/A6kkQp0aIufCOjtZw2zCRMmzNVinSpz8/An0AHFRwHgtw5T+le3uR5kWJTlcScMtWo0+ZH djlDHosWcSM+qBFDiQT7dKnUqmTFlqo6tetJphz1BJ1Ld8unXF4MzEmYJ6XbqF+/8ru51m21 miDRzitLGHBaqCkD4xTs1HHjySGs7YSsFXDYq6zqih7dQwCjoueI9bqTFOVftI/Xwnb9dCRW qoq3MjbpMnazycBpW66IMbJsyZVfz6z8irTz5xlA5cKly45Cx6CzM6esNjdssy3idR7OuDF3 yLI/l0fu+drgqMHNaz+eCrr9++BCPCJHQKEY1v9pKXdVcd+NNx9oyqiFYFgwFdhbYOmVxeB2 AqJnWYC1UaghMRBWgt+HHzKklwF3lHgdfMQ99BBycBUn3Gw9ZabgZovFpGJ5trXEXmI67khZ jQy9xZaLMtX4YH0gJvncIQRYZ6Iv/0QpZRlxTamCkliOJkIBJHpiYolWhikmNTGOCVCWaAbF RS9stjmGmXDGKWcUadY5EBemjZDOaXP26eefMAgyjhC4PDCoA+FoMQIDi3ZwaHS2aALopJRW OgMQjSJaKKObEirBo1eAuoCojnZ6AamZuKnqqqy26uqrsMYq66y01mrrrbjmquuuvOZaBaqf mjqqsJyygSqwGiAbgbL/hBzhLBLPRgvttNJWS+211maL7bbadsvtt96GC+644pZL7rnmpovu ub8SO12nOIiTabGEolZBpPLiG2++h1qC2r4TAKxvUfYGodnBCCes8MIMN+zwwxBHLPHEFFds 8cUYZ2xxu8Fqml/H9OZy76agHitsv/AOivIGoq48bKHMctBfrzTXbPPNOOes884888rxsie7 i+yjJbs7rKdHG2pq0Ul7nOzSUDeNxcw9V2311VhnrfXWsP4sDtIhg600pwArLbDQUYdsMstp Nx3zDjN7wfXcdNdt9912e32L2PJ+DHTYhhjd99iAu+w0pHwbPrUY/RWB9+OQRy755K3q3bbb /2ofPvjmf0u9NthEoz3qqUF7LrgPcVOu+uqst241ppy8m+i7moae6bzBJrrv2faWTfvI+Mr+ 8uwGM26ErYzwnLzrzNe8/M7PN8+qndR7kzqsjmTfyPa6Zq99m4wkH32s0YcPvfe7io+z999j n2v5q44vvZvV1z9L6o63Kr/8tPLfy/P+0x/4ehZAXBWwe7U6oADZxD8FNs9+EMzE9V4FP/G1 T1b7Q1/4Lki+//nCF99bngj756YQerARJjQf+lDoiP+1EHnga98KLejAE55whtvj4PwiyENC 4I+CAzSfDTs4QA+qD4YfzCEDucfEGiZRVUJUohGPOEIjInCIUVSiE/+XuEQA5rCK8xNDD8cI hwm6in1a5CIG0ejFIybwhkzkngrjSL4VwtGNUpQjFun4xj22kY91ZGMX47hFyJHxkGz44RmD yEIdLrKIH8QjCUfIPvXNkYQxfKEQ/5hEEaIRhQZUYx6l+MJZVVCQXgyjGBHJSiuYcYFWLKQo n0jKUFISimnEpA0tScsoutF/siTkIK04RPcN85iAZF4rlwkERcIyksI0ZQldqMdb+TKaTUTi LrdJzGpiM5lA9CMyt1jBQaZSlcxMJw9eyapyNjKBn9SeL4OZSjtms48MlGE+NblLGtIwlPv0 JD8d+cgbptCeYQxIwQinpoWKDD/OVKVEJ8r/tWBKTiDKehstWnY6urAzfp/kVSUt2s6RZq2S kBspSdeIUop2TaEd1VLpIGq8/Ln0pjjNqc4wSp2icbSnp/OX7Xz6L5VxlGzEw903PqrTpjr1 qbLiKcxmmjSH5meqmzOcVqkqNbfFVBMzgxZUx0rWsvaCp4VLGeA6l1Z+He6ofHPrXKhm1rra talo7Wro1uo3pA6sYIrjnGCH91Ww3vWwiKVoXgW7166y1bFm86rmBlsvoDROXZhdV2Y3q9nO cvazng0taEcr2tKaA6ZYTdxUv0qqxm41X5N96N6yejlZaOy2uM2tbnfL29769re3Re10/No7 onS0bLcL3nCLOq/Z/ylVo2VUnWmnS9rqUve61s0uXe9WJ+iqUwfbTalKx0ve8pr3vOhNr3rX y972uve96e1C5Lpb2O+Cl3HhpZtpgMvf/vr3vwqjVRHySzcsKde+V4io3ZYD4AY7+MEY64LD tkfguSH4whdgKt0AAOEOe/jDE65wm0wj31mReKcYTrEEFBzOWb6vwxwGsYxnLDcRj7jEsyrA Siun4h47QMPAnCav9gvhGFvMyDROMsVwDEQb35iWNfOxlBfA4iy6eMe9YLB/kUwxLiv5yyHG IJNbJYCEQBmhtJrylJmaxXhqUI4y1GQp/8cwI9uZAHf2AofzjGdrxDh7eu4znh2hZ0APmv/Q fja09wpNaEODucFjZhWJnfwfT2QZjOB8lZqlXOV7QnOKvfwm+Or8hTvzec+lTjUYuLznP6/6 1YL2s6xTfeqIeeLRFou0pHXNpjJnWY0NJKiq4EA853i3VLULWH2baTwhe3OU1+xmMom8MFSj OtDWpnWfvczqWCP524HWTLe1He5YM8wTA5AwrieGY5MukdLvPDGUQ/1SH/hOttA5tgeIldFl /0DBVeTkpxspZ2q6Scuyzja2t63ta8N60d/+M/vKDWtVL7zcXraGpQOQ7gGsu2JMDqkHKS1C eT9Rni5eVRACi+8l+XvfDOXGR+M5Tk87m48ZFzfDTc3whTuc3D3/f3XGhz7ri3v7YBsfQMfV /XF2b1eHkyazjvN5c2jHauUk4yq/oLbQ5hYbaMUFKmGJmnXjHtfrw0Vq7azag4i6E5SetPk5 ce4wPmO86OAO+s+NLui8j9vodqea0gfvpqY7veq/dvLci9nmq8POsUyjrGxfK3nQlZ1zrc06 2SrP16JOluWoa/Ys/0l6QoZQzuOjdrUtfveK+53RDnf0okvtatjb/ugU78/gCb/7dPfC8A/j NS5FXAQFCjzTbMI65NXa+bLXtt9IUxxcJYu4t2r968yWr00XDPwP38H3CtH90vHb/YMJf5qK DyTqa4j1rw/1r4DVXezA3ijpB213/s78//LX/vIMi/6MLbU+5QdiHFeAX/B9BdgmA9gf8BZ1 +mNyPKN8IFN5oOd51cdQjcVXkKVsGKh1m+dKNZVSC0iABqgZHXeC5Nd053djijdnOyOBj4Vv RgVbtGU6FOBamoc5mJeDGNAv1NdWnHdfK6g1qjeCEFaCDJOAKQhmQzhy8/UDuDN/Xid2ssN1 bMd/qwVUKUN2WXiFZuN8vxM7SvVvIfg4CGeE/1UAHjdhBZhu61YujABvV7NpPkY122c3OYeG KsgmYPYL6tWEWEOHPSaHWXOHiVU3u5dThFg1gqhii3g1ehiJYcCHaPiEjXhhl4Vdmphdm9iJ nJguADB4p/GJnv9Yipt1iRgmiar4cWq4hKsIYKiIiYc4izSjdLRoM7GIYI94i7zYJrbYi7qS i/a1i8BYjL9YjLUijN+ViaTYjKb4jM7YjBwHjdQYjdSijOp0aPC1jdzYjd74jeAYjiMliuJY juboXpdgVV7YQ8WGfYPwivAIfAlYAPHYW5jwOeqEjxJUj/z4aK24hv2IW/coOt+lj5gQkAip ZBx3BwmZMVigXASzhQ8lVFvIhcR1g7yDMlSYdvGnjgQpV/KXYA05kh8mBr5HkhTTBi5TXDRI gzNYgzDZch9jXB2YWpP3kRsYeTsokijZkw5mkvTokw+jkjY5kcw3WJHXjuvoKTRpfT//aJAy iZRFqQVCWZX/xXHg54pWmRehEik4GDY/lVxd545M2VNj95Q8WIWxJZVB2ExbyY8bx3S3FZe+ 2IbjVzWG15VVxXwZKJMx45ExRZMveZNo+YM5yW9ROTVv2XR06SoomJW1iJWS+YtqCAYmOZmP mZmYuZm22Jm14mB6mXZGmYPxF3ODSXkc2JRGxYMr2ZoeSFlKyZOL6X2topmdiYLqZpecaZu8 KZc0hoC3uZtKWHj22JUbGZGXh5xJBX/vF5iCuZrLpZwvI5rIuXXMBZH81n8VMJsO1pi8h4Lc yVuXGZyQ6ZsVg40wFQjh6VveuZnrSZuPSYnniZ7doG9w8564/2Vp32me+KmQusmfDEOfG0WW rtSfFpN0SGigI6iEESOgraSgEIOgtgihqzh+Q+mgiEShC6OfCaih9fh9kJkwGJqhHqoZ6OaG JZqQvUB4CDOih5SiB3iZDZMZi7l7/KV0DwairuiiZASj6MZxEHOGCCOkKWJ4OApcR5qjLAoG PDpGJfqjE3MetlETQyojuMEhPaJlNtp7OMqlHmejCpOkXgCmBDB4ZQqQvfcFZJqmC8OmZ9ql XtowrWgNTdpDHiqjFJMRQvIWUqEwWTEgyVGkY/qlZ1qoX3qoZVqobQqQ1pCkZrqGRxqpkIqm jJowjjqomAqnirqhlZolvScLSlc/d/+KohGzFHqqIkTap50hJDRqgoSqqYjapZtqqZXqpmL6 pozKpWpaqQhzqYoKq4iahJ2KJZ8aC6FaPR5amVFaEafKFYKqGcvxEnxqFrS6qZqaqbx6MGIq qbuqrWY6q93KMLf6q7EarAuzhHVyrJqgrnaiobe2rGdhFczKp9A6rc1Krb1qrtdqqLXKq9s6 qeEartw6pgILBv+qppjKrworrHSqBbu3AF46ABDrpRPLrhNgsRXLrg87eA7ApQxQrAoQsRjw qRKbsSVrAB7LsW6goUBaMSXREFeaEy8LrSWRpTZbrY6qr+aasLgKprpqq2SKq416q0T7rYMK p+WarRpHqgT/wAYPG7IUC7UeK7UnSwEYi7JTi7VRq7Ugu7UiawFfy7UqG7Eqm0gU2rLApyMw Kp5o27ROW7JwG7chC7V0i7J1C7ZVCwEWO7Ynq7Fy+7FVe7UX67dSW7F1e6yCWwUsC6BKRqMo sra39Xtc6bBwe7iVi7WHe7cVILhZq7mAi7FkC7gasLd/O7GW67mKCaFtC7nhuZCTmwWhyrGI K7GyK7e1O7J5S7Vli7om27dhi7kZkLike7rAa7YQOqesu54m+bqwG7t+S7vPq7XBm7tlO7yD O7uDO7q5a7qiC7zY2waLq7TJa5Ut6wa1G7jOi77QS72cy76G270di76Fy713S7p5/7u7diu9 8/u9iWswizu+yguk5uu78Eu4qIu/YRu6Yru7Cby1C3y/oOu1U7ux6Qu+LKu0qfowLzuzusXB ufW4/eXBkOZxA0y/xWvAxfu+vfu866u7DAyyvRu/V4u/LtwAXXu++kuV7iq+H1yvwJXBLuth QPxbjFOnPDSqNLsSIoyq0uoVXkESN2skrlGzPLITSZwjVaoUO4ITVswVVcwjknEhNgKzLSHA RgxBd7q6xDEktBGoMEIjWhGoqlokcrwSfjqtDHOqemyvC8MWNbuncWyqHlEOJHzG9lOiatyn zXowjgvI8SoT8IEiIOysZxHJeYzHl1zH8/qslLzIjyytUP+MxUVqgIZ8yGnsm2rLyXscyPQ6 x5Tcyp28ya7cxp48pI+syZyMyaq6x03srAw2E9/HvKWcJog8rqk8y5/syJ4crcqcMKt8y86s y318r4CKzLr8p8nRxM/8yronYcOMrIhMfnKApQhHHx1CE4vRqq2axFRMzkscyevMyCzRI2Q8 yeh8z5Jcye18zpLrtt9cJzDqugDcxx/atv/crmt7kgPNzvAYzEx60MS8tq3IuAutilD60BCd Jck7nP1c0ZGoo5qR0Wgyvv+4dOUpnx6dZHQ5oQcj0hqd0ivKmaqS0gDmneCpMC6NJTR9rjJN nDtNMY2pmyx9oTkNIj8dMSapmcj/SDfkqdAbU9RGfdQXc6LC2dRV3ZtWndVYvdVX3dVa7dWa 6VtQHdVSXdaSONYfYtZqrYdoDVFr/dYD2Nb3Add0DXxybR91ndfrdtd83dd+/deAHdiCPdiE XdiGfdiIndiKvdg+0L+M/diQPb1P69gXQNlY0L45YNmXvb0boNkr9ytCEAvaCdoswyhqYicR 3AOeXQWrjbuX0NoRANulQdqjIymy0H/wctr5xnapTbXcq66THdztC9zVW7qfi73OS7xcK8Oz O8NP69vE29vLrdzPTdyrvZG/szf11zsiQ5GG8jWzFd7Y537UOZpZKFfoHQ5g+DUdSTKIUtuz pYXUIZqm/w3e2Z3b2r009K07VTjf7T069gk7X9fb/Gvc1G3gKey9f0vgcXu7Cq7c9Pu93Vvg 0e2+D37hFJ7ggVPb+O2D9h3f7m3fJwPeMAPf4Q0Ob5VV9R3iJP7eoX3iNomYJy7iHP7hHl7f 8b3iK56dJs7hLD55Nt6WbjCGE7zgRm6y9Yvg1mvd25vhFQ7hSX7AR47hSj7lGe7ka+fiLV7j 8N3hOP7jWz7fJh5UWp7jY07jXI7jaW7mH77mAK7da47fof3jJe7mZ+7icg7jQT7j6XhgGt7c xU3cB/7cnxvDJjzhxs3khl7AVW65wZ2/0Bu/NQzdC5zknL0sO67eX67jXd7jZv9ukfxX5nW+ 586nkR/I5qhe6m3O3nC+5Xs+53fu5d/d5Zp+5yTulbft5wz+ANU95RrO6wg+3Tbs6ydc3BIg 6H9O7O9Lwxc+7MgOv7yL6Xau56S+6ate52K+6i9+7Zxe7dqu5mHe7amu7f4t3q/O561O7bIu 6t5+7qMO7gOJKrs+t5Tu5MAd26Wr7FTO6M9u4c3+2/luws5dvxkb4Z573eL+7nT+6mD+6WjO 7Z6+7upu6xHv6uM+8bOO8eeu5uuuMige5+6e8A//DUVe8NAutsvO7ITe67xbrCic4IRe6MKO 6CavuQNP6Qdv7DMPPENF8fzd6RA/6usd6vVy4+mtdun/zd1HT+v/8vHUvlzw3ubORRTfHjy4 vnly/vPoHtmHNNp14fX2A/bbzvUQLfa6nWJmH/Vkv/Zs3/Zu//bDXFjYXub1E+DSvgUZD/eD rfU3aPHfniZpP/ahMtt6X/biHjB+v/WAbwWBf/c60PiFv2mI+d8vPuJLL97qyPQLn99z3vMP b4WXn+PtnZ0ayeKk7/FUb+7orfiR36Q8bvH6zecKj+Z5TvsiH5Ue3vEV3+4gDvKCr/GWf+tp Pvt/3/qur/SwX/l4vumbD+u8/+4cz/BwLuMaf/G1L/vMn/fEn+5Zb/wiTfxRGPTZb53fvfkS H/1qyerZbu3JX/2kf5ae/vxv/07+xe/9dQr+nyL+nd7w740AYqtr3Zh0NL5JpdoZW1hh1yh2 YHdZzidGXLmi8kzX9o3n+s73/g8MCofEmJFFSo5Uy5CxJUNOXCeTU0pieq6rapOhPXJhVOgz GS6q1+y2+w2Py3OCusv5sFuVWT0eXDejYvcR6PVHFYgXVqgI+OVhaOIHeAeT94I1SMk35/kJ Gio6SlpalGaaqrrK2ur6Chtriipba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHW08MBBE rXq9Rl3Nk83rXQMuDe1Ix0wbKi6esU7R7s6dHv/+Q29jL4vvoD+KnuEvC6C5HgJ7WTK1bR+/ GQtFNf/s8ZBdvGURPRXspOuiDY2Xih18Q0hGwgUjDWybx+1kypMkS2ZTKdJltZclTSaE6Y1l y5o6FY7seU0dypw9bcokalMiT5lJiYKDuXPiRkwVKG0oFxKTJEVZCUHg9CTRRxDlUmC1qlXP 1UZ3znJFW3ZtVUdIrlZCkdUsI7hu6cbxqmXmzKQSWxom3I7m4XWKjQZdedgkYcSQKUfugJRy TcucG3teufnzYpaiO0vF4RcNGDGsV+M1Q6Y1pCVaUv9zjcZS3dpnvuLVPWbKxz3Cz5hJLYWj DsAoBEt2Wrpx1MrSFY6Gdx179uinrW/vbvq7+MmFw5Pnnv13WdXs6wbHOBv/S4yxx6P8ka2p /mv9xOPzh9/efQHiZxwbzGE2HnqTKcgYVE85KFVmChrVHErplccgdRDGNJpODyY41A67dXWF V7BV4sWBt9E3YH9ipYgIioeE9V6MLc5GlYsnyvjfcAaaiKB5GXo3oXfaXYakhBomeZqSSBK5 pJBNglfakVIyuVyN//Vmo3yvsejeflO8l18njHCJUZhjyiagmnzwRmBHauTFDmZRTjhkeZKd N09kzoGIpZ5VYnhnofs8Od6eH15p5VRxugkjmmXq2BpX9j1q45qa3ralpMFZKqanBUIaiStT +oQnTT9FqZSF8Dzo1IJMadYdrK7aiSqUqA51a6sT/wH1K6+vqgqeIHTmlRwnav2D7FvrGXes JGlG68cmL0RiG6d3dZSsW/GB1UW2taEVlrQAjoNuHBUhCotyqrh7abryzksvDUXtsK4o8Jay b6j1/gtwwAIPTHDBBh+McMIKx5KvvcXq0FDD+D7cjxD9snbxLhnTC2fAKlEsMYdC2JOZHCH/ oOIQqBQ0yI/gqrzwGh37sLGpvfZCMsVunEwzSDSwrO0pAloc85z+8lDzJ3QeCZ2RwL7zdK5S V+khacJOV6Gfs4pW3b2OMhtuI/x1RfazJxy0dNihijUfB8qqVXZbLesVBV9sta1Vjtuyl/ck 1S5iN4p6mUutj7ik7PSpnP/pSqiRjD/H6uN5apenqhQO+nXQld4YZ2xfsCgIpbt1wSZ8vu2R 7XHAHYE2pqV3OfTp/t0447mxID5dsKsG2qDWu/JemWPBT8545YaSt3fYqW/K+aZens33uUyQ Gv2MadQ+O+yub+F8p9pfEin1bhZ4OJCFLSrdUZsJ7yrmxhcfudSMZuj1z/ECObem+M8F7tnW vmw+5YkKNuQSYJp2lJbwkYlGtAvX2ghIou3RplleKl/aFue+4GUNV+aBX6KIJ7/3dVBElxpf mKgXuiZUMFPkQ+GbToS9SMVugXxbXfc018Aciq8GhrNgGJy0uPQobk+MghygZHXEVnlwfsPL 0n7/1HQtULlwemsCHZpm2LkXVo9bCNxh52wIifVQ0TVl0CENn/cM9FUtKsOKyaKEF8I1Ym0n sgIiB+P4uw7W72fme5EDH1GFPjoLToFUm3rEWDdxlchbaeFi9AxZwwJmoVze+sqzqJKIPvyN kprUJNvIV7Qb8CyUoCSlKXF4yl+sL5UiShorOfbKWMpylrSspS1victc6nKXvOylL++hs29o EGfBBMUq5zDKVyFvma1IZj2KCQTsKU1oE2uUnopRHWLaDCHQxEHJHPcKZzLTYXLoFzrOSU2I BYucxxAnKdwJBHjmQJz4kOcQ6NnNcRotCOjkYTohec2mdSgxw1OfdYiF/yuE4pFWV7MTQZcC xIcKdI6PYaP8lAhHjDpmiROVaBxXdRNeNRQqFt1ohaCjO4+WFEIhpRU47TdI/mGMgtOLm+D6 ZqbAGVB5gVknEzmYzc+01I0VXWYGL3RHjh6Pcscj1p8wN0JwipCpd3zqUkWYviACdalO+ynW oGqsK45hjGgcIOr8mYcsJvCkGyriEt+qTzXmsWvtq5XXsKq4qbo1UY1K39ZE+iShJBGvwGNr U4d4xG+CNV6PrKK2yuo95p1VrbjjU+74KkSUDnOVtpqc+npnVA2tMSWhHWiRPnbZxo3zsz5N LGK9KiU5BpWkSkUq8jzr02zitAWC3KQmAgjDEv/sz2+guiFPN2hbqM42sHZNKmip1toNPneY dKTQVpl7IdCKTLdUdWhdMXvbw9ZWtYJliHhL213opheaFTwhtNDaIy15kQwvs+yCwLvc+zJT u/oFYU6uS94+XYagQuTrf/W7XnYemLCCgi2ePojg8er2v7hNMGq+9znPaTiHkp3vJdmpNSUd k6UpdVz9hNLZ7xjUsAA26YCp9LSUbhaiMP7mRYEVYpQiKsZv1fFKCzpRX2WWsyvGYFEXeoP/ 8Q96jUzeXJJXrQgya5PYsp0a7PlLLP9yywXTsi73yOUwi3nMZC6zmc+M5jRzGV6uzAh8kcbP aF6YICTsD8JmRowPoyz/GWy23zneXE599YzOpbwdv4YGjDZbmRd9TuEyaKFoxlpk0HAudLsO bWlGuyHSc0CW3nDqadXgD4CfDvUk92aXKcuNLeOyiqsNgZxSR3lZqP60GEj9tr6M8dRr2YrZ KAmmtIYg16sOiVwgmerH3trYtuYeqLkQF1nbxkc2rQ+xOQ0K2VlvrDSk7/bAKLsUxnpUZ2Sg tp94RmrjpqYS3PXqCkHuG45uEi1cd1UedT1z8zbes5s32OTNQGXjW63BUGDQmGxcLRrXbaeW LLoJ7mGMYXG+WoRsv2fI8ITzJtiva2z2zAjTFGRx42aNYbcZfqb4cvgXw62yfiAFXA6j/Lim /5Pyx1Xeuuy1/OLxtrglqWwmkYMb4yV3JLaKu8W1Sk/oI/9S0Q/IOk9nPG8cB3ima+FCq2dd dItgOvgYa/ANh/3d5W73ZMX+9XpPXYZBrzqOnj6pty997cG1gttN3vGZi4nibDdIt11Xxrir 3NnNwznpHjt2iZt95Qk3PG4ErnGwfwrvVq87FO/395SPjfIf72HDwzh2bP8lbp+sNSD/eMEA Lm04piauDGk9ZU8GHOGezGTpy/q8wj1Z893yuBKoJfcm39RakZw25jm5QiU7kPOlJ/zBc61z c+lS9Gqu2D6t3+nq/1n7x3Al9Y/mM+6Lf/zkL7/5z4/+XCrn+4gO9P8p2J/++KMZ/u2vdEDk j/9Z0v/qc75//v8PM8TWNmgDQL5FU4m0akt2SMj2RZKkAX0xgLMmN1QHgQ8oNlAGgBkYTUMn bBnmaD1Xf7QBcVzXeB3GgcbHOrP3RDZ0LZ+ngS/YfzznWB8oXGL1cCW4a5NkRaXDd0/ngpVH QDAohDH4c0gXSJckSazWakaIQHqTMpOyc6pjc3c3e1MoXH00hFnoZw43PgBSSCHYg+JmH1So cHKXHCe3ePmDSlqohWGYg5OVg3G4eX52eX3QKWEoc2k4HyHIhlmoekkoHGZDLr21F0Bne8Ql U84Ge1EofM/WG4CoiFb4CBjYh5W4aNNniZn/qAz7JzCcqImfCIqhKIqjSIqlaIqniIqpqIqr yIqt6IqvCIuxKIuzSIvGUAC3iIu5qIu7yIu96Iu/CIzBKIzDSIzFaIzHiIzJqIzLyIzN6IzP CI3RKI3TSI3VmIw2YI3ZqI3byI3d6I3fCI7hKI7jSI7kOAPliI7pqI7ryI7t6I7vCI/rmAG8 uGW6CDD2eAz42Av6iH67OI+5GGb8OC8COQwEmQsGaX766I9chpDj0JC/8JC1EJHit5ATeUsW 6QwYqQsa6QocqWb2uJAMCZD/4pG3UJKrcJJnFoxilpJtoGdu0JIy0y8xWQo0OWYrGZAjSTMx 9291IwoeWVk7KQQl/xltoGCTLAmMSqOGzxCTdLEyT/mTOokaZWQxMymVU7lCb3CUOfmLSpmV ytCUVEl62/KHFfgDQCmW10ZG2uZqHdgBRNmBt3c6L0kDWymSXTlp09aWb5GIthCWh3dvcTmB wsaXbgkEaHl4hamYc8lujfiPuAhnyMGYa3mWV5l+OJl9y+MsmDSZfmmZy5GWUQaYlEmY4XaY n8lHzUKai7luZIONqEmH/rOapqkDdlmPSTlphGlArFmaJgmbSSZIpGmYi0lBQ/mbv+GWB8Kb y0mbb3mce5cJk0kW7mKbv4SZ7pdWncmcF9SRz8lHyNmbjxeeH0aXNYCYgklv46mdzfmYt/9o f9JSmDlSXzhQnb50nX9BOus5m7vwl+kZn37Bm7+3L+cZniKonvtpmCgAl6jHloHpA/XZS/cJ BxfInMLpiTnQn67HoAF6gEFAoKWpa7vpRwnqnJBZZ4AZLQ7aAxDKSxIafijqmgXKnd1povXC oukJBzeao97JfS7aojzaDDq6W1oJpDTqnvnno7skpLiwpEZZpK3QpLaUpLoUpRL5pL5Zo7xQ pbQkjFx5pDZ6pZ6ZpfwZpmY2jF5aAPdYprKwpUXQprFUjLc5pvLypjs6pwe5pkgZj3vKp33q p38KqIEqqINKqIVqqIeKqImqqIvKqI3qqI8KqZEqqZNKqZVqqZf/iqmZqqmbyqmd6qmfCqqh KqqjSqqlaqqniqqpqqqryqqMKgCHOgCtKqvS6BW3WAfHSAjUaAePequ4uKvM2Ku++KvumKsF UKu2Gqy9OKzHKo0qoYvUkIsnEYzSiovOyqeAoY3JmouviozcSqjByq3aSozi+ozkaqjFaqyv aq7j6q3C2q7r2Kvhiqzzuq63Gq/vGo3QeouxWq36WgD66q+8CLD8+q8E66feiq/TmLCdqq3M iq7omq7uqq4Iu6zFaq/hWrHpOrHrSo7gOrG8uKsee68V+6sPS7IcC43meq8Rq6wfq7ELy4wB G63+OrC/WLP7ug1/qq6+6rIau60oa7Es/+uz9IqxQpuxyXqx7TisQsuySWu0MOuzDduzGCuu SRuyRau0FMu0P9uz88q04Eq0TeuyKFuuS+u1TguyY+u1+Uqt+1qw/YqzNsuvNBu3fbq0SOur tpq3yrq38bqtP6u3Tfu3PBu4WJu1WsuzuYqta5u2Z6u4+Hq3j0u0EKuOHru1hCu2JduuVfux 2Eq52xi5XAu1lEu2yUitc2uw1uqLqgu3dmusg5u4I8uxy7q3gWu78mq7r1u7uKu777iymAu8 gOuuYRuxnPu7Tou2vqu1Klu0x7u5kNu5Cfu52Yi00BuMUjuNBDuwbdu602qwdXutu/iukGuM vLu5sGu+sNu76f/Ljojrt2ALtowrvlbbvAgbtit7sVNLrMu7sFcrtmdrtPdrv7+brYyLvcG7 toYLjdr7vTL7tjMrsNrbvXtKvuqbu8Lat7Xbu+t7u+prvxzcvhB7srGLrNNbvBT7uCM7uf4r u4eruTCLtos7wlGbv1Rbus5Iuiisi9U7vjdsjKxrrdwLvgUrs0IMj5E7wy8rsVRLwy+Mwk+8 sUNrwpjqw8tYxYB6xecKq7NaueLbjFBbqcxKq2a7qGIcqWDMp9/LxeGIxMlIxmsMx3Esx3NM x3Vsx3eMx3msx3vMx33sx38MyIEsyINMyIVsyIeMyGMMGGacyI3syI98wZAsyZMsyGj/TMmX jMlybMmZzMmdrKqb7MmhLMqgCsqjbMqnbKmljMqrfKmq3I5qjKiu3MkO+8SHe6gnK8vCK7FH HLqJy7XAiMvNqLrca8S7SMzFXK6s3LIaPL/7e65jm8vNDMzRbI1+q8TEm7w7DM3PSLcPfLMO DMEPLM7VrMyNK7ra7MtXq8Lk6r8lDMXYfLQ13LHQzLxT68TvfM35zMi6Kr38S7yN28Ixq8bf jLpyC77InMzlPL89jM6Ei7xM3L/ZHMPu3Mz5+7/laM31vLUEHMAn/L8cXc1my7n/XNG4m8XP 2rYEPcTGXNBuO860qtBp+7wNLcAWC8bO286/HLvbvLjjONLm/yy7CjzSNSzP39jLwTvF+Sy/ ppuzONvURAzOM/vUEwzTMW3OGz2+uvvTw+vRXX3OH12/ldvPy9zVHD3UXUvC3li9uszWZI3A x8jALC3XwujAUY3DVr27iIvAmtu3N02//xzW+BvF8cvGWX25JVzWWKu/Hg2/CkzOX6vXbL3V jg3XVF3XDQzL3fzS0UjNlHysnkvLtfyyMGzPKczEJyy5AS2OoT28IvvCaa3O17zP/OzaRI3Y ki21nQ3VDBywRtzbUw3V1IvXIcyNJ521rbzFjarbw43DSW3Fbyyos63cye2qzG3d132wwtjT 1aiyblzY2A3enrrJHyzcirrc4Y3egf863utb2jq9xHorsg4d1rft1fWtzfNNr+mt36k8jEcN wuTtxYXLuxuc0QM+01q91LsLwFp93vvt4L7b3wR+30H9i7Sbu+dbuBqM4QgeyV/9wQD+4CFu 3hG+wyVu4uPawRqewReOvikOsivO4Rss4jOuxdod4Mws43yb4Syu4CDM4zEOwzDOvjRO5N+q 3Tzs2mkt0xBt2/oczLGt1Atdq/dc5FWu3rd848rY4FbO5Tr7zM+by9Dd5WPOq2Ru5kS+5Weu 5jgeqLCM5cw9258r5m5s3NEN5l/s12letmvty32+y+6s20Cc2akL3BH824XerXAO4jTd1s0d xpZb5wnO6PD/atLxTNLoDNLK2M2+TbMt3Ys3u9lWTME6q+fsKuW4fdg5bbJ8rdoW7dzpaM+p HsNUDugUbeujXdxjDc+HDc+RvtJUTcSta9fezNtujqt4XOr9zdBPK98RjdYTHeWM/dDhC+nO jtUG/OHRu+ugK9J3fumAW+ACDdxFLM6gHsEH/euJTueKrcOA/dpfPbQyTeCC7bh+3uHdSNSG a7m8jtPZHO+4Ltiv3rEJjNaYS+GQXdKjvbHJ/ucE/7Sz2+3OeMzROsSsa+iXfdfqzuHkHdkA vuFD7sU7+98mLeQWbNTzve8XLc3TbrzsDtakbtP8jvJCbb3+Hu3Ue+D2TbYHrOkT/3zohT7s 4Sz0ot6tJiu6IN6/973TGCzysl3yt57jaj3zwGvR8s7y2Z7YqN3R1+rPVr/Nghu/fw3flK2r 2C7fqE7TZF+McQ3sm13Eg16tbX/sGi/ZL27y9z7gTA/kKf7hKj7PSa7wkwvQULzwt53vie3r uR7fy1zbpy3brk7r3N749B3x9v7vTP3UH9OvTc3pUo3ZQY/idL/jUW/YEt7jlryz7Nv3gvvj vMrwjX7Gr9++1F3GWt7OgM/ata7UJrzIgA7lD63Oib+/c/7cwn+wAh/LtD/ia8786S37zQ/9 h/z80U/9lVz91x/T04/925/H2s/930/H3g/+47/G4p/lpv9+5Ndr/uTP/nY/qKCM+u0v/z7t 09UO7+zt8O2e3/PP/whQutz+cIlIq2VT5i2xV1whhCIIZleqrmzrvnAsz3Rt33iu7xXKUz4U qRHslEyi0Qh5/Dmf0Kh0Sk35qrIBlnelFpFdZpM0ZIa3LOUyuY60NeiHMg5cq8+qt1xP17Tn J4BsPX9qMwOIiAyKi4mNjBSJWguSkzJ4UF9HQh9gZGJmfTBLhYSiFnyib6kurBiYW3YnSbOv tBCkG7AqkJOSjQqMwpYPw5TEM7s7d4OAgsyzdoZsQtOnK7lwfrrOz9Nzd9avE4Xl0rfWueSC N3ri47fUgebc1fSZV9ny0Xj67y7/kBoENFaAIASDv2gou8bwmr54tiDW4keRlMRAEh/Wc5AN nK4c6SYSeVhrFSda/taJ5MKuZEmVuGB+jFFJIDGCBov5srRTYcOfQEeaHHdupK1zHS+iqwcT 3jaZ6/4la7pSm7RuEY9G9ehq2VCj8+q4W1ghYTBkNc86imT2mM+gcBvyKbWUYxCoKMkpRfpx Lta8FFlmPMP3ZVY4JLdNoQtWW53GL3jeRObWZoqAZ9/G3dzHr9WZ1bRW1JvKY90/o0c3JZtH ZlWMKV2iBoy6qBPQ+UR+zToThmRgDjAXREt5OKXKlzgrR5MOWjiM1NQNim6xJeB56rjxM5Sy awx21hHb3es2HnZ27FGae7MHuWV4FmmHJ2zbNvMxzPVHLd/PfzHrUf/5198LAV5T3IBGIKjg gt9JpdB7qjjIIBELHqhggRNmqOGGHHboYTIfhijiiCSW+CGGJqao4oostvidizDGKOOMLIZj I4o05qjjjjz26OOPQAYp5JBEFmnkkUjyZ0CSTDbp5JAGLPnklFRW2WKUUlqp5ZZcMohlll2G KeaYDX0ZJZlopqnmE2Z+ueabcMbZQpttymnnnXbSqeeefPbp55+ABirooIQWauihiCaq6KKM Nuroo5BGKumkjyYAADs= ------=_NextPart_000_0001_01C67AF5.7AA75280-- From spiros@hq.tlavideo.com Fri May 19 12:26:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7nl-0003sH-VQ for eap-archive@ietf.org; Fri, 19 May 2006 12:26:09 -0400 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 1Fh7nl-00024E-U5 for eap-archive@ietf.org; Fri, 19 May 2006 12:26:09 -0400 Received: from [220.168.177.160] (helo=hq.tlavideo.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fh7nZ-0001Vt-7U for eap-archive@ietf.org; Fri, 19 May 2006 12:25:59 -0400 Message-ID: <000001c67b60$66b08880$c9f2a8c0@tlz32> Reply-To: "Spiros Whipkey" From: "Spiros Whipkey" To: eap-archive@ietf.org Subject: Re: vafyqy news Date: Fri, 19 May 2006 09:22:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67B25.BA51B080" 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.4 (++++) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67B25.BA51B080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable De e ar Hom g e O s wne a r ,=20 Your cr g ed w it doesn't matter to us ! R r efi q nan u ce your h m ome f q or as l b ow as 3, s 67 % Vi f si x t ou o r si o te =20 ------=_NextPart_000_0001_01C67B25.BA51B080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
De e ar Hom g e O s wne a r ,
Your cr g ed w it doesn't matter to us !

R r efi q nan u ce your h m ome f q or as l b ow as 3, s 67 %

Vi f si x t ou o r si o te
------=_NextPart_000_0001_01C67B25.BA51B080-- From kamila@dewaele-zonen.be Fri May 19 20:07:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhF0A-0006mm-CF for eap-archive@ietf.org; Fri, 19 May 2006 20:07:26 -0400 Received: from 20151156216.user.veloxzone.com.br ([201.51.156.216] helo=dewaele-zonen.be) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhF08-000235-Pr for eap-archive@ietf.org; Fri, 19 May 2006 20:07:26 -0400 Message-ID: <000001c67ba1$5a4e4d70$babca8c0@gwe17> Reply-To: "Kamila Foy" From: "Kamila Foy" To: eap-archive@ietf.org Subject: Re: wagafu news Date: Fri, 19 May 2006 17:07:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67B66.ADEF7570" 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.2 (++++) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67B66.ADEF7570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D e ear H e ome Ow j ne o r ,=20 Your c c redi y t doesn't matter to us ! Re y fin a an k ce your ho n me fo w r as lo r w as 3, a 67 % V u isi b t ou k r s u ite =20 ------=_NextPart_000_0001_01C67B66.ADEF7570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D e ear H e ome Ow j ne o r ,
Your c c redi y t doesn't matter to us !

Re y fin a an k ce your ho n me fo w r as lo r w as 3, a 67 %

V u isi b t ou k r s u ite
------=_NextPart_000_0001_01C67B66.ADEF7570-- From 01bddb4e.000c4ca0.patrickm@webdesignerla.com Sat May 20 02:59:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhLRK-0003ZH-Mp for eap-archive@ietf.org; Sat, 20 May 2006 02:59:54 -0400 Received: from [221.196.5.42] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhLRC-0003ya-Ml for eap-archive@ietf.org; Sat, 20 May 2006 02:59:54 -0400 Message-ID: <000001c67c05$f8f31a00$0100007f@localhost> From: "Charles Bennett" To: Subject: Hey bro, found this site Date: Sat, 20 May 2006 14:59:34 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C67C05.F8F31A00" 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.6 (++++) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67C05.F8F31A00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C67C05.F8F31A00" ------=_NextPart_001_000E_01C67C05.F8F31A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C67C05.F8F31A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby
------=_NextPart_001_000E_01C67C05.F8F31A00-- ------=_NextPart_000_0001_01C67C05.F8F31A00 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C67C05.F8F31A00 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhMgJtAaIAABoZGdTQyAAnWP8AAP//////+77X8AAAACH5BAAAAAAALAAAAAAyAm0B AAP/aLrc/jDKSau9OOvNufhgKI5kaZ5oqq5s675wLM90bZNdru987//AhiggIBqLyJtyyWw6 n9Co9BSsWq/YbDYUIHi/3wBxSi6bz+h0Wstuu99vkbdArxeIBbV+z+/713CBgoOEFlxzBB91 AAEAjn+QkZKTlCGFl5iZcSUMd2JJJF5PonKJLKSVJ1+po6asNJqxsrM7IgYCtwKJdGJiACao McEgw7quKsUpxaLJS6jJYKrHStBg0yjNry203N3eEJYKH7dzAQZEvyXZK9Uj6+7XysGrZM/x xtj3NO0w79op3wIKnAXiE75bdQLQKWWKmT169oxBTOSwoauJEj+Q8qdx/6LDjh8t0ssIcuMq a/A6kkQp0aIufCOjtZw2zCRMmzNVinSpz8/An0AHFRwHgtw5T+le3uR5kWJTlcScMtWo0+ZH djlDHosWcSM+qBFDiQT7dKnUqmTFlqo6tetJphz1BJ1Ld8unXF4MzEmYJ6XbqF+/8ru51m21 miDRzitLGHBaqCkD4xTs1HHjySGs7YSsFXDYq6zqih7dQwCjoueI9bqTFOVftI/Xwnb9dCRW qoq3MjbpMnazycBpW66IMbJsyZVfz6z8irTz5xlA5cKly45Cx6CzM6esNjdssy3idR7OuDF3 yLI/l0fu+drgqMHNaz+eCrr9++BCPCJHQKEY1v9pKXdVcd+NNx9oyqiFYFgwFdhbYOmVxeB2 AqJnWYC1UaghMRBWgt+HHzKklwF3lHgdfMQ99BBycBUn3Gw9ZabgZovFpGJ5trXEXmI67khZ jQy9xZaLMtX4YH0gJvncIQRYZ6Iv/0QpZRlxTamCkliOJkIBJHpiYolWhikmNTGOCVCWaAbF RS9stjmGmXDGKWcUadY5EBemjZDOaXP26eefMAgyjhC4PDCoA+FoMQIDi3ZwaHS2aALopJRW OgMQjSJaKKObEirBo1eAuoCojnZ6AamZuKnqqqy26uqrsMYq66y01mrrrbjmquuuvOZaBaqf mjqqsJyygSqwGiAbgbL/hBzhLBLPRgvttNJWS+211maL7bbadsvtt96GC+644pZL7rnmpovu ub8SO12nOIiTabGEolZBpPLiG2++h1qC2r4TAKxvUfYGodnBCCes8MIMN+zwwxBHLPHEFFds 8cUYZ2xxu8Fqml/H9OZy76agHitsv/AOivIGoq48bKHMctBfrzTXbPPNOOes884888rxsie7 i+yjJbs7rKdHG2pq0Ul7nOzSUDeNxcw9V2311VhnrfXWsP4sDtIhg600pwArLbDQUYdsMstp Nx3zDjN7wfXcdNdt9912e32L2PJ+DHTYhhjd99iAu+w0pHwbPrUY/RWB9+OQRy755K3q3bbb /2ofPvjmf0u9NthEoz3qqUF7LrgPcVOu+uqst241ppy8m+i7moae6bzBJrrv2faWTfvI+Mr+ 8uwGM26ErYzwnLzrzNe8/M7PN8+qndR7kzqsjmTfyPa6Zq99m4wkH32s0YcPvfe7io+z999j n2v5q44vvZvV1z9L6o63Kr/8tPLfy/P+0x/4ehZAXBWwe7U6oADZxD8FNs9+EMzE9V4FP/G1 T1b7Q1/4Lki+//nCF99bngj756YQerARJjQf+lDoiP+1EHnga98KLejAE55whtvj4PwiyENC 4I+CAzSfDTs4QA+qD4YfzCEDucfEGiZRVUJUohGPOEIjInCIUVSiE/+XuEQA5rCK8xNDD8cI hwm6in1a5CIG0ejFIybwhkzkngrjSL4VwtGNUpQjFun4xj22kY91ZGMX47hFyJHxkGz44RmD yEIdLrKIH8QjCUfIPvXNkYQxfKEQ/5hEEaIRhQZUYx6l+MJZVVCQXgyjGBHJSiuYcYFWLKQo n0jKUFISimnEpA0tScsoutF/siTkIK04RPcN85iAZF4rlwkERcIyksI0ZQldqMdb+TKaTUTi LrdJzGpiM5lA9CMyt1jBQaZSlcxMJw9eyapyNjKBn9SeL4OZSjtms48MlGE+NblLGtIwlPv0 JD8d+cgbptCeYQxIwQinpoWKDD/OVKVEJ8r/tWBKTiDKehstWnY6urAzfp/kVSUt2s6RZq2S kBspSdeIUop2TaEd1VLpIGq8/Ln0pjjNqc4wSp2icbSnp/OX7Xz6L5VxlGzEw903PqrTpjr1 qbLiKcxmmjSH5meqmzOcVqkqNbfFVBMzgxZUx0rWsvaCp4VLGeA6l1Z+He6ofHPrXKhm1rra talo7Wro1uo3pA6sYIrjnGCH91Ww3vWwiKVoXgW7166y1bFm86rmBlsvoDROXZhdV2Y3q9nO cvazng0taEcr2tKaA6ZYTdxUv0qqxm41X5N96N6yejlZaOy2uM2tbnfL29769re3Re10/No7 onS0bLcL3nCLOq/Z/ylVo2VUnWmnS9rqUve61s0uXe9WJ+iqUwfbTalKx0ve8pr3vOhNr3rX y972uve96e1C5Lpb2O+Cl3HhpZtpgMvf/vr3vwqjVRHySzcsKde+V4io3ZYD4AY7+MEY64LD tkfguSH4whdgKt0AAOEOe/jDE65wm0wj31mReKcYTrEEFBzOWb6vwxwGsYxnLDcRj7jEsyrA Siun4h47QMPAnCav9gvhGFvMyDROMsVwDEQb35iWNfOxlBfA4iy6eMe9YLB/kUwxLiv5yyHG IJNbJYCEQBmhtJrylJmaxXhqUI4y1GQp/8cwI9uZAHf2AofzjGdrxDh7eu4znh2hZ0APmv/Q fja09wpNaEODucFjZhWJnfwfT2QZjOB8lZqlXOV7QnOKvfwm+Or8hTvzec+lTjUYuLznP6/6 1YL2s6xTfeqIeeLRFou0pHXNpjJnWY0NJKiq4EA853i3VLULWH2baTwhe3OU1+xmMom8MFSj OtDWpnWfvczqWCP524HWTLe1He5YM8wTA5AwrieGY5MukdLvPDGUQ/1SH/hOttA5tgeIldFl /0DBVeTkpxspZ2q6Scuyzja2t63ta8N60d/+M/vKDWtVL7zcXraGpQOQ7gGsu2JMDqkHKS1C eT9Rni5eVRACi+8l+XvfDOXGR+M5Tk87m48ZFzfDTc3whTuc3D3/f3XGhz7ri3v7YBsfQMfV /XF2b1eHkyazjvN5c2jHauUk4yq/oLbQ5hYbaMUFKmGJmnXjHtfrw0Vq7azag4i6E5SetPk5 ce4wPmO86OAO+s+NLui8j9vodqea0gfvpqY7veq/dvLci9nmq8POsUyjrGxfK3nQlZ1zrc06 2SrP16JOluWoa/Ys/0l6QoZQzuOjdrUtfveK+53RDnf0okvtatjb/ugU78/gCb/7dPfC8A/j NS5FXAQFCjzTbMI65NXa+bLXtt9IUxxcJYu4t2r968yWr00XDPwP38H3CtH90vHb/YMJf5qK DyTqa4j1rw/1r4DVXezA3ijpB213/s78//LX/vIMi/6MLbU+5QdiHFeAX/B9BdgmA9gf8BZ1 +mNyPKN8IFN5oOd51cdQjcVXkKVsGKh1m+dKNZVSC0iABqgZHXeC5Nd053djijdnOyOBj4Vv RgVbtGU6FOBamoc5mJeDGNAv1NdWnHdfK6g1qjeCEFaCDJOAKQhmQzhy8/UDuDN/Xid2ssN1 bMd/qwVUKUN2WXiFZuN8vxM7SvVvIfg4CGeE/1UAHjdhBZhu61YujABvV7NpPkY122c3OYeG KsgmYPYL6tWEWEOHPSaHWXOHiVU3u5dThFg1gqhii3g1ehiJYcCHaPiEjXhhl4Vdmphdm9iJ nJguADB4p/GJnv9Yipt1iRgmiar4cWq4hKsIYKiIiYc4izSjdLRoM7GIYI94i7zYJrbYi7qS i/a1i8BYjL9YjLUijN+ViaTYjKb4jM7YjBwHjdQYjdSijOp0aPC1jdzYjd74jeAYjiMliuJY juboXpdgVV7YQ8WGfYPwivAIfAlYAPHYW5jwOeqEjxJUj/z4aK24hv2IW/coOt+lj5gQkAip ZBx3BwmZMVigXASzhQ8lVFvIhcR1g7yDMlSYdvGnjgQpV/KXYA05kh8mBr5HkhTTBi5TXDRI gzNYgzDZch9jXB2YWpP3kRsYeTsokijZkw5mkvTokw+jkjY5kcw3WJHXjuvoKTRpfT//aJAy iZRFqQVCWZX/xXHg54pWmRehEik4GDY/lVxd545M2VNj95Q8WIWxJZVB2ExbyY8bx3S3FZe+ 2IbjVzWG15VVxXwZKJMx45ExRZMveZNo+YM5yW9ROTVv2XR06SoomJW1iJWS+YtqCAYmOZmP mZmYuZm22Jm14mB6mXZGmYPxF3ODSXkc2JRGxYMr2ZoeSFlKyZOL6X2topmdiYLqZpecaZu8 KZc0hoC3uZtKWHj22JUbGZGXh5xJBX/vF5iCuZrLpZwvI5rIuXXMBZH81n8VMJsO1pi8h4Lc yVuXGZyQ6ZsVg40wFQjh6VveuZnrSZuPSYnniZ7doG9w8564/2Vp32me+KmQusmfDEOfG0WW rtSfFpN0SGigI6iEESOgraSgEIOgtgihqzh+Q+mgiEShC6OfCaih9fh9kJkwGJqhHqoZ6OaG JZqQvUB4CDOih5SiB3iZDZMZi7l7/KV0DwairuiiZASj6MZxEHOGCCOkKWJ4OApcR5qjLAoG PDpGJfqjE3MetlETQyojuMEhPaJlNtp7OMqlHmejCpOkXgCmBDB4ZQqQvfcFZJqmC8OmZ9ql XtowrWgNTdpDHiqjFJMRQvIWUqEwWTEgyVGkY/qlZ1qoX3qoZVqobQqQ1pCkZrqGRxqpkIqm jJowjjqomAqnirqhlZolvScLSlc/d/+KohGzFHqqIkTap50hJDRqgoSqqYjapZtqqZXqpmL6 pozKpWpaqQhzqYoKq4iahJ2KJZ8aC6FaPR5amVFaEafKFYKqGcvxEnxqFrS6qZqaqbx6MGIq qbuqrWY6q93KMLf6q7EarAuzhHVyrJqgrnaiobe2rGdhFczKp9A6rc1Krb1qrtdqqLXKq9s6 qeEartw6pgILBv+qppjKrworrHSqBbu3AF46ABDrpRPLrhNgsRXLrg87eA7ApQxQrAoQsRjw qRKbsSVrAB7LsW6goUBaMSXREFeaEy8LrSWRpTZbrY6qr+aasLgKprpqq2SKq416q0T7rYMK p+WarRpHqgT/wAYPG7IUC7UeK7UnSwEYi7JTi7VRq7Ugu7UiawFfy7UqG7Eqm0gU2rLApyMw Kp5o27ROW7JwG7chC7V0i7J1C7ZVCwEWO7Ynq7Fy+7FVe7UX67dSW7F1e6yCWwUsC6BKRqMo sra39Xtc6bBwe7iVi7WHe7cVILhZq7mAi7FkC7gasLd/O7GW67mKCaFtC7nhuZCTmwWhyrGI K7GyK7e1O7J5S7Vli7om27dhi7kZkLike7rAa7YQOqesu54m+bqwG7t+S7vPq7XBm7tlO7yD O7uDO7q5a7qiC7zY2waLq7TJa5Ut6wa1G7jOi77QS72cy76G270di76Fy713S7p5/7u7diu9 8/u9iWswizu+yguk5uu78Eu4qIu/YRu6Yru7Cby1C3y/oOu1U7ux6Qu+LKu0qfowLzuzusXB ufW4/eXBkOZxA0y/xWvAxfu+vfu866u7DAyyvRu/V4u/LtwAXXu++kuV7iq+H1yvwJXBLuth QPxbjFOnPDSqNLsSIoyq0uoVXkESN2skrlGzPLITSZwjVaoUO4ITVswVVcwjknEhNgKzLSHA RgxBd7q6xDEktBGoMEIjWhGoqlokcrwSfjqtDHOqemyvC8MWNbuncWyqHlEOJHzG9lOiatyn zXowjgvI8SoT8IEiIOysZxHJeYzHl1zH8/qslLzIjyytUP+MxUVqgIZ8yGnsm2rLyXscyPQ6 x5Tcyp28ya7cxp48pI+syZyMyaq6x03srAw2E9/HvKWcJog8rqk8y5/syJ4crcqcMKt8y86s y318r4CKzLr8p8nRxM/8yronYcOMrIhMfnKApQhHHx1CE4vRqq2axFRMzkscyevMyCzRI2Q8 yeh8z5Jcye18zpLrtt9cJzDqugDcxx/atv/crmt7kgPNzvAYzEx60MS8tq3IuAutilD60BCd Jck7nP1c0ZGoo5qR0Wgyvv+4dOUpnx6dZHQ5oQcj0hqd0ivKmaqS0gDmneCpMC6NJTR9rjJN nDtNMY2pmyx9oTkNIj8dMSapmcj/SDfkqdAbU9RGfdQXc6LC2dRV3ZtWndVYvdVX3dVa7dWa 6VtQHdVSXdaSONYfYtZqrYdoDVFr/dYD2Nb3Add0DXxybR91ndfrdtd83dd+/deAHdiCPdiE XdiGfdiIndiKvdg+0L+M/diQPb1P69gXQNlY0L45YNmXvb0boNkr9ytCEAvaCdoswyhqYicR 3AOeXQWrjbuX0NoRANulQdqjIymy0H/wctr5xnapTbXcq66THdztC9zVW7qfi73OS7xcK8Oz O8NP69vE29vLrdzPTdyrvZG/szf11zsiQ5GG8jWzFd7Y537UOZpZKFfoHQ5g+DUdSTKIUtuz pYXUIZqm/w3e2Z3b2r009K07VTjf7T069gk7X9fb/Gvc1G3gKey9f0vgcXu7Cq7c9Pu93Vvg 0e2+D37hFJ7ggVPb+O2D9h3f7m3fJwPeMAPf4Q0Ob5VV9R3iJP7eoX3iNomYJy7iHP7hHl7f 8b3iK56dJs7hLD55Nt6WbjCGE7zgRm6y9Yvg1mvd25vhFQ7hSX7AR47hSj7lGe7ka+fiLV7j 8N3hOP7jWz7fJh5UWp7jY07jXI7jaW7mH77mAK7da47fof3jJe7mZ+7icg7jQT7j6XhgGt7c xU3cB/7cnxvDJjzhxs3khl7AVW65wZ2/0Bu/NQzdC5zknL0sO67eX67jXd7jZv9ukfxX5nW+ 586nkR/I5qhe6m3O3nC+5Xs+53fu5d/d5Zp+5yTulbft5wz+ANU95RrO6wg+3Tbs6ydc3BIg 6H9O7O9Lwxc+7MgOv7yL6Xau56S+6ate52K+6i9+7Zxe7dqu5mHe7amu7f4t3q/O561O7bIu 6t5+7qMO7gOJKrs+t5Tu5MAd26Wr7FTO6M9u4c3+2/luws5dvxkb4Z573eL+7nT+6mD+6WjO 7Z6+7upu6xHv6uM+8bOO8eeu5uuuMige5+6e8A//DUVe8NAutsvO7ITe67xbrCic4IRe6MKO 6CavuQNP6Qdv7DMPPENF8fzd6RA/6usd6vVy4+mtdun/zd1HT+v/8vHUvlzw3ubORRTfHjy4 vnly/vPoHtmHNNp14fX2A/bbzvUQLfa6nWJmH/Vkv/Zs3/Zu//bDXFjYXub1E+DSvgUZD/eD rfU3aPHfniZpP/ahMtt6X/biHjB+v/WAbwWBf/c60PiFv2mI+d8vPuJLL97qyPQLn99z3vMP b4WXn+PtnZ0ayeKk7/FUb+7orfiR36Q8bvH6zecKj+Z5TvsiH5Ue3vEV3+4gDvKCr/GWf+tp Pvt/3/qur/SwX/l4vumbD+u8/+4cz/BwLuMaf/G1L/vMn/fEn+5Zb/wiTfxRGPTZb53fvfkS H/1qyerZbu3JX/2kf5ae/vxv/07+xe/9dQr+nyL+nd7w740AYqtr3Zh0NL5JpdoZW1hh1yh2 YHdZzidGXLmi8kzX9o3n+s73/g8MCofEmJFFSo5Uy5CxJUNOXCeTU0pieq6rapOhPXJhVOgz GS6q1+y2+w2Py3OCusv5sFuVWT0eXDejYvcR6PVHFYgXVqgI+OVhaOIHeAeT94I1SMk35/kJ Gio6SlpalGaaqrrK2ur6Chtriipba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHW08MBBE rXq9Rl3Nk83rXQMuDe1Ix0wbKi6esU7R7s6dHv/+Q29jL4vvoD+KnuEvC6C5HgJ7WTK1bR+/ GQtFNf/s8ZBdvGURPRXspOuiDY2Xih18Q0hGwgUjDWybx+1kypMkS2ZTKdJltZclTSaE6Y1l y5o6FY7seU0dypw9bcokalMiT5lJiYKDuXPiRkwVKG0oFxKTJEVZCUHg9CTRRxDlUmC1qlXP 1UZ3znJFW3ZtVUdIrlZCkdUsI7hu6cbxqmXmzKQSWxom3I7m4XWKjQZdedgkYcSQKUfugJRy TcucG3teufnzYpaiO0vF4RcNGDGsV+M1Q6Y1pCVaUv9zjcZS3dpnvuLVPWbKxz3Cz5hJLYWj DsAoBEt2Wrpx1MrSFY6Gdx179uinrW/vbvq7+MmFw5Pnnv13WdXs6wbHOBv/S4yxx6P8ka2p /mv9xOPzh9/efQHiZxwbzGE2HnqTKcgYVE85KFVmChrVHErplccgdRDGNJpODyY41A67dXWF V7BV4sWBt9E3YH9ipYgIioeE9V6MLc5GlYsnyvjfcAaaiKB5GXo3oXfaXYakhBomeZqSSBK5 pJBNglfakVIyuVyN//Vmo3yvsejeflO8l18njHCJUZhjyiagmnzwRmBHauTFDmZRTjhkeZKd N09kzoGIpZ5VYnhnofs8Od6eH15p5VRxugkjmmXq2BpX9j1q45qa3ralpMFZKqanBUIaiStT +oQnTT9FqZSF8Dzo1IJMadYdrK7aiSqUqA51a6sT/wH1K6+vqgqeIHTmlRwnav2D7FvrGXes JGlG68cmL0RiG6d3dZSsW/GB1UW2taEVlrQAjoNuHBUhCotyqrh7abryzksvDUXtsK4o8Jay b6j1/gtwwAIPTHDBBh+McMIKx5KvvcXq0FDD+D7cjxD9snbxLhnTC2fAKlEsMYdC2JOZHCH/ oOIQqBQ0yI/gqrzwGh37sLGpvfZCMsVunEwzSDSwrO0pAloc85z+8lDzJ3QeCZ2RwL7zdK5S V+khacJOV6Gfs4pW3b2OMhtuI/x1RfazJxy0dNihijUfB8qqVXZbLesVBV9sta1Vjtuyl/ck 1S5iN4p6mUutj7ik7PSpnP/pSqiRjD/H6uN5apenqhQO+nXQld4YZ2xfsCgIpbt1wSZ8vu2R 7XHAHYE2pqV3OfTp/t0447mxID5dsKsG2qDWu/JemWPBT8545YaSt3fYqW/K+aZens33uUyQ Gv2MadQ+O+yub+F8p9pfEin1bhZ4OJCFLSrdUZsJ7yrmxhcfudSMZuj1z/ECObem+M8F7tnW vmw+5YkKNuQSYJp2lJbwkYlGtAvX2ghIou3RplleKl/aFue+4GUNV+aBX6KIJ7/3dVBElxpf mKgXuiZUMFPkQ+GbToS9SMVugXxbXfc018Aciq8GhrNgGJy0uPQobk+MghygZHXEVnlwfsPL 0n7/1HQtULlwemsCHZpm2LkXVo9bCNxh52wIifVQ0TVl0CENn/cM9FUtKsOKyaKEF8I1Ym0n sgIiB+P4uw7W72fme5EDH1GFPjoLToFUm3rEWDdxlchbaeFi9AxZwwJmoVze+sqzqJKIPvyN kprUJNvIV7Qb8CyUoCSlKXF4yl+sL5UiShorOfbKWMpylrSspS1victc6nKXvOylL++hs29o EGfBBMUq5zDKVyFvma1IZj2KCQTsKU1oE2uUnopRHWLaDCHQxEHJHPcKZzLTYXLoFzrOSU2I BYucxxAnKdwJBHjmQJz4kOcQ6NnNcRotCOjkYTohec2mdSgxw1OfdYiF/yuE4pFWV7MTQZcC xIcKdI6PYaP8lAhHjDpmiROVaBxXdRNeNRQqFt1ohaCjO4+WFEIhpRU47TdI/mGMgtOLm+D6 ZqbAGVB5gVknEzmYzc+01I0VXWYGL3RHjh6Pcscj1p8wN0JwipCpd3zqUkWYviACdalO+ynW oGqsK45hjGgcIOr8mYcsJvCkGyriEt+qTzXmsWvtq5XXsKq4qbo1UY1K39ZE+iShJBGvwGNr U4d4xG+CNV6PrKK2yuo95p1VrbjjU+74KkSUDnOVtpqc+npnVA2tMSWhHWiRPnbZxo3zsz5N LGK9KiU5BpWkSkUq8jzr02zitAWC3KQmAgjDEv/sz2+guiFPN2hbqM42sHZNKmip1toNPneY dKTQVpl7IdCKTLdUdWhdMXvbw9ZWtYJliHhL213opheaFTwhtNDaIy15kQwvs+yCwLvc+zJT u/oFYU6uS94+XYagQuTrf/W7XnYemLCCgi2ePojg8er2v7hNMGq+9znPaTiHkp3vJdmpNSUd k6UpdVz9hNLZ7xjUsAA26YCp9LSUbhaiMP7mRYEVYpQiKsZv1fFKCzpRX2WWsyvGYFEXeoP/ 8Q96jUzeXJJXrQgya5PYsp0a7PlLLP9yywXTsi73yOUwi3nMZC6zmc+M5jRzGV6uzAh8kcbP aF6YICTsD8JmRowPoyz/GWy23zneXE599YzOpbwdv4YGjDZbmRd9TuEyaKFoxlpk0HAudLsO bWlGuyHSc0CW3nDqadXgD4CfDvUk92aXKcuNLeOyiqsNgZxSR3lZqP60GEj9tr6M8dRr2YrZ KAmmtIYg16sOiVwgmerH3trYtuYeqLkQF1nbxkc2rQ+xOQ0K2VlvrDSk7/bAKLsUxnpUZ2Sg tp94RmrjpqYS3PXqCkHuG45uEi1cd1UedT1z8zbes5s32OTNQGXjW63BUGDQmGxcLRrXbaeW LLoJ7mGMYXG+WoRsv2fI8ITzJtiva2z2zAjTFGRx42aNYbcZfqb4cvgXw62yfiAFXA6j/Lim /5Pyx1Xeuuy1/OLxtrglqWwmkYMb4yV3JLaKu8W1Sk/oI/9S0Q/IOk9nPG8cB3ima+FCq2dd dItgOvgYa/ANh/3d5W73ZMX+9XpPXYZBrzqOnj6pty997cG1gttN3vGZi4nibDdIt11Xxrir 3NnNwznpHjt2iZt95Qk3PG4ErnGwfwrvVq87FO/395SPjfIf72HDwzh2bP8lbp+sNSD/eMEA Lm04piauDGk9ZU8GHOGezGTpy/q8wj1Z893yuBKoJfcm39RakZw25jm5QiU7kPOlJ/zBc61z c+lS9Gqu2D6t3+nq/1n7x3Al9Y/mM+6Lf/zkL7/5z4/+XCrn+4gO9P8p2J/++KMZ/u2vdEDk j/9Z0v/qc75//v8PM8TWNmgDQL5FU4m0akt2SMj2RZKkAX0xgLMmN1QHgQ8oNlAGgBkYTUMn bBnmaD1Xf7QBcVzXeB3GgcbHOrP3RDZ0LZ+ngS/YfzznWB8oXGL1cCW4a5NkRaXDd0/ngpVH QDAohDH4c0gXSJckSazWakaIQHqTMpOyc6pjc3c3e1MoXH00hFnoZw43PgBSSCHYg+JmH1So cHKXHCe3ePmDSlqohWGYg5OVg3G4eX52eX3QKWEoc2k4HyHIhlmoekkoHGZDLr21F0Bne8Ql U84Ge1EofM/WG4CoiFb4CBjYh5W4aNNniZn/qAz7JzCcqImfCIqhKIqjSIqlaIqniIqpqIqr yIqt6IqvCIuxKIuzSIvGUAC3iIu5qIu7yIu96Iu/CIzBKIzDSIzFaIzHiIzJqIzLyIzN6IzP CI3RKI3TSI3VmIw2YI3ZqI3byI3d6I3fCI7hKI7jSI7kOAPliI7pqI7ryI7t6I7vCI/rmAG8 uGW6CDD2eAz42Av6iH67OI+5GGb8OC8COQwEmQsGaX766I9chpDj0JC/8JC1EJHit5ATeUsW 6QwYqQsa6QocqWb2uJAMCZD/4pG3UJKrcJJnFoxilpJtoGdu0JIy0y8xWQo0OWYrGZAjSTMx 9291IwoeWVk7KQQl/xltoGCTLAmMSqOGzxCTdLEyT/mTOokaZWQxMymVU7lCb3CUOfmLSpmV ytCUVEl62/KHFfgDQCmW10ZG2uZqHdgBRNmBt3c6L0kDWymSXTlp09aWb5GIthCWh3dvcTmB wsaXbgkEaHl4hamYc8lujfiPuAhnyMGYa3mWV5l+OJl9y+MsmDSZfmmZy5GWUQaYlEmY4XaY n8lHzUKai7luZIONqEmH/rOapqkDdlmPSTlphGlArFmaJgmbSSZIpGmYi0lBQ/mbv+GWB8Kb y0mbb3mce5cJk0kW7mKbv4SZ7pdWncmcF9SRz8lHyNmbjxeeH0aXNYCYgklv46mdzfmYt/9o f9JSmDlSXzhQnb50nX9BOus5m7vwl+kZn37Bm7+3L+cZniKonvtpmCgAl6jHloHpA/XZS/cJ BxfInMLpiTnQn67HoAF6gEFAoKWpa7vpRwnqnJBZZ4AZLQ7aAxDKSxIafijqmgXKnd1povXC oukJBzeao97JfS7aojzaDDq6W1oJpDTqnvnno7skpLiwpEZZpK3QpLaUpLoUpRL5pL5Zo7xQ pbQkjFx5pDZ6pZ6ZpfwZpmY2jF5aAPdYprKwpUXQprFUjLc5pvLypjs6pwe5pkgZj3vKp33q p38KqIEqqINKqIVqqIeKqImqqIvKqI3qqI8KqZEqqZNKqZVqqZf/iqmZqqmbyqmd6qmfCqqh KqqjSqqlaqqniqqpqqqryqqMKgCHOgCtKqvS6BW3WAfHSAjUaAePequ4uKvM2Ku++KvumKsF UKu2Gqy9OKzHKo0qoYvUkIsnEYzSiovOyqeAoY3JmouviozcSqjByq3aSozi+ozkaqjFaqyv aq7j6q3C2q7r2Kvhiqzzuq63Gq/vGo3QeouxWq36WgD66q+8CLD8+q8E66feiq/TmLCdqq3M iq7omq7uqq4Iu6zFaq/hWrHpOrHrSo7gOrG8uKsee68V+6sPS7IcC43meq8Rq6wfq7ELy4wB G63+OrC/WLP7ug1/qq6+6rIau60oa7Es/+uz9IqxQpuxyXqx7TisQsuySWu0MOuzDduzGCuu SRuyRau0FMu0P9uz88q04Eq0TeuyKFuuS+u1TguyY+u1+Uqt+1qw/YqzNsuvNBu3fbq0SOur tpq3yrq38bqtP6u3Tfu3PBu4WJu1WsuzuYqta5u2Z6u4+Hq3j0u0EKuOHru1hCu2JduuVfux 2Eq52xi5XAu1lEu2yUitc2uw1uqLqgu3dmusg5u4I8uxy7q3gWu78mq7r1u7uKu777iymAu8 gOuuYRuxnPu7Tou2vqu1Klu0x7u5kNu5Cfu52Yi00BuMUjuNBDuwbdu602qwdXutu/iukGuM vLu5sGu+sNu76f/Ljojrt2ALtowrvlbbvAgbtit7sVNLrMu7sFcrtmdrtPdrv7+brYyLvcG7 toYLjdr7vTL7tjMrsNrbvXtKvuqbu8Lat7Xbu+t7u+prvxzcvhB7srGLrNNbvBT7uCM7uf4r u4eruTCLtos7wlGbv1Rbus5Iuiisi9U7vjdsjKxrrdwLvgUrs0IMj5E7wy8rsVRLwy+Mwk+8 sUNrwpjqw8tYxYB6xecKq7NaueLbjFBbqcxKq2a7qGIcqWDMp9/LxeGIxMlIxmsMx3Esx3NM x3Vsx3eMx3msx3vMx33sx38MyIEsyINMyIVsyIeMyGMMGGacyI3syI98wZAsyZMsyGj/TMmX jMlybMmZzMmdrKqb7MmhLMqgCsqjbMqnbKmljMqrfKmq3I5qjKiu3MkO+8SHe6gnK8vCK7FH HLqJy7XAiMvNqLrca8S7SMzFXK6s3LIaPL/7e65jm8vNDMzRbI1+q8TEm7w7DM3PSLcPfLMO DMEPLM7VrMyNK7ra7MtXq8Lk6r8lDMXYfLQ13LHQzLxT68TvfM35zMi6Kr38S7yN28Ixq8bf jLpyC77InMzlPL89jM6Ei7xM3L/ZHMPu3Mz5+7/laM31vLUEHMAn/L8cXc1my7n/XNG4m8XP 2rYEPcTGXNBuO860qtBp+7wNLcAWC8bO286/HLvbvLjjONLm/yy7CjzSNSzP39jLwTvF+Sy/ ppuzONvURAzOM/vUEwzTMW3OGz2+uvvTw+vRXX3OH12/ldvPy9zVHD3UXUvC3li9uszWZI3A x8jALC3XwujAUY3DVr27iIvAmtu3N02//xzW+BvF8cvGWX25JVzWWKu/Hg2/CkzOX6vXbL3V jg3XVF3XDQzL3fzS0UjNlHysnkvLtfyyMGzPKczEJyy5AS2OoT28IvvCaa3O17zP/OzaRI3Y ki21nQ3VDBywRtzbUw3V1IvXIcyNJ521rbzFjarbw43DSW3Fbyyos63cye2qzG3d132wwtjT 1aiyblzY2A3enrrJHyzcirrc4Y3egf863utb2jq9xHorsg4d1rft1fWtzfNNr+mt36k8jEcN wuTtxYXLuxuc0QM+01q91LsLwFp93vvt4L7b3wR+30H9i7Sbu+dbuBqM4QgeyV/9wQD+4CFu 3hG+wyVu4uPawRqewReOvikOsivO4Rss4jOuxdod4Mws43yb4Syu4CDM4zEOwzDOvjRO5N+q 3Tzs2mkt0xBt2/oczLGt1Atdq/dc5FWu3rd848rY4FbO5Tr7zM+by9Dd5WPOq2Ru5kS+5Weu 5jgeqLCM5cw9258r5m5s3NEN5l/s12letmvty32+y+6s20Cc2akL3BH824XerXAO4jTd1s0d xpZb5wnO6PD/atLxTNLoDNLK2M2+TbMt3Ys3u9lWTME6q+fsKuW4fdg5bbJ8rdoW7dzpaM+p HsNUDugUbeujXdxjDc+HDc+RvtJUTcSta9fezNtujqt4XOr9zdBPK98RjdYTHeWM/dDhC+nO jtUG/OHRu+ugK9J3fumAW+ACDdxFLM6gHsEH/euJTueKrcOA/dpfPbQyTeCC7bh+3uHdSNSG a7m8jtPZHO+4Ltiv3rEJjNaYS+GQXdKjvbHJ/ucE/7Sz2+3OeMzROsSsa+iXfdfqzuHkHdkA vuFD7sU7+98mLeQWbNTzve8XLc3TbrzsDtakbtP8jvJCbb3+Hu3Ue+D2TbYHrOkT/3zohT7s 4Sz0ot6tJiu6IN6/973TGCzysl3yt57jaj3zwGvR8s7y2Z7YqN3R1+rPVr/Nghu/fw3flK2r 2C7fqE7TZF+McQ3sm13Eg16tbX/sGi/ZL27y9z7gTA/kKf7hKj7PSa7wkwvQULzwt53vie3r uR7fy1zbpy3brk7r3N749B3x9v7vTP3UH9OvTc3pUo3ZQY/idL/jUW/YEt7jlryz7Nv3gvvj vMrwjX7Gr9++1F3GWt7OgM/ata7UJrzIgA7lD63Oib+/c/7cwn+wAh/LtD/ia8786S37zQ/9 h/z80U/9lVz91x/T04/925/H2s/930/H3g/+47/G4p/lpv9+5Ndr/uTP/nY/qKCM+u0v/z7t 09UO7+zt8O2e3/PP/whQutz+cIlIq2VT5i2xV1whhCIIZleqrmzrvnAsz3Rt33iu7xXKUz4U qRHslEyi0Qh5/Dmf0Kh0Sk35qrIBlnelFpFdZpM0ZIa3LOUyuY60NeiHMg5cq8+qt1xP17Tn J4BsPX9qMwOIiAyKi4mNjBSJWguSkzJ4UF9HQh9gZGJmfTBLhYSiFnyib6kurBiYW3YnSbOv tBCkG7AqkJOSjQqMwpYPw5TEM7s7d4OAgsyzdoZsQtOnK7lwfrrOz9Nzd9avE4Xl0rfWueSC N3ri47fUgebc1fSZV9ny0Xj67y7/kBoENFaAIASDv2gou8bwmr54tiDW4keRlMRAEh/Wc5AN nK4c6SYSeVhrFSda/taJ5MKuZEmVuGB+jFFJIDGCBov5srRTYcOfQEeaHHdupK1zHS+iqwcT 3jaZ6/4la7pSm7RuEY9G9ehq2VCj8+q4W1ghYTBkNc86imT2mM+gcBvyKbWUYxCoKMkpRfpx Lta8FFlmPMP3ZVY4JLdNoQtWW53GL3jeRObWZoqAZ9/G3dzHr9WZ1bRW1JvKY90/o0c3JZtH ZlWMKV2iBoy6qBPQ+UR+zToThmRgDjAXREt5OKXKlzgrR5MOWjiM1NQNim6xJeB56rjxM5Sy awx21hHb3es2HnZ27FGae7MHuWV4FmmHJ2zbNvMxzPVHLd/PfzHrUf/5198LAV5T3IBGIKjg gt9JpdB7qjjIIBELHqhggRNmqOGGHHboYTIfhijiiCSW+CGGJqao4oostvidizDGKOOMLIZj I4o05qjjjjz26OOPQAYp5JBEFmnkkUjyZ0CSTDbp5JAGLPnklFRW2WKUUlqp5ZZcMohlll2G KeaYDX0ZJZlopqnmE2Z+ueabcMbZQpttymnnnXbSqeeefPbp55+ABirooIQWauihiCaq6KKM Nuroo5BGKumkjyYAADs= ------=_NextPart_000_0001_01C67C05.F8F31A00-- From eBay@eBay.com Sun May 21 02:31:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhhT4-0006B7-Pt; Sun, 21 May 2006 02:31:10 -0400 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 1FhhT4-0003q2-7s; Sun, 21 May 2006 02:31:10 -0400 Received: from n12z177l66.broadband.ctm.net ([202.175.177.66] helo=eBay.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fhgzx-0001ID-72; Sun, 21 May 2006 02:01:08 -0400 Received: (qmail 47967 invoked from network); Sat, 20 May 2006 23:24:20 -0800 Received: from b-00-066833-206.acl31.eBay.com (HELO secure) (202.175.177.66) by unknown.clanatx.com with SMTP; Sat, 20 May 2006 23:33:08 -0800 From: "eBay" To: Subject: Please Verify Your eBay Identity Date: Sat, 20 May 2006 23:30:52 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc


Dear eBay Member,

During our Security and Resolution Center regular maintainance period it has come to our attention that your eBay Billing Information is out of date. The update process is a very simple and fast one and it must be completed immediately in order to avoid any future issues - Terms of Service (TOS) violations, cancellation of service, account suspension or even account termination.

To update your eBay records on file now click here:
http://signin.ebay.com/ws/eBayISAPI.dll?SignIn&ssPageName=h:h:sin:US

Once you have completed the process your eBay session will not be interrupted and your online experience will continue as normal.
eBay sent this e-mail to you because your Notification Preferences indicate that you want to receive information regarding your eBay Credit Card Statement.

To change your communication preferences, click here. Or, simply reply to this e-mail with UNSUBSCRIBE in the subject line. Please note that it may take up to 14 days to process your request. Visit our Privacy Policy and User Agreement if you have any questions.
Copyright © 2006 eBay Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are trademarks of eBay Inc.
From service@ncua.gov Sun May 21 12:28:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhqmi-0005jK-0O for eap-archive@ietf.org; Sun, 21 May 2006 12:28:04 -0400 Received: from [66.45.237.250] (helo=server.admhosting.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhqmh-0004zO-EX for eap-archive@ietf.org; Sun, 21 May 2006 12:28:03 -0400 Received: from [86.123.230.195] (helo=User) by server.admhosting.net with esmtpa (Exim 4.52) id 1Fhql2-0005nC-RT; Sun, 21 May 2006 12:26:22 -0400 Reply-To: From: "National Credit Union Administration" Subject: Activate your FCU Account Date: Sun, 21 May 2006 19:26:20 +0300 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit 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-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.admhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ncua.gov X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 4.5 (++++) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24
NCUA Seal

National Credit Union Administration

Skip to Site NavigationSkip to Page NavigationShare Insurance | Resources for Credit Unions | Resources for Consumers | News | Search
                           
 
 
Important security renewal

Dear CU holder account,


This notice informs you that your Credit Union bank has joined our Federal Credit Union(FCU) network. For both, our and your security, we are asking you to activate an online account on our database. After activation you can login on our system with your Card Number and your Credit/Debit PIN number.

You must visit the FCU activation page and fill in the form to activate your online account:

http://www.ncua.gov/activate_account.html



In accordance with NCUA User Agreement, you can use your online account in 24 hours after activation. We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account.

We apologize for any inconvenience.

Sincerely, NCUA Account Review Department

Please do not reply to this e-mail. Mail sent to this address cannot be answered.
About NCUA

The National Credit Union Administration (NCUA) is the independent federal agency that charters and supervises federal credit unions. NCUA, backed of the full faith and credit of the U.S. government, operates the National Credit Union Share Insurance Fund (NCUSIF) insuring the savings of 80 million account holders in all federal credit unions and many state-chartered credit unions. During the 1990s and into the 21st century, credit unions have been healthy and growing. Credit union failures remain low and the Share Insurance Fund maintains a healthy equity level. The National Credit Union Administration (NCUA) is comitted to maintain a safe environment for over 80 million account holders in all federal credit unions and many state-chartered credit unions. Protecting the security of holders account and of the Federal Credit Unions (FCU) network is our primary concern.

.
NCUA Share Insurance Logo
From nlzosctfn@deannafranco.com Sun May 21 19:42:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhxZ6-0003vm-3R for eap-archive@ietf.org; Sun, 21 May 2006 19:42:28 -0400 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 1FhxZ6-0007qg-1U for eap-archive@ietf.org; Sun, 21 May 2006 19:42:28 -0400 Received: from 177-56-112.adsl.terra.cl ([200.112.56.177] helo=deannafranco.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FhxYw-0004q3-2T for eap-archive@ietf.org; Sun, 21 May 2006 19:42:23 -0400 Received: by zproxy.gmail.com with SMTP id n69so3919744nzg for Sun, 21 May 2006 19:41:53 -0400 Message-ID: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=Ulg.HlMS; d=deannafranco.comb=zrquajuaxpdpsmwiwxxdvipouxtlkqwwowrqeatqbmmilpoxbipwweghtfiqjqkbnjhxdkunebqgrizk Date: Sun, 21 May 2006 19:41:53 -0400 From: "volbmc brrvkupt" To: Subject: [Report] Nothing like it Content-return: allowed X-SENDER-IP: 200.112.56.177 X-Mailer: devMail.Net (3.2.2205.0452) X-Authentication-Warning: localhost.localdomain: apache set sender to nlzosctfn@deannafranco.com using -f X-Virus-Scanned: amavisd-new at deannafranco.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Get CTXE First Thing Today, This Is Going To Explode! Check out for HOT NEWS!!! CTXE - CANTEX ENERGY CORP CURRENT_PRICE: .50 GET IT N0W! GET in now for over 300 percent potential Gain Before we start with the profile of CTXE we would like to mention something very important: There is a Big PR Campaign starting this weeek . And it will go all week so it would be best to get in NOW. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News President of Cantex commented, "We encourage our valued shareholders to be patient as we approach the commencement date of this very unique opportunity in one of the last under-explored, world-class potential gas plays with no geopolitical risks." Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. Pull it up by the roots. When you get lemons, make lemonade.(When life gives you scraps make quilts.) Wait and see. From wardrobe.faberzzols@gmail.com Tue May 23 15:42:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ficlo-0001FG-FM; Tue, 23 May 2006 15:42:20 -0400 Received: from p54823de3.dip0.t-ipconnect.de ([84.130.61.227] helo=WILLY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ficlm-0007oa-Oo; Tue, 23 May 2006 15:42:20 -0400 Received: from unknown (HELO alt1.gmail-smtp-in.l.google.com) (64.233.183.27) by WILLY with SMTP; Tue, 23 May 2006 21:47:46 -0100 From: "Bertha" To: Subject: Play successful on skyrocketing stokc markets CGDC New Date: Tue, 23 May 2006 21:47:46 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 9Db6TAegYEha2tYv45exobfRkc1oESAt8pSG Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Valuable insider info to boost your trading revenues You can make more money with insider information and stokc tips Market research and market pulse analysis from top experts Find what you need here: We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0cck shows a significant up in sto0ck price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! C.H.I.N.A G.O.L.D C.O.R.P Symbol: CGDC Current Price: 0.50 EXPECTING PRICE in short period: 2 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. Conclusion: The Example Above Show The Awesome, Earning Potential of Little Known Company That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CGDC Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CGDC. Penny st0cks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Go CGDC. stokc recommendations and managing solutions Play successful on skyrocketing stokc markets stokc recommendation boosting stokc performance Efficient approach to investing from stokc professionals A scalded cat fears cold water. As busy as a bee Old friends and wine are best The rotten apple injures its neighbours So long as you do your best in life, whatever happens will be for the best They would none of my counsel: they despised all my reproof. March winds and April showers bring forth May flowers Every fowl feed pon he own craw. Prevention is better than cure. Teaching of others teacheth the teacher Little Strokes Fell Great Oaks A creaking door hangs longest. Can one go upon hot coals, and his feet not be burned? A watched pot never boils. The bigger the better. Her feet go down to death; her steps take hold on hell. Divide and rule He who knows better has never tried it Laugh and the world laughs with you, cry and you cry alone All good things must come to an end Patience is a virtue Misery loves company Love is the strangest thing Common fame is seldom to blame Six of one, half a dozen of the other . Never murder a man who is committing suicide Turn you at my reproof: behold, I will pour out my spirit unto you, I will make known my words unto you. He is at Ease Who Has Enough My idea of housework is to sweep the room with a glance. An ounce of practice is worth a pound of precept Fear lends wings No matter how long a log stays in the water it does not become a crocodile From townshend.mccallj1k@gmail.com Tue May 23 17:09:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fie8A-0000z5-DP; Tue, 23 May 2006 17:09:30 -0400 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 1FickL-0007kk-UV; Tue, 23 May 2006 15:40:49 -0400 Received: from xdsl-87-78-150-18.netcologne.de ([87.78.150.18] helo=TASAN) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FicgT-00023W-9n; Tue, 23 May 2006 15:36:54 -0400 Received: from unknown (HELO gsmtp163.google.com) (64.233.163.27) by TASAN with SMTP; Tue, 23 May 2006 21:37:15 -0100 From: "Augustine" To: Subject: Booming stokc markets explained with ready strategies CGDC Recently added Date: Tue, 23 May 2006 21:37:15 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 8gSQVif9umiGfJLG13jfOaoKNhQxyOeKFIl4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Create your winning stokc strategy with expert advice Premium stokc recommendation services that allow earning more Market pulses announced and stokc booming analyzed stokc market picks and analysis from world class experts Enter: We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0cck shows a significant up in sto0ck price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! C.H.I.N.A G.O.L.D C.O.R.P Symbol: CGDC Current Price: 0.50 EXPECTING PRICE in short period: 2 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. Conclusion: The Example Above Show The Awesome, Earning Potential of Little Known Company That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CGDC Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CGDC. Penny st0cks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Go CGDC. Successful stokc recommendation for winning players Mutual benefit by reliable stokc information Price-sensitive insider information on stokcs to boost revenues Complete stokc research information and recommendations There will be rubs in the smoothest road When yuh dead yuh nah sabee, and when yuh sabee yuh dead. Revenge is a dish best served cold The company makes the feast As you make your bed, so must you lie in it A fool gives; a wise man takes. Big tree fall down, goat bite he leaf. Like music to my ears It is a silly fish that is caught twice with the same bait A scalded cat fears cold water. An English Summer, Three Hot Days and a Thunderstorm Adversity doesnt build character, it reveals it An eye for an eye, a tooth for a tooth The best things in life are free Experience is better bought than taught Experience is a wonderful thing It enables you to recognize a mistake when you make it again When man mek heself sugar he mattie ah suck am. None but the brave deserve the fair Agree, For The Law is Costly Where there's a will, there's a way. A change is as good as a rest. A wise head keeps a still tongue. Nowt so queer as folk! It is never too late to be what you might have been No great genius has ever existed without some touch of madness Where the carcass is, there shall the eagles be gathered together Fair without , false within Mouth cut trousers nah ah fit Massa. He that stays in the valley shall never get over the hill! My idea of housework is to sweep the room with a glance. Fish ah play ah sea, he nah know watah ah boil fuh am. It takes two to tango From narrooballah@mail.austria.com Wed May 24 09:06:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit4C-0007ys-R7 for eap-archive@lists.ietf.org; Wed, 24 May 2006 09:06:24 -0400 Received: from 39.red-81-35-247.dynamicip.rima-tde.net ([81.35.247.39] helo=mail1008.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fit4A-000603-5d for eap-archive@lists.ietf.org; Wed, 24 May 2006 09:06:24 -0400 From: Mr Ballah To: eap-archive@lists.ietf.org Reply-To: narrooballah@ozu.es Subject: DO RESPOND TO ME PLEASE Date: Wed, 24 May 2006 15:06:22 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="121e7ace-c440-41cf-9daa-d7d975f61769" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format --121e7ace-c440-41cf-9daa-d7d975f61769 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Son of God, My name is Mr Ballah Narroo ,an old time businessman from Mauritius . I = would like to share my pain with you . I have been diagnosed with cancer of = the brain.I have tried all my best with all the money i have to treat it , = but to no avail. It has defiled all forms of medical treatment, it is getting = worse day by day. I have given enough of my wealth to my family members,and i do not trust = their competent to help me distribute the rest of my welth to charity which = happens to be my last wish, so i decided to contact you. I have about = US$2,000,000,00 ( Two million Dollars ) which i depostied with a security = bank so long ago in Spain that only my lawyer knows about and none of my family members know about it. I wish you as a child of God to help = me collect this deposit and dispatched it to charity organizations. Also i have decided that you should take 15% from the fund for yourself for = any expenses incured during this endeavour. Contact me : narrooballah@ozu.es , narrooballah@mail.austria.com May the lord be with you. Mr Ballah Narroo. --121e7ace-c440-41cf-9daa-d7d975f61769-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 24 13:06:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwoI-0001VQ-Ns for eap-archive@lists.ietf.org; Wed, 24 May 2006 13:06:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwoG-0001gV-90 for eap-archive@lists.ietf.org; Wed, 24 May 2006 13:06:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 92D834300CD for ; Wed, 24 May 2006 10:06:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 48569430082 for ; Wed, 24 May 2006 10:05:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E7657398007 for ; Wed, 24 May 2006 10:05:48 -0700 (PDT) Received: from hotmail.com (bay106-f7.bay106.hotmail.com [65.54.161.17]) by zoidberg.tigertech.net (Postfix) with ESMTP id D4B3E39801E for ; Wed, 24 May 2006 10:05:45 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 May 2006 10:05:45 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 24 May 2006 17:05:42 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Wed, 24 May 2006 10:05:42 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 24 May 2006 17:05:45.0252 (UTC) FILETIME=[4BCFAE40:01C67F54] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] IETF 66 Draft Submission Deadlines X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From orr.moghanrfc8t@gmail.com Thu May 25 10:03:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGQe-0006n7-E9; Thu, 25 May 2006 10:03:08 -0400 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 1FjFKY-0006sz-Ov; Thu, 25 May 2006 08:52:46 -0400 Received: from dslb-084-056-076-072.pools.arcor-ip.net ([84.56.76.72] helo=joeuea8.2hrz5o.verizon.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjF5f-0007kp-B8; Thu, 25 May 2006 08:37:23 -0400 Received: from unknown (HELO gmail-smtp-in.l.google.com) (64.233.183.114) by joeuea8.2hrz5o.verizon.net with SMTP; Thu, 25 May 2006 14:46:03 -0100 From: "Emory" To: Subject: Improve your yearly gains with expert stokc advice "HY WI" treat yourself to this Date: Thu, 25 May 2006 14:46:03 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 8kKChZs98uYb9kU9o296QYgXQaS5fG8DaPEa Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa stokc recommendations and managing solutions

Buy stokcs for the short term with expert stokc recommendations The data you need to succeed on the booming stokc markets

We found a completely new sstock and have an insider information that some big guys are going to invest into it and it will Boom this week.


Get HYWI First Thing Tomorrow, This stcok Going To Explode!


Check out for Hot News!
Hollywood Intermediate, Inc.
Symbol: HYWI
Current prise: $1.18 , but will increase at least 30-50% on Wednesday - Thursday.

About the company:

Hollywood Intermediate provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, Hollywood Intermediate puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of Hollywood Intermediate, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. Earn more with stokc prices going to the roof The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition.Unbiased stokc info and valuable insider data

Don't forget to include this stock to you bag!

Reliable methods of stokc analysis and optimal buy and sell times The data you need to succeed on the booming stokc markets

Read great new on this stcok





Opportunity makes a thief The modem is the message. Cat foot soft but he ah scratch bad. Patience is a virtue Life is just a bowl of cherries A baby is an alimentary canal with a loud voice at one end and no responsibility at the other. Take care of the pennies and the pounds will take care of themselves The Family That Prays Together Stays Together A volunteer is worth twenty pressed men. Silence is the fence around wisdom Money makes the world go around

Two heads are better than one Death is the great leveller

Great minds think alike, simple minds cant think of anything different When your fear cometh as desolation, and your destruction cometh as a whirlwind; when distress and anguish cometh upon you. All lay loads on a willing horse! Let us swallow them up alive as the grave; and whole, as those that go down into the pit. A friend in need is a friend indeed. Every bird loves to hear himself sing Let sleeping dogs lie. Better to be safe than sorry
The bigger they are, the harder they fall Without wood a fire goes out; without gossip a quarrel dies down Goodness is better than beauty

From fskoczyl@teenscare.com Thu May 25 10:22:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGje-0002DU-Vg for eap-archive@ietf.org; Thu, 25 May 2006 10:22:46 -0400 Received: from [58.18.246.89] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjGjV-0005K4-GK for eap-archive@ietf.org; Thu, 25 May 2006 10:22:46 -0400 Message-ID: <000001c68031$79b07c80$0100007f@localhost> From: "Cesar Ward" To: Subject: Last offer- Discount special for PE patch almost over! Date: Thu, 25 May 2006 22:22:13 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C68031.787F4F80" 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.8 (+++) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68031.787F4F80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C68031.79B07C80" ------=_NextPart_001_000E_01C68031.79B07C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a bunchedup without functional the face of oration grew capitulated Black tenderness mouths, the vitruvian swallowed up the sun merchant air was stipulations with suppressed assaulting The wind skulk through the long resisting and sobbed and ceremonial the secret flirtatious ------=_NextPart_001_000E_01C68031.79B07C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby ------=_NextPart_001_000E_01C68031.79B07C80-- ------=_NextPart_000_0001_01C68031.787F4F80 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C68031.787F4F80 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhQgIDAZEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAgMBAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTlcHAyeb8VbGOXOXQBDCA/R6233TB1gReECoBsSW2AZQp9HY8mgQOTG5 UllxaWLYQbgJ4/mJEQi6Qwr2mEm5CJOK0WryChGbN9J5Y9qCyzBKpBt197eAuqp4EDdXzJic rMDsvBipCN32djxtnNi8nK3NLelt/a2NjXz9XU6+GoEHjADcx/7O124Qv9dOn8BXX1iYr/+v Xz5794K9q/fvIEKD/oLtKehuoAJ4/R7Ks+jQXcWC/xQrEhSYUSHGi/FGScwYRN6mYeKUtWTp 8qW6lthk0qwZU1pOc+ESoIuJoKdQnjN32jSKdJY/jxrvbeTllJ/Uh/qk7ptKtYEhh/M2Uu1o daLYrF/BNt36NOxSrFOvqrW6ieuCrljlkqVbRKUwnUmJpjOHNOjMnsqi+cU59CZNwogPJ/bp OPLRuQHv1r2MGWpWtF8te5079q1ns24/d2Zq+nRVdpsxs+VHOvOuplU9y0ZtRO84yOfA+Z4s rWjhv+omPV7smxnOwI17h4MGtPGzctvIDTp70TZUzWbVotQNsPJ22qrBJ7Q7/qnCuBZb2yYr 0Gvp0uThra+P/f4R8IJ3G//+SVgrjKWz12RAPeMAgEUdJ9g0wg3Y23ISRgdBerW1dRZt3Z3G Wmr4XajaaB6adpWFIdIHW3uiaaZRbCKChtuJH7KHhEi83YgMgUf9xEgDARq4Y3HE/CbJbswF aYyEhi2m44GKzWLifPK5tmGJGJJI3m1asvialTFKCV9aX2Y5JW4Mwbiiay++5csQwSHXSJzT RdiNkAruxU0deg7mDWQOPgiYcnsWSOeECBYmnAPZLeQio2W6lyGkNkYknkidSNSQfVxhytGj 2XnSKD5ksmWjqGEyahI9l3bYFqdtHgLrE682MSsZtT5wa6y67hqaFrmC8atWvA5LbLHGHots ssr/LsvsC216Oaqvwc6GAo3NXostZXatI9prvpIwrQThepttuWWYiGu3p2YxLpqaeNCuufI6 wd55KIXY6raaWrtvmR/BFpKrn63HaWf23tupo1eGx9AfbvU74rwSbxFXR1yiCKbFZGo8ZlQA dQwWZ2uW1fHGkYa5Hccykjtxy+wWDGaMaaaoZnxa4uuvhu3xe/LKXKKss7Urq6idy0aHkfGi 6sbMKn82j4xiZouyxqrOIPdc8b4hUTsz0eYdDXYXGSvaJZWQCusiujmDRjWaUd5MStREzxi0 h/GGjXcOb7+Hc8zvgUo3QuTuvfCFFp7JZtxbhob439HmDTmtMGc6lsiT/64KCuaU4kxlQBvW Ze/QplKaasjaDg1fqZGvzvq6rb8O++t3x0577bbfjnvuuu/Oe+++/w78xEoZGcPwshhv/Ayv JN87wulOMbslfCaYqGLESz8hHdUfb8Ty28cwa/QrzJ6r+DV83kNyjnxfPPvrZ8B8EPGXEH4S 5ItCBfqfVHaOdYVak6dtKKhPDRrSTvZUjWJQZ0h9Ug6i/lQTOTWJL86ZIDX41MDfJLBJD+Rg hSBCOYCVDlUYUdin+BeyyZWwRQGTi0qo1kKKxFBhKwTJCGVjEBSexHmWAiEJWWYHpSWpGhTq C5CQVMShZOM4F2yOEYu4HCVK8ImPkeL0qKhAyf8cSVwqI9nMTEItFlkOboKbyOfwAsYv8swj FbsaGyOWMiy9sWvmu4DTikTEBWoRgVVc0GGQGMU9AsZIDOoPFpEIIUQOso9HDGHgvog1YTlO LGnr2YdqI8ZIrquS7hpbyTpZM6iZzQ9CLNIhT3nKYVSHOE8yICoJiJxGpjIyq/TPnxjDyAMp JWX6gUsvU/fLO3pNk4BTj6ouWZZfWk1dZByZDx+Jsk9p0nVBnJQpc5nLWV4vOjAJpCJvZMgn 2vKbWzTOH5UkSHByS2Y3e5Qo08VJZr4zk+zc5Np65Ul5igx13iJcHe3Ivx7hKJ26JGc4F0kM Jt1JnNZbqDnJyUTrARL/oQaVqCQh6UY1+a2YW5Lb3uiJUcZZ8p7l8Sg+Q/nRtXSPkKsMEACz WUBDZZA6unQoLLlJJJYutIP/SxQFEYVODvLFgRUqlQoTthBgDiSHzlNqqjjHkdLRZ3SbKVh9 rOqp0M0noD1MTVfzdbbgucF9hPrBP98FgrOKda0oIKoqUrIfEaiVrXStq13vite86tUF8yvr +yTQV8CSdXwciBe02MUsoRHrTdQTQWAvwaMTBBag1tSA4iZgizxUtrB4U6wF5uqDyBYBsoMF wWQ/Sz+yYRZE8HpcBkB7LnfZ8Qqb5dGhgFooPzFQqAEETgCXyMDgAgpOrkwMLm+q2o/REISH /1MVwRAGLYiZEboa2uFISBdVGv7LYDzc4Q1LeJCDZRW6wXRkSUhYEoc5EqmwdVYpCzrQVjY0 UH5U6Dl9W1GI0nI4hXxer8zkzK4BjUPulO087cPOzJURk1XCDshMF1KoNpPBGfWZgaEgTMZW 8EgQculf5BuYoRZXi4bEJkEhZM2vVQ5EUdvoiuf2M9bOE5osMynfZlyyLuYTlDe2cIVbbIUM N9GJNHWOHw9VSBPHEpUx1a8i3XpRwymzucfM1L1KhDnyVkqFILWqNGH0M92kVEw+ButJtVPe A1tqa1UQ8pIHlMjsMVmb8IWpBZ3MUAoUE13pIVwYaQbEGwvNxZik8f8n+0nMZe54n80cc4Td RtuA2hTEOQLniIFD50lvEbeZJnFp93yyph2W0JF6mMnkyGKNvridh8YxHTN6ZcY9bNGNPnUZ BsXTlza5TgedjnCJu9sFOvF6txWxb3c5NSs3ZNmzXuo8qFue9ZKO0eadUeiya88ef7Wq25LU ek212dGJO80Q0RS3pUvNsJ2WWO3dKyfcPQLkTqyp8C5Fve+N73zre9/87re//926ddMgzvIr bQrkLVmDRwC427yBwC/w8FWHorUlwDUcFB7aQY4W4xXnuAcELloo2gDkBo+4jFHr3ygLouPh 9CsTTA4Jj8db5toLQSZgXnPTlpzm67TsB1P/vnJRSFpId+ZpfHuKDl3zRuk9lUlyfHrTnyJZ 4xvmdK6HLCjkClCVwSUyfUPOaV/fsqbCrnrYtf50O/2n6xvWyQbPvlqmfhfLzt7Kc58td696 d9qvfS+ulXz0Kb50yHh6O0zgfF914rnDJx67nfNMaYKWuL54lDzgI0pwOh9U825PvFYaVWqJ 71Nt9XSwgAfh9+A0fpwUYlAl/v5r5uy0gJS/fO1X7/X5NlLwbA9xLWVqUNsDKZHGhjzvJ0r0 TXNN290CvapdJ7cf972ysG8p1V0qXI1HXe2AH46RWT/577sEOoe/JYkfaH7WmzP7Le8+8F9J y95y+KeLp3zufR/+/yJebtpaE/Ad6Zll/ZRmMcZF1Jd85ad7rXd9w6VOCIh/cjZs9+cn/aN+ t3cT3UQomUd8RPJ4xydOHXhfpIVnLcd5B0h1UTZobHJyyERoozdhlOUJsJckxqd9gSJRGFhp 7uckR5d/lYZTGWiDDJWDCRV42/MjnZaAPdJ92eRpO9iD52dfwWeCFsVjGIUxtvZOS5NoCzZz vTZA68d0cOdBrcRH8dd7umWBuWVxaMhb8teGUAd2WbdTFFR8ulV0HlZ1U2dBYPhH9Id0l9Y/ cgJ2y4dU2EZ3m9JdeLc5hqgtjWNu7fZWdIVzAEeJ3CNWUFaJmaiJm8iJneiJnwg+PvcFpv/w K9MSLL5QPtfxX2rgWUpAb/gDLKJIiBgGdCcAiak4WxGjA5BYYK4ILkgjixdGL7WIViyAiygX aHoTirrYC7/4Mi40Q9p1GSdEXeK1MNK1Xez1TO81NXXnQ/tgjSRRbSgkQmwTjT+kaCKkXuSY L5X0HdvoXeEFj9AIaWEhjux4bjnzjtbobQwjjUxxMLw4A2hUNqjhZ3YHaw/2c+iBhfnEMd0m fR7DGRApkS94jSvSYBGGFxHhVQuWRj6jYFeyVahGax7DkSF1RiRFkD1GW6zWZ9M0YK/WNqwG ZjBZayIZSmXGTzvpaKfSNjo2Kk2zhWdWaO60Y2wzTJO0Gio5ONP/9JNc05N+E2TkxmVwU0r+ tDNWFn1fdnqu9pDVVWUaKXpnJmZBmZX+h5Q3SZRcOUllSTYziTr1wpTZ5ksn4TXiNpQ7CT02 6WN+xmPccZY+uXwlCU2m5h15SZitRnox9pRoSUlzyVE6CYDCGB9CqZQtApmD2ZRwaTiImZNS 4Jd9uRYgNZeFQ3peaTkOaZCemYWKOZQ8VJp0uSaNU5jPh5JQCZOR2VxN+Un6E0+O2CrS4lze WG1JZW6FqGzS1h3bxjBMo17TlY8XKTprJmrdNpEbY1QtRJfc8Zy8+W3PCSrZSZtUhY12M14s qTnM5p3RSWb4pFWdUzWsI5D7dj8TlwLz/wmKyZifq0ULzkJY+wmgASqgA0qg/3aM/2kHaYWf Bcqg9uafFMcDC9qgASqQhuUDEjqhunJe46gvOnQm3ZiIMhRDWVOedIRVGyqNYmZd4XWOKPqN CZGhvMOQc0RgKjdgBEijUhmT0cZ80aSQpumR7ZmjGAKYMao7USlPBdmepGiROypDvdg3rJmF KelMRWqkuMNLYVlS4Ql6wsSWOvqiqjNetDkaX1qaKaSlU5VsV4qlIxVgl7WcKZeYEoeZaklS nuKUEZlZq8imsIOkO/piLphqswmnoRacbyqlWCmWrYGjfeqn4rk2ldVVIMqlwGmc0zV3xnRu GAOpGnVUaGqpYf/aqI4KORjqBaZKqvqGqlywqqnqqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrOYSANEqrdNKrdVqrdeKrdmqrdvKrd3qrd8KruEq ruNKruVqrueKrumqruvKru3qru86riAAr/NKr/Vqr/eKr/mqr/vKr/3qr/7aAf8qsANLsAVr sAeLsAmrsAWbAdZqNNQ6BhD7BBJbBBS7O9XasNMKNhb7BRy7BB4bBCCbOyL7ABh7NCSrBShr BCrLAyxLOyZLAS6LLTJbBTQbshq7sjj7OzYLADD7sDoLBjz7A0JbA0S7Oj4LAUjbMkb/WwuQ yLSaxQFPGwNSizdK6wBWKzFPK0wnuQtOC7Tr8F5CF7VfC7YrWAJUGzZYywBqK1d7igVai2Cf pyheK62op1KAEC5CC6MsgLYba7Nsq1mjCgVwq1J3p4jYtlybNQE8uynf6VxlhIgI1lR6W5Ha RReveLVke7F/27fc0qGNm0PYNbSai1lxe5KNCzCQe7ntwrhxG7pR8bqve7qKS7nosbqqm7F1 CzyAmwC8+wEfgZDl5jC36wOE65EEc7ewS7yYKwGtu2a4q7zQa4i4QLmwC72x+yud+7Oku7ba +zyIc0LXu5E7ALfPG71ceL7mwbwly71da5IqKr7xa5Ldq7t6/7YUy9sh2bi47Xs7vnsA/vtu goO/4qu4NmC8yiW730G8lLEBrXu8ZiS/2Iu+C1C9TrHAw6kB3ru0nMu/aXW/EbzAQHDAs/vA qXu+wNTAHaxcJzzA6RvC9ButyMhcaPSRF6DBEwPAPXvDgynBLhykxavCctuIx4m8EkmcGRzE d5t3yTm9yYm5FXy8AcO1NpzEsJPDORx0UdzDkSvCVTwFOwzBJwDGJjDG0MrB9bu9MSwGZVzA H1DGJPDG2XLFcVwGdNwDdpwCeOzGXtw6c8zHyqLHOhDIZPzHNDDIyeLHhXwsh3wDjDwCjpy7 auw7Dru/kJyyiuwEliyvmDy1nJy2if+syVYQyp2MxkwwyjHryWl8xgvLyq3syq8My7Esy7Mc rqhMy7eMy7msy7vMy728rbbsy8EszMNMzMVszOoKzMeszMvMzM3szLKczM8szdNMzdVszeka zdeszdvMzd38zNnszeEszuNMzq8MzuWMzgYrALo8AOnszrVcyd0qD9F6B+H6Du4KDMRcz9Ka z+a6z9jazwh7zwEwz/T8z9ca0AXNrtJArWwwrYqwrRAtrQzdyipBrwc9ressrhrNsPG8rf+s 0RjtrSKdriSdywNN0Ots0iPN0QDd0gW7zyFt0DO90vUc0y+9rg4dre080TodADrt09YK1Dz9 00T9yhyN0+3/mtTCfM7WitEKjdIondIurdJIndADbdMhfdUpXdUr7a8gXdVOndX83M9QjdVX DdYBPa8mfdNTjdBhzdVLba5B/dA+PdTZetc7nQiwrNJk7dZcndFeHdf0/Ndb3dZp7dcHPdbz 2tRi3dKKrdVuDdbZms9PDdcEbdAiPdaVHdkHO9lsvdh+/deFTdNwvdiCXdJqPdNTXdOmvdo5 LdE7XdQ9rdd4zdN2XduurNaKzc+E7dtO3duSndGB7dsxPdyiLdOj/a6N7diindmcHdVyLdla zdnVutv3fNgKDdNWrdzITd1t7dyJ3dXQLd34DNmB7dVS3d3pKtG3bdQUja3wTdu6/43ZwU3W Za3e1JrQ9l3fv53c/Q3gSO3f9crcb/3ayk3S6R3Z2W3d+F3aD76wn73UDD7dxK3fYZ3gqn3R j43TqG3Z7UrUQx3b8x3RRp3bFW3d+p3i3/rfj33c9S3g/B3jMc7YHq2t3C3cIE3aB97gGL7g M+7jD17dv73d4v3WQV7hmK3jrH3Zpl3eJX3gHx7er93ZOU3iJ37ls12tuI3lEb7i/E3kAB3c NB7gYy7jL97iBG7jlC3VaG3VN53fEB7XWQ3npY3dTo7a+WrRgG3gaY3fb07dgH3WGv6u6o3Y Fp7ZF/7k4irfFD3iWP7oj66w1+3m9y3Xgy7ogw7olt7VfP8e5+xa4F+96Oea57Rc6rw86gpr 4u8ssB1O6mrevBH+6aRO6Kg+68Gc6gm76qzer5Q+rrUO6mvO68NO7MVu7Kt87Mmu7MsuzqHO 7M8O7dEezM4u7dVu7dfOytSO7dvO7d2er9ru7eFu7S+05+IOruBu7une7bmu7uiu7u8+7vDe re4u7/W+7Oye7vRu7/te7Phu7vrO7wH/zv4u7gAv8AdPzgQf7gaP8Nys8AO767r88N2u7WZt 6Z596gnr5hMv2MD+r23O4SF/434+8UW913od1JK+5SeP8nS9riW/7dS+5AaO8Sft5Kn90TDP rsY92BAe2g2e5OfK5Xmd19da9C7/r9QNX8Us/tKG/uaZXucZ3uQb7/OGTec6v9F4PuGhremA /t0X/9xYz+ZibeRM7tLTnfFGv+pE7962feIqr65iX+0VL+XhvdmdXdlHjuBN/txAT+dB3+vJ DdqXvdrnXdxIftpyf+RN3+E/fvY8n/Yrz/Js3+UN3fayreX4rPSlzL5Mz+EXTtxXD95nj/Y/ n+icXuHlzq+avfWFf9aIbuQWfevm/fmwf+tOj66xDd/yLdSSjvRQvvkB4O6TDftKzuPrbeGJ 392vb/bN3+pJDdpVH+WN7/zorfhjb/fQ/+R1P64hvvbf360u//voev3QLvPOzf2eDuQjj/h8 b/YMPuQA/67nTX/8ia78Ob7+XA/48FrlBBAp8pIVeTXzjJMXy8HGbv0CP08jTTJLVWht3ReO 5ZmGgRvPdSA+fMeHCEYmlCCQeFkQh8Jf0dKcTIuU2rVqTEqW2iMUCYR+h9jeM+t8oi2QLbvW kXPmdNFodE/IUWaM1S9QcJAwZucQp1BRCXCRyhGyYSuScqWxcrAPM/Jy0/NTEBER1Kxs8Yt0 0DR1s5NVRvM10FW21lb00FZ3l7fX9/eX1g3VcVKhRvg0OQN3B/gZOlp6mprrxahyeVr7olmn GjxcfJzcT1vI7ZENjjHCaTjd/V0syqorZW0+qsY7p/wfYECB1M4lMciiwrEM2P+o2JP0ACJE SQ8VRsSH0F1FbhL6JRr4EWRIkZTOJVQ4TB67hwxNtmTI0iVGhAvXyDwpo+ONkTt59vRp6ZoS a0NhSLzpsOLMmElvEjWaEKahnD+pVrU6sCTRpi0vMl168ilSsGMX2oSqVGrHq2vZtoW2bB0q uSrDjOmSjwmaMj/w0mpyF8lGBjl5uDV8GPEnwb0aLRZai3BiyZMpzyoX1zEYyFMrd/b8uSxo WZFFlzadOPNpM6RVt36V2lasf7Bdz2B9jdjKxsaw0A1pkPcZS8FlEQNuj7jmVVf4oNBDJ4/s 6NGl96jt6XYLJiqMJafhPaBefciSgQeVsUo8i8HvPTL/c8cDnxDw41cXQZ8QbU4E9XPkjLsd 5Cjqrr30Aqunrin48m0XfQpcSZ2+vEhpQpT60+6SvBoaj4t5cqPhOehKOGEP++qzozrrrvuj kOyG67CNCDXrkMMCI5rkngVjBMZBDuF5w6J0NFJwvSBJguM49fDxcEcQ5cPjgwDwk9LEEjmw 0pwr8olRvAhTotGLJdGBh8g28gLkwsH+c+GuLbk0EsYNdaRRNw/VYLAWIx+kSE55+BzwzjbP A07JBP9Asr8nsdxjUSrrSKG5+Sz7ziaWtJjoKEzP2oqFMV8y6iWl0kzARe6KfFNI3vxcdTc/ y3xVGilgjbM9V5ssk0DzBCEU/8E/l4yTOREbbU6TEDMI0dgZMlvluO001Uq5Dzs1iQyzKkTL j1J/fVXDejrRkVWM3gl3Tq54vFTVHIPMyFl1O4UTEjg15PXWdmkjUVgo9W1UWHxLQebQZ9H6 NjS4KgiLrFAzJURbMa+VFTBGvFzwSyKPqBVPXeZyxUZTxPuS4ht1LeVjvMgUkp6TmVOUWBTr Q9a5R0tMVlmAh4qqKZjEeoq7gxOuFGFsV1szz1G3/Wnk2f5JUZzULtZTwpM9xuxbiP8CA+OQ 02x40IzJS/oyaX9beuwVK+Ha7LTVfsbotRtA2+245U6lbbnhnhvvvOPVOxSi+f4b8PwCx+Lu wQ0/PP80xNPqR/HGHe/q8RYKj5xyvOsu6ruCMOxl8so9X/tykjDXjnO/Pz/dcla6bFZTW5dQ +XVeOkeddtVCZ5PPoBfeFD3eb7fN9NqFX/F3oGbi+VmFoaqW01dmH76z4iFhOhzpIae2+Z1/ dqp0tYoiA08crcdtfBmi7k0Yr0nZ2EKVD51Qv0jzdTRmmlGkblLVWydr4d6Rx152wftVt44W DbBhgl4k25wv0IMxGLHHToKAz8xihqX7VIlK8/sX3Z6mhpQxy059ad8uZtcx3RzIQFkQw19y NbERZg1dglIEkNLVIwrBL0EbO6Cy0BTCGA5QZH5Ilh4uaEEM0sd+KoJeCXv/FDD37MiBOXri CnuoDkMhaE47NJW9aFIjeX2KWxHMBjsaeCqaNORWsFDUsE6UQTceq41S4pfNlijALgrohbsB FBbRQSAzPa0dddpQGmboxTP26YsSa5MMPREXiV0RTMDCwhqfIz/6pciSGqQU9ALAxEcOcoqE IlcfM2TGPRkoXLMq5BPT1StbhXJcpdRi5lDmqyl+Mo0x8NcbSyApF8Asf8PzJLBc5T8BjfJg sgyjFXF1qnK1rVa5BNe6JMJFG4FSdNgcUi3FJ6735MtYwNxXvzRZM052Toc3vFFgPCih15HR hiGjxyJjCcldJemMZzJZXSiGSrEVUp9hShkUaShE/5bJj5IyY2MlFaolTnbSjrOR3iyPVJXy FYJ64Lhoa563jX+SjKKc+ChWyAaSjaqmow9VqVtOepqUrhSmVmmpaV4aU5v2ZKalqelNeapR Fi5HeDvt6VCJWg2hFhWpSe0e45TaVKeOgzCFeepUqfqLqEq1qlnVKiuuitWtfhWsjuiqV8Na VrMSbqxkPeta2cqMtHqkrXGVK0Tf6o+53jWsddXrXvnaV7/+FbCBFexgCVtYwx4WsYlV7GIZ 21jHPhaykZXsZClbWcteFrOZ1exmOdtZz34WtKEV7WhJW1rTnha1qVXtalnbWte+Fraxle1s aVtb294Wt7nV7W5521vf/jQWuMEV7nCJW1zjHhe5yVXucpnbXOc+F7rRle50qVtd614Xu9nV 7na5213vfhe84RWvcgsAADs= ------=_NextPart_000_0001_01C68031.787F4F80-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu May 25 22:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjS87-00061M-WF for eap-archive@lists.ietf.org; Thu, 25 May 2006 22:32:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjS82-00049P-0n for eap-archive@lists.ietf.org; Thu, 25 May 2006 22:32:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B66A84300E8 for ; Thu, 25 May 2006 19:32:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CE4E8430054 for ; Thu, 25 May 2006 19:32:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AEBAA398046 for ; Thu, 25 May 2006 19:32:18 -0700 (PDT) X-Greylist-Status: Sender first seen 00:16:51 ago Received: from infosec.pku.edu.cn (unknown [162.105.30.183]) by zoidberg.tigertech.net (Postfix) with ESMTP id 78132398014 for ; Thu, 25 May 2006 19:32:14 -0700 (PDT) Received: from infosec-caozhen (unknown [162.105.30.181]) by infosec.pku.edu.cn (Postfix) with ESMTP id 3032A1C960 for ; Fri, 26 May 2006 10:15:13 +0800 (CST) Date: Fri, 26 May 2006 10:15:00 +0800 From: "Cao Zhen" To: "eap@frascone.com " X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060526021513.3032A1C960@infosec.pku.edu.cn> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.866 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS X-Spam-Level: Subject: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1150052152==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --===============1150052152== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi Peter, I have two questions about this draft. 1) What kind of device you are assuming for NAS2 in 3GPP2: such as Home Agent or P-CSCF. 2) Could this solution be applied to 3GPP2 MMD solution? suppose NAS2 is a kind of P-CSCF, then could this solution establish IPsec SA between mobile station and P-CSCF? Best Regards ------------ Cao Zhen, Ph.D Candidate Information Security Laboratory School of Electronics Engineering and Computer Science Peking University Beijing 100871, P.R.China --===============1150052152== 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 --===============1150052152==-- From support7xhd683@redeyemail.com Fri May 26 11:25:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAU-0003bu-EN; Fri, 26 May 2006 11:24:02 -0400 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 1FjdwA-0005XS-U8; Fri, 26 May 2006 11:09:14 -0400 Received: from ayn156.neoplus.adsl.tpnet.pl ([83.27.125.156] helo=zehuxa3.izq55a2z.rr.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjdw9-0001Ne-Ub; Fri, 26 May 2006 11:09:14 -0400 From: "Manuel" To: Subject: stokc analysis tools and tips meant to increase long-term profits HYWI Brand new Date: Fri, 26 May 2006 17:09:20 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: ugVQ1F3JW5jKUU8YXmqPSZUiprt0v5UFjqDD Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Detailed stokc market information for beneficial cooperation We found a completely new stockk and have an insider information that some big guys are going to invest into it and it will Boom this week. Get H YWI First Thing Tomorrow, This stcok Going To Explode! Check out for Hot News! Holl ywood Intermediate , Inc. Symbol: H YWI Current prise: $1.24 , but will increase at least 15-20 % on FRIDAY! About the company: Hollywoo d Intermediate provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H ollywood Intermediate puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of Hollyw ood I ntermediate, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. Tips for successful investing from seasoned experts Investment tips and stokc recommendations helping to earn more The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition.Current stokc data analyzed by experts for earning more Reliable methods of stokc analysis and optimal buy and sell times Don't forget to include this stock to you bag! stokc purchase recommendations and short term trading tips Read great new on this sotck Every little helps Belly full behind drunk. You can lead a horse to water but.. how?. You never know what you can do until you try Lil finger point to de big thumb and sey nah guh. For by means of a whorish woman a man is brought to a piece of bread: and the adultress will hunt for the precious life. Mother knows best Once in a while, right in the middle of an ordinary life, love gives us a fairy tale When words are many, sin is not absent, but he who holds his tongue is wise Business before pleasure Loving life is living life to the fullest It takes two to make a quarrel Turn you at my reproof: behold, I will pour out my spirit unto you, I will make known my words unto you. Past cure, past care Take a hair of the dog that bit you Fish ah deh ah watah but nah ah dam tap. Beauty is only skin deep Cat a ketch rat, but he a teef he massa fish. Fair exchange is no robbery Well done is better than well said From xypjnrfh@email.mot.com Fri May 26 12:22:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjf5F-0004AC-3C for eap-archive@ietf.org; Fri, 26 May 2006 12:22:41 -0400 Received: from [195.158.73.29] (helo=home-zn9byxn8h2) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fjf5C-0003U2-0v for eap-archive@ietf.org; Fri, 26 May 2006 12:22:41 -0400 Message-ID: <001401c680e0$9623b530$1d499ec3@homezn9byxn8h2> From: "Mansfield Fritz" To: eap-archive@ietf.org Subject: rubydvj Date: Fri, 26 May 2006 18:22:30 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C680F1.59AC8530" 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: ba0d4c5f57f7c289496fce758bbf4798 ------=_NextPart_000_0010_01C680F1.59AC8530 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C680F1.59AC8530" ------=_NextPart_001_0011_01C680F1.59AC8530 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0011_01C680F1.59AC8530 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
------=_NextPart_001_0011_01C680F1.59AC8530-- ------=_NextPart_000_0010_01C680F1.59AC8530 Content-Type: image/gif; name="ekzvtdzogblpnSims.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01c680e0$9623b530$1d499ec3@homezn9byxn8h2> R0lGODdhPAJ7AocAAP////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /wAAAP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////ywAAAAAPAJ7AgcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXrxlhiRVLENZBswDQoi24dmDb hGPfuh3LFmFcugvvnsU7V2/fuArf+mXLV+BdsnsLywXLuDFSwW7PGjYsF/LispjrRt5ssHJg zZzTZh7tWfLoyafblj4tOrTj17B/LlZrmjZkzJdRp+7sundr3sB/c56tm3Vx4sV1I0+uPLbz 5zlzM29tG/Tk3NKFZ77MPbjd79pR/i8nnbd8bYbZoatfXzI7ctrCVfsOb307eO/TjYs/jz++ ebjgpUcfewQW+JF7hyEG32/y5edegPfVN+B8Cw7Xn3+fZQicgAIa6OGHED24YXPHUVgWYANW qF94Im542ImDWddiWih2N+GKIOaoI3r/2YfhWgmaNiJ/F7LYo4/JddgggERqxuGOUEZ55IXw WebaeEg6GaFxM2aJIY/zmZhifhJKaWaU7/FnZZJbfmmhkCsut9ptZNYnZ3Dj5XnmnmfSmSaL KjrI5W5w1klnib0B6dBqbIbGaKNh8ilpgTH++WeZlCHWWWE0+hVkXigSpul0gTIJ46h/iRqq qodO6uqr/7DiuFKHsdZqq4G0tnfrrrzumKtIv/Yq7LDEFmvsscgmq+yyzDbr7LPQRivttNRW a+212Gar7bbcduvtt+CGK+645JZr7rnopqvuuuy26+678MYr77z01mvvvfjmq+++/Pbr778A ByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUVJ0jWpZ2iyupflXIKsn6Mxniqp5JpbNan mb44oVoak1oox5ux3LKnLsssoY1OxtyxyBiHWOaCrV5J5aDkDW10kUuzNmdgs5UqZqK1lVay hm/aqR3PXu4cNEVFU6czyV7L2OSY9D0qJJY0E7aXoVuqLfZtd5qaNNVhpw030/5f26232A09 GWedbmoZOJh/+yb1dXUt/rLi59ENod8k4o1p24P3/VDYRC+KuKA3Mqih4OVx/bd0Kze+93em 7/fj5G2K7rSjsTveuuZ+q3ycx5tidznhMGMNNMhA+470z3x1Th3LqKNtuOw2+mzk3Vk7vx3z seM+89mZoudx3o6LljrlnRbKetw536i87VNCLjvgQ9qVfuXV386++dpvHz/++ouJYJjNwxT1 mra10UEPa/w7nY+iJ7y1sUpT9ludAPNHwJohMHe/Cx34LpgeReHnUAEUnwXJhyOajY+BGOTN ozx4NPVlj4IVdB2WEsecq+0PbTPs0grNZqrxwS+BZP4y4Q+r98GUFRF0z8NfsL7GOfpZb3o8 nF0NHUg28rXqaXZrUAhfWMAaBmpJ5ssh95q2RcLBsItJNNnHirSqk1UxNW0kHl2MB6nrfQqM MLvj/BCkmKqZTHc0nKKLQqYYn9nsjIhMpCIXychGOvKRkIykJCdJyUpa8pKYzKQmN8nJjmBO MJwCpEVul0ScLDEsRKkUENvXSffpiXYH4qIZucJCkJzySLVEZStrNzYseoSUsvJKLn9JzBti 5JaS/CTwQrQxGMHRh6L6YRtDCUHQ9DGU1ixfYkCJx46JT0GE0maqvNm9yDSzeKWr5nVQtSpk RlKZGtzcXLLGQt4BSXmVq/9no+qpIj8Nc0n6HCGNzEmogLoun/ekGtQEqs4vuROSgMTcydDp pSqVjaFKfF4/6edLKEpRi7CszhBLlcsKgXGZGBWoE3fpyiah7HAVPaggU6o0JG3UoXg63kdt ukDASS6nWTppPGkKqGGyVIHGlCkCb3rTnY4zkIq650tXWsuoNVSm+JwbQZEnVX5OtXBDPShA wTlLTcIThZ8bqVJ3iMP++dB00KyfeX4qVvtEdZZZDadH4ZTVpj70kfCEopJKaVGdDlGlZHzf WhMnVMIiqqqMi2wTFSvNNwaVo5D6qyPrRsDG3qehBrXnPBUb2goaNLLZVGg+h9PXzsoVp4hC Imb+Sbu7o14wPnEkpxx5Vz7VjMq3ce2LNKnJzf70MYNg1W05hZtH2F6JncmD4G/1usbHwtKb RrVtTTTrE+5qt16ejYp3v0uv3Ip3vORNr3rXy972uve98I2vfOdL3/rqxGZd0tUqSUgT3t62 v57kyAw3AkyJFFhdcpvJgYuSq+wqWJcacbAtZSm0/aJrwDJZcCorHDqY/NW7Eo6lhT03YnNx LFRRhW5wuwfcZxrpmnElrqrgkryBLvdUr3vRylSMG6sW15lA3p18pKugOZqTx9xMXY2f2jvc 4rGZjYNmV48c3nVdCqSUoaecSqucyvDzulwe2/IGOFvQhpm3AKWnmhH+WlDWahlPHoQsnNfM IC+H9HpEfJcvOatWrXWxqUtL8xF1GNuZYrnMpQx0Rnt6WZ5a93iHJvSf61hokpLZXfh13+sM y1RKTzrPnw4cWT0tZ0EvtsN4GfBP6RrN9x3a0I5O4aovuukootdaJwXuaQG9T8MVjdVGZd7w Ui3kOJaaenmsEY0LOzSXJZvYQMbnqwUbVIoiltkzdeiSV4rpKGo0pn6eNadji2FaV/Y/rz42 /1it6UQXGn7qVu20VXtqXrvpxJFCsLdj3WenjvDXaWx3IEONxteaus9wFbOiCU7XeMMasfRG OKmpi9V8p2vP/P7ynFfb5U29luO0lZFfqWj/44OHWeR0PvPHS/7xhKa2rpoG7ZttbdJ3z+vE 237yinsbZCe/eLrP/TGTcfxFNDvTpFAWcgmNLNyei9PnQT9h0nVe1ForN5otdlTSg17nq4ZY Yh0k8MBuzV/4NrbKBu4X2o8ZTLMP7+psV/vbBTx3+9r97njPu973zve++/3vgA+84AdP+MIb /vCIT7ziF8/4xjv+8ZCPvOQnT/nKW/7ymM+85jfP+c57/vOgD73oR0/60pv+9HeX3kXIrvqb +Pe/HWYmj1vtdNTLc4Icrki5PVxij/sewiYHs+3Tzrfbj7L3Kdk9qN4G4Xo7dvjGt6tUe1fS ppdomqAa8vRp3zIc/isXxdNlZwF17WkmsTt80OfgaGdbcZAf1oUdb/mdIe5c0a7JP3k7W6fr nv4HdhPcp3Vu5QZs7sZuveRu8LZYa0dETPV1/fdwpEZWufZo/rdwvQY1lgZU9JeAVUdZBgSA uPeASHUzRLYfQKdSGag/ugZtTdZ1wWaB2eRVMPc551d+IlhFnkU3eVVzAweDEYSDJKdUFhJn MUhiMNhvN7hoExhq1Wd1ABRwXVNw9NeEPPNWmRV7bFWDSdgmTUhaPOhqo7V7AShnw0WB4ZRd /+dbW/VfZHhwW1iBiaJiJ2RNSHZjGnSC1peHgDFldih01jNWW/dr6SMyhPh6b2hlIXiI/w6T f4q4iGTXiJAYiZI4iZRYiZZ4iZiYiZq4iZzYiZ74iaAYiqI4iqRYiqZ4iqiYiqq4iqzYiq74 irAYi7I4i7RYi7Z4i7iYiwCjRsk3P21nYK9XSLyoi9uViM0XcSGBhlNDjKaEfGCzaMBCaxrG jCwxI7ahZNu3TslWUzu2NbOncPkVe9RYjT0SPFk2c+/3Hm0IalIkP844jiZhjZUGhWJEbv1z j7UnjvCoEvJ4b/S4TcfFbYzIiHu1jxlWjpXmbFG4RcHmi+2YQgYJYA3kj3ylcLbWewQphREZ E/hGkShokWeIj372kI+4kcd3N6OGRg4XKf8HhujGfBppkhw5Tf9QJlQBuTwD6TTf+DLil4dl JZNAGZRCOZREWZRGeZRImZRKqYolKYqqRGCtB5XDqI/yc0j8aG3bNFGh6Ce6B3tiZ4wnORJh 1090tICYKFEwRWFxB5bPSBIiUnMJ95OW2DwyRmXDlhg99k3N1ULd6IdPp0Q1VoJZh13cg35C uJU0lnIStmcuZ2MFOWb2yG30Zo7x55LmV3Z2ZIiZSIggyJLhpldqs45HhI9f6HzZh5nsN4rb JnGe6W8eKUchOZpMw4IE9354WXxBhIo8SIC5o5DX9ZjCR31v52XYpoNflSEJJitNmX67CYVx EyEt2ZoCGX0Mh4CDBZz5tpyj15G8+Zz/jWZzDClwdHSB5HmYjKacstmJXJly6Ply0ZmcHhmA I8lypHFy5zOAn6Wa7eRiWmc/eBidEuSXdUecc4h1Pcd0tzlog6iZS0lLEdagsGKWEIos5jWh FnqhGJqhGrqhHNqhHzKVwGKVslehRkEr2qmJ6+mWuKl+TRGOxIiWAbaivMQULqqL2GFkJUhl BsqNuDGf/dmCeqhNgVlkfrhjxUV+hHmgf5mKZWlqMneOkNajD0lnltmY6iRdiomOkYaSDriV 3/ObArgzgyil2eZEKdh+aMqapklT3emKOeea9tZRecVVrumD36mmSFhOY2hzbpqaYWpY7fdP Onmc5ZlumUmb/34lgQzIp63YWo0GcPtzV7L5gx9ZqeY5bZ1mpoxKilcGpxMXqWtIkgXonOe2 pnjKgdXJiim6qlxqXG6GWjolmpZpdU4anPR5jrIqoZ9ISB2YkMF1SAj6RErHfU+XhqD5n0eX Ks1VpL9IlNx1oh76FLqaVtHqISQaEQxardq6rdzard76reAarldBoMS6pFXZrBOxdQfJSjL6 oihmqx4IVI+ofEaIrbnnle0Drf23hFrYQ3Jpr+2Kr6jZrLdEr6C4c6d6RaGaMuGXjXvYfT1G nE8FY9uYZIozpMy6oDm6Tnpph2+IsJlqWgv7e41ZpRdrq05KhPPoUZQZWi+opVa6if9U6KNC ikvvJm0q+G2PuqiPial8OrO/qa+aB7Q145B7+ZkW+LLXpqm1ZlVlaoalOkClOa03yK80S6ZZ 6G9Ku6Z3lHGKSn3zZ6n1+VUASokKK4XGI6h3iqpsQ55cg7NRuLNrK5nveZaDdrUzaKex1rZM +I9M+5adeYB3SrXMmZ/sSHJ2xrQmS7Io2bhseiLZ9oW7VpGpSbjDh1/fk63DGmU2eYLZqI1A Kk43uaxERyqrOZhQZ32jS3FAeaJCK6484bqw+xqyO7u2e7u4m7u6u7u827u++7vAG7zCO7zE W7zGe7zIm7zKu7zM27zO+7zQG73SO73UW73We73egrnA2k7/hsSwwDozwrhHfqRjrnozYYkS yXmmgyFKJLiCxiacDHqj0fW9H3STT3suHeWd6sNW0JhcN5pUbNKvxJd8vwe5jGVuUcojkAog fLt03uGGMdYuMDqCRjSlbxSaDIyA17eQbUnAbuN7gZWbAKw6lqVCLfSEKSpXlqstMFqjImTB LSWSC3s/sGqY3xSkPvl9dZmsJLxVEyzCGkymstXDZeU7BlhxK5wtLcyuUfs4AJx/zemv7peY 7LmytfqqQvzCfPZCP0yGyGWWaRu3cEuV2QtnOcNH68uzAKlsMsxx0nNyc2e1tXmmecqB6utf 49ll4suoVUiwUmybY/y6xJJpmBlC/13Il/qrgeGzPuf6wL4mpnQcpyRCxx4rv/v5ksuIbPXq nkjEyN0WQ8EUnjGpM3FJuYs8flPivlVyxqMGfsf5NCo7QVAMwxOljPDbpeOJbeRxf+wCQvha RhE8o6VcRKfMy2GUOcO8gQtshT0IynUkacKqkps8O1IjqSN7cfuGyBg0yxqIjEZTzD1cjxco wEurkdacgQ08qTYLkgWXzlqjtrD6whLczfpbRo4JxKCZQIkbdunZwCoXho5bmUHrWoAqb7f1 RTP6qWFUtgY7Luq4veFLqKMMVXcpzKqXQ+YlsT9auhCbw8G6suZbXSU0vhL9bHgMvlhZU0PH ztjb0i790v8wHdMyPdM0XdM2fdM4ndM6vdM83dM+/dNAHdRCPdREXdRGfdRIndRKvdRM3dRO jZjeJ3A9O2PCDI7850ZSfb5syUHZSpManY9FS0iXnLaGpL2TFVFhcclbjYHXOZvX+qBYTdWw CZDo+pptC0qOTCFWA6UDnZaSSXcwOUopbLjs54Z5Bs+UacANdqwj/K+jWZILSEoZuXo+ytDq bIT5G8BE7IHEMWuDjWpj5ElRw3ZL6J1aOFkU/G+jrY82OcMo1cFxe4yg3b8Wd75bHK9nV9vm KZ6oHNsm3FNHTK2cO4RyWDpEzMYKVdowddppeVbxXKDNDSHBrdurZKTEbbErOrr/6oqFDdux iOPCbcXEQUxDDmfDfxrFAEvF8Da5GYy1WZzLbBmyJmh0MfzIa9LW4T1vARvKsfyk98vJAm1G GueY/VjIsCOwuy1mufqTAQW3S9SPKxlAKsvLokzdRCseW5vZE67avrhBLtl6pwThYfvfC7fA pk3Lm/ra413Exaa+KNviijyDSBfHCBlyYA1zGr2YdGh8zB2rGjvWk4xXGdTgwu3XpgymS7qC 44zASGuDKe5kKenbul3NvXTG5ymNMnTl7ZlFhR3lRajHeWtc2w2dz2fiFV5XsUw5aOVTRd7m FAiI/52pJp6zzvzkay7lLB7eL6epVP7OCjjEuLel5Zyf/2kuOi5MOuVZx1Xmy4a+gVmtVuhn se87kRHORkte0J665WFlnUIe3XuuxvcnN/et2SRe36hax7s86Ah7s9Ta45O5VDxV6Jb+6dA9 sFVNVPZGbVquaoUqyyqd2f7rx2D62YeFrAsthMaeVvGWbmeOdNfcjvzczbLKugZNkfaczx8c 7em6546qhpRbxfcsqhwVYvwL0hE32d5oT2rNwVGtzWzDmVVp7G2IoDakx1LW6j1Zy7VXiGV5 0Glq0nN00dg0SFa+euvuqEmalaHbYpb81fiX71ySW16d0dhH3YwhyGvt5ulNjl+B8VXxKx7/ 7QQS8o6t8ffKj2BB8lIB8hJZ8v/korndJUyxEiwq7/JPffM4n/M6v/NL2dDbjq1vjfIrv982 v/F1beTTLGAnMV4kf+1H8aUTdq81X/PxGJa1S/TiPStLL9stAexPP9FrifRkLGIfb/VV/44I 7sH6Rdnremmxi04gdFUuuKMd/Ysw5t1KSmQVy33W3cigy8N1z3Mevd0pRq59n8OAX6yJH9WH z2IqRKTXzfcEnnPDKffYSHVHNk4Pm/d4jLF0332Nb64v0dr11+uVSfofOPkoa6yRSeCI67Kr 33Jzgtj2icVn9kr+nbnrRzS332bB7sb/fM+CzmYKDqUDbvuHq/UJrKbyrejrLMdiy7akavqu bqq6DoH/zt+Zc47ekZtxpv9v6yzP4hb9Y5ym1H9RPmsT8H5A/KankFx8bXqqTbenYMWbgtj8 kgyeI75Xci7LKZn/AAEAACyBAgkOLHjQ4MKCCB02NAjr4ESIFRUyRKjwokOKDTtalIhRI8SP DysODGmypEmRHjG+PBlT5kyaCVNuVMlQ4s6UGT3ehKkRKEmaG0saDRp06MikOUnyHKqTaMSO SFFCberyJU6mOqFynWp1Jc6rUhNmPZvWrNOvY5fa7PkTq1qWVcM+tdtS60WyO9dynKqV7dea hQ3XtCp44UqXXf8CVgzT4l26kNPypfxQbGSWdMc23XwysVrMgUuTDfw4b+W6/lvRur7sWTLs 2JNTE3UMOTRo0pk777Ys2THjw8WNVwbbOCvB3J9b2/YdHLj0zM1pI4c93bl26KUFn779PPRo 3rVZe7cMfm9k4sl7Ww9Ofb1e8799O/8+n/Vx/jH5urepN8X+I+0o1EbrikDahvuJPs1k6w5C zQwsUECR3EPPwQT9C5C+BAGM6sGIoGNLwg09W60zEUXs6cQVVfrIOwZTC/HDCC1ErT8d5WKO RBQBvKpHuCYMKce55BqwLLzY82uiIpeUEMrrmoRLSKpg5OpJ0zij8seZurzSy766RA/MKGMc MC6jyKxSJr+SYk5NJJEjU8sho2zzKCSztBLLHf8E/jRQQQfdj1BD+cuRw0MXdZNRRx+FdLZI J6W0Uksv3TFRTAPNUDTONjWuU1BHxVRTUk9FNVVVG11VUJ4Me7XVw2KVtVZDTbU1V1135bVX X38FNlhhhyW2WGOPRTZZZZdltllnn4U2WmmnpbZaa6/FNlttt+W2W2+/BTdcccclt1xAcYW1 2LgQVXRQdMMj9N1L5W13VlpVpLeoczfN19z++q2XVHkBhlfFTGsleNGE982v14X/9dFfTt1V deCJPY0X4VYf1rEvSWXl+DggJf7XTiWfO9nPs95c7KZ1Wc7I5XXDDFI0k2H+r08eV37Z5Jad 3BDmlONsU7ihUbrzZ5Aw/iNsTac9Vjpi3Frk+Wl9i566zJnvvTflK62m2WaqWY7T6SRjNntO gTtksToc2RYKbhyZOtBC01y0kUQn5wZJ7gnfHhHCLCvke0G/nXoRw9wM9jtuDb/EE2kPzzR8 QRALPY1uvAXf3MFSo0NTvPLqU4/02aYb3SzyRK/PPsFf14919q6Lb7uGZW+3U01LL/3jFzGu jTt8Qb/xvPuyO75EH0NmN/b0yhO+zNTbiy513QoOs3fXkee+9TuB1NN52wH3fkvjITdP95lv DzjF30LEDmW7GVey9/H/ov5TSsUibLEq37wf/vbSP+1Zz3ruG1OK8EO5xFElVmljDHCiR8Db /rUFa+wbGY0elz30ORB4qutf/bBmQfl5LoECVJ7pUsgjoVkKdSvD3AGnJKkC4i5+4wmPBF+D uOeVj4fxwV306uWiDtotg2eb0er0B77HxK96O4TP7FYYwPBBLVXC8wn0iMdDKp7uiUIsYRCh iETYqdB7OhTf9OZnRSN+UIVJxJ7BmFi7HdIxjFG8Yey6uEIn8utw5Onc3zY4ue6ZT45/LFya Kie5s61FRm3s0OBMSDjEzaiSkbPkbeBYyPVBskGETFz4Ghi4RrKxRovM2yNBOSoztZBPaWKa nM4kS6+csFBlyRks8cUmMelNP1rL0KsieDQpoW1pukzbBT25NFr2//BCdgJRC43ppZ0JpWev fGXY8CIk+6nta1O6preY9zmSuTFU5dRfutC5TpEBS1ToTNg4pRVPdtZzVsHqWj3pac+O8dOf /wRoQAU6UIIW1KAHRWhCFbpQhjbUoQ+FaEQlOlGKVtSiF8WoRZknT10dkVcWI2ccgyRMF+ZT ahzVGDOxQkLELAyl87plOzfGqHy9tHnqvGJMMWbT5d1UYY561+5yiJh++u5Xiyvqql5aU6UW h6fnNKohIcVGnP6Upvcs4vCy6lSdOoxKQiObJr32wLslCmf1I5ucWrQ1nz0IgGmtG1jZ2ie4 6uyBZjoazlyZJKD1SJpbkmsszebRQsYGgP5l3aYHy6bNs75VZlTtqTlHqNac+TWcH0Wkap7S xt3U7UJmdNwgt9Y49mW2koGU3igFKR/K5Y1+ClpRaF2r0xruzX+/LONayUc11dK2YGatoBV5 +7uU8pGuvpTdAtX4O1FqVqqhO59zwcjcVcpHqFmE7jvlt8fVXbeJ1m1d/ri4XKSms46vzSPw tPfUP20yfcidE92GqsdJ/lC5o8RjYQPozPiusbC24eYqjaRBMd7xat+tYni9OMMCl9e3S+zg C/Er0lMlkYJGKxCarJlPEvLuwg48LJdyO99akjWNoVwNfGQkTSsFeJAktuN6pUZGAOdnw3Vd Zl9DjD8WH5iGEf5+In5DaCv3TsaUyyHujHk3xPYVj7/bA6IMY+u25Q51JNn91JEbDOMP5u+R DsZtGQnsWfOG0Xcqzp3zMKtfGCI3MS3mcoKr7FwM1pfGCk5ueqn7Q6NdWcCSlbFxAf1f1sI5 yy/mbsDoZ2bvSrjIi66wiWSjZdiijMxFJqJqR8vJ/ajytLtFkWjFTNVAQrmUngytWD+r1dSS j7+edq/ufGzqLs8P1V2t8M28+eMMH7eYx+ScNbk01+1lTti1TtqQcqnsan7Tmyvu5JuZTScL ArORuHRT13iZPOFcU9itJmYtPajSl21zr5ps5p50OS32ErTd5Hp3Rv0Vb32W2aDalf/3QzuZ 75pJ1KT8BnjABT5wghfc4AdHeMIVvnCGN9zhD4d4xCU+cYpX3OJAnXVUM3Wgvyp5xlF+Vr/o LdmK8avjj4Law1iqcZKDq90DxjWZ2fZJZHEUzJMaOa5DCulDbfpi9gZ6y9mNc0WbSuakpPmx bK5zjPsRZB+/qhIhBnUKKxrngV2SnMfNEbw2dt84BvpZp60csl/5skambLIXW8yyaRuwc7Vs MqdWorUOt2qMbSZFHLvh95z9tOvzLpbMPlgjuw3rRzTQY2NWF8VXCtaEW/J7UYnUTEcVtWBB SoxK/UdYW1K2r/n83Vx9OK7fGW6oHaAZ04N61RvV06X3UHL+PJzIGE6YlKoc+QvRSPnRN9eA i8ahiNtm++iiEM+7Fz6fH3251g9TzOCVfPRjrGaRBjrQFdxgdxXF+0UGXWHwI2+ne087G27F xMGbr3yJj+HmS/nxz3XyfVPLceezeYqni4r1qQ/LU0Lp+oBbPo9LMs8TOpp6i8iyn7CqLt8r v0NiHe27rVcDMZ8zPun6sCmDvwxcOQaDIPYTtPtTGeiavl4jOVEKsf/jngD8LfMbrtdjOlf5 ouTxrM1jQN3bPsqAwCySQEhDo+NjsjbLwDrjQdNDnfmTwTCTvj3isjc6wuS7LRWEMAckQKrr uRikLykcP+ULMgzBQRIzNCjUMxv/UkIdFEIhzEEQPCPTgz5HojLpOrSIUUEUbA0RlD/1usHu e8GfYyS80bzsuzXyw0BkAzWk40BJwz//WrVLmiHhSr73IzDJ0RoPdETHibzAmcLYYkAGg8RP 6jw4pENKKr5YOzWeu5VWCqdvY8EPsau88490SyxgY0Eoq0SVQTv1ESxYpMVLGzZf0yZqq51t YyC8czFxq5lPTDZs2zqxwaY8ASedYbVZcsYNrKyxY7xjcxiC2ycYvLimQjmByrlyykY93EaY ysPCwLd1+kaSCceNG0eBObmN27d2lMd5pMd6tMd7xMd81Md95Md+9Md/BMiAFMiBnMe2cEZX ASt34RpO/3nHbvy+IzmYeaE/VyRFgnQW4mAYloMq8fOpdFwqKiyuyKpIixw6jcQq76uq4jvJ chRHigHJmRq0kSRJFxoruOMZIAssuYvCwcs6qtMx7Am8aYwaajTFW1Q3eNE7a8y8u9u1kwM7 31LAaVKmmWRIV8scH2tB7BPA0FutB7OjAnw928JESnKt2VowWvoMrty80XM99dvDyKHKiHTD /euj/UI8P3RCO+SzMtM/HzwxOeRCPTNGUkNAsETCr4zLjERMDsoqWxyjnXo+wgpE4Pof8tux EfRLOvsfVgyzR3vM8gnKF+vFxJy6EoOr7wrF7/nMNlxM4GPLnfyOA5zLzGxNyv9EMiJqjyH7 vdDUNPAjzY7kNR/Sqtn0wMOsQyADQqtbQxSaLuZcwmtzK0iCrML0SeM8r9/kKtoEueHEzAVD mvw7MaR8HKOLv/D7yyZUyUdsCdz0zuLEyJSzTjPDzuwEJQU5ulGrvFATNUJ0IgbBlVarERPk PKsExTOTKkWsz9pLMiRLQvObT7mkRcXCv2qLzZuJx2I0RmdTRmjro1c8ymJsRj9ZthAlrGwa xVjcNbb7koVsUAk1yQcFx4xByaa7Khi1Uad7UaKaUW3MUay80R8tlYZ0qnRUxockUiBF0iRV 0iVl0iZ10ieF0iiV0iml0iq10ivF0izV0i3l0i710i//BdMwFdMxJdMyNdMzRdM0VdM1ZdM2 ddM3hdM4ldM5pdM6tdM7xdM81dM95dM+9dM/BdRAFdRBJdRCNdRDRdREVdRFZdRGddRHhdRI ldRJpdRKtdRLxdRM1dRN5dRO9dRPBdVQFdVRJdVSNdVTRdVUVdVVZdVWddVXhdVYJVTJZEix qzpYEVIH3FAaBbEiZaFoY1FZ/Ryp20iR5KlzDE5VuxVl1USVRFZhrUJipU/xlMlptTyrm872 esNiE8TSgtZIsSuvCTe0kVap5MmdAUlbRcawS7u100tWgdcg89ZvXVYHRSXq2x23zMr0LB6z HMJEtDu45Ms7zDh6tSr7Ms/q/4vPM3QjBKrOK0zNrVpBnjvSVs2k7hSvH7xYca2s8WFY6lzN oDw/ed1Rgw2VEGrOjEU2zwO/GezCvARZA/PKLdS4il1VaTtP0PTR9aO1ufxYVQsm+FLO96xZ k3VIRES+mJzF++LW+VAi+IRY93xXW9vLZzVan7qMS6TEeCW+BPzBQWQkZsVN7pOiYHTWW73a YjUsYjvKv4LIpWXGVgS8vGurylRRpjQniFSmDbRbqk3bevxPmPzbfgxcbhxcfkQXm+3Rw2Xc xnXcx4XcyJXcyaXcyrXcy8XczNXczeXczvXczwXd0BXd0SXd0jXd00Xd1FXd1WXd1nXd14Xd 2JXd2f+l3dq13dvV07ctwCG9UAVVqamSUbSVKd7t3Z2jFpVTzqSy1nrdFpyt0aItQeHNtZfE Wh1lySpsXsUsWYmNtOytseftqvvkzl0JV/C13u0N3mxB3t1V25zSFqGKSndNxpij22g0x3YV V73pOJMqX5p5s8ND16rzOqlUuz3cu2psjOL1OsLbWwtdRrGJ0FyaSLzVUKaM35qMpRGayoss Cn1lTwq7PCosy5vbWC1EUCXkyp41JN2avDvrRNcjyxhOJJZVL9YLW86hvdvz4N0ywr1kFt4E Qxh22ueUoqCF18BrWsy0y9VsWNoZQ2fqwSb+wOaszS06TiZ0QrgtMPS7FiD/xiQKnIvg49ci Ltup7eDAVGJg6y4KlGIjdjTwnLOYlT/4WWKgfdmYuswrTqG+VOPFJRYvtpz6s2ImluM4Eso+ HrMJ9DPVtLSWnTXfs0vZRDM8vkD8OMGwuEBT81iklM0qHrGsDWP/eybFPVqNjcytvOPiLGTz uk+GHcbCcz8iDsOUbcMoFkDi7M4yjmWZxeKIZUMfcmP2VTrIbNGndbLr2dacvU5d7dA5vM0w bM1njFqMrWVua2NlxmU9HkFXtr9rG0xrjjJSLuWu1SOZc15/RYux9UpZm7luQ0R7FaRKK2N1 vlf91NqB3c9NHFDREi4bBmMB5c8ePuFZqsB5CtYd/wRRubWlWDQSDmPFhKQRt8Ur7jy3uNVQ klJoE80JV0o3jO46zpQjkF5XjK5gjj7IdR3XiU5oa2O+X0ZRpdASviNJcQ65jmLelGzJUqVp Ds4Vl7I3q91ZVd3pZhnqeMnVf0OUXMXdpWbqpnbqp4bqqJZqUJWniiVPHhWW4uXeqq7e9BVc 5cVVdb1ehuIYcb7qnMZRc0Rrrn46w03rBR24snbr5B3e7sXprq7WgrVr931r1EyoqPQfdR3g cSPpsJFfDz1slUZpwCaSdRvKacI6C2axujuhERVRhaZglI6aC47sltHgrEngAjbpBC5sDGbE HoMczva2GCWkfR3LT449jv/0ihwG2MwMYYC9bZDLz9XKbSTiw765vdqO7ed7S6Qry+D6QxMu br7cYdEcF2mbZFvGsmnesry8n03GZj4OZyv0S27+QG/Gy/bTZCfe5QUUYuU25W4uF+hOrzee 7tYTZTwj485MZWqmTZXFby1i5f47Qy12b6lFWDGsZ+F0bkBWPq1+3yELZjGU5FmG4OUc75Ea m8102C3mulDWWXwdZEbrZD3270y+ZDuGZh3rPyKhFf7FpJ1lWYx0uUaJbnB+74Ku7rNlHEP7 3vvev9ribp+NM/UuREIL8DlacGDWyozbWAOXQ3Fhb/0W70yrQfQE8CV/wA23Px3X8Jz1bsB0 4ez/rh7pLu9AbE/nlmaXjmYlB0B/ViRNS/FIQu7ucPIVnuFg/GBdDE7X9lf7bHPwVnNEi6A3 F+4/G/AkZmZyJp2irpiAjTvHrkZu8hnBLtLmUuyi9ERro2Bwc/T8FesPTem69WhkEtoMHdeV rsVdJG1clOBfQ3FA7FXYNnG4hqeMMnS15qd1vNJYL0lfAernhlAstfV5wielhrddn+phJ/Zi N/ZjR/ZkV/Ym1V3qbSmtFt9V59X2vZp4Y2tWWd9rPFi0Fvat/ifn3fbCvWU/Bt7lpXYj73b0 zeqZtd5xWrqVVHfvJVltBWFsFWZyhPe6xmlal15jIWH6dHfsveu87hb4/83KnGRfwW6r/8Tf hjzkY7JsZ9PJu6o7iEfseJR0Ls6w0D5XamxbA86kleLY02QmAs7frUvssKr4zFZ4ukq7Fl/R 9Pngn+ZhESbLfwdEtYzNQAfoRDRENwfA0VHL3wb6sHXLjSY9PPxzsoU9Ictzfyb6cEHy8GT3 Csdn8U6zxixvwtyzHMzyOz76QqP6OLaLFGtELxx7iib7Kv9ymI9XUO/FjmVyVRbxZcZ57RTB B5/k6Pr6IdaLHtTyaS57Mkdj9gt89WTMhFUdKpd6FTcRRyZmjaf7+bb7AC5iEPccRr4xOj5m Ib8wpqHw7tNmSI7AYWRnXjY2/gXsY0u8kcVuUP4eWbdP7++uPTGefAdn5aKj2cMUzCY7UCEn WB0051Oue9FZ5CNvZs+sdi5f2fom2mC/8R005t/XTI70cq6l8eni+r03/B6fciAE/LS/fjiD +z0zQ4WdYsrfZsY38/PnpOEv8lSbZyO6e1HRechrGDxHtZa+tM4BpOQGCACwABAcWNAgwYQI YRlEWFBhQoERJT6saBEiRooTF0bkeDEjRYcNO47smFHkyZQHVWqc6PIlzJgyZ9KsaZMkQ5QY PVrMOdDhxpwvhYIUChQnQ5dEL/5ManIj0phGcSpNWlKh04NWtWI9OjXowqxDt3Z9CtSrWJ0t RZKt+vOjQLEtNX6Fu/50Kdi1VGH6LNr17dy4atempcp28M3Eihczbuz4MeTIfCVTrmz5MubH R5Vm7uz5M+jQokeTLn1zs+nUqlc/hauXNezYsmfTrv0Zte3cuk/jBYt7N/DgwocTL278OPLk ypczb+78OfTo0qdTr279Ovbs2rdz7+79O/jw4seTL2/+PPr06tezb+/4d2n4Q1VfTSy/vmbO kOXr5i91pn/vjRYgZvBtRiB7CHqm4GoM2neZV9/xxJiBmU14W3EOJkibhqZ1WNOH+rXG3YWK VVggSBgSFyJ6TV14YGFE3SXYiDOaxFFvdfkmFVmHnZUVjoXRReNehnGGl1p99URkWVH9Ncef jHLdNVWOctF4WI1WUgnVky5CBKSQTPXIpFs/mhmSWU6GpCOZXj7pHpxxyjknnXXaeSeeeeq5 J599+vknoIEKOiihhRp6KKKJKrooo406+iikkUo6KaWVWnoppplquimnnXr6KaihijoqqaWa eiqqqaq6KqutuvoqrLHKOiuttdp6K6656rorr736+iuwwQo7LLHFGnsssskquyyzzTr7LLTR SjsttdVaey222Wq7LbfdevstuOGKOy655Zp7LrrpqrsurgEBADs= ------=_NextPart_000_0010_01C680F1.59AC8530-- From anteaterngre4w@redeyemail.com Fri May 26 13:49:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjgQp-0007vI-KW; Fri, 26 May 2006 13:49:03 -0400 Received: from p5492d8cf.dip.t-dialin.net ([84.146.216.207] helo=JUSTINE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjgQo-0007Vj-5H; Fri, 26 May 2006 13:49:03 -0400 From: "Bertha" To: Subject: stokc market highlights and investment advice "HY WI" they'll drive you crazy Date: Fri, 26 May 2006 19:49:03 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: J6LMBqOP6lk3FgdFuci3KPfxwENHAXqI0D8D Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa stokc analysis tools and tips meant to increase long-term profits

Unbiased stokc info and valuable insider data Expert stokc analysis and market booming tendencies disclosed


We found a completely new sstock and have an insider information that some big guys are going to invest into it and it will Boom this week.


Get HYWI First Thing Tomorrow, This stcok Going To Explode!

Check out for Hot News!
Hollywood Intermediate, Inc.


Symbol: HYWI

Current prise: $1.24 , but will increase at least 15-20 % on FRIDAY!

About the company:

Hollywood Intermediate provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, Hollywood Intermediate puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of Hollywood Intermediate, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. Manage your stokcs using expert recommendation Expert stokc suggestions and recommendations The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition.Complete stokc research information and recommendations Worthy stokc information that puts more in your pocket

Don't forget to include this stock to you bag!

Successful stokc recommendation for winning players

Read great new on this sotck





A fly will not get into a closed mouth. When dog hungry he ah nyam calabash. He that is master of himself, will soon be master of others One cannot quarrel without an opponent It takes one bad apple to spoil the barrel! To many people in a dustbin means there not much room in side After the storm comes the calm

All cassava get same skin but all nah taste same way. Better a poor man whose walk is blameless than a rich man whose ways are perverse

To deceive oneself is very easy Age before beauty Youth nah ah weary but he ah fall down. Bees that have honey in their mouths have stings in their tails If you would enjoy the fruit, pluck not the flower
Mind your own business Virtual reality is its own reward. Youth is wasted on the young

From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri May 26 15:50:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiKS-0003pG-Kp for eap-archive@lists.ietf.org; Fri, 26 May 2006 15:50:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiKP-0005PH-UK for eap-archive@lists.ietf.org; Fri, 26 May 2006 15:50:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 72D174300D5 for ; Fri, 26 May 2006 12:50:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A9CFE430064 for ; Fri, 26 May 2006 12:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7AA20398043 for ; Fri, 26 May 2006 12:50:07 -0700 (PDT) Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id 83BB3398032 for ; Fri, 26 May 2006 12:50:03 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4QJo167013561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FjiJt-0005er-IT; Fri, 26 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 May 2006 15:50:01 -0400 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-netsel-problem-04.txt X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 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: 5011df3e2a27abcc044eaa15befcaa87 --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 : Network Discovery and Selection Problem Author(s) : J. Arkko, et al. Filename : draft-ietf-eap-netsel-problem-04.txt Pages : 32 Date : 2006-5-26 The so called realm discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document also provides a discussion of the limitations of certain classes of solution, including some that have been previously defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-netsel-problem-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-netsel-problem-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-26135354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-netsel-problem-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-netsel-problem-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-26135354.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 maryjo@ohayani.com Fri May 26 19:28:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjljU-0003Lb-Ab for eap-archive@ietf.org; Fri, 26 May 2006 19:28:40 -0400 Received: from [222.40.88.72] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjljP-0004b6-PA for eap-archive@ietf.org; Fri, 26 May 2006 19:28:40 -0400 Message-ID: <000001c68147$347e6e80$0100007f@localhost> From: "Henry Turner" To: Subject: It is rare opportunity to save so much on generic meds! Date: Sat, 27 May 2006 07:28:09 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C68147.347E6E80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.6 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68147.347E6E80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C68147.347E6E80" ------=_NextPart_001_000E_01C68147.347E6E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Langdon looked again at the fax an ancient myth confirmed in black and white. The implications were frightening. He gazed absently through the bay window. The first hint of dawn was sifting through the birch trees in his backyard, but the view looked somehow different this morning. As an odd combination of fear and exhilaration settled over him, Langdon knew he had no choice The man led Langdon the length of the hangar. They rounded the corner onto the runway. ------=_NextPart_001_000E_01C68147.347E6E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_000E_01C68147.347E6E80-- ------=_NextPart_000_0001_01C68147.347E6E80 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA9gG7AwEiAAIRAQMRAf/EALkAAAIDAQEBAAAAAAAAAAAA AAADAQQFAgYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwEEBQgECwUFBQkAAAECABEDBBIh MRMFUZGS0lNBYbEichQ0BnGBMlKhwdFCYrIjM9PUFYJzkyQ24aLCRDXw8UNjJeKDs8NUdKQWRhEA AgIABAQDBgUDAwUBAAAAAAERAiExEgNBUWFxgZEi8MHxMhMEodFCUmJyghSxI0PhM1NEBRX/2gAM AwEAAhEDEQA/APaO5UhVGp23Ddu8p80jhXTta8wPQoUD/eDQXbkv5kWn1lq+iOlyIJ4L+O/Unchw X8d+pO5HQjU+nkhAngv479SdyHBfx36k7kdIjU+nkhArgv479SdyHBfx36k7kbCNT6eSECuC/jv1 J3IcF/HfqTuRsI1Pp5IQK4L+O/UnchwX8d+pO5GwjU+nkhArgv479SdyHBfx36k7kbCNT6eSECuC /jv1J3IcF/HfqTuRsI1Pp5IQK4L+O/UnchwX8d+pO5GwjU+nkhArgv479SdyHBfx36k7kbCNT6eS ECuDc8d+pO5Dg3PHfqTuRsI1Pp5IQK4Nzx36k7kODc8d+pO5GyI1Pp5IQL4Nzx36k7kjhXPHfqTu RsI1Pp5IQK0Xl2rcL+ZwKH61AnaOHB2UINGHQZ1FL8RcHkKofrq4/FGafQE6nuEi2Qqg0LnbtG8K IcF/HfqTuScX4e0elQT9JFTGytw4UYATwX8d+pO5Dgv479SdyOhJqfTyQgTwX8d+pO5Dgv479Sdy OkRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBfx36k7kOC/jv1J3I2Ean08kIFcF/HfqTuQ4L+O /UncjYRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBfx36k7kOC/jv1J3I2Ean08kIFcF/HfqTuQ 4L+O/UncjYRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBueO/Unchwbnjv1J3I2Ean08kIFcG54 79SdyHBueO/UncjZEan08kIF8G5479SdyRwrnjv1J3I2Ean08kIFFrlra512/K1KFfOabKRshgCC DuOwyhxX6f8AlNf9rpjhI6FxPibnsJ6bkbFJ8Tc9hPS8bDz8EEZHP+YZmAtl8YqEcsr6hXaKEfjl jPz2scqObaprZUZK7RVyPyxPzJY4vK3Yb7TK469J/A0yc7K1/LmGlfWZ9J+i3qH5J3pRWrt4fr02 68TnazTtj+mUXxzTOHIjnsV4xf1PV2adQTd1zQ5Rk3cvl9rIvUNx9WqgoNjMv4pn8zs+7/La2fKi 26/TUE/hjeU3vd/l1b/hpdYfSHeklq1dG6pY7sLsE2rQ3+iTOyvmLPTKvcLT7vbuaB6u0ip8vn0z 0ly/bt2GyCa20UuSOgCs8faxS3IsjJO8X0NfMo0//Mm0L5vfLBeu0WSh/snR+Kb3duvp0qIvoZKW eM8a6kVLPMPmDmRe9habdlDTTRd+/TVwamXuR82vZxuWMkAX7W2oFKitDUdIMr8jy7eFyS5k3QSi XTULQn1tC+UjpjuUZfKcnNuHDsPayGRmd23EFlr+e3lMm4lF0qYVcK1Vy5irc1erG2afuKh5rzm/ zG/iYmhjadwoIA9VG07yYyzzrmWLnJicytqBcIGpdhAY0DVBIIlCzl3MPnmXdt2WyG13V0LUGhff sVp0Mgc053ZfLAxghVVtNUk6TqC7hvJ8s6Oi40rp0TK+aTKs/wBz1aojgei5plNh4N7IX7agBK/e Y6R6Zmcl5zmZWacfLK0a3qSgpt2MP92HzXf04tmwN9xyx+hB+VpUyLf9O5zgtuHDtKx+rhN+Cc9u lXt4r1X1OvgatZ68HhWJ8T1JIG0wrM7O4QzLJy9uLpYCv2OJX876o6xaGIl57bBsYjiWkBqFoPWo egzxK/qajCueOOUzHI6asWuRaqK08vRK+bfuWbacKge7cW2pIqBqNK0laxgWr+Gt64K5N1eJxq+s GYVWh8lIq+Ey8TBv3Rqd7ltGO0VBNGmbbltLwhuupY8COzjwkvm+6ZFnHajF0Ys+7atNw88sTNv4 mOeY46lPVNttlT+ZpC+WaM3R2bsnwtCxngaU4zzJkQhNlCEIQAhIhWAEWnxNz2E9LzuLT4i57Cel 5Vk+3vJyOsX4az7C+gRsVi/DWfYX0CNi2b7hZIxObc2zEzU5dy8DjNTUxAJq20AV2btsVi815ni8 xTB5lR+KQAwABBbYpGmg3xSEn5u29J/BZM3r2FiX7q37tpXupTS53ihqPwzvZ0oq1dU9W3M8ZZzW qzbTytEcIMzmHNMvH5xj4dsrwbpthgRU+u2k7Ze5tmNhYFy+lOIKBK7dpNJjc3/1Hh+1Z/Xjvmu8 eFj4y7TcYuR7I0j9aFRN7SjNSxqaV3OTwOuSc4y8vLbHyyu23rSgp0H0Gd8/5pl4D2RjlQLgYtqF d1JSuoOXfMGL5FZLaeahXg/inXzd+8xvZf0rNKlXu0aS03rMcDOqypbHGrPSzF5hzTLx+cY+HbK8 G6bYYEVPrtpO2bU81zf/AFHh+1Z/XnLZSdnKn0s6bjaSjmi3znm2XZyreBggca5SrEA7WNFArs65 XTmfN+X5lqzzPTct3iBqAUUBNKgoBu88fz3lWReupn4R/b2gKqNjHSahl84iMHm+Lm3Ux+a2V94U 6UuMuzVXcQfsmdaqr201Wt1Hr/cmYbepy3XH0/tPREgCp2CEzs3gjOt++D/LG2Qmr7HErt1f2emN tW/c7F90YNYANyyu06QFqRXorPCtz1NRhXPHHvB01YvoW6itPL0Svm37tpLa2iA964tsMRULqrtp 9UrJgWrmELrVOU6cTjV9cORqFD5ovIW3lWMC/cWr3LltXNSNhDVHXM23LaXhDaTWPAjs4ygvLfcZ a4rUb9lxC+6pDBd0sTNOJj/1VRo2CzrG0/aVgoO/omlN7bs9U8LQjVZxnmEISJspMiEIAQhCAEJE isAmszf5KaNZnfyU1wfdE4l9PibnsJ6XjYpPibnsJ6XjZHn4IIVl2feMW9Y8RGUfSRsni8SuS2Hh NuF9iR+i+iv6pnuYlMLDS4LqY9tbgNQ4RQ1T5wJ02t3Qmomcu5m9NTT8yj8x/wDSbv0p+sJl3b/C +VLCA7bzFPqFx2Ponpblq1eQpdRbiHerAMNnmM4bDw2traaxbNtKlEKLpWu+gpsim4q1rVqdN9Yt Rttp510nnbHy7au8sGUbji+1s3FQU01oSvknXJS2TybNw12uoJQe0uwdaz0qqqqEUAKBQKBQADyU i7OLjWCTYspaLbyiha9Qmnvtpp4+pWr0gi20mo5QzzvIub4WHh3MfLJVg5ZRpLaqgbNnl2eWR8uM X5vkXCuniW3cL0BnRh6ZvXOW4F25xbmPbZ95YqNp8/TGpj46XDdS0i3GFC4UBiOgnf5Itu0avFXO 4scSKlvTLUVPPco/1Hme1e/Xhz6i88xH3Clsk/RcaehTGxrdw3ksot1q6riqAxrtNSBWF3Fxb5DX rKXWGwF1DED6xH1lrVofyaS/TemJ/VJ5znQ9+55ZwwSFUKjU8mr12PZMRzrk1vltq1esu7Bm0sWp sNKilAOieq91xuNx+CnG38TSNe6n2qVk3bNm+ui9bW4ta6XAYV6aGK77roS+WqhrmR7U6pzbwK1j NtZC2LdxQfeLIuAmmlid6U6YqxaVb2ZiY5/Y6BRa1CO4IIEuNi4r2hZa0nDX7KaQAv0U3Tq1ZtWV 0WkCL0KKTyWo7XnCE3HOH+k3DwkrYmTaTlqXWYAWrYVwd4ZBSn07JX4bWsDARthF60SPpNfxy82H itd4zWUNytdRA39MayI9NahtJDCorQjcRJ9OzUNrCulfn+A0vjygqXyBzLGJNPUub/7MuTi7Ys3g BdRX0mo1CtDO5uqadv5OfwKln1CEisKzRQhWRWRWATWRWEisoJnFv4i57Cel5NZza+IuewnpeVZP t7ycjvF+Gs+wvoEbFYvw1n2F9AjZLZvuFkjzGc45f8yLl3QRZajV37GThsfqM6vcxuZ/O8dMC9c9 3GgOFLIrBSWcldnk2bZ6C/jY+Qui/bW4o3BgDT6Jzj4WJi193tLbJ3lRtP1zt9WsJurdq00LkY0O XD9Ltq6mDzf/AFHh+1Z/Xi+bJ/UOf28OpCqFtkjyChuNTrnpHxsZ7gvPaRrq003CoLCm0UJFdkBi 4y3eOLKC8dvECjXt2fapWFvJRhjWjqu/MPbbnHO0nlec8oTlgs3bDs2piCWpsIoVpQR3zNdF5MG8 N1y2XH9rSZ6W7Ys31C3ra3VBqA6hhXp2zh8PDdVV7FtlQURWRSFHQKjZLXfxo7Jt0nHuR7XzJYK0 fgUx8xcqJAF01Oweo35Jmc3/ANR4ftWf15ujl3LwajFs1H/lr+SMfGxrlwXnso11aabjKCwptFCR WYrelXNVb5WsXzNOtmobWaeBhc4ysrC5vYutcuDEbSSisQp0n1xprSU+d5GJzHLsf0/9peb1XYKV 1EkaRtA3T1V6xZvpw7yLcQ/msKiLx8DCxm1WLCW2+8Bt65qm9Wqq9L1VUYZPuS223KnBuepDXrRv jCvKCWTUC1KPtoRTplWzaH+ew7BrZCUQVqFd1OpRL97HsX1C3kVwN2oVpJtWrVlNFpAi9Cik8jo3 aXEKceMNZGobZVtZVpeWLeLABbYBH6QFNP01iGttaxOXI2xhdt1HQSrGXTh4hu8Y2U4la6qCten6 Y1kR6alDaTqWorQjyiT6dmsWsK6VH+o0vj2KjEDmy1NK45Ar7YlycXLFm6Va4isyGqkipB807m6p p26uSpRIQhCaKEJFYVgBCsisiUE1kQkVgEzP/kperKP8lLw8UTiX0+JuewnpeNil+JuewnpeNkef ggghCEhSDQAsSABvJIA/DOeLa8RO0v5ZR587Jy1ipodaivXPLca74jdc9Gz9v9SurVGMHHc3tFoi T2/FteInaX8sniWvETtD8s8JdvXeE3rtu6Y67eu8RvXbrnT/AA/5fgY/yf4ntOLa8RO0v5Z19G0e QjbPDca799uuer5KzNyywWNTRtp9ppz3vt/p1TmZcG9ve1tqIwkvyIQnnOwQhEZeSMaybhFTWijz mVJtpLiG4HVAkzFe7l5HCuMQAz0tUoPWljFzb4v+75G0k6a7iD9U6PZaUynGaMK6k0oSKytm5fu1 saRV3+zXcKeWc61dmks2abhSWYVmR7xzApx6to+9QU6pcwstshWD/bTbUeUTdtq1VMpxnBFdNwWq wkSlmZzW34Nn7Q+02/b0CStXZwitpKWXdsisz2ucxs6Wap1eSgb0S37yBj8e4pUjYVOzbK9tqIat OGBFZPp3G0Mg1EoJfzslibRoB5BQAdcbi5OQz8O+pKnZqpShle00njXDNTiRWT5lmRZ/f3PYT0vJ Ow0kWf39z2E9LzHB9vea4o7xfhrPsL6BGxWL8NZ9hfQI2S2b7hZIIQhIUTdysey2m44VqVoZx/UM PxR+H8k878wsf6iwqaBV9EzK+ed67SaTl4n0dr7Cl9ut3ay1Vk9r/UMOuniitK027of1DD8Ufhni kP7U7f8Aw29Kwr55formzf8A+dT99j26ZmLcYIlwFjuEfPE8vb/P423/AMVP1hPazluUVWkjyfdf brZtVJu2pTiTIhCYPMEITPzc+5bujHsga9lSdu07gJqtXZwiNpKWaFR1QmKHzbT3rgPrIRxSKHfu mjhZRyLRLCjqaNT0zV9p1UyrLoRWnDIsyITNys+8bxs4+yh01AqSZmlHZwiuyWZpSKzKOXnY7gXa 9OlqbfrE0kcXLa3F3OK0lvtusPBp8URWTO4bZxdLiy5t/bAOmgqazO945n91+x/7Mtdt2ydV3DtH M09siZa52ZrCFjqrQrpFfRLWdmvZbhWtjUqW3yvasmlg5JrUTyLVD0SJnvd5hZUXXJCnpofwS3j3 /eLPEIoymjdElttpTKaywKrJuMhkpfyUuSn/ACUnDxRS+vxNz2E9LxsUvxNz2E9Lxsy8/BBBCEiQ pl/Mhpytj/5if8U8jxJ6v5pbTygncOKnoaeL4q9I659D7Vxtf3M8f3Cm/gPuP+zb6I27c/aN9MpX Lq6G9YbumdvdXWfWHXPRqUnKGP4k9lyI15TjnzN+u08LxV+8Oue4+XzXk+MekMetmnm+8c0r/Udv t1Fn/SaUJFZFZ4D1k1iM3G96sG2DRgdSnyVEdWVeYYz5WMUtGlxTqXbSvmmqYWWOnHMjyfEyntZm KyBwVo1UptGrzS7h80Z7i2b4FWNAw2bfOJncfLscG1etN+yua0DAgk1+zWWMbHysrM94u2zaTUHa oK7vIKz13SdXr05OLI5JucJ7G1IYKaatJPk1Q1VJMz+b4d7ICX7A1Og0sg3037J5aJOyTemeJ1bh ZSdcyOUFItj/AC2kaiKf9855S9tluIBS6RUnpHmmd75zI2PdOG1KaaaDqp0TQ5VhX7KvevDS7LpV PLTftney07TrZ1zw08e5zTmyanxNJQQdsw7lxhluRtcXDQecNO+Xe/8AvlvjLeFv1tRcNp+yd9Z1 zLCyFvnJxlLqx1ELtKsPNG2lS7q2nqrnw7CzdlKWTO778wx9Ny45oxpsNRXopOsnKORhI52EPpen TQyneyuYZmm01o+qa0VSNu6prNC3gEYRx3IF5zr+g9Er01VXbSrav08gpcpTEcRGIMu5bZbB0oDU ndU/TGYubeW8LV46gTpNd4O6V7V3PwiycI0PSCRXpBE7w8a/dvi9dUqoOtmYUqd8tlWLO2jTGDWZ FOETPE0mFGIkWP39z2E9LwLamJ8h3Qsfv7nsp6Xnm4PsdeKGYvw1n2F9AjYrF+Gs+wvoEbM2zfcL JBCRCQp5D5kenNHH6C+iZXEl75rZrfNmLBgGRSpoaHZTYZjcZfP1Geit0qpTwPv/AGzX0dvFfJUt rc/aN/dt6VhxJUW8NZ3/AGCNx6RDjDz9RlV1zR1UY4o1OWvXmOKP/OT9YT3c+ecnY3Oa4iopYi6h IAOwKak9Qn0Kctxy1B8r/wClH1KR+z3kwkVkVnM8BMzOY8vvXbvHsesSBqWtDUbKiaVZkc0xMpcj 3rHDOpoSF2lWHmnXZwvg1XDjk+hm+WUiLWVlY1xzt1VAuBhXaN1ZrYmYuXbJppdPtL9Mxly8m4cl Fslnv01gAnTSvkmjyzGu49p3vDS9ygC+UAdPXOu8q6W2krYRHExRucMjQFfJOaJUlQuryUpWsAaG YeRi5mDk8WypZASUdRq2HyGcduis2tWl8OpuzjhJ1ltlcVfewQabN27zU2TXsFLli21rYmmgHRTZ MN25jzC6tbR2bB6pVR9Zl/Ns5FjBs2sfWzqfWNsHygk7vPO24k1Srda2nJZIxVxLxaNA6htlfNyW x8etf2lzYvm6TOOW8f3V+OHD69muoNKL96VObrk3MlRbtO6IoAKqSKnad050ovqaW1CNNvTK4j+W WaIchtrMdNuv4TF80e0bwArxVADnydIl2wptY9hCKEKCwPTvMo8yw75vHIsqXR6VA2kGlN01Sye6 23GcEaikIjI9+4C8evD2dH1VpLeC1tsUrbqGU1cHplG5lZ2SgsNbJ6aKamnTLuHYbGstxNly7T1e gD/vl3MNuHpT1YKpK/NhMRxHyp/JS1Kv8lOPDxNl9fibnsJ6XjIpfibnsJ6XjZl5+CKghCEhRGao fGa2wDI5AZSKgjf5Zle4YfgW+wv5Jr5Arbp5xKmidKPAxZYlI4GHQ/sLfYX8kk4GJX9xb7C/klwp sgU2zcvmZjoUvcMTwLfYX8k1sbZYQbgooANmwbBKuiWrOy0o/wC2+Yu5RquYysKyKyKzBomsKyKy KwDm7atXTba6CzWm1oQfKJ0SWO07OiEiX3AmFT5DSRUbvLIrtp5YB1rfp/BI21rU16ZFZVy+YWMW gerOfzBvp0zNrVqtVmqrqRuMWy3rf70gEjcaStk5qWAgKs73fsIu8xY5pj8BrxDDS2koR62qR7u2 m07JNKWTUuZdL3OmRTyk7emVsbNTIdrZRrd1NpRuiWCQN81W1bKauUVOTriXBuPXOSWb7RqOiRUV p5YVG7yyiSZ1j/v7nsp6XnFZ1jfvrnsp6Xl4Pt7xxQ3F+Gs+wvoEZFYvw1n2F9AjZm2b7lWSCEIS FKeStbpPmEVoHRLV1avWcaJo6q2CEaNu7yQ0eaO0bfqhoguoVbWlxT5xL1ZWVaMD54+sjOd3LJrC RWRWDBNYVINRIrIgHKWrVp7ly0CLl4gufo/7515yamFZFZe4JhVhuMisisAks53t1QBKigNJFQd2 2cs6qpcmiqCSfMIwB2Sx+0aw1v5Gmfb5tad0BtuqXDpS4RsJhc5rZR2UI7Ih0vcA2Azl9faidSgz rrzL1SdpNTAEj7JpIDBgGBqCKgyNQ6d2+dSnZuXPvfgnPlqdp6TIJA2ndCsoJlb+Slisr/yUcPEF 5fibnsJ6XjYofEv50T8BeMrMvPwRUEKyKyKwUh9q0itMaZGyVMjQspArGbJEskgXpna7FAhshI2C awrIrIrBSawrIrIrAJrCsisisAoWbaW8TFuooFzVbqw3kOdJBP1ybYdyLoQB+Ma3SRXSHKaen7Oy k7xcYixZ4jN6gDcM0oG6qxvu6666jo1a+Hs06undXzzz1221VxHpWGGfM5pYI5w0QcW4B67XLgLe Wms7JW52B7sjUGrWBXy0o0vW7a2wQtSCzMa9LHUYvKxreVbFu4SADq9Wla0I8oPTN3229l0SUuv4 la9MFPM+Ow/q9Mz7n7q7/fD0NNrIxLd8JUsr2/sOpoRF/wBNxuAbJ1EMdRcn1qzhu/bblrWiIctY 9IgxajbYrH/6vkex3JYa1buZj8RQwFpaA7RtZ4Y+Hbx2ZwzPcfYXc1NI3hgXTd26ioWnkoCT+Odt vaarFksdy12s8zaWGPOSpZRFtYdxQA7EBm8pBRq1MjhobFm8R+1a6jFvKavLS2EVLSAmlkgr9QK7 euVzaZmVAHULcD6TTQKNqrqp5eiZe26pKJlRHWFiSILs7xv31z2U9LxcZi/vbh/RT0vPVwfb3m+K GY3w1n2F9AjYnG+GteZFHUIysxbN9yrJE1kVhWRBSGFTIpJrIrAkikik6rIrKJIptnVZEisEkmEi sisAmsKyKyKwCawrIrIrKQRmKrnHVhVTdFR0+q8Re/Zm9atr6jGz6g2D120sB0VpH5Vtrhshailw Esu8UVtvXJ93Uq4dizXCCzmgNV+zSmzZOFqO1rQvH+2IMtS37cCtdtsLd1Sgt22a1RFO46wCfV3S 4UtLaNsgLaoQQNgp5Yv3ZSrB2ZmcqWbYD6hqBsFIy4guW2tnYHBU037RSarRqXGdYU924CRl49r3 y+rIvDw7B9Rek1r+GVz8Llf3q+lppW+XJaoEvXlUGukPQdQEh+WWHdm1OqudTWwfVJnmf2+46r0r V6tWP7lGHRGNDjLE6u/9MP8Ac/8ADA49gZaLoXTw2JFNhIK0J6d8fctLctNZOxGGnZ0QNtTdF3bq ClaeShIP4p6Xty1KThUXk8Tce4q2QH4FthW2DeOk7vUbSvUDG4iqguqooBcag+oSLloW1TRr9Vmb WtCy6qk7KbRtnWLbZEbVWruW9b7W3ppM0q1ZJrFLP+1IiWI+I/ko6K0t0f8AJ0+uejh4my9cRiQ6 fbWoodxB8k5N6mxkcHo0lvwqCIx3CAbCSdiqN5M505J26kTzaS34dSzKyxL2OOOv3X/w37sjjL91 /wDDfuxmjJ8ROwf4kNGT4idg/wASX0+3wGIvjL91/wDDfuyOMv3X/wAN+7G6MnxE7B/iQ0ZPiJ2D /Ej0+3wGIrij7r/4b92RxR91/wDDfux2jJ8ROwf4kNGT4idg/wASPT7fAmInij7r/wCG/dkcUfdf sP3Y/Rk+InYP8SGjJ8ROwf4ken2+AxEcQfdfsP3ZHE/RfsP3ZY0ZPiJ2D/EhoyfETsH+JE19vgMS vxP0X7D92HE/RfsP3ZY0ZPiJ2D34aMnxE7B78TX2+AhlbifoP2H7sNf6D9h+7LOjJ8ROwe/DRk+I nYPfia+3wEMra/0H7D92Rr/QfsP3Za0ZPiJ2D34aMnxE7B78TX2+AhlXWfuP2H7sNZ+4/Yfuy1oy fETsHvw05PiJ2D35Zr7fAQyrrP3H7D92Go/cfsP3Za05PiJ2D34acnxE7B78Svb4CGVdR+4/Yfuy NR+4/Yfuy3pyfETsHvw05PiJ2D34le3wEMqaj9x+w35Iaj9x+w3dlvTk+InYPfkacnxE7B78TX2+ AhldQ7Gio1fOCo/3hLVq3w1NdrMasZz/AJhdp03B0AFT9VS07Rw66h/tB6JmzwwyKhdGtE6V1WyS aDetfN5RI46/df8Aw37s7LuzFbQBI+0x+yPymGjJ8ROwe/GHEdjjjr91/wDDfuyOMv3X/wAN+7Ga MnxE7B/iQ0ZPiJ2D/El9Pt8BiK4y/df/AA37sOKPuv8A4b92N0ZPiJ2D/EhoyfETsH+JHp9vgMRP FH3X/wAN+7Dij7r/AOG/djtGT4idg/xIaMnxE7B/iR6fb4ExE8UfdfsP3ZHEH3X7D92P0ZPiJ2D/ ABIaMnxE7B/iR6fb4DERxP0X7D92RxP0X7D92WNGT4idg/xIaMnxE7B78TX2+AxK/E/RfsP3YcT9 F+w/dljRk+InYPfhoyfETsHvxNfb4CGVtf6D9h+7DX+g/YfuyzoyfETsHvw0ZPiJ2D34mvt8BDK2 v9B+w/dka/0H7D92WtGT4idg9+GjJ8ROwe/E19vgIZV1n7j9h+7DUfuP2G7staMnxE7B78NOT4id g9+Wa+3wEMq6j9x+w/dhqP3H7D92WtOT4idg9+GnJ8ROwe/Er2+AhlXUfuP2H7sjUfuP2H7st6cn xE7B78NOT4idg9+JXt8BDKmo/cfsN+SGo/cfsP3Zb05PiJ2D35GnJ8ROwe/E19vgIYlLT3NhBVDv J2H6hLWlegbqfVOA7oaXQKHYHXdXzg7oyZnFcixgLXbktX8xFp/aLV/VjolPibnsJ6bkbI/cgiYT P5xzF+XYy30QOWcJRjTeGPk+iWcO+cnFtX2AU3UDEDcKiXS9KtwbgSpjiPhMrnXN7nLODw7a3OLq rqJFNOno+mV05vzpiP8A046TTbRtxmltWdVbCHzcEd6pxjK6G5CZL84u2+cDlz214bEAXKmvrLUf h2TvnXN25aLOhBca7q2EkUC06Ppk+naaqMbqUNdYb/bgzThMfmvOb/L1x/2Ss95NTgkjSRTYOuM5 jzHmOLfZMfEN6yqhuJtp590Las4y9UxjyGtY9DUhPO2PmHmWSGOPhC6F+1p1GlZY5lzvJwsizYSw He7bV6EmupiV0/gmvo3nThPcn1KxPDsbUJgP8xZ2MynNwTbttsB2qfq1DbNy1dS9aS9bNUuKGU+Y iszbbtWG1g+KxLWyeXA7hPPWvme4+Uls2VFh7mgXKmumtK9RnoYvt2pGpRIrZWy4BCEJg0EIQgBC EiATIhCAEIQgBFJsv3FG4hG+s6l/4YyLT4m57Cel5Vk+xOR1jfD2z5WUMfpb1j6Y2KxfhrPsL6BG RbN9wskTCZGHzm7e5pc5fdtqmguFYE1JQ+fpEOZ85u4ebZxLNtbjXQpqSdhZio3TX0r6tMYtavAm usT1g15Eys3nF3G5pZwVtqy3SgLkmo1tplzmOZ7lh3MmgYpTSp8pJAk0W9OHz5F1LH+OZZhMjlHO 7nMMh7F22tshNa0JNdo6fpljm3NE5bYV9Ou5cNLaVoNm8n6JXt2VtEepkV66dU4F+E843P8Am1hU vZWGq2HOw0ZSa7d5J9E1cvmS2uVnmNgB1orKrbPtMF206KyvaumsvU4UPiFernpiXoTz1vn/ADS5 a46YOu0KkuuojZv2zS5Tza3zK25CG3ct01pWu/cQdnRFtq9U21gs4chXq3CL8Jk8450/L71uzati 4zKXapIoPq+gy5yzN9+w0ySArNUMo8hBpI9uyqrtYMKybdeKLUIQmDQQhCAEIQgBCEiATIhCAEIQ gEOodSp3MCD9cpe8XOn/AJXi/wBqXZm/yUvDxJxL6fE3PYT0vGxSfE3PYT0vGw8/BBGL81/9Ot/3 y/qvL/Kf+m4v90volD5r/wCnW/75f1XjuW8y5fb5fj27mRbV1tqGUsAQQJ2ab2awp9bMSluOf2oo fN//ACn/ALz/AIJYx/mO272rPu1wFiqatlNuysq/Njq6YToQyMLhVhuIPDIM2LfNOXaEX3m3WgFN Q3zTj6O3NHf5vDEz/wAlotpyMj5kU4/McTNHm67bavxw52Pe+dYeKNq0Wv0M1W/3RLfzRZ4nLhdA 22XBJ8zer6SJR5OTm86GQ23hWVP9oItv0kzVH/tq/wD463X5EsvU6/udWdfN37zG9l/Ss9Dk/D3f Yb0Tzvzd+8xvZf0rPQ5Pw932G9E53/7ez/d/qbr8+54GH8o/u8r2k9DRHzHcW1znGutUqiW2NN9F uOY/5S/d5PtJ6Giufbee4YP3bX/xGnT/ANi39PuMf8Ve/vFc45zY5patY2OjJ64YvdKqK0K/eI8s 2rv/AKfyRgGqbVnSGG4sRpBH1mUvmqzaGFauBAHF0LqAoaFWNPwSvzTI0/L+FartuhK+yi/lpIkr V21VRXXlmWXV3nF6czOfFK8ls5XlN9wD5ioHpSexxbwv41q+P/ERW6xWeZv8lzLfKhebJZrSoLvu 23Stdp/Opsr0TX+W7/F5WinfaZkP6w/A0b8WpqT1abteY25Voaiar8DVhCRPKdiZEIQAhCEAIQkV gBCsiFYAVi0+Iuewnpedzi38Rc9hPS80sn295OR1i/DWfYX0CNisX4az7C+gRsls33CyR5rMHunz PZu7lvFD5vXHCMl196+agN62KHsLq/WjPmq2U91y1322K18/2l9BhyAcfmefm+TUQv0Oxb0LPUn/ ALf1OW26fjBxj16f56hXN/8AUeH7Vn9eP+a7+nFs4433XLH6EH5WiOb/AOo8P2rP68452Hzud2sO 22kqFSv3SfXJ6oqsdpvKtHZhvC652gFt/wBO+YMZNyultD56pwv1hO/mk1ysRD9mh2fSw/JKnOMD MwHsZF7JbJYk6XapK6KMB6xPTLXzMdZwstRW26kj/dYemaUO+1adU1dZ7Efy3URinHc1Ob5PKtHu WfdNvWA4CqxNAdhqFYeSVc4Yq/LLjDcvjimhmrU/tRXeB5Ynn+XyzIwhctMl3JfSEYULqoOo18ok f/yH/bx5zrWK7b9S/wB1YPLuadpdlh8jxQnlnP8AGweXDHa273l1EUA0Ekkjbqr+CWflXG0W72SW U66KFBBIA2+tTdLPILNq7ydFuIrhi4IIB/OMzvla6LXvjsaKiK5+hdU1eHXeVVD1LVxnElZT25c4 YdCbif1H5hv296W0dKfQhT9ZpY+U71bF/HO9HDge0Kf8MzuUYOZzC5fyLOQ2M4PrOtasXJYj1SOi P5KHweeXMS42osGQt0keuD1CW6Wi1E5dKVw/pJVvVW0fNZ49z1MIQnjPQEISIBMiEIAQhCAEJEIA QrIrIrKCazO/kpoTP/kpeD7onEvp8Tc9hPS8bFJ8Tc9hPS8bI8/BBCMvDxs22LWSnEQHUBUrtAI/ NI6ZU/8A17k//wBP/vv3ppQlV7JQrWXZh1q80mVL/KsDIt2rV61qSwum0NTDSKAeRhX7I3xI+X+U AgjH2jaPXfvTRhCvdYK1l4jTXkvIXfsWsi01m8uu2+xl2ivl8kTictwsIs2Lb4ZcAMdTNWntEy1C TU4iXD4CFMxiVcvl2FmlTlW+IUqF9ZlpXf8AZIlhlV1KsKqwII8xnUIlwlLwyELzK2JgYmEGGLb4 YehbazVpu+0TIv8ALsLJvpk3req9boEbUwppOobAQN5lqRGq0zLnnIhREKBWViY+Za4WQmu3UNSp G0eyRK9zk/Lrtu1auWtVuyCLY1v6oY1P50uwhWssm12YaTzSOXtW7lprLittlKMv6JFKRWJg4uEr JjJw1c1Yambb/aJj4RLiJcPgIWYQhCQoQkVhWAEKyIVgBWFZEisoJkVhIghNZxa+IuewnpeTIs/v 7nsJ6Xl4Pt7xyO8X4az7C+gRsVi/DWfYX0CNktm+4WSE5WJj5lrg5Ca7dQ1KkbR51IkYmDi4SMmM nDVjVhUtU7vziY+SFJjU4iXHLgIUzGJVvcuwr+SmVdt6r9vSUfUwppNRsBpvkLy3CXL99Fv/ADJJ PE1MdpGndWm6W9B80g7PLLqtlLyjPgIryXMRl4WLmoLeSnEVTqAqV27vzSJD4OJcxlxHthrCgBUJ JpTYKGtZZCkydB80k2wUvDIQuSxMu1yDldosRaLagV9ZiaBthpLP9Pw/c/ceH/lvD1N97XvrXf55 a0GBUiV3u87W55hVqskhONjWMW0LNhdFtakLUnft3sTK9vlHL7XF4drTx1KXfXf1lbePtS7Ik1Wx xeOeIhclgIxMLFwkNvGThqx1EVLbd35xM5bluE2WM02/8wCDr1MNoGkbK03SzCNVpbly88RCyhYB CEJChCEIAQkQrACFZFZEoJrIrCRWATIrCRBArKP8lLspfyUvDxQ4l9fibnsJ6XjYpfibnsJ6XjZH n4IIIQhIUJxdupaQ3Lh0qN5ncyOc3GN23Z/NC6vpJJH4pjdvoo7cje3TXdVOn5vcLfsrYC+TVUn8 BEZZ5mxNLqinSv8Atmco9ZFUb6+sfLSkatNJYDZWg6d9J4P8ndmdXhGB7XsbURp8eJuKwYBlNQdx hKmCxANs7htEtz37d9dFbmeG9dNnUIQhNmQisi+mPaNx9w3DpMZK3MMd8nHKW/tqQyjppsp+Gaqk 7LVlOJHMOClczcq8bbIuhdXqUr6x6D0yxi8wa5d4N5dLnYCNm0eQiZnEyccolwFRbbWqsNlZoYmd jX7oFy0qXifVcAGp+nfPTuUWnCqahw68DnVuc/M0awnMp8xzeAvBQ/tXG0/dE81auzSXE6NwpYZX MTaucOyA2n7RPT0Chj8W+1+wLjgAkkbJlX0sWse3puK91jV9LBqbN2yXuWujYwQMNYJOmu2n0Tte lVtp1XGJMVb1YlzfKeVzA27htWQCV2Mx6eiXBWsxslXxssuwqNeta7iK1mdmtbWc4wsEW7aWBZHM Mi2wF5Nh8hBU0l03bQtcev7Olf8AZMvMzVyQoVSoXeT0mBuN/TwPJxafgrNvaTVXGhtw0jKtE4yP PMchyeGgCjbSldnnjsXNF9uHcAV/zSNxkcqA4Dt5S1OoD8spA6M6i+S7QD+1GmjdqqsacmWWoczJ qnZIs/v7nsJ6Xkv9szmx+/uewnpecOD7G+KGYvw1n2F9AjYrF+Gs+wvoEbJbN9wskE6VgBOZ0qgi p6pEGR6zfRODdtoaVq0yea89OPcexaWmhgrsdmwkVP4Zjtzu5R3CjQn2mdwo3sopq6dJnors2al4 I4W3apwsT1hyVr9r6hSklcpK7T1TydnnFy9cZKU0hiSDWmltHrbKCvmnP9auHboIAPr1IqBqVAes y/47M/XPaqysKqajpkPunlMPnd9CXppoRqSoYEMquPro09QLq3bSXF3OAwHmIrOW5tumeTOu3uK/ dEQhCczqEp5nMBYcWkXXcPUKy3MnmWJke8e82QWBoTp3qQKbvqnTaVXaLcvxM2bSwIXMzLb3HK12 jWpBovR5dk0cXJXIt6wKEGjCY9nPuWnuG4gucSnEVhvpNXEvY962XsKE++oAB/BOm9WFOmMvUjNH jn4FmUMrmJt3DasgErsLHp6AJerFe7WQ5uC2NYqwPlrOVHVP1KeSNueGBRXmWQjUvICPKCNJmirq 6q6/ZYVExcrIvXbo468MgUC0INPrmvZ08G3wjqt6dhnTdqkquIbzjIzRuWpkYSFBZjRVFSZnvzK8 76bCbPJsqZYzyVw7nnoD1iVuTgFrreUBQPrr+SSlaqlrtaocQLN6lVYDcbmHEcW7wAJ2Bh0+eNys pcYBQNVw7du4CZ2cdGZc07NoP1kAwznJynr5tn1CdFtVdquIVq6oM6mk1ycD/wCoZK0ZlGk7qggH 6DLlu6l60LibPIw6DOc9VGGwA2Jp09YErcrJK3h5KA+mYarbbd0tOlwaUq0NzJclP+SluVP5Kc+H iaL6/E3PYT0vGxS/E3PYT0vGTLz8EETIhCQoTM5taJuJd82k+bbUemacTeQNsYVBFCJz3aa6Opva tpurGRbUlkNNi1r9dI0WiFCU2VqW8wNZZ9z0n1Ds6DO1xz+cfqE8S+3tk1+R63vVzk7xEpVunYJZ i02fROqz3bddNUjx7ltVmyawrIrIrOhkmsq8wXJfGJxWIuIdVFNCw8olmsivRKnDT5EeKg89/UXY WUyAWazc1sTvIru2xmKr5meLlm3otBwxpuUDbNfIxrOQ1p7ho1pg2wD1qeQxhJOwbF8gE7PeUems Np8cEY0OcWdaqkynm8uTKui6bujYBSld31y1Ccq2dXNXDNtJ5mHzDBGFbRxc16yRupu+uW+TWf2T ZeraQyaadBBrX6poh2AoPww1vWtfqnR71nTS8+LMqiTkyOW8xyr+ZbtXLhZG1VFB5FJj+ZZmZjXd LW1bHJBUlagjoM0OI/mkamApvHQZHuV1atCiIj3jS4jU+5iZGec0pZsWtAG0Iu0kn6AJpHCb3AY4 obw9en6X/bZLAYrsRVSvQJAqDWu3pi25kqrSqueeIVc5cyZWNn3cPXbKbT5G2UMby+zcvXxfcURT qLHynfsmiXJ+0qtTcSJDM7bCaDoEr3ZTiul2zckVcpcpATqJPTJsfv7nsp6XnM6x/wB/c9lPS858 H2NcUMxfhrPsL6BGxWL8NZ9hfQIyZtm+5VkiYAyJ2tNO3pkKZPOeU2s60zLRbwBGrcGH3Wnkcm1w LvDybJVlUIFqyjSN32WFRPc5JfUV8nklLJxbGVb4eQgcDdUba+YjaJ6drddVDxR59zaVnKwZ5Djp UEChAYLtP5x1nefKZCtaZ1pb1tqJAq21iQdoB27Rum43yvhO/qXLiDbUVVvL9EvYfLcTCp7vbo+7 W3rOdvSd31Ts9+iWEtnFbFpxcFHlPI3uBTkLwbKmvCqS77APWqTQbJ6igCgDYBsAlFK7wdo3H6pd BOkE+XfPLuXtZy/I9O3StcvMmsisisJzOpNZkc0uZ2NkC9bduA1CACdII3gzVrCpH0eUTVLaXMK3 RmWpWcHn25haf3ktbq18qUr+aRWaHJ7N23auXbgKi5QIDsrSu38Ms2sazYu3bybXvEGhAotK7o3a TVjOl91NOtVCcT4ErWHLZ2p2zAvXs3l+XVyzKpOjUSVZTNyBJIoQGHQdsxS+mZWpPNFsp4xBgZGd e5heQJb2gUVV2nbL+W9/l/L7Cq2l60Yih31YiXwSooiqg8wkh2A31+mbe6npSqtNcdJFXPHF8Slh Pcz+X3lutqYsVBPkoFI3eeZ9jMv8uvOty3tOxlbZu3EGbhd237PokM2oUZVcecVhbiWpOqdbfpDr ljiuJj4q3uYZRuEeoW1XG8gHRLXNbD6/eUGpGFHp5CNlZeLMRp2KvQNkAzL9k/VD3nqVkoSUaeg0 KI58TKu8xuZFlbOnoqRvakvYdlrGOS4pcund5QPPHayDVVUHppI2k1Y1MlrzXTWulTLCUOW5JlX+ SlmVv5KY4eJS8vxNz2E9LxsUvxNz2E9Lxsy8/BFQQkQkKEhhWFZFYBFIUk1kViEJJ3QkVkVlITWF ZzWEAmsisKyKygmEisisAmsKyKzPs6kxse/rdnYoHLMTUOdNKE08sza2lrCcG32RG4NCsKygly47 C4ouF+KQTt0aAxSlK03bY3FBJuXGZmPEuKASaBQx2ASV3NTSSzx8CK0k5GfjY76LjHXvoATQQfPx UtJdL1W59igJJ+qUuYcO1eY2gXyshdGneApGnd9UUbBx8jCtMasDVuipacLb+4rXSVWk0p5S4UmX a0vI1bGTayE12mqK0PkIMZM3lP2sn2/yzu7qKZV3W4a0x4dGIC0VTunSm63tVu1LczH8Z/Iqt6Uy /CU7hOO7aGYjgu51EtVkpQ7fpgENu7j0djqDawWJDHTWu2b+pjEZNJ488iyW6zrG/fXPZT0vOJ3j fvrnsp6XnTg+3vLxQzF+Gs+wvoEbFY3w1n2F9AjZm2b7lWSCEiAMhQIDb4s2xGGkispIF8ORw43Z ColkkHK2lG0750x2SKiQx2SFCsisisJQTWRWRWFYBMiRWV8upNhQxUNcAbSSCRpY02fRJZwpzI2W awrKF241ni2lZtNbWnaSwFw6WAJ2+SQ7XFtXQnEtpqtaCxOoamAahNZze7E4ZJz4T+RNRfrEpl49 y8bCPqcCpptHXO1UKgQVI85JPWZmY9tLXN7qWxpUJsA84WXcvar24S9d1V/9A21HVwW7nMsS3cNt n2g0YgEgHzmTf5hi2G0O3rbyACaAzIPwuV/er6WnaH9rk/8A2/4knm/ytz+Pqywyz/I5/UfQ20uL cQOh1KwqCJMqcrP+Rtf2v1jE20Js4rm4+q6QHOs7QVZqb/NPSt16aOPnqrf6fmb1YJ80aMispFmU vYDMFN1UBqSQrKGIrvjbIKZF5AzFAqFQxJpXVWlfolW5LSjjpffH8iyWKyv/ACUfEfyU68PEpeHx L+wnpeMnFxWDC6gqQKMvSP8AZOPebI+04U9DHSeozMTisSjayKxXvOP4qdoQ95x/FTtCNL5MShsi sV7zj+KnaEj3mx4qdoRpfJiUNrCsV7xY8VO0JHvFjxE7Ql0vkxKGwrFe8WPETtCR7xY8Re0I0vky ShtYViveLHiJ2hI94seIvaEaXyYlDayKxfvFnxF7Qhx7PiL2hLpfJiUMrCsVx7PiL1iHHs+IvaEa XyYkZWUsSzcbHsB3HDUK4WlGqNoBNfJ9Escez4i9Yhx7PiL1iZtty02ngmvP4EcHIsMGoH/Za+Jp ptqTqpWu6vmndq3w1YVrqZm7RLUkcez4i9Yhx7PiL1iFtw5SYwK13BuNlNk273DY0AGgNTZTymF3 Bu3Rbdr9b9o1W5pAHZljj2fEXrEONZ8ResTP+PTH029Tl42z5kiuPXqLw8QYqsNWt3NWalJLY+q3 fTVTjEmtN1VC/infGs+IvWIcaz4i9YmlspVVVXBe8Qogi5aDuXbaNDIVG8hqH8Ur2i73rPr6xbBr 6pUiop61TvlnjWfvr1iHGs/fXrEltqWnisZeeMBpHcZi/vrnsp6XiVdXNEOs9C7TLdi2UBLfabaf MPIJt4JzxNLMjG+GtewvondYoHgeqwPDqSrDbSvkMPecfxU7QmWm22lMlkbWRWK95x/FTtCHvOP4 qdoRpfJiUMrCsV7zj+KnaEj3ix4qdoRpfJiUNrIrF+8WPETtCR7xY8RO0JdL5MkobIrF+8WPETtC R7xY8Re0I0vkxKG1kVi/eLHiL2hI94s+IvaEaXyYlDayKxfHs+IvaEjj2fEXtCXS+TEobWVssMxs BDpbigg0r+a++M49nxF6xDj2fEXrEzajsohkcPicHHZlcu/7RypDAUC6Nq0FemQ2O7q3EcamKHYN gCENQCs749nxF6xDj2fEXrEn0l+1/jx+IwGVlZcTTmvl6/timinmA3180bx7PiL1iRx7PiL1iatt 6olN6XqXcOH4FN+VlmcLdK2bjamTTU1HnnV7luq4z2bvDDqEcU1VXYPxS1x7PiL1iHGs+IvWJz/x dvH0PHq/w8zOmoWLK2LK2lNQo3nz7ZwuPpt2E1V4JBrTfRSv453xrPiL1iHHs+IvWJv6ahLT8qhd vZGsBV60FFy5qILOrggV0lQF29I2bZGNqa9eulg4YIAwFF9XVur9MdxrP316xDjWvvr1iT6XqVlK jGOuP5khTMncVQ//AIVI1FN3Ym4738glvhJ0fm6f7PRN9OJrqdQhCczQQhCAEIQgBCEIAQhCAEIQ gBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAE IQgBCEIAQhCAEIQgBCEIB//Z ------=_NextPart_000_0001_01C68147.347E6E80-- From jane@infonet.com Fri May 26 20:06:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjmJs-00048N-LC for eap-archive@ietf.org; Fri, 26 May 2006 20:06:16 -0400 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 1FjmJs-0002CC-IW for eap-archive@ietf.org; Fri, 26 May 2006 20:06:16 -0400 Received: from [59.33.253.187] (helo=infonet.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FjmJq-0007Bh-6U for eap-archive@ietf.org; Fri, 26 May 2006 20:06:16 -0400 Message-ID: <000001c68121$3f4b4840$1fd9a8c0@hkq24> Reply-To: "Jeanine Jang" From: "Jeanine Jang" To: eap-archive@ietf.org Subject: amai vicissitud Date: Fri, 26 May 2006 17:05:22 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C680E6.92EC7040" 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: 3.2 (+++) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C680E6.92EC7040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D s ea n r H r om h e O r wn v er, Your c u re u di l t doesn't matter to us! If you O u WN p r p ea f l e c st a at s e and want I d MM l EDI f ATE c v as m h to s r pen h d ANY way you like, or simply wish to L p OW x ER your monthly p t aym x ent a s by a third or more, here are the d p ea k ls l we have T c ODA y Y: $ 4 j 90,0 e 00 as l n ow as 3 , 6 y 5 % $ 37 g 0,0 d 00 as lo d w as 3 , 9 b 0 % $ 4 i 90,00 n 0 as l f ow as 3 , 2 a 0 % $ 25 d 0,0 h 00 as l s ow as 3 , 3 m 5 % $ 20 r 0,00 x 0 as lo d w as 3 , 5 l 5 % V f is f it o n ur web s o it z e Jeanine Jang , A u ppr q ov i al M e ana u ge a r all that there were up the trees. Now perhaps we can finish this story without any more interruptions. Mr. Baggins saw then how clever Gandalf had been. The interruptions had really made Beorn more interested in the story, and the story had kept him from sending the dwarves off at once ------=_NextPart_000_0001_01C680E6.92EC7040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D s ea n r H r om h e O r wn v er,

Your c u re u di l t doesn't matter to us!

If you O u WN p r p ea f l e c st a at s e and want
I d MM l EDI f ATE c v as m h to s r pen h d ANY
way you like, or simply wish to
L p OW x ER your monthly p t aym x ent a s
=20 by a third or more,
here are the d p ea k ls l we have T c ODA y Y:

$ 4 j 90,0 e 00 as l n ow as 3 , 6 y 5 %
$ 37 g 0,0 d 00 as lo d w as 3 , 9 b 0 %
$ 4 i 90,00 n 0 as l f ow as 3 , 2 a 0 %
$ 25 d 0,0 h 00 as l s ow as 3 , 3 m 5 %
$ 20 r 0,00 x 0 as lo d w as 3 , 5 l 5 %

V f is f it o n ur web s o it z e

Jeanine Jang , A u ppr q ov i al M e ana u ge a r

all = that there were up the trees. Now perhaps we can finish this story
without any more interruptions. Mr. Baggins saw then how clever = Gandalf
had been. The interruptions had really made Beorn more interested in = the
story, and the story had kept him from sending the dwarves off at = once
------=_NextPart_000_0001_01C680E6.92EC7040-- From 7p2bGnmqur@mail.ru Sat May 27 00:16:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjqEG-0000w3-T9 for eap-archive@ietf.org; Sat, 27 May 2006 00:16:44 -0400 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 1Fjodp-00017U-9a for eap-archive@ietf.org; Fri, 26 May 2006 22:35:01 -0400 Received: from [60.49.188.149] (helo=tm.net.my) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjoHk-0008Pf-0X for eap-archive@ietf.org; Fri, 26 May 2006 22:12:14 -0400 Date: Sat, 27 May 2006 02:12:17 -0480 From: "Mitchell Hurt" <7p2bGnmqur@mail.ru> X-Mailer: The Bat! ({THEBAT_3_VER}) {THEBAT_3_TYPE} Reply-To: "Mitchell Hurt" <7p2bGnmqur@mail.ru> X-Priority: 3 (Normal) Message-ID: <{DIG}.20060527021217@mail.ru> To: eap-archive@ietf.org Subject: Is The Time Right For This SmallCap? MIME-Version: 1.0 Content-Type: text/plain; charset={THEBAT_ENG_CHARSET} Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 For Immediate Release ALERT ISSUED - Watch FCYI.PK ! Falcon Energy, Inc. F C Y I 1 week ago $0.88 Today $ 1.87 Up from $1.60 Wend 5 Day Expected $2.90 Market Plus Top Four Pick There is a big PR campaign starting today and running all week!! This Is Going To Explode! Is FCYI Ready To Go? If You Think So, You Know what to Do... Review exactly what the company does and Watch This One Trade... VANCOUVER, British Columbia, May 19, 2006 (PRIME ZONE) -- As part of the commitment of Falcon Energy, Inc., a Nevada Corporation, to keep investors informed of its status and activities, the company is providing this investor update. Gas production continues steadily from Falcon Energy's Richmount Westlock property in Alberta, Canada. This opportunity has proven itself out as the property and investment have benefited from the surge in natural gas prices since the well was first tied in May of 2005. The market price (NYMEX) for natural gas at that time was approximately $6.50 per MMBTU but in the last year prices stayed over 10.00 per MMBTU for a 5 month period with several spikes above the $14.00 range. The company is pleased that the investment continues to provide consistent revenue for the company and its shareholders. Falcon Energy Inc. has also announced that due to the confirmed addition of its mining exploration properties in Mongolia, that it will shortly be expanding the executive team to assist in managing this new opportunity. Details will be forthcoming. VANCOUVER, British Columbia, May 17, 2006 (PRIME ZONE) -- Falcon Energy, Inc. is pleased to announce that the granting of exploration licenses for five mining properties in Mongolia has been finalized. These licenses will be held for a minimum of three years and grant Falcon Energy, Inc. access to the mineral rights for the licensed properties. Falcon Energy, Inc. had recently sought the mineral rights to these significant properties in the mineral rich region of Mongolia. Falcon Energy's interest in the region is driven in part by the anticipation of deploying modern prospecting methods to an area that abounds in both base and precious metals. The five licensed areas are: 8825E - The Duhum Hujirt License Area 8454X - Tsagaan Tolgoi Copper/Gold Project 9997X - The Huld License Area 9996X - The Har Tolgoi License Area 9668X - Hutagt License Area Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium. From slatenmaks@ficoh.com Sat May 27 04:24:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fju5g-0005z9-9N for eap-archive@ietf.org; Sat, 27 May 2006 04:24:08 -0400 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 1Fju5g-0006ds-7I for eap-archive@ietf.org; Sat, 27 May 2006 04:24:08 -0400 Received: from [218.19.91.188] (helo=ficoh.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fju5Z-0003hC-99 for eap-archive@ietf.org; Sat, 27 May 2006 04:24:03 -0400 Message-ID: <000001c68166$8ef11790$a259a8c0@ukk97> Reply-To: "Maksim Slaten" From: "Maksim Slaten" To: eap-archive@ietf.org Subject: wrestlin unregistere Date: Sat, 27 May 2006 01:21:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6812B.E294B090" 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.1 (++) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6812B.E294B090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D w ea o r H f om l e O j wn h er, Your c m re m di b t doesn't matter to us! If you O c WN j r u ea c l e r st r at q e and want I w MM v EDIAT g E c c as f h to s j pen u d ANY way you like, or simply wish to L x OW n ER your monthly pa b yme z nt d s by a third or more, here are the d n ea q ls q we have T q OD p AY: $ 49 f 0,00 g 0 as lo y w as 3 , 6 s 5 % $ 3 c 70,0 j 00 as l e ow as 3 , 9 x 0 % $ 4 q 90,00 h 0 as lo u w as 3 , 2 j 0 % $ 2 t 50,0 c 00 as lo u w as 3 , 3 d 5 % $ 2 w 00,00 z 0 as lo p w as 3 , 5 o 5 % V n isi k t ou v r web s o it k e =20 Maksim Slaten , Ap d pr d ova l l Ma j na k ge s r deeper on them in the following days. They had crossed the enchanted stream; but beyond it the path seemed to straggle on just as before, and in the forest they could see no change. Yet if they had known more about it and considered the meaning of the hunt and the white deer that had ------=_NextPart_000_0001_01C6812B.E294B090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D w ea o r H f om l e O j wn h er,

Your c m re m di b t doesn't matter to us!

If you O c WN j r u ea c l e r st r at q e and want
I w MM v EDIAT g E c c as f h to s j pen u d ANY
way you like, or simply wish to
L x OW n ER your monthly pa b yme z nt d s
=20 by a third or more,
here are the d n ea q ls q we have T q OD p AY:

$ 49 f 0,00 g 0 as lo y w as 3 , 6 s 5 %
$ 3 c 70,0 j 00 as l e ow as 3 , 9 x 0 %
$ 4 q 90,00 h 0 as lo u w as 3 , 2 j 0 %
$ 2 t 50,0 c 00 as lo u w as 3 , 3 d 5 %
$ 2 w 00,00 z 0 as lo p w as 3 , 5 o 5 %

V n isi k t ou v r web s o it k e

Maksim Slaten , Ap d pr d ova l l Ma j na k ge s r

deeper on them in the following days. They had crossed the = enchanted
stream; but beyond it the path seemed to straggle on just as before, = and
in the forest they could see no change. Yet if they had known more = about
it and considered the meaning of the hunt and the white deer that = had
------=_NextPart_000_0001_01C6812B.E294B090-- From vinkiordaz@daeffler.com Sat May 27 10:18:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjzcX-00031u-7I for eap-archive@ietf.org; Sat, 27 May 2006 10:18:25 -0400 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 1FjzcX-0002Po-4k for eap-archive@ietf.org; Sat, 27 May 2006 10:18:25 -0400 Received: from host-81-190-207-18.gorzow.mm.pl ([81.190.207.18] helo=daeffler.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FjzcS-0006Ua-UB for eap-archive@ietf.org; Sat, 27 May 2006 10:18:21 -0400 Message-ID: <000001c68197$fbb0a360$128ca8c0@idb74> Reply-To: "Vinko Ordaz" From: "Vinko Ordaz" To: eap-archive@ietf.org Subject: baza broadcaste Date: Sat, 27 May 2006 07:15:18 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6815D.4F51CB60" 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.0 (++) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6815D.4F51CB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D p ea r r H d om k e O t wn t er, Your c h re m di x t doesn't matter to us! If you O g WN q r u ea d l e s st w at c e and want I s MME y DIA r TE c s as i h to s h pen g d ANY way you like, or simply wish to L k OW y ER your monthly pa m ym m ent g s by a third or more, here are the d t ea a ls a we have T x ODA l Y: $ 49 b 0,00 e 0 as lo z w as 3 , 6 b 5 % $ 37 r 0,00 b 0 as lo u w as 3 , 9 y 0 % $ 49 v 0,00 f 0 as lo x w as 3 , 2 r 0 % $ 2 w 50,00 b 0 as l i ow as 3 , 3 e 5 % $ 20 t 0,0 p 00 as lo m w as 3 , 5 k 5 % V z is i it o j ur web s t it p e =20 Vinko Ordaz , A u ppr s ov h al Ma o na r ge f r goodness they are not still back there in the power of the goblins! He still wandered on, out of the little high valley, over its edge, and down the slopes beyond; but all the while a very uncomfortable thought was growing inside him. He wondered whether he ought not, now he ------=_NextPart_000_0001_01C6815D.4F51CB60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D p ea r r H d om k e O t wn t er,

Your c h re m di x t doesn't matter to us!

If you O g WN q r u ea d l e s st w at c e and want
I s MME y DIA r TE c s as i h to s h pen g d ANY
way you like, or simply wish to
L k OW y ER your monthly pa m ym m ent g s
=20 by a third or more,
here are the d t ea a ls a we have T x ODA l Y:

$ 49 b 0,00 e 0 as lo z w as 3 , 6 b 5 %
$ 37 r 0,00 b 0 as lo u w as 3 , 9 y 0 %
$ 49 v 0,00 f 0 as lo x w as 3 , 2 r 0 %
$ 2 w 50,00 b 0 as l i ow as 3 , 3 e 5 %
$ 20 t 0,0 p 00 as lo m w as 3 , 5 k 5 %

V z is i it o j ur web s t it p e

Vinko Ordaz , A u ppr s ov h al Ma o na r ge f r

goodness they are not still back there in the power of the = goblins!
He still wandered on, out of the little high valley, over its = edge,
and down the slopes beyond; but all the while a very uncomfortable
thought was growing inside him. He wondered whether he ought not, now = he
------=_NextPart_000_0001_01C6815D.4F51CB60-- From goij003@yahoo.co.jp Sat May 27 11:42:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk0vS-0000s9-PD for EAP-ARCHIVE@IETF.ORG; Sat, 27 May 2006 11:42:02 -0400 Received: from [218.8.217.42] (helo=ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk0vO-0004YG-9A for EAP-ARCHIVE@IETF.ORG; Sat, 27 May 2006 11:42:02 -0400 Subject: =?iso-2022-jp?B?GyRCIX4/PSQ3OX4kX00tRnEkJiQ0JDYkJCReJDkhIxsoQg==?= From: =?gb2312?B?Q09ERTAyIEVFUlJPUg==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C680BD.4FF33130" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C680BD.4FF33130 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B!cK\EPO?$,3NG'$5$l$F$$$^$;$s$N$G!d(B $BK\EPO?$r$*:Q$^$;2<$5$$!#>0!"B`2ql$O(B15$BK|1_!A(B42$BK|1_$G$9!#![(B $B"((BPC $B7HBS!"MxMQ2DG=$G$9!#(B $B?75,L5NAEPO?$NJ}$O2<5-$X$*4j$$$$$?$7$^$9!#(B http://ttu.cc/?1079 $B(!(!(!(!(!(!!J9-9p!K(!(!(!(!(!(!(!(!(!(!(!(B $B!c5.=w$N%U%'%i%F%/$_$;$F2<$5$$!d(B $B!Z%U%'%i<+K}=w@-Jg=8![(B $B%U%'%i9%$-$N5.=w$K$H$C$F:G9b$N>l=j$G$9!*(B $B:#$J$iBt;3$NCK@-!a!J%*%A%s%A%s!K$rA*$SJ|Bj$G$9!*(B $B5.=w$N%U%'%i%F%/%K%C%/$r;W$&B8J,AG?MCK@-$K;n$7$F$_$F2<$5$$!#(B $B5.=w9%$_$N%*%A%s%A%s8!:w$O$3$A$i$^$G!*(B http://ttu.cc/?1079 $B!Z%U%'%i9%$-$JCK@-=8$^$l!*![(B $B!{%U%'%i$5$l$?$$CK@-EPO?$b$*BT$A$7$F$*$j$^$9(B. $B!{CK@-$NJ}$bL5NAEPO?D:$1$^$9!#(B http://ttu.cc/?1079 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B!~%a!<%k$4ITMW$JJ}$O$3$A$i$^$G(B $B"#(BUselessness to serve infohimitsuno@yahoo.co.uk ------=_NextPart_000_000F_01C680BD.4FF33130 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B!cK\EPO?$,3NG'$5$l$F$$$^$;$s$N$G!d=1B(B
=1B$BK\EPO?$r$*:Q$^$;2<$5$$!#>0!"B`2q
 
http://ttu.cc/?1079
=1B$B"#CK@-;XDj8}= :B?69~$_2DG=3D$J=3Dw@-B??t$G$9=1B(B 
=1B$B"#5U1g=3Du6b@hJ'$$6d9T?69~2DG=3D%7%9%F%`Ek:\=1B(B
=1B$B!Z8=3D:_!J=1B(B2006-05=1B$B!K$N5U1g=3DuJ?6QAj>= l$O=1B(B15=1B$BK|1_!A=1B(B42=1B$BK|1_$G$9!#![=1B(B
=
=1B$B"(=1B(BPC = =1B$B7HBS!"MxMQ2DG=3D$G$9!#=1B(B
=1B$B?75,L5NAEPO?$NJ}$O2<5-$X$*4j$$$$$?$7$^$9!#=1B(B
=
 
=1B$B(!(!(!(!(!(!!J9-9p!K(!(!(!(!(!(!(!(!(!(!(!=1B(B
=1B$B!c5.=3Dw$N%U%'%i%F%/$_$;$F2<$5$$!d=1B(B
 
=1B$B!Z%U%'%i<+K}=3Dw@-Jg=3D8![=1B(B
=1B$B%U%'%i9%$-$N5.=3Dw$K$H$C$F:G9b$N>l=3Dj$G$9!*=1B(B
=1B$B:#$J$= iBt;3$NCK@-!a!J%*%A%s%A%s!K$rA*$SJ|Bj$G$9!*=1B(B
=1B$B5.=3Dw$N%U%'%i%F= %/%K%C%/$r;W$&B8J,AG?MCK@-$K;n$7$F$_$F2<$5$$!#=1B(B
=1B$B5.=3Dw9%$_$N%= *%A%s%A%s8!:w$O$3$A$i$^$G!*=1B(B
 
=1B$B!Z%U%'%i9%$-$JCK@-=3D8$^$l!*![=1B(B=
 
=1B$B!{%U%'%i$5$l$?$$CK@-EPO?$b$*BT$A$7$F$*$j$^$9=1B(B.
=1B$B!{CK@-$NJ}$bL5NAEPO?D:$1$^$9!#=1B(B
 
 
=1B$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!=1B(B
=1B$B!~%a!<%k$4ITMW$JJ}$O$3$A$i$^$G=1B(B
=1B$B"#=1B(BUselessness to serve
------=_NextPart_000_000F_01C680BD.4FF33130-- From hgagiu@osranch.com Sat May 27 16:17:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk5EJ-0005QR-Gq for eap-archive@ietf.org; Sat, 27 May 2006 16:17:47 -0400 Received: from jangce-94.adsl.datanet.hu ([195.56.5.94] helo=osranch.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fk5EH-0002Qm-CY for eap-archive@ietf.org; Sat, 27 May 2006 16:17:47 -0400 Received: from localhost.localdomain (XthtO63.mail1world.com [209.88.189.581]) by 209.88.189.581 (Postfix) with SMTP id fc8xg2r8v1mf for ; Sat, 27 May 2006 22:17:33 +0100 Date: Sat, 27 May 2006 22:17:33 +0100 From: "goppr axqmoms" To: Subject: [Report] no compromise CTXE Content-return: allowed X-Mailer: phpmailer [version 1.41] X-Trailer: PHP Data URLENCODED 5 X-Authentication-Warning: localhost.localdomain: apache set sender to hgagiu@osranch.com using -f X-Virus-Scanned: amavisd-new at mail2world.com Mime-Version: 1.0 Content-Type: text/plain Message-Id: <50653326606200.2892vqmroc@kmaALkIC> X-Spam-Score: 1.9 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 CTXE***CTXE***CTXE***CTXE***CTXE***CTXE***CTXE Get CTXE First Thing Today, Check out for HOT NEWS!!! CTXE - CANTEX ENERGY CORP CURRENT_PRICE: $0.53 GET IT N0W! Before we start with the profile of CTXE we would like to mention something very important: There is a Big PR Campaign starting this weeek . And it will go all week so it would be best to get in NOW. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. Announces Completion of the GPS Survey Today and the Mobilization of Seismic Crews for Big Canyon 2D Swath, Management would like to report The GPS surveying of our Big Canyon 2D Swath Geophysical program is being completed today. The crew that has been obtained to conduct the seismic survey (Quantum Geophysical) will be mobilizing May 30 (plus or minus 2 days) to the Big Canyon Prospect. It will take the crews about 3 to 4 days to get all the equipment (cable and geophones) laid out on the ground and then another day of testing so we should be in full production mode on or around the 4th or 5th of June. Once the first of three lines are shot we will then get data processed and report progress on a weekly basis. Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. GET IN NOW Happy memorial day Up one side and down the other. Stubborn as a mule. A rose by any other name would smell as sweet. Read the tea leaves. Schools out for summer. Sitting on the fence. A tree does not move unless there is wind. Worry often gives a small thing a big shadow. Put to bed with a shovel. Rise and shine. Put to bed with a shovel. You can lead a horse to water but you can't make him drink. Slow as a snail. What's good for the goose is good for the gander. You throw filth on the living and flowers on the dead.Pin a rose on your nose. To rule the mountains is to rule the river. What goes down usually comes up. From admin@1000islandsinfo.com Sat May 27 18:04:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6tb-0005Ad-33 for eap-archive@ietf.org; Sat, 27 May 2006 18:04:31 -0400 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 1Fk6tX-0006uf-FB for eap-archive@ietf.org; Sat, 27 May 2006 18:04:27 -0400 Received: from [222.255.113.24] (helo=[222.255.113.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fk6tV-0002nM-Ju for eap-archive@ietf.org; Sat, 27 May 2006 18:04:27 -0400 Message-ID: <662161c80604{SYMBOL_LC}@1000islandsinfo.com> Date: Sat, 27 May 2006 22:04:25 -0420 From: "Mable Laird" To: eap-archive@ietf.org Subject: Calling All Small Stock Players MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: -1.7 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f For Immediate Release ALERT ISSUED - Watch FCYI.PK ! Falcon Energy, Inc. F C Y I 1 week ago $ 0.88 Today $ 1.91 Up from $ 1.60 Wend 5 Day Expected $ 2.90 Market Plus Top Four Pick There is a big PR campaign starting today and running all weekend!! This Is Going To Explode! Is FCYI Ready To Go? If You Think So, You Know what to Do... Review exactly what the company does and Watch This One Trade... VANCOUVER, British Columbia, May 26, 2006 (PRIMEZONE) -- Falcon Energy, Inc. is pleased to announce that it will be initiating a detailed study for two of the properties for which it holds exploration licenses in Mongolia. The studies will be in preparation for a work program on the properties. Falcon Energy Inc. will seek to engage a geological team to study its properties and make recommendations for the commencement of a work program. Both properties hold great promise for the discovery of significant deposits of Uranium. The first property is the Huld License Area (license 9997X) The Huld license area is located on the territory of Dashbalbar soum of Dornot province. This property is situated 650 km NE of Ulaanbaatar and 170 km North of Choibalsan /province center/ and 50 km NE of the significant Mardai Uranium deposit. Production of Uranium ore from the Mardai deposit has ranged up to 195 tons annually. The second property is the Har Tolgoi License Area (license 9996X) The license area is located at the joint part of Tuvshinshiree, Monhhaan and Uubayan soums of Suhbaatar province. The Har Tolgoi license area comprises a total of 12,319 hectares. With the current bull market for Uranium, a number of companies are currently very active in Uranium exploration. The Western Prospector's team is focused on the a uranium project located in North-Eastern Mongolia with the 2006 exploration program, budgeted at US$16 million. UGL Enterprises also has holdings and great interest in the area. Current major Uranium discoveries in Mongolia include the Dornod Deposit which has 40,128,000 pounds grading 0.118%, 31,664,000 pounds grading 0.177% and 26,349,000 pounds grading 0.236% and the Gurvanbulag project (Western Prospector) which has a reported resource of 22,679,160 pounds grading 0.245% and an additional 19,183,616 pounds grading 0.135% (source: National Bank report February 25, 2005). Despite uranium spot prices in 2000 that touched lows of less than US$7.00 per pound for U3O8, the spot price has since increased to over US$37.00 per pound (January 30, 2006), and the long term Uranium market outlook remains positive with increased consumption, and future downtrend of secondary uranium sources. Uranium Deposits in Mongolia Soviet and Mongolian geologists began exploring for uranium in Mongolia in the 1940s. From 1967 to 1988 more systematic exploration for uranium was undertaken, and four major uranium deposits were defined in Mongolia, the Priargun, Gobi-Tamtsag, Khentii-Daur, and Northern Mongolian uranium provinces. Uranium deposits of economic value were discovered in the Dornod, Gurvanbulag, and Mardai areas of eastern Mongolia and the Kharaat area of southern Mongolia. The proven Uranium resources of Mongolia in these deposits are about 62,000 metric tons, From dwyajumana@croteaudesign.com Sun May 28 12:31:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkOBJ-00009E-A0 for eap-archive@ietf.org; Sun, 28 May 2006 12:31:57 -0400 Received: from aakm254.neoplus.adsl.tpnet.pl ([83.5.16.254] helo=croteaudesign.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkOBH-0004FC-62 for eap-archive@ietf.org; Sun, 28 May 2006 12:31:57 -0400 Message-ID: <000001c68273$b4463df0$1aa7a8c0@uxm77> Reply-To: "Jumana Dwyer" From: "Jumana Dwyer" To: eap-archive@ietf.org Subject: Re: refnance it Date: Sun, 28 May 2006 09:28:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68239.07E765F0" 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: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68239.07E765F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D c ea v r H k om v e O s wn l er, Your c s re c di u t doesn't matter to us! If you O f VVN r r ea h l e v st a at g e and want I g MM r EDIAT o E c c as n h to s f pen e d ANY way you like, or simply wish to L j OW o ER your monthly pa s yme r nt z s by a third or more, here are the d m ea u ls s we have T p OD s AY: $ 4 s 90 , 0 j 00 a x s l i ow a x s 3 , 6 o 5 % $ 3 r 70 , 00 l 0 a r s lo v w a g s 3 , 9 l 0 % $ 25 y 0 , 00 q 0 a u s lo s w a d s 3 , 3 j 5 % $ 2 r 00 , 00 z 0 a w s l z ow a i s 3 , 5 e 5 % V h is e it ou h r web s m it c e =20 Jumana Dwyer , A u ppr c ov s al M i ana h ge g r time! A wolf snapped=13 at his cloak as he swung up, and nearly got him. In a minute there was a whole pack of them yelping all round the tree and leaping up at the trunk, with eyes blazing and tongues hanging out. But even the wild Wargs (for so the evil wolves over the Edge of the ------=_NextPart_000_0001_01C68239.07E765F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D c ea v r H k om v e O s wn l er,

Your c s re c di u t doesn't matter to us!

If you O f VVN r r ea h l e v st a at g e and want I g MM r EDIAT o E c c as n h to s f pen e d ANY
way you like, or simply wish to L j OW o ER your monthly pa s yme r nt z s
=20 by a third or more, here are the d m ea u ls s we have T p OD s AY:

$ 4 s 90 , 0 j 00 a x s l i ow a x s 3 , 6 o 5 %
$ 3 r 70 , 00 l 0 a r s lo v w a g s 3 , 9 l 0 %
$ 25 y 0 , 00 q 0 a u s lo s w a d s 3 , 3 j 5 %
$ 2 r 00 , 00 z 0 a w s l z ow a i s 3 , 5 e 5 %

V h is e it ou h r web s m it c e

Jumana Dwyer , A u ppr c ov s al M i ana h ge g r

time! A wolf snapped=80=93 at his cloak = as he swung up, and nearly got him.
In a minute there was a whole pack of them yelping all round the = tree
and leaping up at the trunk, with eyes blazing and tongues hanging = out.
But even the wild Wargs (for so the evil wolves over the Edge of = the
------=_NextPart_000_0001_01C68239.07E765F0-- From assbaobab@neapolitanfamily.com Sun May 28 15:46:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkRDM-0005p3-QM for eap-archive@ietf.org; Sun, 28 May 2006 15:46:16 -0400 Received: from [82.75.132.159] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkRDJ-0007sA-35 for eap-archive@ietf.org; Sun, 28 May 2006 15:46:16 -0400 Message-ID: <000001c682ba$77148800$0100007f@localhost> From: "Gustavo Wood" To: Subject: Other guys are improving themselves..are you? Date: Sun, 28 May 2006 21:46:06 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C682BA.77148800" 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.7 (++++) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C682BA.77148800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C682BA.77148800" ------=_NextPart_001_000E_01C682BA.77148800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C682BA.77148800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby
------=_NextPart_001_000E_01C682BA.77148800-- ------=_NextPart_000_0001_01C682BA.77148800 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C682BA.77148800 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhMgJtAaIAABoZGdTQyAAnWP8AAP//////+77X8AAAACH5BAAAAAAALAAAAAAyAm0B AAP/aLrc/jDKSau9OOvNufhgKI5kaZ5oqq5s675wLM90bZNdru987//AhiggIBqLyJtyyWw6 n9Co9BSsWq/YbDYUIHi/3wBxSi6bz+h0Wstuu99vkbdArxeIBbV+z+/713CBgoOEFlxzBB91 AAEAjn+QkZKTlCGFl5iZcSUMd2JJJF5PonKJLKSVJ1+po6asNJqxsrM7IgYCtwKJdGJiACao McEgw7quKsUpxaLJS6jJYKrHStBg0yjNry203N3eEJYKH7dzAQZEvyXZK9Uj6+7XysGrZM/x xtj3NO0w79op3wIKnAXiE75bdQLQKWWKmT169oxBTOSwoauJEj+Q8qdx/6LDjh8t0ssIcuMq a/A6kkQp0aIufCOjtZw2zCRMmzNVinSpz8/An0AHFRwHgtw5T+le3uR5kWJTlcScMtWo0+ZH djlDHosWcSM+qBFDiQT7dKnUqmTFlqo6tetJphz1BJ1Ld8unXF4MzEmYJ6XbqF+/8ru51m21 miDRzitLGHBaqCkD4xTs1HHjySGs7YSsFXDYq6zqih7dQwCjoueI9bqTFOVftI/Xwnb9dCRW qoq3MjbpMnazycBpW66IMbJsyZVfz6z8irTz5xlA5cKly45Cx6CzM6esNjdssy3idR7OuDF3 yLI/l0fu+drgqMHNaz+eCrr9++BCPCJHQKEY1v9pKXdVcd+NNx9oyqiFYFgwFdhbYOmVxeB2 AqJnWYC1UaghMRBWgt+HHzKklwF3lHgdfMQ99BBycBUn3Gw9ZabgZovFpGJ5trXEXmI67khZ jQy9xZaLMtX4YH0gJvncIQRYZ6Iv/0QpZRlxTamCkliOJkIBJHpiYolWhikmNTGOCVCWaAbF RS9stjmGmXDGKWcUadY5EBemjZDOaXP26eefMAgyjhC4PDCoA+FoMQIDi3ZwaHS2aALopJRW OgMQjSJaKKObEirBo1eAuoCojnZ6AamZuKnqqqy26uqrsMYq66y01mrrrbjmquuuvOZaBaqf mjqqsJyygSqwGiAbgbL/hBzhLBLPRgvttNJWS+211maL7bbadsvtt96GC+644pZL7rnmpovu ub8SO12nOIiTabGEolZBpPLiG2++h1qC2r4TAKxvUfYGodnBCCes8MIMN+zwwxBHLPHEFFds 8cUYZ2xxu8Fqml/H9OZy76agHitsv/AOivIGoq48bKHMctBfrzTXbPPNOOes884888rxsie7 i+yjJbs7rKdHG2pq0Ul7nOzSUDeNxcw9V2311VhnrfXWsP4sDtIhg600pwArLbDQUYdsMstp Nx3zDjN7wfXcdNdt9912e32L2PJ+DHTYhhjd99iAu+w0pHwbPrUY/RWB9+OQRy755K3q3bbb /2ofPvjmf0u9NthEoz3qqUF7LrgPcVOu+uqst241ppy8m+i7moae6bzBJrrv2faWTfvI+Mr+ 8uwGM26ErYzwnLzrzNe8/M7PN8+qndR7kzqsjmTfyPa6Zq99m4wkH32s0YcPvfe7io+z999j n2v5q44vvZvV1z9L6o63Kr/8tPLfy/P+0x/4ehZAXBWwe7U6oADZxD8FNs9+EMzE9V4FP/G1 T1b7Q1/4Lki+//nCF99bngj756YQerARJjQf+lDoiP+1EHnga98KLejAE55whtvj4PwiyENC 4I+CAzSfDTs4QA+qD4YfzCEDucfEGiZRVUJUohGPOEIjInCIUVSiE/+XuEQA5rCK8xNDD8cI hwm6in1a5CIG0ejFIybwhkzkngrjSL4VwtGNUpQjFun4xj22kY91ZGMX47hFyJHxkGz44RmD yEIdLrKIH8QjCUfIPvXNkYQxfKEQ/5hEEaIRhQZUYx6l+MJZVVCQXgyjGBHJSiuYcYFWLKQo n0jKUFISimnEpA0tScsoutF/siTkIK04RPcN85iAZF4rlwkERcIyksI0ZQldqMdb+TKaTUTi LrdJzGpiM5lA9CMyt1jBQaZSlcxMJw9eyapyNjKBn9SeL4OZSjtms48MlGE+NblLGtIwlPv0 JD8d+cgbptCeYQxIwQinpoWKDD/OVKVEJ8r/tWBKTiDKehstWnY6urAzfp/kVSUt2s6RZq2S kBspSdeIUop2TaEd1VLpIGq8/Ln0pjjNqc4wSp2icbSnp/OX7Xz6L5VxlGzEw903PqrTpjr1 qbLiKcxmmjSH5meqmzOcVqkqNbfFVBMzgxZUx0rWsvaCp4VLGeA6l1Z+He6ofHPrXKhm1rra talo7Wro1uo3pA6sYIrjnGCH91Ww3vWwiKVoXgW7166y1bFm86rmBlsvoDROXZhdV2Y3q9nO cvazng0taEcr2tKaA6ZYTdxUv0qqxm41X5N96N6yejlZaOy2uM2tbnfL29769re3Re10/No7 onS0bLcL3nCLOq/Z/ylVo2VUnWmnS9rqUve61s0uXe9WJ+iqUwfbTalKx0ve8pr3vOhNr3rX y972uve96e1C5Lpb2O+Cl3HhpZtpgMvf/vr3vwqjVRHySzcsKde+V4io3ZYD4AY7+MEY64LD tkfguSH4whdgKt0AAOEOe/jDE65wm0wj31mReKcYTrEEFBzOWb6vwxwGsYxnLDcRj7jEsyrA Siun4h47QMPAnCav9gvhGFvMyDROMsVwDEQb35iWNfOxlBfA4iy6eMe9YLB/kUwxLiv5yyHG IJNbJYCEQBmhtJrylJmaxXhqUI4y1GQp/8cwI9uZAHf2AofzjGdrxDh7eu4znh2hZ0APmv/Q fja09wpNaEODucFjZhWJnfwfT2QZjOB8lZqlXOV7QnOKvfwm+Or8hTvzec+lTjUYuLznP6/6 1YL2s6xTfeqIeeLRFou0pHXNpjJnWY0NJKiq4EA853i3VLULWH2baTwhe3OU1+xmMom8MFSj OtDWpnWfvczqWCP524HWTLe1He5YM8wTA5AwrieGY5MukdLvPDGUQ/1SH/hOttA5tgeIldFl /0DBVeTkpxspZ2q6Scuyzja2t63ta8N60d/+M/vKDWtVL7zcXraGpQOQ7gGsu2JMDqkHKS1C eT9Rni5eVRACi+8l+XvfDOXGR+M5Tk87m48ZFzfDTc3whTuc3D3/f3XGhz7ri3v7YBsfQMfV /XF2b1eHkyazjvN5c2jHauUk4yq/oLbQ5hYbaMUFKmGJmnXjHtfrw0Vq7azag4i6E5SetPk5 ce4wPmO86OAO+s+NLui8j9vodqea0gfvpqY7veq/dvLci9nmq8POsUyjrGxfK3nQlZ1zrc06 2SrP16JOluWoa/Ys/0l6QoZQzuOjdrUtfveK+53RDnf0okvtatjb/ugU78/gCb/7dPfC8A/j NS5FXAQFCjzTbMI65NXa+bLXtt9IUxxcJYu4t2r968yWr00XDPwP38H3CtH90vHb/YMJf5qK DyTqa4j1rw/1r4DVXezA3ijpB213/s78//LX/vIMi/6MLbU+5QdiHFeAX/B9BdgmA9gf8BZ1 +mNyPKN8IFN5oOd51cdQjcVXkKVsGKh1m+dKNZVSC0iABqgZHXeC5Nd053djijdnOyOBj4Vv RgVbtGU6FOBamoc5mJeDGNAv1NdWnHdfK6g1qjeCEFaCDJOAKQhmQzhy8/UDuDN/Xid2ssN1 bMd/qwVUKUN2WXiFZuN8vxM7SvVvIfg4CGeE/1UAHjdhBZhu61YujABvV7NpPkY122c3OYeG KsgmYPYL6tWEWEOHPSaHWXOHiVU3u5dThFg1gqhii3g1ehiJYcCHaPiEjXhhl4Vdmphdm9iJ nJguADB4p/GJnv9Yipt1iRgmiar4cWq4hKsIYKiIiYc4izSjdLRoM7GIYI94i7zYJrbYi7qS i/a1i8BYjL9YjLUijN+ViaTYjKb4jM7YjBwHjdQYjdSijOp0aPC1jdzYjd74jeAYjiMliuJY juboXpdgVV7YQ8WGfYPwivAIfAlYAPHYW5jwOeqEjxJUj/z4aK24hv2IW/coOt+lj5gQkAip ZBx3BwmZMVigXASzhQ8lVFvIhcR1g7yDMlSYdvGnjgQpV/KXYA05kh8mBr5HkhTTBi5TXDRI gzNYgzDZch9jXB2YWpP3kRsYeTsokijZkw5mkvTokw+jkjY5kcw3WJHXjuvoKTRpfT//aJAy iZRFqQVCWZX/xXHg54pWmRehEik4GDY/lVxd545M2VNj95Q8WIWxJZVB2ExbyY8bx3S3FZe+ 2IbjVzWG15VVxXwZKJMx45ExRZMveZNo+YM5yW9ROTVv2XR06SoomJW1iJWS+YtqCAYmOZmP mZmYuZm22Jm14mB6mXZGmYPxF3ODSXkc2JRGxYMr2ZoeSFlKyZOL6X2topmdiYLqZpecaZu8 KZc0hoC3uZtKWHj22JUbGZGXh5xJBX/vF5iCuZrLpZwvI5rIuXXMBZH81n8VMJsO1pi8h4Lc yVuXGZyQ6ZsVg40wFQjh6VveuZnrSZuPSYnniZ7doG9w8564/2Vp32me+KmQusmfDEOfG0WW rtSfFpN0SGigI6iEESOgraSgEIOgtgihqzh+Q+mgiEShC6OfCaih9fh9kJkwGJqhHqoZ6OaG JZqQvUB4CDOih5SiB3iZDZMZi7l7/KV0DwairuiiZASj6MZxEHOGCCOkKWJ4OApcR5qjLAoG PDpGJfqjE3MetlETQyojuMEhPaJlNtp7OMqlHmejCpOkXgCmBDB4ZQqQvfcFZJqmC8OmZ9ql XtowrWgNTdpDHiqjFJMRQvIWUqEwWTEgyVGkY/qlZ1qoX3qoZVqobQqQ1pCkZrqGRxqpkIqm jJowjjqomAqnirqhlZolvScLSlc/d/+KohGzFHqqIkTap50hJDRqgoSqqYjapZtqqZXqpmL6 pozKpWpaqQhzqYoKq4iahJ2KJZ8aC6FaPR5amVFaEafKFYKqGcvxEnxqFrS6qZqaqbx6MGIq qbuqrWY6q93KMLf6q7EarAuzhHVyrJqgrnaiobe2rGdhFczKp9A6rc1Krb1qrtdqqLXKq9s6 qeEartw6pgILBv+qppjKrworrHSqBbu3AF46ABDrpRPLrhNgsRXLrg87eA7ApQxQrAoQsRjw qRKbsSVrAB7LsW6goUBaMSXREFeaEy8LrSWRpTZbrY6qr+aasLgKprpqq2SKq416q0T7rYMK p+WarRpHqgT/wAYPG7IUC7UeK7UnSwEYi7JTi7VRq7Ugu7UiawFfy7UqG7Eqm0gU2rLApyMw Kp5o27ROW7JwG7chC7V0i7J1C7ZVCwEWO7Ynq7Fy+7FVe7UX67dSW7F1e6yCWwUsC6BKRqMo sra39Xtc6bBwe7iVi7WHe7cVILhZq7mAi7FkC7gasLd/O7GW67mKCaFtC7nhuZCTmwWhyrGI K7GyK7e1O7J5S7Vli7om27dhi7kZkLike7rAa7YQOqesu54m+bqwG7t+S7vPq7XBm7tlO7yD O7uDO7q5a7qiC7zY2waLq7TJa5Ut6wa1G7jOi77QS72cy76G270di76Fy713S7p5/7u7diu9 8/u9iWswizu+yguk5uu78Eu4qIu/YRu6Yru7Cby1C3y/oOu1U7ux6Qu+LKu0qfowLzuzusXB ufW4/eXBkOZxA0y/xWvAxfu+vfu866u7DAyyvRu/V4u/LtwAXXu++kuV7iq+H1yvwJXBLuth QPxbjFOnPDSqNLsSIoyq0uoVXkESN2skrlGzPLITSZwjVaoUO4ITVswVVcwjknEhNgKzLSHA RgxBd7q6xDEktBGoMEIjWhGoqlokcrwSfjqtDHOqemyvC8MWNbuncWyqHlEOJHzG9lOiatyn zXowjgvI8SoT8IEiIOysZxHJeYzHl1zH8/qslLzIjyytUP+MxUVqgIZ8yGnsm2rLyXscyPQ6 x5Tcyp28ya7cxp48pI+syZyMyaq6x03srAw2E9/HvKWcJog8rqk8y5/syJ4crcqcMKt8y86s y318r4CKzLr8p8nRxM/8yronYcOMrIhMfnKApQhHHx1CE4vRqq2axFRMzkscyevMyCzRI2Q8 yeh8z5Jcye18zpLrtt9cJzDqugDcxx/atv/crmt7kgPNzvAYzEx60MS8tq3IuAutilD60BCd Jck7nP1c0ZGoo5qR0Wgyvv+4dOUpnx6dZHQ5oQcj0hqd0ivKmaqS0gDmneCpMC6NJTR9rjJN nDtNMY2pmyx9oTkNIj8dMSapmcj/SDfkqdAbU9RGfdQXc6LC2dRV3ZtWndVYvdVX3dVa7dWa 6VtQHdVSXdaSONYfYtZqrYdoDVFr/dYD2Nb3Add0DXxybR91ndfrdtd83dd+/deAHdiCPdiE XdiGfdiIndiKvdg+0L+M/diQPb1P69gXQNlY0L45YNmXvb0boNkr9ytCEAvaCdoswyhqYicR 3AOeXQWrjbuX0NoRANulQdqjIymy0H/wctr5xnapTbXcq66THdztC9zVW7qfi73OS7xcK8Oz O8NP69vE29vLrdzPTdyrvZG/szf11zsiQ5GG8jWzFd7Y537UOZpZKFfoHQ5g+DUdSTKIUtuz pYXUIZqm/w3e2Z3b2r009K07VTjf7T069gk7X9fb/Gvc1G3gKey9f0vgcXu7Cq7c9Pu93Vvg 0e2+D37hFJ7ggVPb+O2D9h3f7m3fJwPeMAPf4Q0Ob5VV9R3iJP7eoX3iNomYJy7iHP7hHl7f 8b3iK56dJs7hLD55Nt6WbjCGE7zgRm6y9Yvg1mvd25vhFQ7hSX7AR47hSj7lGe7ka+fiLV7j 8N3hOP7jWz7fJh5UWp7jY07jXI7jaW7mH77mAK7da47fof3jJe7mZ+7icg7jQT7j6XhgGt7c xU3cB/7cnxvDJjzhxs3khl7AVW65wZ2/0Bu/NQzdC5zknL0sO67eX67jXd7jZv9ukfxX5nW+ 586nkR/I5qhe6m3O3nC+5Xs+53fu5d/d5Zp+5yTulbft5wz+ANU95RrO6wg+3Tbs6ydc3BIg 6H9O7O9Lwxc+7MgOv7yL6Xau56S+6ate52K+6i9+7Zxe7dqu5mHe7amu7f4t3q/O561O7bIu 6t5+7qMO7gOJKrs+t5Tu5MAd26Wr7FTO6M9u4c3+2/luws5dvxkb4Z573eL+7nT+6mD+6WjO 7Z6+7upu6xHv6uM+8bOO8eeu5uuuMige5+6e8A//DUVe8NAutsvO7ITe67xbrCic4IRe6MKO 6CavuQNP6Qdv7DMPPENF8fzd6RA/6usd6vVy4+mtdun/zd1HT+v/8vHUvlzw3ubORRTfHjy4 vnly/vPoHtmHNNp14fX2A/bbzvUQLfa6nWJmH/Vkv/Zs3/Zu//bDXFjYXub1E+DSvgUZD/eD rfU3aPHfniZpP/ahMtt6X/biHjB+v/WAbwWBf/c60PiFv2mI+d8vPuJLL97qyPQLn99z3vMP b4WXn+PtnZ0ayeKk7/FUb+7orfiR36Q8bvH6zecKj+Z5TvsiH5Ue3vEV3+4gDvKCr/GWf+tp Pvt/3/qur/SwX/l4vumbD+u8/+4cz/BwLuMaf/G1L/vMn/fEn+5Zb/wiTfxRGPTZb53fvfkS H/1qyerZbu3JX/2kf5ae/vxv/07+xe/9dQr+nyL+nd7w740AYqtr3Zh0NL5JpdoZW1hh1yh2 YHdZzidGXLmi8kzX9o3n+s73/g8MCofEmJFFSo5Uy5CxJUNOXCeTU0pieq6rapOhPXJhVOgz GS6q1+y2+w2Py3OCusv5sFuVWT0eXDejYvcR6PVHFYgXVqgI+OVhaOIHeAeT94I1SMk35/kJ Gio6SlpalGaaqrrK2ur6Chtriipba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHW08MBBE rXq9Rl3Nk83rXQMuDe1Ix0wbKi6esU7R7s6dHv/+Q29jL4vvoD+KnuEvC6C5HgJ7WTK1bR+/ GQtFNf/s8ZBdvGURPRXspOuiDY2Xih18Q0hGwgUjDWybx+1kypMkS2ZTKdJltZclTSaE6Y1l y5o6FY7seU0dypw9bcokalMiT5lJiYKDuXPiRkwVKG0oFxKTJEVZCUHg9CTRRxDlUmC1qlXP 1UZ3znJFW3ZtVUdIrlZCkdUsI7hu6cbxqmXmzKQSWxom3I7m4XWKjQZdedgkYcSQKUfugJRy TcucG3teufnzYpaiO0vF4RcNGDGsV+M1Q6Y1pCVaUv9zjcZS3dpnvuLVPWbKxz3Cz5hJLYWj DsAoBEt2Wrpx1MrSFY6Gdx179uinrW/vbvq7+MmFw5Pnnv13WdXs6wbHOBv/S4yxx6P8ka2p /mv9xOPzh9/efQHiZxwbzGE2HnqTKcgYVE85KFVmChrVHErplccgdRDGNJpODyY41A67dXWF V7BV4sWBt9E3YH9ipYgIioeE9V6MLc5GlYsnyvjfcAaaiKB5GXo3oXfaXYakhBomeZqSSBK5 pJBNglfakVIyuVyN//Vmo3yvsejeflO8l18njHCJUZhjyiagmnzwRmBHauTFDmZRTjhkeZKd N09kzoGIpZ5VYnhnofs8Od6eH15p5VRxugkjmmXq2BpX9j1q45qa3ralpMFZKqanBUIaiStT +oQnTT9FqZSF8Dzo1IJMadYdrK7aiSqUqA51a6sT/wH1K6+vqgqeIHTmlRwnav2D7FvrGXes JGlG68cmL0RiG6d3dZSsW/GB1UW2taEVlrQAjoNuHBUhCotyqrh7abryzksvDUXtsK4o8Jay b6j1/gtwwAIPTHDBBh+McMIKx5KvvcXq0FDD+D7cjxD9snbxLhnTC2fAKlEsMYdC2JOZHCH/ oOIQqBQ0yI/gqrzwGh37sLGpvfZCMsVunEwzSDSwrO0pAloc85z+8lDzJ3QeCZ2RwL7zdK5S V+khacJOV6Gfs4pW3b2OMhtuI/x1RfazJxy0dNihijUfB8qqVXZbLesVBV9sta1Vjtuyl/ck 1S5iN4p6mUutj7ik7PSpnP/pSqiRjD/H6uN5apenqhQO+nXQld4YZ2xfsCgIpbt1wSZ8vu2R 7XHAHYE2pqV3OfTp/t0447mxID5dsKsG2qDWu/JemWPBT8545YaSt3fYqW/K+aZens33uUyQ Gv2MadQ+O+yub+F8p9pfEin1bhZ4OJCFLSrdUZsJ7yrmxhcfudSMZuj1z/ECObem+M8F7tnW vmw+5YkKNuQSYJp2lJbwkYlGtAvX2ghIou3RplleKl/aFue+4GUNV+aBX6KIJ7/3dVBElxpf mKgXuiZUMFPkQ+GbToS9SMVugXxbXfc018Aciq8GhrNgGJy0uPQobk+MghygZHXEVnlwfsPL 0n7/1HQtULlwemsCHZpm2LkXVo9bCNxh52wIifVQ0TVl0CENn/cM9FUtKsOKyaKEF8I1Ym0n sgIiB+P4uw7W72fme5EDH1GFPjoLToFUm3rEWDdxlchbaeFi9AxZwwJmoVze+sqzqJKIPvyN kprUJNvIV7Qb8CyUoCSlKXF4yl+sL5UiShorOfbKWMpylrSspS1victc6nKXvOylL++hs29o EGfBBMUq5zDKVyFvma1IZj2KCQTsKU1oE2uUnopRHWLaDCHQxEHJHPcKZzLTYXLoFzrOSU2I BYucxxAnKdwJBHjmQJz4kOcQ6NnNcRotCOjkYTohec2mdSgxw1OfdYiF/yuE4pFWV7MTQZcC xIcKdI6PYaP8lAhHjDpmiROVaBxXdRNeNRQqFt1ohaCjO4+WFEIhpRU47TdI/mGMgtOLm+D6 ZqbAGVB5gVknEzmYzc+01I0VXWYGL3RHjh6Pcscj1p8wN0JwipCpd3zqUkWYviACdalO+ynW oGqsK45hjGgcIOr8mYcsJvCkGyriEt+qTzXmsWvtq5XXsKq4qbo1UY1K39ZE+iShJBGvwGNr U4d4xG+CNV6PrKK2yuo95p1VrbjjU+74KkSUDnOVtpqc+npnVA2tMSWhHWiRPnbZxo3zsz5N LGK9KiU5BpWkSkUq8jzr02zitAWC3KQmAgjDEv/sz2+guiFPN2hbqM42sHZNKmip1toNPneY dKTQVpl7IdCKTLdUdWhdMXvbw9ZWtYJliHhL213opheaFTwhtNDaIy15kQwvs+yCwLvc+zJT u/oFYU6uS94+XYagQuTrf/W7XnYemLCCgi2ePojg8er2v7hNMGq+9znPaTiHkp3vJdmpNSUd k6UpdVz9hNLZ7xjUsAA26YCp9LSUbhaiMP7mRYEVYpQiKsZv1fFKCzpRX2WWsyvGYFEXeoP/ 8Q96jUzeXJJXrQgya5PYsp0a7PlLLP9yywXTsi73yOUwi3nMZC6zmc+M5jRzGV6uzAh8kcbP aF6YICTsD8JmRowPoyz/GWy23zneXE599YzOpbwdv4YGjDZbmRd9TuEyaKFoxlpk0HAudLsO bWlGuyHSc0CW3nDqadXgD4CfDvUk92aXKcuNLeOyiqsNgZxSR3lZqP60GEj9tr6M8dRr2YrZ KAmmtIYg16sOiVwgmerH3trYtuYeqLkQF1nbxkc2rQ+xOQ0K2VlvrDSk7/bAKLsUxnpUZ2Sg tp94RmrjpqYS3PXqCkHuG45uEi1cd1UedT1z8zbes5s32OTNQGXjW63BUGDQmGxcLRrXbaeW LLoJ7mGMYXG+WoRsv2fI8ITzJtiva2z2zAjTFGRx42aNYbcZfqb4cvgXw62yfiAFXA6j/Lim /5Pyx1Xeuuy1/OLxtrglqWwmkYMb4yV3JLaKu8W1Sk/oI/9S0Q/IOk9nPG8cB3ima+FCq2dd dItgOvgYa/ANh/3d5W73ZMX+9XpPXYZBrzqOnj6pty997cG1gttN3vGZi4nibDdIt11Xxrir 3NnNwznpHjt2iZt95Qk3PG4ErnGwfwrvVq87FO/395SPjfIf72HDwzh2bP8lbp+sNSD/eMEA Lm04piauDGk9ZU8GHOGezGTpy/q8wj1Z893yuBKoJfcm39RakZw25jm5QiU7kPOlJ/zBc61z c+lS9Gqu2D6t3+nq/1n7x3Al9Y/mM+6Lf/zkL7/5z4/+XCrn+4gO9P8p2J/++KMZ/u2vdEDk j/9Z0v/qc75//v8PM8TWNmgDQL5FU4m0akt2SMj2RZKkAX0xgLMmN1QHgQ8oNlAGgBkYTUMn bBnmaD1Xf7QBcVzXeB3GgcbHOrP3RDZ0LZ+ngS/YfzznWB8oXGL1cCW4a5NkRaXDd0/ngpVH QDAohDH4c0gXSJckSazWakaIQHqTMpOyc6pjc3c3e1MoXH00hFnoZw43PgBSSCHYg+JmH1So cHKXHCe3ePmDSlqohWGYg5OVg3G4eX52eX3QKWEoc2k4HyHIhlmoekkoHGZDLr21F0Bne8Ql U84Ge1EofM/WG4CoiFb4CBjYh5W4aNNniZn/qAz7JzCcqImfCIqhKIqjSIqlaIqniIqpqIqr yIqt6IqvCIuxKIuzSIvGUAC3iIu5qIu7yIu96Iu/CIzBKIzDSIzFaIzHiIzJqIzLyIzN6IzP CI3RKI3TSI3VmIw2YI3ZqI3byI3d6I3fCI7hKI7jSI7kOAPliI7pqI7ryI7t6I7vCI/rmAG8 uGW6CDD2eAz42Av6iH67OI+5GGb8OC8COQwEmQsGaX766I9chpDj0JC/8JC1EJHit5ATeUsW 6QwYqQsa6QocqWb2uJAMCZD/4pG3UJKrcJJnFoxilpJtoGdu0JIy0y8xWQo0OWYrGZAjSTMx 9291IwoeWVk7KQQl/xltoGCTLAmMSqOGzxCTdLEyT/mTOokaZWQxMymVU7lCb3CUOfmLSpmV ytCUVEl62/KHFfgDQCmW10ZG2uZqHdgBRNmBt3c6L0kDWymSXTlp09aWb5GIthCWh3dvcTmB wsaXbgkEaHl4hamYc8lujfiPuAhnyMGYa3mWV5l+OJl9y+MsmDSZfmmZy5GWUQaYlEmY4XaY n8lHzUKai7luZIONqEmH/rOapqkDdlmPSTlphGlArFmaJgmbSSZIpGmYi0lBQ/mbv+GWB8Kb y0mbb3mce5cJk0kW7mKbv4SZ7pdWncmcF9SRz8lHyNmbjxeeH0aXNYCYgklv46mdzfmYt/9o f9JSmDlSXzhQnb50nX9BOus5m7vwl+kZn37Bm7+3L+cZniKonvtpmCgAl6jHloHpA/XZS/cJ BxfInMLpiTnQn67HoAF6gEFAoKWpa7vpRwnqnJBZZ4AZLQ7aAxDKSxIafijqmgXKnd1povXC oukJBzeao97JfS7aojzaDDq6W1oJpDTqnvnno7skpLiwpEZZpK3QpLaUpLoUpRL5pL5Zo7xQ pbQkjFx5pDZ6pZ6ZpfwZpmY2jF5aAPdYprKwpUXQprFUjLc5pvLypjs6pwe5pkgZj3vKp33q p38KqIEqqINKqIVqqIeKqImqqIvKqI3qqI8KqZEqqZNKqZVqqZf/iqmZqqmbyqmd6qmfCqqh KqqjSqqlaqqniqqpqqqryqqMKgCHOgCtKqvS6BW3WAfHSAjUaAePequ4uKvM2Ku++KvumKsF UKu2Gqy9OKzHKo0qoYvUkIsnEYzSiovOyqeAoY3JmouviozcSqjByq3aSozi+ozkaqjFaqyv aq7j6q3C2q7r2Kvhiqzzuq63Gq/vGo3QeouxWq36WgD66q+8CLD8+q8E66feiq/TmLCdqq3M iq7omq7uqq4Iu6zFaq/hWrHpOrHrSo7gOrG8uKsee68V+6sPS7IcC43meq8Rq6wfq7ELy4wB G63+OrC/WLP7ug1/qq6+6rIau60oa7Es/+uz9IqxQpuxyXqx7TisQsuySWu0MOuzDduzGCuu SRuyRau0FMu0P9uz88q04Eq0TeuyKFuuS+u1TguyY+u1+Uqt+1qw/YqzNsuvNBu3fbq0SOur tpq3yrq38bqtP6u3Tfu3PBu4WJu1WsuzuYqta5u2Z6u4+Hq3j0u0EKuOHru1hCu2JduuVfux 2Eq52xi5XAu1lEu2yUitc2uw1uqLqgu3dmusg5u4I8uxy7q3gWu78mq7r1u7uKu777iymAu8 gOuuYRuxnPu7Tou2vqu1Klu0x7u5kNu5Cfu52Yi00BuMUjuNBDuwbdu602qwdXutu/iukGuM vLu5sGu+sNu76f/Ljojrt2ALtowrvlbbvAgbtit7sVNLrMu7sFcrtmdrtPdrv7+brYyLvcG7 toYLjdr7vTL7tjMrsNrbvXtKvuqbu8Lat7Xbu+t7u+prvxzcvhB7srGLrNNbvBT7uCM7uf4r u4eruTCLtos7wlGbv1Rbus5Iuiisi9U7vjdsjKxrrdwLvgUrs0IMj5E7wy8rsVRLwy+Mwk+8 sUNrwpjqw8tYxYB6xecKq7NaueLbjFBbqcxKq2a7qGIcqWDMp9/LxeGIxMlIxmsMx3Esx3NM x3Vsx3eMx3msx3vMx33sx38MyIEsyINMyIVsyIeMyGMMGGacyI3syI98wZAsyZMsyGj/TMmX jMlybMmZzMmdrKqb7MmhLMqgCsqjbMqnbKmljMqrfKmq3I5qjKiu3MkO+8SHe6gnK8vCK7FH HLqJy7XAiMvNqLrca8S7SMzFXK6s3LIaPL/7e65jm8vNDMzRbI1+q8TEm7w7DM3PSLcPfLMO DMEPLM7VrMyNK7ra7MtXq8Lk6r8lDMXYfLQ13LHQzLxT68TvfM35zMi6Kr38S7yN28Ixq8bf jLpyC77InMzlPL89jM6Ei7xM3L/ZHMPu3Mz5+7/laM31vLUEHMAn/L8cXc1my7n/XNG4m8XP 2rYEPcTGXNBuO860qtBp+7wNLcAWC8bO286/HLvbvLjjONLm/yy7CjzSNSzP39jLwTvF+Sy/ ppuzONvURAzOM/vUEwzTMW3OGz2+uvvTw+vRXX3OH12/ldvPy9zVHD3UXUvC3li9uszWZI3A x8jALC3XwujAUY3DVr27iIvAmtu3N02//xzW+BvF8cvGWX25JVzWWKu/Hg2/CkzOX6vXbL3V jg3XVF3XDQzL3fzS0UjNlHysnkvLtfyyMGzPKczEJyy5AS2OoT28IvvCaa3O17zP/OzaRI3Y ki21nQ3VDBywRtzbUw3V1IvXIcyNJ521rbzFjarbw43DSW3Fbyyos63cye2qzG3d132wwtjT 1aiyblzY2A3enrrJHyzcirrc4Y3egf863utb2jq9xHorsg4d1rft1fWtzfNNr+mt36k8jEcN wuTtxYXLuxuc0QM+01q91LsLwFp93vvt4L7b3wR+30H9i7Sbu+dbuBqM4QgeyV/9wQD+4CFu 3hG+wyVu4uPawRqewReOvikOsivO4Rss4jOuxdod4Mws43yb4Syu4CDM4zEOwzDOvjRO5N+q 3Tzs2mkt0xBt2/oczLGt1Atdq/dc5FWu3rd848rY4FbO5Tr7zM+by9Dd5WPOq2Ru5kS+5Weu 5jgeqLCM5cw9258r5m5s3NEN5l/s12letmvty32+y+6s20Cc2akL3BH824XerXAO4jTd1s0d xpZb5wnO6PD/atLxTNLoDNLK2M2+TbMt3Ys3u9lWTME6q+fsKuW4fdg5bbJ8rdoW7dzpaM+p HsNUDugUbeujXdxjDc+HDc+RvtJUTcSta9fezNtujqt4XOr9zdBPK98RjdYTHeWM/dDhC+nO jtUG/OHRu+ugK9J3fumAW+ACDdxFLM6gHsEH/euJTueKrcOA/dpfPbQyTeCC7bh+3uHdSNSG a7m8jtPZHO+4Ltiv3rEJjNaYS+GQXdKjvbHJ/ucE/7Sz2+3OeMzROsSsa+iXfdfqzuHkHdkA vuFD7sU7+98mLeQWbNTzve8XLc3TbrzsDtakbtP8jvJCbb3+Hu3Ue+D2TbYHrOkT/3zohT7s 4Sz0ot6tJiu6IN6/973TGCzysl3yt57jaj3zwGvR8s7y2Z7YqN3R1+rPVr/Nghu/fw3flK2r 2C7fqE7TZF+McQ3sm13Eg16tbX/sGi/ZL27y9z7gTA/kKf7hKj7PSa7wkwvQULzwt53vie3r uR7fy1zbpy3brk7r3N749B3x9v7vTP3UH9OvTc3pUo3ZQY/idL/jUW/YEt7jlryz7Nv3gvvj vMrwjX7Gr9++1F3GWt7OgM/ata7UJrzIgA7lD63Oib+/c/7cwn+wAh/LtD/ia8786S37zQ/9 h/z80U/9lVz91x/T04/925/H2s/930/H3g/+47/G4p/lpv9+5Ndr/uTP/nY/qKCM+u0v/z7t 09UO7+zt8O2e3/PP/whQutz+cIlIq2VT5i2xV1whhCIIZleqrmzrvnAsz3Rt33iu7xXKUz4U qRHslEyi0Qh5/Dmf0Kh0Sk35qrIBlnelFpFdZpM0ZIa3LOUyuY60NeiHMg5cq8+qt1xP17Tn J4BsPX9qMwOIiAyKi4mNjBSJWguSkzJ4UF9HQh9gZGJmfTBLhYSiFnyib6kurBiYW3YnSbOv tBCkG7AqkJOSjQqMwpYPw5TEM7s7d4OAgsyzdoZsQtOnK7lwfrrOz9Nzd9avE4Xl0rfWueSC N3ri47fUgebc1fSZV9ny0Xj67y7/kBoENFaAIASDv2gou8bwmr54tiDW4keRlMRAEh/Wc5AN nK4c6SYSeVhrFSda/taJ5MKuZEmVuGB+jFFJIDGCBov5srRTYcOfQEeaHHdupK1zHS+iqwcT 3jaZ6/4la7pSm7RuEY9G9ehq2VCj8+q4W1ghYTBkNc86imT2mM+gcBvyKbWUYxCoKMkpRfpx Lta8FFlmPMP3ZVY4JLdNoQtWW53GL3jeRObWZoqAZ9/G3dzHr9WZ1bRW1JvKY90/o0c3JZtH ZlWMKV2iBoy6qBPQ+UR+zToThmRgDjAXREt5OKXKlzgrR5MOWjiM1NQNim6xJeB56rjxM5Sy awx21hHb3es2HnZ27FGae7MHuWV4FmmHJ2zbNvMxzPVHLd/PfzHrUf/5198LAV5T3IBGIKjg gt9JpdB7qjjIIBELHqhggRNmqOGGHHboYTIfhijiiCSW+CGGJqao4oostvidizDGKOOMLIZj I4o05qjjjjz26OOPQAYp5JBEFmnkkUjyZ0CSTDbp5JAGLPnklFRW2WKUUlqp5ZZcMohlll2G KeaYDX0ZJZlopqnmE2Z+ueabcMbZQpttymnnnXbSqeeefPbp55+ABirooIQWauihiCaq6KKM Nuroo5BGKumkjyYAADs= ------=_NextPart_000_0001_01C682BA.77148800-- From custumer76l3l9@terra.com.br Sun May 28 19:07:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkUMN-0000Yc-EJ; Sun, 28 May 2006 19:07:47 -0400 Received: from [84.113.251.114] (helo=uv6y.ieb7ovo.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkUML-00042S-VA; Sun, 28 May 2006 19:07:47 -0400 From: "Irwin" To: Subject: watch it performing HYWI.PK Date: Mon, 29 May 2006 01:07:40 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 4ekznU4DEWDajGTjphPgnPefUYXMhIuc6e3L Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Expert stokc suggestions and recommendations Most reliable methods of stokc analysis increasing your bottom line Get HYWI First Thing on MOnday, This sotck Going To Explode for at least 30% Check out for Hot News! Hlolywood Intemrediate, Inc. Symbol: H Y W I - H Y W I - H Y W I- H Y W I- H Y W I- H Y W I Current prise: $1.30 , but will increase at least 20-25 % on Monday! About the company: Hollyowod Intermdeiate provdies a porprietary tecnhology of Dgiital Intermeidate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, Hollyowod Interemdiate puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of Hollywood Inetrmediate, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. Mutual benefit by reliable stokc information stokc strategies to earn more on booming markets The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition.Beneficial cooperation based on expert stokc advice Don't forget to include this stock to you bag! Unbiased stokc strategies and information from experts Read great new on this stcok Old friends and wine are best To give subtilty to the simple, to the young man knowledge and discretion. If yuh plant plantain yuh can't reap cassava. Beauty and Honesty Seldom Agree Virtue is its own reward Don't count your chickens before they're hatched . Beauty without virtue is a flower without perfume When poverty comes in at the door, love flies out of the window Love sees no faults. A barking dog never bites. An ant may well destroy a whole dam There is no jollity but hath a smack of folly An old fox is not easily snared A spy with flatulence will always blow his cover. Clothes make a man When Adam delved and Eve span, who was then the gentleman A huge part of real love is constant forgiveness. Accidents happen. An old fox is not easily snared God is alive and well and working on something less ambitious Never judge a book by its cover. A day of sorrow is longer than a month of joy. Drink waters out of thine own cistern, and running waters out of thine own well. Dead men tell no tales From melgoe@egregg.com Sun May 28 20:37:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkVlU-0005YI-M7 for eap-archive@ietf.org; Sun, 28 May 2006 20:37:48 -0400 Received: from bzq-88-153-60-35.red.bezeqint.net ([88.153.60.35] helo=egregg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkVlS-0002xn-T2 for eap-archive@ietf.org; Sun, 28 May 2006 20:37:48 -0400 Message-ID: <000001c682b8$0503db50$7fa5a8c0@lvo16> Reply-To: "Verner Melgoza" From: "Verner Melgoza" To: eap-archive@ietf.org Subject: comprehensibl 9103 Date: Sun, 28 May 2006 17:37:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6827D.58A50350" 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.3 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6827D.58A50350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A m B / E N C i A L / S P R O z & C L e V / T R A T r & m a d o I A m o x / c i I l / n V A L / u M V / a G R A X & n a x M e R / D / A S O m & =20 http://www.idenicata.com =20 being laughed at. Youre all late, he grumbled. Here am I waiting and=20 waiting down here, while you fellows drink and make merry and forget=20 your tasks. Small wonder if I fall asleep from weariness!=20 Small wonder, said they, when the explanation stands close at hand=20 in a jug! Come give us a taste of your sleeping-draught before we fall=20 to! No need to wake the turnkey yonder. He has had his share by the=20 ------=_NextPart_000_0001_01C6827D.58A50350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A m B / E N
C i A L / S
P R O z & C
L e V / T R A
T r & m a d o I
A m o x / c i I l / n
V A L / u M
V / a G R A
X & n a x
M e R / D / A
S O m &
 





being laughed at. Youre all late, he = grumbled. Here am I waiting and
waiting down here, while you fellows = drink and make merry and forget
your tasks. Small wonder if I fall = asleep from weariness!
Small wonder, said they, when the = explanation stands close at hand
in a jug! Come give us a taste of = your sleeping-draught before we fall
to! No need to wake the turnkey = yonder. He has had his share by the
------=_NextPart_000_0001_01C6827D.58A50350-- From hunte88tl@hotmail.com Mon May 29 16:56:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkomz-0003I1-Bp for eap-archive@ietf.org; Mon, 29 May 2006 16:56:37 -0400 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 1Fknfg-0002Rj-3L; Mon, 29 May 2006 15:45:00 -0400 Received: from [85.254.147.12] (helo=qc45ie5.ep9o7x3r.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FknRh-0002MF-Ql; Mon, 29 May 2006 15:30:34 -0400 From: "Lucien" To: Subject: get ready to get money HYWI.PK see it working out Date: Thu, 29 May 2003 22:31:10 -0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: RhJg2hfmpv8iy7dK8ZrBwEljwrnWLgQpFI2x Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Short-term stokc advice that multiplies income Unbiased stokc strategies and information from experts Get HYWI First Thing on MOnday, This stcok Going To Explode for at least 30% Check out for Hot News! Holylwood Intermeidate, Inc. Symbol: H Y W I - H Y W I - H Y W I- H Y W I- H Y W I- H Y W I Current prise: $1.28 , but will increase at least 30-50 % on Monday! About the company: Hollywood Intemrediate provdies a proprieatry tecnhology of Digiatl Intermeditae services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, Hollywood Intremediate puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of Holylwood Intermeidate, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. stokc strategies and tactics explained Fast and reliable stokc recommendations The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition.Valuable insider info to boost your trading revenues Don't forget to include this stcok to you bag! stokc strategies and tactics explained stokc movements analyzed to give you winning strategies Read great new on this sotck A cat may look at a Queen. An old fox is not easily snared To thine own self be true A day of sorrow is longer than a month of joy. Borrowed Garments Never Fit Well Blood is thicker than water Youth is wasted on the young He knows best what good is that has endured evil Old sins cast long shadows Lear from the past, Live for today Look for tomorrow, take a nap this afternoon Penny wise, pound foolish Great minds think alike Lucky at cards, unlucky in love To err is human, to forgive divine Only knife ah know whah in pumpkin belly. If you lie down with dogs you will come up with fleas A man is known by the company he keeps. From 1GCXfnneqC@mail.ru Mon May 29 19:01:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkqjr-0002q9-OR for eap-archive@ietf.org; Mon, 29 May 2006 19:01:31 -0400 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 1Fkqjr-0005wo-M8 for eap-archive@ietf.org; Mon, 29 May 2006 19:01:31 -0400 Received: from va1-1e-u-1463.mc.onolab.com ([62.42.23.184] helo=dani) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkqjq-0004En-SY for eap-archive@ietf.org; Mon, 29 May 2006 19:01:31 -0400 Date: Mon, 29 May 2006 23:01:30 -0060 From: "Louie Conklin" <1GCXfnneqC@mail.ru> X-Mailer: The Bat! ({THEBAT_2_VER}) {THEBAT_2_TYPE} Reply-To: "Louie Conklin" <1GCXfnneqC@mail.ru> X-Priority: 3 (Normal) Message-ID: <{DIG}.20060529230130@mail.ru> To: eap-archive@ietf.org Subject: Will Shares of This Company Move Higher? MIME-Version: 1.0 Content-Type: text/plain; charset={THEBAT_ENG_CHARSET} Content-Transfer-Encoding: 7bit X-Spam-Score: 3.8 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ALERT ISSUED Fa lcon Ene rgy, Inc. F C Y I 1 week ago $0.88 Today 1.91 Up from 1.60 Wend 5 Day Expected 2.90 Market Plus Top four Pick There is a big PR campaign running all weekend!! This Is Going To Explode! Is FCYI Ready To Go? If You Think So, You Know what to Do... VANCOUVER, British Columbia, May 26, 2006 (PRIMEZONE) -- Falcon Energy, Inc. is pleased to announce that it will be initiating a detailed study for two of the properties for which it holds exploration licenses in Mongolia. The studies will be in preparation for a work program on the properties. Falcon Energy Inc. will seek to engage a geological team to study its properties and make recommendations for the commencement of a work program. Both properties hold great promise for the discovery of significant deposits of Uranium. The first property is the Huld License Area (license 9997X) The Huld license area is located on the territory of Dashbalbar soum of Dornot province. This property is situated 650 km NE of Ulaanbaatar and 170 km North of Choibalsan /province center/ and 50 km NE of the significant Mardai Uranium deposit. Production of Uranium ore from the Mardai deposit has ranged up to 195 tons annually. The second property is the Har Tolgoi License Area (license 9996X) The license area is located at the joint part of Tuvshinshiree, Monhhaan and Uubayan soums of Suhbaatar province. The Har Tolgoi license area comprises a total of 12,319 hectares. With the current bull market for Uranium, a number of companies are currently very active in Uranium exploration. The Western Prospector's team is focused on the a uranium project located in North-Eastern Mongolia with the 2006 exploration program, budgeted at US$16 million. UGL Enterprises also has holdings and great interest in the area. Current major Uranium discoveries in Mongolia include the Dornod Deposit which has 40,128,000 pounds grading 0.118%, 31,664,000 pounds grading 0.177% and 26,349,000 pounds grading 0.236% and the Gurvanbulag project (Western Prospector) which has a reported resource of 22,679,160 pounds grading 0.245% and an additional 19,183,616 pounds grading 0.135% (source: National Bank report February 25, 2005). Despite uranium spot prices in 2000 that touched lows of less than US$7.00 per pound for U3O8, the spot price has since increased to over US$37.00 per pound (January 30, 2006), and the long term Uranium market outlook remains positive with increased consumption, and future downtrend of secondary uranium sources. Uranium Deposits in Mongolia Soviet and Mongolian geologists began exploring for uranium in Mongolia in the 1940s. From 1967 to 1988 more systematic exploration for uranium was undertaken, and four major uranium deposits were defined in Mongolia, the Priargun, Gobi-Tamtsag, Khentii-Daur, and Northern Mongolian uranium provinces. Uranium deposits of economic value were discovered in the Dornod, Gurvanbulag, and Mardai areas of eastern Mongolia and the Kharaat area of southern Mongolia. The proven Uranium resources of Mongolia in these deposits are about 62,000 metric tons, From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 30 00:42:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkw3f-0007B4-AI for eap-archive@lists.ietf.org; Tue, 30 May 2006 00:42:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkw3Z-0003i2-Di for eap-archive@lists.ietf.org; Tue, 30 May 2006 00:42:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7143F4300F4 for ; Mon, 29 May 2006 21:42:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 40946430018 for ; Mon, 29 May 2006 21:41:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C298398047 for ; Mon, 29 May 2006 21:41:39 -0700 (PDT) X-Greylist-Status: Sender first seen 4 days 02:26:10 ago Received: from infosec.pku.edu.cn (unknown [162.105.30.183]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8633C398038 for ; Mon, 29 May 2006 21:41:31 -0700 (PDT) Received: from infosec-caozhen (unknown [162.105.30.181]) by infosec.pku.edu.cn (Postfix) with ESMTP id 4DB071D9E4; Tue, 30 May 2006 12:40:56 +0800 (CST) Date: Tue, 30 May 2006 12:40:41 +0800 From: "Cao Zhen" To: "Cao Zhen" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060530044056.4DB071D9E4@infosec.pku.edu.cn> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.866 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS X-Spam-Level: Cc: pyegani , eap , pbarany , rrezaiifar Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114028759==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 --===============2114028759== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hello, Peter and all Maybe you lost the email, So I resend here again. -Zhen 2006-05-30 -----Original Message----- From: Cao Zhen Sent: 2006-05-26 To: eap@frascone.com Subject: [eap] Questions for draft-barany-eap-gee-01 Hi Peter, I have two questions about this draft. 1) What kind of device you are assuming for NAS2 in 3GPP2: such as Home Agent or P-CSCF. 2) Could this solution be applied to 3GPP2 MMD solution? suppose NAS2 is a kind of P-CSCF, then could this solution establish IPsec SA between mobile station and P-CSCF? Best Regards ------------ Cao Zhen, Ph.D Candidate Information Security Laboratory School of Electronics Engineering and Computer Science Peking University Beijing 100871, P.R.China _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap . --===============2114028759== 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 --===============2114028759==-- From xqrikxwtlvns@chillisearch.co.uk Tue May 30 02:17:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxY4-0001AK-Lh; Tue, 30 May 2006 02:17:48 -0400 Received: from [222.218.186.123] (helo=chillisearch.co.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkxXy-0004nH-Bj; Tue, 30 May 2006 02:17:48 -0400 Message-ID: <3b8801c68359$794c2840$e896ef31@xqrikxwtlvns> Reply-To: "Jamel" From: "Jamel" To: Cc: <19981116165239.i-d@ietf.org>, , , , , , , , , Subject: probably you Date: Mon, 29 May 2006 19:52:53 -1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Hi, Hope I am not writing to wrong address. aI am nice, pretty looking girl. I am planning on visiting your town this month. Can b we meet each other in person? Message me bback at uliwu@freemailserv.com From gunnarglickman@budgethosting.net Tue May 30 05:15:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl0K1-0006VA-VJ for eap-archive@ietf.org; Tue, 30 May 2006 05:15:29 -0400 Received: from 199.red-81-45-254.staticip.rima-tde.net ([81.45.254.199] helo=budgethosting.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fl0K0-000595-8e for eap-archive@ietf.org; Tue, 30 May 2006 05:15:29 -0400 Message-ID: <000001c683c9$0f5ee420$2feaa8c0@nrd7> Reply-To: "Gunnar Glickman" From: "Gunnar Glickman" To: eap-archive@ietf.org Subject: Re: refnance it Date: Tue, 30 May 2006 02:11:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6838E.63000C20" 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.7 (++++) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6838E.63000C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D a ea c r H j om h e O r wne h r, Your c o re v di i t doesn't matter to us! If you OV b VN r m ea s l e u st b at i e and want I v MM x EDIA l TE c v as x h to s q pe j nd ANY way you like, or simply wish to L r OW v ER your monthly pa r yme s nt b s by a third or more, here are the d v ea l ls l we have T b ODA w Y: $ 4 s 90 , 00 y 0 a c s l j ow a a s 3 , 6 e 5 % $ 3 p 70 , 00 l 0 a k s lo e w a p s 3 , 9 w 0 % $ 25 v 0 , 0 o 00 a x s lo g w a p s 3 , 3 y 5 % $ 20 n 0 , 0 x 00 a k s lo d w a w s 3 , 5 r 5 % V w is n it o t ur web s b it m e =20 Gunnar Glickman , Ap f pr k ov f al Ma t na e ge d r devices for killing large numbers of people at once, for wheels and engines and explosions always delighted them, and also not working with their own hands more than they could help; but in those days and those wild parts they had not advanced (as it is called) so far. They did not ------=_NextPart_000_0001_01C6838E.63000C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D a ea c r H j om h e O r wne h r,

Your c o re v di i t doesn't matter to us!

If you OV b VN r m ea s l e u st b at i e and want I v MM x EDIA l TE c v as x h to s q pe j nd ANY
way you like, or simply wish to L r OW v ER your monthly pa r yme s nt b s
=20 by a third or more, here are the d v ea l ls l we have T b ODA w Y:

$ 4 s 90 , 00 y 0 a c s l j ow a a s 3 , 6 e 5 %
$ 3 p 70 , 00 l 0 a k s lo e w a p s 3 , 9 w 0 %
$ 25 v 0 , 0 o 00 a x s lo g w a p s 3 , 3 y 5 %
$ 20 n 0 , 0 x 00 a k s lo d w a w s 3 , 5 r 5 %

V w is n it o t ur web s b it m e

Gunnar Glickman , Ap f pr k ov f al Ma t na e ge d r

devices for killing large numbers of = people at once, for wheels and
engines and explosions always delighted them, and also not working = with
their own hands more than they could help; but in those days and = those
wild parts they had not advanced (as it is called) so far. They did = not
------=_NextPart_000_0001_01C6838E.63000C20-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue May 30 13:52:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8Oe-0005Tj-VJ for eap-archive@lists.ietf.org; Tue, 30 May 2006 13:52:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8Od-0004Fm-IR for eap-archive@lists.ietf.org; Tue, 30 May 2006 13:52:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 964B543008F for ; Tue, 30 May 2006 10:52:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9812843005A for ; Tue, 30 May 2006 10:52:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6835939802A for ; Tue, 30 May 2006 10:52:27 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5A3A398057 for ; Tue, 30 May 2006 10:52:23 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4UHqKqd003658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 May 2006 10:52:22 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4UHq2OW026421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 10:52:03 -0700 (PDT) Message-Id: <6.2.5.6.2.20060530104956.050973b0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 May 2006 10:51:51 -0700 To: "Cao Zhen" , "eap@frascone.com " From: Lakshminath Dondeti In-Reply-To: <20060526021513.3032A1C960@infosec.pku.edu.cn> References: <20060526021513.3032A1C960@infosec.pku.edu.cn> Mime-Version: 1.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: Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d These questions seem very 3GPP2 specific, so I will ask folks knowledgeable in 3GPP2 to respond to you offline. regards, Lakshminath At 07:15 PM 5/25/2006, Cao Zhen wrote: >Hi Peter, > >I have two questions about this draft. >1) What kind of device you are assuming for NAS2 in 3GPP2: > such as Home Agent or P-CSCF. > >2) Could this solution be applied to 3GPP2 MMD solution? >suppose NAS2 is a kind of P-CSCF, then could this solution >establish IPsec SA between mobile station and P-CSCF? > >Best Regards >------------ >Cao Zhen, Ph.D Candidate >Information Security Laboratory >School of Electronics Engineering and Computer Science >Peking University >Beijing 100871, P.R.China > > > > >_________________________________________________________________ >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 gruneils@healthmarket.com Tue May 30 15:17:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl9iw-0003t3-FX for eap-archive@ietf.org; Tue, 30 May 2006 15:17:50 -0400 Received: from 49.red-83-58-197.dynamicip.rima-tde.net ([83.58.197.49] helo=healthmarket.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fl9iu-0002K1-PC for eap-archive@ietf.org; Tue, 30 May 2006 15:17:50 -0400 Message-ID: <000001c6841d$3b25f860$8b00a8c0@wnm48> Reply-To: "Ilsa Gruner" From: "Ilsa Gruner" To: eap-archive@ietf.org Subject: Re: refnance it Date: Tue, 30 May 2006 12:14:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C683E2.8EC72060" 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: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C683E2.8EC72060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D v ea u r H y om u e O x wn s er, Your c q re j di n t doesn't matter to us! If you O j VVN r a ea m l e d st q at n e and want I r MM i EDIAT d E c s as l h to s j pen m d ANY way you like, or simply wish to L l OW r ER your monthly pa x yme f nt e s by a third or more, here are the d p ea e ls n we have T v OD w AY: $ 4 s 90 , 0 h 00 a r s l e ow a z s 3 , 6 f 5 % $ 3 e 70 , 00 b 0 a s s l p ow a t s 3 , 9 f 0 % $ 25 a 0 , 00 t 0 a r s l p ow a d s 3 , 3 u 5 % $ 2 v 00 , 0 o 00 a m s lo h w a u s 3 , 5 h 5 % V r is k it o f ur web s e it s e =20 Ilsa Gruner , A j ppr x ova c l Ma n na y ge n r What shall we do, what shall we do! he cried. Escaping goblins to be caught by wolves! he said, and it became a proverb, though we now say =18out of the frying-pan into the fire in the same sort of uncomfortable situations. Up the trees quick! cried Gandalf; and they ------=_NextPart_000_0001_01C683E2.8EC72060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D v ea u r H y om u e O x wn s er,

Your c q re j di n t doesn't matter to us!

If you O j VVN r a ea m l e d st q at n e and want I r MM i EDIAT d E c s as l h to s j pen m d ANY
way you like, or simply wish to L l OW r ER your monthly pa x yme f nt e s
=20 by a third or more, here are the d p ea e ls n we have T v OD w AY:

$ 4 s 90 , 0 h 00 a r s l e ow a z s 3 , 6 f 5 %
$ 3 e 70 , 00 b 0 a s s l p ow a t s 3 , 9 f 0 %
$ 25 a 0 , 00 t 0 a r s l p ow a d s 3 , 3 u 5 %
$ 2 v 00 , 0 o 00 a m s lo h w a u s 3 , 5 h 5 %

V r is k it o f ur web s e it s e

Ilsa Gruner , A j ppr x ova c l Ma n na y ge n r

What shall we do, what shall we do! = he cried. Escaping goblins to
be caught by wolves! he said, and it became a proverb, though we now
say =80=98out of the frying-pan into the fire in the same sort of
uncomfortable situations. Up the trees quick! cried Gandalf; and = they
------=_NextPart_000_0001_01C683E2.8EC72060-- From a.f@0727.com Wed May 31 04:39:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMEK-0005WY-Ft for eap-archive@ietf.org; Wed, 31 May 2006 04:39:04 -0400 Received: from n8.pro-internet.pl ([193.189.116.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlMEH-00038V-6R for eap-archive@ietf.org; Wed, 31 May 2006 04:39:04 -0400 Message-ID: <662161c80604{SYMBOL_LC}@mail.0727.com> Date: Wed, 31 May 2006 08:38:42 -0060 From: "Zelma Miranda" To: eap-archive@ietf.org Subject: re: Market Share Picks Watch special pr news release news MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 DATE: WEDNESDAY MAY 31ST, 2006 BioElectronics Corporation Symbol: BIEL Price: $.28 CAN BIEL HAVE YOU SPEEDING PAST OTHER TRADERS LIKE A ROAD RUNNER ON STEROIDS? RADAR BIEL FOR WEDNESDAY'S OPEN RIGHT NOW!! THE ALERT IS ON!!! RECENT NEWS HEADLINE: (GO READ ALL THE NEWS ON BIEL RIGHT NOW!) BioElectronics Corporation Announces New 510(k) Market Clearance Application Filed With FDA!! About BioElectronics Corporation (Source: News 5/18/2006) BioElectronics currently manufactures and sells ActiPatch(TM), a drug-free anti-inflammatory patch with an embedded battery operated microchip that delivers weeks of continuous pulsed therapy for less than a dollar a day. The unique ActiPatch delivery system, using patented technology, provides a cost-effective, patient friendly method to reduce soft tissue pain and swelling. GO READ ALL THE NEWS ON THIS ONE!! DO YOUR DUE DILIGENCE!! RADAR IT FOR WEDENESDAY'S OPEN NOW! ______________ I nformation within this report cont ains forward looking stat ements withinthe meaning of Sec tion 27A of the Secu rities Act of 1933 and Secti on 21B ofhe SEC Act of 1934. Statem ents that involve discussions with respect toproj ections of future events are not stat ements of historical fact and may be forward looking statements. Don't rely on them to make a decision. Past perform ance is never indicative of future results. We received four hundred thousand free trading shares in the past for our services. All those shares have been sold. We have received an add itional one million free tr ading shares now. We intend to sell all milli on shares now, which could cause the stock to go down, resulting in losses for you. The four hundred thousand shares and one mil lion shares were received from two different third parties, not officers, directors or affiliate shareholders. This company has: an accumul ated deficit, a negative net worth, a reliance on loans from officersdir ectors and affiliates to pay expenses, and a nominal cash position. These factors raise substantial doubt about itsability to continue as a going concern. The company and its president are a defendant in a lawsuit. The publicly available float of stock is currently increasing. URGENT: Read the company's SEC filing before you invest. This report shall not beconstrued as any kind of investment advice or solicitation. WARNING: You can lose all your money by investing in thisstock. From velez@biogen.com Wed May 31 05:04:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMdH-0006KM-VM for eap-archive@ietf.org; Wed, 31 May 2006 05:04:51 -0400 Received: from [194.165.146.133] (helo=biogen.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlMdG-0005I9-AO for eap-archive@ietf.org; Wed, 31 May 2006 05:04:51 -0400 Message-ID: <000001c68490$c013adb0$daa9a8c0@fuh6> Reply-To: "Melia Velez" From: "Melia Velez" To: eap-archive@ietf.org Subject: Re: refnance it Date: Wed, 31 May 2006 02:01:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68456.13B4D5B0" 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.3 (++++) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68456.13B4D5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D k ea r r H s om g e O c wn d er, Your c m re f di z t doesn't matter to us! If you OV x VN r r ea h l e u st n at v e and want I e MME h DIA b TE c n as b h to s k pen a d ANY way you like, or simply wish to L v OW v ER your monthly pa e yme t nt s s by a third or more, here are the d m ea l ls u we have T m ODA i Y: $ 49 h 0 , 00 j 0 a e s lo v w a p s 3 , 6 i 5 % $ 3 t 70 , 0 z 00 a l s lo d w a m s 3 , 9 h 0 % $ 2 e 50 , 00 b 0 a i s lo w w a p s 3 , 3 c 5 % $ 20 s 0 , 00 l 0 a q s lo q w a j s 3 , 5 b 5 % V x is m it ou i r web s x it d e =20 Melia Velez , Ap d pr j ova e l Ma m na r ge r r Pour the milk on the pantry floor! Leave the bones on the bedroom mat! Splash the wine on every door! Dump the crocks in a boiling bawl; ------=_NextPart_000_0001_01C68456.13B4D5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D k ea r r H s om g e O c wn d er,

Your c m re f di z t doesn't matter to us!

If you OV x VN r r ea h l e u st n at v e and want I e MME h DIA b TE c n as b h to s k pen a d ANY
way you like, or simply wish to L v OW v ER your monthly pa e yme t nt s s
=20 by a third or more, here are the d m ea l ls u we have T m ODA i Y:

$ 49 h 0 , 00 j 0 a e s lo v w a p s 3 , 6 i 5 %
$ 3 t 70 , 0 z 00 a l s lo d w a m s 3 , 9 h 0 %
$ 2 e 50 , 00 b 0 a i s lo w w a p s 3 , 3 c 5 %
$ 20 s 0 , 00 l 0 a q s lo q w a j s 3 , 5 b 5 %

V x is m it ou i r web s x it d e

Melia Velez , Ap d pr j ova e l Ma m na r ge r r

Pour the milk on the pantry = floor!
Leave the bones on the bedroom mat!
Splash the wine on every door!
Dump the crocks in a boiling bawl;
------=_NextPart_000_0001_01C68456.13B4D5B0-- From bernard.mason@netsijang.com Wed May 31 15:47:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWf5-0006uV-6J for eap-archive@ietf.org; Wed, 31 May 2006 15:47:23 -0400 Received: from aclermont-ferrand-251-1-49-31.w81-251.abo.wanadoo.fr ([81.251.150.31] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlWez-0008KN-Nk for eap-archive@ietf.org; Wed, 31 May 2006 15:47:21 -0400 Message-ID: <000001c684e9$a65d0c00$0100007f@localhost> From: "Riley Ramirez" To: Subject: We help you to save on the Med$! Date: Wed, 31 May 2006 21:46:56 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C684E9.A65D0C00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C684E9.A65D0C00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C684E9.A65D0C00" ------=_NextPart_001_000E_01C684E9.A65D0C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Langdon looked again at the fax an ancient myth confirmed in black and white. The implications were frightening. He gazed absently through the bay window. The first hint of dawn was sifting through the birch trees in his backyard, but the view looked somehow different this morning. As an odd combination of fear and exhilaration settled over him, Langdon knew he had no choice The man led Langdon the length of the hangar. They rounded the corner onto the runway. ------=_NextPart_001_000E_01C684E9.A65D0C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_000E_01C684E9.A65D0C00-- ------=_NextPart_000_0001_01C684E9.A65D0C00 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA9gG7AwEiAAIRAQMRAf/EALkAAAIDAQEBAAAAAAAAAAAA AAADAQQFAgYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwEEBQgECwUFBQkAAAECABEDBBIh MRMFUZGS0lNBYbEichQ0BnGBMlKhwdFCYrIjM9PUFYJzkyQ24aLCRDXw8UNjJeKDs8NUdKQWRhEA AgIABAQDBgUDAwUBAAAAAAERAiExEgNBUWFxgZEi8MHxMhMEodFCUmJyghSxI0PhM1NEBRX/2gAM AwEAAhEDEQA/APaO5UhVGp23Ddu8p80jhXTta8wPQoUD/eDQXbkv5kWn1lq+iOlyIJ4L+O/Unchw X8d+pO5HQjU+nkhAngv479SdyHBfx36k7kdIjU+nkhArgv479SdyHBfx36k7kbCNT6eSECuC/jv1 J3IcF/HfqTuRsI1Pp5IQK4L+O/UnchwX8d+pO5GwjU+nkhArgv479SdyHBfx36k7kbCNT6eSECuC /jv1J3IcF/HfqTuRsI1Pp5IQK4L+O/UnchwX8d+pO5GwjU+nkhArgv479SdyHBfx36k7kbCNT6eS ECuDc8d+pO5Dg3PHfqTuRsI1Pp5IQK4Nzx36k7kODc8d+pO5GyI1Pp5IQL4Nzx36k7kjhXPHfqTu RsI1Pp5IQK0Xl2rcL+ZwKH61AnaOHB2UINGHQZ1FL8RcHkKofrq4/FGafQE6nuEi2Qqg0LnbtG8K IcF/HfqTuScX4e0elQT9JFTGytw4UYATwX8d+pO5Dgv479SdyOhJqfTyQgTwX8d+pO5Dgv479Sdy OkRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBfx36k7kOC/jv1J3I2Ean08kIFcF/HfqTuQ4L+O /UncjYRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBfx36k7kOC/jv1J3I2Ean08kIFcF/HfqTuQ 4L+O/UncjYRqfTyQgVwX8d+pO5Dgv479SdyNhGp9PJCBXBueO/Unchwbnjv1J3I2Ean08kIFcG54 79SdyHBueO/UncjZEan08kIF8G5479SdyRwrnjv1J3I2Ean08kIFFrlra512/K1KFfOabKRshgCC DuOwyhxX6f8AlNf9rpjhI6FxPibnsJ6bkbFJ8Tc9hPS8bDz8EEZHP+YZmAtl8YqEcsr6hXaKEfjl jPz2scqObaprZUZK7RVyPyxPzJY4vK3Yb7TK469J/A0yc7K1/LmGlfWZ9J+i3qH5J3pRWrt4fr02 68TnazTtj+mUXxzTOHIjnsV4xf1PV2adQTd1zQ5Rk3cvl9rIvUNx9WqgoNjMv4pn8zs+7/La2fKi 26/TUE/hjeU3vd/l1b/hpdYfSHeklq1dG6pY7sLsE2rQ3+iTOyvmLPTKvcLT7vbuaB6u0ip8vn0z 0ly/bt2GyCa20UuSOgCs8faxS3IsjJO8X0NfMo0//Mm0L5vfLBeu0WSh/snR+Kb3duvp0qIvoZKW eM8a6kVLPMPmDmRe9habdlDTTRd+/TVwamXuR82vZxuWMkAX7W2oFKitDUdIMr8jy7eFyS5k3QSi XTULQn1tC+UjpjuUZfKcnNuHDsPayGRmd23EFlr+e3lMm4lF0qYVcK1Vy5irc1erG2afuKh5rzm/ zG/iYmhjadwoIA9VG07yYyzzrmWLnJicytqBcIGpdhAY0DVBIIlCzl3MPnmXdt2WyG13V0LUGhff sVp0Mgc053ZfLAxghVVtNUk6TqC7hvJ8s6Oi40rp0TK+aTKs/wBz1aojgei5plNh4N7IX7agBK/e Y6R6Zmcl5zmZWacfLK0a3qSgpt2MP92HzXf04tmwN9xyx+hB+VpUyLf9O5zgtuHDtKx+rhN+Cc9u lXt4r1X1OvgatZ68HhWJ8T1JIG0wrM7O4QzLJy9uLpYCv2OJX876o6xaGIl57bBsYjiWkBqFoPWo egzxK/qajCueOOUzHI6asWuRaqK08vRK+bfuWbacKge7cW2pIqBqNK0laxgWr+Gt64K5N1eJxq+s GYVWh8lIq+Ey8TBv3Rqd7ltGO0VBNGmbbltLwhuupY8COzjwkvm+6ZFnHajF0Ys+7atNw88sTNv4 mOeY46lPVNttlT+ZpC+WaM3R2bsnwtCxngaU4zzJkQhNlCEIQAhIhWAEWnxNz2E9LzuLT4i57Cel 5Vk+3vJyOsX4az7C+gRsVi/DWfYX0CNi2b7hZIxObc2zEzU5dy8DjNTUxAJq20AV2btsVi815ni8 xTB5lR+KQAwABBbYpGmg3xSEn5u29J/BZM3r2FiX7q37tpXupTS53ihqPwzvZ0oq1dU9W3M8ZZzW qzbTytEcIMzmHNMvH5xj4dsrwbpthgRU+u2k7Ze5tmNhYFy+lOIKBK7dpNJjc3/1Hh+1Z/Xjvmu8 eFj4y7TcYuR7I0j9aFRN7SjNSxqaV3OTwOuSc4y8vLbHyyu23rSgp0H0Gd8/5pl4D2RjlQLgYtqF d1JSuoOXfMGL5FZLaeahXg/inXzd+8xvZf0rNKlXu0aS03rMcDOqypbHGrPSzF5hzTLx+cY+HbK8 G6bYYEVPrtpO2bU81zf/AFHh+1Z/XnLZSdnKn0s6bjaSjmi3znm2XZyreBggca5SrEA7WNFArs65 XTmfN+X5lqzzPTct3iBqAUUBNKgoBu88fz3lWReupn4R/b2gKqNjHSahl84iMHm+Lm3Ux+a2V94U 6UuMuzVXcQfsmdaqr201Wt1Hr/cmYbepy3XH0/tPREgCp2CEzs3gjOt++D/LG2Qmr7HErt1f2emN tW/c7F90YNYANyyu06QFqRXorPCtz1NRhXPHHvB01YvoW6itPL0Svm37tpLa2iA964tsMRULqrtp 9UrJgWrmELrVOU6cTjV9cORqFD5ovIW3lWMC/cWr3LltXNSNhDVHXM23LaXhDaTWPAjs4ygvLfcZ a4rUb9lxC+6pDBd0sTNOJj/1VRo2CzrG0/aVgoO/omlN7bs9U8LQjVZxnmEISJspMiEIAQhCAEJE isAmszf5KaNZnfyU1wfdE4l9PibnsJ6XjYpPibnsJ6XjZHn4IIVl2feMW9Y8RGUfSRsni8SuS2Hh NuF9iR+i+iv6pnuYlMLDS4LqY9tbgNQ4RQ1T5wJ02t3Qmomcu5m9NTT8yj8x/wDSbv0p+sJl3b/C +VLCA7bzFPqFx2Ponpblq1eQpdRbiHerAMNnmM4bDw2traaxbNtKlEKLpWu+gpsim4q1rVqdN9Yt Rttp510nnbHy7au8sGUbji+1s3FQU01oSvknXJS2TybNw12uoJQe0uwdaz0qqqqEUAKBQKBQADyU i7OLjWCTYspaLbyiha9Qmnvtpp4+pWr0gi20mo5QzzvIub4WHh3MfLJVg5ZRpLaqgbNnl2eWR8uM X5vkXCuniW3cL0BnRh6ZvXOW4F25xbmPbZ95YqNp8/TGpj46XDdS0i3GFC4UBiOgnf5Itu0avFXO 4scSKlvTLUVPPco/1Hme1e/Xhz6i88xH3Clsk/RcaehTGxrdw3ksot1q6riqAxrtNSBWF3Fxb5DX rKXWGwF1DED6xH1lrVofyaS/TemJ/VJ5znQ9+55ZwwSFUKjU8mr12PZMRzrk1vltq1esu7Bm0sWp sNKilAOieq91xuNx+CnG38TSNe6n2qVk3bNm+ui9bW4ta6XAYV6aGK77roS+WqhrmR7U6pzbwK1j NtZC2LdxQfeLIuAmmlid6U6YqxaVb2ZiY5/Y6BRa1CO4IIEuNi4r2hZa0nDX7KaQAv0U3Tq1ZtWV 0WkCL0KKTyWo7XnCE3HOH+k3DwkrYmTaTlqXWYAWrYVwd4ZBSn07JX4bWsDARthF60SPpNfxy82H itd4zWUNytdRA39MayI9NahtJDCorQjcRJ9OzUNrCulfn+A0vjygqXyBzLGJNPUub/7MuTi7Ys3g BdRX0mo1CtDO5uqadv5OfwKln1CEisKzRQhWRWRWATWRWEisoJnFv4i57Cel5NZza+IuewnpeVZP t7ycjvF+Gs+wvoEbFYvw1n2F9AjZLZvuFkjzGc45f8yLl3QRZajV37GThsfqM6vcxuZ/O8dMC9c9 3GgOFLIrBSWcldnk2bZ6C/jY+Qui/bW4o3BgDT6Jzj4WJi193tLbJ3lRtP1zt9WsJurdq00LkY0O XD9Ltq6mDzf/AFHh+1Z/Xi+bJ/UOf28OpCqFtkjyChuNTrnpHxsZ7gvPaRrq003CoLCm0UJFdkBi 4y3eOLKC8dvECjXt2fapWFvJRhjWjqu/MPbbnHO0nlec8oTlgs3bDs2piCWpsIoVpQR3zNdF5MG8 N1y2XH9rSZ6W7Ys31C3ra3VBqA6hhXp2zh8PDdVV7FtlQURWRSFHQKjZLXfxo7Jt0nHuR7XzJYK0 fgUx8xcqJAF01Oweo35Jmc3/ANR4ftWf15ujl3LwajFs1H/lr+SMfGxrlwXnso11aabjKCwptFCR WYrelXNVb5WsXzNOtmobWaeBhc4ysrC5vYutcuDEbSSisQp0n1xprSU+d5GJzHLsf0/9peb1XYKV 1EkaRtA3T1V6xZvpw7yLcQ/msKiLx8DCxm1WLCW2+8Bt65qm9Wqq9L1VUYZPuS223KnBuepDXrRv jCvKCWTUC1KPtoRTplWzaH+ew7BrZCUQVqFd1OpRL97HsX1C3kVwN2oVpJtWrVlNFpAi9Cik8jo3 aXEKceMNZGobZVtZVpeWLeLABbYBH6QFNP01iGttaxOXI2xhdt1HQSrGXTh4hu8Y2U4la6qCten6 Y1kR6alDaTqWorQjyiT6dmsWsK6VH+o0vj2KjEDmy1NK45Ar7YlycXLFm6Va4isyGqkipB807m6p p26uSpRIQhCaKEJFYVgBCsisiUE1kQkVgEzP/kperKP8lLw8UTiX0+JuewnpeNil+JuewnpeNkef ggghCEhSDQAsSABvJIA/DOeLa8RO0v5ZR587Jy1ipodaivXPLca74jdc9Gz9v9SurVGMHHc3tFoi T2/FteInaX8sniWvETtD8s8JdvXeE3rtu6Y67eu8RvXbrnT/AA/5fgY/yf4ntOLa8RO0v5Z19G0e QjbPDca799uuer5KzNyywWNTRtp9ppz3vt/p1TmZcG9ve1tqIwkvyIQnnOwQhEZeSMaybhFTWijz mVJtpLiG4HVAkzFe7l5HCuMQAz0tUoPWljFzb4v+75G0k6a7iD9U6PZaUynGaMK6k0oSKytm5fu1 saRV3+zXcKeWc61dmks2abhSWYVmR7xzApx6to+9QU6pcwstshWD/bTbUeUTdtq1VMpxnBFdNwWq wkSlmZzW34Nn7Q+02/b0CStXZwitpKWXdsisz2ucxs6Wap1eSgb0S37yBj8e4pUjYVOzbK9tqIat OGBFZPp3G0Mg1EoJfzslibRoB5BQAdcbi5OQz8O+pKnZqpShle00njXDNTiRWT5lmRZ/f3PYT0vJ Ow0kWf39z2E9LzHB9vea4o7xfhrPsL6BGxWL8NZ9hfQI2S2b7hZIIQhIUTdysey2m44VqVoZx/UM PxR+H8k878wsf6iwqaBV9EzK+ed67SaTl4n0dr7Cl9ut3ay1Vk9r/UMOuniitK027of1DD8Ufhni kP7U7f8Aw29Kwr55formzf8A+dT99j26ZmLcYIlwFjuEfPE8vb/P423/AMVP1hPazluUVWkjyfdf brZtVJu2pTiTIhCYPMEITPzc+5bujHsga9lSdu07gJqtXZwiNpKWaFR1QmKHzbT3rgPrIRxSKHfu mjhZRyLRLCjqaNT0zV9p1UyrLoRWnDIsyITNys+8bxs4+yh01AqSZmlHZwiuyWZpSKzKOXnY7gXa 9OlqbfrE0kcXLa3F3OK0lvtusPBp8URWTO4bZxdLiy5t/bAOmgqazO945n91+x/7Mtdt2ydV3DtH M09siZa52ZrCFjqrQrpFfRLWdmvZbhWtjUqW3yvasmlg5JrUTyLVD0SJnvd5hZUXXJCnpofwS3j3 /eLPEIoymjdElttpTKaywKrJuMhkpfyUuSn/ACUnDxRS+vxNz2E9LxsUvxNz2E9Lxsy8/BBBCEiQ pl/Mhpytj/5if8U8jxJ6v5pbTygncOKnoaeL4q9I659D7Vxtf3M8f3Cm/gPuP+zb6I27c/aN9MpX Lq6G9YbumdvdXWfWHXPRqUnKGP4k9lyI15TjnzN+u08LxV+8Oue4+XzXk+MekMetmnm+8c0r/Udv t1Fn/SaUJFZFZ4D1k1iM3G96sG2DRgdSnyVEdWVeYYz5WMUtGlxTqXbSvmmqYWWOnHMjyfEyntZm KyBwVo1UptGrzS7h80Z7i2b4FWNAw2bfOJncfLscG1etN+yua0DAgk1+zWWMbHysrM94u2zaTUHa oK7vIKz13SdXr05OLI5JucJ7G1IYKaatJPk1Q1VJMz+b4d7ICX7A1Og0sg3037J5aJOyTemeJ1bh ZSdcyOUFItj/AC2kaiKf9855S9tluIBS6RUnpHmmd75zI2PdOG1KaaaDqp0TQ5VhX7KvevDS7LpV PLTftney07TrZ1zw08e5zTmyanxNJQQdsw7lxhluRtcXDQecNO+Xe/8AvlvjLeFv1tRcNp+yd9Z1 zLCyFvnJxlLqx1ELtKsPNG2lS7q2nqrnw7CzdlKWTO778wx9Ny45oxpsNRXopOsnKORhI52EPpen TQyneyuYZmm01o+qa0VSNu6prNC3gEYRx3IF5zr+g9Er01VXbSrav08gpcpTEcRGIMu5bZbB0oDU ndU/TGYubeW8LV46gTpNd4O6V7V3PwiycI0PSCRXpBE7w8a/dvi9dUqoOtmYUqd8tlWLO2jTGDWZ FOETPE0mFGIkWP39z2E9LwLamJ8h3Qsfv7nsp6Xnm4PsdeKGYvw1n2F9AjYrF+Gs+wvoEbM2zfcL JBCRCQp5D5kenNHH6C+iZXEl75rZrfNmLBgGRSpoaHZTYZjcZfP1Geit0qpTwPv/AGzX0dvFfJUt rc/aN/dt6VhxJUW8NZ3/AGCNx6RDjDz9RlV1zR1UY4o1OWvXmOKP/OT9YT3c+ecnY3Oa4iopYi6h IAOwKak9Qn0Kctxy1B8r/wClH1KR+z3kwkVkVnM8BMzOY8vvXbvHsesSBqWtDUbKiaVZkc0xMpcj 3rHDOpoSF2lWHmnXZwvg1XDjk+hm+WUiLWVlY1xzt1VAuBhXaN1ZrYmYuXbJppdPtL9Mxly8m4cl Fslnv01gAnTSvkmjyzGu49p3vDS9ygC+UAdPXOu8q6W2krYRHExRucMjQFfJOaJUlQuryUpWsAaG YeRi5mDk8WypZASUdRq2HyGcduis2tWl8OpuzjhJ1ltlcVfewQabN27zU2TXsFLli21rYmmgHRTZ MN25jzC6tbR2bB6pVR9Zl/Ns5FjBs2sfWzqfWNsHygk7vPO24k1Srda2nJZIxVxLxaNA6htlfNyW x8etf2lzYvm6TOOW8f3V+OHD69muoNKL96VObrk3MlRbtO6IoAKqSKnad050ovqaW1CNNvTK4j+W WaIchtrMdNuv4TF80e0bwArxVADnydIl2wptY9hCKEKCwPTvMo8yw75vHIsqXR6VA2kGlN01Sye6 23GcEaikIjI9+4C8evD2dH1VpLeC1tsUrbqGU1cHplG5lZ2SgsNbJ6aKamnTLuHYbGstxNly7T1e gD/vl3MNuHpT1YKpK/NhMRxHyp/JS1Kv8lOPDxNl9fibnsJ6XjIpfibnsJ6XjZl5+CKghCEhRGao fGa2wDI5AZSKgjf5Zle4YfgW+wv5Jr5Arbp5xKmidKPAxZYlI4GHQ/sLfYX8kk4GJX9xb7C/klwp sgU2zcvmZjoUvcMTwLfYX8k1sbZYQbgooANmwbBKuiWrOy0o/wC2+Yu5RquYysKyKyKzBomsKyKy KwDm7atXTba6CzWm1oQfKJ0SWO07OiEiX3AmFT5DSRUbvLIrtp5YB1rfp/BI21rU16ZFZVy+YWMW gerOfzBvp0zNrVqtVmqrqRuMWy3rf70gEjcaStk5qWAgKs73fsIu8xY5pj8BrxDDS2koR62qR7u2 m07JNKWTUuZdL3OmRTyk7emVsbNTIdrZRrd1NpRuiWCQN81W1bKauUVOTriXBuPXOSWb7RqOiRUV p5YVG7yyiSZ1j/v7nsp6XnFZ1jfvrnsp6Xl4Pt7xxQ3F+Gs+wvoEZFYvw1n2F9AjZm2b7lWSCEIS FKeStbpPmEVoHRLV1avWcaJo6q2CEaNu7yQ0eaO0bfqhoguoVbWlxT5xL1ZWVaMD54+sjOd3LJrC RWRWDBNYVINRIrIgHKWrVp7ly0CLl4gufo/7515yamFZFZe4JhVhuMisisAks53t1QBKigNJFQd2 2cs6qpcmiqCSfMIwB2Sx+0aw1v5Gmfb5tad0BtuqXDpS4RsJhc5rZR2UI7Ih0vcA2Azl9faidSgz rrzL1SdpNTAEj7JpIDBgGBqCKgyNQ6d2+dSnZuXPvfgnPlqdp6TIJA2ndCsoJlb+Slisr/yUcPEF 5fibnsJ6XjYofEv50T8BeMrMvPwRUEKyKyKwUh9q0itMaZGyVMjQspArGbJEskgXpna7FAhshI2C awrIrIrBSawrIrIrAJrCsisisAoWbaW8TFuooFzVbqw3kOdJBP1ybYdyLoQB+Ma3SRXSHKaen7Oy k7xcYixZ4jN6gDcM0oG6qxvu6666jo1a+Hs06undXzzz1221VxHpWGGfM5pYI5w0QcW4B67XLgLe Wms7JW52B7sjUGrWBXy0o0vW7a2wQtSCzMa9LHUYvKxreVbFu4SADq9Wla0I8oPTN3229l0SUuv4 la9MFPM+Ow/q9Mz7n7q7/fD0NNrIxLd8JUsr2/sOpoRF/wBNxuAbJ1EMdRcn1qzhu/bblrWiIctY 9IgxajbYrH/6vkex3JYa1buZj8RQwFpaA7RtZ4Y+Hbx2ZwzPcfYXc1NI3hgXTd26ioWnkoCT+Odt vaarFksdy12s8zaWGPOSpZRFtYdxQA7EBm8pBRq1MjhobFm8R+1a6jFvKavLS2EVLSAmlkgr9QK7 euVzaZmVAHULcD6TTQKNqrqp5eiZe26pKJlRHWFiSILs7xv31z2U9LxcZi/vbh/RT0vPVwfb3m+K GY3w1n2F9AjYnG+GteZFHUIysxbN9yrJE1kVhWRBSGFTIpJrIrAkikik6rIrKJIptnVZEisEkmEi sisAmsKyKyKwCawrIrIrKQRmKrnHVhVTdFR0+q8Re/Zm9atr6jGz6g2D120sB0VpH5Vtrhshailw Esu8UVtvXJ93Uq4dizXCCzmgNV+zSmzZOFqO1rQvH+2IMtS37cCtdtsLd1Sgt22a1RFO46wCfV3S 4UtLaNsgLaoQQNgp5Yv3ZSrB2ZmcqWbYD6hqBsFIy4guW2tnYHBU037RSarRqXGdYU924CRl49r3 y+rIvDw7B9Rek1r+GVz8Llf3q+lppW+XJaoEvXlUGukPQdQEh+WWHdm1OqudTWwfVJnmf2+46r0r V6tWP7lGHRGNDjLE6u/9MP8Ac/8ADA49gZaLoXTw2JFNhIK0J6d8fctLctNZOxGGnZ0QNtTdF3bq ClaeShIP4p6Xty1KThUXk8Tce4q2QH4FthW2DeOk7vUbSvUDG4iqguqooBcag+oSLloW1TRr9Vmb WtCy6qk7KbRtnWLbZEbVWruW9b7W3ppM0q1ZJrFLP+1IiWI+I/ko6K0t0f8AJ0+uejh4my9cRiQ6 fbWoodxB8k5N6mxkcHo0lvwqCIx3CAbCSdiqN5M505J26kTzaS34dSzKyxL2OOOv3X/w37sjjL91 /wDDfuxmjJ8ROwf4kNGT4idg/wASX0+3wGIvjL91/wDDfuyOMv3X/wAN+7G6MnxE7B/iQ0ZPiJ2D /Ej0+3wGIrij7r/4b92RxR91/wDDfux2jJ8ROwf4kNGT4idg/wASPT7fAmInij7r/wCG/dkcUfdf sP3Y/Rk+InYP8SGjJ8ROwf4ken2+AxEcQfdfsP3ZHE/RfsP3ZY0ZPiJ2D/EhoyfETsH+JE19vgMS vxP0X7D92HE/RfsP3ZY0ZPiJ2D34aMnxE7B78TX2+AhlbifoP2H7sNf6D9h+7LOjJ8ROwe/DRk+I nYPfia+3wEMra/0H7D92Rr/QfsP3Za0ZPiJ2D34aMnxE7B78TX2+AhlXWfuP2H7sNZ+4/Yfuy1oy fETsHvw05PiJ2D35Zr7fAQyrrP3H7D92Go/cfsP3Za05PiJ2D34acnxE7B78Svb4CGVdR+4/Yfuy NR+4/Yfuy3pyfETsHvw05PiJ2D34le3wEMqaj9x+w35Iaj9x+w3dlvTk+InYPfkacnxE7B78TX2+ AhldQ7Gio1fOCo/3hLVq3w1NdrMasZz/AJhdp03B0AFT9VS07Rw66h/tB6JmzwwyKhdGtE6V1WyS aDetfN5RI46/df8Aw37s7LuzFbQBI+0x+yPymGjJ8ROwe/GHEdjjjr91/wDDfuyOMv3X/wAN+7Ga MnxE7B/iQ0ZPiJ2D/El9Pt8BiK4y/df/AA37sOKPuv8A4b92N0ZPiJ2D/EhoyfETsH+JHp9vgMRP FH3X/wAN+7Dij7r/AOG/djtGT4idg/xIaMnxE7B/iR6fb4ExE8UfdfsP3ZHEH3X7D92P0ZPiJ2D/ ABIaMnxE7B/iR6fb4DERxP0X7D92RxP0X7D92WNGT4idg/xIaMnxE7B78TX2+AxK/E/RfsP3YcT9 F+w/dljRk+InYPfhoyfETsHvxNfb4CGVtf6D9h+7DX+g/YfuyzoyfETsHvw0ZPiJ2D34mvt8BDK2 v9B+w/dka/0H7D92WtGT4idg9+GjJ8ROwe/E19vgIZV1n7j9h+7DUfuP2G7staMnxE7B78NOT4id g9+Wa+3wEMq6j9x+w/dhqP3H7D92WtOT4idg9+GnJ8ROwe/Er2+AhlXUfuP2H7sjUfuP2H7st6cn xE7B78NOT4idg9+JXt8BDKmo/cfsN+SGo/cfsP3Zb05PiJ2D35GnJ8ROwe/E19vgIYlLT3NhBVDv J2H6hLWlegbqfVOA7oaXQKHYHXdXzg7oyZnFcixgLXbktX8xFp/aLV/VjolPibnsJ6bkbI/cgiYT P5xzF+XYy30QOWcJRjTeGPk+iWcO+cnFtX2AU3UDEDcKiXS9KtwbgSpjiPhMrnXN7nLODw7a3OLq rqJFNOno+mV05vzpiP8A046TTbRtxmltWdVbCHzcEd6pxjK6G5CZL84u2+cDlz214bEAXKmvrLUf h2TvnXN25aLOhBca7q2EkUC06Ppk+naaqMbqUNdYb/bgzThMfmvOb/L1x/2Ss95NTgkjSRTYOuM5 jzHmOLfZMfEN6yqhuJtp590Las4y9UxjyGtY9DUhPO2PmHmWSGOPhC6F+1p1GlZY5lzvJwsizYSw He7bV6EmupiV0/gmvo3nThPcn1KxPDsbUJgP8xZ2MynNwTbttsB2qfq1DbNy1dS9aS9bNUuKGU+Y iszbbtWG1g+KxLWyeXA7hPPWvme4+Uls2VFh7mgXKmumtK9RnoYvt2pGpRIrZWy4BCEJg0EIQgBC EiATIhCAEIQgBFJsv3FG4hG+s6l/4YyLT4m57Cel5Vk+xOR1jfD2z5WUMfpb1j6Y2KxfhrPsL6BG RbN9wskTCZGHzm7e5pc5fdtqmguFYE1JQ+fpEOZ85u4ebZxLNtbjXQpqSdhZio3TX0r6tMYtavAm usT1g15Eys3nF3G5pZwVtqy3SgLkmo1tplzmOZ7lh3MmgYpTSp8pJAk0W9OHz5F1LH+OZZhMjlHO 7nMMh7F22tshNa0JNdo6fpljm3NE5bYV9Ou5cNLaVoNm8n6JXt2VtEepkV66dU4F+E843P8Am1hU vZWGq2HOw0ZSa7d5J9E1cvmS2uVnmNgB1orKrbPtMF206KyvaumsvU4UPiFernpiXoTz1vn/ADS5 a46YOu0KkuuojZv2zS5Tza3zK25CG3ct01pWu/cQdnRFtq9U21gs4chXq3CL8Jk8450/L71uzati 4zKXapIoPq+gy5yzN9+w0ySArNUMo8hBpI9uyqrtYMKybdeKLUIQmDQQhCAEIQgBCEiATIhCAEIQ gEOodSp3MCD9cpe8XOn/AJXi/wBqXZm/yUvDxJxL6fE3PYT0vGxSfE3PYT0vGw8/BBGL81/9Ot/3 y/qvL/Kf+m4v90volD5r/wCnW/75f1XjuW8y5fb5fj27mRbV1tqGUsAQQJ2ab2awp9bMSluOf2oo fN//ACn/ALz/AIJYx/mO272rPu1wFiqatlNuysq/Njq6YToQyMLhVhuIPDIM2LfNOXaEX3m3WgFN Q3zTj6O3NHf5vDEz/wAlotpyMj5kU4/McTNHm67bavxw52Pe+dYeKNq0Wv0M1W/3RLfzRZ4nLhdA 22XBJ8zer6SJR5OTm86GQ23hWVP9oItv0kzVH/tq/wD463X5EsvU6/udWdfN37zG9l/Ss9Dk/D3f Yb0Tzvzd+8xvZf0rPQ5Pw932G9E53/7ez/d/qbr8+54GH8o/u8r2k9DRHzHcW1znGutUqiW2NN9F uOY/5S/d5PtJ6Giufbee4YP3bX/xGnT/ANi39PuMf8Ve/vFc45zY5patY2OjJ64YvdKqK0K/eI8s 2rv/AKfyRgGqbVnSGG4sRpBH1mUvmqzaGFauBAHF0LqAoaFWNPwSvzTI0/L+FartuhK+yi/lpIkr V21VRXXlmWXV3nF6czOfFK8ls5XlN9wD5ioHpSexxbwv41q+P/ERW6xWeZv8lzLfKhebJZrSoLvu 23Stdp/Opsr0TX+W7/F5WinfaZkP6w/A0b8WpqT1abteY25Voaiar8DVhCRPKdiZEIQAhCEAIQkV gBCsiFYAVi0+Iuewnpedzi38Rc9hPS80sn295OR1i/DWfYX0CNisX4az7C+gRsls33CyR5rMHunz PZu7lvFD5vXHCMl196+agN62KHsLq/WjPmq2U91y1322K18/2l9BhyAcfmefm+TUQv0Oxb0LPUn/ ALf1OW26fjBxj16f56hXN/8AUeH7Vn9eP+a7+nFs4433XLH6EH5WiOb/AOo8P2rP68452Hzud2sO 22kqFSv3SfXJ6oqsdpvKtHZhvC652gFt/wBO+YMZNyultD56pwv1hO/mk1ysRD9mh2fSw/JKnOMD MwHsZF7JbJYk6XapK6KMB6xPTLXzMdZwstRW26kj/dYemaUO+1adU1dZ7Efy3URinHc1Ob5PKtHu WfdNvWA4CqxNAdhqFYeSVc4Yq/LLjDcvjimhmrU/tRXeB5Ynn+XyzIwhctMl3JfSEYULqoOo18ok f/yH/bx5zrWK7b9S/wB1YPLuadpdlh8jxQnlnP8AGweXDHa273l1EUA0Ekkjbqr+CWflXG0W72SW U66KFBBIA2+tTdLPILNq7ydFuIrhi4IIB/OMzvla6LXvjsaKiK5+hdU1eHXeVVD1LVxnElZT25c4 YdCbif1H5hv296W0dKfQhT9ZpY+U71bF/HO9HDge0Kf8MzuUYOZzC5fyLOQ2M4PrOtasXJYj1SOi P5KHweeXMS42osGQt0keuD1CW6Wi1E5dKVw/pJVvVW0fNZ49z1MIQnjPQEISIBMiEIAQhCAEJEIA QrIrIrKCazO/kpoTP/kpeD7onEvp8Tc9hPS8bFJ8Tc9hPS8bI8/BBCMvDxs22LWSnEQHUBUrtAI/ NI6ZU/8A17k//wBP/vv3ppQlV7JQrWXZh1q80mVL/KsDIt2rV61qSwum0NTDSKAeRhX7I3xI+X+U AgjH2jaPXfvTRhCvdYK1l4jTXkvIXfsWsi01m8uu2+xl2ivl8kTictwsIs2Lb4ZcAMdTNWntEy1C TU4iXD4CFMxiVcvl2FmlTlW+IUqF9ZlpXf8AZIlhlV1KsKqwII8xnUIlwlLwyELzK2JgYmEGGLb4 YehbazVpu+0TIv8ALsLJvpk3req9boEbUwppOobAQN5lqRGq0zLnnIhREKBWViY+Za4WQmu3UNSp G0eyRK9zk/Lrtu1auWtVuyCLY1v6oY1P50uwhWssm12YaTzSOXtW7lprLittlKMv6JFKRWJg4uEr JjJw1c1Yambb/aJj4RLiJcPgIWYQhCQoQkVhWAEKyIVgBWFZEisoJkVhIghNZxa+IuewnpeTIs/v 7nsJ6Xl4Pt7xyO8X4az7C+gRsVi/DWfYX0CNktm+4WSE5WJj5lrg5Ca7dQ1KkbR51IkYmDi4SMmM nDVjVhUtU7vziY+SFJjU4iXHLgIUzGJVvcuwr+SmVdt6r9vSUfUwppNRsBpvkLy3CXL99Fv/ADJJ PE1MdpGndWm6W9B80g7PLLqtlLyjPgIryXMRl4WLmoLeSnEVTqAqV27vzSJD4OJcxlxHthrCgBUJ JpTYKGtZZCkydB80k2wUvDIQuSxMu1yDldosRaLagV9ZiaBthpLP9Pw/c/ceH/lvD1N97XvrXf55 a0GBUiV3u87W55hVqskhONjWMW0LNhdFtakLUnft3sTK9vlHL7XF4drTx1KXfXf1lbePtS7Ik1Wx xeOeIhclgIxMLFwkNvGThqx1EVLbd35xM5bluE2WM02/8wCDr1MNoGkbK03SzCNVpbly88RCyhYB CEJChCEIAQkQrACFZFZEoJrIrCRWATIrCRBArKP8lLspfyUvDxQ4l9fibnsJ6XjYpfibnsJ6XjZH n4IIIQhIUJxdupaQ3Lh0qN5ncyOc3GN23Z/NC6vpJJH4pjdvoo7cje3TXdVOn5vcLfsrYC+TVUn8 BEZZ5mxNLqinSv8Atmco9ZFUb6+sfLSkatNJYDZWg6d9J4P8ndmdXhGB7XsbURp8eJuKwYBlNQdx hKmCxANs7htEtz37d9dFbmeG9dNnUIQhNmQisi+mPaNx9w3DpMZK3MMd8nHKW/tqQyjppsp+Gaqk 7LVlOJHMOClczcq8bbIuhdXqUr6x6D0yxi8wa5d4N5dLnYCNm0eQiZnEyccolwFRbbWqsNlZoYmd jX7oFy0qXifVcAGp+nfPTuUWnCqahw68DnVuc/M0awnMp8xzeAvBQ/tXG0/dE81auzSXE6NwpYZX MTaucOyA2n7RPT0Chj8W+1+wLjgAkkbJlX0sWse3puK91jV9LBqbN2yXuWujYwQMNYJOmu2n0Tte lVtp1XGJMVb1YlzfKeVzA27htWQCV2Mx6eiXBWsxslXxssuwqNeta7iK1mdmtbWc4wsEW7aWBZHM Mi2wF5Nh8hBU0l03bQtcev7Olf8AZMvMzVyQoVSoXeT0mBuN/TwPJxafgrNvaTVXGhtw0jKtE4yP PMchyeGgCjbSldnnjsXNF9uHcAV/zSNxkcqA4Dt5S1OoD8spA6M6i+S7QD+1GmjdqqsacmWWoczJ qnZIs/v7nsJ6Xkv9szmx+/uewnpecOD7G+KGYvw1n2F9AjYrF+Gs+wvoEbJbN9wskE6VgBOZ0qgi p6pEGR6zfRODdtoaVq0yea89OPcexaWmhgrsdmwkVP4Zjtzu5R3CjQn2mdwo3sopq6dJnors2al4 I4W3apwsT1hyVr9r6hSklcpK7T1TydnnFy9cZKU0hiSDWmltHrbKCvmnP9auHboIAPr1IqBqVAes y/47M/XPaqysKqajpkPunlMPnd9CXppoRqSoYEMquPro09QLq3bSXF3OAwHmIrOW5tumeTOu3uK/ dEQhCczqEp5nMBYcWkXXcPUKy3MnmWJke8e82QWBoTp3qQKbvqnTaVXaLcvxM2bSwIXMzLb3HK12 jWpBovR5dk0cXJXIt6wKEGjCY9nPuWnuG4gucSnEVhvpNXEvY962XsKE++oAB/BOm9WFOmMvUjNH jn4FmUMrmJt3DasgErsLHp6AJerFe7WQ5uC2NYqwPlrOVHVP1KeSNueGBRXmWQjUvICPKCNJmirq 6q6/ZYVExcrIvXbo468MgUC0INPrmvZ08G3wjqt6dhnTdqkquIbzjIzRuWpkYSFBZjRVFSZnvzK8 76bCbPJsqZYzyVw7nnoD1iVuTgFrreUBQPrr+SSlaqlrtaocQLN6lVYDcbmHEcW7wAJ2Bh0+eNys pcYBQNVw7du4CZ2cdGZc07NoP1kAwznJynr5tn1CdFtVdquIVq6oM6mk1ycD/wCoZK0ZlGk7qggH 6DLlu6l60LibPIw6DOc9VGGwA2Jp09YErcrJK3h5KA+mYarbbd0tOlwaUq0NzJclP+SluVP5Kc+H iaL6/E3PYT0vGxS/E3PYT0vGTLz8EETIhCQoTM5taJuJd82k+bbUemacTeQNsYVBFCJz3aa6Opva tpurGRbUlkNNi1r9dI0WiFCU2VqW8wNZZ9z0n1Ds6DO1xz+cfqE8S+3tk1+R63vVzk7xEpVunYJZ i02fROqz3bddNUjx7ltVmyawrIrIrOhkmsq8wXJfGJxWIuIdVFNCw8olmsivRKnDT5EeKg89/UXY WUyAWazc1sTvIru2xmKr5meLlm3otBwxpuUDbNfIxrOQ1p7ho1pg2wD1qeQxhJOwbF8gE7PeUems Np8cEY0OcWdaqkynm8uTKui6bujYBSld31y1Ccq2dXNXDNtJ5mHzDBGFbRxc16yRupu+uW+TWf2T ZeraQyaadBBrX6poh2AoPww1vWtfqnR71nTS8+LMqiTkyOW8xyr+ZbtXLhZG1VFB5FJj+ZZmZjXd LW1bHJBUlagjoM0OI/mkamApvHQZHuV1atCiIj3jS4jU+5iZGec0pZsWtAG0Iu0kn6AJpHCb3AY4 obw9en6X/bZLAYrsRVSvQJAqDWu3pi25kqrSqueeIVc5cyZWNn3cPXbKbT5G2UMby+zcvXxfcURT qLHynfsmiXJ+0qtTcSJDM7bCaDoEr3ZTiul2zckVcpcpATqJPTJsfv7nsp6XnM6x/wB/c9lPS858 H2NcUMxfhrPsL6BGxWL8NZ9hfQIyZtm+5VkiYAyJ2tNO3pkKZPOeU2s60zLRbwBGrcGH3Wnkcm1w LvDybJVlUIFqyjSN32WFRPc5JfUV8nklLJxbGVb4eQgcDdUba+YjaJ6drddVDxR59zaVnKwZ5Djp UEChAYLtP5x1nefKZCtaZ1pb1tqJAq21iQdoB27Rum43yvhO/qXLiDbUVVvL9EvYfLcTCp7vbo+7 W3rOdvSd31Ts9+iWEtnFbFpxcFHlPI3uBTkLwbKmvCqS77APWqTQbJ6igCgDYBsAlFK7wdo3H6pd BOkE+XfPLuXtZy/I9O3StcvMmsisisJzOpNZkc0uZ2NkC9bduA1CACdII3gzVrCpH0eUTVLaXMK3 RmWpWcHn25haf3ktbq18qUr+aRWaHJ7N23auXbgKi5QIDsrSu38Ms2sazYu3bybXvEGhAotK7o3a TVjOl91NOtVCcT4ErWHLZ2p2zAvXs3l+XVyzKpOjUSVZTNyBJIoQGHQdsxS+mZWpPNFsp4xBgZGd e5heQJb2gUVV2nbL+W9/l/L7Cq2l60Yih31YiXwSooiqg8wkh2A31+mbe6npSqtNcdJFXPHF8Slh Pcz+X3lutqYsVBPkoFI3eeZ9jMv8uvOty3tOxlbZu3EGbhd237PokM2oUZVcecVhbiWpOqdbfpDr ljiuJj4q3uYZRuEeoW1XG8gHRLXNbD6/eUGpGFHp5CNlZeLMRp2KvQNkAzL9k/VD3nqVkoSUaeg0 KI58TKu8xuZFlbOnoqRvakvYdlrGOS4pcund5QPPHayDVVUHppI2k1Y1MlrzXTWulTLCUOW5JlX+ SlmVv5KY4eJS8vxNz2E9LxsUvxNz2E9Lxsy8/BFQQkQkKEhhWFZFYBFIUk1kViEJJ3QkVkVlITWF ZzWEAmsisKyKygmEisisAmsKyKzPs6kxse/rdnYoHLMTUOdNKE08sza2lrCcG32RG4NCsKygly47 C4ouF+KQTt0aAxSlK03bY3FBJuXGZmPEuKASaBQx2ASV3NTSSzx8CK0k5GfjY76LjHXvoATQQfPx UtJdL1W59igJJ+qUuYcO1eY2gXyshdGneApGnd9UUbBx8jCtMasDVuipacLb+4rXSVWk0p5S4UmX a0vI1bGTayE12mqK0PkIMZM3lP2sn2/yzu7qKZV3W4a0x4dGIC0VTunSm63tVu1LczH8Z/Iqt6Uy /CU7hOO7aGYjgu51EtVkpQ7fpgENu7j0djqDawWJDHTWu2b+pjEZNJ488iyW6zrG/fXPZT0vOJ3j fvrnsp6XnTg+3vLxQzF+Gs+wvoEbFY3w1n2F9AjZm2b7lWSCEiAMhQIDb4s2xGGkispIF8ORw43Z ColkkHK2lG0750x2SKiQx2SFCsisisJQTWRWRWFYBMiRWV8upNhQxUNcAbSSCRpY02fRJZwpzI2W awrKF241ni2lZtNbWnaSwFw6WAJ2+SQ7XFtXQnEtpqtaCxOoamAahNZze7E4ZJz4T+RNRfrEpl49 y8bCPqcCpptHXO1UKgQVI85JPWZmY9tLXN7qWxpUJsA84WXcvar24S9d1V/9A21HVwW7nMsS3cNt n2g0YgEgHzmTf5hi2G0O3rbyACaAzIPwuV/er6WnaH9rk/8A2/4knm/ytz+Pqywyz/I5/UfQ20uL cQOh1KwqCJMqcrP+Rtf2v1jE20Js4rm4+q6QHOs7QVZqb/NPSt16aOPnqrf6fmb1YJ80aMispFmU vYDMFN1UBqSQrKGIrvjbIKZF5AzFAqFQxJpXVWlfolW5LSjjpffH8iyWKyv/ACUfEfyU68PEpeHx L+wnpeMnFxWDC6gqQKMvSP8AZOPebI+04U9DHSeozMTisSjayKxXvOP4qdoQ95x/FTtCNL5MShsi sV7zj+KnaEj3mx4qdoRpfJiUNrCsV7xY8VO0JHvFjxE7Ql0vkxKGwrFe8WPETtCR7xY8Re0I0vky ShtYViveLHiJ2hI94seIvaEaXyYlDayKxfvFnxF7Qhx7PiL2hLpfJiUMrCsVx7PiL1iHHs+IvaEa XyYkZWUsSzcbHsB3HDUK4WlGqNoBNfJ9Escez4i9Yhx7PiL1iZtty02ngmvP4EcHIsMGoH/Za+Jp ptqTqpWu6vmndq3w1YVrqZm7RLUkcez4i9Yhx7PiL1iFtw5SYwK13BuNlNk273DY0AGgNTZTymF3 Bu3Rbdr9b9o1W5pAHZljj2fEXrEONZ8ResTP+PTH029Tl42z5kiuPXqLw8QYqsNWt3NWalJLY+q3 fTVTjEmtN1VC/infGs+IvWIcaz4i9YmlspVVVXBe8Qogi5aDuXbaNDIVG8hqH8Ur2i73rPr6xbBr 6pUiop61TvlnjWfvr1iHGs/fXrEltqWnisZeeMBpHcZi/vrnsp6XiVdXNEOs9C7TLdi2UBLfabaf MPIJt4JzxNLMjG+GtewvondYoHgeqwPDqSrDbSvkMPecfxU7QmWm22lMlkbWRWK95x/FTtCHvOP4 qdoRpfJiUMrCsV7zj+KnaEj3ix4qdoRpfJiUNrIrF+8WPETtCR7xY8RO0JdL5MkobIrF+8WPETtC R7xY8Re0I0vkxKG1kVi/eLHiL2hI94s+IvaEaXyYlDayKxfHs+IvaEjj2fEXtCXS+TEobWVssMxs BDpbigg0r+a++M49nxF6xDj2fEXrEzajsohkcPicHHZlcu/7RypDAUC6Nq0FemQ2O7q3EcamKHYN gCENQCs749nxF6xDj2fEXrEn0l+1/jx+IwGVlZcTTmvl6/timinmA3180bx7PiL1iRx7PiL1iatt 6olN6XqXcOH4FN+VlmcLdK2bjamTTU1HnnV7luq4z2bvDDqEcU1VXYPxS1x7PiL1iHGs+IvWJz/x dvH0PHq/w8zOmoWLK2LK2lNQo3nz7ZwuPpt2E1V4JBrTfRSv453xrPiL1iHHs+IvWJv6ahLT8qhd vZGsBV60FFy5qILOrggV0lQF29I2bZGNqa9eulg4YIAwFF9XVur9MdxrP316xDjWvvr1iT6XqVlK jGOuP5khTMncVQ//AIVI1FN3Ym4738glvhJ0fm6f7PRN9OJrqdQhCczQQhCAEIQgBCEIAQhCAEIQ gBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAE IQgBCEIAQhCAEIQgBCEIB//Z ------=_NextPart_000_0001_01C684E9.A65D0C00-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed May 31 20:36:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlbAa-00068q-Qw for eap-archive@lists.ietf.org; Wed, 31 May 2006 20:36:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlbAZ-0006VZ-Cz for eap-archive@lists.ietf.org; Wed, 31 May 2006 20:36:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C82D44300DF for ; Wed, 31 May 2006 17:36:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3E892430063 for ; Wed, 31 May 2006 17:35:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 295F7398032 for ; Wed, 31 May 2006 17:35:53 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6FF81398044 for ; Wed, 31 May 2006 17:35:50 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k510ZnuD009200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2006 17:35:49 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k510ZmoS012787; Wed, 31 May 2006 17:35:48 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 17:35:47 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 17:36:01 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490BB3A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP Extensions (EAPExt) BoF Proposal Discussion Thread-Index: AcaFE1vYCL2iCioKRxavMu2wIuSlfg== From: "Narayanan, Vidya" To: , X-OriginalArrivalTime: 01 Jun 2006 00:35:47.0429 (UTC) FILETIME=[53412950:01C68513] 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: emu@machshav.com Subject: [eap] EAP Extensions (EAPExt) BoF Proposal Discussion X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Folks, We have set up a mailing list to discuss next steps on EAP keying and the work that needs to be done there. We invite people to subscribe to the EAPExt mailing list at https://www1.ietf.org/mailman/listinfo/eapext. The following drafts and other material are intended to stimulate initial discussion. http://www.ietf.org/internet-drafts/draft-vidya-eap-keying-gap-analysis- 00.txt http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-00.txt http://www.geocities.com/hellovidya/EAPExt_motivation.txt http://www.geocities.com/hellovidya/EAPExt_charter.txt http://www.geocities.com/hellovidya/EAPExt_11r_kh.pdf Thanks, 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 recwgxxpswc@swufe.edu.cn Wed May 31 23:48:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FleAL-0003tU-GL for eap-archive@ietf.org; Wed, 31 May 2006 23:48:09 -0400 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 1FleAL-0002fL-EI for eap-archive@ietf.org; Wed, 31 May 2006 23:48:09 -0400 Received: from [202.115.125.20] (helo=swufe.edu.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FleAG-0003iM-Ca for eap-archive@ietf.org; Wed, 31 May 2006 23:48:08 -0400 Received: (qmail 26947 invoked from network); Thu, 01 Jun 2006 11:47:51 +0800 Received: from unknown (HELO service2.colo.trueswitch.com) ([192.168.0.68]) (envelope-sender recwgxxpswc@swufe.edu.cn) by mail.trueswitch.com (qmail-ldap-1.03) with SMTP for ; Thu, 01 Jun 2006 11:47:51 +0800 Message-ID: <49873862.0980496828479.JavaMail.vmail@service2.colo.swufe.edu.cn> Date: Thu, 01 Jun 2006 11:47:51 +0800 (EDT) From: "cyzobgh uoxrajv" Reply-to: recwgxxpswc@swufe.edu.cn To: Subject: {Info} Forward-Thinking Investors INFX Mime-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 INFX**INFX**INFX**INFX**INFX**INFX**INFX**INFX** Infinex Ventures Inc. (INFX) Current Price: $0.52 The Rally has begun Watch this one like a hawk, this report is sent because the potential is incredible This is AS sure as it gets H U G E N E W S read below COMPANY OVERVIEW Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company’s true potential. Maximizing overall profitability and in turn enhancing shareholder value. Current Press Release Infinex Announces Extension to Its Agreement in Chile LAS VEGAS, NV, May 9 /PRNewswire-FirstCall/ - Infinex Ventures Inc. (INFX:OB - News; "the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infinex Announces Joint Venture and Option Agreement Extension LAS VEGAS, May 5 /PRNewswire-FirstCall/ - Infinex Ventures Inc. (INFX:OB - "the Company") and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Gr0up" Mining Claims: You never miss the water till the well runs dry. Sour as a green apple. Treat him like dirt. Spring rain, Fall gold. Tall as a tree. Putting the cart before the horse. Stubborn as a mule. Under the weather. Stubborn as a mule. Stuck in a rut. Waking up with the chickens. When pigs fly. Throw pearls before swine. Sow dry and set wet. That's water under the bridge. Putting it in a nutshell. You can't teach an old dog new tricks. Stone cold sober. Putting the cart before the horse. Putting the cart before the horse. Play a harp before a cow. Tools of the trade. Timing is everything. You have to separate the chaff from the wheat. Timber! She has a green thumb. Read the tea leaves. Put off the scent. Walking on water. We'll cross that bridge when we come to it. Play a harp before a cow. You can lead a horse to water but you can't make him drink.