From ietfdbh@comcast.net Mon Mar 1 09:27:05 2010 Return-Path: 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 A482A28C14F for ; Mon, 1 Mar 2010 09:27:05 -0800 (PST) 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 cW99jbqdIliK for ; Mon, 1 Mar 2010 09:27:04 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 9524C28C14C for ; Mon, 1 Mar 2010 09:27:04 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta12.emeryville.ca.mail.comcast.net with comcast id nt3a1d0041ZMdJ4ACtT6Ux; Mon, 01 Mar 2010 17:27:06 +0000 Received: from Harrington73653 ([209.31.239.147]) by omta16.emeryville.ca.mail.comcast.net with comcast id ntVe1d00J3BWNmh8ctVhEh; Mon, 01 Mar 2010 17:29:51 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <001f01cab6ac$d60a2660$6801a8c0@oemcomputer> <20100226084549.GC33124@elstar.local> Date: Mon, 1 Mar 2010 09:26:31 -0800 Message-ID: <02e901cab964$5c152c00$242630b8@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100226084549.GC33124@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq2wCS/26hLsyyqS1mdmslRG8ZxGQCpCzJw Cc: isms@ietf.org Subject: Re: [Isms] RADIUS/VACM issue 3 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: , X-List-Received-Date: Mon, 01 Mar 2010 17:27:05 -0000 agreed. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, February 26, 2010 12:46 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] RADIUS/VACM issue 3 > > On Fri, Feb 26, 2010 at 07:27:56AM +0100, Randy Presuhn wrote: > > Hi - > > > > The current issue list says: > > 3. Dave Harrington had issued a summary email after IETF75 > > containing apparently contradictory statements about > whether the > > additional columns should be in the *same* table > that VACM uses > > or in another, separate table that augments the VACM table. > > Basically, we need some help in actually structuring > the new MIB > > Module. > > > > I think we can close this one. We have a single table which > > sparsely extends / augments the vacmSecurityToGroupTable, along > > with elements of procedures for creating, updating, and deleting > > entries in the vacmSecurityToGroupTable. > > I agree. > > /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 ietfdbh@comcast.net Mon Mar 1 11:26:16 2010 Return-Path: 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 6AD9928C53A for ; Mon, 1 Mar 2010 11:26:16 -0800 (PST) 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 RObbzVm+PMTM for ; Mon, 1 Mar 2010 11:26:15 -0800 (PST) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 9321328C522 for ; Mon, 1 Mar 2010 11:26:15 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta08.emeryville.ca.mail.comcast.net with comcast id nrNm1d0020cQ2SLA8vSHFT; Mon, 01 Mar 2010 19:26:17 +0000 Received: from Harrington73653 ([209.31.239.147]) by omta10.emeryville.ca.mail.comcast.net with comcast id nvS61d0063BWNmh8WvS8A2; Mon, 01 Mar 2010 19:26:15 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer><20100226085255.GE33124@elstar.local> <001c01cab6c3$de47b600$6801a8c0@oemcomputer> Date: Mon, 1 Mar 2010 11:26:05 -0800 Message-ID: <02f101cab975$0ecb09e0$242630b8@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001c01cab6c3$de47b600$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq2wy/I0Y6AGXXmQ5OwJFoqJ4Zz8QCsTg4w Subject: Re: [Isms] RADIUS/VACM issue 6 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: , X-List-Received-Date: Mon, 01 Mar 2010 19:26:16 -0000 hi, I am away from this discussion, so I'm dealing with the question out of context. what would another reasonable choice? I believe it was/is important that this is the **transport model** session ID, not the **transport** session id. I think that was the point of the comment. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Friday, February 26, 2010 1:13 AM > To: isms@ietf.org > Subject: Re: [Isms] RADIUS/VACM issue 6 > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Friday, February 26, 2010 12:52 AM > > Subject: Re: [Isms] RADIUS/VACM issue 6 > ... > > Would it make sense to spell out that this could be the > tlstmSessionID > > so that implementors do not have to wonder why > tlstmSessionID was not > > picked in the first place? It might be OK to allow other identifiers > > but since the object name carries SessionID in its name, it > might even > > make sense to default this to tlstmSessionID, no? > > How about this? > > extVacmTransportSessionID OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION "A transport model-specific identifier of the > session. This value MUST be unique among all > of a given transport model's currently open sessions. > The value has no particular significance other > to distinguish sessions. An example of a suitable > value would be tlstmSessionID." > ::= { extVacmSecurityToGroupEntry 3 } > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From randy_presuhn@mindspring.com Mon Mar 1 11:39:37 2010 Return-Path: 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 21B543A8B9F for ; Mon, 1 Mar 2010 11:39:37 -0800 (PST) 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 j1ib7Gv+Gp1D for ; Mon, 1 Mar 2010 11:39:36 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 024F83A8AFA for ; Mon, 1 Mar 2010 11:39:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kxtTF36CUFo1q5XjfR2acfI2yL/IYMEB/3+2Uuihku3J0J6O5RIHzC00+hiQDqOE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.243] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NmBSq-0000wb-7p for isms@ietf.org; Mon, 01 Mar 2010 14:39:36 -0500 Message-ID: <008a01cab977$108cf340$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer><20100226085255.GE33124@elstar.local> <001c01cab6c3$de47b600$6801a8c0@oemcomputer> <02f101cab975$0ecb09e0$242630b8@china.huawei.com> Date: Mon, 1 Mar 2010 11:40:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40224d185973fbb5013be27f612229489c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.243 Subject: Re: [Isms] RADIUS/VACM issue 6 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: , X-List-Received-Date: Mon, 01 Mar 2010 19:39:37 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; > Sent: Monday, March 01, 2010 11:26 AM > Subject: RE: [Isms] RADIUS/VACM issue 6 ... > I am away from this discussion, so I'm dealing with the question out > of context. > what would another reasonable choice? > I believe it was/is important that this is the **transport model** > session ID, > not the **transport** session id. > I think that was the point of the comment. Ok, I'll make the change. As a matter of "minimum critical specification", it needs to be unique within the scope of a security model, which would make a difference if we ever get a security model that somehow supported multiple transport models. From an implementor's point of view, this seems very straightforward, but it's not clear to me how it fits in with the transport subsystem architecture. (Though this document is clearly *not* the place to try to clarify how the transport subsystem works!) I'd appreciate guidance on the terminology here - e.g. when to use "secure transport model", "transport model" and "security model". Randy From wjhns1@hardakers.net Mon Mar 1 14:47:08 2010 Return-Path: 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 D244828C1DD for ; Mon, 1 Mar 2010 14:47:08 -0800 (PST) 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 vha0i2BtafDH for ; Mon, 1 Mar 2010 14:47:08 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id E8C2B28C150 for ; Mon, 1 Mar 2010 14:47:07 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BE6EB9C422; Mon, 1 Mar 2010 14:47:07 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> <20100226085255.GE33124@elstar.local> <001c01cab6c3$de47b600$6801a8c0@oemcomputer> Date: Mon, 01 Mar 2010 14:47:07 -0800 In-Reply-To: <001c01cab6c3$de47b600$6801a8c0@oemcomputer> (Randy Presuhn's message of "Fri, 26 Feb 2010 01:12:48 -0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] RADIUS/VACM issue 6 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: , X-List-Received-Date: Mon, 01 Mar 2010 22:47:08 -0000 >>>>> On Fri, 26 Feb 2010 01:12:48 -0800, "Randy Presuhn" said: RP> How about this? RP> extVacmTransportSessionID OBJECT-TYPE RP> SYNTAX Unsigned32 RP> MAX-ACCESS not-accessible RP> STATUS current RP> DESCRIPTION "A transport model-specific identifier of the RP> session. This value MUST be unique among all RP> of a given transport model's currently open sessions. RP> The value has no particular significance other RP> to distinguish sessions. An example of a suitable RP> value would be tlstmSessionID." RP> ::= { extVacmSecurityToGroupEntry 3 } Color me confused... I thought that you'd do something more generic. tlstmSessionID is specific to the TLS-TM transport. Wouldn't tmSessionID be a better choice to reference, which is common to both TLSTM and SSHTM? (and tmSessionID == tlstmSessionID in TLSTM) -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Mar 1 14:50:35 2010 Return-Path: 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 2E78828C203 for ; Mon, 1 Mar 2010 14:50:35 -0800 (PST) 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 R8lriJbcevAD for ; Mon, 1 Mar 2010 14:50:34 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 30C8328C1FC for ; Mon, 1 Mar 2010 14:50:34 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 772499C46B; Mon, 1 Mar 2010 14:50:34 -0800 (PST) From: Wes Hardaker To: Randy Presuhn Organization: Sparta References: <001301cab6ac$2cf27dc0$6801a8c0@oemcomputer> <20100226084433.GA33124@elstar.local> Date: Mon, 01 Mar 2010 14:50:34 -0800 In-Reply-To: <20100226084433.GA33124@elstar.local> (Juergen Schoenwaelder's message of "Fri, 26 Feb 2010 09:44:33 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM open issue 1 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: , X-List-Received-Date: Mon, 01 Mar 2010 22:50:35 -0000 >>>>> On Fri, 26 Feb 2010 09:44:33 +0100, Juergen Schoenwaelder said: JS> As far as I recall, we do not touch any of the RFC 3514 semantics and JS> hence it seems reasonable that we do not claim to update RFC 3514. I'll note that I think it's rather funny you referenced 3514 instead of 3414. 3514 is the Apr 1 document that defines the IPv4 "evil bit". I'm quite sure we're not updating that one. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Mon Mar 1 16:38:06 2010 Return-Path: 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 1F9833A89C2 for ; Mon, 1 Mar 2010 16:38:06 -0800 (PST) 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 Ec3KLE85u-Td for ; Mon, 1 Mar 2010 16:38:05 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 346753A68ED for ; Mon, 1 Mar 2010 16:38:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ppa/0K5KqJTowb4/Eoc3Ar70xQ1b0CMBvh9tsNdK8i2lTaGZ8J/4OJITVDVQUNYJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.4.5] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NmG7h-0002Uu-JK for isms@ietf.org; Mon, 01 Mar 2010 19:38:05 -0500 Message-ID: <000c01cab9a0$c2239c20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer><20100226085255.GE33124@elstar.local><001c01cab6c3$de47b600$6801a8c0@oemcomputer> Date: Mon, 1 Mar 2010 16:39:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a9ec9648795d2f12ed11c4bd4dbf6f49350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.4.5 Subject: Re: [Isms] RADIUS/VACM issue 6 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: , X-List-Received-Date: Tue, 02 Mar 2010 00:38:06 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Monday, March 01, 2010 2:47 PM > Subject: Re: RADIUS/VACM issue 6 ... > Color me confused... I thought that you'd do something more generic. > tlstmSessionID is specific to the TLS-TM transport. Wouldn't > tmSessionID be a better choice to reference, which is common to both > TLSTM and SSHTM? (and tmSessionID == tlstmSessionID in TLSTM) ... Ok, I'll use that. (I don't have strong feelings about this. It's only an example, and the only real requirement is that it be unique in the scope of the security model with which it is associated) Randy From randy_presuhn@mindspring.com Mon Mar 1 16:39:23 2010 Return-Path: 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 278193A89FB for ; Mon, 1 Mar 2010 16:39:23 -0800 (PST) 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 hQ-NyAmK0mVS for ; Mon, 1 Mar 2010 16:39:22 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id A5E213A68ED for ; Mon, 1 Mar 2010 16:39:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I2AJdT2FchDDThVke/n/j8fpAlj/KAtExauHxMknwqDPMIOdj17mGKVnb9tYKWL3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.4.5] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NmG8w-00040R-22 for isms@ietf.org; Mon, 01 Mar 2010 19:39:22 -0500 Message-ID: <001101cab9a0$f1603340$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001301cab6ac$2cf27dc0$6801a8c0@oemcomputer><20100226084433.GA33124@elstar.local> Date: Mon, 1 Mar 2010 16:40:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b409d2aac93d87e6a0a30ddbb47da2d0dde350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.4.5 Subject: Re: [Isms] RADIUS/VACM open issue 1 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: , X-List-Received-Date: Tue, 02 Mar 2010 00:39:23 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Monday, March 01, 2010 2:50 PM > Subject: Re: RADIUS/VACM open issue 1 ... > I'll note that I think it's rather funny you referenced 3514 instead of > 3414. 3514 is the Apr 1 document that defines the IPv4 "evil bit". I'm > quite sure we're not updating that one. But that's the bit we pass to VACM in order to generate the "access denied" decision. :-) Randy From wjhns1@hardakers.net Tue Mar 2 17:13:51 2010 Return-Path: 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 C4BCA3A8C91 for ; Tue, 2 Mar 2010 17:13:50 -0800 (PST) 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 ac1UNi9-bIMD for ; Tue, 2 Mar 2010 17:13:45 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 0AA4A3A8881 for ; Tue, 2 Mar 2010 17:13:43 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 481069C9C4; Tue, 2 Mar 2010 17:13:43 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 02 Mar 2010 17:13:42 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Thu, 25 Feb 2010 14:23:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Wed, 03 Mar 2010 01:13:51 -0000 PE> AD review comments for draft-ietf-isms-dtls-tm-08 Pasi, I've acted on most of your comments and have questions/discussion items about a few. I haven't tackled your rewording suggestions for 5.1.1 yet and will get to those tomorrow. Please see the notes below about each item and let me know what you think in particular about the ones marked "DISCUSS". My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it Table of Contents ================= 1 Somewhat substantial first: 2 Semi-editorial/editorial: 1 TODO Somewhat substantial first: ----------------------------------- * DONE Unless we have a normative dependency to draft-ietf-tsvwg-dtls-for-sctp (which would delay this document for unpredictable time), we need to specify which of the possible ways of running DTLS over SCTP we're using in this document. Since this might take some time, I would suggest just leaving out DTLS-over-SCTP from this document. + WH: Done. Originally it looked like that document would long beat us, but it apparently hasn't. (It just entered WG last call I see). * DISCUSS Currently, the document specifies how the TLS client authenticates/ authorizes the TLS server only when SNMP-TARGET-MIB is used. But clearly authenticating the TLS server is also important for e.g. command generators. These may not have a MIB, but shouldn't we at least recommend an implementation-specific management/configuration interface that supports configuring the same details as tlstmAddrTable? (E.g. Syslog-over-TLS specifies that the management interface must be able to configure this stuff, but that "management interface" could be a configuration file, GUI, or even a proprietary MIB.) + WH: The current draft says (5.3.1 bullet 4): "The (D)TLS client MUST then verify that the (D)TLS server's presented certificate is the expected certificate. [...] If the connection is being established from configuration based on SNMP-TARGET-MIB configuration then the procedures in the tlstmAddrTable DESCRIPTION clause should be followed to determine if the presented identity matches the expectations of the configuration. Validation procedures (like the path validation procedures defined in [RFC5280] or through the use of fingerprints as defined by the tlstmAddrServerIdentity column) MUST be followed. If a server identity name has been configured in the tlstmAddrServerIdentity column then this reference identity must be compared against the presented identity (for example using procedures described in [I-D.saintandre-tls-server-id-check]). If the connection is being established for reasons other than configuration found in the SNMP-TARGET-MIB then configuration and procedures outside the scope of this document should be followed." Would adding something like the following to the end of that last paragraph meet your goals: Configuration mechanisms SHOULD be similar in nature to those defined in the tlstmAddrTable to ensure consistency across management configuration systems. * DONE Overall: The details of exactly how (D)TLS needs to be used are scattered over the document, and in some cases, not very clearly written. Probably we should include a "(D)TLS usage" section that explains what TLS features/etc. we're using and so on. Here's a first sketch, replacing current 4.2: 4.2. (D)TLS Usage (D)TLS MUST negotiate a cipher suite that uses X.509 certificates for authentication, and MUST authenticate both the client and the server. The mandatory-to-implement cipher suite is specified in the TLS specification [RFC5246]. TLSTM verifies the certificates when the connection is opened (see Section 5.3). For this reason, TLS renegotiation with different certificates MUST NOT be done. That is, implementations MUST either disable renegotiation completely (RECOMMENDED), or MUST present the same certificate during renegotiation (and MUST verify that the other end presented the same certificate). For DTLS over UDP, each SNMP message MUST be placed in a single UDP datagram; it MAY be split to multiple DTLS records. In other words, if a single datagram contains multiple DTLS application_data records, they are concatenated when received. The TLSTM implementation SHOULD return an error if the SNMP message does not fit in the UDP datagram, and thus cannot be sent. For DTLS over UDP, the DTLS server implementation MUST support DTLS cookies ([RFC4347] already requires that clients support DTLS cookies). Implementations are not required to perform the cookie exchange for every DTLS handshake; however, enabling it by default is RECOMMENDED. For DTLS, replay protection MUST be used. + WH: I'm fine with that wording, with one minor change. The working group has waffled back and forth generally on how much "(D)TLS" specific protocol information should be referenced and thus I could see people objecting to the wording like "... multiple DTLS application_data records ..." because we expressly removed wording like that before that talked about DTLS internals. I'll leave it up to others to complain if your next text strikes a nerve with them. * DISCUSS Section 3.1.3. "As an implementation hint: although the tlstmSessionID may be the same as the (D)TLS internal SessionID caution must be exercised since the (D)TLS internal SessionID may change over the life of the connection as seen by the TLSTM (for example during renegotiation). The tlstmSessionID identifier MUST NOT change during the entire duration of the session from the TLSTM's perspective even if the TLS internal session identifier does change." This is not correct; it's possible to have several (D)TLS connections (over different TCP connections, or different UDP five-tuples) that have the same (D)TLS internal Session ID, so it does not uniquely identify a TLSTM session. I would suggest just deleting this paragraph. + WH: I think you're missing the point of the paragraph. It's stating that the SNMP-specific tlstmSessionID MUST NOT and MUST be consistent. No where does the paragraph state that the TLS session IDs uniquely identify a session. It only states that if you use it you need to be careful and I think this is an important point. I'd be happy to add an additional sentence describing that a single TLS sessionID may be shared among connections, but using a shared sessionID within TLSTM is prohibited. * TODO Largely for the same reason, Section 5.1.1 is not quite correct; here's an attempt to rephrase it: + WH: I need to think/work more heavily on this one; I'll get back to you about it in another day or so. There is a balance to be struck between the agonizing detail that SNMP EOPs go into sometimes vs what should be described for DTLS processing. 5.1.1. DTLS over UDP Processing for Incoming Messages For connection-oriented transport protocols, such as TCP, the transport protocol takes care of demultiplexing incoming packets to the right connection. Depending on the DTLS implementation, for DTLS over UDP, this demultiplexing may need to be done by the TLSTM implementation. Like TCP, DTLS over UDP uses the four-tuple for identifying the connection (and relevant DTLS connection state). This means that when establishing a new session, implementations MUST use a different UDP source port number for each active connection to a remote destination IP-address/port-number combination to ensure the remote entity can disambiguate between multiple connections. If demultiplexing received UDP datagrams to DTLS connection state is done by the TLSTM implementation (instead of the DTLS implementation), the steps below describe one possible method to accomplish this. 1) The TLS Transport Model examines the UDP datagram, in an implementation-dependent manner. 2) The TLS Transport Model queries the LCD using the transport parameters (source and destination IP addresses and ports) to determine if a session already exists. If a matching entry in the LCD does not exist, create a new entry containing the transport parameters; a new DTLS connection handle (an implementation-dependent detail), and a new tlsTmSessionId. 3) Pass the UDP packet and DTLS connection handle to DTLS (in implementation-dependent manner). If processing does not return an incomingMessage and an incomingMessageLength then processing stops (this is the case when the UDP datagram contained DTLS handshake messages, for example). 4) Retrieve the incomingMessage and an incomingMessageLength from DTLS. These results and the tlstmSessionID are used below in Section 5.1.2 to complete the processing of the incoming message. * DONE Section 7, tlstmCertSANDNSName: I thought we agreed in IETF76 that this should be lowercased? + WH: Good catch; thanks. I think when the text split into OIDs the revision specifying the lower-casing got lost. Re-added as follows: DESCRIPTION "Maps a subjectAltName's dNSName to a tmSecurityName after first converting it to all lower case." * DONE Section 7, tlstmCertSANIpAddress: I thought we agreed in IETF76 that IPv6 addresses need to be in lowercase? + WH: Good catch; thanks. I think when the text split into OIDs the revision specifying the lower-casing got lost. Re-added as follows: 2) for IPv6 addresses the value is converted into a 32-character all lowercase hexadecimal string without any colon separators. * DONE Section 7, tlstmCertCommonName: "[..] by directly passing the value without any transformations" -> "[..]. The value is converted to UTF-8 encoding, but no other transformation are done." + WH: new text: DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName after converting it to a UTF-8 encoding." * DISCUSS Section 7, tlstmParamsClientFingerprint: we should probably allow an empty value to accommodate the common case where the client has just one certificate/private key? + WH: I think it would be better to allow a non-existing row to indicate use the default client certificate. This probably isn't clearly spelled out in 5.3.1 step 2, which reads: The client selects the appropriate certificate and cipher_suites for the key agreement based on the tmSecurityName and the tmRequestedSecurityLevel for the session. For sessions being established as a result of a SNMP-TARGET-MIB based operation, the certificate will potentially have been identified via the tlstmParamsTable mapping and the cipher_suites will have to be taken from system-wide or implementation-specific configuration. How's this for a suggested addition as a last sentence: If no row in the tlstmParamsTable exists then implementations MAY choose to establish the connection using a default client certificate available to the application. * DONE Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some of the details, and in its present form, would need a normative reference to draft-saintandre-tls-server-id-check (which we might want to avoid so this document is not delayed). Suggested rephrasing: "This table is used by a (D)TLS client when a (D)TLS connection is being set up using an entry in the SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that the client can verify that the correct server has been reached. This verification can use either a certificate fingerprint, or an identity authenticated via certification path validation. If there is a row in this table corresponding to the entry in the SNMP-TARGET-MIB that was used to establish the session (and that row is active), and the row's tlstmAddrServerFingerprint column has non-empty value, the server's presented certificate is compared with the fingerprint (and the tlstmAddrServerIdentity column is ignored). If the fingerprint matches, the verification has succeeded. If the server's presented certificate has passed certification path validation [RFC5280] to a configured trust anchor, and a row exists with a zero-length tlstmAddrServerFingerprint value, then the tlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certicate as follows: - Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. - The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. - If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [RFC5280]. If none of the rows in this table match, then the connection MUST be closed (except if the server can be authorized by other, implementation-dependent means)." + WH: - I like the copying of the text from the other draft. - The proposed text has been adopted with some rewording and now reads as follows: DESCRIPTION "This table is used by a (D)TLS client when a (D)TLS connection is being set up using an entry in the SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that the client can verify that the correct server has been reached. This verification can use either a certificate fingerprint, or an identity authenticated via certification path validation. If there is an active row in this table corresponding to the entry in the SNMP-TARGET-MIB that was used to establish the connection, and the row's tlstmAddrServerFingerprint column has non-empty value, then the server's presented certificate is compared with the tlstmAddrServerFingerprint value (and the tlstmAddrServerIdentity column is ignored). If the fingerprint matches, the verification has succeeded. If the fingerprint does not match then the connection MUST be closed. If the server's presented certificate has passed certification path validation [RFC5280] to a configured trust anchor, and an active row exists with a zero-length tlstmAddrServerFingerprint value, then the tlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certificate as follows: - Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. - The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. - If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [RFC5280]. If the expected host name fails these conditions then the connection MUST be closed. A row MUST NOT contain both a blank tlstmAddrServerFingerprint column and a '*' in the tlstmAddrServerIdentity column since this would insecurely accept any presented certificate. If there is no row in this table corresponding to the entry in the SNMP-TARGET-MIB and the server can be authorized by another, implementation dependent means, then the connection MAY still proceed." * DONE Section 7, "tlstmAddrServerIdentity", remove the last sentence (about wildcards) and REFERENCE, and change DEFVAL to "" (the wildcard cannot be used by the procedure as currently described, since the identity column is looke at only if fingerprint is zero-length, and if the fingerprint is zero-length, wildcard is not allowed...) * DONE Section 5.3.1, step 4, rephrase 2nd paragraph as: If the connection is being established from configuration based on SNMP-TARGET-MIB configuration, then the tlstmAddrTable DESCRIPTION clause describes how the verification is done (using either a certificate fingerprint, or an identity authenticated via certification path validation). * DONE Section 10, rephrase items 1..6 as: 1. Two TCP/UDP/SCTP port numbers from the "Registered Ports" range of the Port Numbers registry, with keywords "snmptls" and "snmptls-trap". These are the default ports for receipt of SNMP command messages (snmptls) and SNMP notification messages (snmptls-trap) over a TLS Transport Model as defined in this document. And delete both paragraphs starting with "If possible, ..." later in this section (if we ask for the same port, we will get it). + WH: Ok, done. But you removed the guidance about the port number being > 1023 which was a WG decision to accept something higher than 1023 as acceptable. Shouldn't we include such a note as part of the guidance? * DONE C.1. I think we need an example here. Here's a first attempt (based on RFC 5591, Appendix A): For notification originators performing authorization checks, the server's certificate must be verified against the expected certificate before proceeding to send the notification. This is done by configuring the tlstmAddrTable accordingly. For example, if the verification is done via certification path validation (to a trust anchor configured in implementation dependent manner), the entries could look like: snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain snmpTLSTCPDomain * snmpTargetAddrTAddress 192.0.2.1:5162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (MUST match below) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "blueberry" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain snmpTLSTCPDomain * snmpTargetAddrTAddress 192.0.2.1:5162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (MUST match above) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo tlstmAddrTable row: snmpTargetAddrName toCRAddr tlstmAddrServerFingerprint "" tlstmAddrServerIdentity "server.example.org" tlstmAddrStorageType nonVolatile tlstmAddrRowStatus createAndGo + WH: I've added similar text to the above. The above has some issues with it so I've adapted it to the following: To configure a notification originator to open a TLS over TCP connection to a notification receiver it must be configured so the server's presented certificate can be verified against the expected certificate before proceeding to send the notification. This is done by configuring the tlstmAddrTable accordingly. For example, if the verification is done via certification path validation (to a trust anchor configured in implementation dependent manner), then the table entries could look like: snmpTargetAddrTable row: snmpTargetAddrName = "toNRAddr" snmpTargetAddrTDomain = snmpTLSTCPDomain snmpTargetAddrTAddress = "192.0.2.1:XXXTLSTCPTRAPPORT" snmpTargetAddrTimeout = 1500 snmpTargetAddrRetryCount = 3 snmpTargetAddrTagList = "toNRTag" snmpTargetAddrParams = "toNR" (MUST match below) snmpTargetAddrStorageType = 3 (nonVolatile) snmpTargetAddrColumnStatus = 4 (createAndGo) snmpTargetParamsTable row: snmpTargetParamsName = toNR snmpTargetParamsMPModel = SNMPv3 snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) snmpTargetParamsSecurityName = "blueberry" snmpTargetParamsSecurityLevel = 3 (authPriv) snmpTargetParamsStorageType = 3 (nonVolatile) snmpTargetParamsRowStatus = 4 (createAndGo0 tlstmAddrTable row: snmpTargetAddrName = "toNRAddr" tlstmAddrServerFingerprint = "" tlstmAddrServerIdentity = "server.example.org" tlstmAddrStorageType = 3 (nonVolatile) tlstmAddrRowStatus = 4 (createAndGo) Editor's note: replace the string "XXXTLSTCPTRAPPORT" above with the appropriately assigned "snmptls-trap" port. Editor's note: replace the string "TSMNUM" above with the appropriately assigned "snmptls-trap" port. 2 TODO Semi-editorial/editorial: --------------------------------- * DONE Section 1, "While (D)TLS supports multiple authentication mechanisms, this document only discusses X.509 certificate based authentication. Although other forms of authentication are possible they are outside the scope of this specification." sounds a bit cumbersomet. Perhaps "While [..], this document [..]; other forms of authentication are outside the scope of this specification" would be more fluent? * DONE Section 1: "connectionless (e.g. UDP or SCTP) transport": SCTP is connection-oriented, not connectionless. * DONE Section 1: We shouldn't have a figure longer than one page. Here's an attempt to clean the figure slightly so it fits on one page: [...] + WH: I've replaced the diagram with yours. Thanks for the work; I've never been happy with that diagram. * DONE Section 1.1 says 'The terms "manager" and "agent" are not used in this document'; however, the rest of the document occasionally uses the word 'manager' to refer to the person who's configuring stuff. Should these be changed to 'administrator'? + Good catch: changed; * DONE Section 1.1: "this document (unless otherwise specified) is referring to TLSTM's specific session and not directly to the (D)TLS protocol's session". Actually, even when this document *does* specify otherwise and explicitly says "(D)TLS session", it's still usually talking about D(TLS) connections, not sessions. Proposed rephrasing here: "The (D)TLS protocols also have an internal notion of a session and although these two concepts of a session are related, this document is referring to the TLSTM's specific session and not directly to the (D)TLS protocol's session." + WH: put in place with slight changes: The (D)TLS protocols also have an internal notion of a session and although these two concepts of a session are related, when the term "session" is used this document is referring to the TLSTM's specific session and not directly to the (D)TLS protocol's session. * DONE Section 3: "to close a (D)TLS session" -> "to close the session" (this is *not* about (D)TLS sessions, but TLSTM sessions) + WH: good point; * DONE Section 3.1.1, item 2: "The TLS Transport Model MUST support authentication of both the server and the client." This sentence is very confusing; it seems to be targeted at the writer of this specification, not implementor. I would just suggest deleting this sentence. + WH: Changed to: A TLS Transport Model implementation MUST support authentication of both the server and the client. * DONE Section 3.1.1, item 4: "The TLS Transport Model SHOULD support the message encryption to protect sensitive data from eavesdropping attacks." This sentence is very confusing; it seems to be targeted at the writer of this specification, not implementor. Or if it's targeted at the implementor, is it trying to say that "implementations SHOULD support at least one cipher suite that does encryption?" (that's not needed; the mandatory-to-implement cipher suite in TLS RFCs is quite enough) I would just suggest deleting this sentence. + WH: I think keeping the notion that supporting encryption is important is, um, important. Changed to: A TLS Transport Model implementation SHOULD support the message encryption to protect sensitive data from eavesdropping attacks. It at least indicates that the implementation should support "configuration" of encryption enabled cipher suites. (there is sort of an odd case where an implementation could implement the cipher suite, but refuse to actually use it ;-) * DONE Section 3.1.1, item 5: replace all three paragraphs with 5. Denial of Service - the RFC 3411 architecture [RFC3411] states that denial of service (DoS) attacks need not be addressed by an SNMP security protocol. However, connectionless transports (like DTLS over UDP are susceptible to a variety of denial of service attacks because they are more vulnerable to spoofed IP addresses. See Section 4.2 for details how the cookie mechanism is used. This mechanism, though, does not provide any defense against denial of service attacks mounted from valid IP addresses. + WH: Applied after fixing the closing ) problem in the above text and rewording the last sentence just a touch. * DONE Section 3.1.2: "(D)TLS session provides" -> "(D)TLS connection provides" * DONE Section 3.1.3: "D(TLS) Sessions" -> "D(TLS) Connections" + WH: applied with the proper () grouping. * DONE Section 3.3, "(D)TLS sessions may be initiated" -> "(D)TLS connections may be initiated * DONE Section 3.3, "locally held certificate" -> "locally held certificate (and the corresponding private key)" * DONE Section 4.1.1, OLD Authentication using (D)TLS will require that SNMP entities are provisioned with certificates, which are signed by trusted certificate authorities (possibly the certificate itself). NEW: Authentication using (D)TLS will require that SNMP entities have certificates, either signed by trusted certification authorities, or self-signed. * DONE Section 4.1.1, "tmpSecurityName" -> "tmSecurityName" + WH: yikes! Thanks! * DONE Section 4.3.1 and 4.3.2: SnmpTLSDomain -> SnmpTLSTCPDomain + WH: changed; thanks (lower case s though) * WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a predictable tmSecurityName so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames." Setting requirements for all transport models (not just DTLSTM) doesn't seem to belong to this document... + that's boilerplate-ish text directly from 5592 which we're copying verbatim. * DONE Section 4.4.1.1, "through an existing (D)TLS session" -> "through an existing (D)TLS connection" * DONE Section 4.4.1.2, "D(TLS) session" -> "D(TLS) connection" (both instances) + WH: with proper ()s * DONE Section 5.1, "for all (D)TLS-based sessions" -> " for all(D)TLS-based connections" * DONE Section 5.1: "TLS and DTLS/SCP" -> "TLS/TCP and DTLS/SCTP" * DONE Section 5.1: "5.1.2describes" -> "5.1.2 describes" * DONE Section 5.1.2, "lifetime of the (D)TLS session" -> "lifetime of session" * DONE Section 5.3 and 5.3.1 and 5.3.2, "(D)TLS session" -> "(D)TLS connection" (all instances) * DONE Section 5.4, "Have (D)TLS close the specified session" -> "Have (D)TLS close the specified connection" * DONE Section 6.3, "(D)TLS session usage" -> "session usage" * DONE Section 7, snmpTlstmSessionAccepts DESCRIPTION: TODO + WH: It looks like you wanted to reword this and forgot to get back to it. Given your other comments I've predicted your issues and have changed the wording to this: "The number of times a (D)TLS server has accepted a new connection from a client and has received at least one SNMP message through it." * DONE Section 7, tlstmParamsTable and tlstmAddrTable: "(D)TLS session" -> "(D)TLS connection" * DONE Section 7, tlstmParamsClientFingerprint: "locally held X.509 certificate" -> "locally held X.509 certificate (and the corresponding private key)". * DONE Section 8.1, " A session is discussed throughout this document as meaning a security association between the (D)TLS client and the (D)TLS server." -> "A session is discussed throughout this document as meaning a security association between two TLSTM instances." * DONE Section 9: OLD DTLS adds to the security considerations of TLS only because it is more vulnerable to denial of service attacks. A random cookie exchange was added to the handshake to prevent anonymous denial of service attacks. RFC 4347 recommends that the cookie exchange is utilized for all handshakes. It is also RECOMMENDED by this specification that users enable this cookie exchange. NEW: When run over UDP, DTLS is more vulnerable to denial of service attacks from spoofed IP addresses; see Section 4.2 for details how the cookie exchange is used to address this issue. * DISCUSS Appendix A and B: Please just delete these -- the details aren't quite right (e.g. DTLS sessions...), and fixing them is not worth the effort needed. + WH: The WG discussed these sections in Stockholm (I think) and the consensus was to leave them as they were useful to "newbies" and it would be better to move them to an appendix than to delete them. I've never been really happy with the text (and in fact didn't even write it), but I want to make sure you're explicitly trumping WG consensus with your AD badge before I delete them. * DONE C.1, would suggest adding "In case the notification originator has multiple certificates, ..." to the beginning of the 2nd para. + WH: I don't think that's quite the right text either. I'm now adding this to the end: (Or else a default certificate may be used if available.) * DONE C.2, "(D)TLS session" -> "D(TLS) connection" * WONTDO C.2: suggest replacing "HASH" with an example hash. If I understand the Fingerprint DISPLAY-HINT correctly, that might be something like "02:68b9389e49a815aa4a79f40fcfce7eb8cd10669c" + WH: Though I understand the desire to do that, I don't think it's worth making one up nor is it worth trying to make it fit within the page width (it'd need to be wrapped multiple times). * DONE C.2: OLD tlstmCertToTSNMapType = 1 (specified) tlstmCertToTSNSecurityName = "blueberry" NEW: tlstmCertToTSNMapType = tlstmCertSpecified tlstmCertToTSNData = "blueberry" + WH: Good catch. * DONE C.2: OLD tlstmCertToTSNMapType = 2 (bySubjectAltName) tlstmCertToTSNSANType = 1 (any) NEW: tlstmCertToTSNMapType = tlstmCertSANAny tlstmCertToTSNData = "" (not used) + WH: good catch. * DONE Overall: "certificate authority" -> "certification authority" -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Thu Mar 4 08:22:20 2010 Return-Path: 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 285823A8D3F for ; Thu, 4 Mar 2010 08:22:17 -0800 (PST) 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 D6IWA7vtFNeU for ; Thu, 4 Mar 2010 08:22:10 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 768A23A8D4F for ; Thu, 4 Mar 2010 08:22:04 -0800 (PST) X-Trace: 244761815/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.80/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.80 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0GAG5tj0s+vGlQ/2dsb2JhbACBehiFQIhQQYtPuDANgkIBDoIeBI5p X-IronPort-AV: E=Sophos;i="4.49,582,1262563200"; d="scan'208";a="244761815" X-IP-Direction: IN Received: from 1cust80.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.80]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2010 16:22:02 +0000 Message-ID: <000701cabbae$47c86720$0601a8c0@allison> From: "tom.petch" To: , "isms" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 4 Mar 2010 15:49:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:22:20 -0000 Pasi Two thoughts on your proposal to discourage renegotiation. SNMP may have long running sessions - I know, there is no concept of session in SNMP but allow me a little licence - so that it may trip over limitations on the usage of the security credentials in a way that other applications do not. A certificate could expire and so need to be replaced with a current one, which is one use of renegotiation. And so much data could flow, or time pass, that the keys need refreshing, which again renegotiation allows. Do you intend that these be NOT RECOMMENDED ie if and when such are needed, tear down the TLSTM session and start again? Second, you change all the TLS session to TLS connection, which is a substantial change. I had assumed that the author had intended session resumption to be permitted which your new text would discourage. Again, is this your intention? Tom Petch ----- Original Message ----- From: To: Sent: Thursday, February 25, 2010 2:23 PM Subject: [Isms] AD review comments for draft-ietf-isms-dtls-tm-08 > AD review comments for draft-ietf-isms-dtls-tm-08 > > I've now done my AD review for draft-ietf-isms-dtls-tm-08, and bunch > of comments. Most of them are quite small, and I've tried to suggest > possible text in most cases (but this is just to clarify what I'm > looking for; I'm not hung up on the exact wording): > > Somewhat substantial first: > > - Unless we have a normative dependency to > draft-ietf-tsvwg-dtls-for-sctp (which would delay this document for > unpredictable time), we need to specify which of the possible ways of > running DTLS over SCTP we're using in this document. Since this might > take some time, I would suggest just leaving out DTLS-over-SCTP from > this document. > > - Currently, the document specifies how the TLS client authenticates/ > authorizes the TLS server only when SNMP-TARGET-MIB is used. But > clearly authenticating the TLS server is also important for > e.g. command generators. These may not have a MIB, but shouldn't we at > least recommend an implementation-specific management/configuration > interface that supports configuring the same details as > tlstmAddrTable? > > (E.g. Syslog-over-TLS specifies that the management interface must be > able to configure this stuff, but that "management interface" could > be a configuration file, GUI, or even a proprietary MIB.) > > - Overall: The details of exactly how (D)TLS needs to be used are > scattered over the document, and in some cases, not very clearly > written. Probably we should include a "(D)TLS usage" section that > explains what TLS features/etc. we're using and so on. Here's a first > sketch, replacing current 4.2: > > 4.2. (D)TLS Usage > > (D)TLS MUST negotiate a cipher suite that uses X.509 certificates > for authentication, and MUST authenticate both the client and the > server. The mandatory-to-implement cipher suite is specified in the > TLS specification [RFC5246]. > > TLSTM verifies the certificates when the connection is opened (see > Section 5.3). For this reason, TLS renegotiation with different > certificates MUST NOT be done. That is, implementations MUST > either disable renegotiation completely (RECOMMENDED), or MUST > present the same certificate during renegotiation (and MUST verify > that the other end presented the same certificate). > > For DTLS over UDP, each SNMP message MUST be placed in a single UDP > datagram; it MAY be split to multiple DTLS records. In other words, > if a single datagram contains multiple DTLS application_data > records, they are concatenated when received. The TLSTM > implementation SHOULD return an error if the SNMP message does not > fit in the UDP datagram, and thus cannot be sent. > > For DTLS over UDP, the DTLS server implementation MUST support DTLS > cookies ([RFC4347] already requires that clients support DTLS > cookies). Implementations are not required to perform the cookie > exchange for every DTLS handshake; however, enabling it by default > is RECOMMENDED. > > For DTLS, replay protection MUST be used. > > - Section 3.1.3. "As an implementation hint: although the > tlstmSessionID may be the same as the (D)TLS internal SessionID > caution must be exercised since the (D)TLS internal SessionID may > change over the life of the connection as seen by the TLSTM (for > example during renegotiation). The tlstmSessionID identifier MUST NOT > change during the entire duration of the session from the TLSTM's > perspective even if the TLS internal session identifier does change." > > This is not correct; it's possible to have several (D)TLS connections > (over different TCP connections, or different UDP five-tuples) that > have the same (D)TLS internal Session ID, so it does not uniquely > identify a TLSTM session. I would suggest just deleting this > paragraph. > > Largely for the same reason, Section 5.1.1 is not quite correct; > here's an attempt to rephrase it: > > 5.1.1. DTLS over UDP Processing for Incoming Messages > > For connection-oriented transport protocols, such as TCP, the > transport protocol takes care of demultiplexing incoming packets to > the right connection. Depending on the DTLS implementation, for > DTLS over UDP, this demultiplexing may need to be done by the TLSTM > implementation. > > Like TCP, DTLS over UDP uses the four-tuple IP, source port, destination port> for identifying the connection > (and relevant DTLS connection state). This means that when > establishing a new session, implementations MUST use a different > UDP source port number for each active connection to a remote > destination IP-address/port-number combination to ensure the remote > entity can disambiguate between multiple connections. > > If demultiplexing received UDP datagrams to DTLS connection state > is done by the TLSTM implementation (instead of the DTLS > implementation), the steps below describe one possible method to > accomplish this. > > 1) The TLS Transport Model examines the UDP datagram, in an > implementation-dependent manner. > > 2) The TLS Transport Model queries the LCD using the transport > parameters (source and destination IP addresses and ports) to > determine if a session already exists. > > If a matching entry in the LCD does not exist, create a new > entry containing the transport parameters; a new DTLS > connection handle (an implementation-dependent detail), and a > new tlsTmSessionId. > > 3) Pass the UDP packet and DTLS connection handle to DTLS (in > implementation-dependent manner). If processing does not return > an incomingMessage and an incomingMessageLength then processing > stops (this is the case when the UDP datagram contained DTLS > handshake messages, for example). > > 4) Retrieve the incomingMessage and an incomingMessageLength from > DTLS. These results and the tlstmSessionID are used below in > Section 5.1.2 to complete the processing of the incoming message. > > - Section 7, tlstmCertSANDNSName: I thought we agreed in IETF76 that > this should be lowercased? > > - Section 7, tlstmCertSANIpAddress: I thought we agreed in IETF76 that > IPv6 addresses need to be in lowercase? > > - Section 7, tlstmCertCommonName: "[..] by directly passing the value > without any transformations" -> "[..]. The value is converted to UTF-8 > encoding, but no other transformation are done." > > - Section 7, tlstmParamsClientFingerprint: we should probably allow an > empty value to accommodate the common case where the client has just > one certificate/private key? > > - Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some of the > details, and in its present form, would need a normative reference to > draft-saintandre-tls-server-id-check (which we might want to avoid so > this document is not delayed). Suggested rephrasing: > > "This table is used by a (D)TLS client when a (D)TLS connection is > being set up using an entry in the SNMP-TARGET-MIB. It extends the > SNMP-TARGET-MIB's snmpTargetAddrTable so that the client can verify > that the correct server has been reached. > > This verification can use either a certificate fingerprint, or an > identity authenticated via certification path validation. > > If there is a row in this table corresponding to the entry in the > SNMP-TARGET-MIB that was used to establish the session (and that > row is active), and the row's tlstmAddrServerFingerprint column has > non-empty value, the server's presented certificate is compared > with the fingerprint (and the tlstmAddrServerIdentity column is > ignored). If the fingerprint matches, the verification has > succeeded. > > If the server's presented certificate has passed certification path > validation [RFC5280] to a configured trust anchor, and a row exists > with a zero-length tlstmAddrServerFingerprint value, then the > tlstmAddrServerIdentity column contains the expected host name. > This expected host name is then compared against the server's > certicate as follows: > > - Implementations MUST support matching the expected host name > against a dNSName in the subjectAltName extension field and SHOULD > support checking the name against the common name portion of the > subject distinguished name. > > - The '*' (ASCII 42) wildcard character is allowed in the dNSName > of the subjectAltName extension (and in common name, if used to > store the host name), but only as the left-most (least significant) > DNS label in that value. This wildcard matches any left-most DNS > label in the server name. That is, the subject *.example.com > matches the server names a.example.com and b.example.com, but does > not match example.com or a.b.example.com. Implementations MUST > support wildcards in certificates as specified above, but MAY > provide a configuration option to disable them. > > - If the locally configured name is an internationalized domain > name, conforming implementations MUST convert it to the ASCII > Compatible Encoding (ACE) format for performing comparisons, as > specified in Section 7 of [RFC5280]. > > If none of the rows in this table match, then the connection MUST > be closed (except if the server can be authorized by other, > implementation-dependent means)." > > - Section 7, "tlstmAddrServerIdentity", remove the last sentence > (about wildcards) and REFERENCE, and change DEFVAL to "" (the wildcard > cannot be used by the procedure as currently described, since the > identity column is looke at only if fingerprint is zero-length, and if > the fingerprint is zero-length, wildcard is not allowed...) > > - Section 5.3.1, step 4, rephrase 2nd paragraph as: > > If the connection is being established from configuration based on > SNMP-TARGET-MIB configuration, then the tlstmAddrTable DESCRIPTION > clause describes how the verification is done (using either a > certificate fingerprint, or an identity authenticated via > certification path validation). > > - Section 10, rephrase items 1..6 as: > > 1. Two TCP/UDP/SCTP port numbers from the "Registered Ports" range > of the Port Numbers registry, with keywords "snmptls" and > "snmptls-trap". These are the default ports for receipt of SNMP > command messages (snmptls) and SNMP notification messages > (snmptls-trap) over a TLS Transport Model as defined in this > document. > > And delete both paragraphs starting with "If possible, ..." later > in this section (if we ask for the same port, we will get it). > > - C.1. I think we need an example here. Here's a first attempt > (based on RFC 5591, Appendix A): > > For notification originators performing authorization checks, the > server's certificate must be verified against the expected > certificate before proceeding to send the notification. This is > done by configuring the tlstmAddrTable accordingly. For example, > if the verification is done via certification path validation > (to a trust anchor configured in implementation dependent manner), > the entries could look like: > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > * snmpTargetAddrTDomain snmpTLSTCPDomain > * snmpTargetAddrTAddress 192.0.2.1:5162 > snmpTargetAddrTimeout 1500 > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR (MUST match below) > snmpTargetAddrStorageType nonVolatile > snmpTargetAddrColumnStatus createAndGo > > snmpTargetParamsTable row: > snmpTargetParamsName toCR > snmpTargetParamsMPModel SNMPv3 > * snmpTargetParamsSecurityModel TransportSecurityModel > snmpTargetParamsSecurityName "blueberry" > snmpTargetParamsSecurityLevel authPriv > snmpTargetParamsStorageType nonVolatile > snmpTargetParamsRowStatus createAndGo > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > * snmpTargetAddrTDomain snmpTLSTCPDomain > * snmpTargetAddrTAddress 192.0.2.1:5162 > snmpTargetAddrTimeout 1500 > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR (MUST match above) > snmpTargetAddrStorageType nonVolatile > snmpTargetAddrColumnStatus createAndGo > > tlstmAddrTable row: > snmpTargetAddrName toCRAddr > tlstmAddrServerFingerprint "" > tlstmAddrServerIdentity "server.example.org" > tlstmAddrStorageType nonVolatile > tlstmAddrRowStatus createAndGo > > > Semi-editorial/editorial: > > - Section 1, "While (D)TLS supports multiple authentication > mechanisms, this document only discusses X.509 certificate based > authentication. Although other forms of authentication are possible > they are outside the scope of this specification." sounds a bit > cumbersomet. Perhaps "While [..], this document [..]; other forms of > authentication are outside the scope of this specification" would > be more fluent? > > - Section 1: "connectionless (e.g. UDP or SCTP) transport": > SCTP is connection-oriented, not connectionless. > > - Section 1: We shouldn't have a figure longer than one page. > Here's an attempt to clean the figure slightly so it fits on > one page: > > +---------------------------------------------------------------------+ > | Network | > +---------------------------------------------------------------------+ > ^ | ^ | > |Notifications |Commands |Commands |Notifications > +---|---------------------|-------+ +--|---------------|--------------+ > | | V | | | V | > | +------------+ +------------+ | | +-----------+ +----------+ | > | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | > | | (Client) | | (Server) | | | | (Client) | | (Server) | | > | +------------+ +------------+ | | +-----------+ +----------+ | > | ^ ^ | | ^ ^ | > | | | | | | | | > | +-------------+ | | +--------------+ | > | +-----|------------+ | | +-----|------------+ | > | | V | | | | V | | > | | +--------+ | +-----+ | | | +--------+ | +-----+ | > | | | TLS TM |<--------->|Cache| | | | | TLS TM |<--------->|Cache| | > | | +--------+ | +-----+ | | | +--------+ | +-----+ | > | |Transport Subsys. | ^ | | |Transport Subsys. | ^ | > | +------------------+ | | | +------------------+ | | > | ^ | | | ^ | | > | | +--+ | | | +--+ | > | v | | | V | | > | +-----+ +--------+ +-------+ | | | +-----+ +--------+ +-------+ | | > | | | |Message | |Securi.| | | | | | |Message | |Securi.| | | > | |Disp.| |Proc. | |Subsys.| | | | |Disp.| |Proc. | |Subsys.| | | > | | | |Subsys. | | | | | | | | |Subsys. | | | | | > | | | | | | | | | | | | | | | | | | > | | | | +----+ | | +---+ | | | | | | | +----+ | | +---+ | | | > | | <--->|v3MP|<--> |TSM|<--+ | | | <--->|v3MP|<--->|TSM|<--+ | > | | | | +----+ | | +---+ | | | | | | +----+ | | +---+ | | > | | | | | | | | | | | | | | | | > | +-----+ +--------+ +-------+ | | +-----+ +--------+ +-------+ | > | ^ | | ^ | > | | | | | | > | +-+------------+ | | +-+----------+ | > | | | | | | | | > | v v | | v V | > | +-------------+ +-------------+ | | +-------------+ +-------------+ | > | | COMMAND | | NOTIFICAT. | | | | COMMAND | | NOTIFICAT. | | > | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | | > | | application | | application | | | | application | | application | | > | +-------------+ +-------------+ | | +-------------+ +-------------+ | > | SNMP entity | | SNMP entity | > +---------------------------------+ +---------------------------------+ > > - Section 1.1 says 'The terms "manager" and "agent" are not used in > this document'; however, the rest of the document occasionally uses > the word 'manager' to refer to the person who's configuring > stuff. Should these be changed to 'administrator'? > > - Section 1.1: "this document (unless otherwise specified) is referring > to TLSTM's specific session and not directly to the (D)TLS protocol's > session". Actually, even when this document *does* specify otherwise > and explicitly says "(D)TLS session", it's still usually talking > about D(TLS) connections, not sessions. Proposed rephrasing here: > > "The (D)TLS protocols also have an internal notion of a session and > although these two concepts of a session are related, this document > is referring to the TLSTM's specific session and not directly to > the (D)TLS protocol's session." > > - Section 3: "to close a (D)TLS session" -> "to close the session" > (this is *not* about (D)TLS sessions, but TLSTM sessions) > > - Section 3.1.1, item 2: "The TLS Transport Model MUST support > authentication of both the server and the client." This sentence is > very confusing; it seems to be targeted at the writer of this > specification, not implementor. I would just suggest deleting this > sentence. > > - Section 3.1.1, item 4: "The TLS Transport Model SHOULD support the > message encryption to protect sensitive data from eavesdropping > attacks." This sentence is very confusing; it seems to be targeted at > the writer of this specification, not implementor. Or if it's targeted > at the implementor, is it trying to say that "implementations SHOULD > support at least one cipher suite that does encryption?" (that's not > needed; the mandatory-to-implement cipher suite in TLS RFCs is quite > enough) I would just suggest deleting this sentence. > > - Section 3.1.1, item 5: replace all three paragraphs with > > 5. Denial of Service - the RFC 3411 architecture [RFC3411] states > that denial of service (DoS) attacks need not be addressed by an > SNMP security protocol. However, connectionless transports (like > DTLS over UDP are susceptible to a variety of denial of service > attacks because they are more vulnerable to spoofed IP > addresses. See Section 4.2 for details how the cookie mechanism is > used. This mechanism, though, does not provide any defense against > denial of service attacks mounted from valid IP addresses. > > - Section 3.1.2: "(D)TLS session provides" -> "(D)TLS connection > provides" > > - Section 3.1.3: "D(TLS) Sessions" -> "D(TLS) Connections" > > - Section 3.3, "(D)TLS sessions may be initiated" -> "(D)TLS > connections may be initiated > > - Section 3.3, "locally held certificate" -> "locally held certificate > (and the corresponding private key)" > > - Section 4.1.1, OLD > Authentication using (D)TLS will require that SNMP entities are > provisioned with certificates, which are signed by trusted > certificate authorities (possibly the certificate itself). > NEW: > Authentication using (D)TLS will require that SNMP entities have > certificates, either signed by trusted certification authorities, > or self-signed. > > - Section 4.1.1, "tmpSecurityName" -> "tmSecurityName" > > - Section 4.3.1 and 4.3.2: SnmpTLSDomain -> SnmpTLSTCPDomain > > - Section 4.4.1.1, "Transport Models SHOULD generate a predictable > tmSecurityName so operators will know what to use when configuring MIB > modules that use securityNames derived from tmSecurityNames." > Setting requirements for all transport models (not just DTLSTM) > doesn't seem to belong to this document... > > - Section 4.4.1.1, "through an existing (D)TLS session" -> "through an > existing (D)TLS connection" > > - Section 4.4.1.2, "D(TLS) session" -> "D(TLS) connection" (both > instances) > > - Section 5.1, "for all (D)TLS-based sessions" -> " for > all(D)TLS-based connections" > > - Section 5.1: "TLS and DTLS/SCP" -> "TLS/TCP and DTLS/SCTP" > > - Section 5.1: "5.1.2describes" -> "5.1.2 describes" > > - Section 5.1.2, "lifetime of the (D)TLS session" -> "lifetime of session" > > - Section 5.3 and 5.3.1 and 5.3.2, "(D)TLS session" -> "(D)TLS connection" > (all instances) > > - Section 5.4, "Have (D)TLS close the specified session" -> > "Have (D)TLS close the specified connection" > > - Section 6.3, "(D)TLS session usage" -> "session usage" > > - Section 7, snmpTlstmSessionAccepts DESCRIPTION: TODO > > - Section 7, tlstmParamsTable and tlstmAddrTable: "(D)TLS session" -> > "(D)TLS connection" > > - Section 7, tlstmParamsClientFingerprint: "locally held X.509 > certificate" -> "locally held X.509 certificate (and the corresponding > private key)". > > - Section 8.1, " A session is discussed throughout this document as > meaning a security association between the (D)TLS client and the > (D)TLS server." -> "A session is discussed throughout this document > as meaning a security association between two TLSTM instances." > > - Section 9: OLD > DTLS adds to the security considerations of TLS only because it > is more vulnerable to denial of service attacks. A random cookie > exchange was added to the handshake to prevent anonymous denial > of service attacks. RFC 4347 recommends that the cookie exchange > is utilized for all handshakes. It is also RECOMMENDED by this > specification that users enable this cookie exchange. > NEW: > When run over UDP, DTLS is more vulnerable to denial of service > attacks from spoofed IP addresses; see Section 4.2 for details > how the cookie exchange is used to address this issue. > > - Appendix A and B: Please just delete these -- the details aren't > quite right (e.g. DTLS sessions...), and fixing them is not worth the > effort needed. > > - C.1, would suggest adding "In case the notification originator has > multiple certificates, ..." to the beginning of the 2nd para. > > - C.2, "(D)TLS session" -> "D(TLS) connection" > > - C.2: suggest replacing "HASH" with an example hash. If I understand > the Fingerprint DISPLAY-HINT correctly, that might be something like > "02:68b9389e49a815aa4a79f40fcfce7eb8cd10669c" > > - C.2: OLD > tlstmCertToTSNMapType = 1 (specified) > tlstmCertToTSNSecurityName = "blueberry" > NEW: > tlstmCertToTSNMapType = tlstmCertSpecified > tlstmCertToTSNData = "blueberry" > > - C.2: OLD > tlstmCertToTSNMapType = 2 (bySubjectAltName) > tlstmCertToTSNSANType = 1 (any) > NEW: > tlstmCertToTSNMapType = tlstmCertSANAny > tlstmCertToTSNData = "" (not used) > > - Overall: "certificate authority" -> "certification authority" > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Fri Mar 5 00:16:17 2010 Return-Path: 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 C2A1728C1CF for ; Fri, 5 Mar 2010 00:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 K5VL6lZc9h95 for ; Fri, 5 Mar 2010 00:16:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 57B193A8D58 for ; Fri, 5 Mar 2010 00:16:15 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F2F4C0002; Fri, 5 Mar 2010 09:16:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WXvv4iC1g7GM; Fri, 5 Mar 2010 09:16:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 044D5C0006; Fri, 5 Mar 2010 09:16:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC6F210B8A0F; Fri, 5 Mar 2010 09:16:12 +0100 (CET) Date: Fri, 5 Mar 2010 09:16:12 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100305081612.GC19456@elstar.local> Mail-Followup-To: Wes Hardaker , "Pasi.Eronen@nokia.com" , "isms@ietf.org" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 08:16:17 -0000 On Wed, Mar 03, 2010 at 02:13:42AM +0100, Wes Hardaker wrote: > > PE> AD review comments for draft-ietf-isms-dtls-tm-08 > > Pasi, > > I've acted on most of your comments and have questions/discussion items > about a few. I haven't tackled your rewording suggestions for 5.1.1 yet > and will get to those tomorrow. Please see the notes below about each > item and let me know what you think in particular about the ones marked > "DISCUSS". Wes, thanks for your followup on Pasi's extensive review - and of course thanks to Pasi for his detailed review in the first place. Pasi, do you think we will be able to work through the DISCUSS items so that we can have an updated ID in place before the cutoff?? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 5 00:24:57 2010 Return-Path: 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 EE4F33A8F0C for ; Fri, 5 Mar 2010 00:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] 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 vmviHf4Y1tHF for ; Fri, 5 Mar 2010 00:24:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 797AE28C14E for ; Fri, 5 Mar 2010 00:24:56 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 886A8C0002; Fri, 5 Mar 2010 09:24:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1UiV+V1fubGO; Fri, 5 Mar 2010 09:24:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAC05C0006; Fri, 5 Mar 2010 09:24:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D218A10B8A84; Fri, 5 Mar 2010 09:24:56 +0100 (CET) Date: Fri, 5 Mar 2010 09:24:56 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100305082456.GD19456@elstar.local> Mail-Followup-To: "tom.petch" , "Pasi.Eronen@nokia.com" , isms References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701cabbae$47c86720$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 08:24:58 -0000 On Thu, Mar 04, 2010 at 03:49:49PM +0100, tom.petch wrote: > Pasi > > Two thoughts on your proposal to discourage renegotiation. > > SNMP may have long running sessions - I know, there is no concept of session in > SNMP but allow me a little licence - so that it may trip over limitations on the > usage of the security credentials in a way that other applications do not. > > A certificate could expire and so need to be replaced with a current one, which > is one use of renegotiation. And so much data could flow, or time pass, that > the keys need refreshing, which again renegotiation allows. > > Do you intend that these be NOT RECOMMENDED ie if and when such are needed, tear > down the TLSTM session and start again? > > Second, you change all the TLS session to TLS connection, which is a substantial > change. I had assumed that the author had intended session resumption to be > permitted which your new text would discourage. Again, is this your intention? Speaking as technical contributor: I don't think it is the idea is to make session resumption impossible or to disable rekeying. In fact, I consider session resumption essential. There are many management tools out there that do not maintain long sessions (in particular large collections of scripts) and such scripts will be hit really badly if every call to way snmpwalk kicked off via cron causes an expensive session key calculation. The lack of a session resumption mechanism in SSH makes in my view the SSHTM much less attractive compared to the TLSTM and led us to invent a session resumption mechanism for SSH [1]. /js [1] -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Pasi.Eronen@nokia.com Fri Mar 5 02:56:47 2010 Return-Path: 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 0BBA028C257 for ; Fri, 5 Mar 2010 02:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 N41J0mG3jmLe for ; Fri, 5 Mar 2010 02:56:45 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EEBD728C234 for ; Fri, 5 Mar 2010 02:56:44 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o25AuaL9028192; Fri, 5 Mar 2010 04:56:44 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 12:56:41 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 12:56:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 12:56:32 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 5 Mar 2010 11:56:31 +0100 From: To: Date: Fri, 5 Mar 2010 11:56:30 +0100 Thread-Topic: IsmsAD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq6buTiUVwM9xF4TqqB8blYfxYkZgB3BVHw Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482A52A2@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2010 10:56:32.0421 (UTC) FILETIME=[842AAD50:01CABC52] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Fri, 05 Mar 2010 10:56:47 -0000 Hi Wes, Thanks for a quick reply. Some comments below: > * DISCUSS Currently, the document specifies how the TLS client > authenticates/ > authorizes the TLS server only when SNMP-TARGET-MIB is used. But > clearly authenticating the TLS server is also important for > e.g. command generators. These may not have a MIB, but shouldn't we > at > least recommend an implementation-specific management/configuration > interface that supports configuring the same details as > tlstmAddrTable? > > (E.g. Syslog-over-TLS specifies that the management interface must be > able to configure this stuff, but that "management interface" could > be a configuration file, GUI, or even a proprietary MIB.) > > + WH: The current draft says (5.3.1 bullet 4): > > "The (D)TLS client MUST then verify that the (D)TLS server's > presented certificate is the expected certificate. [...] > > If the connection is being established from configuration > based on SNMP-TARGET-MIB configuration then the procedures > in the tlstmAddrTable DESCRIPTION clause should be followed > to determine if the presented identity matches the > expectations of the configuration. Validation procedures > (like the path validation procedures defined in [RFC5280] > or through the use of fingerprints as defined by the > tlstmAddrServerIdentity column) MUST be followed. If a > server identity name has been configured in the > tlstmAddrServerIdentity column then this reference identity > must be compared against the presented identity (for > example using procedures described in > [I-D.saintandre-tls-server-id-check]). > > If the connection is being established for reasons other > than configuration found in the SNMP-TARGET-MIB then > configuration and procedures outside the scope of this > document should be followed." > > Would adding something like the following to the end of that > last paragraph meet your goals: > > Configuration mechanisms SHOULD be similar in nature to > those defined in the tlstmAddrTable to ensure consistency > across management configuration systems. Yep, this is roughly what I was thinking about. Perhaps we could also add a sentence giving an example what the "reasons other than configuration found in the SNMP-TARGET-MIB" and "configuration mechanisms" might be? For example, a command-line tool for generating SNMP GETs might support specifying either the server's certificate fingerprint or the expected host name as a command line argument. > * DONE Overall: The details of exactly how (D)TLS needs to be used are > scattered over the document, and in some cases, not very clearly > written. Probably we should include a "(D)TLS usage" section that > explains what TLS features/etc. we're using and so on. Here's a first > sketch, replacing current 4.2: > > 4.2. (D)TLS Usage > > (D)TLS MUST negotiate a cipher suite that uses X.509 certificates > for authentication, and MUST authenticate both the client and the > server. The mandatory-to-implement cipher suite is specified in > the TLS specification [RFC5246]. > > TLSTM verifies the certificates when the connection is opened > (see Section 5.3). For this reason, TLS renegotiation with > different certificates MUST NOT be done. That is, > implementations MUST either disable renegotiation completely > (RECOMMENDED), or MUST present the same certificate during > renegotiation (and MUST verify that the other end presented > the same certificate). > > For DTLS over UDP, each SNMP message MUST be placed in a > single UDP datagram; it MAY be split to multiple DTLS > records. In other words, if a single datagram contains > multiple DTLS application_data records, they are concatenated > when received. The TLSTM implementation SHOULD return an error > if the SNMP message does not fit in the UDP datagram, and thus > cannot be sent. > > For DTLS over UDP, the DTLS server implementation MUST support > DTLS cookies ([RFC4347] already requires that clients support > DTLS cookies). Implementations are not required to perform > the cookie exchange for every DTLS handshake; however, > enabling it by default is RECOMMENDED. > > For DTLS, replay protection MUST be used. > > + WH: I'm fine with that wording, with one minor change. The > working group has waffled back and forth generally on how much > "(D)TLS" specific protocol information should be referenced > and thus I could see people objecting to the wording like > "... multiple DTLS application_data records ..." because we > expressly removed wording like that before that talked about > DTLS internals. I'll leave it up to others to complain if > your next text strikes a nerve with them. I think the "multiple DTLS application_data records..." is a detail we need to specify one way or another (the DTLS spec isn't very clear about this, but at least in theory it would be possible to use DTLS so that multiple application_data records are *not* concatenated, and instead treated as separate SNMP messages...) > * DISCUSS Section 3.1.3. "As an implementation hint: although the > tlstmSessionID may be the same as the (D)TLS internal SessionID > caution must be exercised since the (D)TLS internal SessionID may > change over the life of the connection as seen by the TLSTM (for > example during renegotiation). The tlstmSessionID identifier MUST > NOT > change during the entire duration of the session from the TLSTM's > perspective even if the TLS internal session identifier does change." > > This is not correct; it's possible to have several (D)TLS connections > (over different TCP connections, or different UDP five-tuples) that > have the same (D)TLS internal Session ID, so it does not uniquely > identify a TLSTM session. I would suggest just deleting this > paragraph. > > + WH: I think you're missing the point of the paragraph. It's > stating that the SNMP-specific tlstmSessionID MUST NOT and > MUST be consistent. No where does the paragraph state that > the TLS session IDs uniquely identify a session. It only > states that if you use it you need to be careful and I think > this is an important point. I'd be happy to add an additional > sentence describing that a single TLS sessionID may be shared > among connections, but using a shared sessionID within TLSTM > is prohibited. Well, I think the "although the tlstmSessionID may be the same.." part is very misleading; this is NOT an approach an implementation can use. Perhaps something like this? The tlstmSessionID identifier MUST NOT change during the entire duration of the session from the TLSTM's perspective, and MUST uniquely identify a single session. As an implementation hint: note that the (D)TLS internal SessionID does not meet these requirements, since it can change over the life of the connection as seen by the TLSTM (for example, during renegotiation), and does not necessarily uniquely idenfify a TLSTM session (there can be multiple TLSTM sessions sharing the same D(TLS) internal SessionID). > * DISCUSS Section 7, tlstmParamsClientFingerprint: we should > probably allow an empty value to accommodate the common case where > the client has just one certificate/private key? > > + WH: I think it would be better to allow a non-existing row to > indicate use the default client certificate. This probably > isn't clearly spelled out in 5.3.1 step 2, which reads: > > The client selects the appropriate certificate and > cipher_suites for the key agreement based on the > tmSecurityName and the tmRequestedSecurityLevel for the > session. For sessions being established as a result of a > SNMP-TARGET-MIB based operation, the certificate will > potentially have been identified via the tlstmParamsTable > mapping and the cipher_suites will have to be taken from > system-wide or implementation-specific configuration. > > How's this for a suggested addition as a last sentence: > > If no row in the tlstmParamsTable exists then > implementations MAY choose to establish the connection > using a default client certificate available to the > application. Works for me. > * DONE Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some > of the details, and in its present form, would need a normative > reference to draft-saintandre-tls-server-id-check (which we might > want to avoid so this document is not delayed). Suggested > rephrasing: > "This table is used by a (D)TLS client when a (D)TLS connection is > > + WH: > - I like the copying of the text from the other draft. > - The proposed text has been adopted with some rewording and > now reads as follows: > > DESCRIPTION > "This table is used by a (D)TLS client when a (D)TLS > connection is being set up using an entry in the > SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's > snmpTargetAddrTable so that the client can verify that the > correct server has been reached. This verification can use > either a certificate fingerprint, or an identity > authenticated via certification path validation. > > If there is an active row in this table corresponding to the > entry in the SNMP-TARGET-MIB that was used to establish the > connection, and the row's tlstmAddrServerFingerprint column > has non-empty value, then the server's presented certificate > is compared with the tlstmAddrServerFingerprint value (and > the tlstmAddrServerIdentity column is ignored). If the > fingerprint matches, the verification has succeeded. If the > fingerprint does not match then the connection MUST be > closed. > > If the server's presented certificate has passed > certification path validation [RFC5280] to a configured > trust anchor, and an active row exists with a zero-length > tlstmAddrServerFingerprint value, then the > tlstmAddrServerIdentity column contains the expected host > name. This expected host name is then compared against the > server's certificate as follows: > > - Implementations MUST support matching the expected host > name against a dNSName in the subjectAltName extension field > and SHOULD support checking the name against the common name > portion of the subject distinguished name. > > - The '*' (ASCII 0x2a) wildcard character is allowed in the > dNSName of the subjectAltName extension (and in common name, > if used to store the host name), but only as the left-most > (least significant) DNS label in that value. This wildcard > matches any left-most DNS label in the server name. That > is, the subject *.example.com matches the server names > a.example.com and b.example.com, but does not match > example.com or a.b.example.com. Implementations MUST > support wildcards in certificates as specified above, but > MAY provide a configuration option to disable them. > > - If the locally configured name is an internationalized > domain name, conforming implementations MUST convert it to > the ASCII Compatible Encoding (ACE) format for performing > comparisons, as specified in Section 7 of [RFC5280]. > > If the expected host name fails these conditions then the > connection MUST be closed. > > A row MUST NOT contain both a blank > tlstmAddrServerFingerprint column and a '*' in the > tlstmAddrServerIdentity column since this would insecurely > accept any presented certificate. The text earlier allows wildcards in the certificate, but not in tlstmAddrServerIdentity, so this paragraph doesn't make sense. If we wish to allow wildcards also in tlstmAddrServerIdentity, more complex text is needed. RFC 5425, Section 5.2 does have such text, but it leaves the syntax for those wildcards open (they might be regexps or something). > If there is no row in this table corresponding to the entry > in the SNMP-TARGET-MIB and the server can be authorized by > another, implementation dependent means, then the connection > MAY still proceed." > * DONE Section 10, rephrase items 1..6 as: > > 1. Two TCP/UDP/SCTP port numbers from the "Registered Ports" range > of the Port Numbers registry, with keywords "snmptls" and > "snmptls-trap". These are the default ports for receipt of SNMP > command messages (snmptls) and SNMP notification messages > (snmptls-trap) over a TLS Transport Model as defined in this > document. > > And delete both paragraphs starting with "If possible, ..." later > in this section (if we ask for the same port, we will get it). > > + WH: Ok, done. But you removed the guidance about the port > number being > 1023 which was a WG decision to accept > something higher than 1023 as acceptable. Shouldn't we > include such a note as part of the guidance? The "Registered Ports" range means 1024...49151. > * DONE C.1. I think we need an example here. Here's a first attempt > (based on RFC 5591, Appendix A): > + WH: I've added similar text to the above. The above has > some issues with it so I've adapted it to the following: > > To configure a notification originator to open a TLS over TCP > connection to a notification receiver it must be configured > so the server's presented certificate can be verified against > the expected certificate before proceeding to send the > notification. This is done by configuring the tlstmAddrTable > accordingly. For example, if the verification is done via > certification path validation (to a trust anchor configured > in implementation dependent manner), then the table entries > could look like: > > snmpTargetAddrTable row: > snmpTargetAddrName =3D "toNRAddr" > snmpTargetAddrTDomain =3D snmpTLSTCPDomain > snmpTargetAddrTAddress =3D "192.0.2.1:XXXTLSTCPTRAPPORT" > snmpTargetAddrTimeout =3D 1500 > snmpTargetAddrRetryCount =3D 3 > snmpTargetAddrTagList =3D "toNRTag" > snmpTargetAddrParams =3D "toNR" (MUST match below) > snmpTargetAddrStorageType =3D 3 (nonVolatile) > snmpTargetAddrColumnStatus =3D 4 (createAndGo) > > snmpTargetParamsTable row: > snmpTargetParamsName =3D toNR > snmpTargetParamsMPModel =3D SNMPv3 > snmpTargetParamsSecurityModel =3D 4 (TransportSecurityModel) > snmpTargetParamsSecurityName =3D "blueberry" > snmpTargetParamsSecurityLevel =3D 3 (authPriv) > snmpTargetParamsStorageType =3D 3 (nonVolatile) > snmpTargetParamsRowStatus =3D 4 (createAndGo0 > > tlstmAddrTable row: > snmpTargetAddrName =3D "toNRAddr" > tlstmAddrServerFingerprint =3D "" > tlstmAddrServerIdentity =3D "server.example.org" > tlstmAddrStorageType =3D 3 (nonVolatile) > tlstmAddrRowStatus =3D 4 (createAndGo) > > Editor's note: replace the string "XXXTLSTCPTRAPPORT" above with the > appropriately assigned "snmptls-trap" port. > > Editor's note: replace the string "TSMNUM" above with the > appropriately assigned "snmptls-trap" port. Looks good, except the last editor's note looks strange (TSMNUM is not used, and it's not the trap port :). > * WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a > predictable tmSecurityName so operators will know what to use when > configuring MIB modules that use securityNames derived from > tmSecurityNames." Setting requirements for all transport models > (not just DTLSTM) doesn't seem to belong to this document... > > + that's boilerplate-ish text directly from 5592 which we're > copying verbatim. IMHO we would have removed this sentence from 5592 if we had noticed it... but as its currently written, it leaves open the question, well, does TLSTM generate predictable tmSecurityNames, or does it behave unpredictably? So if you feel it provides some valuable information (I don't think it does), it needs to be rephrased anyway... > * DONE Section 7, snmpTlstmSessionAccepts DESCRIPTION: TODO > > + WH: It looks like you wanted to reword this and forgot to > get back to it. Given your other comments I've predicted > your issues and have changed the wording to this: > > "The number of times a (D)TLS server has accepted a new > connection from a client and has received at least one SNMP > message through it." Yes, this was my intent :) > * DISCUSS Appendix A and B: Please just delete these -- the details > aren't quite right (e.g. DTLS sessions...), and fixing them is not > worth the effort needed. > > + WH: The WG discussed these sections in Stockholm (I think) > and the consensus was to leave them as they were useful to > "newbies" and it would be better to move them to an appendix > than to delete them. I've never been really happy with the > text (and in fact didn't even write it), but I want to make > sure you're explicitly trumping WG consensus with your AD > badge before I delete them. Well, as AD I do require that if the text is included, it needs to be correct. Fixing the text will require some effort and will take time. I'm OK if we have WG members who're willing to do that effort and the WG consensus is that it's worth delaying the document. Here's a partial lists of things that are either wrong or misleading: - A.1: encryption keys are not per session, but per connection state (if multiple TLS connections are resumed from the same TLS session, they get different encryption keys) - A.1: "such as the (D)TLS handshake protocol" is very misleading, since it suggests there are other protocols that could be used. But there are none. - A.1: Message integrity doesn't necessarily use hash functions; MACs can also be based on block ciphers, and TLS supports combined mode (authenticated encryption), too. - A.1: "is generally only used" suggests there are other cases; there are none. - A.1: replay protection is optional in DTLS - A.2: the references [AES], [DES], [DSS], [RSA], [X509] are missing most of the details. - A.2: (D)TLS support other ways of authenticating the peers than public-key crypto - A.2: I-D.saintandre-tls-server-id-check applies only to some application protocols; others may use other approaches. - A.2.: "anonymous denial of service attacks" cookies have nothing to do with anonymity; they're about spoofed source IP addresses. - A.2: retransmissions apply only to handshake messages, not whole DTLS - B: the two-step process of verifying signature first, checking digest second doesn't work that way with e.g. DSA or ECDSA. - B describes only certificates directly issued by locally configured trust anchors; but important part of X.509 is path validation. - "root certificate" is not a term used in PKIX - B, "signatureValue": these details of ASN.1 encoding don't seem very useful to a reader who doesn't know what certificates are. > * DONE C.1, would suggest adding "In case the notification originator > has multiple certificates, ..." to the beginning of the 2nd para. > > + WH: I don't think that's quite the right text either. I'm > now adding this to the end: > > (Or else a default certificate may be used if available.) OK. > * WONTDO C.2: suggest replacing "HASH" with an example hash. If I > understand > the Fingerprint DISPLAY-HINT correctly, that might be something like > "02:68b9389e49a815aa4a79f40fcfce7eb8cd10669c" > > + WH: Though I understand the desire to do that, I don't think > it's worth making one up nor is it worth trying to make it > fit within the page width (it'd need to be wrapped multiple > times) Yes, it would mess up the formatting, so perhaps it's ok to leave this as-is... Best regards, Pasi From Pasi.Eronen@nokia.com Fri Mar 5 03:02:26 2010 Return-Path: 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 C401628C25D for ; Fri, 5 Mar 2010 03:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EMzYo0AzORGZ for ; Fri, 5 Mar 2010 03:02:26 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DFD4B28C25C for ; Fri, 5 Mar 2010 03:02:25 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o25B1c9l032138; Fri, 5 Mar 2010 05:02:24 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 13:02:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 13:02:02 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 5 Mar 2010 12:02:02 +0100 From: To: , Date: Fri, 5 Mar 2010 12:02:00 +0100 Thread-Topic: Renego: [Isms] was AD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq7tuFQITmEHCnuQnOg4biR0vcx4gAm6RTQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> In-Reply-To: <000701cabbae$47c86720$0601a8c0@allison> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2010 11:02:02.0244 (UTC) FILETIME=[48C1AC40:01CABC53] X-Nokia-AV: Clean Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Fri, 05 Mar 2010 11:02:26 -0000 Tom Petch wrote: > Pasi >=20 > Two thoughts on your proposal to discourage renegotiation. >=20 > SNMP may have long running sessions - I know, there is no concept of > session in SNMP but allow me a little licence - so that it may trip > over limitations on the usage of the security credentials in a way > that other applications do not. >=20 > A certificate could expire and so need to be replaced with a current > one, which is one use of renegotiation. And so much data could > flow, or time pass, that the keys need refreshing, which again > renegotiation allows. >=20 > Do you intend that these be NOT RECOMMENDED ie if and when such are > needed, tear down the TLSTM session and start again? Well, TCP connections are cheap (since the situations you're describing would occur rarely, not several times a second), so in case of TLSTM, it seems it's much simpler just to start a new connection instead of doing renegotiation. (BTW, tearing down the old one can happen after the new one is up, so this doesn't mean a break in connectivity.) > Second, you change all the TLS session to TLS connection, which is a > substantial change. I had assumed that the author had intended > session resumption to be permitted which your new text would > discourage. Again, is this your intention? No, this is more a terminology fix. When TLSTM needs to establish a connection, it asks TLS to do so; TLS might or might not use previously cached information when doing so (=3Dsession resumption),=20 but that's not visible to TLSTM. Best regards, Pasi From wjhns1@hardakers.net Fri Mar 5 08:59:38 2010 Return-Path: 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 503A03A8A8F for ; Fri, 5 Mar 2010 08:59:38 -0800 (PST) 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=[AWL=0.000, 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 PJaHSj9y4WiT for ; Fri, 5 Mar 2010 08:59:37 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 6B71D3A8ABC for ; Fri, 5 Mar 2010 08:59:37 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 33CE29DCFB; Fri, 5 Mar 2010 08:59:39 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 05 Mar 2010 08:59:38 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 5 Mar 2010 12:02:00 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Fri, 05 Mar 2010 16:59:38 -0000 >>>>> On Fri, 5 Mar 2010 12:02:00 +0100, said: PE> No, this is more a terminology fix. When TLSTM needs to establish a PE> connection, it asks TLS to do so; TLS might or might not use PE> previously cached information when doing so (=session resumption), PE> but that's not visible to TLSTM. I agree; I thought Pasi's terminology change was definitely correct. In summary: you do start a second TLS connection within TLSTM. Think of it in terms of an underlying TCP "connection" and it's easier to think about (and then just extend that to the DTLS case). -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Fri Mar 5 10:40:05 2010 Return-Path: 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 D218E3A8FFA for ; Fri, 5 Mar 2010 10:40:05 -0800 (PST) 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 H52+Sy4QNIyR for ; Fri, 5 Mar 2010 10:40:03 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 5257A3A87C7 for ; Fri, 5 Mar 2010 10:40:03 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3150E9DEEE; Fri, 5 Mar 2010 10:40:05 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482A52A2@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 05 Mar 2010 10:40:04 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482A52A2@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 5 Mar 2010 11:56:30 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Fri, 05 Mar 2010 18:40:06 -0000 Responses in-line. Quick summary though: these outstanding issues are all closed now. > Would adding something like the following to the end of that > last paragraph meet your goals: > > Configuration mechanisms SHOULD be similar in nature to > those defined in the tlstmAddrTable to ensure consistency > across management configuration systems. PE> Yep, this is roughly what I was thinking about. Perhaps we could also PE> add a sentence giving an example what the "reasons other than PE> configuration found in the SNMP-TARGET-MIB" and "configuration PE> mechanisms" might be? PE> For example, a command-line tool for generating SNMP GETs might PE> support specifying either the server's certificate fingerprint or PE> the expected host name as a command line argument. I think that's good text and have added it. Thanks. Issue-status-change: DONE > * DISCUSS Section 3.1.3. "As an implementation hint: although the > tlstmSessionID may be the same as the (D)TLS internal SessionID > caution must be exercised since the (D)TLS internal SessionID may > change over the life of the connection as seen by the TLSTM (for > example during renegotiation). The tlstmSessionID identifier MUST > NOT > change during the entire duration of the session from the TLSTM's > perspective even if the TLS internal session identifier does change." > > This is not correct; it's possible to have several (D)TLS connections > (over different TCP connections, or different UDP five-tuples) that > have the same (D)TLS internal Session ID, so it does not uniquely > identify a TLSTM session. I would suggest just deleting this > paragraph. > > + WH: I think you're missing the point of the paragraph. It's > stating that the SNMP-specific tlstmSessionID MUST NOT and > MUST be consistent. No where does the paragraph state that > the TLS session IDs uniquely identify a session. It only > states that if you use it you need to be careful and I think > this is an important point. I'd be happy to add an additional > sentence describing that a single TLS sessionID may be shared > among connections, but using a shared sessionID within TLSTM > is prohibited. PE> Well, I think the "although the tlstmSessionID may be the same.." part PE> is very misleading; this is NOT an approach an implementation can use. PE> Perhaps something like this? PE> The tlstmSessionID identifier MUST NOT change during the entire PE> duration of the session from the TLSTM's perspective, and MUST PE> uniquely identify a single session. As an implementation hint: PE> note that the (D)TLS internal SessionID does not meet these PE> requirements, since it can change over the life of the connection PE> as seen by the TLSTM (for example, during renegotiation), and does PE> not necessarily uniquely idenfify a TLSTM session (there can be PE> multiple TLSTM sessions sharing the same D(TLS) internal PE> SessionID). I think this new wording is the most clear yet, so I've put it in place. Issue-status-change: DONE > * DISCUSS Section 7, tlstmParamsClientFingerprint: we should > probably allow an empty value to accommodate the common case where > the client has just one certificate/private key? > > + WH: I think it would be better to allow a non-existing row to > indicate use the default client certificate. This probably > isn't clearly spelled out in 5.3.1 step 2, which reads: > > The client selects the appropriate certificate and > cipher_suites for the key agreement based on the > tmSecurityName and the tmRequestedSecurityLevel for the > session. For sessions being established as a result of a > SNMP-TARGET-MIB based operation, the certificate will > potentially have been identified via the tlstmParamsTable > mapping and the cipher_suites will have to be taken from > system-wide or implementation-specific configuration. > > How's this for a suggested addition as a last sentence: > > If no row in the tlstmParamsTable exists then > implementations MAY choose to establish the connection > using a default client certificate available to the > application. PE> Works for me. Issue-status-change: DONE > * DONE Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some > of the details, and in its present form, would need a normative > reference to draft-saintandre-tls-server-id-check (which we might > want to avoid so this document is not delayed). Suggested > rephrasing: [...] > A row MUST NOT contain both a blank > tlstmAddrServerFingerprint column and a '*' in the > tlstmAddrServerIdentity column since this would insecurely > accept any presented certificate. PE> The text earlier allows wildcards in the certificate, but not in PE> tlstmAddrServerIdentity, so this paragraph doesn't make sense. Oh, whoops. I put that in the email but had deleted it from the actual draft. Sorry about that. > * DONE Section 10, rephrase items 1..6 as: > > + WH: Ok, done. But you removed the guidance about the port > number being > 1023 which was a WG decision to accept > something higher than 1023 as acceptable. Shouldn't we > include such a note as part of the guidance? PE> The "Registered Ports" range means 1024...49151. Ah, duh. Thanks. > * DONE C.1. I think we need an example here. Here's a first attempt > (based on RFC 5591, Appendix A): > + WH: I've added similar text to the above. The above has > some issues with it so I've adapted it to the following: [...] > Editor's note: replace the string "TSMNUM" above with the > appropriately assigned "snmptls-trap" port. PE> Looks good, except the last editor's note looks strange (TSMNUM is not PE> used, and it's not the trap port :). Ah, good catch. It shouldn't have been there and I removed it. > * WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a > predictable tmSecurityName so operators will know what to use when > configuring MIB modules that use securityNames derived from > tmSecurityNames." Setting requirements for all transport models > (not just DTLSTM) doesn't seem to belong to this document... > > + that's boilerplate-ish text directly from 5592 which we're > copying verbatim. PE> IMHO we would have removed this sentence from 5592 if we had noticed PE> it... but as its currently written, it leaves open the question, PE> well, does TLSTM generate predictable tmSecurityNames, or does it PE> behave unpredictably? PE> So if you feel it provides some valuable information (I don't PE> think it does), it needs to be rephrased anyway... Actually, I think adding this text at the end of the above paragraph makes everything fit nicely together and discuss some of the implications of the TLSTM: The TLSTM generates predictable tmSecurityNames based on the configuration found in the TLSTM-MIB's tlstmCertToTSNTable and relies on the network operators to have configured this table appropriately. Sound good? Issue-status-change: DONE (though I'll reopen if you think this doesn't solve the problem). > * DISCUSS Appendix A and B: Please just delete these -- the details > aren't quite right (e.g. DTLS sessions...), and fixing them is not > worth the effort needed. > PE> Well, as AD I do require that if the text is included, it needs to PE> be correct. Fixing the text will require some effort and will take PE> time. I'm OK if we have WG members who're willing to do that effort PE> and the WG consensus is that it's worth delaying the document. Since no one else has spoken up on the subject, I'll delete it. We can still wait for the screams. I have recorded locally you list of issues so that I can make sure they're fixed if people feel strongly that removing it was a mistake. Issue-status-change: DONE > * WONTDO C.2: suggest replacing "HASH" with an example hash. If I > understand > the Fingerprint DISPLAY-HINT correctly, that might be something like > "02:68b9389e49a815aa4a79f40fcfce7eb8cd10669c" > > + WH: Though I understand the desire to do that, I don't think > it's worth making one up nor is it worth trying to make it > fit within the page width (it'd need to be wrapped multiple > times) Yes, it would mess up the formatting, so perhaps it's ok to leave this as-is... Best regards, Pasi -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Fri Mar 5 12:20:43 2010 Return-Path: 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 AB76328C330 for ; Fri, 5 Mar 2010 12:20:43 -0800 (PST) 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 7V-e2UVlXYWm for ; Fri, 5 Mar 2010 12:20:35 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 7E7553A8E4E for ; Fri, 5 Mar 2010 12:20:35 -0800 (PST) X-Trace: 188544767/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.43/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.43 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHAMf1kEs+vGkr/2dsb2JhbACBehgYhSmJGItRtyQNhGoE X-IronPort-AV: E=Sophos;i="4.49,588,1262563200"; d="scan'208";a="188544767" X-IP-Direction: IN Received: from 1cust43.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.43]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Mar 2010 20:20:20 +0000 Message-ID: <000e01cabc98$bb9c1620$0601a8c0@allison> From: "tom.petch" To: , "isms" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 5 Mar 2010 20:07:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:20:43 -0000 ----- Original Message ----- From: To: ; Sent: Friday, March 05, 2010 12:02 PM Tom Petch wrote: > Two thoughts on your proposal to discourage renegotiation. > > SNMP may have long running sessions - I know, there is no concept of > session in SNMP but allow me a little licence - so that it may trip > over limitations on the usage of the security credentials in a way > that other applications do not. > > A certificate could expire and so need to be replaced with a current > one, which is one use of renegotiation. And so much data could > flow, or time pass, that the keys need refreshing, which again > renegotiation allows. > > Do you intend that these be NOT RECOMMENDED ie if and when such are > needed, tear down the TLSTM session and start again? Well, TCP connections are cheap (since the situations you're describing would occur rarely, not several times a second), so in case of TLSTM, it seems it's much simpler just to start a new connection instead of doing renegotiation. (BTW, tearing down the old one can happen after the new one is up, so this doesn't mean a break in connectivity.) Yes and no; we are now binding the TLSTM session to the (D)TLS connection so starting a new TLS connection will force a new TLSTM session with a break in connectivity (SNMP is not HTTP:-). Worst case scenario would be for this to happen between Get and Response causing the Response to be discarded, making TLS/TCP an unreliable transport (compared to UDP:-) Which is ok with me. > Second, you change all the TLS session to TLS connection, which is a > substantial change. I had assumed that the author had intended > session resumption to be permitted which your new text would > discourage. Again, is this your intention? No, this is more a terminology fix. When TLSTM needs to establish a connection, it asks TLS to do so; TLS might or might not use previously cached information when doing so (=session resumption), but that's not visible to TLSTM. If TLS reuses the connection state with a new transport 5-tuple, then I expect that that will upset TLSTM. If TLS reuses connection state with an old 5-tuple (a rare event with TCP), then again, I expect that that will upset TLSTM. So I think there cannot be session resumption. Again, not a problem for me. Underlying this is the lack of the concept of a session in SNMP so it uses the transport parameters as a proxy for it to get Responses back to the right place; a change of transport parameters ripples up to the application. No abstraction layer here. Tom Petch Best regards, Pasi From wjhns1@hardakers.net Fri Mar 5 18:15:34 2010 Return-Path: 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 D83F028B797 for ; Fri, 5 Mar 2010 18:15:34 -0800 (PST) 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=[AWL=0.000, 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 Jcn3sS6tn4Qm for ; Fri, 5 Mar 2010 18:15:33 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id C8CD23A89DB for ; Fri, 5 Mar 2010 18:15:32 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9E2149E15D; Fri, 5 Mar 2010 18:15:34 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 05 Mar 2010 18:15:34 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Thu, 25 Feb 2010 14:23:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 02:15:35 -0000 Pasi, The last remaining issue was section 5.1.1, which I mentioned in the previous note was a bit more complex and would take more time. I've now completed the review of the old vs the new and tried to accommodate everything. Let me know if the following doesn't meet your needs. * DONE Your comment: ------------- Largely for the same reason, Section 5.1.1 is not quite correct; here's an attempt to rephrase it: 5.1.1. DTLS over UDP Processing for Incoming Messages For connection-oriented transport protocols, such as TCP, the transport protocol takes care of demultiplexing incoming packets to the right connection. Depending on the DTLS implementation, for DTLS over UDP, this demultiplexing may need to be done by the TLSTM implementation. Like TCP, DTLS over UDP uses the four-tuple for identifying the connection (and relevant DTLS connection state). This means that when establishing a new session, implementations MUST use a different UDP source port number for each active connection to a remote destination IP-address/port-number combination to ensure the remote entity can disambiguate between multiple connections. If demultiplexing received UDP datagrams to DTLS connection state is done by the TLSTM implementation (instead of the DTLS implementation), the steps below describe one possible method to accomplish this. 1) The TLS Transport Model examines the UDP datagram, in an implementation-dependent manner. 2) The TLS Transport Model queries the LCD using the transport parameters (source and destination IP addresses and ports) to determine if a session already exists. If a matching entry in the LCD does not exist, create a new entry containing the transport parameters; a new DTLS connection handle (an implementation-dependent detail), and a new tlsTmSessionId. 3) Pass the UDP packet and DTLS connection handle to DTLS (in implementation-dependent manner). If processing does not return an incomingMessage and an incomingMessageLength then processing stops (this is the case when the UDP datagram contained DTLS handshake messages, for example). 4) Retrieve the incomingMessage and an incomingMessageLength from DTLS. These results and the tlstmSessionID are used below in Section 5.1.2 to complete the processing of the incoming message. My Response ----------- + WH: Issues with your text: + Some important elements were dropped. + You end up creating LCD entries *before* DTLS has the opportunity to throw out bad packets which could lead to a resource consumption attack (messages to dead or unknown connections on the server's side will result in creating state). Based on this, I took your text and changed it a bit to produce this. Let me know if this looks ok to you. I believe it addresses your concerns with the original text and my concerns with yours ;-) 5.1.1. DTLS over UDP Processing for Incoming Messages For connection-oriented transport protocols, such as TCP, the transport protocol takes care of demultiplexing incoming packets to the right connection. Depending on the DTLS implementation, for DTLS over UDP, this demultiplexing may need to be done by the TLSTM implementation. Like TCP, DTLS over UDP uses the four-tuple for identifying the connection (and relevant DTLS connection state). This means that when establishing a new session, implementations MUST use a different UDP source port number for each active connection to a remote destination IP-address/port-number combination to ensure the remote entity can disambiguate between multiple connections. If demultiplexing received UDP datagrams to DTLS connection state is done by the TLSTM implementation (instead of the DTLS implementation), the steps below describe one possible method to accomplish this. The important output results from the steps in this process are the remote transport address, incomingMessage, incomingMessageLength, and the tlstmSessionID. 1) The TLS Transport Model examines the raw UDP message, in an implementation-dependent manner. 2) The TLS Transport Model queries the LCD using the transport parameters (source and destination IP addresses and ports) to determine if a session already exists. 2a) If a matching entry in the LCD does not exist then the UDP packet is passed to the DTLS implementation for processing. If the DTLS implementation returns both success and a new connection handle then this and a newly assigned tlstmSessionId is cached as a new entry in the LCD. If the DTLS implementation returns an error then processing stops. 2b) If a session does exist in the LCD then its DTLS connection handle (an implementation dependent detail) and its tlstmSessionId is extracted from the LCD. The UDP packet and the connection handle is passed to the DTLS implementation. If the DTLS implementation returns success but does not return an incomingMessage and an incomingMessageLength then processing stops (this is the case when the UDP datagram contained DTLS handshake messages, for example). If the DTLS implementation returns an error then processing stops. 3) Retrieve the incomingMessage and an incomingMessageLength from DTLS. These results and the tlstmSessionID are used below in Section 5.1.2 to complete the processing of the incoming message. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Fri Mar 5 18:32:23 2010 Return-Path: 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 A147D3A89E4 for ; Fri, 5 Mar 2010 18:32:23 -0800 (PST) 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=[AWL=0.000, 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 K3E4r-GKhvfO for ; Fri, 5 Mar 2010 18:32:22 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A05513A89AF for ; Fri, 5 Mar 2010 18:32:22 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 180D69E167; Fri, 5 Mar 2010 18:32:25 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> <000e01cabc98$bb9c1620$0601a8c0@allison> Date: Fri, 05 Mar 2010 18:32:24 -0800 In-Reply-To: <000e01cabc98$bb9c1620$0601a8c0@allison> (tom petch's message of "Fri, 5 Mar 2010 20:07:13 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 02:32:23 -0000 >>>>> On Fri, 5 Mar 2010 20:07:13 +0100, "tom.petch" said: tp> Yes and no; we are now binding the TLSTM session to the (D)TLS tp> connection so starting a new TLS connection will force a new TLSTM tp> session with a break in connectivity (SNMP is not HTTP:-). Worst tp> case scenario would be for this to happen between Get and Response tp> causing the Response to be discarded, making TLS/TCP an unreliable tp> transport (compared to UDP:-) Which is ok with me. Anything we do could result in something going down between the point where the command responder starts processing a request and the point it wants to send the reply back out. Pasi's text changes haven't affected this at all. But renegotiation with a new session would require a potential change in a securityName which is a bigger issue. I don't think we have any scenarios that really require renegotiation so I don't see the harm in dropping support for it, but I do see benefits. tp> If TLS reuses the connection state with a new transport 5-tuple, then tp> I expect that that will upset TLSTM. TLSTM will operate just fine. There may be a new tlstmSessionId even though a previously existing session within TLS was reused. But again, the only time I see that being a problem is in the middle of command or notification responder processing (or proxy). But again, the connection has already gone down in this case so the responder is already stuck. Session resumption merely buys us the ability to spin up faster the next time around. Pasi's rewording of session -> connection doesn't change any of this. tp> If TLS reuses connection state with an old 5-tuple (a rare event tp> with TCP), then again, I expect that that will upset TLSTM. With proper processing then TLSTM should have dropped it's knowledge on a TCP close. On a dead DTLS case, DTLS will be just as confused as TLSTM would be and again, nothing new is introduced. tp> So I think there cannot be session resumption. Again, not a problem tp> for me. I think you're wrong about that. But we don't spell out the details of when and how you'd do that within our draft (and we didn't before either). Implementations could very easily implement session resumption by matching remote targets with sessions that could be reused. Can you find text in our document that would prohibit that from working? Note that session resumption would need to happen in the same way that algorithm selection needs to happen: via configuration beyond the scope of this document, as is already stated. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Sat Mar 6 02:00:01 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8BD1E3A90A3; Sat, 6 Mar 2010 02:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100306100001.8BD1E3A90A3@core3.amsl.com> Date: Sat, 6 Mar 2010 02:00:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-05.txt 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: , X-List-Received-Date: Sat, 06 Mar 2010 10:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Extensions to the View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-05.txt Pages : 20 Date : 2010-03-06 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes a backward-compatible supplement to the View-based Access Control Model (VACM) for version 3 of the Simple Network Management Protocol (SNMPv3) for use with the Remote Authentication Dial-In User Service (RADIUS) or other Authentication, Authorization, and Accounting (AAA) services to provide authorization of MIB database access, and defines objects for managing this supplement. It is intended to be used in conjunction with session-oriented secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. Comments are solicited and should be addressed to the working group's mailing list at isms@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-06015658.I-D@ietf.org> --NextPart-- From Pasi.Eronen@nokia.com Sat Mar 6 03:59:19 2010 Return-Path: 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 D52E83A89DD for ; Sat, 6 Mar 2010 03:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CoNaztVc7C5B for ; Sat, 6 Mar 2010 03:59:19 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 13B213A89D1 for ; Sat, 6 Mar 2010 03:59:18 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26BxIYE003783; Sat, 6 Mar 2010 05:59:19 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:59:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:59:13 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sat, 6 Mar 2010 12:59:13 +0100 From: To: Date: Sat, 6 Mar 2010 12:59:12 +0100 Thread-Topic: IsmsAD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq8k12+dGkY+TpfTvWWuE5OX5x3ZgAkOpJA Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF053@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482A52A2@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2010 11:59:13.0741 (UTC) FILETIME=[70804FD0:01CABD24] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 11:59:19 -0000 Wes Hardaker wrote: > > * WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a > > predictable tmSecurityName so operators will know what to use when > > configuring MIB modules that use securityNames derived from > > tmSecurityNames." Setting requirements for all transport models > > (not just DTLSTM) doesn't seem to belong to this document... > > > > + that's boilerplate-ish text directly from 5592 which we're > > copying verbatim. >=20 > PE> IMHO we would have removed this sentence from 5592 if we had > PE> noticed > PE> it... but as its currently written, it leaves open the question, > PE> well, does TLSTM generate predictable tmSecurityNames, or does it > PE> behave unpredictably? > PE> > PE> So if you feel it provides some valuable information (I don't > PE> think it does), it needs to be rephrased anyway... >=20 > Actually, I think adding this text at the end of the above paragraph > makes everything fit nicely together and discuss some of the > implications of the TLSTM: >=20 > The TLSTM generates predictable tmSecurityNames > based on the configuration found in the TLSTM-MIB's > tlstmCertToTSNTable and relies on the network operators to have > configured this table appropriately. >=20 > Sound good? >=20 > Issue-status-change: DONE (though I'll reopen if you think this > doesn't solve the problem). Sounds good! Best regards, Pasi From Pasi.Eronen@nokia.com Sat Mar 6 04:12:17 2010 Return-Path: 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 B2F3728C11D for ; Sat, 6 Mar 2010 04:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EmTF09YQ+h7d for ; Sat, 6 Mar 2010 04:12:15 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 562C328C1CD for ; Sat, 6 Mar 2010 04:12:14 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26CCBjf016223; Sat, 6 Mar 2010 14:12:12 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:12:11 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:12:06 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:12:02 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sat, 6 Mar 2010 13:12:01 +0100 From: To: , Date: Sat, 6 Mar 2010 13:12:00 +0100 Thread-Topic: Renego: [Isms] was AD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq8oUoOtRXPzle5SeeQAW3G+1dHTgAg0P+Q Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF055@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> <000e01cabc98$bb9c1620$0601a8c0@allison> In-Reply-To: <000e01cabc98$bb9c1620$0601a8c0@allison> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2010 12:12:02.0324 (UTC) FILETIME=[3A9CC540:01CABD26] X-Nokia-AV: Clean Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 12:12:18 -0000 Tom Petch wrote: >> Well, TCP connections are cheap (since the situations you're >> describing would occur rarely, not several times a second), so in case >> of TLSTM, it seems it's much simpler just to start a new connection >> instead of doing renegotiation. >>=20 >> (BTW, tearing down the old one can happen after the new one is up, >> so this doesn't mean a break in connectivity.) >=20 > > Yes and no; we are now binding the TLSTM session to the (D)TLS > connection so starting a new TLS connection will force a new TLSTM > session with a break in connectivity (SNMP is not HTTP:-). Worst > case scenario would be for this to happen between Get and Response > causing the Response to be discarded, making TLS/TCP an unreliable > transport (compared to UDP:-) Which is ok with me. > Well, nothing prevents having more than one TLS connection between the SNMP entities, so tearing down the old one could happen some time after the new one has been established... >>> Second, you change all the TLS session to TLS connection, which is a >>> substantial change. I had assumed that the author had intended >>> session resumption to be permitted which your new text would >>> discourage. Again, is this your intention? > > >> No, this is more a terminology fix. When TLSTM needs to establish a >> connection, it asks TLS to do so; TLS might or might not use >> previously cached information when doing so (=3Dsession resumption), >> but that's not visible to TLSTM. >=20 > > If TLS reuses the connection state with a new transport 5-tuple, > then I expect that that will upset TLSTM. If TLS reuses connection > state with an old 5-tuple (a rare event with TCP), then again, I > expect that that will upset TLSTM. So I think there cannot be > session resumption. Again, not a problem for me. (BTW, in TLS "connection state" and "session state" are different things; TLS will never reuse the connection state for another connection.) This will not upset TLSTM, because to applications, new and resumed TLS connections look exactly the same (TLSTM does not know whether session resumption is happening or not, and does not need to=20 know -- it's a purely TLS internal detail). Best regards, Pasi From Pasi.Eronen@nokia.com Sat Mar 6 04:27:40 2010 Return-Path: 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 61DD73A90B3 for ; Sat, 6 Mar 2010 04:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1LEfn8nhT0sn for ; Sat, 6 Mar 2010 04:27:39 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 872DA3A90AC for ; Sat, 6 Mar 2010 04:27:39 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26CRcHc026295; Sat, 6 Mar 2010 06:27:40 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:27:33 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:27:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 14:27:29 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sat, 6 Mar 2010 13:27:28 +0100 From: To: Date: Sat, 6 Mar 2010 13:27:27 +0100 Thread-Topic: IsmsAD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq80u0+6WSwCqAMRmG/YVpvYvTHIgAU20vQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF057@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2010 12:27:29.0318 (UTC) FILETIME=[6324D460:01CABD28] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 12:27:40 -0000 Wes Hardaker wrote: > + WH: Issues with your text: > + Some important elements were dropped. > + You end up creating LCD entries *before* DTLS has the > opportunity to throw out bad packets which could lead to a > resource consumption attack (messages to dead or unknown > connections on the server's side will result in creating > state). Good point! Creating the LCD entry is needed only if DTLS has decided to allocate state (which doesn't happen if it responds to ClientHello with HelloVerifyRequest, or if the incoming packet is junk). > 2a) If a matching entry in the LCD does not exist then the UDP > packet is passed to the DTLS implementation for processing. If the > DTLS implementation returns both success and a new connection handle > then this and a newly assigned tlstmSessionId is cached as a new > entry in the LCD. If the DTLS implementation returns an error then > processing stops. It's not quite clear what "returns success" means here. Perhaps something like this: 2a) If a matching entry in the LCD does not exist, then the UDP packet is passed to the DTLS implementation for processing. If the DTLS implementation decides to continue with the connection and allocate state for it, it returns a new DTLS connection handle (an implementation dependent detail). In this case, TLSTM selects a new tlstmSessionId, and caches this and the DTLS connection handle as a new entry in the LCD (indexed by the transport parameters). If the DTLS implementation returns an error or does not allocate connection state (which can happen with the stateless cookie exchange), processing=20 stops. Best regards, Pasi From wjhns1@hardakers.net Sat Mar 6 07:18:41 2010 Return-Path: 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 45E5C3A8CF8 for ; Sat, 6 Mar 2010 07:18:41 -0800 (PST) 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 6yfK42G5dslC for ; Sat, 6 Mar 2010 07:18:40 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 9A96E3A8CB8 for ; Sat, 6 Mar 2010 07:18:36 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B2D909E3B7; Sat, 6 Mar 2010 07:18:38 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482FF057@NOK-EUMSG-01.mgdnok.nokia.com> Date: Sat, 06 Mar 2010 07:18:38 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF057@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Sat, 6 Mar 2010 13:27:27 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Sat, 06 Mar 2010 15:18:41 -0000 >>>>> On Sat, 6 Mar 2010 13:27:27 +0100, said: PE> It's not quite clear what "returns success" means here. Perhaps PE> something like this: Ok, I've changed the text to that. Which closes out the new outstanding issues entirely and I'll go publish a new copy of the draft momentarily which should meet all of your outstanding "revision needed" requirements. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Sat Mar 6 08:30:01 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A6C8228C10F; Sat, 6 Mar 2010 08:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100306163001.A6C8228C10F@core3.amsl.com> Date: Sat, 6 Mar 2010 08:30:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-09.txt 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: , X-List-Received-Date: Sat, 06 Mar 2010 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-09.txt Pages : 63 Date : 2010-03-06 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-06081622.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Sat Mar 6 11:49:44 2010 Return-Path: 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 224793A8FFD for ; Sat, 6 Mar 2010 11:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 ymm+AWls0HtN for ; Sat, 6 Mar 2010 11:49:43 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 5A4CB3A8E21 for ; Sat, 6 Mar 2010 11:49:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Pz9+7fn2Aon1k20yY6D7dlgBbJ/WhZNIomrDUrVhhOFPrykxd9VLdlvhoprbkxTl; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.238.67] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1No00Q-0002be-0r for isms@ietf.org; Sat, 06 Mar 2010 14:49:46 -0500 Message-ID: <001f01cabd66$54668840$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Sat, 6 Mar 2010 11:50:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b403a4014a711052b732e5103274aebc041350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.67 Subject: [Isms] RADIUS/VACM - do we need to talk about tmStateReference? 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: , X-List-Received-Date: Sat, 06 Mar 2010 19:49:44 -0000 Hi - I've posted an update to the document. There are a few (IMO) very minor points left to resolve. I'll send out a separate message for each issue. I think the first and second ones are closely linked: 1. Is there really any need to talk about the tmStateReference cache? 2. Is there a need for the RFC 5590 reference to be normative? Is it needed at all? Currently, tmStateReference is introduced in 4.2, but not used anywhere else. I don't think it is needed or even helpful, and would propose removing it. RFC 5590 is mentioned twice in the document. The first is in a list of "important" documents in the introduction, and the second is as the point of reference for tmStateReference. If we get rid of the talk about tmStateReference, I don't see why the reference to RFC 5590 would need to be normative, but I'm willing to be convinced otherwise. The MIB module mentions tmSessionID in an example in a DESCRIPTION, but we don't have a good way to make references for things like this. I think that RFC 5590 should at least be in the informative references for this reason, but would like (a) confirmation from the group that this makes sense, and (b) suggestions on how to make the reference so the id-nits tools don't complain. Randy From randy_presuhn@mindspring.com Sat Mar 6 11:58:13 2010 Return-Path: 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 0F9B43A8BEE for ; Sat, 6 Mar 2010 11:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 5DZo8rTbJ00s for ; Sat, 6 Mar 2010 11:58:12 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 4B0123A873F for ; Sat, 6 Mar 2010 11:58:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VSjXH65pI7tyhDe+QwpfiC/zmhMpd0yhiPy6sLUPErxFH5+JHLiL7eAq6fzcDigd; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.238.67] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1No08d-0007Wl-06 for isms@ietf.org; Sat, 06 Mar 2010 14:58:15 -0500 Message-ID: <002501cabd67$86cacfc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Sat, 6 Mar 2010 11:59:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a45a1da2f424e90b4bc60aa0c1cd5cb0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.67 Subject: [Isms] RADIUS/VACM - normative reference to RFC 5591? 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: , X-List-Received-Date: Sat, 06 Mar 2010 19:58:13 -0000 Hi - There is one other issue that I think needs to be brought to the WG's attention. Even if we decide to do nothing about it, I think the decision should be a conscious one. Issue: 3. Does the reference to RFC 5591 need to be normative? One of the surprising things about the evolution of the RADIUS/VACM integration is that all the references to RFC 5591 come very close to being "for examples", rather than clear normative references. This is a consequence of our decision to describe this integration in a way that would permit its use with other transports / security models. Indeed, even the title has become somewhat misleading, since RADIUS is just one example of an AAA service that could be supported. On the other hand, the document DOES spell out exactly which RADIUS attributes are to be used, and just "hand waves" what would be used with other AAA services. Do we want / need to do anything about this? Randy From Pasi.Eronen@nokia.com Sun Mar 7 23:07:22 2010 Return-Path: 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 2B2CA3A6930 for ; Sun, 7 Mar 2010 23:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ScnShPPxkdhL for ; Sun, 7 Mar 2010 23:07:21 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 38C493A692E for ; Sun, 7 Mar 2010 23:07:21 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2877J32020918; Mon, 8 Mar 2010 01:07:22 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:07:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:07:07 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 8 Mar 2010 08:07:00 +0100 From: To: Date: Mon, 8 Mar 2010 08:06:59 +0100 Thread-Topic: IsmsAD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq9QFJ8QAsxWwjcTTqFnoReRe4MHgBTY+Mg Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF378@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482FF057@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2010 07:07:07.0554 (UTC) FILETIME=[F6E7E820:01CABE8D] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Mon, 08 Mar 2010 07:07:22 -0000 Thanks! Version -09 looks good, and I've asked the secretariat=20 to start the IETF last call. Best regards, Pasi > -----Original Message----- > From: ext Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: 06 March, 2010 17:19 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: wjhns1@hardakers.net; isms@ietf.org > Subject: Re: IsmsAD review comments for draft-ietf-isms-dtls-tm-08 >=20 > >>>>> On Sat, 6 Mar 2010 13:27:27 +0100, said: >=20 > PE> It's not quite clear what "returns success" means here. Perhaps > PE> something like this: >=20 > Ok, I've changed the text to that. Which closes out the new > outstanding > issues entirely and I'll go publish a new copy of the draft momentarily > which should meet all of your outstanding "revision needed" > requirements. > -- > Wes Hardaker > Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Mar 8 01:08:30 2010 Return-Path: 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 6B7853A67A1 for ; Mon, 8 Mar 2010 01:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 DcE96X918vqu for ; Mon, 8 Mar 2010 01:08:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 28DC63A67CF for ; Mon, 8 Mar 2010 01:08:29 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93A8FC0014 for ; Mon, 8 Mar 2010 10:08:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9rf6FF2c4CBs; Mon, 8 Mar 2010 10:08:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A58DC0007; Mon, 8 Mar 2010 10:08:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 74C9510BF7CB; Mon, 8 Mar 2010 10:08:29 +0100 (CET) Date: Mon, 8 Mar 2010 10:08:29 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100308090828.GA1852@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] wg last call on the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:08:30 -0000 This message starts a 14-day working group last call on the following document: Extensions to the View-based Access Control Model for use with RADIUS http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-05 This WGLC will end on March 22, 2010. Please review the document and post your comments on the mailing list. If you have reviewed the document but do not have comments, please let us know as well. We will treat the questions Randy Presuhn asked on the WG mailing list on March 6 as WG last call comments. Please review this version of the document - it is reasonably short and should not take too much time to review. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dnelson@elbrysnetworks.com Mon Mar 8 05:59:20 2010 Return-Path: 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 5EF493A695B for ; Mon, 8 Mar 2010 05:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9ScQRqmW9XHf for ; Mon, 8 Mar 2010 05:59:19 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 876683A683E for ; Mon, 8 Mar 2010 05:59:18 -0800 (PST) Received: (qmail 22688 invoked from network); 8 Mar 2010 13:59:20 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 13:59:20 -0000 Message-Id: <7F09BE1B-ABA2-45BA-A8FB-0FE69BE65A16@elbrysnetworks.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--160732267 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Mon, 8 Mar 2010 08:59:20 -0500 References: <001f01cabd66$54668840$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] RADIUS/VACM - do we need to talk about tmStateReference? 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: , X-List-Received-Date: Mon, 08 Mar 2010 13:59:20 -0000 --Apple-Mail-1--160732267 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Resending from my enrolled email address. > On Mar 6, 2010, at 2:50 PM, Randy Presuhn wrote: > >> 1. Is there really any need to talk about the tmStateReference >> cache? > > Not strictly speaking. It is necessary to bind the session in the > Transport Model to the dynamically created rows in the > extVacmSecurityToGropTable and the vacmSecurityToGroupTable. Such > a session identifier is described in Section 7.2, et seq. The > mention of tmStateReference was originally added to suggest one way > of maintaining that required binding. Specifying the requirements > of the binding, without suggesting a specific implementation is > sufficient. > >> 2. Is there a need for the RFC 5590 reference to be normative? Is >> it needed at all? > > It probably doesn't need to be normative. On the other hand, the > methods described in this document are *only* applicable when a > Secure Transport Model is also in use, so it would seem reasonable > to keep it as an informative reference. > > Regards, > > Dave > > David B. Nelson > > Elbrys Networks, Inc. > 282 Corporate Drive, Unit 1 > Portsmouth, NH 03801 > > +1.603.570.2636 > www.elbrys.com > dnelson@elbrys.com --Apple-Mail-1--160732267 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Resending from my = enrolled email address.

On = Mar 6, 2010, at 2:50 PM, Randy Presuhn wrote:

1.  Is there really any need to talk about the = tmStateReference
=      cache?

Not strictly = speaking.  It is necessary to bind the session in the Transport = Model to the dynamically created rows in the extVacmSecurityToGropTable = and the vacmSecurityToGroupTable.   Such a session identifier = is described in Section 7.2, et seq.  The mention of = tmStateReference was originally added to suggest one way of maintaining = that required binding.  Specifying the requirements of the binding, = without suggesting a specific implementation is = sufficient.

2.  Is there a need = for the RFC 5590 reference to be normative? =  Is
=     it needed at all?

It = probably doesn't need to be normative.  On the other hand, the = methods described in this document are *only* applicable when a Secure = Transport Model is also in use, so it would seem reasonable to keep it = as an informative reference.

Regards,

Dave

David B. = Nelson

Elbrys Networks, Inc.
282 Corporate Drive, Unit = 1
Portsmouth, NH 03801

+1.603.570.2636
www.elbrys.com
dnelson@elbrys.com






= --Apple-Mail-1--160732267-- From dnelson@elbrysnetworks.com Mon Mar 8 06:00:07 2010 Return-Path: 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 802123A69C4 for ; Mon, 8 Mar 2010 06:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 M8ZdRPo1NwUO for ; Mon, 8 Mar 2010 06:00:05 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 0A6373A69B3 for ; Mon, 8 Mar 2010 06:00:03 -0800 (PST) Received: (qmail 22775 invoked from network); 8 Mar 2010 14:00:02 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 14:00:02 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--160689664 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Mon, 8 Mar 2010 09:00:02 -0500 References: <002501cabd67$86cacfc0$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] RADIUS/VACM - normative reference to RFC 5591? 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: , X-List-Received-Date: Mon, 08 Mar 2010 14:00:07 -0000 --Apple-Mail-2--160689664 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Resending from my enrolled email address. > On Mar 6, 2010, at 2:59 PM, Randy Presuhn wrote: > >> 3. Does the reference to RFC 5591 need to be normative? >> >> One of the surprising things about the evolution of the >> RADIUS/VACM integration is that all the references to >> RFC 5591 come very close to being "for examples", rather >> than clear normative references. This is a consequence >> of our decision to describe this integration in a way >> that would permit its use with other transports / security >> models. > > I'm a little less optimistic about our ability to "future-proof" > this document, in the traditional fashion of the strongly modular > SNMP architecture. It's quite possible that some other transport > and security models could be used with AAA-provisioned access. On > the other hand, given the poor modularity properties of the original > Security Subsystem architecture, which really only supports locally- > based models such as USM, I would prefer to avoid making overly > general statements, in the absence of time to think out the relevant > details and specific text to review. > >> Indeed, even the title has become somewhat misleading, >> since RADIUS is just one example of an AAA service that >> could be supported. > > Um... Well, I'm only aware of RADIUS, Diameter and TACACS as > potential AAA candidates. Diameter inherits RADIUS attributes via > its NAS Application, so that leaves only TACACS unconsidered. For > the reasons articulated above, I would hesitate to make overly > general assertions that might come back to haunt us, when someone > actually tries to undertake a particular extension of this work. > > Regards, > > Dave > > David B. Nelson > > Elbrys Networks, Inc. > 282 Corporate Drive, Unit 1 > Portsmouth, NH 03801 > > +1.603.570.2636 > www.elbrys.com > dnelson@elbrys.com --Apple-Mail-2--160689664 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Resending from my = enrolled email address.

On = Mar 6, 2010, at 2:59 PM, Randy Presuhn wrote:

 3.  Does the reference to RFC 5591 need to be = normative?

One of the = surprising things about the evolution of the
RADIUS/VACM integration is that all the references = to
RFC 5591 come very close to = being "for examples", rather
than clear normative references.  This is a = consequence
of our decision to = describe this integration in a way
that would permit its use with other transports / = security
models.

I'm a little less optimistic = about our ability to "future-proof" this document, in the traditional = fashion of the strongly modular SNMP architecture.  It's quite = possible that some other transport and security models could be used = with AAA-provisioned access.  On the other hand, given the poor = modularity properties of the original Security Subsystem architecture, = which really only supports locally-based models such as USM, I would = prefer to avoid making overly general statements, in the absence of time = to think out the relevant details and specific text to = review.

Indeed, even the title has = become somewhat misleading,
since RADIUS is just one example of an AAA service = that
could be = supported.

Um...  Well, I'm only aware of = RADIUS, Diameter and TACACS as potential AAA candidates.  Diameter = inherits RADIUS attributes via its NAS Application, so that leaves only = TACACS unconsidered.  For the reasons articulated above, I would = hesitate to make overly general assertions that might come back to haunt = us, when someone actually tries to undertake a particular extension of = this work.

Regards,

Dave

David B. = Nelson

Elbrys Networks, Inc.
282 Corporate Drive, Unit = 1
Portsmouth, NH 03801

+1.603.570.2636
www.elbrys.com
dnelson@elbrys.com




= --Apple-Mail-2--160689664-- From dnelson@elbrysnetworks.com Mon Mar 8 06:02:16 2010 Return-Path: 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 0589B3A69C4 for ; Mon, 8 Mar 2010 06:02:16 -0800 (PST) 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=[AWL=0.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 8ffQFLvyBojc for ; Mon, 8 Mar 2010 06:02:13 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id D2EF03A69B6 for ; Mon, 8 Mar 2010 06:02:11 -0800 (PST) Received: (qmail 23027 invoked from network); 8 Mar 2010 14:02:15 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 14:02:15 -0000 Message-Id: <70653AA0-8388-450F-AD86-78F61879090C@elbrysnetworks.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20100308090828.GA1852@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 09:02:15 -0500 References: <20100308090828.GA1852@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document 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: , X-List-Received-Date: Mon, 08 Mar 2010 14:02:16 -0000 On Mar 8, 2010, at 4:08 AM, Juergen Schoenwaelder wrote: > This message starts a 14-day working group last call on the > following document: > > Extensions to the View-based Access Control Model for use with RADIUS > I will send my comments in separate email messages for each major issue. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From dnelson@elbrysnetworks.com Mon Mar 8 06:17:45 2010 Return-Path: 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 1040F3A6952 for ; Mon, 8 Mar 2010 06:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Xk0kDNGi39WU for ; Mon, 8 Mar 2010 06:17:43 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id EF11A3A6904 for ; Mon, 8 Mar 2010 06:17:41 -0800 (PST) Received: (qmail 23672 invoked from network); 8 Mar 2010 14:17:45 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 14:17:45 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20100308090828.GA1852@elstar.local> Content-Type: multipart/alternative; boundary=Apple-Mail-3--159626615 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 09:17:45 -0500 References: <20100308090828.GA1852@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 1 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: , X-List-Received-Date: Mon, 08 Mar 2010 14:17:45 -0000 --Apple-Mail-3--159626615 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In Section 4.3: Likewise, although this memo specifically refers to RADIUS, it MAY be used with other AAA services satisfying these requirements: o the service provides information semantically equivalent to the RADIUS Management-Policy-ID attribute [RFC5607], which has been mapped (perhaps trivially) into a GroupName; o the service provides information semantically equivalent to the RADIUS User-Name Attribute, which has been mapped (perhaps trivially) into a SecurityName. I'm moderately concerned about the language "which has been mapped (perhaps trivially)". Admittedly, I look at this work more from an AAA / Security perspective, than from an SNMP / Network Management perspective. My "principle of least surprise" is driven by the viewpoint of the RADIUS system administrator, rather than that of the SNMP system administrator. When they are in fact the same individual, it doesn't matter, of course. My concern is for the deployments where it's not the same individual. I don't think that many NAS (RADIUS client) implementations perform "mapping" on RADIUS authorization attributes, except to the extent necessary to translate them into action, in an implementation dependent internal data structure. For the Management-Policy-ID, there is always some sort for mapping going on, since this is simply a name for a locally-provisioned policy. In the case of the User-Name, this is the user's identity, and the only common form of "mapping" would be the addition or stripping of a "domain-part", as in the case of a Network Access Identifier. Perhaps this simply warrants some additional text in the Security Considerations section to describe what might happen if non-trivial mappings were to be applied to these values. If the managed entity views user identity different from the RADIUS system administrator, there is certainly the opportunity, at least, for a "surprise" and in some cases it might result in a misidentification that would pose a security risk. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com --Apple-Mail-3--159626615 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
In Section = 4.3:
 =
Likewise, although this memo specifically refers to RADIUS, it MAY be
 used with other AAA services satisfying these requirements:

   o  the service provides information semantically equivalent to the
      RADIUS Management-Policy-ID attribute [RFC5607], which has been
      mapped (perhaps trivially) into a GroupName;

   o  the service provides information semantically equivalent to the
      RADIUS User-Name Attribute, which has been mapped (perhaps
      trivially) into a SecurityName.


I'm moderately =
concerned about the language "which has been mapped (perhaps =
trivially)".
Admittedly, I look at this work more from an AAA / =
Security perspective, than from an SNMP / Network Management =
perspective.  My "principle of least surprise" is driven by the =
viewpoint of the RADIUS system administrator, rather than that of the =
SNMP system administrator.  When they are in fact the same individual, =
it doesn't matter, of course.  My concern is for the deployments where =
it's not the same individual.
I don't think that many NAS (RADIUS client) =
implementations perform "mapping" on RADIUS authorization attributes, =
except to the extent necessary to translate them into action, in an =
implementation dependent internal data structure.  For the =
Management-Policy-ID, there is always some sort for mapping going on, =
since this is simply a name for a locally-provisioned policy.  In the =
case of the User-Name, this is the user's identity, and the only common =
form of "mapping" would be the addition or stripping of a "domain-part", =
as in the case of a Network Access Identifier.  Perhaps this simply =
warrants some additional text in the Security Considerations section to =
describe what might happen if non-trivial mappings were to be applied to =
these values.  If the managed entity views user identity different from =
the RADIUS system administrator, there is certainly the opportunity, at =
least, for a "surprise" and in some cases it might result in a =
misidentification that would pose a security =
risk.
Regards,

Dave

Dav= id B. Nelson

Elbrys Networks, = Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH = 03801

+1.603.570.2636
dnelson@elbrysnetworks.com<= /div>





= --Apple-Mail-3--159626615-- From dnelson@elbrysnetworks.com Mon Mar 8 06:47:25 2010 Return-Path: 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 B5D453A69C0 for ; Mon, 8 Mar 2010 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zKdBQsLeYovq for ; Mon, 8 Mar 2010 06:47:24 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 0B42D3A69B3 for ; Mon, 8 Mar 2010 06:47:21 -0800 (PST) Received: (qmail 24983 invoked from network); 8 Mar 2010 14:47:17 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 14:47:17 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20100308090828.GA1852@elstar.local> Content-Type: multipart/alternative; boundary=Apple-Mail-4--157854489 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 09:47:17 -0500 References: <20100308090828.GA1852@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 14:47:25 -0000 --Apple-Mail-4--157854489 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Section 7.2.2: If a corresponding entry already exists in the vacmSecurityToGroupTable, and the row's StorageType is anything other than "volatile", or the RowStatus is anything other than "active", then a role (group) mapping for this user (principal) has already been put in place on this system, and will not be overridden. I've said this before, but I'll say it again, hopefully in clearer terms. I think that the notion of the *same* principal identity that comes from RADIUS (or other AAA) having already been "put in place on this system" is highly dubious. At best, it relies on special circumstances. Here's my reasoning on this: (a) There is nothing in the documented protocol or elements of procedures that guarantees that the content of an SNMP securityName bears any relationship to the content of a RADIUS User-Name *unless* the former is dynamically obtained from the later, in the context of a single secure transport session. (b) In the absence of careful coordination on the part of the RADIUS system administrator and the SNMP system administrator, i.e. "special circumstances" there is no guarantee that independently, manually- configured but identical user names actually refer to the same user. For example, it is possible that the RADIUS system administrator is using the name "dave" for Dave Nelson and the SNMP system administrator is using the name "dave" for Dave Harrington. I understand that the likelihood of such name collisions is reduced if fuller versions of the names are used, but 'll observe that at one point in time there were *five* Dave Nelson's working for Digital Equipment Corporation, of which I was just one. So name collisions, and the resulting mis-identity, are not such a narrow corner case. (c) The use case in which RADIUS is involved in SNMP access authorization is likely similar to the use case in which NIS us used for UNIX workstation login. In other words, either you choose to centralize your authentication and authorization or you don't. While there is alway the need for a [small] number of locally maintained access credentials for "emergency" login usages, it seems odd to me that a real-world deployment would be using RADIUS for "outsourced" identity management and at the same time there would be a manually configured set of user identities in the VACM MIB tables that requires constant synchronization with the user configured in RADIUS. For these reasons, I think that the particular scenario in which an existing, manually-configured, non-volatile, vacmSecurityToGroup table row is expected to correctly match the securityName dynamically derived from RADIUS relies on "special circumstances", i.e. careful manual coordination of potentially disjoint name spaces. I think this opens up the *potential* for a significant security risk. In short, I would not automatically assume that the SNMP security manage knew what he/she was doing. :-) Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com --Apple-Mail-4--157854489 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Section = 7.2.2:
  =
 If a corresponding entry already exists in the
   vacmSecurityToGroupTable, and the row's StorageType is anything other
   than "volatile", or the RowStatus is anything other than "active",
   then a role (group) mapping for this user (principal) has already
   been put in place on this system, and will not be =
overridden.
I've said this before, but I'll say it again, hopefully in =
clearer terms.  I think that the notion of the *same* principal identity =
that comes from RADIUS (or other AAA) having already been "put in place =
on this system" is highly dubious.  At best, it relies on special =
circumstances.  Here's my reasoning on this:
(a) There is nothing in =
the documented protocol or elements of procedures that guarantees that =
the content of an SNMP securityName bears any relationship to the =
content of a RADIUS User-Name *unless* the former is dynamically =
obtained from the later, in the context of a single secure transport =
session.
(b)  In =
the absence of careful coordination on the part of the RADIUS system =
administrator and the SNMP system administrator, i.e. "special =
circumstances" there is no guarantee that independently, =
manually-configured but identical user names actually refer to the same =
user.  For example, it is possible that the RADIUS system administrator =
is using the name "dave" for Dave Nelson and the SNMP system =
administrator is using the name "dave" for Dave Harrington.  I =
understand that the likelihood of such name collisions is reduced if =
fuller versions of the names are used, but 'll observe that at one point =
in time there were *five* Dave Nelson's working for Digital Equipment =
Corporation, of which I was just one.  So name collisions, and the =
resulting mis-identity, are not such a narrow corner =
case.
(c) The =
use case in which RADIUS is involved in SNMP access authorization is =
likely similar to the use case in which NIS us used for UNIX workstation =
login.   In other words, either you choose to centralize your =
authentication and authorization or you don't.  While there is alway the =
need for a [small] number of locally maintained access credentials for =
"emergency" login usages, it seems odd to me that a real-world =
deployment would be using RADIUS for "outsourced" identity management =
and at the same time there would be a manually configured set of user =
identities in the VACM MIB tables that requires constant synchronization =
with the user configured in RADIUS.
For these reasons, I think =
that the particular scenario in which an existing, manually-configured, =
non-volatile, vacmSecurityToGroup table row is expected to correctly =
match the securityName dynamically derived from RADIUS relies on =
"special circumstances", i.e. careful manual coordination of potentially =
disjoint name spaces.  I think this opens up the *potential* for a =
significant security risk.  In short, I would not automatically assume =
that the SNMP security manage knew what he/she was doing.  =
:-)
Regards,

Dave

Dav= id B. Nelson

Elbrys Networks, = Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH = 03801

+1.603.570.2636
dnelson@elbrysnetworks.com<= /div>





= --Apple-Mail-4--157854489-- From dnelson@elbrysnetworks.com Mon Mar 8 07:03:37 2010 Return-Path: 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 261803A69BA for ; Mon, 8 Mar 2010 07:03:37 -0800 (PST) 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=[AWL=0.000, 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 lZFX2cUBGyR2 for ; Mon, 8 Mar 2010 07:03:35 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 9A0573A69A1 for ; Mon, 8 Mar 2010 07:03:35 -0800 (PST) Received: (qmail 25725 invoked from network); 8 Mar 2010 15:03:38 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 15:03:38 -0000 Message-Id: <510570E4-0246-4C86-8705-FDC2A0E7AF45@elbrysnetworks.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20100308090828.GA1852@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 10:03:38 -0500 References: <20100308090828.GA1852@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 3 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: , X-List-Received-Date: Mon, 08 Mar 2010 15:03:37 -0000 I previously opined that removing the error counters from the MB module in this document was a mistake. Randy observed that notifications would often be more helpful in resolving the errors than would simple counters. I agree. Randy also observed that implementors could use implementation dependent means, including appropriate syslog messages. Yes, they could. My concern is that if we don't include either counters or notification objects in the MIB module, that implementers will be tempted to skip over including any form of error indications. We could beef up the security considerations text, to make that alternative less attractive. Either way, I think *something* needs to be done about these potential error conditions. While the counters are simplistic, much as that "check engine" idiot light on my dashboard, they at least indicate the need for investigation. They also have the advantage of being simple to implement. Not all of the originally proposed counters fall into this category, but some of them do. I'm thinking of the ones that signal a *possible* disconnect or lack of coordination between the RADIUS system administrator and SNMP security administrator. Leaving it up the the initiative of conscientious implementers to handle these potential security mis-configurations in an ad-hoc fashion is not a good idea. We should aim higher, I think. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From wwwrun@core3.amsl.com Mon Mar 8 07:16:55 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D299B3A69F4; Mon, 8 Mar 2010 07:16:55 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100308151655.D299B3A69F4@core3.amsl.com> Date: Mon, 8 Mar 2010 07:16:55 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:16:55 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Transport Layer Security (TLS) Transport Model for SNMP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19028&rfc_flag=0 From dnelson@elbrysnetworks.com Mon Mar 8 07:29:51 2010 Return-Path: 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 0D5F73A69B5 for ; Mon, 8 Mar 2010 07:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 iK9svMBZFVFo for ; Mon, 8 Mar 2010 07:29:49 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 745063A6904 for ; Mon, 8 Mar 2010 07:29:47 -0800 (PST) Received: (qmail 26805 invoked from network); 8 Mar 2010 15:29:51 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 15:29:51 -0000 Message-Id: <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20100308090828.GA1852@elstar.local> Content-Type: multipart/alternative; boundary=Apple-Mail-5--155301383 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 10:29:50 -0500 References: <20100308090828.GA1852@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Mon, 08 Mar 2010 15:29:51 -0000 --Apple-Mail-5--155301383 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Editorial corrections: Section 1: s/from RADIUS or other AAA/from RADIUS or another AAA/ Old text: o The Secure Shell Transport Model for SNMP [RFC5592] defines a Secure Shell Transport Model and Remote Authentication Dial-In User Service (RADIUS). New text: o The Secure Shell Transport Model for SNMP [RFC5592] defines a Secure Shell Transport Model. Old text: This memo defines an extension to the View-based Access Control Model to obtain authorization information for an authenticated principal, from RADIUS or equivalent AAA service supporting a Transport Security Model. New text: This memo defines an extension to the View-based Access Control Model to obtain authorization information for an authenticated principal, from RADIUS or an equivalent AAA service when used with a Transport Security Model. Section 4.3: Old text: o the model provides an indication of the establishment session for a particular user, identified using a SecurityName, and provides the corresponding value of vacmGroupName to be used, based on information provided by the AAA service in use; New text: o the model provides an indication of the establishment of a session for a particular user, identified using a SecurityName, and provides the corresponding value of vacmGroupName to be used, based on information provided by the AAA service in use; Section 9: This integration strongly assumes that RADIUS (or some other AAA service) is at least as trusted as the security administrator with access rights to the vacmSecurityToGroupTable. It assumes that the transport security model can be trusted to pass through the users' security name and the group name provided by the AAA service. It also trusts the transport security model to enforce any session timeouts imposed by the RADIUS server, and to provide an indicate whenever a session ends. s/an indicate/an indication/ The algorithms in this memo make heuristic use of the StorageType of entries in the vacmSecurityToGroupTable to distinguish those which have been provisioned by a security administrator (which would presumably not be configured as "volatile") and those dynamically generated. In making this distinction, it assumes that those entries explicitly provisioned by a security administrator and given a non-"volatile" status are not to be dynamically over-ridden. I don't think it's reasonable, or generally safe, to automatically assume that the SNMP security administrator is "clueful" and the RADIUS system administrator is "clueless". That would seem to be the implication of always favoring the statically configured information over the dynamically derived information. IMHO, the only thing that can be safely inferred from this type of conflict is that the two individuals are not coordinating with each other. That raises a "red flag" and SHOULD result in an investigation of the root cause of the apparent conflict. Users of this memo need to be aware of this operational assumption, which, while reasonable, is not necessarily universal. Um... yeah. I think this is insufficiently sternly worded advice. The design of VACM ensures that if an unknown policy (group name) is used in the VacmSecurityToGroupTable, no access is granted. A consequence of this is that even in the presence of a malfunctioning or compromised AAA server, no user can gain access rights not already granted to some group. It is reasonable to "fail safe" by not granting access in that case of an apparent misconfiguration or lack of policy coordination among system and security administrators. On the other hand, why is it more likely that the AAA server is malfunctioning or compromised? This language seems to give greater weight (credence) to the actions and configurations of the SNMP security administrator in setting up the VACM MIB modules. It seems to me that either source of information is equally subject to malfunction, misconfiguration or compromise. Of course, if the security and access control mechanisms of the managed entity have indeed been compromised, all bets are off, no matter what RADIUS may have to say in the mater. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com --Apple-Mail-5--155301383 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Editorial = corrections:

Section = 1:

s/from RADIUS or other AAA/from RADIUS or = another AAA/

Old = text:

 o    The Secure Shell Transport Model for SNMP =
[RFC5592] defines a
      Secure Shell Transport Model and Remote Authentication Dial-In
      User Service (RADIUS).

New = text:

 o    The Secure Shell Transport Model for SNMP =
[RFC5592] defines a
      Secure Shell Transport =
Model.


Old = text:

   This memo defines an extension to the =
View-based Access Control 
   Model to obtain authorization =
information for an authenticated
   principal, from RADIUS or =
equivalent AAA service supporting a
   Transport Security =
Model.

New = text:

   This memo =
defines an extension to the View-based Access Control 
   Model to =
obtain authorization information for an authenticated
   principal, =
from RADIUS or an equivalent AAA service when used
   with a =
Transport Security Model.

Section 4.3:
Old text:
o     the model provides an indication of the =
establishment session for
      a particular user, identified using a SecurityName, and provides
      the corresponding value of vacmGroupName to be used, based on
      information provided by the AAA service in =
use;
New text:

o     the model provides an indication of the =
establishment of a session for
      a particular user, identified using a SecurityName, and provides
      the corresponding value of vacmGroupName to be used, based on
      information provided by the AAA service in =
use;

Section= 9:

   This integration strongly assumes that =
RADIUS (or some other AAA
   service) is at least as trusted as the security administrator with
   access rights to the vacmSecurityToGroupTable.  It assumes that the
   transport security model can be trusted to pass through the users'
   security name and the group name provided by the AAA service.  It
   also trusts the transport security model to enforce any session
   timeouts imposed by the RADIUS server, and to provide an indicate
   whenever a session ends.
s/an indicate/an =
indication/
   The algorithms in this memo make heuristic =
use of the StorageType of
   entries in the vacmSecurityToGroupTable to distinguish those which
   have been provisioned by a security administrator (which would
   presumably not be configured as "volatile") and those dynamically
   generated.  In making this distinction, it assumes that those entries
   explicitly provisioned by a security administrator and given a
   non-"volatile" status are not to be dynamically =
over-ridden.
I don't =
think it's reasonable, or generally safe, to automatically  assume that =
the SNMP security administrator is "clueful" and the RADIUS system =
administrator is "clueless".  That would seem to be the implication of =
always favoring the statically configured information over the =
dynamically derived information.  IMHO, the only thing that can be =
safely inferred from this type of conflict is that the two individuals =
are not coordinating with each other.  That raises a "red flag" and =
SHOULD result in an investigation of the root cause of the apparent =
conflict.
   Users
   of this memo need to be aware of this operational assumption, which,
   while reasonable, is not necessarily universal.
Um...  yeah.  I =
think this is insufficiently sternly worded =
advice.
   The design of VACM ensures that if an =
unknown policy (group name) is
   used in the VacmSecurityToGroupTable, no access is granted.  A
   consequence of this is that even in the presence of a malfunctioning
   or compromised AAA server, no user can gain access rights not already
   granted to some group.
It is reasonable to = "fail safe" by not granting access in that case of an apparent = misconfiguration or lack of policy coordination among system and = security administrators.   On the other hand, why is it more likely = that the AAA server is malfunctioning or compromised?  This = language seems to give greater weight (credence) to the actions and = configurations of the SNMP security administrator in setting up the VACM = MIB modules.  It seems to me that either source of information is = equally subject to malfunction, misconfiguration or compromise.   = Of course, if the security and access control mechanisms of the managed = entity have indeed been compromised, all bets are off, no matter what = RADIUS may have to say in the mater.

Regards,

Dave

Dav= id B. Nelson

Elbrys Networks, = Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH = 03801

+1.603.570.2636
dnelson@elbrysnetworks.com<= /div>





= --Apple-Mail-5--155301383-- From cfinss@dial.pipex.com Mon Mar 8 08:01:05 2010 Return-Path: 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 938BD3A69DA for ; Mon, 8 Mar 2010 08:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_05=-1.11, J_CHICKENPOX_35=0.6] 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 7Vff9QlJT6TD for ; Mon, 8 Mar 2010 08:01:04 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id DD3153A69E9 for ; Mon, 8 Mar 2010 08:01:03 -0800 (PST) X-Trace: 189038496/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.142/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.142 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGAJOtlEs+vGmO/2dsb2JhbACBehkYhSmIcotVrQ0JjH4CC4JPDYIPBA X-IronPort-AV: E=Sophos;i="4.49,602,1262563200"; d="scan'208";a="189038496" X-IP-Direction: IN Received: from 1cust142.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.142]) by smtp.pipex.tiscali.co.uk with SMTP; 08 Mar 2010 16:01:06 +0000 Message-ID: <000c01cabed0$014ed8e0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> Date: Mon, 8 Mar 2010 15:35:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:01:05 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: ; "isms" Sent: Friday, March 05, 2010 9:24 AM > On Thu, Mar 04, 2010 at 03:49:49PM +0100, tom.petch wrote: > > Pasi > > > > Two thoughts on your proposal to discourage renegotiation. > > > > SNMP may have long running sessions - I know, there is no concept of session in > > SNMP but allow me a little licence - so that it may trip over limitations on the > > usage of the security credentials in a way that other applications do not. > > > > A certificate could expire and so need to be replaced with a current one, which > > is one use of renegotiation. And so much data could flow, or time pass, that > > the keys need refreshing, which again renegotiation allows. > > > > Do you intend that these be NOT RECOMMENDED ie if and when such are needed, tear > > down the TLSTM session and start again? > > > > Second, you change all the TLS session to TLS connection, which is a substantial > > change. I had assumed that the author had intended session resumption to be > > permitted which your new text would discourage. Again, is this your intention? > > Speaking as technical contributor: I don't think it is the idea is to > make session resumption impossible or to disable rekeying. In fact, I > consider session resumption essential. Juergen I am unclear. Are youre requirements met by the new wording, of "That is, implementations MUST either disable renegotiation completely (RECOMMENDED), or MUST present the same certificate during renegotiation (and MUST verify that the other end presented the same certificate). " which I have previously paraphrased as 'NOT RECOMMENDED'? Tom Petch > There are many management tools > out there that do not maintain long sessions (in particular large > collections of scripts) and such scripts will be hit really badly if > every call to way snmpwalk kicked off via cron causes an expensive > session key calculation. > > The lack of a session resumption mechanism in SSH makes in my view the > SSHTM much less attractive compared to the TLSTM and led us to invent > a session resumption mechanism for SSH [1]. > > /js > > [1] > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From cfinss@dial.pipex.com Mon Mar 8 08:01:19 2010 Return-Path: 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 471813A6A2B for ; Mon, 8 Mar 2010 08:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 Su-GjJWT0uqF for ; Mon, 8 Mar 2010 08:01:18 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 00A583A69B4 for ; Mon, 8 Mar 2010 08:01:17 -0800 (PST) X-Trace: 189038514/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.142/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.142 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGAL6ulEs+vGmO/2dsb2JhbACBehkYhSmIcotVugkNhGsE X-IronPort-AV: E=Sophos;i="4.49,602,1262563200"; d="scan'208";a="189038514" X-IP-Direction: IN Received: from 1cust142.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.142]) by smtp.pipex.tiscali.co.uk with SMTP; 08 Mar 2010 16:01:07 +0000 Message-ID: <000d01cabed0$024a9e00$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com><000701cabbae$47c86720$0601a8c0@allison><808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com><000e01cabc98$bb9c1620$0601a8c0@allison> Date: Mon, 8 Mar 2010 15:41:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:01:19 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Saturday, March 06, 2010 3:32 AM > >>>>> On Fri, 5 Mar 2010 20:07:13 +0100, "tom.petch" said: > > tp> Yes and no; we are now binding the TLSTM session to the (D)TLS > tp> connection so starting a new TLS connection will force a new TLSTM > tp> session with a break in connectivity (SNMP is not HTTP:-). Worst > tp> case scenario would be for this to happen between Get and Response > tp> causing the Response to be discarded, making TLS/TCP an unreliable > tp> transport (compared to UDP:-) Which is ok with me. > > Anything we do could result in something going down between the point > where the command responder starts processing a request and the point it > wants to send the reply back out. Pasi's text changes haven't affected > this at all. > > But renegotiation with a new session would require a potential change in > a securityName which is a bigger issue. I don't think we have any > scenarios that really require renegotiation so I don't see the harm in > dropping support for it, but I do see benefits. > > tp> If TLS reuses the connection state with a new transport 5-tuple, then > tp> I expect that that will upset TLSTM. > > TLSTM will operate just fine. There may be a new tlstmSessionId even > though a previously existing session within TLS was reused. But again, > the only time I see that being a problem is in the middle of command or > notification responder processing (or proxy). But again, the connection > has already gone down in this case so the responder is already stuck. > Session resumption merely buys us the ability to spin up faster the next > time around. Pasi's rewording of session -> connection doesn't change > any of this. > > tp> If TLS reuses connection state with an old 5-tuple (a rare event > tp> with TCP), then again, I expect that that will upset TLSTM. > > With proper processing then TLSTM should have dropped it's knowledge on > a TCP close. On a dead DTLS case, DTLS will be just as confused as > TLSTM would be and again, nothing new is introduced. > > tp> So I think there cannot be session resumption. Again, not a problem > tp> for me. > > I think you're wrong about that. But we don't spell out the details of > when and how you'd do that within our draft (and we didn't before > either). Implementations could very easily implement session resumption > by matching remote targets with sessions that could be reused. Can you > find text in our document that would prohibit that from working? Note > that session resumption would need to happen in the same way that > algorithm selection needs to happen: via configuration beyond the scope > of this document, as is already stated. Wes You may recall that during the production of the first three RFC, there were a number of occasions when I found that what we had specified would lead to commands never getting responses. I found that by spending considerable time going through the EoPs to confirm my suspicions (and then even longer convincing the editors that what we had really would not work:-(. I suspect that the something comparable will emerge here, although not as serious, but it will take me a while to confirm or deny this, so I will go away and do the work and come back to you when I have the answer; but it will take some time, perhaps weeks not days. Tom Petch > -- > Wes Hardaker > Cobham Analytic Solutions From wjhns1@hardakers.net Mon Mar 8 09:23:22 2010 Return-Path: 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 37E1A3A6AC9 for ; Mon, 8 Mar 2010 09:23:18 -0800 (PST) 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 ShwHixobJ+uy for ; Mon, 8 Mar 2010 09:23:06 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A795A3A6AE4 for ; Mon, 8 Mar 2010 09:23:01 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 254D4A054F; Mon, 8 Mar 2010 09:23:03 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB7758482A52BB@NOK-EUMSG-01.mgdnok.nokia.com> <000e01cabc98$bb9c1620$0601a8c0@allison> <000d01cabed0$024a9e00$0601a8c0@allison> Date: Mon, 08 Mar 2010 09:23:02 -0800 In-Reply-To: <000d01cabed0$024a9e00$0601a8c0@allison> (tom petch's message of "Mon, 8 Mar 2010 15:41:18 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Mon, 08 Mar 2010 17:23:22 -0000 >>>>> On Mon, 8 Mar 2010 15:41:18 +0100, "tom.petch" said: tp> You may recall that during the production of the first three RFC, tp> there were a number of occasions when I found that what we had tp> specified would lead to commands never getting responses. I found tp> that by spending considerable time going through the EoPs to confirm tp> my suspicions (and then even longer convincing the editors that what tp> we had really would not work:-(. I think it is highly likely that as we develop more and more connection oriented approaches to things (or at least finish the ones we've started) that one of the downsides of a connection oriented approach (even when sent over a connectionless base transport layer) is that if the connection goes down the responder will get confused and not be able to cope. There are really only two scenarios: A) connection lost in the middle 1. CG opens a connection 2. CG sends a request 3. CR receives the request and starts to process it 4. Connection drops (the reason doesn't really matter) 5. CR wants to send the response and either: a. The most likely: it simply can't and drops it b. Somehow manages to open a reverse connection, which has long been discussed and never solved in the IETF c. Queues it and Waits for the manager to open a connection I'd argue that although we'd like b., no one today is doing it nor will they soon. c. is even less likely to ever happen and many would argue shouldn't happen. Thus, a. is the only real world choice at the moment. B) connection lost in the middle and re-established very very quickly 1. CG opens a connection 2. CG sends a request 3. CR receives the request and starts to process it 4. Connection drops (the reason doesn't really matter) 5. Connection is re-opened by the manager with as a new "connection" which may or may not be a re-established old session. 6. CR wants to send the response and either: a. Can figure out that the existing request can be sent over the new connection b. Can't and drops it. I believe that the current real world code and the way state is handled internally makes a. nearly impossible without a lot of work. Now, if this was a common case (IE connections come and go frequently) then maybe it'd be worth solving, but in the end I think the likelyhood of this being a real world problem worth solving is very very low. If a connection is going up and down so frequently that you're dropping huge numbers of request/response pairs due to the flapping then you have some pretty serious issues. Certainly you shouldn't be using a transport that is flapping so much (and many would argue that's one of the prime reasons for using a UDP based transport, be it raw UDP/USM or the now possible UDP/DTLS). And this doesn't even get into manager code, where modern code is also likely tied to state that will not accept responses from a different source stream. Don't get me wrong: I agree that it's likely that if a connection drops and gets restarted the likelyhood of an agent being able to successfully transmit the response back to the manager is very very slim. But I remain unconvinced that even if we solved this in the SNMPv3 architecture and transport models that the real world code could easily implement it or would find it worthwhile to do so. But, fortunately, SNMP was designed at the application layer to expect transport issues a lot of the time which is why they all have "timeouts" and "retries" and even make use of those parameters when a TCP-based session is in place. I do think that most manager code today is smart enough to open a new connection if it needs to retry and finds its previous connection closed. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Mon Mar 8 10:41:28 2010 Return-Path: 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 4EB933A6A6C for ; Mon, 8 Mar 2010 10:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 79EyDNJGHGma for ; Mon, 8 Mar 2010 10:41:27 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 329E03A6A28 for ; Mon, 8 Mar 2010 10:41:27 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o28IfNXt014685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 13:41:23 -0500 (EST) Date: Mon, 08 Mar 2010 13:41:23 -0500 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: In-Reply-To: <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 18:41:28 -0000 --On Monday, March 08, 2010 09:47:17 AM -0500 "David B. Nelson" wrote: > I've said this before, but I'll say it again, hopefully in clearer terms. > I think that the notion of the *same* principal identity that comes from > RADIUS (or other AAA) having already been "put in place on this system" > is highly dubious. I disagree. You make the argument that if RADIUS and some SNMP device are not administered by the same person, they are completely coordinated and further the SNMP device administrator is a boob who has no clue what he is doing. Certainly this is possible, and even somewhat common, but it is by no means the only case. In a large enterprise (or a sub-unit of such an enterprise), it is usually the case that every person has a well-known username assigned by a central authority. Unlike "Dave Nelson" at the time you worked for DEC, these usernames are unique, always refer to the same person, and can be looked up in a common directory. They are generally mapped in a straightforward way to names used by various authentication services, including RADIUS. At Carnegie Mellon, I have the same username in at least three different organizational units between which username assignment is pretty much the _only_ thing we coordinate. It is thus not terribly unlikely that an administrator of a device might create locally-managed accounts for one or more users, using the same centrally-assigned username. If an administrator does such a thing, chances are he intended for his entry to override whatever might come from RADIUS, and not the other way around. > (a) There is nothing in the documented protocol or elements of procedures > that guarantees that the content of an SNMP securityName bears any > relationship to the content of a RADIUS User-Name *unless* the former is > dynamically obtained from the later, in the context of a single secure > transport session. True, but in practice they will both be derived from the common username directory. > (b) In the absence of careful coordination on the part of the RADIUS > system administrator and the SNMP system administrator, i.e. "special > circumstances" there is no guarantee that independently, > manually-configured but identical user names actually refer to the same > user. True, but they often do; see above. > (c) The use case in which RADIUS is involved in SNMP access authorization > is likely similar to the use case in which NIS us used for UNIX > workstation login. In other words, either you choose to centralize your > authentication and authorization or you don't. False. A far more common case is to choose to centralize _most_ authentication, but have a few locally-maintained accounts on each host/device/whatever. > it seems odd to me that a real-world deployment > would be using RADIUS for "outsourced" identity management and at the > same time there would be a manually configured set of user identities in > the VACM MIB tables that requires constant synchronization with the user > configured in RADIUS. Well, that's true. The manually-configured thing is manually configured. Its data didn't come from RADIUS, and it doesn't require "synchronization" with RADIUS. Your statement seems predicated on the idea that RADIUS is the authoritative source of all information, which I suspect is almost never the case. It's far more common for the RADIUS server to get its data from some other source, which is also accessed in other ways. > I think this opens up > the *potential* for a significant security risk. In short, I would not > automatically assume that the SNMP security manage knew what he/she was > doing. :-) No, you probably wouldn't, since you seem to apply the RADIUS worldview in which the RADIUS server is authoritative for what everyone else _MUST_ do, rather than the provider of information that it actually is. An SNMP implementation must assume that the SNMP security manager knew what he was doing. To do otherwise is to usurp that person's role as the definer of policy, and instead place the implementor in that role. -- Jeff From dnelson@elbrysnetworks.com Mon Mar 8 11:10:14 2010 Return-Path: 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 EBB633A6A83 for ; Mon, 8 Mar 2010 11:10:14 -0800 (PST) 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=[AWL=0.000, 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 D6HKPRqg-PZ7 for ; Mon, 8 Mar 2010 11:10:13 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 76E673A69B1 for ; Mon, 8 Mar 2010 11:10:13 -0800 (PST) Received: (qmail 5620 invoked from network); 8 Mar 2010 19:10:09 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 19:10:09 -0000 Message-Id: From: "David B. Nelson" To: Jeffrey Hutzelman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 14:10:09 -0500 References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 19:10:15 -0000 > At Carnegie Mellon, I have the same username in at least three > different organizational units between which username assignment is > pretty much the _only_ thing we coordinate. Is the authentication, i.e. the credentials you present, also coordinated, or only the name? I fully agree that such a system *can* work, given that the requisite manually coordination occurs. My complaint is that nowhere in this document does it make such manual coordination a prerequisite for secure operation. You may claim that's simply common sense. i'd like to see it written down if we are to rely upon it. > It is thus not terribly unlikely that an administrator of a device > might create locally-managed accounts for one or more users, using > the same centrally-assigned username. If an administrator does such > a thing, chances are he intended for his entry to override whatever > might come from RADIUS, and not the other way around. OK, but such arrangement seem to me to be a mistake waiting to happen. YMMV. >> (a) There is nothing in the documented protocol or elements of >> procedures >> that guarantees that the content of an SNMP securityName bears any >> relationship to the content of a RADIUS User-Name *unless* the >> former is >> dynamically obtained from the later, in the context of a single >> secure >> transport session. > > True, but in practice they will both be derived from the common > username directory. I'm always nervous when the identity is authenticated in one name space / administrative domain and then authorized (without further authentication) in *another* name space / administrative domain. As you have suggested, thus can be safe if care is taken to keep the use of names synchronized across all these services. I claim that requires "special considerations", and even if it's a fairly common use case, we ned to document the "special considerations" >> (c) The use case in which RADIUS is involved in SNMP access >> authorization >> is likely similar to the use case in which NIS us used for UNIX >> workstation login. In other words, either you choose to >> centralize your >> authentication and authorization or you don't. > > False. A far more common case is to choose to centralize _most_ > authentication, but have a few locally-maintained accounts on each > host/device/whatever. But even in those cases, the locally maintained accounts are both authenticated and authorized using local data, right? >> it seems odd to me that a real-world deployment >> would be using RADIUS for "outsourced" identity management and at the >> same time there would be a manually configured set of user >> identities in >> the VACM MIB tables that requires constant synchronization with the >> user >> configured in RADIUS. > > Well, that's true. The manually-configured thing is manually > configured. Its data didn't come from RADIUS, and it doesn't require > "synchronization" with RADIUS. My concern is the separation of authentication and authorization. We've had this discussion before, BTW. I haven't changed my opinion. > It's far more common for the RADIUS server to get its data from some > other source, which is also accessed in other ways. RADIUS may indeed consult other sources for both authentication and authorization, but once it binds those two items into an Access-Accept they need to remain bound. The RADIUS server is free make such trust model choices, the RADIUS client typically is not. (Well, of course, any implementation is possible. I'm talking about what's common.) >> I think this opens up >> the *potential* for a significant security risk. In short, I would >> not >> automatically assume that the SNMP security manage knew what he/she >> was >> doing. :-) > > No, you probably wouldn't, since you seem to apply the RADIUS > worldview in which the RADIUS server is authoritative for what > everyone else _MUST_ do, rather than the provider of information > that it actually is. Well, that is the standard RADIUS world-view. I understand that this is a "collision" of different system-level assumptions and trust models. > An SNMP implementation must assume that the SNMP security manager > knew what he was doing. To do otherwise is to usurp that person's > role as the definer of policy, and instead place the implementor in > that role. I disagree. Once the authentication and authorization policy decisions are "outsourced" to RADIUS, then SNMP is no longer authoritative. Right? How can two separate entities both be [equally] authoritative? Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From ietfdbh@comcast.net Mon Mar 8 11:45:30 2010 Return-Path: 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 D03843A6B97 for ; Mon, 8 Mar 2010 11:45:30 -0800 (PST) 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 myIkpZ+5Y1rJ for ; Mon, 8 Mar 2010 11:45:29 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id D43303A6B91 for ; Mon, 8 Mar 2010 11:45:29 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta12.emeryville.ca.mail.comcast.net with comcast id qdZe1d0070S2fkCACjlbAc; Mon, 08 Mar 2010 19:45:35 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta09.emeryville.ca.mail.comcast.net with comcast id qjlY1d00r4G8Frs8VjlZNs; Mon, 08 Mar 2010 19:45:34 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 8 Mar 2010 14:45:31 -0500 Message-ID: <087101cabef7$ea79c990$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq2HcZ0tkcwx5yLTDSj8MmBzFfQvwI1ZNuA Subject: Re: [Isms] AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Mon, 08 Mar 2010 19:45:30 -0000 Hi, > > - Currently, the document specifies how the TLS client authenticates/ > authorizes the TLS server only when SNMP-TARGET-MIB is used. But > clearly authenticating the TLS server is also important for > e.g. command generators. These may not have a MIB, but shouldn't we at > least recommend an implementation-specific management/configuration > interface that supports configuring the same details as > tlstmAddrTable? Note that even notification originators aren't required to have a MIB. >From RFC3413: Notification originator applications require a mechanism for identifying the management targets to which notifications should be sent. The particular mechanism used is implementation dependent. However, if an implementation makes the configuration of management targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module described in this document. > - Section 3.1.3. "As an implementation hint: although the > tlstmSessionID may be the same as the (D)TLS internal SessionID > caution must be exercised since the (D)TLS internal SessionID may > change over the life of the connection as seen by the TLSTM (for > example during renegotiation). The tlstmSessionID identifier MUST NOT > change during the entire duration of the session from the TLSTM's > perspective even if the TLS internal session identifier does change." > > This is not correct; it's possible to have several (D)TLS connections > (over different TCP connections, or different UDP five-tuples) that > have the same (D)TLS internal Session ID, so it does not uniquely > identify a TLSTM session. I would suggest just deleting this > paragraph. I think the paragraph should be reworded to ensure that tlstmSessionID uniquely identifies a TLSTM session. (or in the more generic case, a TM session). > - Section 4.4.1.1, "Transport Models SHOULD generate a predictable > tmSecurityName so operators will know what to use when configuring MIB > modules that use securityNames derived from tmSecurityNames." > Setting requirements for all transport models (not just DTLSTM) > doesn't seem to belong to this document... Didn't we leave determining the tmSecurityName to implementers? If so, then the paragraph should read "Transport Model implementations SHOULD generate a predictable tmSecurityName so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames." and for that matter, shouldn't this be a MUST? If operators cannot predict the format of the tmSecurityname generated by the implementation, they cannot configure the MIB. dbh From jhutz@cmu.edu Mon Mar 8 11:53:21 2010 Return-Path: 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 291A63A6B8A for ; Mon, 8 Mar 2010 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4YLn2fpkpi0U for ; Mon, 8 Mar 2010 11:53:19 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 8F0573A6BA1 for ; Mon, 8 Mar 2010 11:53:19 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o28JrBFW000166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 14:53:11 -0500 (EST) Date: Mon, 08 Mar 2010 14:53:11 -0500 From: Jeffrey Hutzelman To: "David B. Nelson" Message-ID: In-Reply-To: References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 19:53:21 -0000 --On Monday, March 08, 2010 02:10:09 PM -0500 "David B. Nelson" wrote: >> At Carnegie Mellon, I have the same username in at least three >> different organizational units between which username assignment is >> pretty much the _only_ thing we coordinate. > > Is the authentication, i.e. the credentials you present, also > coordinated, or only the name? Those OU's operate separate Kerberos realms and other infrastructure. They communicate, of course, such that credentials from one can be used to talk to another. But separately, the username space is coordinated -- no new user can be created in any of them with a name that is already in use in another, unless the accounts belong to the same person (in which case we rather strongly encourage the names to be the same). > I fully agree that such a system *can* work, given that the requisite > manually coordination occurs. My complaint is that nowhere in this > document does it make such manual coordination a prerequisite for secure > operation. You may claim that's simply common sense. i'd like to see it > written down if we are to rely upon it. I don't think we're relying on any such thing. What we say is, if there is locally-configured authorization policy for a given username, that overrides authorization policy provided by RADIUS. In other words, ultimate power rests with the local administrator, not with RADIUS. > I'm always nervous when the identity is authenticated in one name space / > administrative domain and then authorized (without further > authentication) in *another* name space / administrative domain. As you > have suggested, thus can be safe if care is taken to keep the use of > names synchronized across all these services. I claim that requires > "special considerations", and even if it's a fairly common use case, we > ned to document the "special considerations" See, you're assuming there are multiple administrative domains involved there. My desire to use RADIUS for authentication but _not_ for authorization, or the other way around, or to not use RADIUS at all, does not mean that the names are unrelated. For a moment, ignore my earlier example, which was intended only to make a specific point. Within my infrastructure, there are multiple means of authentication and a wide variety of sources of authorization and policy. The names, however, always mean the same thing. If they didn't, then policy statements would be meaningless because there would be no way to tell if a given user was the one the policy talked about. If you think the document needs to say something along the lines of VACM entries being meaningless if the security names listed don't match whatever authentication scheme you're using, go ahead. But I think that's fundamental to VACM, and not something we're introducing here. On the other hand, since we've already stated that the RADIUS User-Name gets mapped into the SNMP securityName space, I think that issue is covered. Incidentally, I would point out that any concern you have about name mismatches when using RADIUS for authentication but applying local policy _also_ apply when obtaining policy from RADIUS but using, say, SSH public key authentication, or when using SSH public key authentication with local policy, or when RADIUS verifies users by getting Kerberos tickets but obtains authorization data via LDAP. In every case, if the names don't mean the same thing, you lose. >>> (c) The use case in which RADIUS is involved in SNMP access >>> authorization >>> is likely similar to the use case in which NIS us used for UNIX >>> workstation login. In other words, either you choose to >>> centralize your >>> authentication and authorization or you don't. >> >> False. A far more common case is to choose to centralize _most_ >> authentication, but have a few locally-maintained accounts on each >> host/device/whatever. > > But even in those cases, the locally maintained accounts are both > authenticated and authorized using local data, right? Not necessarily. For example, the normal model in our environment is for users to be authenticated via Kerberos, but for login access to a given host to be controlled by policy local to the host. Kerberos certainly doesn't provide that policy; as an authentication service, authorization is (mostly) out of its scope. At the same time, it is common for machines belonging primarily to one user to be set up so that that user can log in to the _same account_ using either his Kerberos password or one stored in the local password database. In the latter case, you don't get to use most network services until you get tickets, but you can log in when the network is broken or you're not connected to it. > RADIUS may indeed consult other sources for both authentication and > authorization, but once it binds those two items into an Access-Accept > they need to remain bound. The RADIUS server is free make such trust > model choices, the RADIUS client typically is not. Why? Why in your model does the RADIUS server get to make all the policy decisions, rather than individual services making policy decisions? I don't think I've seen this approach anywhere else. >> No, you probably wouldn't, since you seem to apply the RADIUS >> worldview in which the RADIUS server is authoritative for what >> everyone else _MUST_ do, rather than the provider of information >> that it actually is. > > Well, that is the standard RADIUS world-view. I understand that this is > a "collision" of different system-level assumptions and trust models. > >> An SNMP implementation must assume that the SNMP security manager >> knew what he was doing. To do otherwise is to usurp that person's >> role as the definer of policy, and instead place the implementor in >> that role. > > I disagree. Once the authentication and authorization policy decisions > are "outsourced" to RADIUS, then SNMP is no longer authoritative. Right? > How can two separate entities both be [equally] authoritative? Wrong. Authority in this case isn't "outsourced"; it's _delegated_. The SNMP administrator remains in ultimate control, but delegates _some_ authority for decision-making to RADIUS. How much authority to delegate should and does lie with the administrator. Our choice is to either make it easy for the administrator to delegate only some authority, or insist rather loudly that if he wants RADIUS's help at all he must put RADIUS in charge and abdicate all power. I'm not interested in the latter, either as a protocol designer or as an operator. -- Jeff From dnelson@elbrysnetworks.com Mon Mar 8 12:39:03 2010 Return-Path: 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 BCF833A697D for ; Mon, 8 Mar 2010 12:39:03 -0800 (PST) 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=[AWL=0.000, 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 QkncP9g6CjaM for ; Mon, 8 Mar 2010 12:39:02 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id F1EB03A6814 for ; Mon, 8 Mar 2010 12:39:01 -0800 (PST) Received: (qmail 10446 invoked from network); 8 Mar 2010 20:38:58 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 20:38:58 -0000 Message-Id: <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> From: "David B. Nelson" To: Jeffrey Hutzelman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 15:38:58 -0500 References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 20:39:03 -0000 On Mar 8, 2010, at 2:53 PM, Jeffrey Hutzelman wrote: >> I'm always nervous when the identity is authenticated in one name >> space / >> administrative domain and then authorized (without further >> authentication) in *another* name space / administrative domain. >> As you >> have suggested, thus can be safe if care is taken to keep the use of >> names synchronized across all these services. I claim that requires >> "special considerations", and even if it's a fairly common use >> case, we >> ned to document the "special considerations" > > See, you're assuming there are multiple administrative domains > involved there. In the absence of any normative prohibition on *having* multiple administrative domains, I assume there can *be* multiple administrative domains. > My desire to use RADIUS for authentication but _not_ for > authorization, or the other way around, or to not use RADIUS at all, > does not mean that the names are unrelated. The names from separate sources can be *know* to be related by one of two means: (a) the protocols involved bind them in some secure way, or (b) an administrative policy asserts that no apparently duplicate names will ever apply to distinct individuals. The first method can be verified at run time by software, e.g. by security and/or cryptographic methods. The second method is an "act of faith" and requires that humans don't (often) make mistakes. > The names, however, always mean the same thing. If they didn't, > then policy statements would be meaningless because there would be > no way to tell if a given user was the one the policy talked about. Exactly my point! > If you think the document needs to say something along the lines of > VACM entries being meaningless if the security names listed don't > match whatever authentication scheme you're using, go ahead. I think perhaps is does, because in the only other Security Model we have available for use with VACM, i.e. USM, the names are forced to be in synchronization because they exist in the locally configured USM MIB module's data store. There's only one party involved, so there can be no lack of coordination. > Incidentally, I would point out that any concern you have about name > mismatches when using RADIUS for authentication but applying local > policy _also_ apply when obtaining policy from RADIUS but using, > say, SSH public key authentication, or when using SSH public key > authentication with local policy, or when RADIUS verifies users by > getting Kerberos tickets but obtains authorization data via LDAP. > In every case, if the names don't mean the same thing, you lose. Indeed. Which is why I think that the applicability statement for this document needs to be scoped down to deployments where the authentication and authorization information comes from the same entity, *or* an administrative policy ensures that all entities have a manually-enforced consistent view of user identity. >> I disagree. Once the authentication and authorization policy >> decisions >> are "outsourced" to RADIUS, then SNMP is no longer authoritative. >> Right? >> How can two separate entities both be [equally] authoritative? > > Wrong. Authority in this case isn't "outsourced"; it's _delegated_. OK, that's another way of looking at it. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From jhutz@cmu.edu Mon Mar 8 13:03:56 2010 Return-Path: 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 0BD603A6A05 for ; Mon, 8 Mar 2010 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EacKeEMMkP3z for ; Mon, 8 Mar 2010 13:03:55 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 1C6B63A6A06 for ; Mon, 8 Mar 2010 13:03:55 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o28L3jdL002191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 16:03:45 -0500 (EST) Date: Mon, 08 Mar 2010 16:03:45 -0500 From: Jeffrey Hutzelman To: "David B. Nelson" Message-ID: <20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu> In-Reply-To: <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:03:56 -0000 --On Monday, March 08, 2010 03:38:58 PM -0500 "David B. Nelson" wrote: > Indeed. Which is why I think that the applicability statement for this > document needs to be scoped down to deployments where the authentication > and authorization information comes from the same entity, *or* an > administrative policy ensures that all entities have a manually-enforced > consistent view of user identity. Having policy administratively originate from the same place is not the same thing as having an SNMP engine get authentication and authorization data exclusively via RADIUS. The goal here is to allow people to make use of their existing infrastructure to get something useful done, and often that's going to mean getting some but not all of this data via RADIUS. We can certainly say "make sure all your foo->securityName mappings are consistent, or you'll be sorry". But I don't think that's grounds for removing a feature that allows device administrators to override authorization policy from RADIUS. From dnelson@elbrysnetworks.com Mon Mar 8 13:19:22 2010 Return-Path: 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 859E73A69EB for ; Mon, 8 Mar 2010 13:19:22 -0800 (PST) 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=[AWL=0.000, 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 8UDSThkd7LCv for ; Mon, 8 Mar 2010 13:19:11 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 1D5D33A6A82 for ; Mon, 8 Mar 2010 13:18:41 -0800 (PST) Received: (qmail 12261 invoked from network); 8 Mar 2010 21:18:44 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 21:18:44 -0000 Message-Id: From: "David B. Nelson" To: Jeffrey Hutzelman In-Reply-To: <20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 16:18:44 -0500 References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> <20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:19:23 -0000 On Mar 8, 2010, at 4:03 PM, Jeffrey Hutzelman wrote: > Having policy administratively originate from the same place is not > the same thing as having an SNMP engine get authentication and > authorization data exclusively via RADIUS. Right. As I said in my last reply, there are protocol-domain assurances and there are policy-domain assurances. Both can be equally effective. Only the former can be validated at run time. > The goal here is to allow people to make use of their existing > infrastructure to get something useful done, and often that's going > to mean getting some but not all of this data via RADIUS. Ummm... Perhaps. > We can certainly say "make sure all your foo->securityName mappings > are consistent, or you'll be sorry". I would recommend doing so. The Security Considerations section is a natural place for this. > But I don't think that's grounds for removing a feature that allows > device administrators to override authorization policy from RADIUS. OK. As long as we clearly warn implementers and operators about the "you'll be sorry" risks of mis-identification mentioned just above, I agree we can leave that part in the document. If I were implementing this, I think I'd make the override capability a locally configureable option, just to be on the safe side. Of course, that just means you'd have to disengage the safety *and* pull the trigger in order to shoot yourself in the foot. :-) Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From jhutz@cmu.edu Mon Mar 8 13:29:31 2010 Return-Path: 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 BDEBF3A69DE for ; Mon, 8 Mar 2010 13:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vJRX4fWO2kqP for ; Mon, 8 Mar 2010 13:29:31 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 4238C3A69C6 for ; Mon, 8 Mar 2010 13:29:28 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o28LTUoW007707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 16:29:31 -0500 (EST) Date: Mon, 08 Mar 2010 16:29:30 -0500 From: Jeffrey Hutzelman To: "David B. Nelson" Message-ID: In-Reply-To: <22432_1268083183_o28LJfqO001531_B5D2B74C-5017-43DE-862C-CD61020C2BDF@elbrysnetworks.com> References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> <20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu> <22432_1268083183_o28LJfqO001531_B5D2B74C-5017-43DE-862C-CD61020C2BDF@elbrysnetworks.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:29:31 -0000 --On Monday, March 08, 2010 04:18:44 PM -0500 "David B. Nelson" wrote: >> We can certainly say "make sure all your foo->securityName mappings >> are consistent, or you'll be sorry". > > I would recommend doing so. The Security Considerations section is a > natural place for this. > >> But I don't think that's grounds for removing a feature that allows >> device administrators to override authorization policy from RADIUS. > > OK. As long as we clearly warn implementers and operators about the > "you'll be sorry" risks of mis-identification mentioned just above, I > agree we can leave that part in the document. If I were implementing > this, I think I'd make the override capability a locally configureable > option, just to be on the safe side. Of course, that just means you'd > have to disengage the safety *and* pull the trigger in order to shoot > yourself in the foot. :-) OK then. I think now all we need is some text. From randy_presuhn@mindspring.com Mon Mar 8 13:50:10 2010 Return-Path: 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 827BF3A6A24 for ; Mon, 8 Mar 2010 13:50:10 -0800 (PST) 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 oT5aX4DAkoC8 for ; Mon, 8 Mar 2010 13:50:05 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 261FA3A69E0 for ; Mon, 8 Mar 2010 13:49:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=l8+d3ZNb8s0xP/2OOJb4ntMNDQhirRrp0WcHGIKhiLezAZQXGgcmFjJkNjhjD4j7; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.25.201] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nokpr-0007Wn-Ue for isms@ietf.org; Mon, 08 Mar 2010 16:50:00 -0500 Message-ID: <00bd01cabf09$7bcb1c80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local><31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> Date: Mon, 8 Mar 2010 13:51:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b400204fb8a2c037526749ab7e364d43c5f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.25.201 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:50:10 -0000 Hi - > From: "David B. Nelson" > To: "Jeffrey Hutzelman" > Cc: > Sent: Monday, March 08, 2010 12:38 PM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 ... > I think perhaps is does, because in the only other Security Model we > have available for use with VACM, i.e. USM, the names are forced to > be in synchronization because they exist in the locally configured USM > MIB module's data store. There's only one party involved, so there > can be no lack of coordination. There's a crucial difference between isms-style solutions and USM. By design, usmUserTable is indexed by usmUserName (what shows up in protocol), but maps it to another object, usmUserSecurityName, which is what would be passed on to VACM. This is to allow for cases where "synchronization" departs from the monotonous ideal across multiple systems, and may be practically unavoidable in cases of federation. But it also requires things to be set up in advance, which would defeat the purpose of an isms-style solution. Randy From randy_presuhn@mindspring.com Mon Mar 8 13:51:31 2010 Return-Path: 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 20F0C3A6A24 for ; Mon, 8 Mar 2010 13:51:31 -0800 (PST) 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=[AWL=0.000, 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 4sZRTQYdm-Wr for ; Mon, 8 Mar 2010 13:51:30 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id CF0043A6A20 for ; Mon, 8 Mar 2010 13:51:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZaPPPZ0YMLh+H/yDSgB1R6D4MbMg5LHwSjrD2h6Cf3tJnf+9zytY604FepRVljPi; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.25.201] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NokrN-0007bG-OL for isms@ietf.org; Mon, 08 Mar 2010 16:51:34 -0500 Message-ID: <00c401cabf09$b3e01b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local><31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com><9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com><20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu><22432_1268083183_o28LJfqO001531_B5D2B74C-5017-43DE-862C-CD61020C2BDF@elbrysnetworks.com> Date: Mon, 8 Mar 2010 13:52:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40da97a011d14cf0417b69c791d901efdf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.25.201 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:51:31 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "David B. Nelson" > Cc: ; > Sent: Monday, March 08, 2010 1:29 PM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 ... > --On Monday, March 08, 2010 04:18:44 PM -0500 "David B. Nelson" > wrote: > > >> We can certainly say "make sure all your foo->securityName mappings > >> are consistent, or you'll be sorry". > > > > I would recommend doing so. The Security Considerations section is a > > natural place for this. > > > >> But I don't think that's grounds for removing a feature that allows > >> device administrators to override authorization policy from RADIUS. > > > > OK. As long as we clearly warn implementers and operators about the > > "you'll be sorry" risks of mis-identification mentioned just above, I > > agree we can leave that part in the document. If I were implementing > > this, I think I'd make the override capability a locally configureable > > option, just to be on the safe side. Of course, that just means you'd > > have to disengage the safety *and* pull the trigger in order to shoot > > yourself in the foot. :-) > > OK then. I think now all we need is some text. Will one of you be making a proposal, or should I make something up? Randy From dnelson@elbrysnetworks.com Mon Mar 8 13:53:23 2010 Return-Path: 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 5CDEE3A6A4B for ; Mon, 8 Mar 2010 13:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 i8SBTjXXzhqB for ; Mon, 8 Mar 2010 13:53:22 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id E66073A6A47 for ; Mon, 8 Mar 2010 13:53:21 -0800 (PST) Received: (qmail 14045 invoked from network); 8 Mar 2010 21:53:21 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 21:53:21 -0000 Message-Id: <4480DC9D-2D13-4B7F-BBBC-658CF26FB5D6@elbrysnetworks.com> From: "David B. Nelson" To: Jeffrey Hutzelman In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6--132290723 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 16:53:21 -0500 References: <20100308090828.GA1852@elstar.local> <31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> <20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu> <22432_1268083183_o28LJfqO001531_B5D2B74C-5017-43DE-862C-CD61020C2BDF@elbrysnetworks.com> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:53:23 -0000 --Apple-Mail-6--132290723 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 8, 2010, at 4:29 PM, Jeffrey Hutzelman wrote: > OK then. I think now all we need is some text. Here's some proposed text to add to the Security Considerations section: In order to ensure that the access control policy that is ultimately applied by means of the mechanisms described in this document accurately represents the intended policy for any given principal, care needs to be applied in the mapping of the authenticated user (principal) identity to the securityName that is used to make the access control decision. Generally speaking, there are two approaches to ensure the consistency of identity: (a) that the RADIUS User-Name (or other AAA-authenticated identity) is dynamically propagated into the securityName object(s) of the vacmSecurityToGroup table, or (b) in the case of a pre-configured entry in the vacmSecurityToGroup table, with a name that apparently matches the authenticated principal's User-Name, that administrative policy ensures a manually- enforced consistency of identity between the authenticated principal's User-Name and the securityName in the vacmSecurityToGroup table row entries. In the later case, if care is not taken, it is possible that inconsistent re-use of the same name for different entities or individuals (principals) will cause the incorrect access control policy to be applied for the authenticated principal. This may result in greater or lesser access rights than the administrative policy intended. Inadvertent mis-identification in such cases may be undetectable by the SNMP engine or other software elements of the managed entity. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com --Apple-Mail-6--132290723 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 8, 2010, at = 4:29 PM, Jeffrey Hutzelman wrote:

OK = then.  I think now all we need is some = text.

Here's some proposed text to = add to the Security Considerations = section:

In order to ensure that the access control = policy that is ultimately applied by means of the mechanisms described = in this document accurately represents the intended policy for any given = principal, care needs to be applied in the mapping of the authenticated = user (principal) identity to the securityName that is used to make the = access control decision.  Generally speaking, there are two = approaches to ensure the consistency of = identity:

=  (a) that the RADIUS User-Name (or other AAA-authenticated = identity) is dynamically propagated into the securityName object(s) of = the vacmSecurityToGroup table, or

 (b) in the = case of a pre-configured entry in the vacmSecurityToGroup table, with a = name that apparently matches the authenticated principal's User-Name, = that administrative policy ensures a manually-enforced consistency of = identity between the authenticated principal's User-Name and the = securityName in the vacmSecurityToGroup table row = entries.

In the later case, = if care is not taken, it is possible that inconsistent re-use of the = same name for different entities or individuals (principals) will cause = the incorrect access control policy to be applied for the authenticated = principal.  This may result in greater or lesser access rights than = the administrative policy intended.  Inadvertent mis-identification = in such cases may be undetectable by the SNMP engine or other software = elements of the managed = entity.


Regards,

Dave

Dav= id B. Nelson

Elbrys Networks, = Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH = 03801

+1.603.570.2636
dnelson@elbrysnetworks.com<= /div>





= --Apple-Mail-6--132290723-- From dnelson@elbrysnetworks.com Mon Mar 8 13:55:07 2010 Return-Path: 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 2D4203A6A47 for ; Mon, 8 Mar 2010 13:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 1enh9BzWTYqd for ; Mon, 8 Mar 2010 13:55:06 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 2C3823A6A44 for ; Mon, 8 Mar 2010 13:55:06 -0800 (PST) Received: (qmail 14217 invoked from network); 8 Mar 2010 21:55:06 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2010 21:55:06 -0000 From: "David B. Nelson" To: "Randy Presuhn" In-Reply-To: <00c401cabf09$b3e01b20$6801a8c0@oemcomputer> X-Priority: 3 References: <20100308090828.GA1852@elstar.local><31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com><9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com><20FEC3C770725B90E762B4D7@minbar.fac.cs.cmu.edu><22432_1268083183_o28LJfqO001531_B5D2B74C-5017-43DE-862C-CD61020C2BDF@elbrysnetworks.com> <00c401cabf09$b3e01b20$6801a8c0@oemcomputer> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 16:55:06 -0500 X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 21:55:07 -0000 On Mar 8, 2010, at 4:52 PM, Randy Presuhn wrote: > Will one of you be making a proposal, or should I make something up? I have submitted some text for consideration. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From randy_presuhn@mindspring.com Mon Mar 8 14:52:10 2010 Return-Path: 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 8A32D3A6A07 for ; Mon, 8 Mar 2010 14:52:10 -0800 (PST) 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 isf34EwRMNEN for ; Mon, 8 Mar 2010 14:52:09 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 834B53A63D3 for ; Mon, 8 Mar 2010 14:52:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DO8BpzvwePsP09BKMK44Yzfu7vNzLsskfDa8gC38TPp/uaMahhwmFgyJsdCwTa1w; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.25.201] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nolo4-00059E-CM for isms@ietf.org; Mon, 08 Mar 2010 17:52:12 -0500 Message-ID: <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> Date: Mon, 8 Mar 2010 14:53:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4020b6e23f60c7885ce344b504673c53e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.25.201 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Mon, 08 Mar 2010 22:52:11 -0000 Hi - The editorial items in this list are fixed, but I'm not sure what to do with the lengthy comments later on. > From: "David B. Nelson" > To: > Sent: Monday, March 08, 2010 7:29 AM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 > > Editorial corrections: > > Section 1: > > s/from RADIUS or other AAA/from RADIUS or another AAA/ > > Old text: > > o The Secure Shell Transport Model for SNMP [RFC5592] defines a > Secure Shell Transport Model and Remote Authentication Dial-In > User Service (RADIUS). > > New text: > > o The Secure Shell Transport Model for SNMP [RFC5592] defines a > Secure Shell Transport Model. Fixed. > Old text: > > This memo defines an extension to the View-based Access Control > Model to obtain authorization information for an authenticated > principal, from RADIUS or equivalent AAA service supporting a > Transport Security Model. > > New text: > > This memo defines an extension to the View-based Access Control > Model to obtain authorization information for an authenticated > principal, from RADIUS or an equivalent AAA service when used > with a Transport Security Model. Fixed. (Also, changed "extension" to "supplement" for consistency with earlier text.) > Section 4.3: > Old text: > o the model provides an indication of the establishment session for > a particular user, identified using a SecurityName, and provides > the corresponding value of vacmGroupName to be used, based on > information provided by the AAA service in use; > New text: > > o the model provides an indication of the establishment of a > session for > a particular user, identified using a SecurityName, and provides > the corresponding value of vacmGroupName to be used, based on > information provided by the AAA service in use; Fixed. > Section 9: > > This integration strongly assumes that RADIUS (or some other AAA > service) is at least as trusted as the security administrator with > access rights to the vacmSecurityToGroupTable. It assumes that the > transport security model can be trusted to pass through the users' > security name and the group name provided by the AAA service. It > also trusts the transport security model to enforce any session > timeouts imposed by the RADIUS server, and to provide an indicate > whenever a session ends. > s/an indicate/an indication/ Fixed. > The algorithms in this memo make heuristic use of the StorageType of > entries in the vacmSecurityToGroupTable to distinguish those which > have been provisioned by a security administrator (which would > presumably not be configured as "volatile") and those dynamically > generated. In making this distinction, it assumes that those > entries > explicitly provisioned by a security administrator and given a > non-"volatile" status are not to be dynamically over-ridden. > I don't think it's reasonable, or generally safe, to automatically > assume that the SNMP security administrator is "clueful" and the > RADIUS system administrator is "clueless". I don't think we're making any such assumption. It's a question of how to handle information which has been explicitly provisioned to be persistant, and how to heuristically identify stuff which may be overwritten with little risk of trampling on an explicitly provisioned configuration. > That would seem to be the > implication of always favoring the statically configured information > over the dynamically derived information. IMHO, the only thing that > can be safely inferred from this type of conflict is that the two > individuals are not coordinating with each other. That raises a "red > flag" and SHOULD result in an investigation of the root cause of the > apparent conflict. As a practical matter, since these tables are indexed both by security model and security name, I think the interesting cases will happen when systems are upgraded to support this capability, and as the RADIUS attribute for the group mapping is deployed. These systems will likely find themselves needing the administratively configured mapping for some period of time, until the RADIUS support is turned on. At the point, we need to ask ourselves, is it better to require the security administrator to clean up the vacmUserToGroupTables, to rely on error notifications to prompt the administrator to clean up the tables, or to (making a change to the proposed EOP) rely on dynamic updates to override what had been provisioned as non-volatile access control policy configuration data? The current EOP assumes the first of these three strategies. I think there are pros and cons to each of these from a software updgrade, deployment, and operational perspective. What I like best about the current EOP is that it is very simple, offers no surprises, and would be very easy to implement and test, at least in the code bases I'm familiar with. > Users > of this memo need to be aware of this operational assumption, which, > while reasonable, is not necessarily universal. > Um... yeah. I think this is insufficiently sternly worded advice. I'm open to proposals for sterner advice. But before we go too far, I'd like to know whether anyone has ever seen an operational network where vacmUserToGroupTable entries were set up as "volatile". I haven't been able to think of a realistic use case for such a thing, but that might just be the fault of my own limited imagination. > The design of VACM ensures that if an unknown policy (group name) is > used in the VacmSecurityToGroupTable, no access is granted. A > consequence of this is that even in the presence of a malfunctioning > or compromised AAA server, no user can gain access rights not > already > granted to some group. > It is reasonable to "fail safe" by not granting access in that case of > an apparent misconfiguration or lack of policy coordination among > system and security administrators. On the other hand, why is it > more likely that the AAA server is malfunctioning or compromised? I don't think we made any such assumption. > This language seems to give greater weight (credence) to the actions > and configurations of the SNMP security administrator in setting up > the VACM MIB modules. It seems to me that either source of > information is equally subject to malfunction, misconfiguration or > compromise. Of course, if the security and access control mechanisms > of the managed entity have indeed been compromised, all bets are off, > no matter what RADIUS may have to say in the mater. The *intended* perspective is a bit different. The boilerplate is intended to address the stuff that is in common with other MIB documents. VACM is taken as a given, and the added material is intended to address the ways in which this document differs from other MIB documents. The addition of RADIUS as an information source, and the modification of VACM configuration data, are the key differences. I'd like to avoid repeating the security considerations section of the VACM document, just as I'd like to avoid repeating the security considerations sections of the RADIUS documents. Randy From ietfdbh@comcast.net Mon Mar 8 15:46:06 2010 Return-Path: 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 DE6843A6BCB for ; Mon, 8 Mar 2010 15:46:06 -0800 (PST) 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 QVSNR+uxqPlx for ; Mon, 8 Mar 2010 15:46:06 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A9F373A6B86 for ; Mon, 8 Mar 2010 15:46:04 -0800 (PST) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id qcs21d0070FhH24A1nmA09; Mon, 08 Mar 2010 23:46:10 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta08.emeryville.ca.mail.comcast.net with comcast id qnm71d00X4G8Frs8Unm8L9; Mon, 08 Mar 2010 23:46:09 +0000 From: "David Harrington" To: "'David B. Nelson'" , "'Jeffrey Hutzelman'" References: <20100308090828.GA1852@elstar.local><31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> Date: Mon, 8 Mar 2010 18:46:06 -0500 Message-ID: <0a7a01cabf19$8686cfb0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq+8wCbRG+MqZtjQ+uyLQAP0gizTwAI6bxw Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Mon, 08 Mar 2010 23:46:07 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > I'm always nervous when the identity is authenticated in one name > space / administrative domain and then authorized (without further > authentication) in *another* name space / administrative domain. As > you have suggested, thus can be safe if care is taken to keep > the use > of names synchronized across all these services. I claim that > requires "special considerations", and even if it's a fairly common > use case, we ned to document the "special considerations" > > My concern is the separation of authentication and authorization. > We've had this discussion before, BTW. I haven't changed my opinion. The SNMPv3 WG also discussed this at length and decided to deliberately separate authentication and authorization, while RADIUS decided to bind them. Sure, an operator will need to be careful to coordinate the securityName used for authentication and the securityname used when configuring VACM authorization. Anytime a securityname must be manually configured in a MIB, such as in the target-table, the administrator needs to be aware of what the securityname means. SNMP admins know this already. > > An SNMP implementation must assume that the SNMP security manager > > knew what he was doing. To do otherwise is to usurp that person's > > role as the definer of policy, and instead place the > implementor in > > that role. > > I disagree. Once the authentication and authorization policy > decisions are "outsourced" to RADIUS, then SNMP is no longer > authoritative. Right? How can two separate entities both be > [equally] authoritative? An organization might delegate some authority to different persons or mechanisms. As the COPS-PR policy-based management experience showed clearly, network administrators do not completely outsource their authority to automated protocols. Admins and RADIUS are not equally authoritative. Admins are the definers of policy; RADIUS simply tells a NAS what the policy is. Admins assert the right to override policy-based protocols as needed. dbh From ietfdbh@comcast.net Mon Mar 8 16:09:24 2010 Return-Path: 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 0ACAF3A67A6 for ; Mon, 8 Mar 2010 16:09:24 -0800 (PST) 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 MnBC85p2QSND for ; Mon, 8 Mar 2010 16:09:23 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 4CBCF3A65A6 for ; Mon, 8 Mar 2010 16:09:23 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id qnav1d0061ZMdJ4AEo9UEG; Tue, 09 Mar 2010 00:09:28 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta16.emeryville.ca.mail.comcast.net with comcast id qoCy1d0024G8Frs8coCyK3; Tue, 09 Mar 2010 00:13:00 +0000 From: "David Harrington" To: "'David B. Nelson'" , "'Jeffrey Hutzelman'" References: <20100308090828.GA1852@elstar.local><31206_1268059659_o28ElbTO031147_AC40F5FB-CFB6-4472-A255-66662122E898@elbrysnetworks.com> <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> Date: Mon, 8 Mar 2010 19:09:24 -0500 Message-ID: <0ab801cabf1c$c7d9a700$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9BB632E8-6759-4C81-8017-31406C45CE79@elbrysnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq+/2hX+QWiGb0WTEWl1TqpkBgtjQAG05pA Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Tue, 09 Mar 2010 00:09:24 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > > If you think the document needs to say something along the > lines of > > VACM entries being meaningless if the security names listed don't > > match whatever authentication scheme you're using, go ahead. > > I think perhaps is does, because in the only other Security Model we > have available for use with VACM, i.e. USM, the names are forced to > be in synchronization because they exist in the locally > configured USM > MIB module's data store. There's only one party involved, so there > can be no lack of coordination. In SNMPv2 party, the authentication and authorization were bound toghether in a common MIB module for authentication and authorization. The SNMPv3 WG deliberately (i.e., we deliberated long and hard and debated the ramifications of the decision) chose to separate authentication from authorization to permit admins to choose how to combine them. This decision was based on the belief that admins have more authority than either the authentication mechanism or the authorization mechanism in use. We decided that we should assume that the SNMP admins **do** know what they are doing. Your assumption that SNMP admins do not know what they are doing is not consistent with SNMPv3 WG consensus. Somehow, you have concluded that the admin who configures a centralized RADIUS server with a set of static rules at some point in time must know more about the devices being managed than an admin who has direct knowledge of the local device being managed or the current local events impacting the local device. I think that's a mistake. dbh From ietfdbh@comcast.net Mon Mar 8 16:56:21 2010 Return-Path: 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 59A1A3A6A66 for ; Mon, 8 Mar 2010 16:56:21 -0800 (PST) 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=[AWL=0.000, 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 zi-SpbkIAr1Y for ; Mon, 8 Mar 2010 16:56:20 -0800 (PST) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 466343A677E for ; Mon, 8 Mar 2010 16:56:20 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id qmcR1d0021eYJf8A9owRvo; Tue, 09 Mar 2010 00:56:25 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta19.emeryville.ca.mail.comcast.net with comcast id qowP1d00k4G8Frs01owQyU; Tue, 09 Mar 2010 00:56:25 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> Date: Mon, 8 Mar 2010 19:56:22 -0500 Message-ID: <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq/EgLBPUsDhyFjQvugLRZzInk1TAADGHQg Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Tue, 09 Mar 2010 00:56:21 -0000 > > Section 4.3: > > New text: > > > > o the model provides an indication of the establishment of a > > session for > > a particular user, identified using a SecurityName, > and provides > > the corresponding value of vacmGroupName to be used, based on > > information provided by the AAA service in use; That should probably be authenticated principal rather than user. I'm not comfortable talking about session here; SNMP has no sessions. The model provides the establishment of a policy for a particular principal. The lifetime of the policy might be tied to the lifetime of a session of the AAA service in use. > > Section 9: > > > > This integration strongly assumes that RADIUS (or some other AAA > > service) is at least as trusted as the security > administrator with > > access rights to the vacmSecurityToGroupTable. It > assumes that the > > transport security model can be trusted to pass through > the users' > > security name and the group name provided by the AAA > service. It > > also trusts the transport security model to enforce any session > > timeouts imposed by the RADIUS server, and to provide > an indicate > > whenever a session ends. I don't agree with this text. I do not agree that RADIUS is "at least as trusted as the security administrator". The security administrator delegates authority to AAA to inform the SNMP entity about the security policy. There is no assumption that the transport security model "can be trusted". I am not checking the TSM, but I'm pretty sure it never even sees the group name provided by AAA. And IIRC, TSM knows nothing about sessions; a session is something a transport model might know about that is tied to the transport involved. > > I don't think it's reasonable, or generally safe, to > automatically > > assume that the SNMP security administrator is "clueful" and the > > RADIUS system administrator is "clueless". > > I don't think we're making any such assumption. It's a question of > how to handle information which has been explicitly provisioned to > be persistant, and how to heuristically identify stuff which may be > overwritten with little risk of trampling on an explicitly provisioned > configuration. I don't think we're making any such assumption either. What we are assuming is that an admin has a reason to locally and mnaually configure an override. I don't think it's reasonable, or generally safe, to automatically assume that the SNMP security administrator is "clueless" and the RADIUS system administrator is "clueful", especially about current local operating conditions. > > That would seem to be the > > implication of always favoring the statically configured > information > > over the dynamically derived information. IMHO, the only > thing that > > can be safely inferred from this type of conflict is that the two > > individuals are not coordinating with each other. That > raises a "red > > flag" and SHOULD result in an investigation of the root > cause of the > > apparent conflict. And who should do that investigation? the RADIUS server or the clueless security administrator? Remember, only somebody who has permission to change the VACM tables can configure the override. I would like to think that the security administrator is at least as trusted as the RADIUS server. > > As a practical matter, since these tables are indexed both by security > model and security name, I think the interesting cases will happen > when systems are upgraded to support this capability, and as the > RADIUS attribute for the group mapping is deployed. These systems > will likely find themselves needing the administratively configured > mapping for some period of time, until the RADIUS support is > turned on. At the point, we need to ask ourselves, is it better to > require the security administrator to clean up the > vacmUserToGroupTables, > to rely on error notifications to prompt the administrator to > clean up the tables, > or to (making a change to the proposed EOP) rely on dynamic > updates to override what had been provisioned as non-volatile > access control policy configuration data? I strongly recommend you acquaint yourself with the COPS-PR fiasco, where COPS-PR was allowed to override administrator changes. There is a reason you do not see COPS-PR mentioned positively in the O&M area - the operators hated the assumption that some server was trusted more than an administrator who is aware of current operational conditions, which might be different than when the policy server was configured. Operators need to be able to override automated policy, and not have the policy override their overrides. dbh From randy_presuhn@mindspring.com Mon Mar 8 18:06:40 2010 Return-Path: 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 2328C3A67E6 for ; Mon, 8 Mar 2010 18:06:40 -0800 (PST) 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=[AWL=0.000, 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 zhe6esxAbEOP for ; Mon, 8 Mar 2010 18:06:35 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id CB14D3A67E2 for ; Mon, 8 Mar 2010 18:06:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HsS9h72uWxc0jOLatzuc4+9gJTibOUH+Kn8TQOCkt7onN6TAIe+C+PCpBcSwrBeF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.25.201] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NooqE-0006bd-Ev for isms@ietf.org; Mon, 08 Mar 2010 21:06:38 -0500 Message-ID: <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> Date: Mon, 8 Mar 2010 18:07:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b404c1af2761c138e3ed81eeb76087763a5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.25.201 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Tue, 09 Mar 2010 02:06:40 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; > Sent: Monday, March 08, 2010 4:56 PM > Subject: RE: [Isms] wg last call on the radius / vacm document: ISSUE 4 ... > > > Section 4.3: > > > New text: > > > > > > o the model provides an indication of the establishment of a > > > session for > > > a particular user, identified using a SecurityName, > > and provides > > > the corresponding value of vacmGroupName to be used, based > on > > > information provided by the AAA service in use; > > That should probably be authenticated principal rather than user. Fixed. > I'm not comfortable talking about session here; SNMP has no sessions. SNMP doesn't, but the secure transport models we're supporting here do. > The model provides the establishment of a policy for a particular > principal. > The lifetime of the policy might be tied to the lifetime of a session > of the AAA service in use. Indirectly, this gets back to the question of how general we want to make this. For all the AAA examples discussed so far, unless I've overlooked something, the dynamic authorization begins and ends with the session. The dynamic VACM entries created here are *always* limited to the specific security model associated with the authentication / authorization. For a VACM entry to outlive the last remaining session would be pointless - after the end of the last session, there can be no requests with that SecurityModel/ SecurityName pair to authorize. Likewise, since the authorization to even establish a session comes from the AAA, there is no value in having a pre-existing entry for that particular SecurityModel/SecurityName pair. So, I think no change is needed here, though I'm open to alternative wordings for "session". > > > Section 9: > > > > > > This integration strongly assumes that RADIUS (or some other > AAA > > > service) is at least as trusted as the security > > administrator with > > > access rights to the vacmSecurityToGroupTable. It > > assumes that the > > > transport security model can be trusted to pass through > > the users' > > > security name and the group name provided by the AAA > > service. It > > > also trusts the transport security model to enforce any > session > > > timeouts imposed by the RADIUS server, and to provide > > an indicate > > > whenever a session ends. > > I don't agree with this text. I do not agree that RADIUS is "at least > as trusted as the security administrator". The security administrator > delegates authority to AAA to inform the SNMP entity about the > security policy. There is no assumption that the transport security > model "can be trusted". Point taken. However, I'm not sure what to do with the existing text. Does someone have a concrete text proposal? > I am not checking the TSM, but I'm pretty sure it never even sees the > group name provided by AAA. And IIRC, TSM knows nothing about > sessions; a session is something a transport model might know about > that is tied to the transport involved. I'm not sure what to do here. We're dealing with abstractions that may or may not have any recognizable counterpart in an implementation. Text would be welcomed. .... > > > That would seem to be the > > > implication of always favoring the statically configured > > information > > > over the dynamically derived information. IMHO, the only > > thing that > > > can be safely inferred from this type of conflict is that the two > > > > individuals are not coordinating with each other. That > > raises a "red > > > flag" and SHOULD result in an investigation of the root > > cause of the > > > apparent conflict. > > And who should do that investigation? the RADIUS server or the > clueless security administrator? Remember, only somebody who has > permission to change the VACM tables can configure the override. I > would like to think that the security administrator is at least as > trusted as the RADIUS server. I'm of two minds on this. I can understand the reasoning that such a conflicts should be rare. and might merit investigation. But I also can understand the need to apply a more stringent or more liberal policy to a particular user on a particular system than might be the case throughout the rest of the enterprise. My personal preference would be to get some deployment experience with the MIB as it is, and, if we find this is a real operational problem, to address it in a revision to the MIB module. I think that's preferable to potentially over-engineering it from the outset. > > > > As a practical matter, since these tables are indexed both by > security > > model and security name, I think the interesting cases will happen > > when systems are upgraded to support this capability, and as the > > RADIUS attribute for the group mapping is deployed. These systems > > will likely find themselves needing the administratively configured > > mapping for some period of time, until the RADIUS support is > > turned on. At the point, we need to ask ourselves, is it better to > > require the security administrator to clean up the > > vacmUserToGroupTables, > > to rely on error notifications to prompt the administrator to > > clean up the tables, > > or to (making a change to the proposed EOP) rely on dynamic > > updates to override what had been provisioned as non-volatile > > access control policy configuration data? > > I strongly recommend you acquaint yourself with the COPS-PR fiasco, > where > COPS-PR was allowed to override administrator changes. There is a > reason you > do not see COPS-PR mentioned positively in the O&M area - the > operators hated > the assumption that some server was trusted more than an administrator > who is aware of current operational conditions, which might be > different than when the policy server was configured. Operators need > to be able to override automated policy, and not have the policy > override their overrides. ? That's one of the (unwritten) reasons why the current EOP favors administratively configured policy over what is dynamically delivered. I don't see a need to make any changes here. Randy From j.schoenwaelder@jacobs-university.de Mon Mar 8 23:04:20 2010 Return-Path: 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 9E64B3A65A6 for ; Mon, 8 Mar 2010 23:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 8c3WtmBPcaPV for ; Mon, 8 Mar 2010 23:04:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5FB0F3A6765 for ; Mon, 8 Mar 2010 23:04:19 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1573DC0007; Tue, 9 Mar 2010 08:04:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OErFCcgzsh8O; Tue, 9 Mar 2010 08:04:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4326EC0002; Tue, 9 Mar 2010 08:04:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C6EE610C3735; Tue, 9 Mar 2010 08:04:15 +0100 (CET) Date: Tue, 9 Mar 2010 08:04:15 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20100309070415.GA5024@elstar.local> Mail-Followup-To: "David B. Nelson" , "isms@ietf.org" References: <20100308090828.GA1852@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:04:20 -0000 On Mon, Mar 08, 2010 at 03:47:17PM +0100, David B. Nelson wrote: > Section 7.2.2: > > If a corresponding entry already exists in the > vacmSecurityToGroupTable, and the row's StorageType is anything other > than "volatile", or the RowStatus is anything other than "active", > then a role (group) mapping for this user (principal) has already > been put in place on this system, and will not be overridden. > > I've said this before, but I'll say it again, hopefully in clearer terms. I think that the notion of the *same* principal identity that comes from RADIUS (or other AAA) having already been "put in place on this system" is highly dubious. At best, it relies on special circumstances. Here's my reasoning on this: > > (a) There is nothing in the documented protocol or elements of procedures that guarantees that the content of an SNMP securityName bears any relationship to the content of a RADIUS User-Name *unless* the former is dynamically obtained from the later, in the context of a single secure transport session. > > (b) In the absence of careful coordination on the part of the RADIUS system administrator and the SNMP system administrator, i.e. "special circumstances" there is no guarantee that independently, manually-configured but identical user names actually refer to the same user. For example, it is possible that the RADIUS system administrator is using the name "dave" for Dave Nelson and the SNMP system administrator is using the name "dave" for Dave Harrington. I understand that the likelihood of such name collisions is reduced if fuller versions of the names are used, but 'll observe that at one point in time there were *five* Dave Nelson's working for Digital Equipment Corporation, of which I was just one. So name collisions, and the resulting mis-identity, are not such a narrow corner case. > > (c) The use case in which RADIUS is involved in SNMP access authorization is likely similar to the use case in which NIS us used for UNIX workstation login. In other words, either you choose to centralize your authentication and authorization or you don't. While there is alway the need for a [small] number of locally maintained access credentials for "emergency" login usages, it seems odd to me that a real-world deployment would be using RADIUS for "outsourced" identity management and at the same time there would be a manually configured set of user identities in the VACM MIB tables that requires constant synchronization with the user configured in RADIUS. > > For these reasons, I think that the particular scenario in which an existing, manually-configured, non-volatile, vacmSecurityToGroup table row is expected to correctly match the securityName dynamically derived from RADIUS relies on "special circumstances", i.e. careful manual coordination of potentially disjoint name spaces. I think this opens up the *potential* for a significant security risk. In short, I would not automatically assume that the SNMP security manage knew what he/she was doing. :-) But the quoted text essentially says that local configuration takes precedence over RADIUS. This is similar to what happens in NIS or similar services. What do you propose how to handle this situation? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 8 23:06:20 2010 Return-Path: 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 669463A65A6 for ; Mon, 8 Mar 2010 23:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 S3SirnCERhdl for ; Mon, 8 Mar 2010 23:06:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 79AF43A6407 for ; Mon, 8 Mar 2010 23:06:19 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86C4AC0007; Tue, 9 Mar 2010 08:06:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UOHk3H+pv+Di; Tue, 9 Mar 2010 08:06:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18523C0002; Tue, 9 Mar 2010 08:06:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C63FB10C378B; Tue, 9 Mar 2010 08:06:20 +0100 (CET) Date: Tue, 9 Mar 2010 08:06:20 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20100309070620.GB5024@elstar.local> Mail-Followup-To: "David B. Nelson" , "isms@ietf.org" References: <20100308090828.GA1852@elstar.local> <510570E4-0246-4C86-8705-FDC2A0E7AF45@elbrysnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510570E4-0246-4C86-8705-FDC2A0E7AF45@elbrysnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:06:20 -0000 On Mon, Mar 08, 2010 at 04:03:38PM +0100, David B. Nelson wrote: > I previously opined that removing the error counters from the MB > module in this document was a mistake. > > Randy observed that notifications would often be more helpful in > resolving the errors than would simple counters. I agree. > > Randy also observed that implementors could use implementation > dependent means, including appropriate syslog messages. Yes, they > could. > > My concern is that if we don't include either counters or notification > objects in the MIB module, that implementers will be tempted to skip > over including any form of error indications. We could beef up the > security considerations text, to make that alternative less > attractive. Either way, I think *something* needs to be done about > these potential error conditions. While the counters are simplistic, > much as that "check engine" idiot light on my dashboard, they at least > indicate the need for investigation. They also have the advantage of > being simple to implement. Not all of the originally proposed > counters fall into this category, but some of them do. I'm thinking > of the ones that signal a > *possible* disconnect or lack of coordination between the RADIUS > system administrator and SNMP security administrator. > > Leaving it up the the initiative of conscientious implementers to > handle these potential security mis-configurations in an ad-hoc > fashion is not a good idea. We should aim higher, I think. So is your proposal to reinstall the counters (exactly those we had in the revision before they got removed)? Or is your proposal to add suitable notifications? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 8 23:23:53 2010 Return-Path: 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 3C4C93A67C0 for ; Mon, 8 Mar 2010 23:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] 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 hiXc+SCrfWRQ for ; Mon, 8 Mar 2010 23:23:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 390C33A67AE for ; Mon, 8 Mar 2010 23:23:52 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E2F9C000A; Tue, 9 Mar 2010 08:23:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HYMlGidOwkK5; Tue, 9 Mar 2010 08:23:55 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFB47C0002; Tue, 9 Mar 2010 08:23:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8208110C3887; Tue, 9 Mar 2010 08:23:53 +0100 (CET) Date: Tue, 9 Mar 2010 08:23:53 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100309072353.GC5024@elstar.local> Mail-Followup-To: "tom.petch" , "Pasi.Eronen@nokia.com" , isms References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> <000c01cabed0$014ed8e0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cabed0$014ed8e0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: isms Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:23:53 -0000 On Mon, Mar 08, 2010 at 03:35:30PM +0100, tom.petch wrote: > I am unclear. Are youre requirements met by the new wording, of > "That is, implementations MUST > either disable renegotiation completely (RECOMMENDED), or MUST > present the same certificate during renegotiation (and MUST verify > that the other end presented the same certificate). > " > which I have previously paraphrased as 'NOT RECOMMENDED'? I am not an expert on (D)TLS regenotiation issues but I personally believe we went over board with this. I consider the renegotiation bug of TLS a temporary problem that can and likely will be cured (see RFC 5746). Hence, we are making a bad decision to outlaw renegotiation in general just because many deployed libraries today are somewhat vulnerable. I would prefer if the second paragraph in section 4.2 would be removed and we would add discussion to the Security Considerations pointing out the issue with "old" TLS code and the ways to work around things, including the option to disable renegotiation if the (D)TLS library used has not fixed the problem, e.g. via RFC 5746, or to verify the same certificate has been used during renegotiation. Comments? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Tue Mar 9 03:19:32 2010 Return-Path: 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 076683A687D for ; Tue, 9 Mar 2010 03:19:32 -0800 (PST) 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 s37CC3AVHXTg for ; Tue, 9 Mar 2010 03:19:29 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 8E89C3A68CC for ; Tue, 9 Mar 2010 03:19:29 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id qzBC1d0011ei1Bg5CzKaYy; Tue, 09 Mar 2010 11:19:34 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta24.westchester.pa.mail.comcast.net with comcast id qzNB1d0010yip6Y3kzNBoM; Tue, 09 Mar 2010 11:22:11 +0000 From: "Dave Nelson" To: References: <20100308090828.GA1852@elstar.local><510570E4-0246-4C86-8705-FDC2A0E7AF45@elbrysnetworks.com> <20100309070620.GB5024@elstar.local> Date: Tue, 9 Mar 2010 06:19:46 -0500 Message-ID: <313427BE49284D05B70ADCF677E5B13D@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acq/VwrvILER7SHwSbq/q6UXSHactQAIQbOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20100309070620.GB5024@elstar.local> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 3 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: , X-List-Received-Date: Tue, 09 Mar 2010 11:19:33 -0000 Juergen Schoenwaelder writes... > So is your proposal to reinstall the counters (exactly those we > had in the revision before they got removed)? No. Not exactly. I agree, for example, that the counter of "out of memory" occurrences is a bit silly. > Or is your proposal to add suitable notifications? I'd need assistance with crafting that proposal, as I'm a bit rusty at notifications. What I'd like to accomplish is some method of signaling when a potential misconfiguration has occurred. One event in question is when a RADIUS User-Name collides with an existing securityName in the vacmSecurityToGroupTable. Another event is when the RADIUS Management-Policy-Id doesn't match any pre-configured VACM groups. As was extensively debated under ISSUE 2 yesterday, it will not be possible to axiomatically determine what is a misconfiguration and what is an intentional override, when it comes to the User-Name. Only the human in charge of the device configuration will know. Given the potential for a lot of false alarms, in the case of intentional overrides, it seems that counters that can simply be ignored would be less burdensome to manage, as well as to implement. I'm open to suggestions as to whether it should be counters or notifications. One could also argue that the misconfiguration errors I'm concerned about simply won't happen in "real life" and that we need do nothing. I'm not convinced that's the case. In any event, I'd appreciate feedback from others on the list as to whether this is an issue we need to address. From d.b.nelson@comcast.net Tue Mar 9 03:21:49 2010 Return-Path: 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 68EA73A6811 for ; Tue, 9 Mar 2010 03:21:45 -0800 (PST) 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 6M++AlVG7wOZ for ; Tue, 9 Mar 2010 03:21:43 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 4F7493A67E7 for ; Tue, 9 Mar 2010 03:21:42 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta12.westchester.pa.mail.comcast.net with comcast id qzML1d0020ldTLk5CzMnl2; Tue, 09 Mar 2010 11:21:47 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta04.westchester.pa.mail.comcast.net with comcast id qzMn1d0090yip6Y3QzMnvc; Tue, 09 Mar 2010 11:21:47 +0000 From: "Dave Nelson" To: References: <20100308090828.GA1852@elstar.local> <20100309070415.GA5024@elstar.local> Date: Tue, 9 Mar 2010 06:21:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acq/VsLQ5hggGGrxQ06L9bZJ7Gl6pAAI8AAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20100309070415.GA5024@elstar.local> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2 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: , X-List-Received-Date: Tue, 09 Mar 2010 11:21:49 -0000 Juergen Schoenwaelder writes... > What do you propose how to handle this situation? Text to be added to the Security Considerations Section was posted to the list yesterday. From d.b.nelson@comcast.net Tue Mar 9 03:34:34 2010 Return-Path: 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 912F23A68C9 for ; Tue, 9 Mar 2010 03:34:34 -0800 (PST) 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 13EBC3AXbhxZ for ; Tue, 9 Mar 2010 03:34:33 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 87F053A6824 for ; Tue, 9 Mar 2010 03:34:33 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id qzM21d0031ei1Bg58zaeLn; Tue, 09 Mar 2010 11:34:38 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta24.westchester.pa.mail.comcast.net with comcast id qzdF1d0030yip6Y3kzdF5T; Tue, 09 Mar 2010 11:37:15 +0000 From: "Dave Nelson" To: References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 06:34:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acq/LS1s5h0knmpcSdO/YKtj+eHUhwATZ+Ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Tue, 09 Mar 2010 11:34:34 -0000 Randy Presuhn writes (in response to Dave Harrington)... > > I don't agree with this text. I do not agree that RADIUS is "at least > > as trusted as the security administrator". The security administrator > > delegates authority to AAA to inform the SNMP entity about the > > security policy. There is no assumption that the transport security > > model "can be trusted". > > Point taken. However, I'm not sure what to do with the existing text. > Does someone have a concrete text proposal? If you don't trust RADIUS or the system administrator who configures its polices, then don't use it. I think I see organizational dynamics arguments creeping into a protocol discussion. That's always a bad sign, IMHO. If there's bad organizational karma between the SNMP security administrator and the corporate RADIUS administrator, fight that out in the personnel domain, not the protocol domain, please. As to trusting the TSM (or TM), I think what's mean here is that one trust the implementation to pass along the information, including User-Name and Management-Policy-Id attributes and session start and end events, that the documents says it has to pass along. > > I am not checking the TSM, but I'm pretty sure it never even sees the > > group name provided by AAA. And IIRC, TSM knows nothing about > > sessions; a session is something a transport model might know about > > that is tied to the transport involved. > > I'm not sure what to do here. We're dealing with abstractions that may > or may not have any recognizable counterpart in an implementation. > Text would be welcomed. This is another situation where the architectural model is simply getting in the way. I had originally suggested we use one of those "magic caches" as we did for the TSM and TM work. It was suggested by others on the list that we leave the implementation detail more open ended for this document. The result is that it's not exactly clear how the information flows, just that it MUST flow. From d.b.nelson@comcast.net Tue Mar 9 03:41:02 2010 Return-Path: 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 DE0253A68CC for ; Tue, 9 Mar 2010 03:41:02 -0800 (PST) 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=[AWL=0.000, 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 SxYpSWBRqgrI for ; Tue, 9 Mar 2010 03:41:02 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id E16183A687D for ; Tue, 9 Mar 2010 03:41:01 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id qzcz1d0031wpRvQ5Ezh7ZH; Tue, 09 Mar 2010 11:41:07 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta18.westchester.pa.mail.comcast.net with comcast id qzjK1d00D0yip6Y3ezjKwT; Tue, 09 Mar 2010 11:43:20 +0000 From: "Dave Nelson" To: References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 06:41:19 -0500 Message-ID: <57DFA72AF11044CCBA7C0A2FE8E3E59B@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acq/EgIo0oom0vauSLGgGUyWRNciWQAass7A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Tue, 09 Mar 2010 11:41:03 -0000 Randy Presuhn writes... > The editorial items in this list are fixed ... Thanks. > ... but I'm not sure what to do with the lengthy comments > later on. I suspect that the important points will be covered by the Security Considerations section text that I posted to the list yesterday to resolve ISSUE 2. From Pasi.Eronen@nokia.com Tue Mar 9 03:50:10 2010 Return-Path: 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 2C1333A68FB for ; Tue, 9 Mar 2010 03:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ErUvAM-g7zvX for ; Tue, 9 Mar 2010 03:50:09 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 0124D3A68F5 for ; Tue, 9 Mar 2010 03:50:08 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o29Bnhqs007019; Tue, 9 Mar 2010 13:50:08 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 13:50:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 13:50:03 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 9 Mar 2010 12:50:02 +0100 From: To: , Date: Tue, 9 Mar 2010 12:50:01 +0100 Thread-Topic: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq/WYoFX/QcESAARimsaqnjVnpXSwAJEgkA Message-ID: <808FD6E27AD4884E94820BC333B2DB77584836B953@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> <000c01cabed0$014ed8e0$0601a8c0@allison> <20100309072353.GC5024@elstar.local> In-Reply-To: <20100309072353.GC5024@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2010 11:50:03.0739 (UTC) FILETIME=[A7E9EAB0:01CABF7E] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Tue, 09 Mar 2010 11:50:10 -0000 Juergen Schoenwaelder wrote: > I am not an expert on (D)TLS regenotiation issues but I personally > believe we went over board with this. I consider the renegotiation > bug of TLS a temporary problem that can and likely will be cured > (see RFC 5746). Hence, we are making a bad decision to outlaw > renegotiation in general just because many deployed libraries today > are somewhat vulnerable. >=20 > I would prefer if the second paragraph in section 4.2 would be removed > and we would add discussion to the Security Considerations pointing > out the issue with "old" TLS code and the ways to work around things, > including the option to disable renegotiation if the (D)TLS library > used has not fixed the problem, e.g. via RFC 5746, or to verify the > same certificate has been used during renegotiation. Even if you implement RFC 5746, the current EoP (sections 5.3.1 and 5.3.2) won't work as-is if you allow renegotiation with different certificates. The changes needed look rather cumbersome, and in TLSTM,=20 if changing certificates is needed (e.g. certificate is renewed), opening a new TCP connection is cheap. So even if both ends implement RFC 5746, we still need the text about verifying that the same certificate has been used. Best regards, Pasi From ietfdbh@comcast.net Tue Mar 9 05:55:01 2010 Return-Path: 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 2DAC03A6864 for ; Tue, 9 Mar 2010 05:55:01 -0800 (PST) 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 Lx-usbsYM7aK for ; Tue, 9 Mar 2010 05:55:00 -0800 (PST) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id DBB153A6837 for ; Tue, 9 Mar 2010 05:54:59 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id r1CZ1d0011eYJf8A91v56k; Tue, 09 Mar 2010 13:55:05 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta19.emeryville.ca.mail.comcast.net with comcast id r1v31d0094G8Frs011v4Bx; Tue, 09 Mar 2010 13:55:05 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 08:55:01 -0500 Message-ID: <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq/LS1s5h0knmpcSdO/YKtj+eHUhwATZ+UgAAL6WJA= Subject: Re: [Isms] wg last call on the radius / vacm document: multiple 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: , X-List-Received-Date: Tue, 09 Mar 2010 13:55:01 -0000 Hi, Sorry, I'm bringing multiple issues together because they interact somewhat. 1) *** modularity police alert *** I agree the architecture versus implementation details get in the way in this instance. However, there are ways to work around those constraints. We are not allowed to ignore the architectural data flow constraints described by the ASIs - we cannot, for example, say that "TSM passes information" that architecturally it never gets from an ASI or from a process clearly identified as implementation-dependent. So any place the text says "the security model passes information" that it doesn't get from the ASIs, or explicitly from implementation dependent means should be eliminated. Assume the security model never sees or touches such information. Just say that the VACM extension gets the AAA attributes from a transport model in an implementation-dependent manner. 2) *** trusting modules *** Part of my response was about anthropomorphising(?) the subsystems/models in an SNMP engine. We don't "trust" one portion to deliver something unchanged. We design the protocol to deliver it unchanged. And if we make it implementation-dependent, then we should spell out the expectations that the attributes will be delivered unchanged between portions of the system. There is no question of "trust". There is a question of protocol requirements. 3) *** trusting humans *** There is a question of trust when it comes to human administrators. But we are designing protocols, not organizations. trust but verify - we trust both admins because they should be authenticated, and both the RADIUS server and the local operator are allowed to modify VACM tables. If the organization doesn't trust the local SNMP admin, then they should not be given permission to modify VACM tables. Done. We have to assume that all authenticated administrators who are given permission to modify VACM tables are trusted, whether they are RADIUS admins or SNMP admins. We don't allow one to override the other based on whether we trust this one more than the other. A RADIUS admin is not trusted more than an SNMP admin; an SNMP admin is not trusted more than a RADIUS admin. We need to assume both RADIUS and SNMP admins are trusted equally, since both have permission to modify VACM (security) tables. 4) *** the need for overrides *** We do need to make a decision about which should be allowed to override the other's configuration. The IETF OPS community has dealt with this issue before. We went to great lengths to discuss operator needs in the dilbert discussions, the "SNMP World Tour" to operator fora, and the IAB NM workshop. A great deal of that discussion was about policy-based configuration (mainly promoted by COPS-PR and academic research) and operator-driven configuration. The operators were quite clear - policy based configuration is a nice way to automate processes, but a programmatic policy server does not have the ability to recognize unusual circumstances and respond to them; a human has better capability to recognize when a policy is wrong for the current special circumstances, and a network management protocol using a policy-based approach MUST be able to be overridden by a human operator. COPS-PR had this capability. There was an on-off swicth in COPS-PR that allowed an operator to disable policy-based configuration. That allowed an operator to go in and modify the configuration, in order to troubleshoot a problem or stop an attack or whatever short-term problem needed to be solved. When COPS-PR was re-enabled, it would overwrite the changes made by the admin. This was found to be unacceptable by operators. 5) *** override cleanup *** Because an operator should be allowed to override policy-based config, and not be subsequently overridden by the policy manager, it is important that an operator clean up the static entries when he is done. But an operator in the middle of troubleshooting problems might easily forget to clean up a temporary override, and the device will end up being "out of policy". Therefore, I support Dave Nelson that we should have a counter/notification to alert an operator that a policy is being overridden by a static entry. But we need to make sure the notification doesn't get in the way of an operator doing their job. The organization may be able to eliminate the conflict between the trusted RADIUS server and the trusted local operator by changing the RADIUS policy to match the needed override settings. Maybe an organization woudl prefer that the conflict remain - the override might provide super-user privilieges, and the admins might prefer to not always work in superuser mode, and to have a warning when they are in super-user mode. Such a notification should probably be able to be throttled somehow. Whether that notificastion goes to the RADIUS admin or the SNNMP admin is a matter of RFC3413 configuration. They can presumably eliminate the notification if they want to, using the RFC3413 target and filter tables. I am not sure how to throttle the notification. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Tuesday, March 09, 2010 6:35 AM > To: isms@ietf.org > Subject: Re: [Isms] wg last call on the radius / vacm > document: ISSUE 4 > > Randy Presuhn writes (in response to Dave Harrington)... > > > > I don't agree with this text. I do not agree that RADIUS > is "at least > > > as trusted as the security administrator". The security > administrator > > > delegates authority to AAA to inform the SNMP entity about the > > > security policy. There is no assumption that the > transport security > > > model "can be trusted". > > > > Point taken. However, I'm not sure what to do with the > existing text. > > Does someone have a concrete text proposal? > > If you don't trust RADIUS or the system administrator who > configures its > polices, then don't use it. I think I see organizational > dynamics arguments > creeping into a protocol discussion. That's always a bad > sign, IMHO. If > there's bad organizational karma between the SNMP security > administrator and > the corporate RADIUS administrator, fight that out in the > personnel domain, > not the protocol domain, please. > > As to trusting the TSM (or TM), I think what's mean here is > that one trust > the implementation to pass along the information, including > User-Name and > Management-Policy-Id attributes and session start and end > events, that the > documents says it has to pass along. > > > > I am not checking the TSM, but I'm pretty sure it never > even sees the > > > group name provided by AAA. And IIRC, TSM knows nothing about > > > sessions; a session is something a transport model might > know about > > > that is tied to the transport involved. > > > > I'm not sure what to do here. We're dealing with > abstractions that may > > or may not have any recognizable counterpart in an implementation. > > Text would be welcomed. > > This is another situation where the architectural model is > simply getting in > the way. I had originally suggested we use one of those > "magic caches" as > we did for the TSM and TM work. It was suggested by others > on the list that > we leave the implementation detail more open ended for this > document. The > result is that it's not exactly clear how the information > flows, just that > it MUST flow. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From adonati@motorola.com Tue Mar 9 07:06:20 2010 Return-Path: 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 7B9903A697E for ; Tue, 9 Mar 2010 07:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fPWa+ey5m+ck for ; Tue, 9 Mar 2010 07:06:19 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6AFD53A6831 for ; Tue, 9 Mar 2010 07:06:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1268147182!41793458!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27694 invoked from network); 9 Mar 2010 15:06:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Mar 2010 15:06:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o29F6MDX008071 for ; Tue, 9 Mar 2010 08:06:22 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o29F6Mp9017882 for ; Tue, 9 Mar 2010 09:06:22 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o29F6LhG017879 for ; Tue, 9 Mar 2010 09:06:22 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Mar 2010 10:06:00 -0500 Message-ID: In-Reply-To: <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] wg last call on the radius / vacm document: multipleissues -> notification throttle Thread-Index: Acq/LS1s5h0knmpcSdO/YKtj+eHUhwATZ+UgAAL6WJAAAwjk0A== References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> From: "Donati Andrew-MGIA0477" To: "David Harrington" , "Dave Nelson" , X-CFilter-Loop: Reflected Subject: Re: [Isms] wg last call on the radius / vacm document: multipleissues -> notification throttle 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: , X-List-Received-Date: Tue, 09 Mar 2010 15:06:20 -0000 Hi, I believe that notification rate control should be discussed and possibly addressed by both the radius/vacm and the dtls-tm documents.=20 Some network devices have the ability to configure throttle threshold and throttle interval values globally. Typically, the default threshold is 100 (notifications) within an interval of 5 seconds. Below are a few suggested solutions we can consider. A. Add text in both documents stating that it is strongly recommended that the device support global throttle threshold/interval scalar objects for notifications to avoid the possibility of network administrators being overcome with a potential flood of messages.=20 B. Define throttle threshold/interval scalar mib objects for notifications specifically in the dtls and vacm/radius mibs to control the dtls and vacm/radius rate of notifications=20 respectively. - Andy Donati =20 DH> Therefore, I support Dave Nelson that we should have a counter/notification to DH> alert an operator that a policy is being overridden by a static entry. But we DH> need to make sure the notification doesn't get in the way of an operator doing DH> their job. DH> The organization may be able to eliminate the conflict between the trusted DH> RADIUS server and the trusted local operator by changing the RADIUS policy DH> to match the needed override settings. Maybe an organization would prefer DH> that the conflict remain - the override might provide super-user privileges, DH> and the admins might prefer to not always work in superuser mode, and to have DH> a warning when they are in super-user mode. Such a notification should probably DH> be able to be throttled somehow. Whether that notificastion goes to the RADIUS DH> admin or the SNNMP admin is a matter of RFC3413 configuration. They can presumably DH> eliminate the notification if they want to, using the DH> RFC3413 target and filter tables. I am not sure how to throttle the notification. =20 From dnelson@elbrysnetworks.com Tue Mar 9 07:41:58 2010 Return-Path: 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 2E02F3A6B98 for ; Tue, 9 Mar 2010 07:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Sg5v2a-MIMNm for ; Tue, 9 Mar 2010 07:41:48 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id B15E03A691A for ; Tue, 9 Mar 2010 07:41:47 -0800 (PST) Received: (qmail 4533 invoked from network); 9 Mar 2010 15:41:42 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 9 Mar 2010 15:41:42 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Mar 2010 10:41:42 -0500 References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document: multiple 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: , X-List-Received-Date: Tue, 09 Mar 2010 15:41:58 -0000 On Mar 9, 2010, at 8:55 AM, David Harrington wrote: > Just say that the VACM extension gets the AAA attributes from a > transport model in an implementation-dependent manner. Sounds good to me. > There is no question of "trust". There is a question of protocol > requirements. Agreed. Any "trust" of systems or software is implied by successful authentication of the principal. > We need to assume both RADIUS and SNMP admins are trusted equally, > since both have permission to modify VACM (security) tables. Agreed. Equally trusted. However, local information gets precedence over remote information. > Because an operator should be allowed to override policy-based config, > and not be subsequently overridden by the policy manager, it is > important that an operator clean up the static entries when he is > done. But an operator in the middle of troubleshooting problems might > easily forget to clean up a temporary override, and the device will > end up being "out of policy". Correct. > Therefore, I support Dave Nelson that we should have a > counter/notification to alert an operator that a policy is being > overridden by a static entry. But we need to make sure the > notification doesn't get in the way of an operator doing their job. Do you have a preference for either counters or notifications? Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrysnetworks.com dnelson@elbrysnetworks.com From j.schoenwaelder@jacobs-university.de Tue Mar 9 08:06:02 2010 Return-Path: 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 9B44E3A6924 for ; Tue, 9 Mar 2010 08:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 qSwIUwWkDDeW for ; Tue, 9 Mar 2010 08:06:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B51BE3A68F1 for ; Tue, 9 Mar 2010 08:06:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 941D8C0016; Tue, 9 Mar 2010 17:06:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FshQrJimD3v7; Tue, 9 Mar 2010 17:06:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1FFBC0034; Tue, 9 Mar 2010 17:05:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7509410C5791; Tue, 9 Mar 2010 17:05:52 +0100 (CET) Date: Tue, 9 Mar 2010 17:05:52 +0100 From: Juergen Schoenwaelder To: Donati Andrew-MGIA0477 Message-ID: <20100309160552.GB7057@elstar.local> Mail-Followup-To: Donati Andrew-MGIA0477 , David Harrington , Dave Nelson , "isms@ietf.org" References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document: multipleissues -> notification throttle X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 16:06:02 -0000 On Tue, Mar 09, 2010 at 04:06:00PM +0100, Donati Andrew-MGIA0477 wrote: > I believe that notification rate control should be discussed and > possibly addressed by both the radius/vacm and the dtls-tm > documents. So far, the only notifications we have are related to certificate validation errors in the dtls document. The dtls document has passed WG last calls. If you think the throttling of these notifications is necessary, you have to post an explicit IETF last call comment. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Mar 9 08:34:32 2010 Return-Path: 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 A143A3A6830 for ; Tue, 9 Mar 2010 08:34:32 -0800 (PST) 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=[AWL=0.000, 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 reigXz-sPNTF for ; Tue, 9 Mar 2010 08:34:31 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 7A8113A68E7 for ; Tue, 9 Mar 2010 08:34:31 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta11.emeryville.ca.mail.comcast.net with comcast id r1SQ1d0061HpZEsAB4WRZd; Tue, 09 Mar 2010 16:30:25 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta14.emeryville.ca.mail.comcast.net with comcast id r4ab1d0024G8Frs8a4abED; Tue, 09 Mar 2010 16:34:36 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer><0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> Date: Tue, 9 Mar 2010 11:34:33 -0500 Message-ID: <0c5f01cabfa6$678adab0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq/n/l+rNGTnNRGQ6WL+cvYc2FkrgABkPaQ Subject: Re: [Isms] wg last call on the radius / vacm document: multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 16:34:32 -0000 I prefer counters that are reported in notifications. Then an operator can choose use event-based or polling-based management. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Tuesday, March 09, 2010 10:42 AM > To: isms@ietf.org > Subject: Re: [Isms] wg last call on the radius / vacm > document: multipleissues > > On Mar 9, 2010, at 8:55 AM, David Harrington wrote: > > > Just say that the VACM extension gets the AAA attributes from a > > transport model in an implementation-dependent manner. > > Sounds good to me. > > > There is no question of "trust". There is a question of protocol > > requirements. > > Agreed. Any "trust" of systems or software is implied by successful > authentication of the principal. > > > We need to assume both RADIUS and SNMP admins are trusted equally, > > since both have permission to modify VACM (security) tables. > > Agreed. Equally trusted. However, local information gets > precedence > over remote information. > > > Because an operator should be allowed to override > policy-based config, > > and not be subsequently overridden by the policy manager, it is > > important that an operator clean up the static entries when he is > > done. But an operator in the middle of troubleshooting > problems might > > easily forget to clean up a temporary override, and the device will > > end up being "out of policy". > > Correct. > > > Therefore, I support Dave Nelson that we should have a > > counter/notification to alert an operator that a policy is being > > overridden by a static entry. But we need to make sure the > > notification doesn't get in the way of an operator doing their job. > > Do you have a preference for either counters or notifications? > > Regards, > > Dave > > David B. Nelson > > Elbrys Networks, Inc. > 282 Corporate Drive, Unit 1 > Portsmouth, NH 03801 > > +1.603.570.2636 > www.elbrysnetworks.com > dnelson@elbrysnetworks.com > > > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From randy_presuhn@mindspring.com Tue Mar 9 10:47:30 2010 Return-Path: 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 53A7F3A6A15 for ; Tue, 9 Mar 2010 10:47:30 -0800 (PST) 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 M06IHoLvaPUg for ; Tue, 9 Mar 2010 10:47:29 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 59BD83A6A08 for ; Tue, 9 Mar 2010 10:47:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FxbZ/1I7xJwhgB1E76DhSDVWfcNvLQPiIXRyJL5UdOzBwxuwWmFSOfhvVVDgB2LM; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.61] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Np4Sr-0002hq-FD for isms@ietf.org; Tue, 09 Mar 2010 13:47:33 -0500 Message-ID: <005a01cabfb9$29ba2340$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer><0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> <0c5f01cabfa6$678adab0$0202fea9@china.huawei.com> Date: Tue, 9 Mar 2010 10:48:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b408e0d1fb8a861410272d0ecc95b6d2dfc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.61 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 18:47:30 -0000 Hi - > From: "David Harrington" > To: "'David B. Nelson'" ; > Sent: Tuesday, March 09, 2010 8:34 AM > Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues > > I prefer counters that are reported in notifications. > Then an operator can choose use event-based or polling-based > management. But to be of any use at all, such a notification would also need to carry at least the SecurityModel and the SecurityName. It would probably better if it also carried both the old and the proposed values of vacmGroupName, in addition to the value of the counter (which I assume would *not* be indexed, and would thus increase according to the sum of all such events). Now for details: - would we notify in the case where the newly proposed value for vacmGroupName happens to be equal to the value that is already there? - relying on the snmpNotificationMIB to decide whether something goes out (or not) is the right thing to do, IMO, but it comes at a signficiant run-time cost, in that in a typical implementation architecture it will require all the notification payload to have been marshalled, if not actually encoded (in both SMUX and AgentX environments there will be PDUs flying around) and that this information will then be evaluated against the snmpNotifyFilterTable, and, for the selected targets, evaluated again against VACM. This can be a fair amount of work before the implementation reaches the decision that it "doesn't need to do anything." The counter-argument is that this case shouldl be rare, except during initial deployment of this software. - I think the "throttling" question isn't terribly important here. The maximum rate at which these could be generated is no greater than the maximum rate at which new sessions are accepted and authorized by RADIUS. The real problem would be experienced at an enterprise-wide notification sink when this service is initially deployed, due to the fan-in from large numbers of managed devices being polled with short-lived sessions. Throttling would be of no help in this scenario. Randy From dnelson@elbrysnetworks.com Tue Mar 9 11:10:38 2010 Return-Path: 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 B241E3A68F6 for ; Tue, 9 Mar 2010 11:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 L+eDhXC5L9f4 for ; Tue, 9 Mar 2010 11:10:37 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 0C5023A69FB for ; Tue, 9 Mar 2010 11:10:36 -0800 (PST) Received: (qmail 16305 invoked from network); 9 Mar 2010 19:10:40 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 9 Mar 2010 19:10:40 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-1--55651839 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Tue, 9 Mar 2010 14:10:40 -0500 References: X-Mailer: Apple Mail (2.936) Subject: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 19:10:38 -0000 --Apple-Mail-1--55651839 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Resending from my enrolled email address (this is starting to get old...). > From: "David B. Nelson" > Date: March 9, 2010 2:09:18 PM EST > To: isms@ietf.org > Subject: Re: [Isms] wg last call on the radius / vacm > document:multipleissues > > On Mar 9, 2010, at 1:48 PM, Randy Presuhn wrote: > >> - would we notify in the case where the newly proposed value for >> vacmGroupName >> happens to be equal to the value that is already there? > > I don't think the EOP anticipates any "newly proposed" values of > vacmGroupName. The only error case, in terms of a newly started > RADIUS-authorized session, is if there is not match among the > existing vacmGroupName entries. > >> - relying on the snmpNotificationMIB to decide whether something >> goes out (or not) >> is the right thing to do, IMO, but it comes at a signficiant run- >> time cost, in that in a >> typical implementation architecture it will require all the >> notification payload to have >> been marshalled, if not actually encoded (in both SMUX and AgentX >> environments >> there will be PDUs flying around) and that this information will >> then be evaluated >> against the snmpNotifyFilterTable, and, for the selected targets, >> evaluated again >> against VACM. This can be a fair amount of work before the >> implementation >> reaches the decision that it "doesn't need to do anything." The >> counter-argument >> is that this case shouldl be rare, except during initial >> deployment of this software. > > Right. > >> - I think the "throttling" question isn't terribly important here. >> The maximum rate at which >> these could be generated is no greater than the maximum rate at >> which new sessions are >> accepted and authorized by RADIUS. The real problem would be >> experienced at >> an enterprise-wide notification sink when this service is >> initially deployed, due to the >> fan-in from large numbers of managed devices being polled with >> short-lived sessions. >> Throttling would be of no help in this scenario. > > Yes. I can see the advantage of sending a particular notification > only once, but I assume (a) there is no mechanism to support that > concept, an (b) if there were, it would still require significant > work (and state) internally to make that decision. > > Regards, > > Dave > > David B. Nelson > > Elbrys Networks, Inc. > 282 Corporate Drive, Unit 1 > Portsmouth, NH 03801 > > +1.603.570.2636 > www.elbrys.com > dnelson@elbrys.com --Apple-Mail-1--55651839 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Resending from my enrolled = email address (this is starting to get old...).

From: = "David B. Nelson" <dnelson@elbrys.com>
=
Date: = March 9, 2010 2:09:18 PM EST
Subject: = Re: [Isms] wg last call on the radius / vacm = document:multipleissues

On Mar 9, 2010, at 1:48 PM, Randy Presuhn = wrote:

- would we notify in the case = where the newly proposed value for = vacmGroupName
=   happens to be equal to the value that is already = there?

I don't think the EOP anticipates any "newly = proposed" values of vacmGroupName.  The only error case, in terms = of a newly started RADIUS-authorized session, is if there is not match = among the existing vacmGroupName entries.

- relying on the snmpNotificationMIB to decide whether = something goes out (or not)
=   is the right thing to do, IMO, but it comes at a signficiant = run-time cost, in that in a
=   typical implementation architecture it will require all the = notification payload to have
=   been marshalled, if not actually encoded (in both SMUX and = AgentX environments
=   there will be PDUs flying around) and that this information = will then be evaluated
=   against the snmpNotifyFilterTable, and, for the selected = targets, evaluated again
=   against VACM.  This can be a fair amount of work before = the implementation
=   reaches the decision that it "doesn't need to do anything." =  The counter-argument
=   is that this case shouldl be rare, except during initial = deployment of this = software.

Right.

- = I think the "throttling" question isn't terribly important here. =  The maximum rate at which
=   these could be generated is no greater than the maximum = rate at which new sessions are
=   accepted and authorized by RADIUS.  The real problem = would be experienced at
=   an enterprise-wide notification sink when this service is = initially deployed, due to the
=   fan-in from large numbers of managed devices being polled = with short-lived sessions.
=   Throttling would be of no help in this = scenario.

Yes.  I can see the advantage of = sending a particular notification only once, but I assume (a) there is = no mechanism to support that concept, an (b) if there were, it would = still require significant work (and state) internally to make that = decision.

Regards,

Dave

David B. = Nelson

Elbrys Networks, Inc.
282 Corporate Drive, Unit = 1
Portsmouth, NH 03801

+1.603.570.2636
www.elbrys.com
dnelson@elbrys.com
= --Apple-Mail-1--55651839-- From randy_presuhn@mindspring.com Tue Mar 9 11:59:30 2010 Return-Path: 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 0AACE3A68AA for ; Tue, 9 Mar 2010 11:59:30 -0800 (PST) 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 VSeqnik+jT4H for ; Tue, 9 Mar 2010 11:59:29 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 20D003A67B6 for ; Tue, 9 Mar 2010 11:59:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Cx40LxQEcUhrPFuEQIDUPBZRGvOvdT1e6lsz+qCaS97bx8aC+Ug8gevw8jvwiPa+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.61] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Np5aX-0005uO-C9 for isms@ietf.org; Tue, 09 Mar 2010 14:59:33 -0500 Message-ID: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Tue, 9 Mar 2010 12:00:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4031774550eb70af4d87962210da31037c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.61 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 19:59:30 -0000 Hi - > From: "David B. Nelson" > To: > Sent: Tuesday, March 09, 2010 11:10 AM > Subject: [Isms] wg last call on the radius / vacm document:multipleissues ... > > I don't think the EOP anticipates any "newly proposed" values of > vacmGroupName. The only error case, in terms of a newly started > RADIUS-authorized session, is if there is not match among the > existing vacmGroupName entries. We're thinking about two very different cases. I was considering the case where the information from RADIUS corresponded to an existing entry in the vacmSecurityToGroup table. You're considering the case where (regardless of whether there is an existing entry in the vacmSecurityToGroupTable matching the SecurityModel and SecurityName pair) there is no entry in the vacmAccessTable with a matching value for the vacmGroupName index. I still do not think this latter case is an error condition at all - it certainly is not an error in a VACM configuration for this condition to exist. ... > >> - I think the "throttling" question isn't terribly important here. > >> The maximum rate at which > >> these could be generated is no greater than the maximum rate at > >> which new sessions are > >> accepted and authorized by RADIUS. The real problem would be > >> experienced at > >> an enterprise-wide notification sink when this service is > >> initially deployed, due to the > >> fan-in from large numbers of managed devices being polled with > >> short-lived sessions. > >> Throttling would be of no help in this scenario. > > > Yes. I can see the advantage of sending a particular notification > only once, but I assume (a) there is no mechanism to support that > concept, an (b) if there were, it would still require significant > work (and state) internally to make that decision. It's worse than that. The communication amongst the managed systems necessary to prevent such an amplification attack would be as bad or worse than the attack itself. In an enterprise with a large number of identically- configured devices, as each one is polled by a centralized NMS, the notification would be generated. Even if it happens only once, the security alarm sink might be overwhelmed by the deluge resulting when every device in the enterprise sends its one notification. (Worse still if, due to pathological configuration / implementation, RADIUS is consulted in setting up a transport for each of these notifications, which, by the way, could potentially result in another notification.) Randy From dnelson@elbrys.com Tue Mar 9 12:28:52 2010 Return-Path: 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 DD3703A6A22 for ; Tue, 9 Mar 2010 12:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 duacpdZLfHuG for ; Tue, 9 Mar 2010 12:28:50 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id C85BF3A6852 for ; Tue, 9 Mar 2010 12:28:49 -0800 (PST) Received: from source ([209.85.220.226]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS5avhkbTTV/s3KODNtmiVNVA6pY7a+xg@postini.com; Tue, 09 Mar 2010 12:28:55 PST Received: by mail-fx0-f226.google.com with SMTP id 26so1068848fxm.35 for ; Tue, 09 Mar 2010 12:28:54 -0800 (PST) Received: by 10.223.5.71 with SMTP id 7mr394656fau.48.1268166533661; Tue, 09 Mar 2010 12:28:53 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id g28sm545422fkg.58.2010.03.09.12.28.50 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 12:28:52 -0800 (PST) Message-Id: <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Tue, 9 Mar 2010 15:28:45 -0500 References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 20:28:53 -0000 On Mar 9, 2010, at 3:00 PM, Randy Presuhn wrote: > We're thinking about two very different cases. I was considering > the case > where the information from RADIUS corresponded to an existing entry > in the vacmSecurityToGroup table. You're gonna make me dig out the VACM RFC again, aren't you? ;-) You had written: >> - would we notify in the case where the newly proposed value for >> vacmGroupName >> happens to be equal to the value that is already there? OK. I'm confused. If the row exists, why would there be a need to create a new value of vacmGroupName in the vacmSecurityToGroupTable? Are you asking about the case where the *dynamically* provisioned value of group name changes? It certainly can, and that's not an error. The RADIUS server is allowed to change it's mind, or more accurately an system administrator may reconfigure its policy database at any time. On the other hand if there is a conflict with a *statically* configured group name, that comes down to the override case. > You're considering the case where (regardless of whether there is an > existing entry in the vacmSecurityToGroupTable matching the > SecurityModel > and SecurityName pair) there is no entry in the vacmAccessTable with a > matching value for the vacmGroupName index. Umm... yeah, that too. > I still do not think this latter case is an error condition at all - > it certainly is not an error in a VACM configuration for this > condition > to exist. Well, it's *certainly* a RADIUS error for the RADIUS server to provision conditional / limited access using a non-existent, and therefore unenforceable, policy name. Because of the behavior on the VACM end, it's not a security risk, but it's an error. Let's not consider the issues only from an SNMP-centric or a RADIUS-centric viewpoint, but rather consider how it all works as a system. Admittedly, this isn't a VACM error, but it is a RADIUS/VACM error. > It's worse than that. The communication amongst the managed systems > necessary to prevent such an amplification attack would be as bad or > worse > than the attack itself. I was only suggesting a behavior within the scope of a *single* notification originator. Filter out duplicates for a given User- Name / Management-Policy-Id pair from a single SNMP engine. > In an enterprise with a large number of identically-configured > devices, as > each one is polled by a centralized NMS, the notification would be > generated. Only if the "error" had occurred at each device, right? Well, it wasn't a serious suggestion... more like wishful thinking. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com From randy_presuhn@mindspring.com Tue Mar 9 13:14:34 2010 Return-Path: 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 6E5073A6A36 for ; Tue, 9 Mar 2010 13:14:34 -0800 (PST) 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 oqqg4xm8uTm9 for ; Tue, 9 Mar 2010 13:14:32 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 568143A69BD for ; Tue, 9 Mar 2010 13:14:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r9ScpQCVlgnszSm2BwHjWg2pFh7/I9WjR/YIL3361QZ3zE72e2u5doPvaPRq3wB0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.61] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Np6lA-0001Dr-Kr for isms@ietf.org; Tue, 09 Mar 2010 16:14:36 -0500 Message-ID: <001f01cabfcd$b5455060$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> Date: Tue, 9 Mar 2010 13:15:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b409335344e2f5682affd8a2d43e81cc4bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.61 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 21:14:34 -0000 Hi - > From: "David B. Nelson" > To: > Sent: Tuesday, March 09, 2010 12:28 PM > Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues > > On Mar 9, 2010, at 3:00 PM, Randy Presuhn wrote: > > > We're thinking about two very different cases. I was considering > > the case > > where the information from RADIUS corresponded to an existing entry > > in the vacmSecurityToGroup table. > > You're gonna make me dig out the VACM RFC again, aren't you? ;-) > > You had written: > > >> - would we notify in the case where the newly proposed value for > >> vacmGroupName > >> happens to be equal to the value that is already there? > > > OK. I'm confused. If the row exists, why would there be a need to > create a new value of vacmGroupName in the vacmSecurityToGroupTable? When the row (indexed by SecurityModel and SecurityName) in the vacmSecurityToGroupTable already exists, there are several sub-cases. (1) the row that's already there has a "volatile" StorageType. (Such a row was almost certainly created due to the RADIUS/VACM supplemental procedure, as when the user has more than one concurrent session open.) (1a) the new value of vacmGroupName is the same as what's already there - normal case, nothing needs to be done (1b) the new value of vacmGroupName is something different - this would happen if a user was assigned to a different group while a session was open, and the user opened yet another session. In this case, we update the vacmGroupName to the new value, since that is the most up-to-date policy information we have available. (1b.1) this new proposed value already shows up in the vacmAccessTable - normal case, no special handling required (1b.2) this new proposed value does not appear in the vacmAccessTable - we have differing opinions on whether this is a special case and whether any special handling would be required (2) the row that's already there does not have a "volatile" StorageType - current EOP treats this as a "do not update" situation. If we want to generate notifications, then we *might* want to distinguish (2a) the proposed value of vacmGroupName is the same as what's already there - does it really make sense to generate a notification in this case? There's an administratively configured policy that's the same as what RADIUS wants to impose. (2b) the proposed value of vacmGroupName is different from what's there (2b.1) this new proposed value already shows up in the vacmAccessTable (2b.2) this new proposed value does not appear in the vacmAccessTable I hope this breakdown makes it clearer how the various situations differ, and the granularity of notification that would be *possible*. What we as a WG need to figure out is what would actually be *useful*, and what would actually be *necessary*, in order to decide whether support for those notifications should be mandatory or optional. I'm not convinced that notifications for any of these cases are operationally necessary. I can see that there might be some operational regimes in which some of them might potentially be useful. So, if folks really think they need the notifications (and they should say which ones!) I could go along with adding them to the MIB module, but making support for them optional in the conformance material. > Are you asking about the case where the *dynamically* provisioned > value of group name changes? It certainly can, and that's not an > error. The RADIUS server is allowed to change it's mind, or more > accurately an system administrator may reconfigure its policy database > at any time. Yes. This corresponds to (1b) and (2b). > On the other hand if there is a conflict with a > *statically* configured group name, that comes down to the override > case. That's all of (2), potentially allowing a loophole (depending on your needs) for (2a). I can see arguments both for including and excluding the (2a) subcase. ... > > I still do not think this latter case is an error condition at all - > > it certainly is not an error in a VACM configuration for this > > condition > > to exist. > > Well, it's *certainly* a RADIUS error for the RADIUS server to > provision conditional / limited access using a non-existent, and > therefore unenforceable, policy name. Because of the behavior on the > VACM end, it's not a security risk, but it's an error. Let's not > consider the issues only from an SNMP-centric or a RADIUS-centric > viewpoint, but rather consider how it all works as a system. > Admittedly, this isn't a VACM error, but it is a RADIUS/VACM error. The problem is one of deployment / migration and existing practice. We both agree that it's a perfectly reasonable VACM configuration to assign a (SecurityModel,SecurityName) pair to a group (policy) called "NoAccessAllowed". Currently there's no motivation for the security administrator to take the extra step of creating a do-nothing entry in the vacmAccessTable just to say that this group can't do anything. Making this case into what you call a "RADIUS/VACM" error imposes a new requirement - the security administrator would need to create this extra do-nothing entry in the vacmAccessTable in order to keep the RADIUS/VACM integration from complaining. I'd rather avoid imposing any requirements on administrators unless they are actually *necessary* for good security or operational reasons. Randy From dnelson@elbrys.com Tue Mar 9 13:44:35 2010 Return-Path: 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 563693A6A4E for ; Tue, 9 Mar 2010 13:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 awpICRdzKVAN for ; Tue, 9 Mar 2010 13:44:33 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 2BB7D3A69A6 for ; Tue, 9 Mar 2010 13:44:33 -0800 (PST) Received: from source ([209.85.220.224]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS5bBRfHSFpj4QcIsNYZYHICqWELXIGI2@postini.com; Tue, 09 Mar 2010 13:44:38 PST Received: by mail-fx0-f224.google.com with SMTP id 24so6552116fxm.37 for ; Tue, 09 Mar 2010 13:44:37 -0800 (PST) Received: by 10.223.77.25 with SMTP id e25mr538833fak.23.1268171076699; Tue, 09 Mar 2010 13:44:36 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id 35sm11992101fkt.37.2010.03.09.13.44.34 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 13:44:35 -0800 (PST) Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <001f01cabfcd$b5455060$6801a8c0@oemcomputer> Content-Type: multipart/alternative; boundary=Apple-Mail-1--46423508 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Tue, 9 Mar 2010 16:44:28 -0500 References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 21:44:35 -0000 --Apple-Mail-1--46423508 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 9, 2010, at 4:15 PM, Randy Presuhn wrote: > When the row (indexed by SecurityModel and SecurityName) in the > vacmSecurityToGroupTable already exists, there are several sub-cases. > (1) the row that's already there has a "volatile" StorageType. > (Such a > row was almost certainly created due to the RADIUS/VACM > supplemental > procedure, as when the user has more than one concurrent > session open.) > (1a) the new value of vacmGroupName is the same as what's > already there > - normal case, nothing needs to be done > (1b) the new value of vacmGroupName is something different - > this would > happen if a user was assigned to a different group > while a session > was open, and the user opened yet another session. In > this case, we > update the vacmGroupName to the new value, since that > is the most > up-to-date policy information we have available. > (1b.1) this new proposed value already shows up in > the vacmAccessTable > - normal case, no special handling required > (1b.2) this new proposed value does not appear in the > vacmAccessTable > - we have differing opinions on whether > this is a special case and > whether any special handling would be > required See my comment below. It depends on whether the RADIUS server (or its administrator) had a reasonable expectation of gaining meaningful access using that group name. > (2) the row that's already there does not have a "volatile" > StorageType - > current EOP treats this as a "do not update" situation. If > we want to generate > notifications, then we *might* want to distinguish > (2a) the proposed value of vacmGroupName is the same as > what's already there > - does it really make sense to generate a notification > in this case? No. I think it does not make sense. There is no "error" if there is no "conflict". > There's an administratively configured policy that's > the same as what > RADIUS wants to impose. Sure. > (2b) the proposed value of vacmGroupName is different from > what's there > (2b.1) this new proposed value already shows up in > the vacmAccessTable > (2b.2) this new proposed value does not appear in the > vacmAccessTable I don't think that 2b.1 and 2b.2 make a big difference, both are conflicts, but it *might* be interesting to report, because it could, for example, be an indication of a typo-error in manually configuring the vacmSecurityToGroupTable. Or it might not. > I hope this breakdown makes it clearer how the various situations > differ, and the > granularity of notification that would be *possible*. What we as a > WG need to figure > out is what would actually be *useful*, and what would actually be > *necessary*, > in order to decide whether support for those notifications should be > mandatory or optional. Right. > I'm not convinced that notifications for any of these cases are > operationally necessary. > I can see that there might be some operational regimes in which some > of them might potentially > be useful. So, if folks really think they need the notifications > (and they should say which ones!) > I could go along with adding them to the MIB module, but making > support for them optional > in the conformance material. Well, if vendors choose to skip implementation and customers have a rough patch during migration because of that, it could certainly become a product differentiator. > We both agree that it's a perfectly reasonable VACM configuration > to assign a (SecurityModel,SecurityName) pair to a group (policy) > called "NoAccessAllowed". Currently there's no motivation for the > security > administrator to take the extra step of creating a do-nothing entry > in the vacmAccessTable just to say that this group can't do anything. > Making this case into what you call a "RADIUS/VACM" error imposes > a new requirement - the security administrator would need to create > this extra do-nothing entry in the vacmAccessTable in order to keep > the RADIUS/VACM integration from complaining. The RADIUS server will never, if configured correctly, grant SNMP service authorization, via the RFC 5608 mechanism, but deny MIB database access by provisioning a "dead-end" access control policy. The likelihood that a *valid* RADIUS policy id would be named "NoAccessAllowed" is very (very) slim. > I'd rather avoid imposing any requirements on administrators unless > they > are actually *necessary* for good security or operational reasons. Sure, but a collision with the intentional "NoAccessAllowed" group name is not something that I think we practically need to worry about. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com --Apple-Mail-1--46423508 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 9, 2010, at = 4:15 PM, Randy Presuhn wrote:

When = the row (indexed by SecurityModel and SecurityName) in = the
vacmSecurityToGroupTable already exists, there are several = sub-cases.
  (1) the row that's already there has a = "volatile" StorageType.  (Such a
=        row was almost certainly = created due to the RADIUS/VACM supplemental
=        procedure, as when the user = has more than one concurrent session open.)
=        (1a) the new value of = vacmGroupName is the same as what's already there
=             &n= bsp; - normal case, nothing needs to be done
=        (1b) the new value of = vacmGroupName is something different - this would
=             &n= bsp;  happen if a user was assigned to a different group while = a session
=             &n= bsp;  was open, and the user opened yet another = session. In this case, we
=             &n= bsp;  update the vacmGroupName to the new value, since that is = the most
=             &n= bsp;  up-to-date policy information we have available.
=             &n= bsp;  (1b.1) this new proposed value already shows up in the = vacmAccessTable
=             &n= bsp;           &nbs= p; - normal case, no special handling required
=             &n= bsp;  (1b.2) this new proposed value does not appear in the = vacmAccessTable
=             &n= bsp;           &nbs= p;- we have differing opinions on whether this is a special case and
=             &n= bsp;           &nbs= p;  whether any special handling would be = required

See my comment below. =  It depends on whether the RADIUS server (or its administrator) had = a reasonable expectation of gaining meaningful access using that group = name.

 (2) the row that's = already there does not have a "volatile" StorageType -
=        current EOP treats this as a = "do not update" situation.  If we want to generate
=        notifications, then we *might* = want to distinguish
       (2a) =  the proposed value of vacmGroupName is the same as what's already = there
=             &n= bsp; - does it really make sense to generate a notification in this = case?

No.  I think it does = not make sense.  There is no "error" if there is no = "conflict".

     =          There's an administratively = configured policy that's the same as what
             =  RADIUS wants to = impose.

Sure.

       (2b) = the proposed value of vacmGroupName is different from what's there
=             &n= bsp; (2b.1)  this new proposed value already shows up in the = vacmAccessTable
=             &n= bsp; (2b.2)  this new proposed value does not appear in the = vacmAccessTable

I don't think that 2b.1 and 2b.2 make a big difference, both are = conflicts, but it *might* be interesting to report, because it could, = for example, be an indication of a typo-error in manually configuring = the vacmSecurityToGroupTable.  Or it might = not.

I hope this breakdown makes = it clearer how the various situations differ, and the
granularity of = notification that would be *possible*.  What we as a WG need to = figure
out is what would actually be *useful*, and what would = actually be *necessary*,
in order to decide whether support for those = notifications should be mandatory or = optional.

Right.

I'm not convinced that notifications for any of these = cases are operationally necessary.
I can see that there might be some = operational regimes in which some of them might potentially
be = useful.  So, if folks really think they need the notifications (and = they should say which ones!)
I could go along with adding them to the = MIB module, but making support for them optional
in the conformance = material.

Well, if vendors = choose to skip implementation and customers have a rough patch during = migration because of that, it could certainly become a product = differentiator. 

We both = agree that it's a perfectly reasonable VACM configuration
to assign a = (SecurityModel,SecurityName) pair to a group (policy)
called = "NoAccessAllowed". Currently there's no motivation for the = security
administrator to take the extra step of creating a = do-nothing entry
in the vacmAccessTable just to say that this group = can't do anything.
Making this case into what you call a = "RADIUS/VACM" error imposes
a new requirement - the security = administrator would need to create
this extra do-nothing entry in the = vacmAccessTable in order to keep
the RADIUS/VACM integration from = complaining.

The RADIUS server = will never, if configured correctly, grant SNMP service authorization, = via the RFC 5608 mechanism, but deny MIB database access by provisioning = a "dead-end" access control policy.  The likelihood that a *valid* = RADIUS policy id would be named "NoAccessAllowed" is very (very) = slim.

 I'd rather = avoid imposing any requirements on administrators unless = they
 are = actually *necessary* for good security or operational = reasons.

Sure, but a collision = with the intentional "NoAccessAllowed" group name is not something that = I think we practically need to worry about.

Regards,

Dave

David B. Nelson

Elbrys Networks, = Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH = 03801

+1.603.570.2636






= --Apple-Mail-1--46423508-- From ietfdbh@comcast.net Tue Mar 9 14:10:47 2010 Return-Path: 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 4CE243A69A6 for ; Tue, 9 Mar 2010 14:10:47 -0800 (PST) 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=[AWL=0.000, 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 PfX87oKLH4GJ for ; Tue, 9 Mar 2010 14:10:45 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 36AB43A6A98 for ; Tue, 9 Mar 2010 14:10:38 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta03.emeryville.ca.mail.comcast.net with comcast id r4v01d00C0EPchoA3AAjWV; Tue, 09 Mar 2010 22:10:43 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta01.emeryville.ca.mail.comcast.net with comcast id rAAh1d00D4G8Frs8MAAiW0; Tue, 09 Mar 2010 22:10:43 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 17:10:40 -0500 Message-ID: <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001f01cabfcd$b5455060$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq/zY5LjhnqHApMRzGb5Z+c0MApVwABfWEQ Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 22:10:47 -0000 my thinking was only to alert an operator that they had a statically configured rule that conflicts with a RADIUS rule. But I am fine with not using a notification to report that case, given the costs you point out. Your email points out the various possible conflicts, and it is unclear which would be useful. You have obviously spent much more time than I thinking this through. Could we summarize all RADIUS-local conflicts into one counter, and leave it to operators to figure out the conflict? If that still doesn't work, then I recommend wording in the doc that says implementers should consider using syslog to record the details of any conflicts so security admins can track down the policy-vs-local conflicts. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Tuesday, March 09, 2010 4:16 PM > To: isms@ietf.org > Subject: Re: [Isms] wg last call on the radius / vacm > document:multipleissues > > Hi - > > > From: "David B. Nelson" > > To: > > Sent: Tuesday, March 09, 2010 12:28 PM > > Subject: Re: [Isms] wg last call on the radius / vacm > document:multipleissues > > > > > On Mar 9, 2010, at 3:00 PM, Randy Presuhn wrote: > > > > > We're thinking about two very different cases. I was > considering > > > the case > > > where the information from RADIUS corresponded to an > existing entry > > > in the vacmSecurityToGroup table. > > > > You're gonna make me dig out the VACM RFC again, aren't you? ;-) > > > > You had written: > > > > >> - would we notify in the case where the newly proposed > value for > > >> vacmGroupName > > >> happens to be equal to the value that is already there? > > > > > > OK. I'm confused. If the row exists, why would there be a > need to > > create a new value of vacmGroupName in the vacmSecurityToGroupTable? > > When the row (indexed by SecurityModel and SecurityName) in the > vacmSecurityToGroupTable already exists, there are several sub-cases. > (1) the row that's already there has a "volatile" > StorageType. (Such a > row was almost certainly created due to the > RADIUS/VACM supplemental > procedure, as when the user has more than one > concurrent session open.) > (1a) the new value of vacmGroupName is the same as > what's already there > - normal case, nothing needs to be done > (1b) the new value of vacmGroupName is something > different - this would > happen if a user was assigned to a different > group while a session > was open, and the user opened yet another > session. In this case, we > update the vacmGroupName to the new value, > since that is the most > up-to-date policy information we have available. > (1b.1) this new proposed value already shows > up in the vacmAccessTable > - normal case, no special handling required > (1b.2) this new proposed value does not > appear in the vacmAccessTable > - we have differing opinions on > whether this is a special case and > whether any special handling > would be required > (2) the row that's already there does not have a "volatile" > StorageType - > current EOP treats this as a "do not update" > situation. If we want to generate > notifications, then we *might* want to distinguish > (2a) the proposed value of vacmGroupName is the same > as what's already there > - does it really make sense to generate a > notification in this case? There's > an administratively configured policy that's > the same as what RADIUS wants > to impose. > (2b) the proposed value of vacmGroupName is different > from what's there > (2b.1) this new proposed value already shows > up in the vacmAccessTable > (2b.2) this new proposed value does not > appear in the vacmAccessTable > > > I hope this breakdown makes it clearer how the various > situations differ, and the > granularity of notification that would be *possible*. What > we as a WG need to figure > out is what would actually be *useful*, and what would > actually be *necessary*, > in order to decide whether support for those notifications > should be mandatory or optional. > > I'm not convinced that notifications for any of these cases > are operationally necessary. > I can see that there might be some operational regimes in > which some of them might potentially > be useful. So, if folks really think they need the > notifications (and they should say which ones!) > I could go along with adding them to the MIB module, but > making support for them optional > in the conformance material. > > > Are you asking about the case where the *dynamically* provisioned > > value of group name changes? It certainly can, and that's not an > > error. The RADIUS server is allowed to change it's mind, or more > > accurately an system administrator may reconfigure its > policy database > > at any time. > > Yes. This corresponds to (1b) and (2b). > > > On the other hand if there is a conflict with a > > *statically* configured group name, that comes down to the > override > > case. > > That's all of (2), potentially allowing a loophole (depending > on your needs) > for (2a). I can see arguments both for including and > excluding the (2a) subcase. > > ... > > > I still do not think this latter case is an error > condition at all - > > > it certainly is not an error in a VACM configuration for this > > > condition > > > to exist. > > > > Well, it's *certainly* a RADIUS error for the RADIUS server to > > provision conditional / limited access using a non-existent, and > > therefore unenforceable, policy name. Because of the > behavior on the > > VACM end, it's not a security risk, but it's an error. Let's not > > consider the issues only from an SNMP-centric or a RADIUS-centric > > viewpoint, but rather consider how it all works as a system. > > Admittedly, this isn't a VACM error, but it is a RADIUS/VACM error. > > The problem is one of deployment / migration and existing practice. > > We both agree that it's a perfectly reasonable VACM configuration > to assign a (SecurityModel,SecurityName) pair to a group (policy) > called "NoAccessAllowed". Currently there's no motivation for > the security > administrator to take the extra step of creating a do-nothing entry > in the vacmAccessTable just to say that this group can't do anything. > Making this case into what you call a "RADIUS/VACM" error imposes > a new requirement - the security administrator would need to create > this extra do-nothing entry in the vacmAccessTable in order to keep > the RADIUS/VACM integration from complaining. I'd rather avoid > imposing any requirements on administrators unless they are actually > *necessary* for good security or operational reasons. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From randy_presuhn@mindspring.com Tue Mar 9 14:38:02 2010 Return-Path: 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 3AEA83A6A14 for ; Tue, 9 Mar 2010 14:38:02 -0800 (PST) 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=[AWL=0.000, 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 JVRS4mlOn3ya for ; Tue, 9 Mar 2010 14:38:01 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id EC2AD3A6AD9 for ; Tue, 9 Mar 2010 14:37:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=H+dQMKLkqnWWmHVErkhu6AFJclEVSpK7cuE059P5l8LPvr/UvxiXbkoroLBTmKZI; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.61] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Np83s-00015p-DM for isms@ietf.org; Tue, 09 Mar 2010 17:38:00 -0500 Message-ID: <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> Date: Tue, 9 Mar 2010 14:39:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4098e578bf9d2ce27d7b992ac160891cd5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.61 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 22:38:02 -0000 Hi - Trying to take into account both Davids' comments, I think it might make sense to re-factor slightly. But first I think we need to figure out a few corner cases: When the row (indexed by SecurityModel and SecurityName) in the vacmSecurityToGroupTable already exists, there are several sub-cases. (1) the row that's already there has a "volatile" StorageType. (Such a row was almost certainly created due to the RADIUS/VACM supplemental procedure, as when the user has more than one concurrent session open.) (1a) the new value of vacmGroupName is the same as what's already there - normal case, nothing needs to be done *** DO WE CHECK WHETHER THE EXISTING vacmGroupName corresponds to an entry in the vacmAccessTable, and notify if it does not, just as in (1b.2)? (The security administrator could have deleted an entry in the vacmAccessTable since the last time we checked.) *** (1b) the new value of vacmGroupName is something different - this would happen if a user was assigned to a different group while a session was open, and the user opened yet another session. In this case, we update the vacmGroupName to the new value, since that is the most up-to-date policy information we have available. (1b.1) this new proposed value already shows up in the vacmAccessTable - normal case, no special handling required (1b.2) this new proposed value does not appear in the vacmAccessTable *** this is one of the cases for which a notification is needed, right? *** (2) the row that's already there does not have a "volatile" StorageType - current EOP treats this as a "do not update" situation. *** My understanding is that there is NOT a perceived need to categorically count / notify condition (2) If we want to generate notifications, then we *might* want to distinguish (2a) the proposed value of vacmGroupName is the same as what's already there - does it really make sense to generate a notification in this case? There's an administratively configured policy that's the same as what RADIUS wants to impose. *** do we want to nonetheless check whether there's a matching vacmAcessEntry, as in (2b.1 / 2b.2), and notify if there is not? *** (2b) the proposed value of vacmGroupName is different from what's there *** my understanding is that there is a perceived need to notify on (2b) *** (2b.1) this new proposed value already shows up in the vacmAccessTable (2b.2) this new proposed value does not appear in the vacmAccessTable *** do we also want to notify on this condition? *** I could see describing it in terms of two notifications: - extVacmQuestionableGroupReference - whenever extVacmGroupName is assigned a value which doesn't reference something in the vacmAccessTable - extVacmAttemptedUpdateConflict - whenever we *don't* update the vacmSecurityToGroupTable because the entry in question isn't "volatile" and "active". I'm not so sure as David about the extVacmAttemptedUpdateConflict in the sub-case where the vacmGroupName would be unchanged. While it's true that this would be a policy no-op, on the other hand I think it *does* indicate that something is messed up, because if that user is later assigned to a different group in RADIUS, it will *become* an error. Randy From d.b.nelson@comcast.net Tue Mar 9 19:49:26 2010 Return-Path: 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 12B493A681A for ; Tue, 9 Mar 2010 19:49:26 -0800 (PST) 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 BUW7PaAt3LVC for ; Tue, 9 Mar 2010 19:49:25 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id D3FAA3A67E1 for ; Tue, 9 Mar 2010 19:49:24 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id rCEL1d00P17dt5G5DFpV2b; Wed, 10 Mar 2010 03:49:29 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta13.westchester.pa.mail.comcast.net with comcast id rFpV1d0050yip6Y3ZFpVSR; Wed, 10 Mar 2010 03:49:29 +0000 From: "Dave Nelson" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com><001f01cabfcd$b5455060$6801a8c0@oemcomputer><0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 22:49:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acq/2TKHLZVykiaRRWOS9dc0nbEuNQAKZmww X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Wed, 10 Mar 2010 03:49:26 -0000 Randy Presuhn writes... > When the row (indexed by SecurityModel and SecurityName) in the > vacmSecurityToGroupTable already exists, there are several sub-cases. > (1) the row that's already there has a "volatile" StorageType. (Such a > row was almost certainly created due to the RADIUS/VACM > supplemental procedure, as when the user has more than one > concurrent session open.) > (1a) the new value of vacmGroupName is the same as what's already > there > - normal case, nothing needs to be done > *** DO WE CHECK WHETHER THE EXISTING vacmGroupName > corresponds to an entry in the vacmAccessTable, and notify > if it does not, just as in (1b.2)? (The security > administrator could have deleted an > entry in the vacmAccessTable since the last time we > checked.) *** I suppose due diligence would suggest that we do check. > (1b) the new value of vacmGroupName is something different > - this would happen if a user was assigned to a different > group while a session was open, and the user opened yet > another session. In this case, we update the vacmGroupName > to the new value, since that is the most > up-to-date policy information we have available. > (1b.1) this new proposed value already shows up in the > vacmAccessTable > - normal case, no special handling required > (1b.2) this new proposed value does not appear in the > vacmAccessTable > *** this is one of the cases for which a > notification is needed, right? *** Yes. > (2) the row that's already there does not have a "volatile" StorageType > - current EOP treats this as a "do not update" situation. > *** My understanding is that there is NOT a perceived need to > categorically count / notify condition (2) Only in the case of conflicts. > If we want to generate notifications, then we *might* want > to distinguish > (2a) the proposed value of vacmGroupName is the same as what's > already there > - does it really make sense to generate a notification in > this case? There's an administratively configured policy > that's the same as what RADIUS wants to impose. > *** do we want to nonetheless check whether there's a matching > vacmAcessEntry, as in (2b.1 / 2b.2), and notify if there is > not?*** Again, due diligence suggests that we might want to do so. > (2b) the proposed value of vacmGroupName is different from what's > there > *** my understanding is that there is a perceived need to > notify on (2b) *** Yes. > (2b.1) this new proposed value already shows up in the > vacmAccessTable > (2b.2) this new proposed value does not appear in the > vacmAccessTable > *** do we also want to notify on this condition? *** I think so. > I could see describing it in terms of two notifications: > > - extVacmQuestionableGroupReference - whenever extVacmGroupName is > assigned a value which doesn't reference something in the > vacmAccessTable > - extVacmAttemptedUpdateConflict - whenever we *don't* update > the vacmSecurityToGroupTable because the entry in question isn't > "volatile" and "active". I think that basically covers it. > I'm not so sure as David about the extVacmAttemptedUpdateConflict in the > sub-case where the vacmGroupName would be unchanged. While it's true > that this would be a policy no-op, on the other hand I think it *does* > indicate that something is messed up, because if that user is later > assigned to a different group in RADIUS, it will *become* an error. Well, let's report it when it actually becomes an error. From randy_presuhn@mindspring.com Tue Mar 9 21:06:51 2010 Return-Path: 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 5C2E93A6B4A for ; Tue, 9 Mar 2010 21:06:51 -0800 (PST) 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 YvmsMAe1Rdzk for ; Tue, 9 Mar 2010 21:06:50 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 751D83A67D9 for ; Tue, 9 Mar 2010 21:06:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=U6kLCinvTP1Nsz2jtyIEKfp0Pfi/cFUh+zbHP7SAZuGFMhSUlm1aPU198ea/kz2N; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.49.205] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NpE8E-0002No-OS for isms@ietf.org; Wed, 10 Mar 2010 00:06:55 -0500 Message-ID: <002e01cac00f$b0523360$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com><001f01cabfcd$b5455060$6801a8c0@oemcomputer><0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com><001401cabfd9$5997a7c0$6801a8c0@oemcomputer> Date: Tue, 9 Mar 2010 21:08:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40261104c4c52bfcb0153cfa0740462da1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.49.205 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Wed, 10 Mar 2010 05:06:51 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Tuesday, March 09, 2010 7:49 PM > Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues ... > > I'm not so sure as David about the extVacmAttemptedUpdateConflict in the > > sub-case where the vacmGroupName would be unchanged. While it's true > > that this would be a policy no-op, on the other hand I think it *does* > > indicate that something is messed up, because if that user is later > > assigned to a different group in RADIUS, it will *become* an error. > > Well, let's report it when it actually becomes an error. While I can appreciate the reasoning, doing it this way (special-casing the case where the "new" policy is the same as the existing one), it will make both the specification and the implementation *slightly* more complex. (It changes a "whenever" to a "whenever... unless".) I think I understand what the Davids want well enough to craft some specific text. I'll try to get that done Wednesday morning. Randy From dnelson@elbrys.com Mon Mar 8 05:46:55 2010 Return-Path: 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 707163A6957 for ; Mon, 8 Mar 2010 05:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HhT11saukWOv for ; Mon, 8 Mar 2010 05:46:54 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 899D33A6995 for ; Mon, 8 Mar 2010 05:46:53 -0800 (PST) Received: from source ([209.85.220.224]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKS5T/0SkHQe+hRkgiStVE7lo/dk/Q4K3A@postini.com; Mon, 08 Mar 2010 05:46:58 PST Received: by mail-fx0-f224.google.com with SMTP id 24so3411911fxm.17 for ; Mon, 08 Mar 2010 05:46:57 -0800 (PST) Received: by 10.223.7.4 with SMTP id b4mr5533897fab.102.1268056015530; Mon, 08 Mar 2010 05:46:55 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id 13sm2908857fxm.2.2010.03.08.05.46.53 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 05:46:54 -0800 (PST) Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <001f01cabd66$54668840$6801a8c0@oemcomputer> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Mon, 8 Mar 2010 08:46:46 -0500 References: <001f01cabd66$54668840$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 10 Mar 2010 08:58:56 -0800 Subject: Re: [Isms] RADIUS/VACM - do we need to talk about tmStateReference? 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: , X-List-Received-Date: Mon, 08 Mar 2010 13:46:55 -0000 On Mar 6, 2010, at 2:50 PM, Randy Presuhn wrote: > 1. Is there really any need to talk about the tmStateReference > cache? Not strictly speaking. It is necessary to bind the session in the Transport Model to the dynamically created rows in the extVacmSecurityToGropTable and the vacmSecurityToGroupTable. Such a session identifier is described in Section 7.2, et seq. The mention of tmStateReference was originally added to suggest one way of maintaining that required binding. Specifying the requirements of the binding, without suggesting a specific implementation is sufficient. > 2. Is there a need for the RFC 5590 reference to be normative? Is > it needed at all? It probably doesn't need to be normative. On the other hand, the methods described in this document are *only* applicable when a Secure Transport Model is also in use, so it would seem reasonable to keep it as an informative reference. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com From dnelson@elbrys.com Mon Mar 8 05:57:11 2010 Return-Path: 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 159FC3A690C for ; Mon, 8 Mar 2010 05:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2TNX5zmyQonP for ; Mon, 8 Mar 2010 05:57:09 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id 5F3803A683E for ; Mon, 8 Mar 2010 05:57:09 -0800 (PST) Received: from source ([209.85.220.225]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKS5UCOYAyOf9JrjJY0y+CQsaxP5DsXzQW@postini.com; Mon, 08 Mar 2010 05:57:13 PST Received: by mail-fx0-f225.google.com with SMTP id 25so2461552fxm.27 for ; Mon, 08 Mar 2010 05:57:13 -0800 (PST) Received: by 10.223.62.207 with SMTP id y15mr5768984fah.92.1268056631841; Mon, 08 Mar 2010 05:57:11 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id 18sm8594725fkq.4.2010.03.08.05.57.09 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 05:57:10 -0800 (PST) Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <002501cabd67$86cacfc0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Mon, 8 Mar 2010 08:57:07 -0500 References: <002501cabd67$86cacfc0$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 10 Mar 2010 08:58:56 -0800 Subject: Re: [Isms] RADIUS/VACM - normative reference to RFC 5591? 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: , X-List-Received-Date: Mon, 08 Mar 2010 13:57:11 -0000 On Mar 6, 2010, at 2:59 PM, Randy Presuhn wrote: > 3. Does the reference to RFC 5591 need to be normative? > > One of the surprising things about the evolution of the > RADIUS/VACM integration is that all the references to > RFC 5591 come very close to being "for examples", rather > than clear normative references. This is a consequence > of our decision to describe this integration in a way > that would permit its use with other transports / security > models. I'm a little less optimistic about our ability to "future-proof" this document, in the traditional fashion of the strongly modular SNMP architecture. It's quite possible that some other transport and security models could be used with AAA-provisioned access. On the other hand, given the poor modularity properties of the original Security Subsystem architecture, which really only supports locally- based models such as USM, I would prefer to avoid making overly general statements, in the absence of time to think out the relevant details and specific text to review. > Indeed, even the title has become somewhat misleading, > since RADIUS is just one example of an AAA service that > could be supported. Um... Well, I'm only aware of RADIUS, Diameter and TACACS as potential AAA candidates. Diameter inherits RADIUS attributes via its NAS Application, so that leaves only TACACS unconsidered. For the reasons articulated above, I would hesitate to make overly general assertions that might come back to haunt us, when someone actually tries to undertake a particular extension of this work. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com From dnelson@elbrys.com Tue Mar 9 11:09:30 2010 Return-Path: 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 E30D53A69CE for ; Tue, 9 Mar 2010 11:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Fk1jwvZRCeU9 for ; Tue, 9 Mar 2010 11:09:30 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 850AA3A6952 for ; Tue, 9 Mar 2010 11:09:29 -0800 (PST) Received: from source ([209.85.220.216]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKS5ac63GcMK0CXSoqXfWEPbOKiJBM3/u6@postini.com; Tue, 09 Mar 2010 11:09:34 PST Received: by mail-fx0-f216.google.com with SMTP id 8so187040fxm.25 for ; Tue, 09 Mar 2010 11:09:31 -0800 (PST) Received: by 10.223.143.82 with SMTP id t18mr269956fau.52.1268161769542; Tue, 09 Mar 2010 11:09:29 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id e17sm11697345fke.57.2010.03.09.11.09.28 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 11:09:28 -0800 (PST) Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <005a01cabfb9$29ba2340$6801a8c0@oemcomputer> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Tue, 9 Mar 2010 14:09:18 -0500 References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer><0c0f01cabf90$1e5233e0$0202fea9@china.huawei.com> <0c5f01cabfa6$678adab0$0202fea9@china.huawei.com> <005a01cabfb9$29ba2340$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 10 Mar 2010 08:58:56 -0800 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Tue, 09 Mar 2010 19:09:31 -0000 On Mar 9, 2010, at 1:48 PM, Randy Presuhn wrote: > - would we notify in the case where the newly proposed value for > vacmGroupName > happens to be equal to the value that is already there? I don't think the EOP anticipates any "newly proposed" values of vacmGroupName. The only error case, in terms of a newly started RADIUS-authorized session, is if there is not match among the existing vacmGroupName entries. > - relying on the snmpNotificationMIB to decide whether something > goes out (or not) > is the right thing to do, IMO, but it comes at a signficiant run- > time cost, in that in a > typical implementation architecture it will require all the > notification payload to have > been marshalled, if not actually encoded (in both SMUX and AgentX > environments > there will be PDUs flying around) and that this information will > then be evaluated > against the snmpNotifyFilterTable, and, for the selected targets, > evaluated again > against VACM. This can be a fair amount of work before the > implementation > reaches the decision that it "doesn't need to do anything." The > counter-argument > is that this case shouldl be rare, except during initial > deployment of this software. Right. > - I think the "throttling" question isn't terribly important here. > The maximum rate at which > these could be generated is no greater than the maximum rate at > which new sessions are > accepted and authorized by RADIUS. The real problem would be > experienced at > an enterprise-wide notification sink when this service is > initially deployed, due to the > fan-in from large numbers of managed devices being polled with > short-lived sessions. > Throttling would be of no help in this scenario. Yes. I can see the advantage of sending a particular notification only once, but I assume (a) there is no mechanism to support that concept, an (b) if there were, it would still require significant work (and state) internally to make that decision. Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com From randy_presuhn@mindspring.com Wed Mar 10 11:52:25 2010 Return-Path: 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 A9B113A6A11 for ; Wed, 10 Mar 2010 11:52:25 -0800 (PST) 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 flYktrNoIc-R for ; Wed, 10 Mar 2010 11:52:24 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id AFB8F3A69FA for ; Wed, 10 Mar 2010 11:52:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pgWgsdhotMh5OBBBQAoiK0BXKAP9Zt3iVAcZPdPC61qOOpygBjs83XETkn0eax/9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.224.223] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NpRx7-0006f3-Cw for isms@ietf.org; Wed, 10 Mar 2010 14:52:21 -0500 Message-ID: <000a01cac08b$624bc380$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com><001f01cabfcd$b5455060$6801a8c0@oemcomputer><0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com><001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> Date: Wed, 10 Mar 2010 11:53:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b408dd13778d48d416684561a6d2757c9b3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.224.223 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Wed, 10 Mar 2010 19:52:25 -0000 Hi - Here's a summary of the edits I think would be needed to satisfy the comments on error counting and notifications. As a technical contributor, I'm still sceptical of the need for these, and think they increase the size and complexity of the document and of implementations far out of proportion to their value. However, as editor, it seems that the weight of the working group is in favor of doing something along these lines. So - please let me know whether these proposed changes accurately reflect your desires. (1) Changes to section 5 (Structure of the MIB module) - add a subtree for the counters - add a subtree for the notifications (2) Changes to section 6 (Relationship to Other MIB modules) - add a sub-section noting that notifications are turned off/on and destinations selected via RFC 3413 (3) Changes to section 7 (elements of procedure:) - modify 7.2.2 (Creation of Entries in vacmSecurityToGroupTable) to describe circumstances for extVacmAttemptedUpdateConflict notification (with exceptions in case where policy proposed by RADIUS is same as policy already in effect) - modify 7.2.3 (Update of vacmGroupName) to describe circumstances for extVacmQuestionableGroupReference (4) changes to section 8 (MIB modules) - add subtrees for counters and notifications - add counters (read-only) for each of the two notifiable conditions - add notification-type extVacmQuestionableGroupReference with a payload consisting of its counter and extVacmGroupName - add notification-type extVacmAttemptedUpdateConflict with a payload consisting of its counter and extVacmGroupName (minor issue - do we also want to convey the coresponding stuff from the vacmSecurityToGroupEntry, or should we rely on the application processing the notification to dig into it?) . - add a new MODULE-COMPLIANCE (or two ... issue: do we want to have a counters-only (no notifications) option?) - add a new OBJECT-GROUP for the counters - add a new OBJECT-GROUP for the notifications (5) changes to section 9 (security considerations) - add text on sensitivity of the added read-only counters - add text on notification sensitivity - add text on *possible* significance of notifications - add text on potential notification DDoS Let me know whether I've missed anything important in this summary, and confirm whether this is what we want to do. Randy From ietfdbh@comcast.net Wed Mar 10 12:03:52 2010 Return-Path: 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 E48133A6915 for ; Wed, 10 Mar 2010 12:03:52 -0800 (PST) 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 MZMNl06eZAws for ; Wed, 10 Mar 2010 12:03:51 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 503643A69D5 for ; Wed, 10 Mar 2010 12:03:47 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta11.emeryville.ca.mail.comcast.net with comcast id rSnM1d0020vp7WLABXzdGM; Wed, 10 Mar 2010 19:59:37 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta05.emeryville.ca.mail.comcast.net with comcast id rY3r1d00U4G8Frs8RY3szz; Wed, 10 Mar 2010 20:03:53 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com><001f01cabfcd$b5455060$6801a8c0@oemcomputer><0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com><001401cabfd9$5997a7c0$6801a8c0@oemcomputer><002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> Date: Wed, 10 Mar 2010 15:03:50 -0500 Message-ID: <0d6301cac08c$ce3ae0c0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000a01cac08b$624bc380$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcrAizoGcPpH+NgMSbGpw5/g6DvEpAAAYC0g Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Wed, 10 Mar 2010 20:03:53 -0000 if the consensus is that these are not worth the effort/cost, I can live without. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, March 10, 2010 2:54 PM > To: isms@ietf.org > Subject: Re: [Isms] wg last call on the radius / vacm > document:multipleissues > > Hi - > > Here's a summary of the edits I think would be needed to satisfy the > comments on error counting and notifications. As a technical > contributor, > I'm still sceptical of the need for these, and think they > increase the size > and complexity of the document and of implementations far out > of proportion > to their value. However, as editor, it seems that the weight > of the working group > is in favor of doing something along these lines. So - please let me > know whether these proposed changes accurately reflect your desires. > > > (1) Changes to section 5 (Structure of the MIB module) > > - add a subtree for the counters > - add a subtree for the notifications > > (2) Changes to section 6 (Relationship to Other MIB modules) > > - add a sub-section noting that notifications are turned off/on > and destinations selected via RFC 3413 > > (3) Changes to section 7 (elements of procedure:) > > - modify 7.2.2 (Creation of Entries in > vacmSecurityToGroupTable) > to describe circumstances for extVacmAttemptedUpdateConflict > notification (with exceptions in case where policy > proposed by RADIUS > is same as policy already in effect) > > - modify 7.2.3 (Update of vacmGroupName) > to describe circumstances for > extVacmQuestionableGroupReference > > (4) changes to section 8 (MIB modules) > > - add subtrees for counters and notifications > - add counters (read-only) for each of the two > notifiable conditions > - add notification-type extVacmQuestionableGroupReference > with a payload consisting of its counter and extVacmGroupName > - add notification-type extVacmAttemptedUpdateConflict > with a payload > consisting of its counter and extVacmGroupName > (minor issue - do we also want to convey the > coresponding stuff from > the vacmSecurityToGroupEntry, or should we rely on > the application > processing the notification to dig into it?) > . - add a new MODULE-COMPLIANCE > (or two ... issue: do we want to have a > counters-only (no notifications) option?) > - add a new OBJECT-GROUP for the counters > - add a new OBJECT-GROUP for the notifications > > (5) changes to section 9 (security considerations) > - add text on sensitivity of the added read-only counters > - add text on notification sensitivity > - add text on *possible* significance of notifications > - add text on potential notification DDoS > > Let me know whether I've missed anything important in this summary, > and confirm whether this is what we want to do. > > Randy > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From dnelson@elbrys.com Wed Mar 10 12:11:14 2010 Return-Path: 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 4D2E03A6908 for ; Wed, 10 Mar 2010 12:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 VauptoWJa4Av for ; Wed, 10 Mar 2010 12:11:12 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id E50013A694F for ; Wed, 10 Mar 2010 12:11:11 -0800 (PST) Received: from source ([209.85.220.222]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKS5f85Hf1PM2x22HWi1LP4YLMs4+2MArd@postini.com; Wed, 10 Mar 2010 12:11:17 PST Received: by mail-fx0-f222.google.com with SMTP id 22so659652fxm.14 for ; Wed, 10 Mar 2010 12:11:16 -0800 (PST) Received: by 10.223.68.143 with SMTP id v15mr2243068fai.62.1268251876381; Wed, 10 Mar 2010 12:11:16 -0800 (PST) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id p17sm3593386fka.39.2010.03.10.12.11.13 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 12:11:15 -0800 (PST) Cc: Message-Id: <95119A64-88D1-4C9A-936B-7A0462C26676@elbrys.com> From: "David B. Nelson" In-Reply-To: <000a01cac08b$624bc380$6801a8c0@oemcomputer> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Wed, 10 Mar 2010 15:11:09 -0500 References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer><6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com><001f01cabfcd$b5455060$6801a8c0@oemcomputer><0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com><001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Wed, 10 Mar 2010 20:11:14 -0000 On Mar 10, 2010, at 2:53 PM, Randy Presuhn wrote: > As a technical contributor,I'm still sceptical of the need for > these, and think > they increase the size and complexity of the document and of > implementations > far out of proportion to their value. I respect your position. OTOH, it's often added facilities to aid in figuring out what has gone wrong that separates a mundane implementation from a robust one. > However, as editor, it seems that the weight of the working group > is in favor of doing something along these lines. So - please let me > know whether these proposed changes accurately reflect your desires. > > (1) Changes to section 5 (Structure of the MIB module) > > - add a subtree for the counters > - add a subtree for the notifications > > (2) Changes to section 6 (Relationship to Other MIB modules) > > - add a sub-section noting that notifications are turned off/on > and destinations selected via RFC 3413 > > (3) Changes to section 7 (elements of procedure:) > > - modify 7.2.2 (Creation of Entries in vacmSecurityToGroupTable) > to describe circumstances for extVacmAttemptedUpdateConflict > notification (with exceptions in case where policy proposed > by RADIUS > is same as policy already in effect) > > - modify 7.2.3 (Update of vacmGroupName) > to describe circumstances for > extVacmQuestionableGroupReference > > (4) changes to section 8 (MIB modules) > > - add subtrees for counters and notifications > - add counters (read-only) for each of the two notifiable > conditions > - add notification-type extVacmQuestionableGroupReference > with a payload consisting of its counter and extVacmGroupName > - add notification-type extVacmAttemptedUpdateConflict with a > payload > consisting of its counter and extVacmGroupName > (minor issue - do we also want to convey the coresponding > stuff from > the vacmSecurityToGroupEntry, or should we rely on the > application > processing the notification to dig into it?) I have no informed opinion on this issue. My guess would be that we let applications dig for added information, as long as we've provided all the necessary "search keys" in the body of the notification. > . - add a new MODULE-COMPLIANCE > (or two ... issue: do we want to have a counters-only (no > notifications) option?) Again, no strong opinion. I have no objection to making the counter group and notification group (separate or single) optional. The value of these diagnostics aids will either be evident, or not, to the implementer. I think it's important that we provide a standardized framework for implementing them, when they are seen as needed in a particular product or deployment. > - add a new OBJECT-GROUP for the counters > - add a new OBJECT-GROUP for the notifications > > (5) changes to section 9 (security considerations) > - add text on sensitivity of the added read-only counters > - add text on notification sensitivity > - add text on *possible* significance of notifications > - add text on potential notification DDoS > > Let me know whether I've missed anything important in this summary, > and confirm whether this is what we want to do. I think you've got this "nailed". I don't see anything that you've missed. Thanks! Regards, Dave David B. Nelson Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 +1.603.570.2636 www.elbrys.com dnelson@elbrys.com From Robert.Story@cobham.com Wed Mar 10 13:52:26 2010 Return-Path: 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 7DBAC3A6A0E; Wed, 10 Mar 2010 13:52:26 -0800 (PST) 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 Oo-FpLbds9eX; Wed, 10 Mar 2010 13:52:25 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 886B43A6A36; Wed, 10 Mar 2010 13:52:25 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2ALqURl019832; Wed, 10 Mar 2010 15:52:30 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2ALqUGP004998; Wed, 10 Mar 2010 15:52:30 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 16:52:29 -0500 Date: Wed, 10 Mar 2010 16:52:25 -0500 From: Robert Story To: ietf@ietf.org Message-ID: <20100310165225.207170f4@sparta.com> In-Reply-To: <20100308151655.D299B3A69F4@core3.amsl.com> References: <20100308151655.D299B3A69F4@core3.amsl.com> Organization: SPARTA X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/EQITUTGLs1SpulEEsa3euMj"; protocol="application/pgp-signature" X-OriginalArrivalTime: 10 Mar 2010 21:52:29.0575 (UTC) FILETIME=[FAEC8970:01CAC09B] Cc: isms@ietf.org Subject: Re: [Isms] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard 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: , X-List-Received-Date: Wed, 10 Mar 2010 21:52:26 -0000 --Sig_/EQITUTGLs1SpulEEsa3euMj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 8 Mar 2010 07:16:55 -0800 The wrote: TI> The IESG plans to make a decision in the next few weeks, and solicits TI> final comments on this action. Please send substantive comments to the TI> ietf@ietf.org mailing lists by 2010-04-02. I didn't notice that some MIB objects got renamed between the 07 and 08 versions of the draft: dratf 07 draft 08 / current version ------------------------------- ---------------------------- snmpTlstmSessionClientOpens, snmpTlstmSessionOpens, snmpTlstmSessionClientCloses, snmpTlstmSessionClientCloses, snmpTlstmSessionClientOpenErrors, snmpTlstmSessionOpenErrors, snmpTlstmSessionServerOpens, snmpTlstmSessionAccepts, snmpTlstmSessionServerCloses, snmpTlstmSessionServerCloses, I think that the inconsistent use of 'Client' and 'Server' in the object names is confusing. Both snmpTlstmSessionOpens and snmpTlstmSessionOpenErrors are client-side only objects, and snmpTlstmSessionAccepts is a server-side only object. Putting Client/Server back in the object names will make it much easier to understand the output of a snmpwalk without having to refer to the description clause in the MIB. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/EQITUTGLs1SpulEEsa3euMj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkuYFJwACgkQ7/fVLLY1mnh+TACfT2T9U7q3B6I0euchlsdve5GP JX8An3rdAitpN+WRcH96P2qKVaoxr42m =B8kp -----END PGP SIGNATURE----- --Sig_/EQITUTGLs1SpulEEsa3euMj-- From wjhns1@hardakers.net Wed Mar 10 14:18:13 2010 Return-Path: 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 F3EA13A6830; Wed, 10 Mar 2010 14:18:12 -0800 (PST) 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=[AWL=0.000, 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 RxmvrW+S-tZv; Wed, 10 Mar 2010 14:18:10 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 97B853A6812; Wed, 10 Mar 2010 14:18:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id EAE4B9E891; Wed, 10 Mar 2010 14:18:14 -0800 (PST) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100308151655.D299B3A69F4@core3.amsl.com> <20100310165225.207170f4@sparta.com> Date: Wed, 10 Mar 2010 14:18:14 -0800 In-Reply-To: <20100310165225.207170f4@sparta.com> (Robert Story's message of "Wed, 10 Mar 2010 16:52:25 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf@ietf.org, isms@ietf.org Subject: Re: [Isms] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard 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: , X-List-Received-Date: Wed, 10 Mar 2010 22:18:13 -0000 >>>>> On Wed, 10 Mar 2010 16:52:25 -0500, Robert Story said: RS> I think that the inconsistent use of 'Client' and 'Server' in the RS> object names is confusing. Both snmpTlstmSessionOpens and RS> snmpTlstmSessionOpenErrors are client-side only objects, and RS> snmpTlstmSessionAccepts is a server-side only object. Putting RS> Client/Server back in the object names will make it much easier to RS> understand the output of a snmpwalk without having to refer to the RS> description clause in the MIB. This naming scheme was the result of a previous discussion (that I lost!) and the decision at the time was that the words "client" and "server" weren't needed in objects that were already only useful for that type of entity. IE: "ServerAccepts" is redundant since only a server can accept new connections. Because this is already a closed issue I don't see a need to revisit the discussion. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Mar 11 00:28:01 2010 Return-Path: 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 B50AF3A6B73 for ; Thu, 11 Mar 2010 00:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 1NnB8N1e0FNm for ; Thu, 11 Mar 2010 00:28:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5465D3A6BBF for ; Thu, 11 Mar 2010 00:26:41 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A9BFC000A; Thu, 11 Mar 2010 09:26:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZRgpKy7lnjsB; Thu, 11 Mar 2010 09:26:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2C2BC0007; Thu, 11 Mar 2010 09:26:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3F73710C9521; Thu, 11 Mar 2010 09:26:43 +0100 (CET) Date: Thu, 11 Mar 2010 09:26:43 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100311082643.GA12378@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01cac08b$624bc380$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 08:28:01 -0000 On Wed, Mar 10, 2010 at 08:53:39PM +0100, Randy Presuhn wrote: > Here's a summary of the edits I think would be needed to satisfy the > comments on error counting and notifications. As a technical contributor, > I'm still sceptical of the need for these, and think they increase the size > and complexity of the document and of implementations far out of proportion > to their value. However, as editor, it seems that the weight of the working group > is in favor of doing something along these lines. So - please let me > know whether these proposed changes accurately reflect your desires. > > > (1) Changes to section 5 (Structure of the MIB module) > > - add a subtree for the counters > - add a subtree for the notifications > > (2) Changes to section 6 (Relationship to Other MIB modules) > > - add a sub-section noting that notifications are turned off/on > and destinations selected via RFC 3413 > > (3) Changes to section 7 (elements of procedure:) > > - modify 7.2.2 (Creation of Entries in vacmSecurityToGroupTable) > to describe circumstances for extVacmAttemptedUpdateConflict > notification (with exceptions in case where policy proposed by RADIUS > is same as policy already in effect) > > - modify 7.2.3 (Update of vacmGroupName) > to describe circumstances for extVacmQuestionableGroupReference > > (4) changes to section 8 (MIB modules) > > - add subtrees for counters and notifications > - add counters (read-only) for each of the two notifiable conditions > - add notification-type extVacmQuestionableGroupReference > with a payload consisting of its counter and extVacmGroupName > - add notification-type extVacmAttemptedUpdateConflict with a payload > consisting of its counter and extVacmGroupName > (minor issue - do we also want to convey the coresponding stuff from > the vacmSecurityToGroupEntry, or should we rely on the application > processing the notification to dig into it?) > . - add a new MODULE-COMPLIANCE > (or two ... issue: do we want to have a counters-only (no notifications) option?) Counters are cheap to implement. If we agree to introduce counters, I think they should be mandatory. Notifications should IMHO be optional since they are more expensive to implement. > - add a new OBJECT-GROUP for the counters > - add a new OBJECT-GROUP for the notifications > > (5) changes to section 9 (security considerations) > - add text on sensitivity of the added read-only counters > - add text on notification sensitivity > - add text on *possible* significance of notifications > - add text on potential notification DDoS > > Let me know whether I've missed anything important in this summary, > and confirm whether this is what we want to do. I think this is a fairly complete summary. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 11 00:51:37 2010 Return-Path: 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 5F0413A6916 for ; Thu, 11 Mar 2010 00:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 DJUacWX5S01B for ; Thu, 11 Mar 2010 00:51:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 063D53A6869 for ; Thu, 11 Mar 2010 00:51:36 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2117FC000A; Thu, 11 Mar 2010 09:51:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HKSjJJqCkfQf; Thu, 11 Mar 2010 09:51:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D9F6C0002; Thu, 11 Mar 2010 09:51:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E720910C96FF; Thu, 11 Mar 2010 09:51:37 +0100 (CET) Date: Thu, 11 Mar 2010 09:51:37 +0100 From: Juergen Schoenwaelder To: "Pasi.Eronen@nokia.com" Message-ID: <20100311085137.GA12492@elstar.local> Mail-Followup-To: "Pasi.Eronen@nokia.com" , "cfinss@dial.pipex.com" , "isms@ietf.org" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> <000c01cabed0$014ed8e0$0601a8c0@allison> <20100309072353.GC5024@elstar.local> <808FD6E27AD4884E94820BC333B2DB77584836B953@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB77584836B953@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 08:51:37 -0000 On Tue, Mar 09, 2010 at 12:50:01PM +0100, Pasi.Eronen@nokia.com wrote: > Juergen Schoenwaelder wrote: > > > I am not an expert on (D)TLS regenotiation issues but I personally > > believe we went over board with this. I consider the renegotiation > > bug of TLS a temporary problem that can and likely will be cured > > (see RFC 5746). Hence, we are making a bad decision to outlaw > > renegotiation in general just because many deployed libraries today > > are somewhat vulnerable. > > > > I would prefer if the second paragraph in section 4.2 would be removed > > and we would add discussion to the Security Considerations pointing > > out the issue with "old" TLS code and the ways to work around things, > > including the option to disable renegotiation if the (D)TLS library > > used has not fixed the problem, e.g. via RFC 5746, or to verify the > > same certificate has been used during renegotiation. > > Even if you implement RFC 5746, the current EoP (sections 5.3.1 and > 5.3.2) won't work as-is if you allow renegotiation with different > certificates. The changes needed look rather cumbersome, and in TLSTM, > if changing certificates is needed (e.g. certificate is renewed), opening > a new TCP connection is cheap. So even if both ends implement RFC 5746, > we still need the text about verifying that the same certificate > has been used. Sure if the certificate gets renewed, opening a new connection is indeed cheap and appropriate. I can live with the "same certificate needs to be used" rule and the text that is in the ID. I note, however, that the SYSLOG over DTLS ID deals with renegotiation only in the security considerations and it says: [...] If, for some reason, renegotiation is allowed then the specification in RFC 5746 MUST be followed and the implementation MUST make sure that the connection security parameters do not change during renegotiation. This text only requires that "security parameters do not change", so it seems a bit more flexible than what we have in the ISMS document, which requires that the certificate must be the same. But then there is no access control model for SYSLOG and for ISMS we likely needed to consider everything that may map to a securityName a "security parameter" not to change and instead doing detailed comparison of certs it might indeed be simpler to require that the certs are the same. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Mar 11 07:55:01 2010 Return-Path: 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 57A293A676A for ; Thu, 11 Mar 2010 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SEX=2.3] 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 KaFl6WaZu8Bo for ; Thu, 11 Mar 2010 07:55:00 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 42C703A6ACD for ; Thu, 11 Mar 2010 07:54:25 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 72D59A0CC2; Thu, 11 Mar 2010 07:54:30 -0800 (PST) From: Wes Hardaker To: "Pasi.Eronen\@nokia.com" Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> <000c01cabed0$014ed8e0$0601a8c0@allison> <20100309072353.GC5024@elstar.local> <808FD6E27AD4884E94820BC333B2DB77584836B953@NOK-EUMSG-01.mgdnok.nokia.com> <20100311085137.GA12492@elstar.local> Date: Thu, 11 Mar 2010 07:54:30 -0800 In-Reply-To: <20100311085137.GA12492@elstar.local> (Juergen Schoenwaelder's message of "Thu, 11 Mar 2010 09:51:37 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 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: , X-List-Received-Date: Thu, 11 Mar 2010 15:55:01 -0000 >>>>> On Thu, 11 Mar 2010 09:51:37 +0100, Juergen Schoenwaelder said: JS> But then there is no access control model for SYSLOG and for ISMS we JS> likely needed to consider everything that may map to a securityName JS> a "security parameter" not to change and instead doing detailed JS> comparison of certs it might indeed be simpler to require that the JS> certs are the same. Renegotiation with different certificates would require significant changes, as it would likely invalidate the existing securityName attached to the session. Even if we just required the securityName to be the same we'd still need to write a new 5.3.x section or two that described EoP for handling renegotiation I think describing that after a renegotiation the securityName must be re-extracted and compared. But what's the gain? I don't really see that we're trying to develop a protocol that needs frequent renegotiations. If we needed it, I think there are solutions we could pick from and work toward documenting and delay everything even longer. But I've yet to see a use case that will happen on a regular enough basis to make it worthwhile to document the procedure. SNMP applications just don't have a need to change identities frequently. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Thu Mar 11 12:33:05 2010 Return-Path: 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 646613A6A04 for ; Thu, 11 Mar 2010 12:33:05 -0800 (PST) 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=[AWL=0.000, 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 8WXiMCqquh5S for ; Thu, 11 Mar 2010 12:33:04 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 6F8B23A6B69 for ; Thu, 11 Mar 2010 12:21:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=uDxbWCCfRfPPVzUaO8HOFuyUHcvcqF5b/IH0mNMlQaJBENrEymAEo3jddtqwUGUW; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.24.198] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NpotP-00051q-L6 for isms@ietf.org; Thu, 11 Mar 2010 15:22:03 -0500 Message-ID: <000401cac158$b412e360$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> Date: Thu, 11 Mar 2010 12:23:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4066a0f4c77f0b8a8a5b236306b4fa64e1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.24.198 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Thu, 11 Mar 2010 20:33:05 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, March 11, 2010 12:26 AM > Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues ... > Counters are cheap to implement. If we agree to introduce counters, I > think they should be mandatory. Notifications should IMHO be optional > since they are more expensive to implement. The counter itself is cheap, but in the case of extVacmQuestionableGroupReference, implementing the counter requires scanning a VACM table (vacmAccessTable) that we would otherwise not even need to mention, since we don't need to know anything about it for this MIB module to do its real job. I think a counter without the corresponding notification is relatively useless. Reacting to a change in the counters would require a scanning the vacmSecurityToGroupTable and vacmAccessTable, and reconciling what is there with the complete RADIUS user/policy configuration for *all* users, since there's no guarantee that the "offending" entry will still be present in the extVacmSecurityToGroupTable when the counter change is noticed. Randy From j.schoenwaelder@jacobs-university.de Thu Mar 11 14:18:07 2010 Return-Path: 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 17CFD3A67FF for ; Thu, 11 Mar 2010 14:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 kyHk9Kk-co3m for ; Thu, 11 Mar 2010 14:18:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E38163A694A for ; Thu, 11 Mar 2010 14:18:05 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94AF8C000D; Thu, 11 Mar 2010 23:18:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1fSDFL-6izav; Thu, 11 Mar 2010 23:18:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D94E5C0007; Thu, 11 Mar 2010 23:18:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0425910D1F60; Thu, 11 Mar 2010 23:18:06 +0100 (CET) Date: Thu, 11 Mar 2010 23:18:06 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100311221806.GA20429@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401cac158$b412e360$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 22:18:07 -0000 On Thu, Mar 11, 2010 at 09:23:23PM +0100, Randy Presuhn wrote: > > Counters are cheap to implement. If we agree to introduce counters, I > > think they should be mandatory. Notifications should IMHO be optional > > since they are more expensive to implement. > The counter itself is cheap, but in the case of > extVacmQuestionableGroupReference, implementing the counter requires > scanning a VACM table (vacmAccessTable) that we would otherwise not > even need to mention, since we don't need to know anything about it > for this MIB module to do its real job. This MIB modules is a close extension of VACM so I do not see the "different MIB module" argument. > I think a counter without the corresponding notification is > relatively useless. Reacting to a change in the counters would > require a scanning the vacmSecurityToGroupTable and vacmAccessTable, > and reconciling what is there with the complete RADIUS user/policy > configuration for *all* users, since there's no guarantee that the > "offending" entry will still be present in the > extVacmSecurityToGroupTable when the counter change is noticed. Yes, for debugging, you like to have a notification or a syslog message. For detecting the situation, a counter is sufficient. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Thu Mar 11 18:28:29 2010 Return-Path: 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 923333A6802 for ; Thu, 11 Mar 2010 18:28:29 -0800 (PST) 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 1+s9SBZ0R1q5 for ; Thu, 11 Mar 2010 18:28:28 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 27B173A69D2 for ; Thu, 11 Mar 2010 18:28:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tnOeXJPpF/OIk5PTljoxzokI4lj98QoDBSjQzRnrf7UaBSHprmbmutPhldOAf2mD; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.163.194] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Npuc5-0005XX-EG for isms@ietf.org; Thu, 11 Mar 2010 21:28:33 -0500 Message-ID: <000601cac18b$e76a51c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00ca01cabfc3$3848bf20$6801a8c0@oemcomputer> <6E69213B-4092-44F8-A885-0FAB8766BE9D@elbrys.com> <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> <20100311221806.GA20429@elstar.local> Date: Thu, 11 Mar 2010 18:29:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40df055015f96cab6435bb825b6d4e7cb1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.163.194 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Fri, 12 Mar 2010 02:28:29 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, March 11, 2010 2:18 PM > Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues > > On Thu, Mar 11, 2010 at 09:23:23PM +0100, Randy Presuhn wrote: > > > > Counters are cheap to implement. If we agree to introduce counters, I > > > think they should be mandatory. Notifications should IMHO be optional > > > since they are more expensive to implement. > > > The counter itself is cheap, but in the case of > > extVacmQuestionableGroupReference, implementing the counter requires > > scanning a VACM table (vacmAccessTable) that we would otherwise not > > even need to mention, since we don't need to know anything about it > > for this MIB module to do its real job. > > This MIB modules is a close extension of VACM so I do not see the > "different MIB module" argument. The point is that *every* time a group name arrives from RADIUS, to support this counter implementations need to scan the vacmAccessTable. This is necessary because the vacmAccessTable could have changed since the last arrival from RADIUS, so even if a group name is not being changed (e.g. a user is just opening another session) the "refresh" requires us to check the vacmAccessTable to see whether the group now refers to a "missing" policy. Without the counter, there's no reason to do so. It's processing overhead that goes beyond "counters are cheap to implement." Is it a huge cost? Probably not, because the same lookup will also happen inside the isAccessAllowed() ASI. Is it free? Certainly not. [Aside - I suppose that if we really wanted to verify that the policy reference was truly valid, we shouldn't just check to see that the row exists, but should also require a check of the RowStatus for the vacmAccessEntry to verify that it is "active".] I just find it more than a little ironic that after all the complaints on another list about VACM being over-engineered, we're doing the same thing here. Randy From j.schoenwaelder@jacobs-university.de Thu Mar 11 23:13:04 2010 Return-Path: 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 11C843A6A8C for ; Thu, 11 Mar 2010 23:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LcSqNiz1LHGz for ; Thu, 11 Mar 2010 23:13:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDE3B3A68B2 for ; Thu, 11 Mar 2010 23:13:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48063C000D; Fri, 12 Mar 2010 08:13:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LcUddCotKZ08; Fri, 12 Mar 2010 08:13:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3BC6C000A; Fri, 12 Mar 2010 08:13:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A55010D2C81; Fri, 12 Mar 2010 08:13:04 +0100 (CET) Date: Fri, 12 Mar 2010 08:13:04 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100312071304.GB21101@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> <20100311221806.GA20429@elstar.local> <000601cac18b$e76a51c0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601cac18b$e76a51c0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 07:13:06 -0000 On Fri, Mar 12, 2010 at 03:29:53AM +0100, Randy Presuhn wrote: > I just find it more than a little ironic that after all the > complaints on another list about VACM being over-engineered, we're > doing the same thing here. I can do well without the counter. Making the counter an optional feature is what I would like to avoid. Either the counter is useful and reasonable to implement or it isn't. Since a RADIUS decision usually comes at the beginning of a secure session, I doubt that the vacm access check will be noticable overhead, given all the other stuff happening at the secure transport layer. So I am not convinced by the complexity argument. That said, I can live very well without the counter. There are other configuration errors an administrator can make (e.g. a VACM access entry pointing to non-existing view names) where the answer is simply "you get what you asked for" and so from an SNMP perspective, a reference to a non existing access rule is just it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Mar 12 11:11:55 2010 Return-Path: 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 183523A68B4 for ; Fri, 12 Mar 2010 11:11:55 -0800 (PST) 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 lqvWMZeFuzS8 for ; Fri, 12 Mar 2010 11:11:53 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 9E2593A676A for ; Fri, 12 Mar 2010 11:11:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UuVddaQqt3luqwMJppxHUC7Qgjisq7FNITEU7I2HdZMtofUGOOqEdyWmYvAr+xUt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.50] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NqAH9-0002VX-05 for isms@ietf.org; Fri, 12 Mar 2010 14:11:59 -0500 Message-ID: <008601cac218$1604d6e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001f01cabfcd$b5455060$6801a8c0@oemcomputer> <0cb001cabfd5$5bc8dc70$0202fea9@china.huawei.com> <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> <20100311221806.GA20429@elstar.local> <000601cac18b$e76a51c0$6801a8c0@oemcomputer> <20100312071304.GB21101@elstar.local> Date: Fri, 12 Mar 2010 11:13:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40f5c7b3b06b1f25fbe3b7296f988150e9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.50 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Fri, 12 Mar 2010 19:11:55 -0000 Hi - Are there any other comments on how / whether to procede with adding counters and notifications? I think I have a good idea what the edits would be, but would like instruction from the chairs whether to apply these edits to the draft. Randy From jhutz@cmu.edu Fri Mar 12 12:23:31 2010 Return-Path: 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 869563A689D for ; Fri, 12 Mar 2010 12:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uNnGtyaw+0Bj for ; Fri, 12 Mar 2010 12:23:30 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 81BFE3A6881 for ; Fri, 12 Mar 2010 12:23:22 -0800 (PST) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2CKNQ9H017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2010 15:23:26 -0500 (EST) Date: Fri, 12 Mar 2010 15:23:25 -0500 From: Jeffrey Hutzelman To: Dave Nelson , isms@ietf.org Message-ID: <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> In-Reply-To: <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 20:23:31 -0000 --On Tuesday, March 09, 2010 06:34:51 AM -0500 Dave Nelson wrote: > If you don't trust RADIUS or the system administrator who configures its > polices, then don't use it. I think I see organizational dynamics > arguments creeping into a protocol discussion. That's always a bad sign, > IMHO. If there's bad organizational karma between the SNMP security > administrator and the corporate RADIUS administrator, fight that out in > the personnel domain, not the protocol domain, please. Good advice. Our goal here is to provide administrators, collectively, with the tools they need to apply their chosen policy. Our goal is not to declare that one subsystem or its administators are more "trusted" than another, more likely to know what is going on, or less likely to do something stupid. With that in mind, I generally like to apply the architectural principal that when configuration and policy come from multiple sources, information coming from a source "closer" to where it is applied should take precedence over information coming from further away. This again has nothing to do with assuming that the closer source is more "trusted", and everythign to do with the fact that it makes sense to have an enterprise-wide policy and make exceptions for specific devices, but not to have a policy for a specific device and make an exception that applies to the entire enterprise. The latter is nonsensical! -- Jeff From randy_presuhn@mindspring.com Fri Mar 12 12:31:58 2010 Return-Path: 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 85B383A6918 for ; Fri, 12 Mar 2010 12:31:58 -0800 (PST) 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 dAnf013svidD for ; Fri, 12 Mar 2010 12:31:57 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 30A013A68D5 for ; Fri, 12 Mar 2010 12:31:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=O6kdtDcK43XZj39z5syS3vfyu2esyFoSl7L+y6IrXyB50O/K5WubHpXozW2TDY1N; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.50] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NqBWb-0001AJ-23 for isms@ietf.org; Fri, 12 Mar 2010 15:32:01 -0500 Message-ID: <006801cac223$44268720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local><95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com><00f601cabf12$2cbed1a0$6801a8c0@oemcomputer><0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com><037001cabf2d$55df1fc0$6801a8c0@oemcomputer><27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> Date: Fri, 12 Mar 2010 12:33:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40cd33f19a1231cdcc19cece28d694c2ab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.50 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 20:31:58 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Dave Nelson" ; > Cc: > Sent: Friday, March 12, 2010 12:23 PM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 ... > Good advice. Our goal here is to provide administrators, collectively, > with the tools they need to apply their chosen policy. Our goal is not to > declare that one subsystem or its administators are more "trusted" than > another, more likely to know what is going on, or less likely to do > something stupid. > > > With that in mind, I generally like to apply the architectural principal > that when configuration and policy come from multiple sources, information > coming from a source "closer" to where it is applied should take precedence > over information coming from further away. This again has nothing to do > with assuming that the closer source is more "trusted", and everythign to > do with the fact that it makes sense to have an enterprise-wide policy and > make exceptions for specific devices, but not to have a policy for a > specific device and make an exception that applies to the entire > enterprise. The latter is nonsensical! Text, please? Randy From cfinss@dial.pipex.com Fri Mar 12 13:08:47 2010 Return-Path: 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 900593A691B for ; Fri, 12 Mar 2010 13:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 FWVhFQzRBn0w for ; Fri, 12 Mar 2010 13:08:44 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 100C23A68F5 for ; Fri, 12 Mar 2010 13:08:42 -0800 (PST) X-Trace: 301601070/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.109/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.109 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8IADo8mks+vGlt/2dsb2JhbAAugUwZGIUqiFOLNq5eCY0/AguCXYIRBA X-IronPort-AV: E=Sophos;i="4.49,628,1262563200"; d="scan'208";a="301601070" X-IP-Direction: IN Received: from 1cust109.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.109]) by smtp.pipex.tiscali.co.uk with SMTP; 12 Mar 2010 21:08:47 +0000 Message-ID: <000f01cac21f$a3458f20$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> <000701cabbae$47c86720$0601a8c0@allison> <20100305082456.GD19456@elstar.local> <000c01cabed0$014ed8e0$0601a8c0@allison> <20100309072353.GC5024@elstar.local> <808FD6E27AD4884E94820BC333B2DB77584836B953@NOK-EUMSG-01.mgdnok.nokia.com> <20100311085137.GA12492@elstar.local> Date: Fri, 12 Mar 2010 18:15:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Renego: was AD review comments for draft-ietf-isms-dtls-tm-08 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 21:08:48 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: ; Sent: Thursday, March 11, 2010 9:51 AM > On Tue, Mar 09, 2010 at 12:50:01PM +0100, Pasi.Eronen@nokia.com wrote: > > Juergen Schoenwaelder wrote: > > > > > I am not an expert on (D)TLS regenotiation issues but I personally > > > believe we went over board with this. I consider the renegotiation > > > bug of TLS a temporary problem that can and likely will be cured > > > (see RFC 5746). Hence, we are making a bad decision to outlaw > > > renegotiation in general just because many deployed libraries today > > > are somewhat vulnerable. > > > > > > I would prefer if the second paragraph in section 4.2 would be removed > > > and we would add discussion to the Security Considerations pointing > > > out the issue with "old" TLS code and the ways to work around things, > > > including the option to disable renegotiation if the (D)TLS library > > > used has not fixed the problem, e.g. via RFC 5746, or to verify the > > > same certificate has been used during renegotiation. > > > > Even if you implement RFC 5746, the current EoP (sections 5.3.1 and > > 5.3.2) won't work as-is if you allow renegotiation with different > > certificates. The changes needed look rather cumbersome, and in TLSTM, > > if changing certificates is needed (e.g. certificate is renewed), opening > > a new TCP connection is cheap. So even if both ends implement RFC 5746, > > we still need the text about verifying that the same certificate > > has been used. > > Sure if the certificate gets renewed, opening a new connection is > indeed cheap and appropriate. I can live with the "same certificate > needs to be used" rule and the text that is in the ID. I note, > however, that the SYSLOG over DTLS ID deals with renegotiation only in > the security considerations and it says: > > [...] If, for some reason, renegotiation is > allowed then the specification in RFC 5746 MUST be followed and the > implementation MUST make sure that the connection security parameters > do not change during renegotiation. > > This text only requires that "security parameters do not change", so > it seems a bit more flexible than what we have in the ISMS document, Juergen The text you quote is a new addition to the syslog I-D which I have asked to be amended to be explicit that change of certificate should not happen so I do not think that the current text should be used as an examplar. Tom Petch > which requires that the certificate must be the same. But then there > is no access control model for SYSLOG and for ISMS we likely needed to > consider everything that may map to a securityName a "security > parameter" not to change and instead doing detailed comparison of > certs it might indeed be simpler to require that the certs are the > same. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From jhutz@cmu.edu Fri Mar 12 13:11:12 2010 Return-Path: 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 9F56D3A681F for ; Fri, 12 Mar 2010 13:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 A-rJ11h8Yabm for ; Fri, 12 Mar 2010 13:11:11 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id E604E3A68D9 for ; Fri, 12 Mar 2010 13:11:09 -0800 (PST) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2CLBEvH015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2010 16:11:15 -0500 (EST) Date: Fri, 12 Mar 2010 16:11:14 -0500 From: Jeffrey Hutzelman To: Randy Presuhn , isms@ietf.org Message-ID: In-Reply-To: <17213_1268425927_o2CKW6oV004399_006801cac223$44268720$6801a8c0@oemcomputer> References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> <17213_1268425927_o2CKW6oV004399_006801cac223$44268720$6801a8c0@oemcomputer> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 21:11:12 -0000 --On Friday, March 12, 2010 12:33:23 PM -0800 Randy Presuhn wrote: > Hi - > >> From: "Jeffrey Hutzelman" >> To: "Dave Nelson" ; >> Cc: >> Sent: Friday, March 12, 2010 12:23 PM >> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 > ... >> Good advice. Our goal here is to provide administrators, collectively, >> with the tools they need to apply their chosen policy. Our goal is not >> to declare that one subsystem or its administators are more "trusted" >> than another, more likely to know what is going on, or less likely to >> do something stupid. >> >> >> With that in mind, I generally like to apply the architectural principal >> that when configuration and policy come from multiple sources, >> information coming from a source "closer" to where it is applied should >> take precedence over information coming from further away. This again >> has nothing to do with assuming that the closer source is more >> "trusted", and everythign to do with the fact that it makes sense to >> have an enterprise-wide policy and make exceptions for specific >> devices, but not to have a policy for a specific device and make an >> exception that applies to the entire enterprise. The latter is >> nonsensical! > > Text, please? What text? I believe we were discussing the question of whether local configuration should override that provided by RADIUS or the other way around. From randy_presuhn@mindspring.com Fri Mar 12 13:52:19 2010 Return-Path: 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 977F53A67FC for ; Fri, 12 Mar 2010 13:52:19 -0800 (PST) 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=[AWL=0.000, 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 pnSdJpLL4fHl for ; Fri, 12 Mar 2010 13:52:18 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id B72E43A67FB for ; Fri, 12 Mar 2010 13:52:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TGh7Jhil9zg6TEO5ejeVnj/NsyykzpJDuw5ORYkGCtPgMYWPslw3AMsv0WTujK6Q; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.50] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NqCmO-0005e2-Ix for isms@ietf.org; Fri, 12 Mar 2010 16:52:24 -0500 Message-ID: <000e01cac22e$80b96bc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> <17213_1268425927_o2CKW6oV004399_006801cac223$44268720$6801a8c0@oemcomputer> Date: Fri, 12 Mar 2010 13:53:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40e04d5e2ded1304166ac59f278f37d98a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.50 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 21:52:19 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Randy Presuhn" ; > Cc: > Sent: Friday, March 12, 2010 1:11 PM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 ... > > Text, please? > > What text? > > I believe we were discussing the question of whether local configuration > should override that provided by RADIUS or the other way around. Which text would you like to add to or remove from the I-D currently in WG last call? If the discussion entails no changes to the I-D, it would be nice to know that, too. :-) As far as I can tell, the draft's operational characteristics with respect to the primacy of administratively provisioned policy vis-a-vis dynamically delivered policy align with my understanding of the consensus view on this list, though of course declaration of consensus is the chairs' perogative. If there is specific text that is incorrect or misleading, please identify it and suggest a replacement. Randy From jhutz@cmu.edu Fri Mar 12 15:02:06 2010 Return-Path: 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 D25A13A6801 for ; Fri, 12 Mar 2010 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 argrey52U4GI for ; Fri, 12 Mar 2010 15:02:05 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 779A83A67FB for ; Fri, 12 Mar 2010 15:02:04 -0800 (PST) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2CN29El023688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2010 18:02:09 -0500 (EST) Date: Fri, 12 Mar 2010 18:02:09 -0500 From: Jeffrey Hutzelman To: Randy Presuhn , isms@ietf.org Message-ID: In-Reply-To: <28226_1268430749_o2CLqRS3002780_000e01cac22e$80b96bc0$6801a8c0@oemcomputer> References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> <17213_1268425927_o2CKW6oV004399_006801cac223$44268720$6801a8c0@oemcomputer> <28226_1268430749_o2CLqRS3002780_000e01cac22e$80b96bc0$6801a8c0@oemcomputer> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 23:02:06 -0000 --On Friday, March 12, 2010 01:53:50 PM -0800 Randy Presuhn wrote: > Hi - > >> From: "Jeffrey Hutzelman" >> To: "Randy Presuhn" ; >> Cc: >> Sent: Friday, March 12, 2010 1:11 PM >> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 > ... >> > Text, please? >> >> What text? >> >> I believe we were discussing the question of whether local configuration >> should override that provided by RADIUS or the other way around. > > Which text would you like to add to or remove from the I-D currently in WG > last call? I'm not sure why you're picking on me. I responded to a comment David Nelson made, which in turn was in response to a comment David Harrington made about a specific piece of text to which he objected. So, it should be pretty clear here that we're talking about that text, and particularly the notion that "RADIUS ... is at least as trusted as the security administrator". In addition, part of my comment was intended to be taken in the context of the discussion that's been going on all week about the question of RADIUS overriding local configuration or vice versa. Since that discussion has not yet quite died down, I think it's a bit premature to be complaining that no one has provided text regarding its outcome. -- Jeff From randy_presuhn@mindspring.com Fri Mar 12 15:36:08 2010 Return-Path: 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 6AB413A68D4 for ; Fri, 12 Mar 2010 15:36:08 -0800 (PST) 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 JKVEkxi1fCFJ for ; Fri, 12 Mar 2010 15:36:07 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 178C03A68D1 for ; Fri, 12 Mar 2010 15:36:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KfUGNeavMuPpA6ha2ADFFCJl+3B9O255EuaQBkiM1sCwL772MRbLW9rKqvKxWN9F; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.50] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NqEOq-0002wz-Sj for isms@ietf.org; Fri, 12 Mar 2010 18:36:13 -0500 Message-ID: <002f01cac23c$ff758a80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308090828.GA1852@elstar.local> <95E2B8D0-E20B-4271-9BE5-C2A65F2AB02C@elbrysnetworks.com> <00f601cabf12$2cbed1a0$6801a8c0@oemcomputer> <0b3e01cabf23$5738a0d0$0202fea9@china.huawei.com> <037001cabf2d$55df1fc0$6801a8c0@oemcomputer> <27876_1268134481_o29BYeeL031161_CBC0A97A00524083B2750D20007A135F@NEWTON603> <358B006140753DF1C6CBBA6A@lysithea.fac.cs.cmu.edu> <17213_1268425927_o2CKW6oV004399_006801cac223$44268720$6801a8c0@oemcomputer> <28226_1268430749_o2CLqRS3002780_000e01cac22e$80b96bc0$6801a8c0@oemcomputer> Date: Fri, 12 Mar 2010 15:37:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a673df52351ac7e550cc8cac99659e98350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.50 Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 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: , X-List-Received-Date: Fri, 12 Mar 2010 23:36:08 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Randy Presuhn" ; > Cc: > Sent: Friday, March 12, 2010 3:02 PM > Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 > > --On Friday, March 12, 2010 01:53:50 PM -0800 Randy Presuhn > wrote: > > > Hi - > > > >> From: "Jeffrey Hutzelman" > >> To: "Randy Presuhn" ; > >> Cc: > >> Sent: Friday, March 12, 2010 1:11 PM > >> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4 > > ... > >> > Text, please? > >> > >> What text? > >> > >> I believe we were discussing the question of whether local configuration > >> should override that provided by RADIUS or the other way around. > > > > Which text would you like to add to or remove from the I-D currently in WG > > last call? > > I'm not sure why you're picking on me. I responded to a comment David > Nelson made, which in turn was in response to a comment David Harrington > made about a specific piece of text to which he objected. So, it should be > pretty clear here that we're talking about that text, and particularly the > notion that "RADIUS ... is at least as trusted as the security > administrator". What do you want to replace that text with? I'm not arguing that what's there is wonderful. It's simply the text I made up in order to address the request that the security considerations section should talk about the trust relationships between the various entities. I'd be happy to replace it with anything meeting that requirement. > In addition, part of my comment was intended to be taken in the context of > the discussion that's been going on all week about the question of RADIUS > overriding local configuration or vice versa. Since that discussion has > not yet quite died down, I think it's a bit premature to be complaining > that no one has provided text regarding its outcome. I've re-read the thread. All specific suggestions for text in this thread have been resolved one way or another. I think the discussion on the primacy of explicitly- provisioned configuration over dynamically delivered stuff was clearly in favor of handling things in the way the draft currently does. (Though this is probably more obvious to those scarred by the COPS experience.) The chairs can over-rule, of course. Randy From j.schoenwaelder@jacobs-university.de Mon Mar 15 02:24:14 2010 Return-Path: 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 B785A3A68EB for ; Mon, 15 Mar 2010 02:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 iIAEghDaEGct for ; Mon, 15 Mar 2010 02:24: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 C6FD93A6A4A for ; Mon, 15 Mar 2010 02:18:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3D74C0008; Mon, 15 Mar 2010 10:18:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cdZ9mU1jInq2; Mon, 15 Mar 2010 10:18:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B516EC0018; Mon, 15 Mar 2010 10:18:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F07710DB379; Mon, 15 Mar 2010 10:18:18 +0100 (CET) Date: Mon, 15 Mar 2010 10:18:18 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100315091818.GA4102@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001401cabfd9$5997a7c0$6801a8c0@oemcomputer> <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> <20100311221806.GA20429@elstar.local> <000601cac18b$e76a51c0$6801a8c0@oemcomputer> <20100312071304.GB21101@elstar.local> <008601cac218$1604d6e0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008601cac218$1604d6e0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 09:24:14 -0000 On Fri, Mar 12, 2010 at 08:13:21PM +0100, Randy Presuhn wrote: > Are there any other comments on how / whether to procede with > adding counters and notifications? I think I have a good idea > what the edits would be, but would like instruction from the chairs > whether to apply these edits to the draft. Speaking as co-chair, it seems there is no concensus yet what to do about counters / notifications. We need more input on this. Here is an attempt to sum up the positions of those who participated in the discussion so far (let me know if I am wrong or missing something): DN: error reporting to spot likely configuration inconsistencies is needed DH: prefers supporting both counters and notifications for error reporting, but can live without if these are not worth the effort/cost RP: counters are not terribly useful, do not over-engineer this ED: proposed adding two counters and notifications, making counters and notifications each optional JS: prefers moving ahead without counters/notifications, dislikes having optional counters as an easy way out, can live with optional notifications but considers this in general an update to VACM AD: concerns about throttling notifications AD = Andy Donati DH = David Harrington RP = Randy Presuhn ED = editor (Randy Presuhn) JS = Juergen Schoenwaelder VACM always allowed security names that map to group names for which there is no access rule. This does not seem to have been a operational problem for the last ten years and it is unclear why RADIUS makes this such a special case. Note that a "questionable group reference" may not just appear when security name to group name entries are added, but also when the security administrator removes entries from the access table. So if we choose to report "questionable group reference", it should in my opinion be reported in all cases, which means we would have to add to the EoP of the vacmAccessTable, something we are likely not charted to do. If we do not check "questionable group reference" when the vacmAccessTable is changed, then the fact that "questionable group reference" was not reported or counted does not mean there is no "questionable group reference", making the error indication relatively useless. I guess I am making up another argument in favor of doing nothing since reporting "questionable group reference" really would require an update of VACM to be generally useful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Mar 15 04:38:43 2010 Return-Path: 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 231EE3A6CF1 for ; Mon, 15 Mar 2010 04:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] 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 VqjsD+viD1ey for ; Mon, 15 Mar 2010 04:38:42 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id EC9523A6B8A for ; Mon, 15 Mar 2010 04:09:21 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id tNzR1d0020SCNGk54P9Wfq; Mon, 15 Mar 2010 11:09:30 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta09.westchester.pa.mail.comcast.net with comcast id tP9V1d0030yip6Y3VP9VGz; Mon, 15 Mar 2010 11:09:30 +0000 From: "Dave Nelson" To: References: <001401cabfd9$5997a7c0$6801a8c0@oemcomputer><002e01cac00f$b0523360$6801a8c0@oemcomputer><000a01cac08b$624bc380$6801a8c0@oemcomputer><20100311082643.GA12378@elstar.local><000401cac158$b412e360$6801a8c0@oemcomputer><20100311221806.GA20429@elstar.local><000601cac18b$e76a51c0$6801a8c0@oemcomputer><20100312071304.GB21101@elstar.local><008601cac218$1604d6e0$6801a8c0@oemcomputer> <20100315091818.GA4102@elstar.local> Date: Mon, 15 Mar 2010 07:09:36 -0400 Message-ID: <629AC763A34B46A38A6A097F18AAC998@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100315091818.GA4102@elstar.local> Thread-Index: AcrEIU98EEov33BJQbmUWcqrKwyIQAADY5Mg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues 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: , X-List-Received-Date: Mon, 15 Mar 2010 11:38:43 -0000 Juergen Schoenwaelder writes... > VACM always allowed security names that map to group names for > which there is no access rule. This does not seem to have been a > operational problem for the last ten years and it is unclear why > RADIUS makes this such a special case. I understand that VACM has always had the opportunity for internal inconsistency of MIB objects in its tables. What makes this slightly different with the introduction of RADIUS is: (a) With VACM, the potential for inconsistency is easily discovered from inspection of the static data in the MIB objects. With RADIUS, a key element of the potential inconsistency will be transient, and not easily visible without externally accessible instrumentation. (b) RADIUS is centralized and VACM is distributed. There are two separate "places" that have to be consistent. Of course, this is no different from other kinds of NAS-resident policy, such as that invoked by the RADIUS Filter-Id attribute, after which the Management-Policy-Id attribute is modeled. I don't feel strongly that we should add instrumentation, if the consensus is that operators will not find it helpful. I can envision it being helpful, but maybe that's just me. From mundy@tislabs.com Fri Mar 19 14:08:31 2010 Return-Path: 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 652433A683D for ; Fri, 19 Mar 2010 14:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 PjkXHsJpBjUY for ; Fri, 19 Mar 2010 14:08:30 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 565403A67DD for ; Fri, 19 Mar 2010 14:08:30 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2JL8haq010440 for ; Fri, 19 Mar 2010 16:08:43 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2JL8h87018156 for ; Fri, 19 Mar 2010 16:08:43 -0500 Received: from hobbes.columbia.sparta.com ([75.197.240.57]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 17:08:43 -0400 Received: from [75.197.240.57] (localhost [127.0.0.1]) by hobbes.columbia.sparta.com (Postfix) with ESMTP id B10571DE3A25; Fri, 19 Mar 2010 17:09:10 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Fri, 19 Mar 2010 17:09:08 -0400 To: isms@ietf.org From: Russ Mundy Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 19 Mar 2010 21:08:43.0222 (UTC) FILETIME=[5B369F60:01CAC7A8] Subject: [Isms] WG Meeting at IETF-77 Cancelled 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: , X-List-Received-Date: Fri, 19 Mar 2010 21:08:31 -0000 After both reviewing the current state of our active documents, Juergen and I concluded that a face to face meeting in Anaheim would not be useful. As a result, I've asked the secretariat to cancel the meeting. However, we do need to conclude on the last radius /vacm document issue related to counters / notifications. Juergen provided a good summary of where this stands on the 15th so I'd like to see us finish this topic on the list by the end of next week. Russ From j.schoenwaelder@jacobs-university.de Tue Mar 30 07:55:56 2010 Return-Path: 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 4E8B13A6890 for ; Tue, 30 Mar 2010 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.718 X-Spam-Level: X-Spam-Status: No, score=0.718 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] 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 fXo+Rpc0S4QF for ; Tue, 30 Mar 2010 07:55:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E4A6D3A6A6B for ; Tue, 30 Mar 2010 07:55:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2208CC0018; Tue, 30 Mar 2010 16:56:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2-0pOA5jz-e3; Tue, 30 Mar 2010 16:56:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53025C0017; Tue, 30 Mar 2010 16:56:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 039FA1129F99; Tue, 30 Mar 2010 16:56:16 +0200 (CEST) Date: Tue, 30 Mar 2010 16:56:16 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20100330145616.GB728@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <002e01cac00f$b0523360$6801a8c0@oemcomputer> <000a01cac08b$624bc380$6801a8c0@oemcomputer> <20100311082643.GA12378@elstar.local> <000401cac158$b412e360$6801a8c0@oemcomputer> <20100311221806.GA20429@elstar.local> <000601cac18b$e76a51c0$6801a8c0@oemcomputer> <20100312071304.GB21101@elstar.local> <008601cac218$1604d6e0$6801a8c0@oemcomputer> <20100315091818.GA4102@elstar.local> <629AC763A34B46A38A6A097F18AAC998@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <629AC763A34B46A38A6A097F18AAC998@NEWTON603> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:55:56 -0000 On Mon, Mar 15, 2010 at 12:09:36PM +0100, Dave Nelson wrote: > Juergen Schoenwaelder writes... > > > VACM always allowed security names that map to group names for > > which there is no access rule. This does not seem to have been a > > operational problem for the last ten years and it is unclear why > > RADIUS makes this such a special case. > > I understand that VACM has always had the opportunity for internal > inconsistency of MIB objects in its tables. What makes this slightly > different with the introduction of RADIUS is: > > (a) With VACM, the potential for inconsistency is easily discovered from > inspection of the static data in the MIB objects. With RADIUS, a key > element of the potential inconsistency will be transient, and not easily > visible without externally accessible instrumentation. OK, I think you have a valid argument here. > (b) RADIUS is centralized and VACM is distributed. There are two separate > "places" that have to be consistent. Of course, this is no different from > other kinds of NAS-resident policy, such as that invoked by the RADIUS > Filter-Id attribute, after which the Management-Policy-Id attribute is > modeled. I do not what (b) has to do with the question whether we should have counters and/or notifications. > I don't feel strongly that we should add instrumentation, if the consensus > is that operators will not find it helpful. I can envision it being > helpful, but maybe that's just me. We need to find a way to move forward since we are obviously getting stuck on this issue. I will consult with Russ to see what his reading is since he is less involved in the technical debate. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wwwrun@rfc-editor.org Wed Mar 31 04:31:52 2010 Return-Path: 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 134C33A69F6 for ; Wed, 31 Mar 2010 04:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.63 X-Spam-Level: X-Spam-Status: No, score=0.63 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] 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 dQUBCKm+pKXc for ; Wed, 31 Mar 2010 04:31:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 672603A69E3 for ; Wed, 31 Mar 2010 04:31:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 82098E0791; Wed, 31 Mar 2010 04:32:22 -0700 (PDT) To: kaushik_narayan@yahoo.com, dnelson@elbrysnetworks.com, turners@ieca.com, tim.polk@nist.gov, Russ.Mundy@sparta.com, j.schoenwaelder@jacobs-university.de From: RFC Errata System Message-Id: <20100331113222.82098E0791@rfc-editor.org> Date: Wed, 31 Mar 2010 04:32:22 -0700 (PDT) Cc: mbj@tail-f.com, isms@ietf.org, rfc-editor@rfc-editor.org Subject: [Isms] [Editorial Errata Reported] RFC5608 (2100) 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: , X-List-Received-Date: Wed, 31 Mar 2010 11:31:52 -0000 The following errata report has been submitted for RFC5608, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5608&eid=2100 -------------------------------------- Type: Editorial Reported by: Martin Björklund Section: 2.3 Original Text ------------- Inactivity-Timeout Corrected Text -------------- Idle-Timeout Notes ----- The list of attributes in section 3 correctly lists the Idle-Timeout attribute. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5608 (draft-ietf-isms-radius-usage-07) -------------------------------------- Title : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Publication Date : August 2009 Author(s) : K. Narayan, D. Nelson Category : PROPOSED STANDARD Source : Integrated Security Model for SNMP Area : Security Stream : IETF Verifying Party : IESG From d.b.nelson@comcast.net Wed Mar 31 04:38:31 2010 Return-Path: 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 839343A691A for ; Wed, 31 Mar 2010 04:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 5wlQISDuRJ1j for ; Wed, 31 Mar 2010 04:38:30 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 237C23A699F for ; Wed, 31 Mar 2010 04:38:24 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id znD41d0011wpRvQ5Dnevcc; Wed, 31 Mar 2010 11:38:55 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta18.westchester.pa.mail.comcast.net with comcast id zni01d00Z0yip6Y3eni0Lf; Wed, 31 Mar 2010 11:42:01 +0000 From: "Dave Nelson" To: "'RFC Errata System'" , , , , , , References: <20100331113222.82098E0791@rfc-editor.org> Date: Wed, 31 Mar 2010 07:38:57 -0400 Message-ID: <19B58DD12A14429AA8E5B3787900F393@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20100331113222.82098E0791@rfc-editor.org> Thread-Index: AcrQxdcikS2uZAFtQwaKzW6pLZ0kvQAALhgg Cc: mbj@tail-f.com, isms@ietf.org Subject: Re: [Isms] [Editorial Errata Reported] RFC5608 (2100) 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: , X-List-Received-Date: Wed, 31 Mar 2010 11:38:31 -0000 I recommend that this errata report and the proposed correction be accepted. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Wednesday, March 31, 2010 7:32 AM > To: kaushik_narayan@yahoo.com; dnelson@elbrysnetworks.com; > turners@ieca.com; tim.polk@nist.gov; Russ.Mundy@sparta.com; > j.schoenwaelder@jacobs-university.de > Cc: mbj@tail-f.com; isms@ietf.org; rfc-editor@rfc-editor.org > Subject: [Isms] [Editorial Errata Reported] RFC5608 (2100) > > > The following errata report has been submitted for RFC5608, > "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5608&eid=2100 > > -------------------------------------- > Type: Editorial > Reported by: Martin Bjvrklund > > Section: 2.3 > > Original Text > ------------- > Inactivity-Timeout > > Corrected Text > -------------- > Idle-Timeout > > Notes > ----- > The list of attributes in section 3 correctly lists the Idle-Timeout > attribute. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5608 (draft-ietf-isms-radius-usage-07) > -------------------------------------- > Title : Remote Authentication Dial-In User Service (RADIUS) > Usage for Simple Network Management Protocol (SNMP) Transport Models > Publication Date : August 2009 > Author(s) : K. Narayan, D. Nelson > Category : PROPOSED STANDARD > Source : Integrated Security Model for SNMP > Area : Security > Stream : IETF > Verifying Party : IESG From j.schoenwaelder@jacobs-university.de Wed Mar 31 16:18:03 2010 Return-Path: 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 A7E1C3A6A20 for ; Wed, 31 Mar 2010 16:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] 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 FYm0R7iPTpJV for ; Wed, 31 Mar 2010 16:18:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 13F4B3A690B for ; Wed, 31 Mar 2010 16:18:02 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E51AC0002; Thu, 1 Apr 2010 01:18:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gxrd8zVgP3-G; Thu, 1 Apr 2010 01:18:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68298C0004; Thu, 1 Apr 2010 01:18:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0127E112D3C2; Thu, 1 Apr 2010 01:18:06 +0200 (CEST) Date: Thu, 1 Apr 2010 01:18:06 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20100331231806.GA3901@elstar.local> Mail-Followup-To: Dave Nelson , 'RFC Errata System' , "kaushik_narayan@yahoo.com" , "dnelson@elbrysnetworks.com" , "turners@ieca.com" , "tim.polk@nist.gov" , "Russ.Mundy@sparta.com" , "mbj@tail-f.com" , "isms@ietf.org" References: <20100331113222.82098E0791@rfc-editor.org> <19B58DD12A14429AA8E5B3787900F393@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19B58DD12A14429AA8E5B3787900F393@NEWTON603> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "mbj@tail-f.com" , "isms@ietf.org" , "tim.polk@nist.gov" , "dnelson@elbrysnetworks.com" , "Russ.Mundy@sparta.com" , 'RFC Errata System' Subject: Re: [Isms] [Editorial Errata Reported] RFC5608 (2100) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 23:18:03 -0000 On Wed, Mar 31, 2010 at 01:38:57PM +0200, Dave Nelson wrote: > I recommend that this errata report and the proposed correction be accepted. I agree. While perhaps obvious, it might be useful to mention that the term Inactivity-Timeout appears twice in Section 2.3 and both occurances should be replaced. /js > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > > RFC Errata System > > Sent: Wednesday, March 31, 2010 7:32 AM > > To: kaushik_narayan@yahoo.com; dnelson@elbrysnetworks.com; > > turners@ieca.com; tim.polk@nist.gov; Russ.Mundy@sparta.com; > > j.schoenwaelder@jacobs-university.de > > Cc: mbj@tail-f.com; isms@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Isms] [Editorial Errata Reported] RFC5608 (2100) > > > > > > The following errata report has been submitted for RFC5608, > > "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > > Network Management Protocol (SNMP) Transport Models". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5608&eid=2100 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Martin Bjvrklund > > > > Section: 2.3 > > > > Original Text > > ------------- > > Inactivity-Timeout > > > > Corrected Text > > -------------- > > Idle-Timeout > > > > Notes > > ----- > > The list of attributes in section 3 correctly lists the Idle-Timeout > > attribute. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5608 (draft-ietf-isms-radius-usage-07) > > -------------------------------------- > > Title : Remote Authentication Dial-In User Service (RADIUS) > > Usage for Simple Network Management Protocol (SNMP) Transport Models > > Publication Date : August 2009 > > Author(s) : K. Narayan, D. Nelson > > Category : PROPOSED STANDARD > > Source : Integrated Security Model for SNMP > > Area : Security > > Stream : IETF > > Verifying Party : IESG > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103