From hzhou@cisco.com Sun Apr 1 19:29:36 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C9F21F870B for ; Sun, 1 Apr 2012 19:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A-a75h3vkdS for ; Sun, 1 Apr 2012 19:29:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1321F8707 for ; Sun, 1 Apr 2012 19:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=1220; q=dns/txt; s=iport; t=1333333754; x=1334543354; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=qdrgmvgv1IhOJHI1JEB1nEU/si7QcMcJXef3aFjsRbo=; b=dfto+QArV37jIIj5AO4DEbQqx1/rss7nlyG4jKzc/pRP57izXoIUNcNc sQu0bdRtwYAP+QNuZfhxdIoyo4kw9NUigb/YCfWgKoSiIHi1Bi81nWdt6 7wMS4/eUBQD5aKdn9aGCMSJXpqCMMgXUUbmB4bdqDqlJEDI44SFridguu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANsOeU+tJV2b/2dsb2JhbABEuH2BB4IJAQEBAwEBAQEPAScCATELBQ0BCG0wAQEEAQ0FIodiBQubVJ1+BJEcBJVhjkeBaIMD X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="71232810" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2012 02:29:03 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q322T3UB021939; Mon, 2 Apr 2012 02:29:03 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 21:29:03 -0500 Received: from 10.81.8.137 ([10.81.8.137]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.63.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 02:29:02 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 01 Apr 2012 22:28:59 -0400 From: Hao Zhou To: Jim Schaad , Message-ID: Thread-Topic: [Emu] Multiple Request Action Items Thread-Index: Ac0OR0cl7mX0lVlfRWyk8JUrmizplgCMRTk0 In-Reply-To: <039301cd0e47$7d7503e0$785f0ba0$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2012 02:29:03.0398 (UTC) FILETIME=[5EAABC60:01CD1078] Cc: emu@ietf.org Subject: Re: [Emu] Multiple Request Action Items X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 02:29:36 -0000 Jim: Good question. The current draft allows for multiple request TLV items, but only says a single Result TLV, indicating the what EAP Success/Failure result the peer would expect if the requested action is not granted. I can definitely see the need for the case you cited. If we want to extend existing design to include individual Result TLVs for the individual request items, we can do that. But I think this might be more complicated and unnecessary. Maybe we can use the mandatory bit in the requested TLVs to indicate whether ignoring it would cause the failure in the result TLV. Thoughts? On 3/30/12 3:34 AM, "Jim Schaad" wrote: > In the presentation you stated that the plan was to make the TLVs that are > requested become a sub TLV of the request TLV items. If that is true, then > should it be possible to allow for multiple request TLVs to be present in a > message. Thus one could say: > Please do A - and if not then fail authentication > Please do B - and if not then succeed authentication > > Jim > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Sun Apr 1 23:08:48 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFD11E80B7 for ; Sun, 1 Apr 2012 23:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrQZuejkB7V1 for ; Sun, 1 Apr 2012 23:08:47 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE611E80B2 for ; Sun, 1 Apr 2012 23:08:47 -0700 (PDT) Received: from Tobias (unknown [81.253.38.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id C0B2A2CA2D; Sun, 1 Apr 2012 23:08:45 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou'" , References: <039301cd0e47$7d7503e0$785f0ba0$@augustcellars.com> In-Reply-To: Date: Mon, 2 Apr 2012 08:07:51 +0200 Message-ID: <046001cd1096$f22df790$d689e6b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJFuiyy3of4oOR+YvL2yoHnnoS9HJWVt85w Cc: emu@ietf.org Subject: Re: [Emu] Multiple Request Action Items X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:08:48 -0000 Hao, The idea that I thought you had presented would not make it a very complicated item. 1. Change the specification so that multiple Request TLVs are permitted to occur in the TLV sequence. 2. Change to specification so that the Request TLV item now looks like M|R|TLV Type | Length | Status | TLV sequence The TLV Sequence is the set of TLV items to be processed for that sequence code. Then need some oddball text to the effect that: Two Request TLVs MUST NOT occur in the message if they have the same Status value. The order of processing multiple Request TLVs is implementation dependent. If the server process the optional (non-fatal) items first, it is possible that the fatal items will disappear at a later time. If the server process the fatal items first, the communication time will be shorter. The client MAY return a new set of Request TLV items after one or more of the requested items has been processed and the server has signaled it wants to end the EAP conversation. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Hao Zhou > Sent: Monday, April 02, 2012 4:29 AM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Multiple Request Action Items > > Jim: > > Good question. The current draft allows for multiple request TLV items, but > only says a single Result TLV, indicating the what EAP Success/Failure result > the peer would expect if the requested action is not granted. > > I can definitely see the need for the case you cited. If we want to extend > existing design to include individual Result TLVs for the individual request > items, we can do that. But I think this might be more complicated and > unnecessary. Maybe we can use the mandatory bit in the requested TLVs to > indicate whether ignoring it would cause the failure in the result TLV. > > Thoughts? > > On 3/30/12 3:34 AM, "Jim Schaad" wrote: > > > In the presentation you stated that the plan was to make the TLVs that > > are requested become a sub TLV of the request TLV items. If that is > > true, then should it be possible to allow for multiple request TLVs to > > be present in a message. Thus one could say: > > Please do A - and if not then fail authentication > > Please do B - and if not then succeed authentication > > > > Jim > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From zhou.sujing@zte.com.cn Tue Apr 10 02:07:23 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17B521F85DF; Tue, 10 Apr 2012 02:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk8X6wOo0zNB; Tue, 10 Apr 2012 02:07:22 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7253421F85E3; Tue, 10 Apr 2012 02:07:21 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286202676637534; Tue, 10 Apr 2012 16:29:45 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.5638350826; Tue, 10 Apr 2012 17:07:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3A97AAD054343; Tue, 10 Apr 2012 17:07:10 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <1B7F8AAF-273D-4ADD-9777-9B413D915814@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 10 Apr 2012 17:07:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-10 17:07:11, Serialize complete at 2012-04-10 17:07:11 Content-Type: multipart/alternative; boundary="=_alternative 00321DE8482579DC_=" X-MAIL: mse01.zte.com.cn q3A97AAD054343 Cc: emu-bounces@ietf.org, "emu@ietf.org" Subject: [Emu] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1jYWt1bGV2LWVtdS1lYXAtaWJh?= =?gb2312?b?a2U=?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:07:23 -0000 This is a multipart message in MIME format. --=_alternative 00321DE8482579DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrEhhbm5lc6OsDQoNCj4gPiANCj4gSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB5b3Ugd2ls bCBub3QgZ2V0IHRoZSBuZWNlc3Nhcnkgc3VwcG9ydCANCj4gZnJvbSB0aGUgRU1VIHdvcmtpbmcg Z3JvdXAgdG8gZ2V0IHRoZSBjaGFydGVyIGNoYW5nZWQgYW5kIHRoZSBncm91cCANCj4gaW50ZXJl c3RlZCBpbiBJQkUuIA0KPiBJIGNhbiB0ZWxsIHlvdSB0aGF0IEkgd2lsbCBub3Qgc3BlbmQgbXkg dGltZSBvbiBpdC4gDQo+IA0KPiBNeSByZWFzb25zIGFyZSBiZWluZyBsZXNzIGV4Y2l0ZWQgYXJl OiANCj4gKiBJZGVudGl0eSBiYXNlZCBjcnlwdG8gYXMgYSB0ZWNobm9sb2d5IGRvZXMgbm90IHJl YWxseSBzb2x2ZSBhIA0KPiBwcm9ibGVtLiAoSW4gY2FzZSB5b3UgYXJlIGdvaW5nIHRvIGFzazog InllcyIgSSBsb29rZWQgaXQgc29tZSB0aW1lIA0KPiBhZ28gd2hlbiBJIHRyaWVkIHRvIGZpZ3Vy ZSBvdXQgd2hhdCB2YWx1ZSBpdCBwcm92aWRlcyBmb3Igc29tZSBJRVRGIA0KPiBwcm90b2NvbHMu IEFuZCBndWVzcyB3aGF0IC0gSSBjb3VsZG4ndCBmaW5kIGFueSBiZW5lZml0cy4pDQo+ICogIkVU U0kgd2FudHMgaXQiIGlzIG5vdCBhIGdvb2QgcmVhc29uIGZvciBtZSB0b2RvIGFueXRoaW5nLg0K PiAqIEkgaGF2ZSBzbyBtYW55IG90aGVyIGdyZWF0IGRvY3VtZW50cyB0byByZXZpZXcuIA0KPiAq IFRoZSBJUFIgc2l0dWF0aW9uIHdpdGggaWRlbnRpdHkgYmFzZWQgY3J5cHRvIG1ha2VzIG1lIGZl ZWwgdW5lYXN5LiANCj4gDQpNYXkgSSAgYXNrIGZvciB0aGUgcmVhc29uIHdoeSB5b3UgdGhpbmsg eW91IGNvdWxkIG5vdCBmaW5kIGFueSBiZW5lZml0cyBpbiANCmlkZW50aXR5IGJhc2VkIGNyeXB0 b2dyYXBoeT8NCk9ubHkgYmVhY2F1c2UgaXQgaGFzIElQUiBwcm9ibGVtcz8NClRvIGJlIG9iamVj dCwgIGlkZW50aXR5IGJhc2VkIGNyeXB0b2dyYXBoeSBpcyBhIGdyZWF0IGlkZWEsIHlvdSBkb24n dCBoYXZlIA0KdG8gdHJhbnNmZXIgbG9uZyBwdWJsaWMga2V5LA0KYW5kIGNoZWNraW5nIHN0YXR1 cyBvZiBwdWJsaWMga2V5cyBmcmVxdWVudGx5Lg0KDQpSZWdhcmRzfn5+DQoNCi1TdWppbmcNCg0K --=_alternative 00321DE8482579DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6xIYW5uZXOjrDwvZm9udD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7IEkgcGVyc29u YWxseSBiZWxpZXZlIHRoYXQgeW91IHdpbGwgbm90IGdldCB0aGUgbmVjZXNzYXJ5IHN1cHBvcnQg PGJyPg0KJmd0OyBmcm9tIHRoZSBFTVUgd29ya2luZyBncm91cCB0byBnZXQgdGhlIGNoYXJ0ZXIg Y2hhbmdlZCBhbmQgdGhlIGdyb3VwDQo8YnI+DQomZ3Q7IGludGVyZXN0ZWQgaW4gSUJFLiA8YnI+ DQomZ3Q7IEkgY2FuIHRlbGwgeW91IHRoYXQgSSB3aWxsIG5vdCBzcGVuZCBteSB0aW1lIG9uIGl0 LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTXkgcmVhc29ucyBhcmUgYmVpbmcgbGVzcyBleGNpdGVk IGFyZTogPGJyPg0KJmd0OyAqIElkZW50aXR5IGJhc2VkIGNyeXB0byBhcyBhIHRlY2hub2xvZ3kg ZG9lcyBub3QgcmVhbGx5IHNvbHZlIGEgPGJyPg0KJmd0OyBwcm9ibGVtLiAoSW4gY2FzZSB5b3Ug YXJlIGdvaW5nIHRvIGFzazogJnF1b3Q7eWVzJnF1b3Q7IEkgbG9va2VkIGl0DQpzb21lIHRpbWUg PGJyPg0KJmd0OyBhZ28gd2hlbiBJIHRyaWVkIHRvIGZpZ3VyZSBvdXQgd2hhdCB2YWx1ZSBpdCBw cm92aWRlcyBmb3Igc29tZSBJRVRGDQo8YnI+DQomZ3Q7IHByb3RvY29scy4gQW5kIGd1ZXNzIHdo YXQgLSBJIGNvdWxkbid0IGZpbmQgYW55IGJlbmVmaXRzLik8YnI+DQomZ3Q7ICogJnF1b3Q7RVRT SSB3YW50cyBpdCZxdW90OyBpcyBub3QgYSBnb29kIHJlYXNvbiBmb3IgbWUgdG9kbyBhbnl0aGlu Zy48YnI+DQomZ3Q7ICogSSBoYXZlIHNvIG1hbnkgb3RoZXIgZ3JlYXQgZG9jdW1lbnRzIHRvIHJl dmlldy4gPGJyPg0KJmd0OyAqIFRoZSBJUFIgc2l0dWF0aW9uIHdpdGggaWRlbnRpdHkgYmFzZWQg Y3J5cHRvIG1ha2VzIG1lIGZlZWwgdW5lYXN5Lg0KPGJyPg0KJmd0OyA8YnI+DQpNYXkgSSAmbmJz cDthc2sgZm9yIHRoZSByZWFzb24gd2h5IHlvdSB0aGluayB5b3UgY291bGQgbm90IGZpbmQgYW55 IGJlbmVmaXRzDQppbiBpZGVudGl0eSBiYXNlZCBjcnlwdG9ncmFwaHk/PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5Pbmx5IGJlYWNhdXNlIGl0IGhhcyBJUFIgcHJvYmxlbXM/PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UbyBiZSBvYmplY3QsICZuYnNwO2lkZW50 aXR5IGJhc2VkIGNyeXB0b2dyYXBoeSBpcw0KYSBncmVhdCBpZGVhLCB5b3UgZG9uJ3QgaGF2ZSB0 byB0cmFuc2ZlciBsb25nIHB1YmxpYyBrZXksPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5hbmQgY2hlY2tpbmcgc3RhdHVzIG9mIHB1YmxpYyBrZXlzIGZyZXF1ZW50bHkuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkc35+fjxicj4NCjxicj4NCi1TdWppbmc8L2ZvbnQ+ DQo8YnI+DQo= --=_alternative 00321DE8482579DC_=-- From hannes.tschofenig@nsn.com Tue Apr 10 03:43:20 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50721F86FC for ; Tue, 10 Apr 2012 03:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-3.299, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+6XWx9T8oO3 for ; Tue, 10 Apr 2012 03:43:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DE2AB21F86F3 for ; Tue, 10 Apr 2012 03:43:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3AAhE1O005276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 12:43:14 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3AAh9DK022841; Tue, 10 Apr 2012 12:43:14 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 12:42:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1706.A9C5DE44" Date: Tue, 10 Apr 2012 13:42:44 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D014D6362@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W0VtdV0gtPC4tDogUmU6ICBkcmFmdC1jYWt1bGV2LWVtdS1lYXAtaWJha2U=?= Thread-Index: Ac0W+UyRIFCTBxy0RTCk7swp2f0N7AAC3+kQ References: <1B7F8AAF-273D-4ADD-9777-9B413D915814@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , "Hannes Tschofenig" X-OriginalArrivalTime: 10 Apr 2012 10:42:45.0769 (UTC) FILETIME=[AA47D790:01CD1706] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12300 X-purgate-ID: 151667::1334054594-00007415-9322D6A9/0-0/0-0 Cc: emu@ietf.org Subject: Re: [Emu] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1jYWt1bGV2LWVtdS1lYXAtaWJh?= =?gb2312?b?a2U=?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:43:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1706.A9C5DE44 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Zhou,=20 =20 The first step is to figure out what the actual problem is.=20 =20 Ask yourself: Is there indeed a problem with transferring the = =A1=B0long=A1=B1 public keys (of the client, as you state below)?=20 =20 For the cases where I have seen EAP used so far I have not heard about = these problems. I have, however, heard about problems with the many = roundtrips of EAP methods and the usage of RADIUS. This was partially = the motivation for the work on RADIUS over TCP (and TLS). =20 There is, however, work ongoing to make use of EAP in environments with = different radio interfaces (like IEEE 802.15.4 and alike) and, as you = know, there you can find additional challenges. However, for those cases = folks had been looking into different solutions that are more likely to = find deployment (assuming that EAP is a suitable technology for whatever = use cases people have in mind there). Today, as you may know the = deployments are actually quite simplicity from a security point of view. = =20 =20 Just to remind you about the last smart object security workshop various = folks had been looking into the usage of TLS-PSK and high-quality = pre-shared secret cipher suites are available as EAP methods as well. (I = had once worked with Thomas Otto on a EAP-TLS-PSK method, see = http://tools.ietf.org/html/draft-otto-emu-eap-tls-psk-02). =20 =20 Regarding the revocation issue: If the client=A1=AFs credentials get = revoked then he must not be able to successfully authenticate to the AAA = server anymore. Done. I don=A1=AFt see how this can get any easier = regardless of the authentication protocol. =20 Ciao Hannes =20 From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of = ext zhou.sujing@zte.com.cn Sent: Tuesday, April 10, 2012 12:07 PM To: Hannes Tschofenig Cc: emu-bounces@ietf.org; emu@ietf.org Subject: [Emu] =B4=F0=B8=B4: Re: draft-cakulev-emu-eap-ibake =20 Hi=A3=ACHannes=A3=AC=20 > >=20 > I personally believe that you will not get the necessary support=20 > from the EMU working group to get the charter changed and the group=20 > interested in IBE.=20 > I can tell you that I will not spend my time on it.=20 >=20 > My reasons are being less excited are:=20 > * Identity based crypto as a technology does not really solve a=20 > problem. (In case you are going to ask: "yes" I looked it some time=20 > ago when I tried to figure out what value it provides for some IETF=20 > protocols. And guess what - I couldn't find any benefits.) > * "ETSI wants it" is not a good reason for me todo anything. > * I have so many other great documents to review.=20 > * The IPR situation with identity based crypto makes me feel uneasy.=20 >=20 May I ask for the reason why you think you could not find any benefits = in identity based cryptography?=20 Only beacause it has IPR problems?=20 To be object, identity based cryptography is a great idea, you don't = have to transfer long public key,=20 and checking status of public keys frequently.=20 Regards~~~ -Sujing=20 ------_=_NextPart_001_01CD1706.A9C5DE44 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Zhou,

 

The first step is to figure out what the actual problem is. =

 

Ask yourself: Is there indeed a problem with transferring the = =A1=B0long=A1=B1 public keys (of the client, as you state below)? =

 

For the cases where I have seen EAP used so far I have not heard = about these problems. I have, however, heard about problems with the = many roundtrips of EAP methods and the usage of RADIUS. This was = partially the motivation for the work on RADIUS over TCP (and = TLS).

 

There is, however, work ongoing to make use of EAP in environments = with different radio interfaces (like IEEE 802.15.4 and alike) and, as = you know, there you can find additional challenges. However, for those = cases folks had been looking into different solutions that are more = likely to find deployment (assuming that EAP is a suitable technology = for whatever use cases people have in mind there). Today, as you may = know the deployments are actually quite simplicity from a security point = of view.  

 

Just to remind you about the last smart object security workshop = various folks had been looking into the usage of TLS-PSK and = high-quality pre-shared secret cipher suites are available as EAP = methods as well. (I had once worked with Thomas Otto on a EAP-TLS-PSK = method, see http://= tools.ietf.org/html/draft-otto-emu-eap-tls-psk-02). =  

 

Regarding the revocation issue: If the client=A1=AFs credentials get = revoked then he must not be able to successfully authenticate to the AAA = server anymore. Done. I don=A1=AFt see how this can get any easier = regardless of the authentication protocol.

 

Ciao

Hannes

 

From:= = emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of = ext zhou.sujing@zte.com.cn
Sent: Tuesday, April 10, 2012 = 12:07 PM
To: Hannes Tschofenig
Cc: = emu-bounces@ietf.org; emu@ietf.org
Subject: [Emu] =B4=F0=B8=B4: Re: = draft-cakulev-emu-eap-ibake

 


Hi=A3=ACHannes= =A3=AC =

> >
> I personally believe that you = will not get the necessary support
> from the EMU = working group to get the charter changed and the group
> = interested in IBE.
> I can tell you that I will not = spend my time on it.
>
> My reasons are = being less excited are:
> * Identity based crypto as a = technology does not really solve a
> problem. (In case = you are going to ask: "yes" I looked it some time =
> ago when I tried to figure out what value it provides = for some IETF
> protocols. And guess what - I couldn't = find any benefits.)
> * "ETSI wants it" is not = a good reason for me todo anything.
> * I have so many = other great documents to review.
> * The IPR situation = with identity based crypto makes me feel uneasy.
> =
May I  ask for the reason why you think you could not = find any benefits in identity based cryptography? =
Only beacause it has IPR = problems?
To be = object,  identity based cryptography is a great idea, you don't = have to transfer long public key,
and checking status of public keys = frequently.

Regards~~~
-Sujing

------_=_NextPart_001_01CD1706.A9C5DE44-- From aland@deployingradius.com Tue Apr 10 04:19:29 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80221F8610 for ; Tue, 10 Apr 2012 04:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOYE30S-e9De for ; Tue, 10 Apr 2012 04:19:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C221F8601 for ; Tue, 10 Apr 2012 04:19:28 -0700 (PDT) Message-ID: <4F841724.4090301@deployingradius.com> Date: Tue, 10 Apr 2012 13:19:00 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <1B7F8AAF-273D-4ADD-9777-9B413D915814@gmx.net> <999913AB42CC9341B05A99BBF358718D014D6362@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D014D6362@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: emu@ietf.org Subject: Re: [Emu] =?utf-8?b?562U5aSNOiBSZTogIGRyYWZ0LWNha3VsZXYtZW11LWVhcC1p?= =?utf-8?q?bake?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:19:29 -0000 Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Ask yourself: Is there indeed a problem with transferring the “long” > public keys (of the client, as you state below)? I've seen this be a problem when the long keys require too many round trips. ~20K of data, or ~20 round trips is about the limit. One way to optimize this is to *not* send the certificates on every authentication. All implementations I've seen currently exchange all of the certs, including any CA chain. But I'm not sure that this is required. Sending only client/server cert would minimize the number of round trips. Alan DeKok. From hannes.tschofenig@nsn.com Tue Apr 10 05:46:06 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABFE21F85C0 for ; Tue, 10 Apr 2012 05:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.286 X-Spam-Level: X-Spam-Status: No, score=-105.286 tagged_above=-999 required=5 tests=[AWL=0.861, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNelYtFRKvGQ for ; Tue, 10 Apr 2012 05:46:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2657821F8589 for ; Tue, 10 Apr 2012 05:46:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3ACk184022531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 14:46:02 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3ACk09T021216; Tue, 10 Apr 2012 14:46:01 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 14:45:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 10 Apr 2012 15:45:33 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D014D6471@FIESEXC035.nsn-intra.net> In-Reply-To: <4F841724.4090301@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?utf-8?B?W0VtdV0g562U5aSNOiBSZTogIGRyYWZ0LWNha3VsZXYtZW11?= =?utf-8?B?LWVhcC1pYmFrZQ==?= Thread-Index: Ac0XC66gQeydfXgZTGSpm5eCU/6NqAAC62VQ References: <1B7F8AAF-273D-4ADD-9777-9B413D915814@gmx.net> <999913AB42CC9341B05A99BBF358718D014D6362@FIESEXC035.nsn-intra.net> <4F841724.4090301@deployingradius.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Alan DeKok" X-OriginalArrivalTime: 10 Apr 2012 12:45:36.0086 (UTC) FILETIME=[D354F760:01CD1717] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1380 X-purgate-ID: 151667::1334061963-00003570-C285E7F9/0-0/0-0 Cc: emu@ietf.org Subject: Re: [Emu] =?utf-8?b?562U5aSNOiBSZTogIGRyYWZ0LWNha3VsZXYtZW11LWVhcC1p?= =?utf-8?q?bake?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:46:07 -0000 SGkgQWxhbiwgDQoNCj4gVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbykgd3JvdGU6 DQo+ID4gQXNrIHlvdXJzZWxmOiBJcyB0aGVyZSBpbmRlZWQgYSBwcm9ibGVtIHdpdGggdHJhbnNm ZXJyaW5nIHRoZSDigJxsb25n4oCdDQo+ID4gcHVibGljIGtleXMgKG9mIHRoZSBjbGllbnQsIGFz IHlvdSBzdGF0ZSBiZWxvdyk/DQo+IA0KPiAgIEkndmUgc2VlbiB0aGlzIGJlIGEgcHJvYmxlbSB3 aGVuIHRoZSBsb25nIGtleXMgcmVxdWlyZSB0b28gbWFueSByb3VuZA0KPiB0cmlwcy4gIH4yMEsg b2YgZGF0YSwgb3IgfjIwIHJvdW5kIHRyaXBzIGlzIGFib3V0IHRoZSBsaW1pdC4NCg0KDQpGb3Ig VExTIGNsaWVudCBhdXRoZW50aWNhdGlvbiBJIGFtIHdvbmRlcmluZyB3aHkgYSBjZXJ0aWZpY2F0 ZSBjaGFpbiBuZWVkcyB0byBiZSB0cmFuc21pdHRlZCB0byB0aGUgc2VydmVyLiANCg0KPiAgIE9u ZSB3YXkgdG8gb3B0aW1pemUgdGhpcyBpcyB0byAqbm90KiBzZW5kIHRoZSBjZXJ0aWZpY2F0ZXMg b24gZXZlcnkNCj4gYXV0aGVudGljYXRpb24uDQoNCkNvcnJlY3QuIE9uZSBjb3VsZCB1c2UgdGhl IGNhY2hlZCBpbmZvIGV4dGVuc2lvbiBpZiB0aGUgc2l6ZSBpcyBhIGNvbmNlcm4gYnV0IEkgZG9u J3QgdGhpbmsgaXQgYWN0dWFsbHkgaXMuIA0KDQo+IEFsbCBpbXBsZW1lbnRhdGlvbnMgSSd2ZSBz ZWVuIGN1cnJlbnRseSBleGNoYW5nZSBhbGwNCj4gb2YNCj4gdGhlIGNlcnRzLCBpbmNsdWRpbmcg YW55IENBIGNoYWluLiAgQnV0IEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMNCj4gcmVxdWlyZWQu DQoNClRoaXMgc2VlbXMgdG8gYmUgdGhlIHJlc3VsdCBvZiBtaXNjb25maWd1cmF0aW9uLiANCg0K PiAgIFNlbmRpbmcgb25seSBjbGllbnQvc2VydmVyIGNlcnQgd291bGQgbWluaW1pemUgdGhlIG51 bWJlciBvZiByb3VuZA0KPiB0cmlwcy4NCg0KVGhhdCdzIHdoYXQgc2hvdWxkIGJlIGRvbmUuDQoN CkNpYW8NCkhhbm5lcw0KDQo+IA0KPiAgIEFsYW4gRGVLb2suDQo= From zhou.sujing@zte.com.cn Tue Apr 10 17:45:26 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE111E8143 for ; Tue, 10 Apr 2012 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXvFV9vUyrdJ for ; Tue, 10 Apr 2012 17:45:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9211E8081 for ; Tue, 10 Apr 2012 17:45:25 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201794749335; Wed, 11 Apr 2012 08:07:43 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 6479.3874837234; Wed, 11 Apr 2012 08:45:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3B0jFr5086424; Wed, 11 Apr 2012 08:45:15 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <999913AB42CC9341B05A99BBF358718D014D6362@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 11 Apr 2012 08:45:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-11 08:45:16, Serialize complete at 2012-04-11 08:45:16 Content-Type: multipart/alternative; boundary="=_alternative 00042A83482579DD_=" X-MAIL: mse02.zte.com.cn q3B0jFr5086424 Cc: emu@ietf.org Subject: [Emu] =?gb2312?b?tPC4tDogUkU6ICC08Li0OiBSZTogIGRyYWZ0LWNha3VsZXYt?= =?gb2312?b?ZW11LWVhcC1pYmFrZQ==?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:45:26 -0000 This is a multipart message in MIME format. --=_alternative 00042A83482579DD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrEhhbm5lcw0KDQoNCj4gDQo+IFJlZ2FyZGluZyB0aGUgcmV2b2NhdGlvbiBpc3N1ZTogSWYg dGhlIGNsaWVudKGvcyBjcmVkZW50aWFscyBnZXQgDQo+IHJldm9rZWQgdGhlbiBoZSBtdXN0IG5v dCBiZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGUgdG8gdGhlDQo+IEFBQSBzZXJ2 ZXIgYW55bW9yZS4gRG9uZS4gSSBkb26hr3Qgc2VlIGhvdyB0aGlzIGNhbiBnZXQgYW55IGVhc2ll ciANCj4gcmVnYXJkbGVzcyBvZiB0aGUgYXV0aGVudGljYXRpb24gcHJvdG9jb2wuDQoNCm9uIHJl dm9jYXRpb24gaXNzdWUsIA0KICBUcmFkaXRpb25hbCBQS0kgYmFzZWQgcHVibGljIGtleSBjcnlw dG9ncmFwaHkgIGFuZCBjZXJ0OiBhIGNsaWVudCBsb2dpbiANCndpdGggYSByZXZva2VkIGNlcnQs IHNlcnZlciBjaGVjayBzdGF0dXMgb2YgdGhlIGNlcnQgYnkgb2NzcCBwcm90b2NvbCBlYWNoIA0K dGltZS4NCiAgSWRlbnRpdHkgYmFzZWQgcHVibGljIGtleSBjcnlwdG9ncmFwaHk6IGEgY2xpZW50 IGxvZ2luIHdpdGggYSBleHBpcmVkIA0KaWRlbnRpdHl8fGRhdGUsICBzZXJ2ZXIgY2FuIGNoZWNr IHN0YXR1cyBvZiB0aGUgY2xpZW50J3MgY3JlZGVudGlhbCANCmxvY2FsbHkuIA0KIA0KDQo+IA0K PiBDaWFvDQo+IEhhbm5lcw0KPiANCg0KPiANCj4gSGmjrEhhbm5lc6OsIA0KPiANCj4gPiA+IA0K PiA+IEkgcGVyc29uYWxseSBiZWxpZXZlIHRoYXQgeW91IHdpbGwgbm90IGdldCB0aGUgbmVjZXNz YXJ5IHN1cHBvcnQgDQo+ID4gZnJvbSB0aGUgRU1VIHdvcmtpbmcgZ3JvdXAgdG8gZ2V0IHRoZSBj aGFydGVyIGNoYW5nZWQgYW5kIHRoZSBncm91cCANCj4gPiBpbnRlcmVzdGVkIGluIElCRS4gDQo+ ID4gSSBjYW4gdGVsbCB5b3UgdGhhdCBJIHdpbGwgbm90IHNwZW5kIG15IHRpbWUgb24gaXQuIA0K PiA+IA0KPiA+IE15IHJlYXNvbnMgYXJlIGJlaW5nIGxlc3MgZXhjaXRlZCBhcmU6IA0KPiA+ICog SWRlbnRpdHkgYmFzZWQgY3J5cHRvIGFzIGEgdGVjaG5vbG9neSBkb2VzIG5vdCByZWFsbHkgc29s dmUgYSANCj4gPiBwcm9ibGVtLiAoSW4gY2FzZSB5b3UgYXJlIGdvaW5nIHRvIGFzazogInllcyIg SSBsb29rZWQgaXQgc29tZSB0aW1lIA0KPiA+IGFnbyB3aGVuIEkgdHJpZWQgdG8gZmlndXJlIG91 dCB3aGF0IHZhbHVlIGl0IHByb3ZpZGVzIGZvciBzb21lIElFVEYgDQo+ID4gcHJvdG9jb2xzLiBB bmQgZ3Vlc3Mgd2hhdCAtIEkgY291bGRuJ3QgZmluZCBhbnkgYmVuZWZpdHMuKQ0KPiA+ICogIkVU U0kgd2FudHMgaXQiIGlzIG5vdCBhIGdvb2QgcmVhc29uIGZvciBtZSB0b2RvIGFueXRoaW5nLg0K PiA+ICogSSBoYXZlIHNvIG1hbnkgb3RoZXIgZ3JlYXQgZG9jdW1lbnRzIHRvIHJldmlldy4gDQo+ ID4gKiBUaGUgSVBSIHNpdHVhdGlvbiB3aXRoIGlkZW50aXR5IGJhc2VkIGNyeXB0byBtYWtlcyBt ZSBmZWVsIHVuZWFzeS4gDQo+ID4gDQo+IE1heSBJICBhc2sgZm9yIHRoZSByZWFzb24gd2h5IHlv dSB0aGluayB5b3UgY291bGQgbm90IGZpbmQgYW55IA0KPiBiZW5lZml0cyBpbiBpZGVudGl0eSBi YXNlZCBjcnlwdG9ncmFwaHk/IA0KPiBPbmx5IGJlYWNhdXNlIGl0IGhhcyBJUFIgcHJvYmxlbXM/ IA0KPiBUbyBiZSBvYmplY3QsICBpZGVudGl0eSBiYXNlZCBjcnlwdG9ncmFwaHkgaXMgYSBncmVh dCBpZGVhLCB5b3UgDQo+IGRvbid0IGhhdmUgdG8gdHJhbnNmZXIgbG9uZyBwdWJsaWMga2V5LCAN Cj4gYW5kIGNoZWNraW5nIHN0YXR1cyBvZiBwdWJsaWMga2V5cyBmcmVxdWVudGx5LiANCj4gDQo+ IFJlZ2FyZHN+fn4NCj4gDQo+IC1TdWppbmcgDQo= --=_alternative 00042A83482579DD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6xIYW5uZXM8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSZWdhcmRpbmcgdGhlIHJldm9jYXRpb24gaXNzdWU6 IElmIHRoZSBjbGllbnShr3MNCmNyZWRlbnRpYWxzIGdldCA8YnI+DQomZ3Q7IHJldm9rZWQgdGhl biBoZSBtdXN0IG5vdCBiZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGUgdG8gdGhl PGJyPg0KJmd0OyBBQUEgc2VydmVyIGFueW1vcmUuIERvbmUuIEkgZG9uoa90IHNlZSBob3cgdGhp cyBjYW4gZ2V0IGFueSBlYXNpZXINCjxicj4NCiZndDsgcmVnYXJkbGVzcyBvZiB0aGUgYXV0aGVu dGljYXRpb24gcHJvdG9jb2wuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5vbiByZXZvY2F0aW9uIGlzc3VlLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZuYnNwOyBUcmFkaXRpb25hbCBQS0kgYmFzZWQgcHVibGljIGtleSBjcnlwdG9ncmFwaHkNCiZu YnNwO2FuZCBjZXJ0OiBhIGNsaWVudCBsb2dpbiB3aXRoIGEgcmV2b2tlZCBjZXJ0LCBzZXJ2ZXIg Y2hlY2sgc3RhdHVzDQpvZiB0aGUgY2VydCBieSBvY3NwIHByb3RvY29sICZuYnNwO2VhY2ggdGlt ZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyBJZGVudGl0eSBiYXNl ZCBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeTogYSBjbGllbnQNCmxvZ2luIHdpdGggYSBleHBpcmVk IGlkZW50aXR5fHxkYXRlLCAmbmJzcDtzZXJ2ZXIgY2FuIGNoZWNrIHN0YXR1cyBvZiB0aGUNCmNs aWVudCdzIGNyZWRlbnRpYWwgbG9jYWxseS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mbmJzcDsgPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDaWFvPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhhbm5lczwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIaaOsSGFubmVzo6wgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhh dCB5b3Ugd2lsbCBub3QgZ2V0IHRoZSBuZWNlc3Nhcnkgc3VwcG9ydA0KPGJyPg0KJmd0OyAmZ3Q7 IGZyb20gdGhlIEVNVSB3b3JraW5nIGdyb3VwIHRvIGdldCB0aGUgY2hhcnRlciBjaGFuZ2VkIGFu ZCB0aGUNCmdyb3VwIDxicj4NCiZndDsgJmd0OyBpbnRlcmVzdGVkIGluIElCRS4gPGJyPg0KJmd0 OyAmZ3Q7IEkgY2FuIHRlbGwgeW91IHRoYXQgSSB3aWxsIG5vdCBzcGVuZCBteSB0aW1lIG9uIGl0 LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE15IHJlYXNvbnMgYXJlIGJlaW5nIGxl c3MgZXhjaXRlZCBhcmU6IDxicj4NCiZndDsgJmd0OyAqIElkZW50aXR5IGJhc2VkIGNyeXB0byBh cyBhIHRlY2hub2xvZ3kgZG9lcyBub3QgcmVhbGx5IHNvbHZlDQphIDxicj4NCiZndDsgJmd0OyBw cm9ibGVtLiAoSW4gY2FzZSB5b3UgYXJlIGdvaW5nIHRvIGFzazogJnF1b3Q7eWVzJnF1b3Q7IEkg bG9va2VkDQppdCBzb21lIHRpbWUgPGJyPg0KJmd0OyAmZ3Q7IGFnbyB3aGVuIEkgdHJpZWQgdG8g ZmlndXJlIG91dCB3aGF0IHZhbHVlIGl0IHByb3ZpZGVzIGZvciBzb21lDQpJRVRGIDxicj4NCiZn dDsgJmd0OyBwcm90b2NvbHMuIEFuZCBndWVzcyB3aGF0IC0gSSBjb3VsZG4ndCBmaW5kIGFueSBi ZW5lZml0cy4pPGJyPg0KJmd0OyAmZ3Q7ICogJnF1b3Q7RVRTSSB3YW50cyBpdCZxdW90OyBpcyBu b3QgYSBnb29kIHJlYXNvbiBmb3IgbWUgdG9kbw0KYW55dGhpbmcuPGJyPg0KJmd0OyAmZ3Q7ICog SSBoYXZlIHNvIG1hbnkgb3RoZXIgZ3JlYXQgZG9jdW1lbnRzIHRvIHJldmlldy4gPGJyPg0KJmd0 OyAmZ3Q7ICogVGhlIElQUiBzaXR1YXRpb24gd2l0aCBpZGVudGl0eSBiYXNlZCBjcnlwdG8gbWFr ZXMgbWUgZmVlbA0KdW5lYXN5LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyBNYXkgSSAmbmJz cDthc2sgZm9yIHRoZSByZWFzb24gd2h5IHlvdSB0aGluayB5b3UgY291bGQgbm90IGZpbmQgYW55 DQo8YnI+DQomZ3Q7IGJlbmVmaXRzIGluIGlkZW50aXR5IGJhc2VkIGNyeXB0b2dyYXBoeT8gPGJy Pg0KJmd0OyBPbmx5IGJlYWNhdXNlIGl0IGhhcyBJUFIgcHJvYmxlbXM/IDxicj4NCiZndDsgVG8g YmUgb2JqZWN0LCAmbmJzcDtpZGVudGl0eSBiYXNlZCBjcnlwdG9ncmFwaHkgaXMgYSBncmVhdCBp ZGVhLCB5b3UNCjxicj4NCiZndDsgZG9uJ3QgaGF2ZSB0byB0cmFuc2ZlciBsb25nIHB1YmxpYyBr ZXksIDxicj4NCiZndDsgYW5kIGNoZWNraW5nIHN0YXR1cyBvZiBwdWJsaWMga2V5cyBmcmVxdWVu dGx5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkc35+fjxicj4NCiZndDsgPGJyPg0KJmd0 OyAtU3VqaW5nIDwvZm9udD48L3R0Pg0K --=_alternative 00042A83482579DD_=-- From hzhou@cisco.com Wed Apr 11 10:15:56 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB011E8094 for ; Wed, 11 Apr 2012 10:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLsVl5QkkIbj for ; Wed, 11 Apr 2012 10:15:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BE11E808D for ; Wed, 11 Apr 2012 10:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=2994; q=dns/txt; s=iport; t=1334164555; x=1335374155; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=5JRgkp7n9NX/Qd1fff10UIO8Hy4+iqW2Dc1LJf0rnbo=; b=CLHk2NUG81mvQX6HcK1bODd53kxiVan33DuNHrEXnxX/FY0KIK5wul0t ekXjhBpvGGCct2+e8qL9vr7Ssj9bbwy+fQ05tv3ddUj52zxpChVmxJ6Ik ZWJYIuz9kQnIM+oEuGGJg8wTJvtsuiZfRmXcx4E1EpOuQCCVA7QglCS9Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisIABq8hU+tJV2Y/2dsb2JhbABEuUwCgQeCCQEBAQMBAQEBDwEnAgExCwUHBgEIDgMEAQEBJy4fCQgCBAENBSKHZwULmwGgJwSRRgSVbI5NgWmDAw X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="73667291" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 11 Apr 2012 17:15:54 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3BHFsB7004831; Wed, 11 Apr 2012 17:15:54 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:15:54 -0500 Received: from 64.101.219.104 ([64.101.219.104]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.63.13]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Apr 2012 17:15:54 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 11 Apr 2012 13:15:49 -0400 From: Hao Zhou To: Jim Schaad , Message-ID: Thread-Topic: [Emu] Multiple Request Action Items Thread-Index: AQJFuiyy3of4oOR+YvL2yoHnnoS9HJWVt85wgA7hU68= In-Reply-To: <046001cd1096$f22df790$d689e6b0$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Apr 2012 17:15:54.0383 (UTC) FILETIME=[C09A71F0:01CD1806] Cc: emu@ietf.org Subject: Re: [Emu] Multiple Request Action Items X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:15:56 -0000 Yes. That would work. If no objections, I can add to the draft. On 4/2/12 2:07 AM, "Jim Schaad" wrote: > Hao, > > The idea that I thought you had presented would not make it a very > complicated item. > > 1. Change the specification so that multiple Request TLVs are permitted to > occur in the TLV sequence. > 2. Change to specification so that the Request TLV item now looks like > M|R|TLV Type | Length | > Status | TLV sequence > > The TLV Sequence is the set of TLV items to be processed for that sequence > code. > > Then need some oddball text to the effect that: > > Two Request TLVs MUST NOT occur in the message if they have the same Status > value. > The order of processing multiple Request TLVs is implementation dependent. > If the server process the optional (non-fatal) items first, it is possible > that the fatal items will disappear at a later time. If the server process > the fatal items first, the communication time will be shorter. > > The client MAY return a new set of Request TLV items after one or more of > the requested items has been processed and the server has signaled it wants > to end the EAP conversation. > > Jim > > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >> Hao Zhou >> Sent: Monday, April 02, 2012 4:29 AM >> To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org >> Cc: emu@ietf.org >> Subject: Re: [Emu] Multiple Request Action Items >> >> Jim: >> >> Good question. The current draft allows for multiple request TLV items, > but >> only says a single Result TLV, indicating the what EAP Success/Failure > result >> the peer would expect if the requested action is not granted. >> >> I can definitely see the need for the case you cited. If we want to extend >> existing design to include individual Result TLVs for the individual > request >> items, we can do that. But I think this might be more complicated and >> unnecessary. Maybe we can use the mandatory bit in the requested TLVs to >> indicate whether ignoring it would cause the failure in the result TLV. >> >> Thoughts? >> >> On 3/30/12 3:34 AM, "Jim Schaad" wrote: >> >>> In the presentation you stated that the plan was to make the TLVs that >>> are requested become a sub TLV of the request TLV items. If that is >>> true, then should it be possible to allow for multiple request TLVs to >>> be present in a message. Thus one could say: >>> Please do A - and if not then fail authentication >>> Please do B - and if not then succeed authentication >>> >>> Jim >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > From zhou.sujing@zte.com.cn Fri Apr 13 02:29:34 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7A21F8644 for ; Fri, 13 Apr 2012 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.53 X-Spam-Level: X-Spam-Status: No, score=-98.53 tagged_above=-999 required=5 tests=[AWL=3.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j70z0TE10-Ee for ; Fri, 13 Apr 2012 02:29:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 59C0721F8628 for ; Fri, 13 Apr 2012 02:29:32 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201794749335; Fri, 13 Apr 2012 16:51:02 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 51191.2827933790; Fri, 13 Apr 2012 17:29:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3D9TH4s026833; Fri, 13 Apr 2012 17:29:17 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 13 Apr 2012 17:29:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-13 17:29:20, Serialize complete at 2012-04-13 17:29:20 Content-Type: multipart/alternative; boundary="=_alternative 003424CC482579DF_=" X-MAIL: mse02.zte.com.cn q3D9TH4s026833 Cc: emu@ietf.org Subject: Re: [Emu] New draft on mutual crypto binding problem X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 09:29:34 -0000 This is a multipart message in MIME format. --=_alternative 003424CC482579DF_= Content-Type: text/plain; charset="US-ASCII" Hi, Sam I have the following questions concerning your new draft on mutual crypto binding 1."What name types are supported and what configuration is easy to perform depends significantly on the peer in question." The issue comes when human beings are involved to verify a certifcate, but if the checking procedure is implemented in software on the peer's side, not verifying or ignoring the server's certificate should not be a problem. 2. Section 3.2.4 "The MSK and EMSK for the tunnel depend on the MSK and EMSK of inner methods." Does it means tunnel method has to support MSK and EMSK? 3. "but MUST NOT prevent an attacker who is unaware of the inner MSK from forcing a bid-down to MSK-based cryptographic binding." Why MUST NOT? Is here a typo? 4. Section 4.2. "Services such as channel binding should be deferred until after cryptographic binding/mutual cryptographic binding." Can't they happen simultaniously to save roundtrips? 5. Can I understand your mutual cryptographic binding as cryptographic binding with MSK replaced by EMSK? If not, what is the difference besides MSK and EMSK? 6. Since tunnel method using mutual cryptographic binding is already quite strong authentication method, what is the use of the inner EAP method? 7. This question might be similar to Question 6, since server authentication by verifying certificate is not considered the unique one, then what else authentication mechnisms can be used? Ones based on password or preshared key? If password or preshared key is used, is it the same credential with the inner EAP method? If the tunnel and inner method share the same credential, then isn't it a bit redundant for two authentication? Why not just upgrade weak EAP method to stronger ones? Since upgrading is unavoidable if we want to protect weak ones with tunnel methods. If the tunnel and inner method have different credential, then simple EAP is becoming more complicated, is it really needed? Regards~~~ -Sujing Zhou --=_alternative 003424CC482579DF_= Content-Type: text/html; charset="US-ASCII"
Hi, Sam
I have the following questions concerning your new draft  on mutual crypto binding

1."What name types are supported and what configuration is easy to perform depends significantly on the peer in question."
The issue comes when human beings are involved to verify a certifcate, but if the checking procedure is implemented in software on the peer's side, not verifying or ignoring the server's
certificate should not be a problem.
 
2. Section 3.2.4 "The MSK and EMSK for the tunnel depend on the MSK and EMSK of
inner methods."
Does it means tunnel method has to support MSK and EMSK?

3. "but MUST NOT prevent an attacker who is unaware of the inner MSK from forcing a bid-down
to MSK-based cryptographic binding."
Why MUST NOT? Is here a typo?

4. Section 4.2. "Services such as channel binding should be deferred until after
cryptographic binding/mutual cryptographic binding."
Can't they happen simultaniously to save roundtrips?

5. Can I understand your mutual cryptographic binding as cryptographic binding with MSK replaced by EMSK?
If not, what is the difference besides MSK and EMSK?

6. Since tunnel method using mutual cryptographic binding is already quite strong authentication method,
what is the use of the inner EAP method?

7. This question might be similar to Question 6, since server authentication by verifying certificate is not considered the unique one,
then what else authentication mechnisms can be used? Ones based on password or preshared key?
If password or preshared key is used, is it the same credential with the inner EAP method?
If the tunnel and inner method share the same credential, then isn't it a bit redundant for two authentication?
Why not just upgrade weak EAP method to stronger ones? Since upgrading is unavoidable if we want to protect weak ones with tunnel methods.
If the tunnel and inner method have different credential, then simple EAP is becoming more complicated, is it really needed?  


Regards~~~

-Sujing Zhou --=_alternative 003424CC482579DF_=-- From zhou.sujing@zte.com.cn Tue Apr 17 02:52:09 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BBF21F8533 for ; Tue, 17 Apr 2012 02:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.537 X-Spam-Level: X-Spam-Status: No, score=-94.537 tagged_above=-999 required=5 tests=[AWL=2.348, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTltlTmKnw5E for ; Tue, 17 Apr 2012 02:52:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 644C621F84D0 for ; Tue, 17 Apr 2012 02:52:08 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 621291794749335; Tue, 17 Apr 2012 17:51:15 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.2827933790; Tue, 17 Apr 2012 17:52:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3H9pve6045008; Tue, 17 Apr 2012 17:51:58 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: hartmans-ietf@mit.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 17 Apr 2012 17:51:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-17 17:51:59, Serialize complete at 2012-04-17 17:51:59 Content-Type: multipart/alternative; boundary="=_alternative 003638C0482579E3_=" X-MAIL: mse01.zte.com.cn q3H9pve6045008 Cc: emu@ietf.org Subject: [Emu] on draft-hartman-emu-mutual-crypto-bind-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:52:09 -0000 This is a multipart message in MIME format. --=_alternative 003638C0482579E3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SW4gU2VjdGlvbiAyIGRyYWZ0LWhhcnRtYW4tZW11LW11dHVhbC1jcnlwdG8tYmluZC0wMKOsDQoi VGhlIHByaW50IHNlcnZlciBvZmZlcnMgYSB0dW5uZWwgbWV0aG9kIHRvd2FyZHMgdGhlIHBlZXIu IFRoZSBwcmludA0KICAgc2VydmVyIGV4dHJhY3RzIHRoZSBpbm5lciBtZXRob2QgZnJvbSB0aGUg dHVubmVsIGFuZCBzZW5kcyBpdCBvbg0KICAgdG93YXJkcyB0aGUgQUFBIHNlcnZlci4gIENoYW5u ZWwgYmluZGluZyBoYXBwZW5zIGF0IHRoZSB0dW5uZWwgbWV0aG9kDQogICB0aG91Z2guICBTbywg dGhlIHByaW50IHNlcnZlciBpcyBoYXBweSB0byBjb25maXJtIHRoYXQgaXQgaXMgdGhlDQogICBm aW5hbmNpYWwgYXBwbGljYXRpb24uICBBZnRlciB0aGUgaW5uZXIgbWV0aG9kIGNvbXBsZXRlcywg dGhlIEVBUA0KICAgc2VydmVyIHNlbmRzIHRoZSBNU0sgdG8gdGhlIHByaW50IHNlcnZlciBvdmVy IHRoZSBBQUEgcHJvdG9jb2wuICBJZg0KICAgb25seSB0aGUgTVNLIGlzIG5lZWRlZCBmb3IgY3J5 cHRvZ3JhcGhpYyBiaW5kaW5nIHRoZW4gdGhlIHByaW50DQogICBzZXJ2ZXIgY2FuIHN1Y2Nlc3Nm dWxseSBwZXJmb3JtIGNyeXB0b2dyYXBoaWMgYmluZGluZyBhbmQgbWF5IGJlIGFibGUNCiAgIHRv IGltcGVyc29uYXRlIHRoZSBmaW5hbmNpYWwgYXBwbGljYXRpb24gdG8gdGhlIHBlZXIuIg0KDQpU aGUgcHJpbnQgc2VydmVyIG9mZmVycyBhIHR1bm5lbCBtZXRob2QgdG93YXJkcyB0aGUgcGVlciwg YW5kIGNoYW5uZWwgDQpiaW5kaW5nIGlzIGFkb3B0ZWQuIA0KDQpBY2NvcmRpbmcgdG8gc2VjdGlv biA0LjIgaW4gZHJhZnQtaWV0Zi1lbXUtY2hiaW5kLTE0LA0KIlRoZSBjaGFubmVsIGJpbmRpbmdz IE1VU1QgYmUgdHJhbnNwb3J0ZWQgd2l0aCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiAgYmFzZWQgDQpv biBhIGtleSBrbm93biBvbmx5IHRvIHRoZSBwZWVyIGFuZCBFQVAgc2VydmVyLiINCnNlY3Rpb24g NiBpbiBkcmFmdC1pZXRmLWVtdS1jaGJpbmQtMTSjug0KIlRoZSBjaGFubmVsIGJpbmRpbmcgcHJv dG9jb2wgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IG11c3QgYmUgdHJhbnNwb3J0ZWQgDQphZnRl ciBrZXlpbmcgbWF0ZXJpYWwgaGFzIGJlZW4gZGVyaXZlZCBiZXR3ZWVuIHRoZSBFQVANCnBlZXIg YW5kIHNlcnZlciwgYW5kIGJlZm9yZSB0aGUgcGVlciB3b3VsZCBzdWZmZXIgYWR2ZXJzZSBhZmZl Y3RzIGZyb20gDQpqb2luaW5nIGFuIGFkdmVyc2FyaWFsIG5ldHdvcmsuIg0KDQpUbyBteSB1bmRl cnN0YW5kaW5nLCByaWdodCBwcmlvciB0byBmaW5pc2hpbmcgdHVubmVsIGVzdGFibGlzaGVtZW50 LCBFQVAgDQpwZWVyIGFuZCBFQVAgU2VydmVyKHByaW50IHNlcnZlciBpbiB0aGUgc2VydmVyIGlu c2VydGlvbiBhdHRhY2sgY2FzZSkgDQpzaG91bGQgaGF2ZQ0KZXhjaGFuZ2VkIGNoYW5uZWwgYmlu ZGluZyB3aXRoIGludGVncml0eSBwcm90ZWN0aW9uIGJ5IGtleSBvbmx5IGtub3duIHRvIA0KRUFQ IHBlZXIgYW5kIEVBUCBzZXJ2ZXIgKE1TSyBpbiB0aGlzIGNhc2UpLA0KYnV0IHByaW50IHNlcnZl ciBkb2VzIG5vdCBrbm93IE1TSyB5ZXQsIHNvIGNoYW5uZWwgYmluZGluZyBjb3VsZCBub3QgcGFz cyANCnZlcmlmaWNhdGlvbiBieSBFQVAgcGVlciwgdGhlbiANCnBlZXIgc2hvdWxkIG5vdCBjb250 aW51ZSB3aXRoIHRoZSBpbm5lciBtZXRob2QsIGFuZCBwcmludCBzZXJ2ZXIgY2hvdWxkIA0Kbm90 IHVzZSBub24tdHVubmVsZWQgaW5uZGVyIG1ldGhvZCB3aXRob3V0IGNvb3BlcmF0aW9uIG9mIHBl ZXIsDQphbmQgcHJpbnQgc2VydmVyIGNob3VsZCBub3QgZ2V0IE1TSyBmcm9tIEVBUCBTZXJ2ZXIs IGFuZCBzZXJ2ZXIgaW5zZXJ0aW9uIA0KYXR0YWNrIGZhaWxzIGV2ZW4gdGhvdWdoIHBlZXIgZG9l cyBub3QgY2hlY2sgcHJpbnQgc2VydmVyIG9yIEVBUCBzZXJ2ZXIncyANCmNlcnQuDQoNCkhhdmUg SSBtaXNzZWQgc29tZXRoaW5nPyANCg0KUmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KDQo= --=_alternative 003638C0482579E3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIFNlY3Rpb24gMiBkcmFmdC1o YXJ0bWFuLWVtdS1tdXR1YWwtY3J5cHRvLWJpbmQtMDCjrDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7VGhlIHByaW50IHNlcnZlciBvZmZlcnMgYSB0dW5u ZWwNCm1ldGhvZCB0b3dhcmRzIHRoZSBwZWVyLiBUaGUgcHJpbnQ8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtzZXJ2ZXIgZXh0cmFjdHMgdGhl IGlubmVyDQptZXRob2QgZnJvbSB0aGUgdHVubmVsIGFuZCBzZW5kcyBpdCBvbjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3Rvd2FyZHMgdGhl IEFBQSBzZXJ2ZXIuDQombmJzcDtDaGFubmVsIGJpbmRpbmcgaGFwcGVucyBhdCB0aGUgdHVubmVs IG1ldGhvZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO3Rob3VnaC4gJm5ic3A7U28sIHRoZSBwcmludA0Kc2VydmVyIGlzIGhhcHB5IHRvIGNv bmZpcm0gdGhhdCBpdCBpcyB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtmaW5hbmNpYWwgYXBwbGljYXRpb24uDQombmJzcDtBZnRlciB0 aGUgaW5uZXIgbWV0aG9kIGNvbXBsZXRlcywgdGhlIEVBUDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NlcnZlciBzZW5kcyB0aGUgTVNLIHRv DQp0aGUgcHJpbnQgc2VydmVyIG92ZXIgdGhlIEFBQSBwcm90b2NvbC4gJm5ic3A7SWY8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtvbmx5IHRo ZSBNU0sgaXMgbmVlZGVkDQpmb3IgY3J5cHRvZ3JhcGhpYyBiaW5kaW5nIHRoZW4gdGhlIHByaW50 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 c2VydmVyIGNhbiBzdWNjZXNzZnVsbHkNCnBlcmZvcm0gY3J5cHRvZ3JhcGhpYyBiaW5kaW5nIGFu ZCBtYXkgYmUgYWJsZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO3RvIGltcGVyc29uYXRlIHRoZSBmaW5hbmNpYWwNCmFwcGxpY2F0aW9uIHRv IHRoZSBwZWVyLiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VGhlIHByaW50IHNlcnZlciBvZmZlcnMgYSB0dW5uZWwgbWV0aG9kDQp0b3dhcmRz IHRoZSBwZWVyLCBhbmQgY2hhbm5lbCBiaW5kaW5nIGlzIGFkb3B0ZWQuIDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIHNlY3Rpb24g NC4yIGluIGRyYWZ0LWlldGYtZW11LWNoYmluZC0xNCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1RoZSBjaGFubmVsIGJpbmRpbmdzIE1VU1QgYmUgdHJh bnNwb3J0ZWQNCndpdGggaW50ZWdyaXR5IHByb3RlY3Rpb24gJm5ic3A7YmFzZWQgb24gYSBrZXkg a25vd24gb25seSB0byB0aGUgcGVlciBhbmQNCkVBUCBzZXJ2ZXIuJnF1b3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWN0aW9uIDYgaW4gZHJhZnQtaWV0Zi1l bXUtY2hiaW5kLTE0o7o8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90O1RoZSBjaGFubmVsIGJpbmRpbmcgcHJvdG9jb2wgZGVmaW5lZA0KaW4gdGhpcyBkb2N1 bWVudCBtdXN0IGJlIHRyYW5zcG9ydGVkIGFmdGVyIGtleWluZyBtYXRlcmlhbCBoYXMgYmVlbiBk ZXJpdmVkDQpiZXR3ZWVuIHRoZSBFQVA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPnBlZXIgYW5kIHNlcnZlciwgYW5kIGJlZm9yZSB0aGUgcGVlcg0Kd291bGQgc3Vm ZmVyIGFkdmVyc2UgYWZmZWN0cyBmcm9tIGpvaW5pbmcgYW4gYWR2ZXJzYXJpYWwgbmV0d29yay4m cXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRv IG15IHVuZGVyc3RhbmRpbmcsIHJpZ2h0IHByaW9yIHRvDQpmaW5pc2hpbmcgdHVubmVsIGVzdGFi bGlzaGVtZW50LCBFQVAgcGVlciBhbmQgRUFQIFNlcnZlcihwcmludCBzZXJ2ZXIgaW4NCnRoZSBz ZXJ2ZXIgaW5zZXJ0aW9uIGF0dGFjayBjYXNlKSBzaG91bGQgaGF2ZTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZXhjaGFuZ2VkIGNoYW5uZWwgYmluZGluZyB3aXRo IGludGVncml0eQ0KcHJvdGVjdGlvbiBieSBrZXkgb25seSBrbm93biB0byBFQVAgcGVlciBhbmQg RUFQIHNlcnZlciAoTVNLIGluIHRoaXMgY2FzZSksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5idXQgcHJpbnQgc2VydmVyIGRvZXMgbm90IGtub3cgTVNLIHlldCwN CnNvIGNoYW5uZWwgYmluZGluZyBjb3VsZCBub3QgcGFzcyB2ZXJpZmljYXRpb24gYnkgRUFQIHBl ZXIsIHRoZW4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5wZWVy IHNob3VsZCBub3QgY29udGludWUgd2l0aCB0aGUgaW5uZXINCm1ldGhvZCwgYW5kIHByaW50IHNl cnZlciBjaG91bGQgbm90IHVzZSBub24tdHVubmVsZWQgaW5uZGVyIG1ldGhvZCB3aXRob3V0DQpj b29wZXJhdGlvbiBvZiBwZWVyLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+YW5kIHByaW50IHNlcnZlciBjaG91bGQgbm90IGdldCBNU0sNCmZyb20gRUFQIFNlcnZl ciwgYW5kIHNlcnZlciBpbnNlcnRpb24gYXR0YWNrIGZhaWxzIGV2ZW4gdGhvdWdoIHBlZXIgZG9l cw0Kbm90IGNoZWNrIHByaW50IHNlcnZlciBvciBFQVAgc2VydmVyJ3MgY2VydC48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhhdmUgSSBtaXNzZWQgc29t ZXRoaW5nPyAmbmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amluZyBaaG91PC9mb250Pg0KPGJyPg0K PGJyPg0K --=_alternative 003638C0482579E3_=-- From ietf@augustcellars.com Wed Apr 18 13:02:57 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DA311E809D; Wed, 18 Apr 2012 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1ak0od+6MjK; Wed, 18 Apr 2012 13:02:53 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23311E80A4; Wed, 18 Apr 2012 13:02:53 -0700 (PDT) Received: from Tobias (50-54-163-224.evrt.wa.frontiernet.net [50.54.163.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0C37438F1D; Wed, 18 Apr 2012 13:02:52 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 18 Apr 2012 13:01:58 -0700 Message-ID: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0dnMTcJAXpzyj2TqGISxbEO8pbog== Content-Language: en-us Cc: abfab@ietf.org Subject: [Emu] Delegation X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:02:57 -0000 In the Plasma work effort we have spent much of the last month thinking about and doing some discussions on the question of delegated access. In the process we have located the following SAML document http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cs-01. pdf which discusses how to create a SAML statement which has the delegation information built in. This gives us what we need in order to do the evaluation on the RP about what delegation has occurred. The problem is that there is currently no way to discuss the questions of delegation in the EAP protocols that I know of. This has not been a problem when we were looking at just the question of accessing a network; however the additional resources that we are now looking at because of ABFAB are now starting to make this an interesting question to looking at. The questions that I would have for the EMU group are: 1. Is there any interest in looking at the issues of how one requests a delegated access to occur? 2. What set of restrictions are going to be necessary for doing delegation. At present, since the only cases that I care about are going to be the ABFAB cases all I would actually need to the ability to say in one of the tunneled messages a simple statement to the effect that "I want delegate access to " which would either be granted or denied. 3. If we do delegated access, what things other than the SAML statement returned in the ABFAB context need to be changed? 4. Do we need to be able to do both delegation, where the delegation process is understood by the RP, and impersonation where the RP may not be able to tell that the authenticated entity is not really the same as the named entity returned to the RP from the IdP. 5. Are there other issues that need to be discussed? Jim From hartmans@mit.edu Mon Apr 30 12:36:38 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2821F8835 for ; Mon, 30 Apr 2012 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEofMzXcCuPs for ; Mon, 30 Apr 2012 12:36:37 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC321F87DC for ; Mon, 30 Apr 2012 12:36:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1EB9F2058F; Mon, 30 Apr 2012 15:32:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1930F4769; Mon, 30 Apr 2012 15:36:22 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Mon, 30 Apr 2012 15:36:22 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] draft-ietf-emu-chbind and username X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:36:38 -0000 Steve Hanna did a secdir review of draft-ietf-emu-chbind. One of the issues he raised is a privacy concern with section 8. He points out that we recommend using the user-name attribute in channel binding. The concern is that if a server checks user-name in i2 against user-name in i1, then a NAS might be able to get an EAP server to act as an oracle for privacy protected identities. That is: 1) Peer identifies to NAS as @example.com 2) NAS thinks peer might actually be bob@example.com. 3) NAS tries that in user-name. 4) If it's not bob@example.com then channel binding fails. He suggested documenting this issue. I'd like to take a step back and ask why you'd ever want to channel-bind user-name in the first place? I guess the theory is that your EAP method supports channel binding but does not have a well-defined concept of peer ID or support identity protection/transporting method-specific identity? My proposal is that we stop recommending channel binding to user-name rather than documenting the issues associated with doing so. --Sam