From nobody Wed Oct 1 08:41:30 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B7D1ACE63 for ; Wed, 1 Oct 2014 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrf1VjGyA-bc for ; Wed, 1 Oct 2014 08:41:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CA61ACE6A for ; Wed, 1 Oct 2014 08:41:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNF31087; Wed, 01 Oct 2014 15:41:25 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Wed, 1 Oct 2014 16:40:31 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: revised version of secauth charter - Please review Thread-Index: Ac/djgfzZhiXZ1TITpqnm+SGqbtDig== Date: Wed, 1 Oct 2014 15:40:31 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A45596@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/jg2K61Y7Yl4PHPalSknW4IsUxKI Subject: [Secauth] revised version of secauth charter - Please review X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:41:29 -0000 Folks, After offlist discussion with Joel. He had a lot of helpful suggestions to = improve the scope of this charter. Please take your time and have a look on the proposed charter. Tell me what you think and how better to go further. I appreciate any inputs to the list either editorial, technical or question= s. Thanks, Best, Hosnieh ---------------------------------------------------------------------- Proposed charter and the working items of secauth ------------------------------------------------------------------------ There are various authentication and authorization mechanisms in use today.= Some supports only particular devices, for instance, only available for co= nstrained devices. Some others support the nodes with rich resources (CPU, = memory, etc.). However, providing trust during the establishment of the com= munication is usually out of the scope of the existing security protocols. = This is why there is usually a big gap that demands some to many manual con= figurations to provide a node with a secure authentication/authorization. A= utomating the establishment of this communication as much as possible, prov= iding user/device authentication and authorization, minimizing the need of = human interaction and be able to assist other protocols to decrease the sec= urity gap in first point of trust is what secauth aim to address. =20 Furthermore, secauth aims to remove the need of CAs and/or installation/con= figuration of any TA infrastructure for authentication and authorization. A= lthough, if only domain names are in use, secauth need to use a DNS server = to translate these names to their IP addresses. There are two scenarios her= e: [1] a node can trust the network where it is connected in order to receive = the IP address of a DNS server. This scenario is only when a node can recei= ve the IP address of a resolver from secure Router Advertisement (RA) or th= ere is any switch-based security available. The scope of secauth here is to securely authenticate the DNS resolver and = to securely authenticate an application or a device. [2] a node cannot trust the network. The finger print of a DNS server needs= to be set in the node manually as explained in http://tools.ietf.org/html/= draft-rafiee-intarea-cga-tsig . This manual step is out of scope of secauth= . After this step, like what explained in last scenario, secauth can verify= the DNS resolver and securely authenticate an application or a device.=20 If the communication is only IP based and a node uses a valid IP address.=20 - In IPv6, dissimilar to [1] and [2], secauth can automate the whole proces= s without any configuration.=20 - In IPv4, this is similar to [1] and [2]. =20 Secauth is not dependent to any IP based solution. However, when a node sup= ports a valid global IP address, secauth does not need to receive any infor= mation from DNS.=20 Summary of the scope of secauth ------------------------------------ - It is not dependent to an IP based solution. - It depends on a secure solution on a switch or a secure RA for full autom= ation as explained in [1]. Unless, it depends on a manual configuration [2]= . - It removes the requirement for the use of a CA - It depends on a DNS server to translate names to IP addresses but it can = securely handle this process. - The configuration of DNS server is out of scope of secauth.=20 - The configuration of switches or providing secure RA is out of scope of s= ecauth =20 The tasks of this group includes: ------------------------------------ 1) Produce problem statement, requirements and use cases 2) Identify the design and architecture for providing first point of trust = and reduce the security gap as much as possible and consider confidentialit= y for this solution 3) Identify the existing protocols that needs this interoperation 4) Identify the light cryptographic approaches that can be used for authent= ication and authorization purposes From nobody Mon Oct 6 06:34:50 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F891A6F6B for ; Mon, 6 Oct 2014 06:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4jSbsek_H-q for ; Mon, 6 Oct 2014 06:34:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97081A6F42 for ; Mon, 6 Oct 2014 06:34:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKG59571; Mon, 06 Oct 2014 13:34:35 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 6 Oct 2014 14:34:30 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Summerize charter? any other inputs? Thread-Index: Ac/hakFR/2W51+OHSJKwVCCgxXX2gA== Date: Mon, 6 Oct 2014 13:34:30 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A46546@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/xmpqT6_RzN3ods0Dcmz7c9WIc1A Subject: [Secauth] Summerize charter? any other inputs? X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:34:49 -0000 Folks, Any new inputs on the charter or requirement documents? I would like to sum= marize the charter so please if you haven't yet take a look on it, please d= o it and share your inputs to the list (not only me please) Thank you, Best, Hosnieh From nobody Thu Oct 9 03:48:24 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16771ACD4A; Thu, 9 Oct 2014 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-Ss90QZAcLw; Thu, 9 Oct 2014 03:48:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0075A1ACD3F; Thu, 9 Oct 2014 03:48:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNL74014; Thu, 09 Oct 2014 10:48:17 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 11:48:16 +0100 From: Hosnieh Rafiee To: "ace@ietf.org" Thread-Topic: some suggestions - clarification of ACE scope and secauth Thread-Index: AQHP466Hjbmt+uEqAkuKiz5ogU7rww== Date: Thu, 9 Oct 2014 10:48:15 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/juovacihWWIU1P4a8ST1UKleT_Y Cc: "secauth@ietf.org" Subject: [Secauth] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 10:48:20 -0000 SGksDQoNCkluIHNlY2F1dGggcmVxdWlyZW1lbnQgZHJhZnQsIHRoZXJlIGlzIHR3byByZXF1aXJl bWVudHMgdGhhdCBJIHN1Z2dlc3QgdG8gYmUgY29uc2lkZXJlZCBieSBBQ0UgaG93ZXZlciwgSWYg QUNFIGRvZXMgbm90IHdhbnQgdG8gd29yayBvbiB0aGVtLCAgSSB3aWxsIGtlZXAgaXQgaW4gc2Vj YXV0aC4NCg0KSGVyZSBpcyB0aGUgbGluayB0byBzZWNhdXRoIHJlcXVpcmVtZW50IGRyYWZ0Lg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhZmllZS1zZWNhdXRoLXVzZWNhc2Ut MDEgDQoNCg0KICAgU2NlbmFyaW8gMjogQWxpY2UncyB3YXNoIG1hY2hpbmUgdGVjaG5pY2FsbHkg aGFzIGEgcHJvYmxlbS4gSXRzDQogICBhcHBsaWNhdGlvbiB3YXMgY29uZmlndXJlZCBieSB0aGUg dmVuZG9ycz8gaW4gYSB3YXkgdG8gcmVwb3J0IHRoaXMNCiAgIHByb2JsZW0gYXV0b21hdGljYWxs eSB0byB0aGlyZCBwYXJ0eSB0ZWNobmljYWwgc2VydmljZSAocmVwYWlyDQogICBwbGFjZSkuIEJv dGggdGhlIHRlY2huaWNhbCBzZXJ2aWNlIGFwcGxpY2F0aW9uIGFuZCB3YXNoIG1hY2hpbmUgbmVl ZA0KICAgdG8gYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgc28gdGhhdCB0aGV5IGNhbiB0cnVzdCBh bmQgZXhjaGFuZ2UNCiAgIGluZm9ybWF0aW9uLiBTaW5jZSB0aGUgYXBwbGljYXRpb24gYXJlIHVz dWFsbHkgaW1wbGVtZW50ZWQgYnkgdGhlDQogICB0aGlyZCBwYXJ0eSBhbmQgdGhlcmUgd2FzIG5v dCBtdWNoIGVmZm9ydCB0byBzZWN1cmUgdGhlDQogICBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHRo ZSBkZXZpY2UgYW5kIHRoZSBhcHBsaWNhdGlvbiwgdGhlIHNlY3VyaXR5DQogICBvZiB0aGVtIGlz IGEgYmlnIGNvbmNlcm4uDQoNCkFsaWNlIHR1cm5lZCBvbiB0aGUgd2FzaCBtYWNoaW5lIGF0IGhv bWUgYW5kIHRoZW4gd2VudCB0byB3b3JrLiBBbGljZQ0KICAgY2FuIGNoZWNrIHRoZSBzdGF0dXMg b2YgdGhpcyB3YXNoIG1hY2hpbmUgdXNpbmcgYW4gYXBwbGljYXRpb24gb24gaGVyDQogICBTbWFy dHBob25lIHJlbW90ZWx5IGF0IGNvbXBhbnkgeC4gV2FzaCBtYWNoaW5lIGRvZXNuJ3Qgc3VwcG9y dCBhbnkNCiAgIGNlcnRpZmljYXRlcyBzaWduZWQgYnkgYSBDQS4gQWxpY2UgbmVlZHMgdG8gYmUg YXV0aGVudGljYXRlZCBpbiB0aGUNCiAgIHdhc2ggbWFjaGluZSBhbmQgd2FzaCBtYWNoaW5lIG5l ZWRzIHRvIHRydXN0IEFsaWNlIHRvIGFsbG93IGhlcg0KICAgY29udHJvbCBpdCByZW1vdGVseS4g U2luY2UgdGhlIGFwcGxpY2F0aW9uIGFyZSB1c3VhbGx5IHByb3ZpZGVkIGJ5DQogICB0aGlyZCBw YXJ0aWVzLCB0aGUgc2VjdXJpdHkgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIGltcG9ydGFudCBh bmQNCiAgIHRoZSBmaXJzdCBwb2ludCBvZiB0cnVzdCBpcyByZWFsbHkgaW1wb3J0YW50Lg0KDQpU aGFua3MsDQpCZXN0LA0KSG9zbmllaA0K From nobody Thu Oct 9 03:50:40 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795F51ACD45; Thu, 9 Oct 2014 03:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCQTZzG8gYdC; Thu, 9 Oct 2014 03:50:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369AC1ACD4B; Thu, 9 Oct 2014 03:50:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNL74237; Thu, 09 Oct 2014 10:50:29 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 11:50:28 +0100 From: Hosnieh Rafiee To: "ace@ietf.org" Thread-Topic: Correction: some suggestions - clarification of ACE scope and secauth Thread-Index: AQHP467W3DWWuTjMsECZBwmlAyg4rA== Date: Thu, 9 Oct 2014 10:50:27 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A47526@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/7fPSyT5F9QH3t3238qTYYDkfCuY Cc: "secauth@ietf.org" Subject: [Secauth] Correction: some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 10:50:36 -0000 Rm9sbG93IHVwOg0KUmVxdWlyZW1lbnQgLT4gdXNlIGNhc2VzDQo= From nobody Fri Oct 10 02:58:51 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BAB1A87B9; Fri, 10 Oct 2014 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD2cv8XRlSju; Fri, 10 Oct 2014 02:58:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BCC1A87B3; Fri, 10 Oct 2014 02:58:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNM67938; Fri, 10 Oct 2014 09:58:36 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 10:58:31 +0100 From: Hosnieh Rafiee To: Stefanie Gerdes , "ace@ietf.org" Thread-Topic: [Ace] some suggestions - clarification of ACE scope and secauth Thread-Index: AQHP466Hjbmt+uEqAkuKiz5ogU7rw5wo9Z+AgAARRzA= Date: Fri, 10 Oct 2014 09:58:31 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A47A47@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <54379D37.6060609@tzi.de> In-Reply-To: <54379D37.6060609@tzi.de> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Etocr4n9v2HwpSEMcGMn3SScKWU Cc: "secauth@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 09:58:48 -0000 Hi Stefanie, Thanks for your message. My responses inline >=20 > Thank you for your suggestions. I am not sure if I completely > understand which part of your scenario you want us to integrate into > the use cases document. Some questions inline. Just these two use cases that I explicitly included in my message. Because = Kathleen reviewed secauth requirement and one of her question about these u= se cases that it might be covered by ACE.=20 > > Scenario 2: Alice's wash machine technically has a problem. Its > > application was configured by the vendors? in a way to report this > > problem automatically to third party technical service (repair > > place). Both the technical service application and wash machine > need > > to authenticate each other so that they can trust and exchange > > information. >=20 > Why does the washing machine contact the repair service and not Alice > herself? She would have to make an appointment with them anyway if the > machine is broken. This is based on an article I read about "talking home devices and privacy = and security concerns. This article was based on researches of one of the = owner of new smart wash machines who was concerned about the information se= nt back and forth by wash machine to x locations. In that article it also e= xplained the ability of a smart wash machine that sends its problems to rep= air service centers automatically and explains the remaining concerns about= the security of such applications since the producers only outsource them = without much supervision on their security.=20 The scenario which you explained is a bit different (only the end point is = different) however, IMO, the security of that can be considered in a same w= ay. =20 > > Since the application are usually implemented by the > > third party and there was not much effort to secure the > > communications between the device and the application, the > security > > of them is a big concern. > > > > Alice turned on the wash machine at home and then went to work. Alice > > can check the status of this wash machine using an application on > her > > Smartphone remotely at company x. Wash machine doesn't support any > > certificates signed by a CA. Alice needs to be authenticated in > the > > wash machine and wash machine needs to trust Alice to allow her > > control it remotely. Since the application are usually provided by > > third parties, the security of this communication is important and > > the first point of trust is really important. >=20 >=20 > Which authorization problem do you want to solve here? Please have a > look at section 2.2.1. in [1]. Do you want to address an authorization > problem that is not already covered here? >=20 I checked ACE use case section 2.2.1. It appears that the use case only con= sidered authorization and not authentication. So it seems that it presumed = the authentication of Jane have already done and Jane only needs to authori= ze Jeffery to access some resources. I have a question for you. I haven't read the new version of OAuth document= s but such authorization scenarios might already considered by Oauth. Maybe= it is good to check with them if it wasn't done before.=20 Thanks, Best, Hosnieh From nobody Fri Oct 10 03:23:08 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8731A6F7D; Fri, 10 Oct 2014 01:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCAmgD9wht_N; Fri, 10 Oct 2014 01:48:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6CE1A6FB9; Fri, 10 Oct 2014 01:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9A8ltZC023878; Fri, 10 Oct 2014 10:47:56 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B2CA293; Fri, 10 Oct 2014 10:47:55 +0200 (CEST) Message-ID: <54379D37.6060609@tzi.de> Date: Fri, 10 Oct 2014 10:47:51 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hosnieh Rafiee , "ace@ietf.org" References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/e-aRJiNcGj5DdFsuB-IrrK4f8aI X-Mailman-Approved-At: Fri, 10 Oct 2014 03:23:05 -0700 Cc: "secauth@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 08:48:36 -0000 Hi Hosnieh, Thank you for your suggestions. I am not sure if I completely understand which part of your scenario you want us to integrate into the use cases document. Some questions inline. On 10/09/2014 12:48 PM, Hosnieh Rafiee wrote: > Hi, > > In secauth requirement draft, there is two requirements that I suggest to be considered by ACE however, If ACE does not want to work on them, I will keep it in secauth. > > Here is the link to secauth requirement draft. > https://tools.ietf.org/html/draft-rafiee-secauth-usecase-01 > > > Scenario 2: Alice's wash machine technically has a problem. Its > application was configured by the vendors? in a way to report this > problem automatically to third party technical service (repair > place). Both the technical service application and wash machine need > to authenticate each other so that they can trust and exchange > information. Why does the washing machine contact the repair service and not Alice herself? She would have to make an appointment with them anyway if the machine is broken. > Since the application are usually implemented by the > third party and there was not much effort to secure the > communications between the device and the application, the security > of them is a big concern. > > Alice turned on the wash machine at home and then went to work. Alice > can check the status of this wash machine using an application on her > Smartphone remotely at company x. Wash machine doesn't support any > certificates signed by a CA. Alice needs to be authenticated in the > wash machine and wash machine needs to trust Alice to allow her > control it remotely. Since the application are usually provided by > third parties, the security of this communication is important and > the first point of trust is really important. Which authorization problem do you want to solve here? Please have a look at section 2.2.1. in [1]. Do you want to address an authorization problem that is not already covered here? Thanks, Steffi From nobody Fri Oct 10 03:23:26 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516101A6FE5; Fri, 10 Oct 2014 01:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmKl-Y_pblT6; Fri, 10 Oct 2014 01:51:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A731A6FA9; Fri, 10 Oct 2014 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9A8opgV002656; Fri, 10 Oct 2014 10:50:51 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 68D4096; Fri, 10 Oct 2014 10:50:51 +0200 (CEST) Message-ID: <54379DEB.6070303@tzi.de> Date: Fri, 10 Oct 2014 10:50:51 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hosnieh Rafiee , "ace@ietf.org" References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <54379D37.6060609@tzi.de> In-Reply-To: <54379D37.6060609@tzi.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/kw9iwzkQQdMAnL0PE5YtWkkesZg X-Mailman-Approved-At: Fri, 10 Oct 2014 03:23:23 -0700 Cc: "secauth@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 08:51:07 -0000 [1] https://tools.ietf.org/id/draft-seitz-ace-usecases-01.txt On 10/10/2014 10:47 AM, Stefanie Gerdes wrote: > Hi Hosnieh, > > Thank you for your suggestions. I am not sure if I completely understand > which part of your scenario you want us to integrate into the use cases > document. Some questions inline. > > On 10/09/2014 12:48 PM, Hosnieh Rafiee wrote: >> Hi, >> >> In secauth requirement draft, there is two requirements that I suggest to be considered by ACE however, If ACE does not want to work on them, I will keep it in secauth. >> >> Here is the link to secauth requirement draft. >> https://tools.ietf.org/html/draft-rafiee-secauth-usecase-01 >> >> >> Scenario 2: Alice's wash machine technically has a problem. Its >> application was configured by the vendors? in a way to report this >> problem automatically to third party technical service (repair >> place). Both the technical service application and wash machine need >> to authenticate each other so that they can trust and exchange >> information. > > Why does the washing machine contact the repair service and not Alice > herself? She would have to make an appointment with them anyway if the > machine is broken. > >> Since the application are usually implemented by the >> third party and there was not much effort to secure the >> communications between the device and the application, the security >> of them is a big concern. >> >> Alice turned on the wash machine at home and then went to work. Alice >> can check the status of this wash machine using an application on her >> Smartphone remotely at company x. Wash machine doesn't support any >> certificates signed by a CA. Alice needs to be authenticated in the >> wash machine and wash machine needs to trust Alice to allow her >> control it remotely. Since the application are usually provided by >> third parties, the security of this communication is important and >> the first point of trust is really important. > > > Which authorization problem do you want to solve here? Please have a > look at section 2.2.1. in [1]. Do you want to address an authorization > problem that is not already covered here? > > Thanks, > Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Mon Oct 13 07:17:10 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920E41A0004; Mon, 13 Oct 2014 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaVxpLyMRE_I; Mon, 13 Oct 2014 07:16:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B62F1A002F; Mon, 13 Oct 2014 07:16:21 -0700 (PDT) Received: from [192.168.10.188] ([195.50.187.121]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MF4eJ-1XNSzT2wQN-00GK5m; Mon, 13 Oct 2014 16:16:16 +0200 Message-ID: <543BDEAA.1000701@gmx.net> Date: Mon, 13 Oct 2014 16:16:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Hosnieh Rafiee , "ace@ietf.org" References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IhAn8r5Lm9LQbQExhWceP0pdRSW8Cv9mG" X-Provags-ID: V03:K0:jkRMInZ/xHVhsLcp+ew2kV8t0AmF+CTfvNo+ZDVnM3eGWUxwdd9 n4hd0n0DuRJzxIadeX9N+PEECXLZ1RMidkagkynxnIvK3vhOg99wgWJubBCEcXT/0zdEV/X Bn/qQ+78eeE87lnoZZ5HTPtd9Gg6Epb3qc4QPMKZXsEYBjQ/A8KeuJZZFY4ChYlv2WicEIn wBNLZzYit7od3nX2LYXbg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/a1EfVLLsMeQGhPS0o8WCtORY7tc Cc: "secauth@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:17:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IhAn8r5Lm9LQbQExhWceP0pdRSW8Cv9mG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, the scenarios fall into the scope of ACE if at least the resource server is constrained. If the washing machine just talks to some cloud-based infrastructure then that's not really of interest to ACE. If there is, however, a technician standing next to the washing machine and wants to retrieve information from the washing machine using his mobile phone or tablet directly then the washing machine becomes the resource server. To me it appears (from our earlier discussion about the scenarios) that you envision some interaction with a server-side infrastructure. If that's the case then you should be able to solve these use cases with the already existing standards we have developed. Ciao Hannes On 10/09/2014 12:48 PM, Hosnieh Rafiee wrote: > Hi, >=20 > In secauth requirement draft, there is two requirements that I suggest = to be considered by ACE however, If ACE does not want to work on them, I= will keep it in secauth. >=20 > Here is the link to secauth requirement draft. > https://tools.ietf.org/html/draft-rafiee-secauth-usecase-01=20 >=20 >=20 > Scenario 2: Alice's wash machine technically has a problem. Its > application was configured by the vendors? in a way to report this > problem automatically to third party technical service (repair > place). Both the technical service application and wash machine need= > to authenticate each other so that they can trust and exchange > information. Since the application are usually implemented by the > third party and there was not much effort to secure the > communications between the device and the application, the security > of them is a big concern. >=20 > Alice turned on the wash machine at home and then went to work. Alice > can check the status of this wash machine using an application on he= r > Smartphone remotely at company x. Wash machine doesn't support any > certificates signed by a CA. Alice needs to be authenticated in the > wash machine and wash machine needs to trust Alice to allow her > control it remotely. Since the application are usually provided by > third parties, the security of this communication is important and > the first point of trust is really important. >=20 > Thanks, > Best, > Hosnieh > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --IhAn8r5Lm9LQbQExhWceP0pdRSW8Cv9mG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUO96rAAoJEGhJURNOOiAtSrkIAIvqHlaOU520JIYYEC+JJbmY kMGrwhiMxnGNG2ng5GHJFWktq8/Fx0mFibORTOaHf7Yem4+d5TWrk/f9lmIe/px3 6slldWfT1WSYEfECgJ6C02edA50Im4Jq6kpvETUlNbGW1m0LjG2kXOd06XAHx5fP dJ+l3fbeFPNk1m4vCNlAMUdGspfGUz/X1r+1sBb9nohs23IEjkPeTL3URi1sa/9x EthXTs8c///52BqM1eUWb1ujceMuQmPblTtDrSvRBMij4j6hgt1JyWUMxmZnBTxh n4ahBTLPvSMCzbdFNjfuyRRj6o7Ee64SoLSiV6HBSr7/1JT8B9tyO1eTFwEuNI4= =rM+R -----END PGP SIGNATURE----- --IhAn8r5Lm9LQbQExhWceP0pdRSW8Cv9mG-- From nobody Mon Oct 13 07:39:43 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19471A016D for ; Mon, 13 Oct 2014 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9FpIwblD7Y7 for ; Mon, 13 Oct 2014 07:39:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839EC1A016B for ; Mon, 13 Oct 2014 07:39:39 -0700 (PDT) Received: from [192.168.10.188] ([195.50.187.121]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M2L60-1YVNMq1cXs-00s7b8; Mon, 13 Oct 2014 16:39:36 +0200 Message-ID: <543BE424.3010206@gmx.net> Date: Mon, 13 Oct 2014 16:39:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Hosnieh Rafiee , "secauth@ietf.org" References: <007801cfd9be$5990cff0$0cb26fd0$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A44B04@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A44B04@lhreml513-mbb.china.huawei.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r7a85uNdRTCM9dmCrha34oL2gtLaEBLue" X-Provags-ID: V03:K0:sbz22nuqLdsSSer72CB2DYwvs7JIucdqS9ZKWjggrihICXukACK m4uIHt1J06jpEGNMUzMH780k86pvI12OrqcyG2DCT6uJFSxP1QMncNmorvSGbo8l0nDZzXm xm3nRqXi9f4pCn8/BiFr63lPMwt75xXQ/snC/zwnPX32KcODayMM04h7iGiUU3nk7RA7T1n YtnWyvInZ4H6Q7oQVRenA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/XsafxiDuCke2V2mzxtWX1bSiTUw Subject: Re: [Secauth] Any opinion on charter? X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:39:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r7a85uNdRTCM9dmCrha34oL2gtLaEBLue Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, a few remarks inline. On 09/29/2014 01:54 PM, Hosnieh Rafiee wrote: > Folks, >=20 > I asked ADs for a side meeting (room request) in upcoming IETF. I still= do not know the time but as soon as I know this, I will let you know.=20 >=20 > I still did not received any opinion on the charter. I welcome your inp= uts so that it can be as clear as possible. >=20 > Thanks, > Best, > Hosnieh >> >> Proposed charter and the working items of secauth >> ----------------------------------------------------------------------= - >> - >> There are various authentication and authorization mechanisms in use >> today. >> These mechanisms might only support particular devices, for instance, >> only available for constrained devices or it might only focuses on >> nodes with rich resources (CPU, memory, etc.) without the possibility >> for them to be used for constrained devices. Therefore, there are >> different types of heterogeneous protocols available and use over the >> internet that cannot authenticate or work together. This is why, there= >> is usually a need that both devices support the same mechanism. Thereb= y, >> Having a mechanism to interoperate between all available mechanisms an= d >> enable different mechanisms to work together for a robust >> authentication and authorization, without the need for the nodes to >> support individual protocols is demanding. You will always need to have some commonly agreed mechanism in order for devices from different vendors to talk to each other. There is no way around that. >> In other word, using a simple, light approach (like a language) that >> can be supported by all current devices so that it provides the >> possibility for two devices that uses two different authentication and= >> authorization protocols to exchange their secure parameters in a secur= e >> manner. I am trying to understand where you are getting with this. It almost seems that you are suggesting to use a language (like JavaScript with the Crypto API) to then accomplish interoperability between devices. Do I understand the idea correctly? Therefore, one of the purpose of secauth is to eliminate >> security gaps during authentication and authorization and provide a >> simple solution that can be supported by different nodes with differen= t >> resources and play a role of interoperate protocol. This paragraph sounds more like you would like to standardize another authentication protocol that can then be supported everywhere. Of course, adding another authentication protocol to the already existing toolbox does not make it the only one and the deployment does not happen by magic either. >> >> In addition, providing trust during the establishment of the >> communication is usually out of the scope of the existing security >> protocols. I personally try to avoid the term "trust" since it is so fuzzy. If you use it then you need to say "who trust whom to do what". This is why there is usually a big gap that demands some to >> many manual configurations to provide a node with a secure >> authentication/authorization. Automating the establishment of this >> communication, providing user/device authentication and authorization,= >> minimizing the need of human interaction and interoperate between othe= r >> protocols to provide a robust secure authentication and authorization >> between two heterogeneous protocols is what this group aim to address.= >> >> Furthermore, secauth aims to remove the need of CAs or >> installation/configuration of any infrastructure for the purpose of >> authentication and authorization. This allows the wide use of this >> protocol over the networks. In a protocol that offers authentication and authorization you need to provision some information. Of course, nobody likes provisioning but if you don't do that then you get something like opportunistic security, which of course does not cover many scenarios either. There is just no free lunch. I fear that you will need a few examples of technologies you want to standardize to give folks an idea about the direction you are heading. The current charter text is very generic. In the discussion about scenarios you had raised a couple of different directions and it might be good to focus on something small at the beginning; something very specific to get folks interested. >> >> >> The tasks of this group includes: >> ------------------------------------ >> 1) Produce problem statement, requirements and use cases >> 2) Identify the design and architecture for providing first point of >> trust and reduce the security gap as much as possible and consider >> confidentiality for this solution >> 3) Identify the existing protocols that needs this interoperation >> 4) Identify the light cryptographic approaches that can be used for >> authentication and authorization purposes >> >=20 Ciao Hannes > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth >=20 --r7a85uNdRTCM9dmCrha34oL2gtLaEBLue Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUO+QlAAoJEGhJURNOOiAtj/UH/0LQFM7EMZmPAtb3iZI7CJ5W VfqHZFPV3Ws5Pgrd1OjQ4+UVQ9oRMsRgk8JkBuWheKielJIYMy6BScDP5lOFXp6I K1ETA1HBexLo/TPfDkdZgexEb6zfTEqLkXM3ZQHyQ8vv9bykGQCu2aM8UVXXRIQw lhaXtS6gV9McBr8vhOpC8Rzs0sx27zd9k58s2aHS3c6GBGnlCPwNHeQGEzVQNv5j yRFWp1564GOGW2fYIJAEfGW7yVZixKBIV0pHipDJjsfeSOKJ9YANuHw9ke38WiXI 6euC3ztHOumLksG4R7LYTe053fZa5SKHyUuuXdmWYPW43Au1fejcq+VZcW0xpmQ= =YGuF -----END PGP SIGNATURE----- --r7a85uNdRTCM9dmCrha34oL2gtLaEBLue-- From nobody Mon Oct 13 08:17:22 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19531A034E; Mon, 13 Oct 2014 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrSFS4Z4TZNh; Mon, 13 Oct 2014 08:17:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313AE1A01C6; Mon, 13 Oct 2014 08:17:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP23713; Mon, 13 Oct 2014 15:17:15 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Mon, 13 Oct 2014 16:17:13 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] some suggestions - clarification of ACE scope and secauth Thread-Index: AQHP466Hjbmt+uEqAkuKiz5ogU7rw5wuCFgAgAAZMhA= Date: Mon, 13 Oct 2014 15:17:13 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4829E@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <543BDEAA.1000701@gmx.net> In-Reply-To: <543BDEAA.1000701@gmx.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/hjuH5rV2WywfpuuCGaosY4nofPw Cc: "secauth@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:17:19 -0000 Hi Hannes, Thanks for your response. My responses inline... >=20 > the scenarios fall into the scope of ACE if at least the resource > server is constrained. I presumed that something like wash machine have constrained resources. > If the washing machine just talks to some cloud-based infrastructure > then that's not really of interest to ACE. If there is, however, a > technician standing next to the washing machine and wants to retrieve > information from the washing machine using his mobile phone or tablet > directly then the washing machine becomes the resource server. Ok, So, if I understand you correctly, if one end point is constrained devi= ces and the other point is cloud infrastructure, this is not what ACE will = work on and I can put it in secauth.=20 > To me it appears (from our earlier discussion about the scenarios) that > you envision some interaction with a server-side infrastructure. If > that's the case then you should be able to solve these use cases with > the already existing standards we have developed. >=20 Yes true. But it appears that I have to revise the scope based on your comm= ents and other offlist discussion. Thanks,=20 Best, Hosnieh From nobody Mon Oct 13 09:18:18 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187231A1AA2; Mon, 13 Oct 2014 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRo5xakMbcOR; Mon, 13 Oct 2014 09:18:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696F01A1AA9; Mon, 13 Oct 2014 09:18:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP28593; Mon, 13 Oct 2014 16:18:01 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 13 Oct 2014 17:16:50 +0100 From: Hosnieh Rafiee To: Carsten Bormann Thread-Topic: [Ace] some suggestions - clarification of ACE scope and secauth Thread-Index: AQHP5v9EihhV/Ms4z0++EQrL8hLnc5wuMN5Q Date: Mon, 13 Oct 2014 16:16:49 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A48363@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <543BDEAA.1000701@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A4829E@lhreml513-mbb.china.huawei.com> <15F2FD1A-76F7-42F3-BBFB-645DD1EC9279@tzi.org> In-Reply-To: <15F2FD1A-76F7-42F3-BBFB-645DD1EC9279@tzi.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/qLG7WjNy2UbrATzzqFpMjwYpG8Y Cc: "secauth@ietf.org" , "ace@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:18:14 -0000 Hi Carsten, Thanks for your message. Please see my responses inline... > > Ok, So, if I understand you correctly, if one end point is > constrained devices and the other point is cloud infrastructure, this > is not what ACE will work on >=20 > If this is just about a secure connection between the constrained > device and a less-constrained device, that is already covered by DTLS, > so there is nothing to work on. To some extend true. Thanks for clarification. I will check DTLS again to s= ee what they have and how they want to provide the authentication and autho= rization in virtualization environment, share the result with the mailingli= st. Besides the above mentioned scenarios, secauth plans to work on first point= of trust for different use cases. Does ACE also work on this first point o= f trust? If so I will remove all use cases regarding constrained devices, i= f not I only change these particular use cases to only focus on providing f= irst point of trust. > If the point is to have the less-constrained device become authorized > to access resources on the constrained device, then we need something > like ACE. >=20 > A more detailed introduction of what ACE is about is in draft-gerdes- > ace-actors-01.txt Thanks, will take a look. Best, Hosnieh From nobody Mon Oct 13 09:23:54 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183E61A0346; Mon, 13 Oct 2014 09:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hceqhcm2pH-D; Mon, 13 Oct 2014 09:03:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648801A037E; Mon, 13 Oct 2014 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9DG3XIG014893; Mon, 13 Oct 2014 18:03:33 +0200 (CEST) Received: from [192.168.217.113] (p54893EA6.dip0.t-ipconnect.de [84.137.62.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F25E6594; Mon, 13 Oct 2014 18:03:32 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4829E@lhreml513-mbb.china.huawei.com> Date: Mon, 13 Oct 2014 18:03:31 +0200 X-Mao-Original-Outgoing-Id: 434909011.275065-4f9c0a48d2711f6ddd9a0f029661d8ba Content-Transfer-Encoding: quoted-printable Message-Id: <15F2FD1A-76F7-42F3-BBFB-645DD1EC9279@tzi.org> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <543BDEAA.1000701@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A4829E@lhreml513-mbb.china.huawei.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/R9wYs1yi_QJvGhiO0lJjJNHsBUg X-Mailman-Approved-At: Mon, 13 Oct 2014 09:23:47 -0700 Cc: Hannes Tschofenig , "secauth@ietf.org" , "ace@ietf.org" Subject: Re: [Secauth] [Ace] some suggestions - clarification of ACE scope and secauth X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:03:45 -0000 On 13 Oct 2014, at 17:17, Hosnieh Rafiee = wrote: > Ok, So, if I understand you correctly, if one end point is constrained = devices and the other point is cloud infrastructure, this is not what = ACE will work on If this is just about a secure connection between the constrained device = and a less-constrained device, that is already covered by DTLS, so there = is nothing to work on. If the point is to have the less-constrained device become authorized to = access resources on the constrained device, then we need something like = ACE. A more detailed introduction of what ACE is about is in = draft-gerdes-ace-actors-01.txt Gr=FC=DFe, Carsten From nobody Tue Oct 14 08:27:50 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31D61A8943 for ; Tue, 14 Oct 2014 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2d_dfiePvM8 for ; Tue, 14 Oct 2014 08:27:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC781A8942 for ; Tue, 14 Oct 2014 08:27:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ32456; Tue, 14 Oct 2014 15:27:33 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 16:27:31 +0100 From: Hosnieh Rafiee To: Carsten Bormann Thread-Topic: Clarification of DTLS and secauth scope Thread-Index: AQHP58NemBLf4mq3Bk2tp6WDmjepbw== Date: Tue, 14 Oct 2014 15:27:30 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A48A6D@lhreml513-mbb.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A37D0@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A3B0D@SZXEMA501-MBS.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A47504@lhreml513-mbb.china.huawei.com> <543BDEAA.1000701@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A4829E@lhreml513-mbb.china.huawei.com> <15F2FD1A-76F7-42F3-BBFB-645DD1EC9279@tzi.org> <814D0BFB77D95844A01CA29B44CBF8A7A48363@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A48363@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/cSzMDMLCb25EXTzqSo-cvCp7Ims Cc: "secauth@ietf.org" Subject: [Secauth] Clarification of DTLS and secauth scope X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:27:47 -0000 Hi Carsten, I just followed your suggestion and reviewed DTLS document again (to recall= its exact application). What I understood from DTLS is that it is similar = to TLS but it only includes the possibility for handling the untruthful com= munication over UDP. But there is nothing about how to handle the communica= tion between two nodes in virtual environment (automatically) or how to han= dle the first point of trust. This is especially important to avoid the use= of CAs (because of reasons explained in the secauth use cases and requirem= ents). My conclusion from that document is that still secauth can keep its scope o= n the followings: - Provides the first point of trust (as specified in revised version of sec= auth charter) - Provides an authentication and authorization language (protocol) for virt= ual environment (device to device, user to device) Any other thoughts? Thanks, Best, Hosnieh From nobody Wed Oct 22 08:44:50 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654EE1ACD85 for ; Wed, 22 Oct 2014 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LNmVsOBX54B for ; Wed, 22 Oct 2014 08:44:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FFD1ACD95 for ; Wed, 22 Oct 2014 08:44:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNX95636; Wed, 22 Oct 2014 15:44:37 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 16:44:27 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig , Joel Halpern , "Liushucheng (Will)" Thread-Topic: Revised version of requirements and use cases (version 2) Thread-Index: Ac/uDw64syp/Z0wAQUOs6L2xPCOigw== Date: Wed, 22 Oct 2014 15:44:26 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4B9DF@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/RHi2NhZBETRJFBYh5gfAkW95YuU Cc: "secauth@ietf.org" Subject: [Secauth] Revised version of requirements and use cases (version 2) X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:44:47 -0000 Thanks Hannes, Joel and Will for your comments.=20 @Folks, I revised the requirement and use case drafts to cover the same scope as do= es the current proposed secauth charter.=20 < https://tools.ietf.org/html/draft-rafiee-secauth-usecase > There are a lot of people in this group however there are a few active peop= le. Therefore, I think there should be some motivation to have more active = members. To understand weak points and having more contributions I appreci= ate your clear answers to the following questions: - Do you support to continue this work? If No: what is missing? Do you see any possibility to improve it?=20 If Yes: Is there anything that we can improve or we forget to address? - What do you think about the scope?=20 What is your opinion about the proposed charter (following)? Proposed charter and the working items of secauth ------------------------------------------------------------------------ There are various authentication and authorization mechanisms in use today.= Some supports only particular devices, for instance, only available for co= nstrained devices. Some others support the nodes with rich resources (CPU, = memory, etc.). However, reliable communication in first point of contact is= usually out of the scope of the existing security protocols. This is why t= here is usually a big gap that demands some to many manual configurations t= o provide a node with a secure authentication/authorization. Providing reli= ability during the first point of contact (decrease the security gap) and a= utomating the establishment of this communication as much as possible and p= roviding device authentication and authorization in virtual environment whe= re NFV and SDN based techniques are in use is what secauth aim to address. = =20 Furthermore, secauth aims to remove the need of CAs and/or installation/con= figuration of any TA infrastructure for authentication and authorization. A= lthough, if only domain names are in use, secauth need to use a DNS server = to translate these names to their IP addresses. There are two scenarios her= e: [1] a node can trust the network where it is connected in order to receive = the IP address of a DNS server. This scenario is only when a node can recei= ve the IP address of a resolver from secure Router Advertisement (RA) or th= ere is any switch-based security available. The scope of secauth here is to securely authenticate the DNS resolver and = to securely authenticate an application or a device. [2] a node cannot trust the network. The finger print of a DNS server needs= to be set in the node manually as explained in http://tools.ietf.org/html/= draft-rafiee-intarea-cga-tsig . This manual step is out of scope of secauth= . After this step, like what explained in last scenario, secauth can verify= the DNS resolver and securely authenticate an application or a device.=20 If the communication is only IP based and a node uses a valid IP address.=20 - In IPv6, dissimilar to [1] and [2], secauth can automate the whole proces= s without any configuration.=20 - In IPv4, this is similar to [1] and [2]. =20 Secauth is not dependent to any IP based solution. However, when a node sup= ports a valid global IP address, secauth does not need to receive any infor= mation from DNS.=20 Summary of the scope of secauth ------------------------------------ - It is not dependent to an IP based solution. - It depends on a secure solution on a switch or a secure RA for full autom= ation as explained in [1]. Unless, it depends on a manual configuration [2]= . - It removes the requirement for the use of a CA - It depends on a DNS server to translate names to IP addresses but it can = securely handle this process. (provide security for DNS servers) - The configuration of DNS server is out of scope of secauth.=20 - The configuration of switches or providing secure RA is out of scope of s= ecauth =20 The tasks of this group includes: ------------------------------------ 1) Produce problem statement, requirements and use cases 2) Identify the design and architecture for providing reliable communicatio= n in first point of contact and reduce the security gap as much as possible= and consider confidentiality for this solution 3) Identify the existing protocols that needs this interoperation 4) Identify the light cryptographic approaches that can be used for authent= ication and authorization purposes Thanks, Best, Hosnieh P.S Please note that secauth is not yet a WG. The charter needs to be appro= ved by ADs.=20 From nobody Thu Oct 30 06:26:07 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403C51AD0B3 for ; Thu, 30 Oct 2014 06:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtsfsCBzV4yb for ; Thu, 30 Oct 2014 06:26:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15AB1A0024 for ; Thu, 30 Oct 2014 06:25:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF54887; Thu, 30 Oct 2014 13:25:53 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Thu, 30 Oct 2014 13:25:48 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: conference call - pre-discussion before bar meeting at IETF Thread-Index: Ac/0RQO5lgYu/N/4RRyPOMwD44PPJg== Date: Thu, 30 Oct 2014 13:25:47 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4E71C@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/CXyDVPxCSX51cXDy08X50luAv-c Subject: [Secauth] conference call - pre-discussion before bar meeting at IETF X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:26:04 -0000 All, Before having any bar meeting at upcoming IETF, I would like to know the nu= mber of participants at bar meeting. I thought the best way to understand t= his is that to have a conference call.=20 Here are the available timeslot (doodle ) for such meeting next week. Pleas= e choose your convenient timeslots. I send the invitation access informatio= n for this conference call to people who send me their availability for thi= s call. The agenda for this conference call: - Discussion about the scope of this group (what IETF groups can be used as= a based to this group, comparison of our charter with other works, etc.) - Discussion about proposed charter (how to improve it? , ...) - Discussion about next steps what you can do here and how you want to contribute on this work. Contribut= ion includes reviewing current draft/s, proposing solutions (writing new dr= afts), actively start discussion topic on the list, contributing some text = to current requirement and use case draft - Discussion about date and time for bar meeting (all time slots are in +1 Berlin time) The duration of meeting is 1 hour. (20-30 minutes presentation and the rest= of time for discussion) < http://doodle.com/5q2zpvxvctuy28qr > Thanks, Hosnieh From nobody Fri Oct 31 00:51:39 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87061A8AF6 for ; Fri, 31 Oct 2014 00:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnViD-oyKFEW for ; Fri, 31 Oct 2014 00:51:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2511A8AF5 for ; Fri, 31 Oct 2014 00:51:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG28313; Fri, 31 Oct 2014 07:51:34 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 07:51:34 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: conference call - pre-discussion before bar meeting at IETF Thread-Index: Ac/0RQO5lgYu/N/4RRyPOMwD44PPJgAmfR9g Date: Fri, 31 Oct 2014 07:51:33 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4EB30@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/bz9FhYW9lpUC623eSdtaaSMq1MU Subject: Re: [Secauth] conference call - pre-discussion before bar meeting at IETF X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 07:51:38 -0000 All, It appears that the calendar did not show time zone so I added time zone to= the calendar.=20 Since today is one of the chosen date, please if you can make it today, ple= ase hurry up and fill out the calendar so that I can arrange this telco tod= ay.=20 The duration of meeting is 1 hour. (20-30 minutes presentation and the rest= of time for discussion) < http://doodle.com/5q2zpvxvctuy28qr > Thanks, Hosnieh From nobody Fri Oct 31 01:02:48 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D01A8AFE for ; Fri, 31 Oct 2014 01:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikgcDDVNH-PH for ; Fri, 31 Oct 2014 01:02:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751FD1A8AFD for ; Fri, 31 Oct 2014 01:02:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG29398; Fri, 31 Oct 2014 08:02:44 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 08:02:43 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Followup- conference call - pre-discussion before bar meeting at IETF Thread-Index: AQHP9OEMZTBzq4M6aU2sJQ5zuzCcpw== Date: Fri, 31 Oct 2014 08:02:43 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4EB5E@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/-QFloHY8xiLpcFlxpr4wJE2Odgs Subject: [Secauth] Followup- conference call - pre-discussion before bar meeting at IETF X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 08:02:47 -0000 Followup This is the correct link to the new poll I guess this will solve the problem of folks who told me that the calendar = doesn't convert the time. Please choose your appropriate time and fill out this doodle poll if you pl= an that we have this call today. Thanks, Best, Hosnieh From nobody Fri Oct 31 07:33:07 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A363A1A8AA9 for ; Fri, 31 Oct 2014 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO8ofsWdIQtx for ; Fri, 31 Oct 2014 07:33:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6941A0013 for ; Fri, 31 Oct 2014 07:33:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD59683; Fri, 31 Oct 2014 14:33:01 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 14:32:59 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Gentle reminder - doodle pre-discussion telco Thread-Index: Ac/1F5FlI/YpUKaKTX2rR4Q8fV4kXg== Date: Fri, 31 Oct 2014 14:32:59 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4EED8@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/QUjCgxB8P0Tnr695ZiuOrwPlrBM Subject: [Secauth] Gentle reminder - doodle pre-discussion telco X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:33:05 -0000 All, I ask you please add your preference to doodle as soon as possible so that = if the discussion supposed to be on Monday (3 November 2014 at 2 PM (berli= n time))Based on the current list of participants, then I can send this inv= itation in a timely manner to the list of attendees. < http://doodle.com/5q2zpvxvctuy28qr > Thanks a lot , Best, Hosnieh From nobody Fri Oct 31 08:32:41 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87D1A9038 for ; Fri, 31 Oct 2014 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0whvMGj4LB8l for ; Fri, 31 Oct 2014 08:32:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDD01A90B2 for ; Fri, 31 Oct 2014 08:32:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD64601; Fri, 31 Oct 2014 15:32:33 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 15:32:28 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Gentle reminder - doodle pre-discussion telco - Corrected Link Thread-Index: AQHP9R/gJFXNithvCUat/OsZjrYK/w== Date: Fri, 31 Oct 2014 15:32:27 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/yHtbtrL5akLXGgp_wDGNLN3U0I8 Subject: [Secauth] Gentle reminder - doodle pre-discussion telco - Corrected Link X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:32:38 -0000 I am really sorry, the copied the link to the wrong poll(the old one withou= t time zone). It was my mistake.=20 Here is the corrected link < http://doodle.com/6gsfdi5u8gptxmhz > -----Original Message----- From: Secauth [mailto:secauth-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Friday, October 31, 2014 3:33 PM To: secauth@ietf.org Subject: [Secauth] Gentle reminder - doodle pre-discussion telco All, I ask you please add your preference to doodle as soon as possible so that = if the discussion supposed to be on Monday (3 November 2014 at 2 PM and 3 = PM (berlin time))Based on the current list of participants, then I can send= this invitation in a timely manner to the list of attendees. Thanks a lot , Best, Hosnieh