From nobody Mon Sep 1 02:27: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 4A1B11A02DB; Mon, 1 Sep 2014 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 jN5Jpx2rwNHe; Mon, 1 Sep 2014 02:27:02 -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 C6B6D1A02D5; Mon, 1 Sep 2014 02:27:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIY11966; Mon, 01 Sep 2014 09:27:00 +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, 1 Sep 2014 10:26:56 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Review request- secauth - authentication and authorization - first draft Thread-Index: AQHPxcbficLM/RnRMUiwoQ+/hu2oEw== Date: Mon, 1 Sep 2014 09:26:55 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> In-Reply-To: <53FDDDA2.3070607@freeradius.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/xzzV1jIken9J5zlaVKqKghXaX0Y Cc: "saag@ietf.org" Subject: [Secauth] Review request- secauth - authentication and authorization - first draft 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, 01 Sep 2014 09:27:04 -0000 Folks, I have received a few comments offlist. I would welcome more comments if an= y. Please consider reviewing it and share your ideas to know whether or not= we considered all your thoughts or we need to work more. I would prefer to receive comments on the mailinglist rather than offlist. = Because other folks might also include something to your comments or there = might be supporters or non-supporters of certain idea. Thanks, Best, Hosnieh http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00=20 From nobody Tue Sep 2 04:11:44 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 EC4111A0109; Tue, 2 Sep 2014 04:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 fVpmRxfS-gOi; Tue, 2 Sep 2014 04:11: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 693AE1A004C; Tue, 2 Sep 2014 04:11:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIZ27693; Tue, 02 Sep 2014 11:11:29 +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; Tue, 2 Sep 2014 12:11:23 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" Thread-Topic: [saag] Review request- secauth - authentication and authorization - first draft Thread-Index: AQHPxcbficLM/RnRMUiwoQ+/hu2oE5vs2XuAgAC44GA= Date: Tue, 2 Sep 2014 11:11:22 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2A78F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <20140901231729.GS14392@mournblade.imrryr.org> In-Reply-To: <20140901231729.GS14392@mournblade.imrryr.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/QFlAQers5BZJ3kNVouS010EbMZQ Cc: "secauth@ietf.org" Subject: Re: [Secauth] [saag] Review request- secauth - authentication and authorization - first draft 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, 02 Sep 2014 11:11:36 -0000 Viktor, Again thanks a lot for your comments which I really appreciated it.=20 >=20 > The draft seems to have much text in 3.1 on various flavours of > authentication mechanisms at the application layer. It is not clear > why these are there, if the goal is primarily to explore the > requirements for an API that exposes network-layer security to the > application layer. Yes, as the title of this draft also shows, the purpose is only requirement= s and use cases and still I don't plan to go through the solution space. Ho= wever, I have some ideas but I guess it makes sense to go through it after = we have an acceptable version of the requirement document. > It is not clear what the purpose of section 3.2 is. >=20 > Section 3.3 seems to talk about virtual network infrastructure. > Is this API between the application layer and local network-layer > security such as IPSEC, ... Or is it an interface to talk to network > infrastructure? (Switches, Proxies, ...) No, this API is inside each node and handles the secure authentication betw= een two devices that there can be user behind one of these device or there = can be also another device.=20 And the infrastructure can be switches, proxy servers, etc. Please consider the following cases Authentication /authorization (for short: Auth2) of a user to a device (thi= s is of course not possible without an application. So to summarize it, it = is Auth2 of the application1 to application2 where application 2 is on anot= her node located on different network or the same network) So for this use case scenario,=20 Virtualization falls into the category of Auth2 of device to device. This i= s , of course, via some applications but the differences is that there is n= o human or user in between and all the things are done automatically betwee= n two devices that can be on a same network or on different networks.=20 This is like a policy enforcer protocol wants to setup authentication and a= uthorization Now about this Auth2 in detail for second scenario that is virtualization (= I guess this was the confusing part. right?) Virtual device (VD) x wants to add a new rule in virtual device y. VD x nee= ds to authenticate VD y and then authorize it before it allows it to add or= modify any resources on VD y. VD x uses secauth api and sends authenticati= on request to VD y, based on secauth configuration, it first uses a network= layer authentication to create the first level of trust. After VD y uses s= ecauth and authenticates VD x, it authorizes VD x to use some resources or = modify a resources on VD y. This step can be handled by other mechanisms (l= ike Oauth) or still can be handled by secauth because the first point of tr= ust was the main purpose of secauth and the other parts can be handled by o= ther protocols or secauth as well. Such as starting a secure channel to enc= rypt all data, etc. =20 Do you think my example is clear?=20 Secauth might also use other mechanisms to create this first trust efficien= tly.=20 This is what I tried to explain or expand the virtualization section.=20 > Critically, the last paragraph of the introduction: > seems rather unclear. Is securing the last mile an API problem? Not an API problem, but the current problems with current protocols and the= purpose is to eliminate this problem or eliminate the gap in first point o= f trust. > One example requirement is to expose a channel-binding between the > network layer encrypted channel, and the application data stream, which > can be used in combination with higher-layer mechanisms to create an > authenticated application-layer message stream out of from a network > layer that provides unauthenticated encryption with integrity > protection. Do you mean I need to go to more detail about requirements? Isn't it consid= ered as a use case scenario that how the things need to work? I mean shall = I expand the use case section or requirement section? > Other requirements might include functionality to query the security > state of the network layer, or control it. >=20 > If I am not misreading the intended scope of the draft, it seems too > early to review it, because so little is there... Thanks again, Best, Hosnieh From nobody Wed Sep 3 04:18:32 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 2DD991A86FE; Wed, 3 Sep 2014 04:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 83wKtVNwyrv1; Wed, 3 Sep 2014 04:18:24 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 CDBE21A00E1; Wed, 3 Sep 2014 04:18:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 98C2A5660916; Wed, 3 Sep 2014 11:18:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPcj3BodvMBB; Wed, 3 Sep 2014 13:17:51 +0200 (CEST) Received: from kopoli (p5B343C97.dip0.t-ipconnect.de [91.52.60.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 8A4495660908; Wed, 3 Sep 2014 13:17:51 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> Date: Wed, 3 Sep 2014 13:17:48 +0200 Message-ID: <000101cfc768$b26d56b0$17480410$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2iDjW82G5bjHhRmYPmeon6KLlwKyZQhkAfvrc1sB0iolhpsZEldQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/NN3Azrgu0fHo_SudYNu5BPGRXLI Cc: saag@ietf.org Subject: Re: [Secauth] [saag] Review request- secauth - authentication and authorization - first draft 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, 03 Sep 2014 11:18:27 -0000 Hi Paul, Thanks a lot for your comments and suggestions. I will consider them all in next version. Please see my responses inline... > I find the abstract and purpose of the document confusing. > It's hard to tell purpose of the requirements. I kept the abstract so short. But if it is needed I would expand it. > "... use cases and requirements for secure > authentication in other layers above the network layer ..." > Not sure why layers matter in the abstract for AuthN/AuthZ services. > > "... and the use of network layer security approaches > for this purpose. ..." > > The first part excludes network layer and now you include network layer. You are right. I guess it is wording problem. The purpose is to use Network layer approaches as means of authentication in other layers. This network layer approaches also can combine with other available approaches. For instance for the start, the authentication is network layer and after the establishment of this trust, it can be application layer or user based password authentication or token based to authorize this user to access to certain resources. Like two level authentication and authorization. > " 3.1. Authentication/Authorization of a User to a Device" > Not sure why this would be in scope since the user is not an 'application'. > This is also not a well formed use case > (e.g. a banking application that needed > to validate that a user had direct control over a application might be a viable > use case) > > > > " 3.1.1. Biometric Authentication" > This is not a use case, it's a mechanism. > > " 3.1.5. NAT Scenario" > Useful use case for network layer ... > Not clearly articulated why it's interesting. > Not so important above layer three. > Not clear about scope of this document. I would like to remove the requirements for CA for each single node. CA might be useful for many cases but not when we supposed to use it for each single user and single node. So the purpose is to remove CAs and also automation when we plan not to use CA. because by removing CA, the problem would be the establishment of trust. So, now the purpose is to provide this trust with less efforts. Since most spoofing attacks happens in network layer, we aim to prevent this attack in this layer. Please consider that the aim is not only the authentication and authorization of a user to access some resources but also a node to update, or modify something on another node. This is why the cases like proxy servers are important. Since we are talking about network layer approaches to easily avoid IP spoofing and other kinds of spoofing problems, then NAT MIGHT cause a problem and that was a reason that I considered a scenario where one of our nodes are behind NAT. Do you think it is clear now? > " 3.1.6. Valid IP address" > Does not make sense in section 3.1 > Not really the right term for the scenario. > Not really a use case, but one possible addressing Situation. Ok, then change it to something else. > Use cases might beter include users: > - home user behind firewall > - home gateway with static IP address (valid) > - home IoT widget with IPv6 based on device MAC address (privacy issues) > - home IoT widget with IPv6 based on Ephemeral MAC address > - etc Thanks for the suggestion. Ok, I will consider them. > > " 3.3. Authentication and Authorization of Virtual Devices" > Not clear if this is in scope for IETF work. Internal security of Virtualized > services is not apparent over-the-wire. A virtual server is typically > indistinguishable from a non-virtual server. > > > > Draft is a bit rough at the moment. Clarity in abstract and purpose would be a > good starting point. Ok I will try to address them and will prepare next version. Best, Hosnieh From nobody Mon Sep 15 08:26:01 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 0408F1A1F20; Mon, 15 Sep 2014 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 UL96Fkd8y_Po; Mon, 15 Sep 2014 08:25:57 -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 0286C1A03C2; Mon, 15 Sep 2014 08:23:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJM09995; Mon, 15 Sep 2014 15:23:17 +0000 (GMT) Received: from LHREML513-MBX.china.huawei.com ([10.201.4.199]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 16:22:33 +0100 From: Hosnieh Rafiee To: Paul Lambert , Viktor Dukhovni Thread-Topic: Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0Pjem6xKx/YzMUuAvU7OwT31FA== Date: Mon, 15 Sep 2014 15:22:32 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> In-Reply-To: <000101cfc768$b26d56b0$17480410$@rozanak.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/wo95xbFgxwdNVsVjB0czf-Z0DpM Cc: "secauth@ietf.org" , "saag@ietf.org" Subject: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 15 Sep 2014 15:25:59 -0000 Hello, I have revised the secauth requirement and use case draft. I would apprecia= te your inputs on this new version. I am going to upload after receiving more feedback The current pre-upload version can be found here: < http://editor.rozanak.com/show.aspx?u=3DAZ6AA4BFD809BB71B2544CTAM > @Paul, Viktor: would you please check to see whether the document is clear = and satisfy the changes you have asked. @folks: I welcome more comments before uploading new version. Please share = your inputs on editorial, document organization or technical. Thanks, Best, Hosnieh From nobody Mon Sep 15 08:58:57 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 7AC741A7035 for ; Mon, 15 Sep 2014 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 0EawZJHzNExU for ; Mon, 15 Sep 2014 08:58:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 B34541A03BD for ; Mon, 15 Sep 2014 08:47:18 -0700 (PDT) Received: from [192.168.131.128] ([80.92.116.66]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MWQSM-1XrJWa3U0Q-00XYmu; Mon, 15 Sep 2014 17:47:15 +0200 Message-ID: <54170A00.3060107@gmx.net> Date: Mon, 15 Sep 2014 17:47:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Hosnieh Rafiee , "secauth@ietf.org" References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8DSaKnXs0n39bNef5pORqvpv0j3fib54x" X-Provags-ID: V03:K0:Y5HZu42FLFsOzPeu7PK7y0ULZOnFW1HB0BG8jH/A0mr7tIzZohr 4+yguXVneHU1KkehcGfQvmE42dFgPNb0iuUDyVUba0ajM8CL18CW0Gi/azm/p+YkrINEliq RNgs4UBQ5HLUixNvjCdCSRRG0g6Q/2m6BEpxQq/c67X3lpV2byZHFFL5o3cSQgCGFHFXT2A rSET+zwC99wnWyxO0orpQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/oXPWa4l43_r__wx9hI89Zr7f7b4 Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 15 Sep 2014 15:58:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8DSaKnXs0n39bNef5pORqvpv0j3fib54x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, I just took a quick look at the scenarios. Comments are inline: ---- 3. Use cases The following subsections explain different use case scenarios. 3.1. Verification of a User to an Application Over the Network 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. [hannes] Take a look at the ACE use case document. This use case sounds very similar to what we are trying to address. Here is the pointer to the use case document: http://tools.ietf.org/html/draft-seitz-ace-usecases-01 3.2. Home User Behind Firewall or a Proxy Server Alice?s device is behind a firewall or a proxy server. Alice wants to use an application that uses SIP protocol to contact Bob. Bob rejects any unknown calls to avoid advertisements/spam. Proxy server needs to verify Alice and send the information to Bob?s device [hannes] Hasn't this been solved already with the work on SIP? 3.3. Home Gateway/Device with an Static IP Address (Valid IP) Scenario 1: Alice needs to control its home gateway and add new rules so that she can access a device inside her home network. Alice remotely connects to this device. This device doesn?t support any valid CA. The device needs to authenticate Alice before lets it control this device and add/modify any new rule to this device. [hannes] Today this issue is solved by either connecting to the device in a special way (when you install it) and then provision your username/password or you use some other pairing procedure (such as entering info that is printed on the bottom of the device). These pairing procedures are interesting but they often relate to the radio technology that is being used (compare Bluetooth vs. WiFi) and then there are various technologies that have been explored (and standardized already). 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 a 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. [hannes] This is not a common use today but what is common is that devices get provisioned with long-term keys during the manufacturing / provisioning process and then they talk to the websites of the manufacturer. In fact, this is the most common deployment model of IoT appliances today. 3.4. Verification of an App. to an App. Over the Network [hannes] I don't know a lot about these use cases since I did not follow the OpenFlow work. So, I will skip those. ---- Ciao Hannes On 09/15/2014 05:22 PM, Hosnieh Rafiee wrote: > Hello, >=20 > I have revised the secauth requirement and use case draft. I would appr= eciate your inputs on this new version. >=20 > I am going to upload after receiving more feedback > The current pre-upload version can be found here: >=20 > < http://editor.rozanak.com/show.aspx?u=3DAZ6AA4BFD809BB71B2544CTAM > >=20 > @Paul, Viktor: would you please check to see whether the document is cl= ear and satisfy the changes you have asked. >=20 > @folks: I welcome more comments before uploading new version. Please sh= are your inputs on editorial, document organization or technical. >=20 > Thanks, > Best, > Hosnieh >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth >=20 --8DSaKnXs0n39bNef5pORqvpv0j3fib54x 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 iQEcBAEBCgAGBQJUFwoBAAoJEGhJURNOOiAtj4MH/RwKMor3p+CWLr6kLATiMhTT kr6oxYsoI51KUQcj/jWbkIwwwxPWKFV+yEsZ/zC7ocJQuo5uFe6/okG5Gm2fnEQi 8uRBDpHPycvMCyXpEgVqeN2LMLjPaoTvBT8XU5k9Xz/xZKexPZ1mE0OGLMqmltmr Tslaek0qmoU13tsYRDUcjewh7W6PSPvKNjpxJWATQNKh/PCbzrmqXzIhNzs2/vTH cBKQbwg0JWnfhSw4gwsglOpqFRsHrb+0XJVLdZFgusAvFaGnsf96mSal8ZWlt9mn csL7rPa8mXLm6VR6ux7X2cjYx3ibajrYURBRbFRMDSP/SY3zViRLTJ56dYGKOIM= =E7fJ -----END PGP SIGNATURE----- --8DSaKnXs0n39bNef5pORqvpv0j3fib54x-- From nobody Mon Sep 15 09:57:46 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 7BAD01A897D for ; Mon, 15 Sep 2014 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 MBKreoE1YNTS for ; Mon, 15 Sep 2014 09:57: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 4769D1A898F for ; Mon, 15 Sep 2014 09:23:57 -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 BMQ14754; Mon, 15 Sep 2014 16:23:54 +0000 (GMT) Received: from LHREML513-MBX.china.huawei.com ([10.201.4.199]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 17:23:48 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig Thread-Topic: [Secauth] Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0Pjem6xKx/YzMUuAvU7OwT31FJwCResAgAATAxA= Date: Mon, 15 Sep 2014 16:23:48 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> In-Reply-To: <54170A00.3060107@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/MUZDnrcgUpc75p5iyVMoAqEi1ao Cc: "secauth@ietf.org" Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 15 Sep 2014 16:57:45 -0000 Hi Hannes, Thanks a lot for your comment that I really appreciated. Please find my res= ponses inline. >=20 > [hannes] Take a look at the ACE use case document. This use case sounds > very similar to what we are trying to address. Here is the pointer to > the use case document: > http://tools.ietf.org/html/draft-seitz-ace-usecases-01 The scope of them are not the same. secauth covers greater scope than ACE. = As far as I can remember (if my memory helps) both group was initiated alm= ost at the first time but ACE focused on constrained devices and the main f= ocus of secauth is the use of network layer security for first point of tru= st in different use cases. In other words, you can combine it with other ap= proaches if it is necessary -- OAuth, ACE, etc. I think ACE is a protocol and secauth is at the moment an API. >=20 > [hannes] Hasn't this been solved already with the work on SIP? As far as I know there was a draft that aimed to use IPsec and I explained = in the draft about the use of IPsec. I haven't seen other works. Probably I= missed them. If there are please share the links and I would review and co= mpare with secauth. Secauth wants to be simple and easy because automation = is also the purpose. > [hannes] Today this issue is solved by either connecting to the device > in a special way (when you install it) and then provision your > username/password or you use some other pairing procedure (such as > entering info that is printed on the bottom of the device). The use of secauth doesn't necessarily reduce the need of passwords. You ca= n use two level authentication and authorization. The other case is that wh= at if you need to change your IP or other parameters? Do you need to reconf= igure manually? This is again what I plan to address. > These pairing procedures are interesting but they often relate to the > radio technology that is being used (compare Bluetooth vs. WiFi) and > then there are various technologies that have been explored (and > standardized already). True. But I also considered them in the introduction and problem statement.= The various security approaches that are used and as far as I know the fir= st point of trust is already the main problem. It is difficult to close tha= t gap completely but we can eliminate this gap by the use of secauth. > 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 a 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 > [hannes] This is not a common use today but what is common is that > devices get provisioned with long-term keys during the manufacturing / > provisioning process and then they talk to the websites of the > manufacturer. In fact, this is the most common deployment model of IoT > appliances today. I read an article two days ago that there are already some vendors that hav= e smart home devices that send information to the technical site. So, this = is already in use but with... unsure level of security. This was the case I= also considered it as one of the important use cases.=20 > 3.4. Verification of an App. to an App. Over the Network >=20 > [hannes] I don't know a lot about these use cases since I did not > follow the OpenFlow work. So, I will skip those. >=20 SDN/NFV are quite new and there are still working on progress for their sec= urity. So secauth can be an answer to the authentication and authorization.= =20 I hope I could answer your concerns. If not please let me know where I did = not. Thanks, Best, Hosnieh=20 From nobody Mon Sep 15 23:39:09 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 442391A0352 for ; Mon, 15 Sep 2014 23:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 t09zUSvGqT-B for ; Mon, 15 Sep 2014 23:39:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 E5D5B1A033E for ; Mon, 15 Sep 2014 23:39:04 -0700 (PDT) Received: from [192.168.131.130] ([80.92.116.66]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MUYiV-1XtJjq0MbL-00RFxs; Tue, 16 Sep 2014 08:38:53 +0200 Message-ID: <5417DAFB.4070905@gmx.net> Date: Tue, 16 Sep 2014 08:38:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Hosnieh Rafiee References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PihTtMXasOEvDrfGTjWs2EahrkVIVhfIB" X-Provags-ID: V03:K0:TfMG9L0ppWl/UA4QyauB2EDw9RlUkUWB4qMjn1GrgYKn5ezyZAy XEKtMWCNzNPs59R0iJaogzWElUkXnyDT1ImA6nD2pl7HUiEgj3fl2iTy3Ma+rfitDNMzxDt mdmPyX8moVZNnWzP3Jm9tkmsCEvVm3lHL0kcG8DbG5GsEDJdvDKAf/FSF1HPhIeEUwCN7+M DOuLHDwC3olo8fdUP5gtQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/1zLmI3qyvzxoGK1bifXXvTKUh98 Cc: "secauth@ietf.org" Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 16 Sep 2014 06:39:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PihTtMXasOEvDrfGTjWs2EahrkVIVhfIB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, thanks for the quick response. Remarks inline: On 09/15/2014 06:23 PM, Hosnieh Rafiee wrote: > Hi Hannes, >=20 > Thanks a lot for your comment that I really appreciated. Please find > my responses inline. >=20 >>=20 >> [hannes] Take a look at the ACE use case document. This use case >> sounds very similar to what we are trying to address. Here is the >> pointer to the use case document:=20 >> http://tools.ietf.org/html/draft-seitz-ace-usecases-01 >=20 > The scope of them are not the same. secauth covers greater scope than > ACE. As far as I can remember (if my memory helps) both group was > initiated almost at the first time but ACE focused on constrained > devices and the main focus of secauth is the use of network layer > security for first point of trust in different use cases. In other > words, you can combine it with other approaches if it is necessary -- > OAuth, ACE, etc. >=20 > I think ACE is a protocol and secauth is at the moment an API. At the moment we are still at the level of use cases. >=20 >=20 >>=20 >> [hannes] Hasn't this been solved already with the work on SIP? >=20 > As far as I know there was a draft that aimed to use IPsec and I > explained in the draft about the use of IPsec. I haven't seen other > works. Probably I missed them. If there are please share the links > and I would review and compare with secauth. Secauth wants to be > simple and easy because automation is also the purpose. An IPsec-based solution was developed in the 3GPP but the IETF solution uses digest authentication (a challenge-response mechanism similar to the one used in HTTP) combined with TLS between the proxy and the user's SIP UA. You can see example call flows here: http://tools.ietf.org/html/rfc3665 >=20 >=20 >> [hannes] Today this issue is solved by either connecting to the >> device in a special way (when you install it) and then provision >> your username/password or you use some other pairing procedure >> (such as entering info that is printed on the bottom of the >> device). >=20 > The use of secauth doesn't necessarily reduce the need of passwords. > You can use two level authentication and authorization. The other > case is that what if you need to change your IP or other parameters? > Do you need to reconfigure manually? This is again what I plan to > address. If you want to change configuration parameters in your home gateway then you need to log-in using the initially provisioned account credentials. Whether an IP address change requires you (as a user to actually take some actions) very much depends on the overall configuration. >=20 >> These pairing procedures are interesting but they often relate to >> the radio technology that is being used (compare Bluetooth vs. >> WiFi) and then there are various technologies that have been >> explored (and standardized already). >=20 > True. But I also considered them in the introduction and problem > statement. The various security approaches that are used and as far > as I know the first point of trust is already the main problem. It is > difficult to close that gap completely but we can eliminate this gap > by the use of secauth. This is certainly an interesting area of work but not an easy topic for the IETF since some of the mechanisms are outside the scope of the IETF itself (since they rely mostly on out-of-band channels with humans doing some stuff). You might want to take a brief look at these two documents and follow the references: http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02= http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >=20 >=20 >> Scenario 2: Alice?s wash machine technically has a problem. Its=20 >> application was configured by the vendors? in a way to report this=20 >> problem automatically to a 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 >> [hannes] This is not a common use today but what is common is that=20 >> devices get provisioned with long-term keys during the >> manufacturing / provisioning process and then they talk to the >> websites of the manufacturer. In fact, this is the most common >> deployment model of IoT appliances today. >=20 > I read an article two days ago that there are already some vendors > that have smart home devices that send information to the technical > site. So, this is already in use but with... unsure level of > security. This was the case I also considered it as one of the > important use cases. The ability for devices to connect to some cloud-based infrastructure is very common (and has been for a long time). I am not sure how common it is with washing machines that get connected to an app from a technician (if I understood it correctly). Maybe you want to clarify the interaction between the technical service app and the washing machine. >=20 >> 3.4. Verification of an App. to an App. Over the Network >>=20 >> [hannes] I don't know a lot about these use cases since I did not=20 >> follow the OpenFlow work. So, I will skip those. >>=20 >=20 > SDN/NFV are quite new and there are still working on progress for > their security. So secauth can be an answer to the authentication and > authorization. Isn't SDN very much a network-operator internal aspect with pre-arranged trust relationships? >=20 > I hope I could answer your concerns. If not please let me know where > I did not. >=20 > Thanks, Best, Hosnieh Ciao Hannes >=20 > _______________________________________________ Secauth mailing list=20 > Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth >=20 --PihTtMXasOEvDrfGTjWs2EahrkVIVhfIB 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 iQEcBAEBCgAGBQJUF9r7AAoJEGhJURNOOiAtBooH/iDvZ1yvxTdQV8Lm8tL26YAG jSkrLafDpHffSYGvd+ZVWpeLQCowEOKUtW1kay9nwTpRUXteqzt1j1rHdRYJMsOh lxphqjpFKT1ViGVAxjVjb//RaSeK/PesjxniFtsSbJvMADXfx97ZSurEbdbuYnhz E5Nwvg+hVMhEh9oIBuzfmBYD+nQZzmnAbIxxJleAS6QjpBQgujkzYVjHlBw4lQZy xp/HQZrvD7DS0WG53AQ6/OnCdEOK3JRPeKU8PCiurtTTOe8xeeV6Gaw43LCV0Zcf 1U4IhPnPhFi7H0b+JoDLCHgNkfQZwzTvEmkg7J4q1ZIuOVKpRI1TlLAfwlFLcLs= =ADxX -----END PGP SIGNATURE----- --PihTtMXasOEvDrfGTjWs2EahrkVIVhfIB-- From nobody Tue Sep 16 08:17:15 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 54A221A070F for ; Tue, 16 Sep 2014 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 MIu-QiSJAecY for ; Tue, 16 Sep 2014 08:17:08 -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 038631A068A for ; Tue, 16 Sep 2014 08:17:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN13043; Tue, 16 Sep 2014 15:17:05 +0000 (GMT) Received: from LHREML513-MBX.china.huawei.com ([10.201.4.199]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 16 Sep 2014 16:17:01 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig Thread-Topic: [Secauth] Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0Pjem6xKx/YzMUuAvU7OwT31FJwCResAgAATAxCAAOYdgIAAj5sA Date: Tue, 16 Sep 2014 15:17:00 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> <5417DAFB.4070905@gmx.net> In-Reply-To: <5417DAFB.4070905@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/_po_UBXGxhiiTAg0rM4ugk2Yq5Q Cc: "secauth@ietf.org" Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 16 Sep 2014 15:17:12 -0000 Hi Hannes, Thanks again for sharing your inputs. Please find my responses inline.. >=20 > An IPsec-based solution was developed in the 3GPP but the IETF solution > uses digest authentication (a challenge-response mechanism similar to > the one used in HTTP) combined with TLS between the proxy and the > user's SIP UA. >=20 > You can see example call flows here: http://tools.ietf.org/html/rfc3665 I checked the RFC reference you have provided including RFC 3261 and RFC 26= 17 that discussed about HTTP digest. There are some problems: 1- MD5 is a weak hash function and no longer is recommended 2- section 26.4.3 RFC 3261 already discussed the problem with TLS Another problem with TLS was already discussed in secauth requirement draft= . So it appears that this problem wasn't solved and still there.=20 Some time ago I saw a draft but cannot find it... it was about SIP and IPse= c... I guess (maybe I am confused with other work...) > > > > > >> [hannes] Today this issue is solved by either connecting to the > >> device in a special way (when you install it) and then provision > your > >> username/password or you use some other pairing procedure (such as > >> entering info that is printed on the bottom of the device). > > > > The use of secauth doesn't necessarily reduce the need of passwords. > > You can use two level authentication and authorization. The other > case > > is that what if you need to change your IP or other parameters? > > Do you need to reconfigure manually? This is again what I plan to > > address. >=20 > If you want to change configuration parameters in your home gateway > then you need to log-in using the initially provisioned account > credentials. > Whether an IP address change requires you (as a user to actually take > some actions) very much depends on the overall configuration. As I explained before, secauth does not necessarily remove the requirement = for the use of password but only aims to ensure that the user enters its pa= ssword in a so called correct server/device. However, if user doesn't like = to use password, then it can handle the communication in other ways that I = do not want to jump to solution space. (however I have some solutions in my= mind) > This is certainly an interesting area of work but not an easy topic for > the IETF since some of the mechanisms are outside the scope of the IETF > itself (since they rely mostly on out-of-band channels with humans > doing some stuff). I am not quite agree with your sentence where you said it is out of scope o= f the IETF. This is because as long as we can use or offer something that r= educe this human interaction with new or current available standards, then = this is not something not achievable at IETF. Although, this is true that n= obody can claim that we can completely remove the human interaction for the= configurations. But there is a difference between having easy configuratio= n than having complex configuration. In other word, to what level the human= needs to interact.=20 > You might want to take a brief look at these two documents and follow > the references: > http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop- > 02 > http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 Thanks I will do it. >=20 > The ability for devices to connect to some cloud-based infrastructure > is very common (and has been for a long time). I am not sure how common > it is with washing machines that get connected to an app from a > technician (if I understood it correctly).=20 That article was more focused in someone remotely control home devices like= a wash machine and also the information that a wash machine sent to the te= chnical service to inform about its health.=20 I imagine that when this is already implemented for a wash machine might ex= ist for other devices as well and the main focus of that article was the pr= ivacy and security concerns. >Maybe you want to clarify > the interaction between the technical service app and the washing > machine. Ok, will do it.=20 > > > >> 3.4. Verification of an App. to an App. Over the Network > >> > >> [hannes] I don't know a lot about these use cases since I did not > >> follow the OpenFlow work. So, I will skip those. > >> > > > > SDN/NFV are quite new and there are still working on progress for > > their security. So secauth can be an answer to the authentication and > > authorization. >=20 > Isn't SDN very much a network-operator internal aspect with pre- > arranged trust relationships? Not completely since the environment is more dynamic and needs more flexibi= lity that wasn't require in the current infrastructure. From nobody Wed Sep 17 04:43:57 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 E6CA91A0203 for ; Wed, 17 Sep 2014 04:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 b8HC77T16KFW for ; Wed, 17 Sep 2014 04:43:51 -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 C3D2B1A011B for ; Wed, 17 Sep 2014 04:43:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN97378; Wed, 17 Sep 2014 11:43:49 +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, 17 Sep 2014 12:43:45 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0myiQNTr5RulX0m9sml+S7oraw== Date: Wed, 17 Sep 2014 11:43:44 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A3F33B@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> <5417DAFB.4070905@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> 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/JmH64tKY3tc2oav5KQZ7Lcw2Bh8 Subject: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 17 Sep 2014 11:43:54 -0000 Hannes, Folks, Is there any other comments that I can address before uploading new version= today? Do you think it is good to have a online meeting to discuss this more? If y= es please suggest the date. Thanks, Best, Hosnieh From nobody Wed Sep 17 05:04: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 1A0261A01C6 for ; Wed, 17 Sep 2014 05:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 hYiQxRVT6Ld0 for ; Wed, 17 Sep 2014 05:04:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A55381A01B0 for ; Wed, 17 Sep 2014 05:04:46 -0700 (PDT) Received: from [192.168.131.130] ([80.92.116.66]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LrrRi-1YTImo0Vxe-013e5T; Wed, 17 Sep 2014 14:04:44 +0200 Message-ID: <541978DB.7000902@gmx.net> Date: Wed, 17 Sep 2014 14:04:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Hosnieh Rafiee References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> <5417DAFB.4070905@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RJhkXSvEBOFLdxVXlVMA7gMlG2kJE0XvA" X-Provags-ID: V03:K0:nsjt344ToX5mt6G0moYSbBF56pcR8Ow56aJqcR0NCddFNzGlKm3 MhYNg22BMLW3lcIuABwC1J/7MmR/GUhRcX+HiusHfA6MhyfGftSrrZZPxvGVcpJkO6ysrjL jBdfQV7LCDi91KvigMEGqY3CK4H0a4BztPnFQhlP5JMpaUGljV+bfqpp1y7KjrgsOo+anrv 75oWluJbHd+n1oV2vPIgA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/ngShO5yX2Jzd4LwEa4CjcNkiCY4 Cc: "secauth@ietf.org" Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 17 Sep 2014 12:04:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RJhkXSvEBOFLdxVXlVMA7gMlG2kJE0XvA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, a few remarks inline: On 09/16/2014 05:17 PM, Hosnieh Rafiee wrote: > Hi Hannes, >=20 > Thanks again for sharing your inputs. Please find my responses > inline.. >=20 >>=20 >> An IPsec-based solution was developed in the 3GPP but the IETF >> solution uses digest authentication (a challenge-response mechanism >> similar to the one used in HTTP) combined with TLS between the >> proxy and the user's SIP UA. >>=20 >> You can see example call flows here: >> http://tools.ietf.org/html/rfc3665 >=20 > I checked the RFC reference you have provided including RFC 3261 and > RFC 2617 that discussed about HTTP digest. There are some problems:=20 > 1- MD5 is a weak hash function and no longer is recommended 2- > section 26.4.3 RFC 3261 already discussed the problem with TLS=20 > Another problem with TLS was already discussed in secauth requirement > draft. While MD5 is a weak hash function it is actually used in a keyed version. That makes it better. The concern raised in Section 26.4.3 of RFC 3261 is not applicable anymore (due to the introduction of DTLS). If you think there are still problems with SIP then it might be worthwhile to reach out to the RAI area. In the meanwhile most of the guys have moved on to WebRTC (even the telco guys). But it would nevertheless be worth a try. >=20 > So it appears that this problem wasn't solved and still there. >=20 > Some time ago I saw a draft but cannot find it... it was about SIP > and IPsec... I guess (maybe I am confused with other work...) The work on SIP and IPsec (between the SIP UA and the proxy server) is a 3GPP specific solution and has been standardized there. >=20 >=20 >>>=20 >>>=20 >>>> [hannes] Today this issue is solved by either connecting to >>>> the device in a special way (when you install it) and then >>>> provision >> your >>>> username/password or you use some other pairing procedure (such >>>> as entering info that is printed on the bottom of the device). >>>=20 >>> The use of secauth doesn't necessarily reduce the need of >>> passwords. You can use two level authentication and >>> authorization. The other >> case >>> is that what if you need to change your IP or other parameters?=20 >>> Do you need to reconfigure manually? This is again what I plan >>> to address. >>=20 >> If you want to change configuration parameters in your home >> gateway then you need to log-in using the initially provisioned >> account credentials. Whether an IP address change requires you (as >> a user to actually take some actions) very much depends on the >> overall configuration. >=20 > As I explained before, secauth does not necessarily remove the > requirement for the use of password but only aims to ensure that the > user enters its password in a so called correct server/device. > However, if user doesn't like to use password, then it can handle the > communication in other ways that I do not want to jump to solution > space. (however I have some solutions in my mind) I think it would be good to describe what the current practices and design/usage patterns are that you would like to change. While the currently deployed approach is certainly a solution one can always phrase the anticipated way of working in form of a user story. >=20 >=20 >> This is certainly an interesting area of work but not an easy topic >> for the IETF since some of the mechanisms are outside the scope of >> the IETF itself (since they rely mostly on out-of-band channels >> with humans doing some stuff). >=20 > I am not quite agree with your sentence where you said it is out of > scope of the IETF. This is because as long as we can use or offer > something that reduce this human interaction with new or current > available standards, then this is not something not achievable at > IETF. Although, this is true that nobody can claim that we can > completely remove the human interaction for the configurations. But > there is a difference between having easy configuration than having > complex configuration. In other word, to what level the human needs > to interact. In one of the documents I listed there was also a pointer to a working group (called ENROLL) that was created by Russ Housley a while ago that tried to solve the enrollment / pairing problem. Unfortunately, the working group never went anymore because the problem statement was not precise enough. That can easily happen again. >=20 >=20 >> You might want to take a brief look at these two documents and >> follow the references:=20 >> http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop= - >> >>=20 02 >> http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >=20 > Thanks I will do it. >=20 >>=20 >> The ability for devices to connect to some cloud-based >> infrastructure is very common (and has been for a long time). I am >> not sure how common it is with washing machines that get connected >> to an app from a technician (if I understood it correctly). >=20 > That article was more focused in someone remotely control home > devices like a wash machine and also the information that a wash > machine sent to the technical service to inform about its health. I > imagine that when this is already implemented for a wash machine > might exist for other devices as well and the main focus of that > article was the privacy and security concerns. Ok. Got it. >=20 >> Maybe you want to clarify the interaction between the technical >> service app and the washing machine. >=20 > Ok, will do it. >=20 >>>=20 >>>> 3.4. Verification of an App. to an App. Over the Network >>>>=20 >>>> [hannes] I don't know a lot about these use cases since I did >>>> not follow the OpenFlow work. So, I will skip those. >>>>=20 >>>=20 >>> SDN/NFV are quite new and there are still working on progress >>> for their security. So secauth can be an answer to the >>> authentication and authorization. >>=20 >> Isn't SDN very much a network-operator internal aspect with pre-=20 >> arranged trust relationships? >=20 > Not completely since the environment is more dynamic and needs more > flexibility that wasn't require in the current infrastructure. I personally do not see how it relates to the other use cases. I would drop it. Ciao Hannes >=20 >=20 > _______________________________________________ Secauth mailing list=20 > Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth >=20 --RJhkXSvEBOFLdxVXlVMA7gMlG2kJE0XvA 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 iQEcBAEBCgAGBQJUGXjbAAoJEGhJURNOOiAtXa0IAI//OWj7inXyXQeSKLKDxxqg ILTbVpxzBNXIXmxYlZeGelJ063ibbfQwHHH5eJfBFhDHs6NTJkrXGcBIyxTI5E/d 4I6zM+6YhsUffun+N6bsvcq28Jw76NPoC/8L6j7Ov0Ez89lHFlum9uz8j6zXjVZy /oqyvvJKWCv8RqO0Gf+ObRM6iFs51eMN7Hd8+nxQhiBeVBIlfOuwEe99ObEaJJlF VETZl8y0x14Ln+P0RYkBHdFE6l7CaOPGlkTmZHOBW7scUxaNfmtZMh6mg7UCnSCR LYgiMtTMKNH80IXRwgdBXHQt6qSghCzrHmq2WNjiImPMNiz/7BtBi7taTWpzoyU= =cX54 -----END PGP SIGNATURE----- --RJhkXSvEBOFLdxVXlVMA7gMlG2kJE0XvA-- From nobody Wed Sep 17 08:34: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 A3BCF1A0194 for ; Wed, 17 Sep 2014 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 arkjGjuIH_uv for ; Wed, 17 Sep 2014 08:34:39 -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 4F1A91A0201 for ; Wed, 17 Sep 2014 08:34:38 -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 BMS25952; Wed, 17 Sep 2014 15:34:33 +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; Wed, 17 Sep 2014 16:33:37 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig Thread-Topic: [Secauth] Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0Pjem6xKx/YzMUuAvU7OwT31FJwCResAgAATAxCAAOYdgIAAj5sAgAFdxoCAAEJfIA== Date: Wed, 17 Sep 2014 15:33:36 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A41449@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> <54170A00.3060107@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A35A41@lhreml513-mbx> <5417DAFB.4070905@gmx.net> <814D0BFB77D95844A01CA29B44CBF8A7A362A6@lhreml513-mbx> <541978DB.7000902@gmx.net> In-Reply-To: <541978DB.7000902@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/a0CKewqZo3x2UWwRNMoqVkP9Itw Cc: "secauth@ietf.org" Subject: Re: [Secauth] Review request- secauth - authentication and authorization - second draft 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, 17 Sep 2014 15:34:40 -0000 Hi Hannes, Thanks again for your remarks. =20 > If you think there are still problems with SIP then it might be > worthwhile to reach out to the RAI area. In the meanwhile most of the > guys have moved on to WebRTC (even the telco guys). But it would > nevertheless be worth a try. Yes, I still think that there is a concern. I will solicit a message to Web= RTC and ask them to join to this group and share their inputs. =20 > The work on SIP and IPsec (between the SIP UA and the proxy server) is > a > 3GPP specific solution and has been standardized there. Ok, got it :-). No argue :-) > > As I explained before, secauth does not necessarily remove the > > requirement for the use of password but only aims to ensure that the > > user enters its password in a so called correct server/device. > > However, if user doesn't like to use password, then it can handle the > > communication in other ways that I do not want to jump to solution > > space. (however I have some solutions in my mind) >=20 >=20 > I think it would be good to describe what the current practices and > design/usage patterns are that you would like to change. While the > currently deployed approach is certainly a solution one can always > phrase the anticipated way of working in form of a user story. Just to clarify this, do you mean I have also to explain the design of solu= tion space? If not, would you please give me an example so that I can under= stand what I expect to do. > > > > > >> This is certainly an interesting area of work but not an easy topic > >> for the IETF since some of the mechanisms are outside the scope of > >> the IETF itself (since they rely mostly on out-of-band channels > >> with humans doing some stuff). > > > > I am not quite agree with your sentence where you said it is out of > > scope of the IETF. This is because as long as we can use or offer > > something that reduce this human interaction with new or current > > available standards, then this is not something not achievable at > > IETF. Although, this is true that nobody can claim that we can > > completely remove the human interaction for the configurations. But > > there is a difference between having easy configuration than having > > complex configuration. In other word, to what level the human needs > > to interact. >=20 > In one of the documents I listed there was also a pointer to a working > group (called ENROLL) that was created by Russ Housley a while ago that > tried to solve the enrollment / pairing problem. Unfortunately, the > working group never went anymore because the problem statement was not > precise enough. That can easily happen again. I understand but technology changed, requirements changed and we can look a= head and widen our scope and our way of thinking accordingly. Maybe the thi= ngs that 2 years ago wasn't possible is now possible due to the new technol= ogy. In other word, people were not ready for that because of unavailabilit= y of technology but I think now it is the time. As I said I first started w= ith solution but then guys said that I need to clarify the problem first be= fore I jump to the solution. (I guess I usually jump!... then I try to retu= rn to the problem). > >>> SDN/NFV are quite new and there are still working on progress > >>> for their security. So secauth can be an answer to the > >>> authentication and authorization. > >> > >> Isn't SDN very much a network-operator internal aspect with pre- > >> arranged trust relationships? > > > > Not completely since the environment is more dynamic and needs more > > flexibility that wasn't require in the current infrastructure. >=20 > I personally do not see how it relates to the other use cases. I would > drop it. >=20 The only reason that I added that is that this solution is not only for use= r to application, but can be used also for device to device either it is v= irtual or it is physical. In other word, just specifying its scope that is not limited to certain app= lications. Do you still think it does not help and not related to have it here? Thanks, Best, Hosnieh From nobody Fri Sep 19 06:19:44 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 C011E1A0154 for ; Fri, 19 Sep 2014 06:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 0cEhQ8ZCIYaA for ; Fri, 19 Sep 2014 06:19:40 -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 124801A0145 for ; Fri, 19 Sep 2014 06:19:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJQ07997; Fri, 19 Sep 2014 13:19:38 +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; Fri, 19 Sep 2014 14:19:37 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: API vs Protocol Thread-Index: Ac/UDFvYr11Kq5aGSeyXlzZ9mtQn6w== Date: Fri, 19 Sep 2014 13:19:36 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A41B86@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/9R95lHtZuj66Q19N7IYh8eDZ0Nk Subject: [Secauth] API vs Protocol 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, 19 Sep 2014 13:19:42 -0000 Folks, Based on some offlist discussions. One of folks suggested me to change seca= uth to protocol.=20 Any thoughts? I am gonna apply this change in the upcoming version. Share any ideas you m= ight have about this change. I am still improving the document and anyone w= ho is interested can access it via the public link which I shared in my las= t version (pre-version) Thanks, Best, Hosnieh From nobody Mon Sep 22 03:16: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 0DC8D1A1A8F for ; Mon, 22 Sep 2014 03:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 e2flHQonbI4a for ; Mon, 22 Sep 2014 03:16:49 -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 1A04E1A07BC for ; Mon, 22 Sep 2014 03:16:47 -0700 (PDT) Received: from [192.168.131.130] ([80.92.114.18]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOOdZ-1XQDFd2AjN-005tJ6; Mon, 22 Sep 2014 12:16:40 +0200 Message-ID: <541FF708.3080204@gmx.net> Date: Mon, 22 Sep 2014 12:16:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Hosnieh Rafiee , "secauth@ietf.org" References: <814D0BFB77D95844A01CA29B44CBF8A7A41B86@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A41B86@lhreml513-mbb.china.huawei.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KNrMRL5vjXN7mSLtSNP6TdEWLRT9wI9Jg" X-Provags-ID: V03:K0:jKRqEoJBigvdNJhI+L4SJnC5yNQWT0dX9I5y1JfavEaM+9sKn6n tGKntGfU05dG+WJWNp7vQQbwf4saZB3iov4+CmPgTXG+D4+gM1qdVSoq6B0kvs0ap5aKGBV Xp0KVbTc6CpE6ox09AYHDboLlbZUgF8eIWwNwaW/C7htXKsWfKaqV48Ils4UsTqtitK+GbA cBDqkvtYzBzIx8+JMVyrA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/l_tjXgUQy9TivrTztTpvPxcRIG0 Subject: Re: [Secauth] API vs Protocol 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, 22 Sep 2014 10:16:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KNrMRL5vjXN7mSLtSNP6TdEWLRT9wI9Jg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, some time ago there was a fairly good difference between a protocol and an API, whereby the latter was an implementation dependent concept and the protocol referred to the on-the-wire content. This difference got blurred a bit when JavaScript became popular that combined the API and the protocol components. The introduction of REST APIs, which has nothing to-do with the actual implementation itself, didn't help to clarify terminology either. So, I would suggest you talk about protocol since you are most likely concerned about the on-the-wire representation anyway. Ciao Hannes On 09/19/2014 03:19 PM, Hosnieh Rafiee wrote: > Folks, >=20 > Based on some offlist discussions. One of folks suggested me to change = secauth to protocol.=20 >=20 >=20 > Any thoughts? >=20 > I am gonna apply this change in the upcoming version. Share any ideas y= ou might have about this change. I am still improving the document and an= yone who is interested can access it via the public link which I shared i= n my last version (pre-version) >=20 > Thanks, > Best, > Hosnieh >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth >=20 --KNrMRL5vjXN7mSLtSNP6TdEWLRT9wI9Jg 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 iQEcBAEBCgAGBQJUH/cIAAoJEGhJURNOOiAtUd4IAJZzHsxAW+tkllamh+iUXN0+ nJabAy4jyZOtNl+BfOQ5v8+dxmaF1jKIWJLaYxH3lJrCNT26tlov9SJtBtIJbgIl /6PG/E6papUXxRYF3yIRfdI+4tlkNKdDkk8zCMNnP7Jg1+N4nHjtYVorRtxjFME+ Z2/hNMtbpkWNv01YLt7ycQkkuR/x4tD9OBfTn6PhMqfi15vjXgM3DRJSTWjnrT+2 KOONWBdKlfFcCkUQy+c0A03QMfwu0KKWumrMgtIyxY8yotM7niNxTsQIrV7WTDOn s747XXSiRXbT+rDQJi8rFJ+v0M5ZfoxPKzMM92JbJTkoMeNUsD1U6IQrYqzA2vo= =+xrc -----END PGP SIGNATURE----- --KNrMRL5vjXN7mSLtSNP6TdEWLRT9wI9Jg-- From nobody Mon Sep 22 04:02: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 723641A1A58 for ; Mon, 22 Sep 2014 04:02:39 -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 mwgAIJfsZP5q for ; Mon, 22 Sep 2014 04:02:37 -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 BE6EA1A1A45 for ; Mon, 22 Sep 2014 04:02: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 BJS17529; Mon, 22 Sep 2014 11:02:30 +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, 22 Sep 2014 12:02:28 +0100 From: Hosnieh Rafiee To: Hannes Tschofenig , "secauth@ietf.org" Thread-Topic: [Secauth] API vs Protocol Thread-Index: Ac/UDFvYr11Kq5aGSeyXlzZ9mtQn6wCOY8cAAAODRuA= Date: Mon, 22 Sep 2014 11:02:27 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A420FD@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A41B86@lhreml513-mbb.china.huawei.com> <541FF708.3080204@gmx.net> In-Reply-To: <541FF708.3080204@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/cOLqJVf6aujtvJBOFSec9u23HD8 Subject: Re: [Secauth] API vs Protocol 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, 22 Sep 2014 11:02:40 -0000 Hi Hannes, Thanks for your message and sharing your thoughts. > So, I would suggest you talk about protocol since you are most likely > concerned about the on-the-wire representation anyway. >=20 I agree with your suggestion. You are right, I am more concerned about on-t= he-wire.=20 Best, Hosnieh From nobody Tue Sep 23 06:30:09 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 688C41A802F for ; Tue, 23 Sep 2014 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, 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 jBNQEB2l9QmY for ; Tue, 23 Sep 2014 06:30:06 -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 9C2341A8028 for ; Tue, 23 Sep 2014 06:30:06 -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 BJU06572; Tue, 23 Sep 2014 13:30:04 +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; Tue, 23 Sep 2014 14:30:02 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: secauth - version 2 authentication and authorization requirement draft Thread-Index: Ac/XMnmgz+vnGkvRSG2uTZEzOwyVKA== Date: Tue, 23 Sep 2014 13:30:01 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@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/Mfez93V9tUglRJ5PAAdiq1SeCn8 Subject: [Secauth] secauth - version 2 authentication and authorization requirement draft 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, 23 Sep 2014 13:30:08 -0000 Folks, I have uploaded a new version of secauth requirement and use cases. Since I= plan to request a BoF, I need your inputs to know that what else we need t= o consider to be ready for BoF request. Therefore I welcome your inputs. Thanks you, Best, Hosnieh From nobody Tue Sep 23 06:47: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 12F6B1A802F for ; Tue, 23 Sep 2014 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, 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 LoVp2N88zRiD for ; Tue, 23 Sep 2014 06:47:24 -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 025BE1A797C for ; Tue, 23 Sep 2014 06:47:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU08413; Tue, 23 Sep 2014 13:47:20 +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; Tue, 23 Sep 2014 14:47:18 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: secauth - version 2 authentication and authorization requirement draft Thread-Index: AQHP1zTjQLZjahktXEme/VttAC1wbw== Date: Tue, 23 Sep 2014 13:47:17 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A42613@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@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/HyRi5LtmK8pmRptaPBPdRC0hTlI Subject: [Secauth] secauth - version 2 authentication and authorization requirement draft 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, 23 Sep 2014 13:47:25 -0000 Followup, Sorry I forgot posting the link It appears that IETF doesn't show the last version on a website. It is stra= nge... http://tools.ietf.org/html/draft-rafiee-secauth-usecase-01 From nobody Wed Sep 24 10:50:06 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 36A091A02EE for ; Wed, 24 Sep 2014 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] 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 pwrgo6W4z8DP for ; Wed, 24 Sep 2014 10:50:01 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 5C0441A02D9 for ; Wed, 24 Sep 2014 10:50:01 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id AC2795660911 for ; Wed, 24 Sep 2014 17:49:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzyZD2Mp4BAY for ; Wed, 24 Sep 2014 19:49:29 +0200 (CEST) Received: from kopoli (p5B3413CB.dip0.t-ipconnect.de [91.52.19.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id D0F315660903 for ; Wed, 24 Sep 2014 19:49:28 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@lhreml513-mbb.china.huawei.com> Date: Wed, 24 Sep 2014 19:49:25 +0200 Message-ID: <018401cfd81f$e2a56670$a7f03350$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIHFezQVPPLBmHa+HAaOuIY1oXPoJuiEyNQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/yQlyoW0NOKSOunlAmtMlpQ_-AXU Subject: Re: [Secauth] secauth - version 2 authentication and authorization requirement draft 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, 24 Sep 2014 17:50:04 -0000 All, Anybody had time to take a look on the new version? Do we need to specify any charter at this point ? Thanks, Best, Hosnieh From nobody Thu Sep 25 01:14:25 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 171CF1A02E5 for ; Thu, 25 Sep 2014 01:14:23 -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 pSb87J5aNBUd for ; Thu, 25 Sep 2014 01:14:21 -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 7C0841A02E0 for ; Thu, 25 Sep 2014 01:14:20 -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 BMZ39672; Thu, 25 Sep 2014 08:14:19 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Sep 2014 09:14:18 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 25 Sep 2014 16:14:13 +0800 From: "Liushucheng (Will)" To: Hosnieh Rafiee , "secauth@ietf.org" Thread-Topic: [Secauth] secauth - version 2 authentication and authorization requirement draft Thread-Index: Ac/XMnmgz+vnGkvRSG2uTZEzOwyVKAAqlliAAC7IGBA= Date: Thu, 25 Sep 2014 08:14:13 +0000 Message-ID: References: <814D0BFB77D95844A01CA29B44CBF8A7A425EE@lhreml513-mbb.china.huawei.com> <018401cfd81f$e2a56670$a7f03350$@rozanak.com> In-Reply-To: <018401cfd81f$e2a56670$a7f03350$@rozanak.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/5DFyhSyvSNVz4NGKD8p_Ldfjv2s Subject: Re: [Secauth] secauth - version 2 authentication and authorization requirement draft 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, 25 Sep 2014 08:14:23 -0000 SGkgSG9zbmllaCBhbmQgYWxsLA0KDQpJIHN1cHBvcnQgeW91ciB3b3JrIGFuZCBiZWxpZXZlIGl0 J3MgYW4gaW50ZXJlc3RpbmcgdG9waWMgdGhhdCBzaG91bGQgYmUgd29ya2VkIGluIElFVEYuDQpI ZXJlIGFyZSBteSBjb21tZW50czoNCg0KMS4gSSB0aGluayBTRUNBVVRIIGludGVuZHMgdG8gcHJv dmlkZSBhIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB1c2luZyBleGlzdGluZyBuZXR3b3JrIGxh eWVyIHNlY3VyZSB0ZWNoLiBJbiBuZXR3b3JrIGxheWVyLCB3ZSBtdXN0IGNvbnNpZGVyIE5BVCBp c3N1ZS4NCmUuZy4sIGluIHNlY3Rpb24gNC4yIFZlcmlmaWNhdGlvbiBvZiBhIFVzZXIgdG8gYW4g QXBwbGljYXRpb24gT3ZlciB0aGUgTmV0d29ya6Osd2FzaCBtYWNoaW5lIG1heSBzdXBwb3NlZCB0 byBiZSBiZWhpbmQgTkFUo6xob3cgZG9lcyBBbGljZSBnZXQgcHJpdmF0ZSBJUCBhZGRyZXNzIG9m IHdhc2ggbWFjaGluZSB0byBhdXRoZW50aWNhdGU/DQogDQoyLiBJbiBJT1SjrG9uZSBzbWFydCBk ZXZpY2UgY291bGQgY29udHJvbCBhbm90aGVyIHNtYXJ0IGRldmljZaOsc28gdGhlcmUgbWlnaHQg YmUgYSBjYXNlIG9mIHZlcmlmaWNhdGlvbiBvZiBhIGRldmljZSB0byBhIGRldmljZSBvdmVyIGNv bnN0cmFpbiBuZXR3b3JrLg0KDQozLiBzZWN0aW9uIDQuNSBzZWVtcyB0byBiZSBkZXNjcmliaW5n IFNETiBzZWN1cml0eS4gV2hhdCdzIHRoZSByZWxhdGlvbnNoaXAgd2l0aCBWZXJpZmljYXRpb24g b2YgYW4gQXBwLiBUbyBhbiBBcHAuIE92ZXIgTmV0d29yayBpbiB0aGUgdGl0bGU/DQoNCk15IDIg Y2VudHMuDQoNClJlZ2FyZHMsDQpXaWxsIChTaHVjaGVuZyBMSVUpDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2VjYXV0aCBbbWFpbHRvOnNlY2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhvc25pZWgNCj4gUmFmaWVlDQo+IFNlbnQ6IFRodXJzZGF5 LCBTZXB0ZW1iZXIgMjUsIDIwMTQgMTo0OSBBTQ0KPiBUbzogc2VjYXV0aEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW1NlY2F1dGhdIHNlY2F1dGggLSB2ZXJzaW9uIDIgYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24NCj4gcmVxdWlyZW1lbnQgZHJhZnQNCj4gDQo+IEFsbCwNCj4gDQo+ IEFueWJvZHkgaGFkIHRpbWUgdG8gdGFrZSBhIGxvb2sgb24gdGhlIG5ldyB2ZXJzaW9uPw0KPiBE byB3ZSBuZWVkIHRvIHNwZWNpZnkgYW55IGNoYXJ0ZXIgYXQgdGhpcyBwb2ludCA/DQo+IA0KPiBU aGFua3MsDQo+IEJlc3QsDQo+IEhvc25pZWgNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNlY2F1dGggbWFpbGluZyBsaXN0DQo+IFNlY2F1 dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNh dXRoDQo= From nobody Thu Sep 25 05:31:16 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 C5EDA1A6FC4 for ; Thu, 25 Sep 2014 05:31:13 -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 t5YfvOn-MAAV for ; Thu, 25 Sep 2014 05:31:09 -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 E91CE1A0005 for ; Thu, 25 Sep 2014 05:31:08 -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 BJX56298; Thu, 25 Sep 2014 12:31:07 +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; Thu, 25 Sep 2014 13:30:58 +0100 From: Hosnieh Rafiee To: "Liushucheng (Will)" Thread-Topic: [Secauth] secauth - version 2 authentication and authorization requirement draft Thread-Index: AQHP2Jrx88FFgNp/ZUCIaLoxhmJGN5wRhjkAgABBh2A= Date: Thu, 25 Sep 2014 12:30:58 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A440BF@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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Mn2XLwmcGYXG7Nt8gb0bc4oKPs4 Cc: "secauth@ietf.org" Subject: Re: [Secauth] secauth - version 2 authentication and authorization requirement draft 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, 25 Sep 2014 12:31:14 -0000 Hi Will, Thanks for your deep review and your suggestions and supports. >=20 > 1. I think SECAUTH intends to provide a authentication mechanism using=20 > existing network layer secure tech. In network layer, we must consider=20 > NAT issue. > e.g., in section 4.2 Verification of a User to an Application Over the > Network=1B$B!$=1B(Bwash machine may supposed to be behind NAT=1B$B!$=1B(B= how does Alice get=20 > private IP address of wash machine to authenticate? Yes that is true. However, I thought that I covered it in other use cases b= ut if I need to explicitly mention this, I would add it. My reasons are tha= t if Alice wants to connect to its home device and control it and if the de= vice is behind a NAT or has no valid IP address, then either Alice needs to= first connect to the intermediate device that has a valid IP address and t= hen try to access this device (something like VPN) or Alice should have a v= alid IP address and introduce it to the device so that the device initiate = the communication. In former case, it falls into category of proxy servers = or intermediate device authentication. In the latter case, it would be simi= lar to a home user who is behind NAT and wants to communicate to a server a= nd be authenticated to it. =20 Furthermore, I presume that the networks which supports IPv6 and in case th= e devices supports IPv6, fortunately/unfortunately the devices are accessib= le via their IPv6 address since it is global. (My printer has an IPv6 addre= ss and it set it up by default via my home router).=20 Nevertheless, there are two solutions for NAT, either secauth uses the secu= rity of network layer and then use those parameters to generate a secure va= lue for the authentication as it happened in the example document in the dr= aft. Then it generates the messages that is not dependent to IP address of = the node so that NAT would not make an issue. The second solution is that, the NAT device has a one to one mapping for de= vices that needs to be accessible outside. Something like what is explained= in the following article http://www.nimlabs.org/dirtynat.html > 2. In IOT=1B$B!$=1B(Bone smart device could control another smart device= =1B$B!$=1B(Bso > there might be a case of verification of a device to a device over=20 > constrain network. Ok I will add it > 3. section 4.5 seems to be describing SDN security. What's the=20 > relationship with Verification of an App. To an App. Over Network in=20 > the title? It is really difficult to categorize SDN related mechanisms. Since at the b= eginning its impact was on layer2/3 but now it also have impact on all abov= e layers. Therefore, some of them can fall in the category of software to s= oftware (app to app). One possibility is to just remove the main title and = make the subtitle as a main title to avoid any misinterpretation. Thanks again, Best, Hosnieh From nobody Fri Sep 26 12:16:56 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 57EE21A06E9 for ; Fri, 26 Sep 2014 12:16:54 -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, RP_MATCHES_RCVD=-0.786] 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 40ZkZA7PpHKb for ; Fri, 26 Sep 2014 12:16:52 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 5CDFE1A023E for ; Fri, 26 Sep 2014 12:16:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 19CFF5660911 for ; Fri, 26 Sep 2014 19:16:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3hLjmohbow7 for ; Fri, 26 Sep 2014 21:16:20 +0200 (CEST) Received: from kopoli (p5B3413CB.dip0.t-ipconnect.de [91.52.19.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 2A5895660900 for ; Fri, 26 Sep 2014 21:16:20 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Fri, 26 Sep 2014 21:16:16 +0200 Message-ID: <007801cfd9be$5990cff0$0cb26fd0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/ZvlbPv6UIJs+ySiGYVdJBmrptSw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/KF1DyLmEOqSQmuOWS8SMAjViHpk Subject: [Secauth] What is your opinion? 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, 26 Sep 2014 19:16:54 -0000 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. Thereby, Having a mechanism to interoperate between all available mechanisms and enable different mechanisms to work together for a robust authentication and authorization, without the need for the nodes to support individual protocols is demanding. 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 secure manner. 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 different resources and play a role of interoperate protocol. In addition, providing trust during the establishment of the communication 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 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 other 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. 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 Any thought? Please share your comments or your ideas. Thank you, Best, Hosnieh From nobody Mon Sep 29 04:54:42 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 5A8B51A875A for ; Mon, 29 Sep 2014 04:54:38 -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 sURdczkfDOUe for ; Mon, 29 Sep 2014 04:54:34 -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 659561A8750 for ; Mon, 29 Sep 2014 04:54:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA74691; Mon, 29 Sep 2014 11:54:33 +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, 29 Sep 2014 12:54:28 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Any opinion on charter? Thread-Index: AQHP29wfOrUgAv+zuki78PRpaeql9Q== Date: Mon, 29 Sep 2014 11:54:27 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A44B04@lhreml513-mbb.china.huawei.com> References: <007801cfd9be$5990cff0$0cb26fd0$@rozanak.com> In-Reply-To: <007801cfd9be$5990cff0$0cb26fd0$@rozanak.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/FjQJVH0spKo-Nao6q1TSwGlebTM Subject: [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, 29 Sep 2014 11:54:38 -0000 Folks, 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 I still did not received any opinion on the charter. I welcome your inputs = so that it can be as clear as possible. Thanks, Best, Hosnieh >=20 > 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. Thereby, > Having a mechanism to interoperate between all available mechanisms and > enable different mechanisms to work together for a robust > authentication and authorization, without the need for the nodes to > support individual protocols is demanding. > 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 secure > manner. 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 different > resources and play a role of interoperate protocol. >=20 > In addition, providing trust during the establishment of the > communication 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 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 other > protocols to provide a robust secure authentication and authorization > between two heterogeneous protocols is what this group aim to address. >=20 > 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. >=20 >=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 > 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