From isms-bounces@ietf.org Thu Mar 27 14:32:18 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A2628C91A; Thu, 27 Mar 2008 14:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.593 X-Spam-Level: X-Spam-Status: No, score=-100.593 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utEVuJd0-TIJ; Thu, 27 Mar 2008 14:32:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260B928C3C0; Thu, 27 Mar 2008 14:32:16 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8751328C2DC for ; Thu, 27 Mar 2008 14:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJcnEVd7KuI2 for ; Thu, 27 Mar 2008 14:32:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4FB7528C7A1 for ; Thu, 27 Mar 2008 14:32:13 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id CED2F8C84A for ; Thu, 27 Mar 2008 22:29:52 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09493-09; Thu, 27 Mar 2008 22:29:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9FC58C843; Thu, 27 Mar 2008 22:29:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C890E51F466; Thu, 27 Mar 2008 22:29:50 +0100 (CET) Date: Thu, 27 Mar 2008 22:29:50 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080327212950.GC4281@elstar.local> Mail-Followup-To: isms@ietf.org References: <20080228090442.GA7656@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080228090442.GA7656@elstar.local> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Feb 28, 2008 at 10:04:42AM +0100, Juergen Schoenwaelder wrote: > Dear all, > > this is the start of the working group last call on the ISMS > RADIUS integration document: > > Remote Authentication Dial-In User Service (RADIUS) Usage for > Simple Network Management Protocol (SNMP) Transport Models > > > The authors and the chairs think that this document is mature > enough for WGLC. Please do review these document and post your > comments on this list until Friday, March 28, 2008. I like to remind everybody here about this last call. We need some more people to read the document and to post their comments to this list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 28 07:58:28 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3553E28C984; Fri, 28 Mar 2008 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.374 X-Spam-Level: X-Spam-Status: No, score=-100.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVY5iPtYwZln; Fri, 28 Mar 2008 07:58:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB41C3A6CB9; Fri, 28 Mar 2008 07:58:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40E128C32A for ; Fri, 28 Mar 2008 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4hM44o7MMoB for ; Fri, 28 Mar 2008 07:58:20 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 9EF3728C96D for ; Fri, 28 Mar 2008 07:55:51 -0700 (PDT) Received: (qmail 6040 invoked from network); 28 Mar 2008 10:55:50 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Mar 2008 10:55:50 -0400 From: "David B. Nelson" To: References: <20080228090442.GA7656@elstar.local> <20080327212950.GC4281@elstar.local> Date: Fri, 28 Mar 2008 10:54:02 -0400 Organization: Elbrys Networks, Inc. Message-ID: <006a01c890e3$8fe84900$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciQUch2DhhcX1DsQmyuiWt9SLu+wwAkScgg In-Reply-To: <20080327212950.GC4281@elstar.local> Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder wrote: > I like to remind everybody here about this last call. We need some > more people to read the document and to post their comments to this > list. http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-02.txt It would be good if people could also comment upon a related document, in simultaneous WGLC in the RADEXT WG: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-02.txt The latter document defines the RADIUS Attributes called out in the former document. Thanks! _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 28 08:34:03 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9CC3A6BB9; Fri, 28 Mar 2008 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.395 X-Spam-Level: X-Spam-Status: No, score=-100.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erSuRVCwHg5F; Fri, 28 Mar 2008 08:33:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243603A68D1; Fri, 28 Mar 2008 08:33:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C653A6892 for ; Fri, 28 Mar 2008 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKc9UehlcT+H for ; Fri, 28 Mar 2008 08:33:55 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id D43453A6831 for ; Fri, 28 Mar 2008 08:33:55 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 6ahu1Z0060b6N64A20HT00; Fri, 28 Mar 2008 15:32:46 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 6fZn1Z00H4HwxpC8P00000; Fri, 28 Mar 2008 15:33:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=97RE6CVaQtYA:10 a=48vgC7mUAAAA:8 a=MFlogg84AXpiVYLPkiUA:9 a=bNpxw9GJ_JAQ8Z1Ecw4A:7 a=YdAXzvSHh2oAG60F5aad9i1o32MA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <20080228090442.GA7656@elstar.local><20080327212950.GC4281@elstar.local> <006a01c890e3$8fe84900$1f0a0a0a@xpsuperdvd2> Date: Fri, 28 Mar 2008 11:33:46 -0400 Message-ID: <090801c890e9$1e0dcde0$6c02a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciQUch2DhhcX1DsQmyuiWt9SLu+wwAkScggAAGDAYA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <006a01c890e3$8fe84900$1f0a0a0a@xpsuperdvd2> Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I thought I still had plenty of time left, and have procrastinated. Am I correct that WGLC for these two documents ends TODAY? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Friday, March 28, 2008 10:54 AM > To: isms@ietf.org > Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP > > Juergen Schoenwaelder wrote: > > > I like to remind everybody here about this last call. We need some > > more people to read the document and to post their comments to this > > list. > > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usa > ge-02.txt > > It would be good if people could also comment upon a related > document, in > simultaneous WGLC in the RADEXT WG: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-manageme > nt-authorizati > on-02.txt > > The latter document defines the RADIUS Attributes called out > in the former > document. > > Thanks! > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 28 08:39:27 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40083A6BB9; Fri, 28 Mar 2008 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sq2wXd63zDX; Fri, 28 Mar 2008 08:39:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC0D3A6B53; Fri, 28 Mar 2008 08:39:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3156D3A6B18 for ; Fri, 28 Mar 2008 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FaVtXGHmTFP for ; Fri, 28 Mar 2008 08:39:25 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 368093A69F1 for ; Fri, 28 Mar 2008 08:39:25 -0700 (PDT) Received: (qmail 7028 invoked from network); 28 Mar 2008 11:39:17 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Mar 2008 11:39:17 -0400 From: "David B. Nelson" To: References: <20080228090442.GA7656@elstar.local><20080327212950.GC4281@elstar.local> <006a01c890e3$8fe84900$1f0a0a0a@xpsuperdvd2> <090801c890e9$1e0dcde0$6c02a8c0@china.huawei.com> Date: Fri, 28 Mar 2008 11:37:29 -0400 Organization: Elbrys Networks, Inc. Message-ID: <006b01c890e9$a1855a30$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciQUch2DhhcX1DsQmyuiWt9SLu+wwAkScggAAGDAYAAAAQosA== In-Reply-To: <090801c890e9$1e0dcde0$6c02a8c0@china.huawei.com> Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > I thought I still had plenty of time left... Don't we all? :-) > Am I correct that WGLC for these two documents ends TODAY? Technically, yes. However, the practice in RADEXT is to allow a few days grace period. That is to say, the draft is not sent off to the IESG the day after the WGLC "closes" (assuming issues are resolved). Maybe Juergen will allow the same here. I would certainly appreciate your review comments on both drafts. But the time allowed for procrastination has expired! :-) Thanks! _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 28 10:12:57 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BF628C94F; Fri, 28 Mar 2008 10:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.656 X-Spam-Level: X-Spam-Status: No, score=-100.656 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTAFCqYqjwgZ; Fri, 28 Mar 2008 10:12:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B89C28C9DA; Fri, 28 Mar 2008 10:12:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEE128C90F for ; Fri, 28 Mar 2008 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtzqdO9ub41M for ; Fri, 28 Mar 2008 10:12:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8B63C28C9DA for ; Fri, 28 Mar 2008 10:12:42 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C3018C871; Fri, 28 Mar 2008 18:12:41 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01488-05; Fri, 28 Mar 2008 18:12:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FE068760F; Fri, 28 Mar 2008 18:12:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 69EA05210CA; Fri, 28 Mar 2008 18:12:39 +0100 (CET) Date: Fri, 28 Mar 2008 18:12:39 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20080328171239.GC9916@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <006a01c890e3$8fe84900$1f0a0a0a@xpsuperdvd2> <090801c890e9$1e0dcde0$6c02a8c0@china.huawei.com> <006b01c890e9$a1855a30$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <006b01c890e9$a1855a30$1f0a0a0a@xpsuperdvd2> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Mar 28, 2008 at 11:37:29AM -0400, David B. Nelson wrote: > Technically, yes. However, the practice in RADEXT is to allow a few days > grace period. That is to say, the draft is not sent off to the IESG the day > after the WGLC "closes" (assuming issues are resolved). Maybe Juergen will > allow the same here. We urgently need more reviews. I am of course flexible with the deadline if that brings us additional reviews. But it will help me if people can send me an email indicating how much additional time they need to provide a review. Without sufficient reviews, the documents will not move forward. So please, whoever has some cycles left, help us by reading the documents and indicating your feedback. If you need more time, please let us know. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 29 08:52:51 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE453A6EFE; Sat, 29 Mar 2008 08:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.401 X-Spam-Level: X-Spam-Status: No, score=-100.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oazx9-LuBSpe; Sat, 29 Mar 2008 08:52:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01653A6EDB; Sat, 29 Mar 2008 08:52:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCE73A6E9D for ; Sat, 29 Mar 2008 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWn4MlSpeiWN for ; Sat, 29 Mar 2008 08:52:48 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 1208A3A6EF7 for ; Sat, 29 Mar 2008 08:52:48 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 6zHW1Z0060mlR8UA40FE00; Sat, 29 Mar 2008 15:51:35 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 73sg1Z0084HwxpC8X00000; Sat, 29 Mar 2008 15:52:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=hjH2OPFlJxgA:10 a=0Cl-pHTdETc6SOGFXRAA:9 a=gkI-iHKIonwJpHaZ4i4A:7 a=Tewub5GTENQ16E_Up_7n9bp6eb8A:4 a=1XvtYRSK9WUA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> Date: Sat, 29 Mar 2008 11:52:39 -0400 Message-ID: <09a301c891b4$ec440280$6c02a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> Cc: isms@ietf.org Subject: Re: [Isms] FW: RADEXT WG Last Call on NAS Management AuthorizationSpecification X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have reviewed draft-ietf-radext-management-authorization-02.txt for the WGLC and have comments. ---------------------May fix editorial------------------- Description of issue Submitter name: David Harrington Submitter email address: ietfdbh@comcast.net Date first submitted: 3-29-08 Reference: URL to e-mail describing problem, if available Document: draft-ietf-radext-management-authorization Comment type: E Priority: '1' Should fix Section: various Requested changes: throughout: "Note that" is usually unnecessary. Don't we want readers to note everything in the document, or we wouldn't have said it? section 3: OLD: "While remote management by interactive CLI sessions is carried over protocols, such as Telnet, Rlogin, and SSH, these protocols are primarily for the delivery of terminal, or pseudo-TTY services. Note that, in this context, "SSH" means the remote terminal service of SSH, not the more general protected transport service of SSH." NEW: While remote management by interactive CLI sessions is carried over protocols, such as Telnet, Rlogin, and the remote terminal service of SSH, these protocols are used in this context for the delivery of terminal, or pseudo-TTY services." section 6: OLD: "To aid in understanding of this document, it" NEW: "It" section 6: It is expected that the additional features of this document with respect to remote access to the CLI of a NAS will be used in conjunction with the existing practice regarding the NAS-Port-Type attribute described in this section. Should this also be expected of other management interfaces if this is existing practice for the vendor? section 8.2 s/The acronyms used/The names used/ I suggest the descriptions of the values should identify the threats and the mitigation provided, in a clear and unambiguous manner. For example, OLD: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide Confidentiality Protection. NEW: The transport ptotocol MUST protect against unauthorized disclosure of information. The secure transport MUST provide encryption. section 13: I have made it a practice to identify the specific registries to be modified, and the specific changes that need to be made to each registry. This is easier for IANA, and removes the chance of IANA misinterpreting what is needed. You say "RADIUS Attributes registry" - is that the RADIUS Attribute Types registry, or the RADIUS Attribute Values registry, or both? Will IANA know just which TBA should be replaced with which assigned type or value? section 14: this entions accounting, but accounting is explicitly out of scope for this document. Author's Address: Greg has no address. ---------------------Should fix editorial------------------- Description of issue Submitter name: David Harrington Submitter email address: ietfdbh@comcast.net Date first submitted: 3-29-08 Reference: URL to e-mail describing problem, if available Document: draft-ietf-radext-management-authorization Comment type: E Priority: '1' Should fix Section: various Requested changes: Section 3: OLD: "NETCONF (XML over HTTP/BEEP/SOAP)" NEW: "NETCONF (XML over SSH/BEEP/SOAP)" Section 4: VACM is composed of multiple tables OLD: (VACM) table [RFC3415], NEW: (VACM) [RFC3415], ---------------------Technical Issues------------------- Description of issue Submitter name: David Harrington Submitter email address: ietfdbh@comcast.net Date first submitted: 3-29-08 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: '1' Should fix Section: various section 8.1 (and elsewhere) Shouldn't Framed-Managament-Protocol "Web-based" (2) be HTTP or HTML/HTTP? Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS? Should we develop acronymns NETCONFS and SNMPS and CLIS so we can just lump the non-secure and secure versions into Configuration-based, and Polling-based names and so on? Should SFTP and SCP be listed separately or lumped together? section 8.2 The same "No Protection" semantics are conveyed by omitting this attribute from an Access- Accept packet." Why is this the default behavior? Wouldn't it be better to default to full security if the attribute is not present? section 8.3 The first paragrapgh says zero or more, while the fourth paragraph says you should not send two or more. OLD" "Zero or more" NEW: "Zero or one" Paragraph 3 says what to do if one is receiverd; and paragraph talks about receiving more than one. What if zero are received? Paragraph 3 says if "the policy rules are incorrectly formatted, the NAS MUST treat the packet as if it had been an Access- Reject." Doesn't this potentially override what the management protocol says should be done if the rules are incorrectly formatted? If the mgmt protocol defines an error condition for incorrectly formatted rules, that error won't be sent because the session is rejected, right? What happens if it is considered incorrect formatting to have an empty table of rules, but the operator is trying to gain mgmt access to set the policy rules into the table? Would RADIUS even know whether the rules were incorrectly formatted? section 8.4 I don't understand why we need a special Management-Privilege-Level attribute. This should be able to specified as a named policy in the Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and "2" and "3". Implementations simply need to map between the policy name and their privilege-level policy implementation. Different implementations might handle priivilege levels differently - some might use integers internally, others might use a different range of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply a mapping exercise. This is a great opportunity to suggest standard names for privilege levels, and then vendors can map those standard names to the internal routines. If vendors provide an API, operators could name the policies as they wanted and map them to the vendors' APIs for invoking different privilege levels. I do not understand "Using the Management- Privilege-Level attribute with a Service-Type attribute with a value of NAS-Prompt will have the effect of increasing the minimum privilege level. Conversely, it is NOT RECOMMENDED to use this attribute with a Service-Type of Administrative, which may require decreasing the maximum privilege level." How does it increase the minimum privilege level or decrease the maximum security level? Wouldn't this simply be implementation-dependent? section 9: I have a concern about protocol versions. What if I want SSHv2 because I don't think SSHv1 is adequate? Should I be able to make the distinction? or is that simply an operator-provisioning task to disallow SSHv1 to the device? I would change Example #4 to use a Management-Policy-ID="Level 15" rather than a Management-Privilege-Level=15 Example #5 mentions SNMPv3, but the attribute says only SNMP. If the operator should be permitted to decide which SNMP version can be used, then we need these specified as different management protocols. I think it would be better to leave the message-version decision to the SNMP standard. So I would change the example from "SNMPv3 access" to simply "SNMP access". I would change the paragraph in example #5: OLD: Note that there is currently no standardized way of implementing this management policy mapping within SNMPv3. Such mechanisms are implementation specific. NEW: "A standardized way of mapping from Management-Policy-ID to a particular access control policy in SNMP is under research." Example #6 talks about using the Secure Shell Transport Model, but most existing SNMP implementations do not support this yet. The "transport model" approach supports a binding between the SSH authenticated identity and the SNMP database access controls. Some SNMP implementations support running SNMP (any version) over an SSH tunnel, but they provide no such binding. I think it is an SNMP internal matter for SNMP access controls to say "they must use transport model to get database access". So I would remove the mention of the Secure Shell Transport Model from the example: OLD: 6. SNMP secure Transport Model access, using the Secure Shell Transport Model: NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH, to an undefined management access level: Example#8 doesn't mention which transport protocol should be used to provide security services. Should it, or is it intentional to allow any transport protocol be used that can provide Confidentiality-Protection? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 10:57:35 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0C33A6988; Mon, 31 Mar 2008 10:57:35 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E1828C13B for ; Mon, 31 Mar 2008 10:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJwzC0CVItjZ for ; Mon, 31 Mar 2008 10:57:32 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id AFEF83A6856 for ; Mon, 31 Mar 2008 10:57:30 -0700 (PDT) Received: (qmail 22229 invoked from network); 31 Mar 2008 13:57:26 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 31 Mar 2008 13:57:26 -0400 From: "David B. Nelson" To: "'David Harrington'" , References: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> <09a301c891b4$ec440280$6c02a8c0@china.huawei.com> Date: Mon, 31 Mar 2008 13:55:29 -0400 Organization: Elbrys Networks, Inc. Message-ID: <016001c89358$683d44b0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAZwwaIA== In-Reply-To: <09a301c891b4$ec440280$6c02a8c0@china.huawei.com> Cc: isms@ietf.org Subject: Re: [Isms] RADEXT WG Last Call on NAS ManagementAuthorizationSpecification X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I have reviewed draft-ietf-radext-management-authorization-02.txt > for the WGLC and have comments. Thanks you! > "Note that" is usually unnecessary. OK. That's a bit of flowery writing that isn't needed. > section 3: > OLD: "While remote management by interactive CLI > sessions is carried over protocols, such as Telnet, Rlogin, > and SSH, these protocols are primarily for the delivery of > terminal, or pseudo-TTY services. Note that, in this context, > "SSH" means the remote terminal service of SSH, not the more > general protected transport service of SSH." > NEW: While remote management by interactive CLI sessions is > carried over protocols, such as Telnet, Rlogin, and the > remote terminal service of SSH, these protocols are used > in this context for the delivery of terminal, or pseudo-TTY > services." OK. > section 6: > OLD: "To aid in understanding of this document, it" > NEW: "It" Sure. The point I was trying to convey here is that this document is not creating the usage being described here, but simply reporting it. > section 6: > It is expected that the additional features of this document with > respect to remote access to the CLI of a NAS will be used in > conjunction with the existing practice regarding the NAS-Port-Type > attribute described in this section. > Should this also be expected of other management interfaces if this is > existing practice for the vendor? I'm not sure what you are trying to ask. We acknowledge an existing practice and indicate that it is compatible with the usages defined in this document. > section 8.2 > s/The acronyms used/The names used/ OK. > I suggest the descriptions of the values should identify the threats > and the mitigation provided, in a clear and unambiguous manner. For > example, > OLD: The management session requires protection in a secure or > protected transport, that is supported by the management access > protocol and implementation. The secure transport MUST provide > Confidentiality Protection. > NEW: The transport protocol MUST protect against unauthorized > disclosure of information. The secure transport MUST provide > encryption. OK. I think that confidentiality implies the use of encryption, unless the medium of communication is physically secured, but I have no objection to your suggested text. > section 13: > I have made it a practice to identify the specific registries to be > modified, and the specific changes that need to be made to each > registry. This is easier for IANA, and removes the chance of IANA > misinterpreting what is needed. You say "RADIUS Attributes registry" - > is that the RADIUS Attribute Types registry, or the RADIUS Attribute > Values registry, or both? Both, which one depending upon context. > Will IANA know just which TBA should be replaced with which assigned > type or value? IANA gets to make up the numeric values, and hopefully can tell which is an Attribute ID code and which is a value, but we could use a notation such as TBA-A (for attribute IDs) and TBA-V (for values), if you think that would be helpful. > section 14: > this mentions accounting, but accounting is explicitly out of > scope for this document. Not entirely. Section 12 indicates that some attributes may be included in Accounting-Request packets. > Author's Address: > Greg has no address. Well, he does have one -- he just hasn't provided it the current draft. This omission will be corrected eventually -- certainly during AUTH84, if not before. > Requested changes: > Section 3: > OLD: "NETCONF (XML over HTTP/BEEP/SOAP)" > NEW: "NETCONF (XML over SSH/BEEP/SOAP)" Well, OK, I guess. Does NETCONF not have a profile for transport over HTTP? I'm a bit confused on that point. > Section 4: > VACM is composed of multiple tables > OLD: (VACM) table [RFC3415], > NEW: (VACM) [RFC3415], OK. > section 8.1 (and elsewhere) > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > HTML/HTTP? Uh, yes... > Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS? Yes, but in the -02 revision the Management-Transport-Protocol Attribute has been removed, because it seemed like unnecessary over-specification, and replaced with the Management-Transport-Protection Attribute. For that reason, your suggestion doesn't quite work. > Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just > lump the non-secure and secure versions into Configuration-based, and > Polling-based names and so on? Well, the tradition of RADIUS documents is that we describe how to provision existing services using RADIUS Attributes. We stay away from actually defining the services being provisioned, and simply provide references as appropriate. In that light, I think it might be inappropriate to define new acronyms for such services in this document. > section 8.2 > The same "No Protection" semantics are conveyed by omitting this > attribute from an Access-Accept packet." > Why is this the default behavior? Wouldn't it be better to default to > full security if the attribute is not present? In the interest of backward compatibility, it seems like de default should be no security. > section 8.3 > The first paragraph says zero or more, while the fourth paragraph > says you should not send two or more. > OLD" "Zero or more" > NEW: "Zero or one" OK. > Paragraph 3 says what to do if one is received; and paragraph talks > about receiving more than one. What if zero are received? If zero are received no management policy is applied to the provisioned service. That's universally true of RADIUS service provisioning Attributes. The absence of an Attribute generally has no significance; it does not cause any action at the NAS. > Paragraph 3 says if "the policy rules are incorrectly formatted, the > NAS MUST treat the packet as if it had been an Access-Reject." > Doesn't this potentially override what the management protocol says > should be done if the rules are incorrectly formatted? What management protocol? Are you alluding to something like the SNMP VACM? > If the mgmt protocol defines an error condition for incorrectly > formatted rules, that error won't be sent because the session is > rejected, right? Well, this is a bit murky. Traditionally, RADIUS Servers provision a service to be delivered to the user at the NAS, and the NAS is responsible for delivering that service, and not some other. If the NAS cannot deliver the service (and it knows what it is) then traditionally the NAS has been required to reject access altogether. The access protocol may or may not have an error channel for the NAS to signal to the user that the service has been denied. > What happens if it is considered incorrect formatting to have an > empty table of rules, but the operator is trying to gain mgmt access > to set the policy rules into the table? Would RADIUS even know > whether the rules were incorrectly formatted? Probably not. The NAS might know, because the term "NAS" describes the entirety of the network device or host device that contains the RADIUS Client. The RADIUS Client would almost certainly not know. In view of this, it may be better or omit the phrase "or the policy rules are incorrectly formatted". > section 8.4 > I don't understand why we need a special Management-Privilege-Level > attribute. This should be able to specified as a named policy in the > Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and > "2" and "3". Implementations simply need to map between the policy > name and their privilege-level policy implementation. Well, it's just that sort of "mapping" that this attribute was introduced to avoid. There are a significant number of currently deployed implementations that provision CLI access control using an integer-valued parameter. It is what it is. This is simply an attempt to recognize that practice and provide a way to provision that type of access control via RADIUS. We are not attempting (not should we) to redefine how CLI access control works in NASes, just how RADIUS can be use to provision it. > This is a great opportunity to suggest standard names for privilege > levels, and then vendors can map those standard names to the internal > routines. Hmmm... I think that type of standardization crosses the line into "defining the service" and would be out of scope for this document. I'd like to solicit some additional WG comment on this suggestion, before we go down that path. > I do not understand "Using the Management-Privilege-Level attribute > with a Service-Type attribute with a value of NAS-Prompt will have the > effect of increasing the minimum privilege level. Conversely, it is > NOT RECOMMENDED to use this attribute with a Service-Type of > Administrative, which may require decreasing the maximum privilege > level." > How does it increase the minimum privilege level or decrease the > maximum security level? Well, NAS-Prompt is the non-privileged CLI service and Administrative is the privileged CLI service. While implementations may vary, my understanding is that NAS-Prompt has no privileges and Administrative has all privileges (like root). Since there are only two choices, this is pretty much a binary thing -- on or off. > Wouldn't this simply be implementation-dependent? It might be... > section 9: > I have a concern about protocol versions. What if I want SSHv2 because > I don't think SSHv1 is adequate? Should I be able to make the > distinction? or is that simply an operator-provisioning task to > disallow SSHv1 to the device? The ability to specify particular transport protocols has been removed from the -02 version, and thus there is no way to specify a particular version of a particular transport protocol. I think this comes down to what is necessary and sufficient to solve the "80% problem", i.e. what will work sufficiently well in 80% of the possible deployment scenarios and use cases. I think we can easily fall into the trap of over-specifying the solution, and adding way more complexity than anyone will ever actually use (correctly). > I would change Example #4 to use a Management-Policy-ID="Level 15" > rather than a Management-Privilege-Level=15 This is dependent on resolution of a previous comment. > Example #5 mentions SNMPv3, but the attribute says only SNMP. If the > operator should be permitted to decide which SNMP version can be used, > then we need these specified as different management protocols. I > think it would be better to leave the message-version decision to the > SNMP standard. So I would change the example from "SNMPv3 access" to > simply "SNMP access". I think that the "v3" is as editing artifact, left over from the -01 version of the draft. > I would change the paragraph in example #5: > OLD: Note that there is currently no standardized way of > implementing this management policy mapping within SNMPv3. > Such mechanisms are implementation specific. > NEW: "A standardized way of mapping from Management-Policy-ID to a > particular access control policy in SNMP is under research." OK, that's fine. We can use text along those lines. > Example #6 talks about using the Secure Shell Transport Model, but > most existing SNMP implementations do not support this yet. The > "transport model" approach supports a binding between the SSH > authenticated identity and the SNMP database access controls. Some > SNMP implementations support running SNMP (any version) over an SSH > tunnel, but they provide no such binding. I think it is an SNMP > internal matter for SNMP access controls to say "they must use > transport model to get database access". So I would remove the mention > of the Secure Shell Transport Model from the example: > OLD: 6. SNMP secure Transport Model access, using the Secure Shell > Transport Model: > NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH, > to an undefined management access level: Well, there's something else wrong with Example 6. It still uses the removed [Management-]Transport-Protocol attribute. (There are several examples with this problem.) I think that this should be revised to indicate SNMP access using a particular protection level (i.e. Management-Transport-Protection). I'll submit some suggested text in a separate message dealing with errata in the examples. Perhaps we can continue the discussion on that basis? > Example#8 doesn't mention which transport protocol should be used to > provide security services. Once again, the Management-Transport-Protocol attribute has been removed from the -02 version of the draft. > Should it, or is it intentional to allow any transport protocol to be > used that can provide Confidentiality-Protection? It is intended that any transport protocol that can meet or exceed the specified minimum security protection requirement (integrity or integrity and confidentiality) can be used for the session. Thanks, once again, for your thorough and insightful review comments. Regards, Dave Nelson _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 11:01:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3D33A6DC8; Mon, 31 Mar 2008 11:01:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6103A68CE for ; Mon, 31 Mar 2008 11:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odaxx7YePn9d for ; Mon, 31 Mar 2008 11:01:37 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 347A428C213 for ; Mon, 31 Mar 2008 11:00:21 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 7sU81Z01q0vyq2s5703L00; Mon, 31 Mar 2008 17:59:07 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 7u0A1Z0014HwxpC3R00000; Mon, 31 Mar 2008 18:00:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=7-Jk3fVs3ZIgDzzkxlgA:9 a=ANQk6AW5vXDJ6KjNBXj8LMBusPUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: References: <20080327212832.GB4281@elstar.local> Date: Mon, 31 Mar 2008 14:00:09 -0400 Message-ID: <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080327212832.GB4281@elstar.local> thread-index: AciQUYUbefALLdliRQyTxIZ5jfsMZAC9ggqw Subject: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Juergen has asked for some status on open issues. The open issues list in the secshell doc is still accurate. #2 could be resolved by allowing an operator to preconfigure a MIB like usmUserTable to provide the mapping from various mechanism-specific identities to securityName. Such preconfiguration could use the identity function to set secruityName if no mapping is provided. Or, they could preconfigure in an implementation-dependent manner. Without preconfiguration, and using a default identity function, an operator would need a VACM entry for each mechanism-specific identity. #3 (same as #2; opposite direction. Not sure if there are any additional complications in this direction. #5 and #8 can be resolved by having securityModel in tmStateRef override message processing selection of model. But we would need to discuss security considerations for doing so, and check whether there are any unforeseen implications (much as doing it the current way had implications with RFC3584). If we do this, then #2 and #3 preconfiguration might become specific to each transport mapping, or share a common table. #6 is about whether the access controls applied are for the same authenticated identity (client vs server) as in USM. I think this needs further research of who must be authenticated for each operation type, and whether the security rules about which identity must be authenticated when using an operation are consistent with SSH and USM and the architecture. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, March 27, 2008 5:29 PM > To: Dave Harrington > Subject: isms open issues call > > David, > > what about a skype/phone call next Monday afternoon your time zone > (evening my time zone)? Something around 9pm would work for me, which > should be 3pm your time zone. Later is fine with me as well. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 11:02:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7488028C27C; Mon, 31 Mar 2008 11:02:30 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EBA3A6DF7 for ; Mon, 31 Mar 2008 11:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEqwMCul2uwO for ; Mon, 31 Mar 2008 11:02:29 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 2D3593A68CE for ; Mon, 31 Mar 2008 11:02:29 -0700 (PDT) Received: (qmail 22408 invoked from network); 31 Mar 2008 14:02:27 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 31 Mar 2008 14:02:27 -0400 From: "David B. Nelson" To: Date: Mon, 31 Mar 2008 14:00:30 -0400 Organization: Elbrys Networks, Inc. Message-ID: <016501c89359$1bcc5ed0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTWRuTBhkSj2gmT7qScXx6kIx4Gw== Cc: isms@ietf.org Subject: Re: [Isms] RADEXT WG Last Call on NAS Management Authorization Specification X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I have reviewed draft-ietf-radext-management-authorization-02.txt > for the WGLC and have comments. Thanks you! > "Note that" is usually unnecessary. OK. That's a bit of flowery writing that isn't needed. > section 3: > OLD: "While remote management by interactive CLI > sessions is carried over protocols, such as Telnet, Rlogin, > and SSH, these protocols are primarily for the delivery of > terminal, or pseudo-TTY services. Note that, in this context, > "SSH" means the remote terminal service of SSH, not the more > general protected transport service of SSH." > NEW: While remote management by interactive CLI sessions is > carried over protocols, such as Telnet, Rlogin, and the > remote terminal service of SSH, these protocols are used > in this context for the delivery of terminal, or pseudo-TTY > services." OK. > section 6: > OLD: "To aid in understanding of this document, it" > NEW: "It" Sure. The point I was trying to convey here is that this document is not creating the usage being described here, but simply reporting it. > section 6: > It is expected that the additional features of this document with > respect to remote access to the CLI of a NAS will be used in > conjunction with the existing practice regarding the NAS-Port-Type > attribute described in this section. > Should this also be expected of other management interfaces if this is > existing practice for the vendor? I'm not sure what you are trying to ask. We acknowledge an existing practice and indicate that it is compatible with the usages defined in this document. > section 8.2 > s/The acronyms used/The names used/ OK. > I suggest the descriptions of the values should identify the threats > and the mitigation provided, in a clear and unambiguous manner. For > example, > OLD: The management session requires protection in a secure or > protected transport, that is supported by the management access > protocol and implementation. The secure transport MUST provide > Confidentiality Protection. > NEW: The transport protocol MUST protect against unauthorized > disclosure of information. The secure transport MUST provide > encryption. OK. I think that confidentiality implies the use of encryption, unless the medium of communication is physically secured, but I have no objection to your suggested text. > section 13: > I have made it a practice to identify the specific registries to be > modified, and the specific changes that need to be made to each > registry. This is easier for IANA, and removes the chance of IANA > misinterpreting what is needed. You say "RADIUS Attributes registry" - > is that the RADIUS Attribute Types registry, or the RADIUS Attribute > Values registry, or both? Both, which one depending upon context. > Will IANA know just which TBA should be replaced with which assigned > type or value? IANA gets to make up the numeric values, and hopefully can tell which is an Attribute ID code and which is a value, but we could use a notation such as TBA-A (for attribute IDs) and TBA-V (for values), if you think that would be helpful. > section 14: > this mentions accounting, but accounting is explicitly out of > scope for this document. Not entirely. Section 12 indicates that some attributes may be included in Accounting-Request packets. > Author's Address: > Greg has no address. Well, he does have one -- he just hasn't provided it the current draft. This omission will be corrected eventually -- certainly during AUTH84, if not before. > Requested changes: > Section 3: > OLD: "NETCONF (XML over HTTP/BEEP/SOAP)" > NEW: "NETCONF (XML over SSH/BEEP/SOAP)" Well, OK, I guess. Does NETCONF not have a profile for transport over HTTP? I'm a bit confused on that point. > Section 4: > VACM is composed of multiple tables > OLD: (VACM) table [RFC3415], > NEW: (VACM) [RFC3415], OK. > section 8.1 (and elsewhere) > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > HTML/HTTP? Uh, yes... > Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS? Yes, but in the -02 revision the Management-Transport-Protocol Attribute has been removed, because it seemed like unnecessary over-specification, and replaced with the Management-Transport-Protection Attribute. For that reason, your suggestion doesn't quite work. > Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just > lump the non-secure and secure versions into Configuration-based, and > Polling-based names and so on? Well, the tradition of RADIUS documents is that we describe how to provision existing services using RADIUS Attributes. We stay away from actually defining the services being provisioned, and simply provide references as appropriate. In that light, I think it might be inappropriate to define new acronyms for such services in this document. > section 8.2 > The same "No Protection" semantics are conveyed by omitting this > attribute from an Access-Accept packet." > Why is this the default behavior? Wouldn't it be better to default to > full security if the attribute is not present? In the interest of backward compatibility, it seems like de default should be no security. > section 8.3 > The first paragraph says zero or more, while the fourth paragraph > says you should not send two or more. > OLD" "Zero or more" > NEW: "Zero or one" OK. > Paragraph 3 says what to do if one is received; and paragraph talks > about receiving more than one. What if zero are received? If zero are received no management policy is applied to the provisioned service. That's universally true of RADIUS service provisioning Attributes. The absence of an Attribute generally has no significance; it does not cause any action at the NAS. > Paragraph 3 says if "the policy rules are incorrectly formatted, the > NAS MUST treat the packet as if it had been an Access-Reject." > Doesn't this potentially override what the management protocol says > should be done if the rules are incorrectly formatted? What management protocol? Are you alluding to something like the SNMP VACM? > If the mgmt protocol defines an error condition for incorrectly > formatted rules, that error won't be sent because the session is > rejected, right? Well, this is a bit murky. Traditionally, RADIUS Servers provision a service to be delivered to the user at the NAS, and the NAS is responsible for delivering that service, and not some other. If the NAS cannot deliver the service (and it knows what it is) then traditionally the NAS has been required to reject access altogether. The access protocol may or may not have an error channel for the NAS to signal to the user that the service has been denied. > What happens if it is considered incorrect formatting to have an > empty table of rules, but the operator is trying to gain mgmt access > to set the policy rules into the table? Would RADIUS even know > whether the rules were incorrectly formatted? Probably not. The NAS might know, because the term "NAS" describes the entirety of the network device or host device that contains the RADIUS Client. The RADIUS Client would almost certainly not know. In view of this, it may be better or omit the phrase "or the policy rules are incorrectly formatted". > section 8.4 > I don't understand why we need a special Management-Privilege-Level > attribute. This should be able to specified as a named policy in the > Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and > "2" and "3". Implementations simply need to map between the policy > name and their privilege-level policy implementation. Well, it's just that sort of "mapping" that this attribute was introduced to avoid. There are a significant number of currently deployed implementations that provision CLI access control using an integer-valued parameter. It is what it is. This is simply an attempt to recognize that practice and provide a way to provision that type of access control via RADIUS. We are not attempting (not should we) to redefine how CLI access control works in NASes, just how RADIUS can be use to provision it. > This is a great opportunity to suggest standard names for privilege > levels, and then vendors can map those standard names to the internal > routines. Hmmm... I think that type of standardization crosses the line into "defining the service" and would be out of scope for this document. I'd like to solicit some additional WG comment on this suggestion, before we go down that path. > I do not understand "Using the Management-Privilege-Level attribute > with a Service-Type attribute with a value of NAS-Prompt will have the > effect of increasing the minimum privilege level. Conversely, it is > NOT RECOMMENDED to use this attribute with a Service-Type of > Administrative, which may require decreasing the maximum privilege > level." > How does it increase the minimum privilege level or decrease the > maximum security level? Well, NAS-Prompt is the non-privileged CLI service and Administrative is the privileged CLI service. While implementations may vary, my understanding is that NAS-Prompt has no privileges and Administrative has all privileges (like root). Since there are only two choices, this is pretty much a binary thing -- on or off. > Wouldn't this simply be implementation-dependent? It might be... > section 9: > I have a concern about protocol versions. What if I want SSHv2 because > I don't think SSHv1 is adequate? Should I be able to make the > distinction? or is that simply an operator-provisioning task to > disallow SSHv1 to the device? The ability to specify particular transport protocols has been removed from the -02 version, and thus there is no way to specify a particular version of a particular transport protocol. I think this comes down to what is necessary and sufficient to solve the "80% problem", i.e. what will work sufficiently well in 80% of the possible deployment scenarios and use cases. I think we can easily fall into the trap of over-specifying the solution, and adding way more complexity than anyone will ever actually use (correctly). > I would change Example #4 to use a Management-Policy-ID="Level 15" > rather than a Management-Privilege-Level=15 This is dependent on resolution of a previous comment. > Example #5 mentions SNMPv3, but the attribute says only SNMP. If the > operator should be permitted to decide which SNMP version can be used, > then we need these specified as different management protocols. I > think it would be better to leave the message-version decision to the > SNMP standard. So I would change the example from "SNMPv3 access" to > simply "SNMP access". I think that the "v3" is as editing artifact, left over from the -01 version of the draft. > I would change the paragraph in example #5: > OLD: Note that there is currently no standardized way of > implementing this management policy mapping within SNMPv3. > Such mechanisms are implementation specific. > NEW: "A standardized way of mapping from Management-Policy-ID to a > particular access control policy in SNMP is under research." OK, that's fine. We can use text along those lines. > Example #6 talks about using the Secure Shell Transport Model, but > most existing SNMP implementations do not support this yet. The > "transport model" approach supports a binding between the SSH > authenticated identity and the SNMP database access controls. Some > SNMP implementations support running SNMP (any version) over an SSH > tunnel, but they provide no such binding. I think it is an SNMP > internal matter for SNMP access controls to say "they must use > transport model to get database access". So I would remove the mention > of the Secure Shell Transport Model from the example: > OLD: 6. SNMP secure Transport Model access, using the Secure Shell > Transport Model: > NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH, > to an undefined management access level: Well, there's something else wrong with Example 6. It still uses the removed [Management-]Transport-Protocol attribute. (There are several examples with this problem.) I think that this should be revised to indicate SNMP access using a particular protection level (i.e. Management-Transport-Protection). I'll submit some suggested text in a separate message dealing with errata in the examples. Perhaps we can continue the discussion on that basis? > Example#8 doesn't mention which transport protocol should be used to > provide security services. Once again, the Management-Transport-Protocol attribute has been removed from the -02 version of the draft. > Should it, or is it intentional to allow any transport protocol to be > used that can provide Confidentiality-Protection? It is intended that any transport protocol that can meet or exceed the specified minimum security protection requirement (integrity or integrity and confidentiality) can be used for the session. Thanks, once again, for your thorough and insightful review comments. Regards, Dave Nelson _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 13:01:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBBF28C44C; Mon, 31 Mar 2008 13:01:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8003A6BEF for ; Mon, 31 Mar 2008 13:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VI0h+2tzYNZ for ; Mon, 31 Mar 2008 13:01:26 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 5FD7E28C47F for ; Mon, 31 Mar 2008 13:00:54 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 7v1u1Z0020ldTLk5503n00; Mon, 31 Mar 2008 19:59:25 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 7w0k1Z00N4HwxpC3Q00000; Mon, 31 Mar 2008 20:00:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=5nv-wM5pOgcA:10 a=EJiopUHZBP4fampjh0YA:9 a=DQTEW-Ngp6kfvSauf0gA:7 a=F9w3CAB3IxSMIYTtd0eG4OG4t9kA:4 a=-utQw5L2n1AA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'David B. Nelson'" , References: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> <09a301c891b4$ec440280$6c02a8c0@china.huawei.com> <016001c89358$683d44b0$1f0a0a0a@xpsuperdvd2> Date: Mon, 31 Mar 2008 16:00:44 -0400 Message-ID: <00c601c89369$e81e7b20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <016001c89358$683d44b0$1f0a0a0a@xpsuperdvd2> thread-index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAZwwaIAAJ0JTw Cc: isms@ietf.org Subject: Re: [Isms] RADEXT WG Last Call on NAS ManagementAuthorizationSpecification X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > Sent: Monday, March 31, 2008 1:55 PM > To: 'David Harrington'; radiusext@ietf.org > Cc: isms@ietf.org > Subject: RE: RADEXT WG Last Call on NAS > ManagementAuthorizationSpecification > > > section 13: > > I have made it a practice to identify the specific registries to be > > modified, and the specific changes that need to be made to each > > registry. This is easier for IANA, and removes the chance of IANA > > misinterpreting what is needed. You say "RADIUS Attributes > registry" - > > is that the RADIUS Attribute Types registry, or the RADIUS Attribute > > Values registry, or both? > > Both, which one depending upon context. My intent was to ask you to spell out in detail which changes you want made to which registry, and then to this document, so IANA doesn't have to figure it out. > > Requested changes: > > Section 3: > > OLD: "NETCONF (XML over HTTP/BEEP/SOAP)" > > NEW: "NETCONF (XML over SSH/BEEP/SOAP)" > > Well, OK, I guess. Does NETCONF not have a profile for > transport over HTTP? > I'm a bit confused on that point. RFCs 4742, 43, and 44 defines transports for SSH, SOAP, and BEEP respectively. There is no separate mapping for HTTP. > > Isn't HTTPS Framed-Management-Protocol=HTTP plus > Transport-Protocol=TLS? > > Yes, but in the -02 revision the > Management-Transport-Protocol Attribute has > been removed, because it seemed like unnecessary > over-specification, and > replaced with the Management-Transport-Protection Attribute. For that > reason, your suggestion doesn't quite work. Transport-Protocol still shows up in section9, and possibly elsewhere in -02-. > > > Should we develop acronyms NETCONFS and SNMPS and CLIS so > we can just > > lump the non-secure and secure versions into > Configuration-based, and > > Polling-based names and so on? > > Well, the tradition of RADIUS documents is that we describe > how to provision > existing services using RADIUS Attributes. We stay away from actually > defining the services being provisioned, and simply provide > references as > appropriate. In that light, I think it might be > inappropriate to define new > acronyms for such services in this document. I was being sarcastic. > > > section 8.2 > > The same "No Protection" semantics are conveyed by omitting this > > attribute from an Access-Accept packet." > > Why is this the default behavior? Wouldn't it be better to > default to > > full security if the attribute is not present? > > In the interest of backward compatibility, it seems like de > default should > be no security. I disagree. > > Paragraph 3 says if "the policy rules are incorrectly formatted, the > > NAS MUST treat the packet as if it had been an Access-Reject." > > Doesn't this potentially override what the management protocol says > > should be done if the rules are incorrectly formatted? > > What management protocol? Are you alluding to something like > the SNMP VACM? Yes, the implementation of the access control mechanism is the only thing that willl have enough knowledge of the rules to know if they are incorrectly formatted. Certainly, the RADIUS client is not expected to know if VACM rules are incorrectly formatted. I think it is a "layer violation" to expect the NAS to apply a RADIUS-specific error responde to a non-RADIUS configuration error. That error should be detected either when the access control policies are being configured, e.g. via Netconf or SNMP, or when the policies are being enforced. The configuration of the access control policies is out of scope of this document. Likewise, if I send a faulty shell script to an interactive shell interface, I do not expect to get a RADIUS response to this condition; I expect to get a shell-specific response. > > > If the mgmt protocol defines an error condition for incorrectly > > formatted rules, that error won't be sent because the session is > > rejected, right? > > Well, this is a bit murky. Traditionally, RADIUS Servers provision a > service to be delivered to the user at the NAS, and the NAS > is responsible > for delivering that service, and not some other. If the NAS > cannot deliver > the service (and it knows what it is) then traditionally the > NAS has been > required to reject access altogether. The access protocol > may or may not > have an error channel for the NAS to signal to the user that > the service has > been denied. > > > What happens if it is considered incorrect formatting to have an > > empty table of rules, but the operator is trying to gain mgmt access > > to set the policy rules into the table? Would RADIUS even know > > whether the rules were incorrectly formatted? > > Probably not. The NAS might know, because the term "NAS" > describes the > entirety of the network device or host device that contains the RADIUS > Client. The RADIUS Client would almost certainly not know. > > In view of this, it may be better or omit the phrase "or the > policy rules > are incorrectly formatted". Yes. I believe it would be better to drop that clause. > > > section 8.4 > > I don't understand why we need a special Management-Privilege-Level > > attribute. This should be able to specified as a named policy in the > > Management-Policy-ID, such as "Level 1" and "Level 2", or > even "1" and > > "2" and "3". Implementations simply need to map between the policy > > name and their privilege-level policy implementation. > > Well, it's just that sort of "mapping" that this attribute > was introduced to > avoid. There are a significant number of currently deployed > implementations > that provision CLI access control using an integer-valued > parameter. It is > what it is. This is simply an attempt to recognize that practice and > provide a way to provision that type of access control via > RADIUS. We are > not attempting (not should we) to redefine how CLI access > control works in > NASes, just how RADIUS can be use to provision it. So the "mapping" would simply be to take privelege level policy name "1" or "Level 1" and run it through an asctoint() function as part of the processing of management-policy-id. > > > This is a great opportunity to suggest standard names for privilege > > levels, and then vendors can map those standard names to > the internal > > routines. > > Hmmm... I think that type of standardization crosses the line into > "defining the service" and would be out of scope for this > document. I'd > like to solicit some additional WG comment on this > suggestion, before we go > down that path. Actually, it is only defining a recommendation for how to "name" the policies for use with management-policy-id. If we shouldn't be "defining the service" then I have to question whether we should be providing this other type of mapping for privilege level. I far as I can see, either approach is defining recommending naming for a policy; using privilege-level requires an extra attribute for this specific policy mechanism; using manageent-policy-id uses a consistent machanism for identifying policies regardless of management protocol. My understanding is RADIUS attributes are scarce, so why waste one unnecessarily? > > > I do not understand "Using the Management-Privilege-Level attribute > > with a Service-Type attribute with a value of NAS-Prompt > will have the > > effect of increasing the minimum privilege level. > Conversely, it is > > NOT RECOMMENDED to use this attribute with a Service-Type of > > Administrative, which may require decreasing the maximum privilege > > level." > > How does it increase the minimum privilege level or decrease the > > maximum security level? > > Well, NAS-Prompt is the non-privileged CLI service and > Administrative is the > privileged CLI service. While implementations may vary, my > understanding is > that NAS-Prompt has no privileges and Administrative has all > privileges > (like root). Since there are only two choices, this is > pretty much a binary > thing -- on or off. > > > Wouldn't this simply be implementation-dependent? > > It might be... So if I set a level of '0' to be exactly the same as NAS-Prompt, and a level of '16' to be the same as Administrtaive, how does my usage increase/decrease privileges? What if I set a level of '2' to match NAS-Prompt, and define new evels 0 and 1 to have even less privilege, how does using this increase/decrease privileges? It seems to be implementation-dependent. > > > section 9: > > I have a concern about protocol versions. What if I want > SSHv2 because > > I don't think SSHv1 is adequate? Should I be able to make the > > distinction? or is that simply an operator-provisioning task to > > disallow SSHv1 to the device? > > The ability to specify particular transport protocols has > been removed from > the -02 version, and thus there is no way to specify a > particular version of > a particular transport protocol. I think this comes down to what is > necessary and sufficient to solve the "80% problem", i.e. > what will work > sufficiently well in 80% of the possible deployment scenarios > and use cases. > I think we can easily fall into the trap of over-specifying > the solution, > and adding way more complexity than anyone will ever actually use > (correctly). Traponsport-Protocol is still in the official version of -02-. See section 8.2, section #3 and #6, and section 14. > Well, there's something else wrong with Example 6. It still uses the > removed [Management-]Transport-Protocol attribute. (There are several > examples with this problem.) I think that this should be revised to > indicate SNMP access using a particular protection level (i.e. > Management-Transport-Protection). > > Should it, or is it intentional to allow any transport > protocol to be > > used that can provide Confidentiality-Protection? > > It is intended that any transport protocol that can meet or exceed the > specified minimum security protection requirement (integrity > or integrity > and confidentiality) can be used for the session. I have a concern with removing transport-protocol. IPSec can provide a fully-secured tunnel, but it never authenticates the principal that is used at the application layer. nor does TLS. SSH provides user-authentication at a level above transport. If we remove the operator choice of tunnel protocol, I fear we might under-specify what is needed to secure a management protocol. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 14:52:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E923A6A82; Mon, 31 Mar 2008 14:52:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83C23A6B3F for ; Mon, 31 Mar 2008 14:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMv6eY9ej9zl for ; Mon, 31 Mar 2008 14:52:32 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 9AE983A6948 for ; Mon, 31 Mar 2008 14:52:32 -0700 (PDT) Received: (qmail 26032 invoked from network); 31 Mar 2008 16:52:25 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 31 Mar 2008 16:52:25 -0400 From: "David B. Nelson" To: "'David Harrington'" , References: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> <09a301c891b4$ec440280$6c02a8c0@china.huawei.com> <016001c89358$683d44b0$1f0a0a0a@xpsuperdvd2> <00c601c89369$e81e7b20$0600a8c0@china.huawei.com> Date: Mon, 31 Mar 2008 16:50:28 -0400 Organization: Elbrys Networks, Inc. Message-ID: <017001c89370$da42f2e0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAZwwaIAAJ0JTwAAIQldA= In-Reply-To: <00c601c89369$e81e7b20$0600a8c0@china.huawei.com> Cc: isms@ietf.org Subject: Re: [Isms] RADEXT WG Last Call on NAS ManagementAuthorizationSpecification X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > My intent was to ask you to spell out in detail which changes you > want made to which registry, and then to this document, so IANA > doesn't have to figure it out. Yes, I got that point. Thanks. That issue will be clarified in -03. > RFCs 4742, 43, and 44 defines transports for SSH, SOAP, and BEEP > respectively. There is no separate mapping for HTTP. Separate mapping? I guess I need to learn a bunch more about NTECONF... > Transport-Protocol still shows up in section 9, and possibly elsewhere > in -02-. Yes, but I've indicated that is an error in -02, and I described in a previous posting to the RADEXT list that it was being removed, and why it was being removed. For the sake of comments on -02, please assume it is gone. > I was being sarcastic. Sorry, I couldn't tell. :-( > > > Why is this the default behavior? Wouldn't it be better to > > > default to full security if the attribute is not present? > > > > In the interest of backward compatibility, it seems like de > > default should be no security. > > I disagree. You disagree that we should optimize for backward compatibility, or you disagree that defaulting to fully secure would hinder backwards compatibility? > > In view of this, it may be better or omit the phrase "or the > > policy rules are incorrectly formatted". > > Yes. I believe it would be better to drop that clause. OK. > So the "mapping" would simply be to take privilege level policy name > "1" or "Level 1" and run it through an asctoint() function as part of > the processing of management-policy-id. The content of Management-Policy-Id is intended to be a flat name of local scope. The only valid operators on this name are strncmp() or strncasecmp(). That is to say, no transforms are anticipated, other than a lookup using it as a search key. Anything else is fraught with interoperability perils, IMO. > Actually, it is only defining a recommendation for how to "name" the > policies for use with management-policy-id. If we can't (and don't) make such recommendations for the content of Filter-Id, how could we do so for Management-Policy-Id? > So if I set a level of '0' to be exactly the same as NAS-Prompt, and a > level of '16' to be the same as Administrative, how does my usage > increase/decrease privileges? For all values of the Management-Privilege-Level attribute (call it X), where 0 < X < 16, using that attribute in conjunction with a Service-Type value of NAS-Prompt will elevate the effective CLI privilege level, and similarly using that attribute in conjunction with a Service-Type value of Administrative will lower the effective CLI privilege. > Transport-Protocol is still in the official version of -02-. See > section 8.2, section #3 and #6, and section 14. See above. This is an oversight. > I have a concern with removing transport-protocol. Ah, that we can discuss. > IPSec can provide a fully-secured tunnel, but it never authenticates > the principal that is used at the application layer. nor does TLS. > SSH provides user-authentication at a level above transport. The current proposal, as intended by the -02 draft, is to provision a minimum security requirement, that the NAS is expected to check and enforce, as to whether or not the management transport protocol is (a) integrity-protected (cryptographically check-summed) and (b) confidentiality protected (encrypted). In order to implement this proposal, the NAS (not just the RADIUS Client portion of the NAS) MUST be able to determine if the required protection is present. Authentication of the principal is handled via the traditional authentication mechanisms of RADIUS, and therefore need not be handled by the secure transport. It is possible, of course, that the secure transport participates in providing the principal's identity to the RADIUS Client for the purpose of authentication. > If we remove the operator choice of tunnel protocol, I fear we might > under-specify what is needed to secure a management protocol. Let's pursue this a bit. If we specify the tunnel protocol, then we also need to specify other properties. Bernard Aboba pointed that out in his commentary on the -01 draft. We then specify the authentication mechanism. This could involve specification of optional cipher suites. We could specify certificates, types of certificates, and certificate authorities, etc. This can get very complicated, very fast. Do we really want or need to go there? :-) My answer to Bernard's commentary was to step back and try to discern what problem we really needed to solve. While specifying all the security properties and options of the secure transport protocol and its support ecosystem may be needed in some environments, I think it is not required in the vast majority of environments. Let's solve a simple problem that we can solve well, and then see if further work is needed later on, once we have some deployment experience. Knowing that your principal has been authenticated (and authorized) and that the management session is protected from tampering and disclosure is probably all that the RADIUS Server, and the system administrator, need to provision. Additional details, such as a list of acceptable tunnel protocols, cipher suites, certificate chains, etc, can be provisioned on the NAS in an implementation-specific fashion. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 31 16:48:50 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7869B3A6CDD; Mon, 31 Mar 2008 16:48:50 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD393A6CDD for ; Mon, 31 Mar 2008 16:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MDNtFCUEh5V for ; Mon, 31 Mar 2008 16:48:48 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 25D423A6CEE for ; Mon, 31 Mar 2008 16:48:46 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 7wl51Z00117dt5G5206U00; Mon, 31 Mar 2008 23:47:40 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 7znn1Z0074HwxpC3Z00000; Mon, 31 Mar 2008 23:47:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=oFKCs4az47lesARtlSEA:9 a=4iDZgKyMi5hfh1q6u1kA:7 a=YPcvseqOvZ_VDQG96VyIKe4DEAYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Mon, 31 Mar 2008 19:47:46 -0400 Message-ID: <00d701c89389$9f805710$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQ== Subject: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have reviewed this document. Comments below. I found the text within the document well-written, and much more compatible with other ISMS documents than I recall was true of previous versions. There is still much work to be done however. I found the document a little hard to read because background info on RADIUS, info on the managament-policy-id related attributes, and the mapping to SNMP are all mushed together. Throughout the document there are clauses/phrases such as "as defined in this document" and "as described herein" that are effectively forward references to a discussion of the management-policy-id attributes which is done somewhat late in the document. I found this style irritating. Why not tell us what the attributes are early on, and then you don't need all the "as defined later in this document" phrases. In discussing the mapping to SNMP, PLEASE assume that the management-policy-id has already been accepted by the IETF. It makes no sense to publish this document if that is not true, so the status of the attributes should not need to be endlessly qualified - just assume they are approved. That measn a lot of the phrases like "RADIUS servers compliant to this specification" can just be reduced to "RADIUS servers". So, I recommend the document have sections 1) introduction to standard RADIUS, 2) introduction to the management-policy-id and related attributes, and THEN discuss the mapping to SNMP (Actually, I would be fine with having the first two combined or possibly eliminated). I think this document should be written as one of multiple mapping documents for the management-policy-id and related attributes, and it should be expected that a mapping document will be done at some point for Netconf, the CLI, and potentially other interfaces. State that readers of this "mapping" document should already be aware of how RADIUS works, and the management-related attributes. If you do this, you can probably eliminate most of the tutorial for RADIUS and the management-related attributes and just focus on doing the mapping to SNMP. 1. I recommend moving the "Requirements language" text into a section, possibly under Introduction. section 1.1 - we don't have modules in ISMS, we have models and subsystems. s/secure transport module/secure transport model/ s/modules/models/ or s/modules/subsystems/ I'm sure there are more uses of module in this document. They should be replaced accordingly. section 1.2 says "An Access-Reject message indicates unsuccessful authentication." Does it also indicate an unsuccessful authorization? section 2 says "Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP over a specific secure Transport Model. I think that is incorrect. The attributes we intend to use here authorize the use of a service for Framed-Management, the Framed-Management-Protocol to use (SNMP), a Managament-Policy-ID (such as "Operator"), and a level of Transport-Protection. Apparently, radext will not permit us to select the transport-protocol, and they certainly will not allow us to specify a spewcific SNMP transport model. Right? section 2 discusses PAM; how do RADIUS servers in a Windows environment do this? Is there a Windows equivalent? s/rely of/rely on/ section 2.1 "Specific attributes for use with SNMP Transport Models are recommended in this document." I don't think this document should be used to make recommendations of specific RADIUS attributes. This document should simply be about how to use the management-related attributes that are defined, in an SNMP environment. s/"RADIUS servers, compliant to this specification, MAY use RADIUS hint attributes, as described herein, to inform the decision whether to accept or reject the authentication request."/ RADIUS servers MAY use RADIUS hint attributes to inform the decision whether to accept or reject the authentication request."/ OR RADIUS servers MAY use the management-related hint attributes to inform the decision whether to accept or reject the authentication request for the SNMP service." (but isn't the hint really part of an authorizarion request rather than an authentication request? I might be able to authenticate who I am, but still not get approval to access the SNMP service.") section 2.2 eliminate the sentence " Specific attributes for use with SNMP Transport Models are recommended in this document." " The following RADIUS attributes MAY be optionally used, to authorize use of SNMP over the default UDP transport protocol (no privacy):" What transport model calls RADIUS to authenticate a UDP session? This is news to me. " The following RADIUS attributes are used to limit the extent of a secure transport session carrying SNMP traffic, in conjunction with an SNMP Transport Model: 1. Session-Timeout 2. Inactivity-Timeout." What transport model does this? I haven't seen one use these. I think this is between RADIUS and the transport protocol that is using RADIUS, such as SSH. I don't think SNMP has anything to do with this, and there is no place in the ISMS architecture to specify these values. I am not sure they should be discussed in this document. Is this Inactivity-Timeout related to the Idle-Timeout mentioned later? section 2.4. I think the authorization attributes provided by RADIUS should probably be captured as part of the LCD, as part of transport-specific information. section 3 shoul dbe part of the introduction to RADIUS and the management related attributes. It seems out of place here. section 5 s/Threats and security issues for this application are described in [RFC3579] and [RFC3580]; " /Threats and security issues for RADIUS are described in [RFC3579] and [RFC3580];/ Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the discussion of using RADIUS with these needs further discussion. Currently, SNMPv1 can be used with an SSH tunnel, with no transport model to provide a binding; we might deveop a transport model with a binding. The RADIUS attributes for managament, however, may not allow us to choose which transport model or even which transport protocol, and under those conditions, I don't know what we have for security with an SNMPv1 or SNMPv2c (or SNMPv3) message, since we may have no transport model to provide a mapping between the transport layer credentials and the SNMP-specific securityModel/Name/Level. The "this may not be expected" would probably be better phrased as "the authenticated identity used for securityName will not be the identity authenticated by RADIUS". David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms