From ietfdbh@comcast.net Mon Feb 1 06:18:46 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 7846728C0E4 for ; Mon, 1 Feb 2010 06:18:46 -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 yeW+jSPkclQH for ; Mon, 1 Feb 2010 06:18:45 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 2709C28C13E for ; Mon, 1 Feb 2010 06:18:45 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id ccFd1d0020xGWP856eKLBp; Mon, 01 Feb 2010 14:19:20 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta12.westchester.pa.mail.comcast.net with comcast id ceKL1d001284sdk3YeKLCx; Mon, 01 Feb 2010 14:19:20 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer><20100130151453.GA99563@elstar.local> <000401caa1c5$e96f5fa0$6801a8c0@oemcomputer> Date: Mon, 1 Feb 2010 09:19:18 -0500 Message-ID: <087801caa349$8afe1d50$0600a8c0@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: <000401caa1c5$e96f5fa0$6801a8c0@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqhxWbeF6Cn3HMHR4+mooeBfU7JIwBg4fNA Subject: Re: [Isms] extVacmRowLifetime 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 Feb 2010 14:18:46 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Saturday, January 30, 2010 11:05 AM > To: isms@ietf.org > Subject: Re: [Isms] extVacmRowLifetime > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Saturday, January 30, 2010 7:14 AM > > Subject: Re: [Isms] extVacmRowLifetime > > > > On Sat, Jan 30, 2010 at 04:51:26AM +0100, Randy Presuhn wrote: > > > > > Working through the elements of procedure and the MIB, I've come > > > to the conclusion that we don't need extVacmRowLifetime. Here's > > > my reasoning: > > > > > > The value is simply whatever came over as the RADIUS > Session-Timeout > > > attribute. > > > > > > The secure transport model is already required to enfore > the RADIUS > > > Session-Timeout attribute. > > > > > > Consequently, while a session may be terminated before > the expiration > > > of Session-Timeout, it cannot outlast it. > > > > > > The secure transport model is also already required to > tell us both > > > when sessions are created and terminated. > > > > > > Thus we can conclude that relying on session termination > indications > > > alone would cause us to take no more time than using both. > > > > > > Consequently, knowledge of the termination all sessions > using a particular > > > (security model, security name) pair is sufficient for > the decision > > > to remove the corresponding extVacmSecurityToGroupEntry. > > > > > > Consequently, extVacmSecurityToGroup doesn't need to know > about it, > > > and we can get rid of extVacmRowLifetime from the MIB, > and the EOP. > > > Also, we don't need to talk about Session-Timeout. > > > > I think it needs to be clear how rows get deleted from the table(s). > > So I think it is essential to keep this sentence: > > > > When the secure transport session is torn down, > disconnected or times > > out, the corresponding extVacmSecurityToGroupEntry is deleted. > > > > While we likely can avoid talking about the RADIUS Session-Timeout > > Attribute, it might still be useful to have explicit text > somewhere to > > help implementors to do the right thing, e.g. > > > > When the secure transport session is torn down, disconnected or > > times out (e.g. following the RADIUS Session-Timeout Attribute), > > the corresponding extVacmSecurityToGroupEntry is deleted. > > > > > As I see it, the counter-argument to all this is to say that we > > > might want to support other security models that don't have these > > > properties with respect to session timeouts. > > > > If there is a security model without a session timeout, > then having a > > MIB object for a timeout that is not known would not help. It seems > > having the MIB object is more a way of exposing the lifetime. > > Agreed on all points. > > The conclusion that leads me to is that if anything exposes > the session lifetime data, it should be the security model, since that > lifetime (and whether it exists at all) is a property of the > security model. I assume you refer to a security model in the SNMP engine. I do not understand how you concluded that the security model knows anything about the session lifetime; SNMP has no sessions. Transport models might recognize transport sessions. So it would need to be a RADIUS-enabled transport model that exposed the session lifetime, no? > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From j.schoenwaelder@jacobs-university.de Mon Feb 1 07:03: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 63EB028C15A for ; Mon, 1 Feb 2010 07:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 NNo72K4NQlCP for ; Mon, 1 Feb 2010 07:03:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0615828C168 for ; Mon, 1 Feb 2010 07:03:34 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2F71C001E; Mon, 1 Feb 2010 16:04:07 +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 GWlrgKprJR3L; Mon, 1 Feb 2010 16:04: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 9E6B7C0016; Mon, 1 Feb 2010 16:04:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F9B81029F6F; Mon, 1 Feb 2010 16:03:54 +0100 (CET) Date: Mon, 1 Feb 2010 16:03:54 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100201150354.GB5475@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: 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] updated TLS drafts published: -06 and -07 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, 01 Feb 2010 15:03:47 -0000 On Thu, Jan 28, 2010 at 01:42:03AM +0100, Wes Hardaker wrote: > This document has no outstanding issues left with it that have been > brought up by working group members. I believe it is ready for it > to be submitted to the IESG. I did the required idnits check and here is the result (trimmed down to thing that might matter): == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) We might have to switch to the 28 Dec 2009 version. -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246) This seems to be intentional. -- No information found for draft-seggelmann-tls-dtls-heartbeat - is the name correct? The name seems to be correct; no clue why idnits fails on this one. /js -- 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 Feb 1 09:36: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 075C928C186 for ; Mon, 1 Feb 2010 09:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 HtdCeu8duLvk for ; Mon, 1 Feb 2010 09:36:46 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id F298A28C165 for ; Mon, 1 Feb 2010 09:36:45 -0800 (PST) X-Trace: 324354304/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.122/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.122 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: AsgFAM6fZks+vGl6/2dsb2JhbACCJhYWhSWJAcoJDIQ5BA X-IronPort-AV: E=Sophos;i="4.49,384,1262563200"; d="scan'208";a="324354304" X-IP-Direction: IN Received: from 1cust122.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.122]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Feb 2010 17:37:11 +0000 Message-ID: <000201caa35c$bef7a5a0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "Wes Hardaker" References: <20100201150354.GB5475@elstar.local> Date: Mon, 1 Feb 2010 17:13:58 +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] updated TLS drafts published: -06 and -07 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, 01 Feb 2010 17:36:47 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Monday, February 01, 2010 4:03 PM > On Thu, Jan 28, 2010 at 01:42:03AM +0100, Wes Hardaker wrote: > > > This document has no outstanding issues left with it that have been > > brought up by working group members. I believe it is ready for it > > to be submitted to the IESG. > > I did the required idnits check and here is the result (trimmed down > to thing that might matter): > > == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 > Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/) > > We might have to switch to the 28 Dec 2009 version. > > -- Obsolete informational reference (is this intentional?): RFC 4366 > (Obsoleted by RFC 5246) > > This seems to be intentional. > > -- No information found for draft-seggelmann-tls-dtls-heartbeat - is the name > correct? > > The name seems to be correct; no clue why idnits fails on this one. Perhaps because it has expired; it was published 6 Jul 2009 so is almost a month gone by now. Tom Petch > /js > From wjhns1@hardakers.net Mon Feb 1 11:30: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 2E96728C1BF for ; Mon, 1 Feb 2010 11:30: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=[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 2RSVkZdcyl2E for ; Mon, 1 Feb 2010 11:30:11 -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 46BD728C1A0 for ; Mon, 1 Feb 2010 11:30:11 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id 11BA79810D; Mon, 1 Feb 2010 11:30:42 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20100201150354.GB5475@elstar.local> <000201caa35c$bef7a5a0$0601a8c0@allison> Date: Mon, 01 Feb 2010 11:30:40 -0800 In-Reply-To: <000201caa35c$bef7a5a0$0601a8c0@allison> (tom petch's message of "Mon, 1 Feb 2010 17:13:58 +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] updated TLS drafts published: -06 and -07 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 Feb 2010 19:30:14 -0000 >>>>> On Mon, 1 Feb 2010 17:13:58 +0100, "tom.petch" said: >> -- No information found for draft-seggelmann-tls-dtls-heartbeat - is the tp> name >> correct? >> >> The name seems to be correct; no clue why idnits fails on this one. tp> Perhaps because it has expired; it was published 6 Jul 2009 so is almost a tp> month gone by now. No, it's actually been failing longer than that and I didn't know why 2 months ago either. I suspect it's a bug in their database files or something. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Feb 1 11:31: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 8224928C13E for ; Mon, 1 Feb 2010 11:31:28 -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 HI8s2HbbWP-I for ; Mon, 1 Feb 2010 11:31:27 -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 9BCF228C1BF for ; Mon, 1 Feb 2010 11:31:27 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id 23C7B98124; Mon, 1 Feb 2010 11:32:02 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20100201150354.GB5475@elstar.local> Date: Mon, 01 Feb 2010 11:32:00 -0800 In-Reply-To: <20100201150354.GB5475@elstar.local> (Juergen Schoenwaelder's message of "Mon, 1 Feb 2010 16:03:54 +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] updated TLS drafts published: -06 and -07 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 Feb 2010 19:31:28 -0000 >>>>> On Mon, 1 Feb 2010 16:03:54 +0100, Juergen Schoenwaelder said: JS> == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 JS> Sep 2009 rather than the newer Notice from 28 Dec 2009. (See JS> http://trustee.ietf.org/license-info/) JS> We might have to switch to the 28 Dec 2009 version. I'll go look at it. I didn't think we could change the notice if it was published before the magic date, but I bet they do have a new wording of the same condition. I didn't think about that. JS> -- Obsolete informational reference (is this intentional?): RFC 4366 JS> (Obsoleted by RFC 5246) JS> This seems to be intentional. Yep. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Feb 2 03: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 93EC828C287 for ; Tue, 2 Feb 2010 03:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 j9YvD1jYP15P for ; Tue, 2 Feb 2010 03:00: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 77D1E28C283 for ; Tue, 2 Feb 2010 03:00:05 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5C74C0033; Tue, 2 Feb 2010 12:00:42 +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 bHEYTwxxeryV; Tue, 2 Feb 2010 12:00:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98BEFC002F; Tue, 2 Feb 2010 12:00:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5ACBB102C351; Tue, 2 Feb 2010 12:00:31 +0100 (CET) Date: Tue, 2 Feb 2010 12:00:31 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100202110031.GA8728@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: 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] new wording for server side counters and establishing a session 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, 02 Feb 2010 11:00:07 -0000 On Sat, Jan 30, 2010 at 02:23:40AM +0100, Wes Hardaker wrote: > > Ok, to support the goals discussed recently: > > 1) renames everything to Jurgen's proposed names > 2) puts text in the incoming message handling that says when to > increment the server side handling > 3) rearranges the "establishing a session" section to clearly indicate > that openSession() is for the client and split the server side into > a separate sub section. > 4) removed the serverSessionOpenErrors counter entirely since it was > basically impossible to say when it happens since it would > generally happen long before the TLSTM got to handling packets. > > The resulting changed text pieces are below. Looks OK to me. A minor editorial nit: Should the phrase "whether it succeeded or failed" be "regardless of whether it suceeded or failed" in the DESCRIPTION clauses? /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 Tue Feb 2 03:02: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 06F0628C283 for ; Tue, 2 Feb 2010 03:02: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=[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 59a2zF1Tx2Ww for ; Tue, 2 Feb 2010 03:02:46 -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 3CF8728C1A6 for ; Tue, 2 Feb 2010 03:02:46 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id 494C798046; Tue, 2 Feb 2010 03:03:23 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20100202110031.GA8728@elstar.local> Date: Tue, 02 Feb 2010 03:03:20 -0800 In-Reply-To: <20100202110031.GA8728@elstar.local> (Juergen Schoenwaelder's message of "Tue, 2 Feb 2010 12:00:31 +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] new wording for server side counters and establishing a session 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 Feb 2010 11:02:47 -0000 >>>>> On Tue, 2 Feb 2010 12:00:31 +0100, Juergen Schoenwaelder said: >> The resulting changed text pieces are below. JS> Looks OK to me. Thanks for responding. I'll go republish it now. I was feeling nervous that no one had responded about the text. Highly unusual in the IETF! -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Feb 2 03:58: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 A87013A69ED for ; Tue, 2 Feb 2010 03:58: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=[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 O1+57ka7zK49 for ; Tue, 2 Feb 2010 03:58:51 -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 665183A6936 for ; Tue, 2 Feb 2010 03:58:48 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id A210A98167; Tue, 2 Feb 2010 03:59:25 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20100201150354.GB5475@elstar.local> Date: Tue, 02 Feb 2010 03:59:23 -0800 In-Reply-To: (Wes Hardaker's message of "Mon, 01 Feb 2010 11:32:00 -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] updated TLS drafts published: -06 and -07 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 Feb 2010 11:58:51 -0000 >>>>> On Mon, 01 Feb 2010 11:32:00 -0800, Wes Hardaker said: JS> Sep 2009 rather than the newer Notice from 28 Dec 2009. (See JS> http://trustee.ietf.org/license-info/) JS> We might have to switch to the 28 Dec 2009 version. That's the only available pre5378 trust text that the latest version of xml2rfc contains. We do need the pre5378 text escape clause since some of the original text came from people that I'd have a hard (impossible) time to track down. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Tue Feb 2 04: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 805F13A6935; Tue, 2 Feb 2010 04: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: <20100202120001.805F13A6935@core3.amsl.com> Date: Tue, 2 Feb 2010 04:00:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-08.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: Tue, 02 Feb 2010 12: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 : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-08.txt Pages : 65 Date : 2010-02-02 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, DTLS/UDP and DTLS/SCTP. 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 or SCTP) 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-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-02035532.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Tue Feb 2 06:50: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 C99943A6864 for ; Tue, 2 Feb 2010 06:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fScwFpjj9VEG for ; Tue, 2 Feb 2010 06:50:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC0D43A67AF for ; Tue, 2 Feb 2010 06:50:22 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1421C004E for ; Tue, 2 Feb 2010 15:51:00 +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 Tf22rkzD2bDt; Tue, 2 Feb 2010 15:50:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB042C0038; Tue, 2 Feb 2010 15:50:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 86786102CC04; Tue, 2 Feb 2010 15:50:48 +0100 (CET) Date: Tue, 2 Feb 2010 15:50:48 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100202145048.GA9823@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] dtls document writeup 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, 02 Feb 2010 14:50:26 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, now that we have cleared up the counters, I believe we are pretty much done with the (D)TLS transport mapping. I plan to deliver the document to our AD by the end of this week. Attached is my document writeup in case you want to review it before it goes to Pasi. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-dtls-writeup.txt" Document: draft-ietf-isms-dtls-tm-08.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including thef latest version and I believe it is ready for forwarding it to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received WG last call reviews from - Andrew Donati - Pasi Eronen - Juergen Schoenwaelder - Hamid Mukhtar - Alan Luchuk - Joe Salowey - David Harrington - Tom Petch - Robert Story and I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document might benefit from a review of the TLS certificate handling procedures by some TLS expert; perhaps this can be dealt with as part of the security directorate review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been checked with idnits 2.12.00 and the warnings generated are all intentional or bugs in the tool. The document contains a MIB module and should go through the MIB doctor review processs. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document requests a number of assignment in existing registries. It does not create any new registries. I believe the IANA instructions are clear. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module has been checked using smilint for syntactic correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary 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. Working Group Summary The working group went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality There are two known implementations in progress of the (D)TLS Transport Model. --ibTvN161/egqYuK8-- From dnelson@elbrysnetworks.com Tue Feb 2 07:01: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 83E5C3A6B11 for ; Tue, 2 Feb 2010 07:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 Q9XKlmYoBSs9 for ; Tue, 2 Feb 2010 07:01:50 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 441523A67BD for ; Tue, 2 Feb 2010 07:01:49 -0800 (PST) Received: (qmail 23142 invoked from network); 2 Feb 2010 15:02:24 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 2 Feb 2010 15:02:24 -0000 Message-Id: <32A78232-9BB1-4F4C-A921-2C625054F243@elbrysnetworks.com> From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <005401caa13f$d7ae0cc0$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, 2 Feb 2010 10:02:24 -0500 References: <20100120122622.GA806@elstar.local><001701caa08f$8599d820$6801a8c0@oemcomputer> <004601caa135$f0024660$6801a8c0@oemcomputer> <535F86B2-A867-4E16-AB94-E7FC123AFD1C@elbrysnetworks.com> <005401caa13f$d7ae0cc0$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] JSo: hard-wire to TSM? 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 Feb 2010 15:01:51 -0000 On Jan 29, 2010, at 7:04 PM, Randy Presuhn wrote: > I think we're in agreement. The existence of such a use case, > no matter how razor-thin, makes the absolute "MUST" problematic. > The person who'd be concerned about the SHOULD/MUST > distinction here would be someone developing another security model. > Though health warnings are often appropriate in cases like this, > I'm happy with the implicit warning that comes with every SHOULD. > But if you'd like to supply some more explicit health warnings to > go along with the SHOULD, I'd be happy to include them. I would like to submit some "health warnings" text for inclusion in the Security Considerations section. I'm currently "on deadline" for some more pressing deliverables, so it may be a little while before I get to this. From ietfdbh@comcast.net Tue Feb 2 07:26:36 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 E19E03A6952 for ; Tue, 2 Feb 2010 07:26:36 -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 SNO-fRrSmSzB for ; Tue, 2 Feb 2010 07:26:35 -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 1ECA73A6864 for ; Tue, 2 Feb 2010 07:26:34 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id d3Gk1d00B0mv7h05D3TEV4; Tue, 02 Feb 2010 15:27:14 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta11.westchester.pa.mail.comcast.net with comcast id d3TD1d008284sdk3X3TDF2; Tue, 02 Feb 2010 15:27:14 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20100202145048.GA9823@elstar.local> Date: Tue, 2 Feb 2010 10:27:12 -0500 Message-ID: <00cd01caa41c$3191f8d0$0600a8c0@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: <20100202145048.GA9823@elstar.local> Thread-Index: AcqkFyhAQ0PtYx6mRe+yxNWFHk15EQAADFYg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] dtls document writeup 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 Feb 2010 15:26:37 -0000 Hi, Has anybody published an analysis of the differences, especially for configuration and defaults and certificate processing, between the TLS/DTLS usage in this document versus that in the syslog/tls and syslog/dtls documents? I know the syslog/dtls document was largely based on Wes's early drafts for snmp/dtls. But both the tlstm and the syslog/dtls documents have gone through significant editing since then. The syslog WG has already had syslog/tls approved, and is about to start WGLC on syslog/dtls, and plans to submit it to the IESG by March. These documents will likely be going through the approval process together, at least to a degree. While the syslog and SNMP architectures are polar opposites, I think it would be helpful to consider whether the operation and security of these two solutions will be compatible and/or comparable. The writeup mentions a review by the security directorate; you might also ask that the operations directorate review it with an eye toward consistency in operations between the protocols. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, February 02, 2010 9:51 AM > To: isms@ietf.org > Subject: [Isms] dtls document writeup > > Hi, > > now that we have cleared up the counters, I believe we are pretty much > done with the (D)TLS transport mapping. I plan to deliver the > document to our AD by the end of this week. Attached is my document > writeup in case you want to review it before it goes to Pasi. > > /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 Tue Feb 2 11:49: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 AAEFA3A697B for ; Tue, 2 Feb 2010 11:49: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 V7rkjl1BksMk for ; Tue, 2 Feb 2010 11:49:36 -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 9B7543A696D for ; Tue, 2 Feb 2010 11:49:34 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id 2117598094 for ; Tue, 2 Feb 2010 11:50:13 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20100202145048.GA9823@elstar.local> Date: Tue, 02 Feb 2010 11:50:11 -0800 In-Reply-To: <20100202145048.GA9823@elstar.local> (Juergen Schoenwaelder's message of "Tue, 2 Feb 2010 15:50:48 +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 Subject: Re: [Isms] Ismsdtls document writeup 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 Feb 2010 19:49:37 -0000 >>>>> On Tue, 2 Feb 2010 15:50:48 +0100, Juergen Schoenwaelder said: JS> now that we have cleared up the counters, I believe we are pretty much JS> done with the (D)TLS transport mapping. I plan to deliver the JS> document to our AD by the end of this week. Attached is my document JS> writeup in case you want to review it before it goes to Pasi. Thanks for the writeup Juergen; looks perfect. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Feb 2 11:51: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 42CA23A698C for ; Tue, 2 Feb 2010 11:51:49 -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 vRs4fRDDRM-i for ; Tue, 2 Feb 2010 11:51:48 -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 3E22528B23E for ; Tue, 2 Feb 2010 11:51:48 -0800 (PST) Received: from localhost (218-42-154-18.cust.bit-drive.ne.jp [218.42.154.18]) by mail.hardakers.net (Postfix) with ESMTPSA id A488D9809E; Tue, 2 Feb 2010 11:52:23 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20100202145048.GA9823@elstar.local> <00cd01caa41c$3191f8d0$0600a8c0@china.huawei.com> Date: Tue, 02 Feb 2010 11:52:21 -0800 In-Reply-To: <00cd01caa41c$3191f8d0$0600a8c0@china.huawei.com> (David Harrington's message of "Tue, 2 Feb 2010 10:27:12 -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: isms@ietf.org Subject: Re: [Isms] dtls document writeup 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 Feb 2010 19:51:49 -0000 >>>>> On Tue, 2 Feb 2010 10:27:12 -0500, "David Harrington" said: DH> Has anybody published an analysis of the differences, especially for DH> configuration and defaults and certificate processing, between the DH> TLS/DTLS usage in this document versus that in the syslog/tls and DH> syslog/dtls documents? I compared them a while back, but I agree they've both received a lot of work since then. I'll take a look at the syslog document next week sometime to look for any gotchas, but I don't think the pieces that are similar between them have likely diverged much for as you said, architecturally they're very different. The one previous thing that the SNMP document didn't do that the syslog document did was fingerprints, and we've since added support for that. I don't think it's worth holding up the submission to the IESG for though. -- Wes Hardaker Cobham Analytic Solutions From jsalowey@cisco.com Wed Feb 3 08:44:27 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 3CF793A6C3C for ; Wed, 3 Feb 2010 08:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jWjc4AIloRVH for ; Wed, 3 Feb 2010 08:44:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 18AC53A6C6F for ; Wed, 3 Feb 2010 08:44:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ82aUurR7H+/2dsb2JhbADAaooeCY1oAoJQgXME X-IronPort-AV: E=Sophos;i="4.49,399,1262563200"; d="scan'208";a="83130560" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2010 16:45:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o13Gj98E028566; Wed, 3 Feb 2010 16:45:09 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:45:08 -0800 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: Wed, 3 Feb 2010 08:45:07 -0800 Message-ID: In-Reply-To: <00cd01caa41c$3191f8d0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] dtls document writeup Thread-Index: AcqkFyhAQ0PtYx6mRe+yxNWFHk15EQAADFYgADYkfgA= References: <20100202145048.GA9823@elstar.local> <00cd01caa41c$3191f8d0$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "Juergen Schoenwaelder" , X-OriginalArrivalTime: 03 Feb 2010 16:45:08.0954 (UTC) FILETIME=[3EFFD3A0:01CAA4F0] Subject: Re: [Isms] dtls document writeup 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 Feb 2010 16:44:27 -0000 When I did my review I looked at this. While the two are not exactly aligned I think they are close enough not to cause problems. I do think it is still a good idea to have folks look at it from an operational point of view. =20 Joe > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Tuesday, February 02, 2010 7:27 AM > To: 'Juergen Schoenwaelder'; isms@ietf.org > Subject: Re: [Isms] dtls document writeup >=20 > Hi, >=20 > Has anybody published an analysis of the differences, especially for > configuration and defaults and certificate processing, between the > TLS/DTLS usage in this document versus that in the syslog/tls and > syslog/dtls documents? >=20 > I know the syslog/dtls document was largely based on Wes's early > drafts for snmp/dtls. But both the tlstm and the syslog/dtls documents > have gone through significant editing since then. >=20 > The syslog WG has already had syslog/tls approved, and is about to > start WGLC on syslog/dtls, and plans to submit it to the IESG by > March. These documents will likely be going through the approval > process together, at least to a degree. While the syslog and SNMP > architectures are polar opposites, I think it would be helpful to > consider whether the operation and security of these two solutions > will be compatible and/or comparable. >=20 > The writeup mentions a review by the security directorate; you might > also ask that the operations directorate review it with an eye toward > consistency in operations between the protocols. >=20 > dbh >=20 > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, February 02, 2010 9:51 AM > > To: isms@ietf.org > > Subject: [Isms] dtls document writeup > > > > Hi, > > > > now that we have cleared up the counters, I believe we are pretty > much > > done with the (D)TLS transport mapping. I plan to deliver the > > document to our AD by the end of this week. Attached is my document > > writeup in case you want to review it before it goes to Pasi. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > >=20 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Wed Feb 3 13:36: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 563D63A6B4A for ; Wed, 3 Feb 2010 13:36:57 -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 9di7sd3-8lFE for ; Wed, 3 Feb 2010 13:36:56 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 145123A6B47 for ; Wed, 3 Feb 2010 13:36:55 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id dVeE1d0060ldTLk55ZcuLL; Wed, 03 Feb 2010 21:36:54 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta04.westchester.pa.mail.comcast.net with comcast id dZdf1d00Q284sdk3QZdfDb; Wed, 03 Feb 2010 21:37:40 +0000 From: "David Harrington" To: "'Wes Hardaker'" , , "'Joseph Salowey \(jsalowey\)'" , Date: Wed, 3 Feb 2010 16:37:38 -0500 Message-ID: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqlGRs1IIhVu5u9SPm0fld2OU5iGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 21:36:57 -0000 Hi, I quickly looked at the two documents for differences. I found a few I thought might deserve discussion: -- DoS -- syslog: Implementations MUST support the denial of service countermeasures defined by DTLS. When these countermeasures are enabled, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. snmp: DTLS Transport Model server implementations MUST support DTLS cookies. Implementations are not required to perform the stateless cookie exchange for every DTLS handshake, but in environments where an overload on server side resources is detectable by the implementation it is RECOMMENDED that the cookie exchange is utilized by the implementation. My impression is that syslog allows an admin to enable this as a deployment option; tlstm seems to depend on the implementation. (and I have difficulty knowing how an implementation will know if overlaod on server side is detectable, unless it is doing the detection itself.) 1) Is enable/disable capability a MUST implement for DTLS cookie exchange? 2) Should tlstm recognize whether it is enabled/disabled? 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in syslog when the implementation can detect an overload on server resources? 4) in syslog, would it be better to specify the actions of the DTLS entity rather than "the transport receiver"? Does the draft spell out clearly whether the "transport receiver" is the DTLS client or DTLS server? When a syslog entity can act as both sender and receiver, what is that implementation REQUIRED to support in terms of DTLS client and DTLS server? I didn't see that in the text prior to section 5.3.1; should this be made clear in the terminology section? Should there be mandatory-to-implement text about this? -- DCCP -- syslog/dtls supports the dccp transport: As the Internet best runs on the basis of appropriate resource sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this document. For systems where DCCP is either not available or not usable (such as the afformentioned situation), DTLS over UDP is also defined. In those circumstances where reliability or ordering is important, SYSLOG over TLS is appropriate. Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution. and DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. and When TCP is used syslog over DTLS MUST NOT be used. If a secure transport is required with TCP then the appropriate mechanism is syslog over TLS. although we are discussing: Based on some advice from Lars, I recommend s/Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. / Implementations of this specification MUST support both DTLS over UDP and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but implementations of this specification MUST be prepared to support DCCP where it is available." I notice DCCP is not mentioned by TLSTM. I'm not sure how much extra work it would take to add DCCP support to snmp/dtls. -- ports -- Since DTLS can run over DCCP, tlstm might want to define a domain for that while you're at it (or not). -- cipher suites -- syslog: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. tsltm: does not define a mandatory-to-implement cipher suite. Could this impact interoperability? I know this is one of those points that keeps getting discussed. 1) A mandatory-to-implement cipher suite ensures that different implementations will have at least one suite that cna be used for interoperability. 2) But doesn't DTLS already define mandatory-to-implement cipher suites? Do we need to do that here as well? Isn't it inherited from DTLS? How's this for a discussion starter? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From Robert.Story@cobham.com Thu Feb 4 18:08: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 CF2653A6BF0; Thu, 4 Feb 2010 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Xzwxrs2X5tQt; Thu, 4 Feb 2010 18:08:31 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id AD1293A6A5E; Thu, 4 Feb 2010 18:08:31 -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 o1529DRR024783; Thu, 4 Feb 2010 20:09:13 -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 o1529CXa030099; Thu, 4 Feb 2010 20:09:13 -0600 Received: from sparta.com ([190.234.20.253]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 21:09:12 -0500 Date: Thu, 4 Feb 2010 21:09:03 -0500 From: Robert Story To: "David Harrington" Message-ID: <20100204210903.329b595a@sparta.com> In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.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_/R.u15V3AUgmoLwrMVHyvy4m"; protocol="application/pgp-signature" X-OriginalArrivalTime: 05 Feb 2010 02:09:12.0480 (UTC) FILETIME=[35B9D200:01CAA608] Cc: syslog@ietf.org, isms@ietf.org Subject: Re: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 02:08:33 -0000 --Sig_/R.u15V3AUgmoLwrMVHyvy4m Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Feb 2010 16:37:38 -0500 David wrote: DH> syslog: DH> Implementations MUST support DH> the denial of service countermeasures defined by DTLS. When these DH> countermeasures are enabled, the transport receiver responds with a DH> DTLS Hello Verify Request containing a cookie. =20 DH> snmp: DH> DTLS Transport DH> Model server implementations MUST support DTLS cookies. DH>=20 DH> Implementations are not required to perform the stateless DH> cookie DH> exchange for every DTLS handshake, but in environments where an DH> overload on server side resources is detectable by the DH> implementation it is RECOMMENDED that the cookie exchange is DH> utilized by the implementation. DH>=20 DH> My impression is that syslog allows an admin to enable this as a DH> deployment option; tlstm seems to depend on the implementation. Hmm... DTLS says that cookies MUST be supported, so it seems like simply mentioning that admins can enabled it, as opposed to only RECOMMENDING it under special circumstances, would bring the two in line. DH> 1) Is enable/disable capability a MUST implement for DTLS cookie DH> exchange? Does syslog have this MUST, or simply a mention of 'when it is enabled' implying it is configurable? I agree that parity would be good, and it would be nice for it to be configurable. DH> Since DTLS can run over DCCP, tlstm might want to define a domain for DH> that while you're at it (or not). Couldn't hurt to add a domain and say implementations MAY support DCCP, but I don't think it's worth it if it's going to hold up the document. DH> Could this impact interoperability? I know this is one of those points DH> that keeps getting discussed.=20 DH> 1) A mandatory-to-implement cipher suite ensures that different DH> implementations will have at least one suite that cna be used for DH> interoperability.=20 DH> 2) But doesn't DTLS already define mandatory-to-implement cipher DH> suites? Do we need to do that here as well? Isn't it inherited from DH> DTLS? I vote for 2, that we inherit from DTLS... --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/R.u15V3AUgmoLwrMVHyvy4m Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAktrfcIACgkQ7/fVLLY1mnh6hACgiRRcpS9SSps4asYAhBVPW9vk R/8An2GVtTrOBBoruD9HmS0cHd5lpj0r =bivQ -----END PGP SIGNATURE----- --Sig_/R.u15V3AUgmoLwrMVHyvy4m-- From randy_presuhn@mindspring.com Thu Feb 4 22:44: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 5ABB53A6DB0 for ; Thu, 4 Feb 2010 22:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 obfeZL7V5IiV for ; Thu, 4 Feb 2010 22:44:51 -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 BD5A028C0E7 for ; Thu, 4 Feb 2010 22:44:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GfKfRCnavShasVjEr/5/rGFkY0JUWKUAjO2TFLdSmEhXj4gPo+UpVVEJvzR4vmPP; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NdHwh-0006cl-9K for isms@ietf.org; Fri, 05 Feb 2010 01:45:39 -0500 Received: from 113.170.20.9 by webmail.earthlink.net with HTTP; Fri, 5 Feb 2010 01:45:39 -0500 Message-ID: <27688781.1265352339213.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Fri, 5 Feb 2010 13:45:39 +0700 (GMT+07:00) From: Randy Presuhn To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4059f59ef94242dd160ed1786f782cecd0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Subject: Re: [Isms] JSo: hard-wire to TSM? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn 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 Feb 2010 06:44:52 -0000 Hi - Agreed. I think there is some need for some text on "environmental assumptions / requirements" both on this question and on assumptions about the transport (per David Harrington's earlier comment). I have extremely limited internet access right now, but should be able to resume work on the document on February 17th or so. Randy -----Original Message----- >From: "David B. Nelson" >Sent: Feb 2, 2010 10:02 PM >To: isms@ietf.org >Subject: Re: [Isms] JSo: hard-wire to TSM? > >On Jan 29, 2010, at 7:04 PM, Randy Presuhn wrote: > >> I think we're in agreement. The existence of such a use case, >> no matter how razor-thin, makes the absolute "MUST" problematic. >> The person who'd be concerned about the SHOULD/MUST >> distinction here would be someone developing another security model. >> Though health warnings are often appropriate in cases like this, >> I'm happy with the implicit warning that comes with every SHOULD. >> But if you'd like to supply some more explicit health warnings to >> go along with the SHOULD, I'd be happy to include them. > >I would like to submit some "health warnings" text for inclusion in >the Security Considerations section. I'm currently "on deadline" for >some more pressing deliverables, so it may be a little while before I >get to this. > > > > >_______________________________________________ >Isms mailing list >Isms@ietf.org >https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Thu Feb 4 22:50: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 23F273A6E9E for ; Thu, 4 Feb 2010 22:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 KWb9DnF77IOs for ; Thu, 4 Feb 2010 22:50:46 -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 516103A6EAA for ; Thu, 4 Feb 2010 22:50:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Qidw4YU89Z4547sDIy9f0topRfySwwBrFbe1HRNQXhsv2dFFzxlz3bbFlfxyljrA; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NdI2R-0000qH-ES for isms@ietf.org; Fri, 05 Feb 2010 01:51:35 -0500 Received: from 113.170.20.9 by webmail.earthlink.net with HTTP; Fri, 5 Feb 2010 01:51:35 -0500 Message-ID: <12692670.1265352695389.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Fri, 5 Feb 2010 13:51:35 +0700 (GMT+07:00) From: Randy Presuhn To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b402768f6a2c2c32345b36bf3a0f262696a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Subject: Re: [Isms] extVacmRowLifetime X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn 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 Feb 2010 06:50:47 -0000 Hi - -----Original Message----- >From: David Harrington >Sent: Feb 1, 2010 9:19 PM >To: 'Randy Presuhn' , isms@ietf.org >Subject: RE: [Isms] extVacmRowLifetime ... >I assume you refer to a security model in the SNMP engine. I do not >understand how you concluded that the security model knows anything >about the session lifetime; SNMP has no sessions. Transport models >might recognize transport sessions. So it would need to be a >RADIUS-enabled transport model that exposed the session lifetime, no? Yes. There are assumptions about the services provided that need to be made explicit. However, if there is visibility of transport session establishment and termination, there is no need for visibility of the lifetime information from RADIUS, since the RADIUS semantics of session lifetime require the transport to terminate the session upon expiration of the lifetime anyway. Randy From j.schoenwaelder@jacobs-university.de Fri Feb 5 01:33:50 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 CF16E3A69B9; Fri, 5 Feb 2010 01:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ygOCArbTI+wg; Fri, 5 Feb 2010 01:33:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 40E453A6880; Fri, 5 Feb 2010 01:33:49 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 635DCC003F; Fri, 5 Feb 2010 10:34:38 +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 e4k68XijfgbA; Fri, 5 Feb 2010 10:34:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B9CAC0006; Fri, 5 Feb 2010 10:34:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B4CA103F3B0; Fri, 5 Feb 2010 10:34:23 +0100 (CET) Date: Fri, 5 Feb 2010 10:34:23 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100205093423.GA41873@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , "isms@ietf.org" , "'Joseph Salowey (jsalowey)'" , "syslog@ietf.org" References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "syslog@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 09:33:50 -0000 On Wed, Feb 03, 2010 at 10:37:38PM +0100, David Harrington wrote: > -- DoS -- > > syslog: > Implementations MUST support > the denial of service countermeasures defined by DTLS. When these > countermeasures are enabled, the transport receiver responds with a > DTLS Hello Verify Request containing a cookie. > snmp: > DTLS Transport > Model server implementations MUST support DTLS cookies. > > Implementations are not required to perform the stateless > cookie > exchange for every DTLS handshake, but in environments where an > overload on server side resources is detectable by the > implementation it is RECOMMENDED that the cookie exchange is > utilized by the implementation. > > My impression is that syslog allows an admin to enable this as a > deployment option; tlstm seems to depend on the implementation. (and I > have difficulty knowing how an implementation will know if overlaod on > server side is detectable, unless it is doing the detection itself.) > 1) Is enable/disable capability a MUST implement for DTLS cookie > exchange? > 2) Should tlstm recognize whether it is enabled/disabled? > 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in > syslog when the implementation can detect an overload on server > resources? > 4) in syslog, would it be better to specify the actions of the DTLS > entity rather than "the transport receiver"? Does the draft spell out > clearly whether the "transport receiver" is the DTLS client or DTLS > server? When a syslog entity can act as both sender and receiver, what > is that implementation REQUIRED to support in terms of DTLS client and > DTLS server? I didn't see that in the text prior to section 5.3.1; > should this be made clear in the terminology section? Should there be > mandatory-to-implement text about this? I suggest that some DTLS expert suggests text that is adequate. It seems to me that the ISMS text is better than the SYSLOG text but I am not too deeply involved in DTLS matters. > -- DCCP -- > > syslog/dtls supports the dccp transport: > As the Internet best runs on the basis of appropriate resource > sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this > document. For systems where DCCP is either not available or not > usable (such as the afformentioned situation), DTLS over UDP is > also > defined. In those circumstances where reliability or ordering is > important, SYSLOG over TLS is appropriate. Syslog over TLS does > not > provide application layer acknowledgements and therefore is not a > fully reliable solution. > and > DTLS can run over multiple transports. Implementations of this > specification MUST support DTLS over UDP and SHOULD support DTLS > over > DCCP [RFC5238]. > and > When TCP is used syslog over DTLS MUST NOT be used. If a secure > transport is required with TCP then the appropriate mechanism is > syslog over TLS. > > although we are discussing: > Based on some advice from Lars, I recommend > s/Implementations of this specification MUST support DTLS over UDP and > SHOULD support DTLS over DCCP [RFC5238]. / > Implementations of this specification MUST support both DTLS over UDP > and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but > implementations of this specification MUST be prepared to support DCCP > where it is available." > > I notice DCCP is not mentioned by TLSTM. > I'm not sure how much extra work it would take to add DCCP support to > snmp/dtls. Nobody ever asked for DCCP and I am reluctant to start new efforts to add DCCP support. SNMP runs over UDP for more than 20 years and for a single CG-CR transport, transactions are pretty much stop-and-wait (multi-threaded retrievals like those described in RFC 1187 never really took off because they spoil the caching on typical agents). SYSLOG is quite different here since it is fire-and-forget and as such a SYSLOG sender will never adapt to the speed of the network. In other words, unless Lars raises a flag that SNMP over UDP is not acceptable anymore after 20+ years of deployment, I am reluctant to add explicit text concerning DCCP. And if Lars successfully raises a flag that SNMP over UDP is not acceptable anymore, we do have a bigger problem to solve. > -- ports -- > > Since DTLS can run over DCCP, tlstm might want to define a domain for > that while you're at it (or not). The ISMS WG never asked for DCCP and unless the IESG requires us to add DCCP support, I do not think we need to do this. > -- cipher suites -- > > syslog: > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support > the > mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. > tsltm: > does not define a mandatory-to-implement cipher suite. > > Could this impact interoperability? I know this is one of those points > that keeps getting discussed. > 1) A mandatory-to-implement cipher suite ensures that different > implementations will have at least one suite that cna be used for > interoperability. > 2) But doesn't DTLS already define mandatory-to-implement cipher > suites? Do we need to do that here as well? Isn't it inherited from > DTLS? This was discussed in the ISMS WG and I think we concluded that the TLS specs define mandatory to implement cipher suites and that it is counter productive to have our own list since we want to pick up new mandatory cipher suites in case TLS specs move on because e.g. a cipher is broken. In short, it is the job of the TLS specs to define mandatory to implement ciphers. /js -- 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 Fri Feb 5 04:14:39 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 DB92128C11E for ; Fri, 5 Feb 2010 04:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.230, 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 oQJiYkMGQLFU for ; Fri, 5 Feb 2010 04:14:38 -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 79B2B3A6D78 for ; Fri, 5 Feb 2010 04:14:37 -0800 (PST) X-Trace: 290869785/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.186 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: AtUEACiaa0s+vGS6/2dsb2JhbACCJiyFKIkAuFkJjUwCCoI2FYF1BA X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="290869785" X-IP-Direction: IN Received: from 1cust186.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.186]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Feb 2010 12:15:23 +0000 Message-ID: <004301caa654$715d8b20$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20100202145048.GA9823@elstar.local> Date: Fri, 5 Feb 2010 09: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 Subject: Re: [Isms] dtls document writeup 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 Feb 2010 12:14:40 -0000 Juergen I think that the document should also be pointed at the Transport Directorate in 1c). You mention a review by a TLS expert there, which is something I appreciate. I think the description of certificate handling wrong, although not wrong enough to say any more than I have already said, so if a(nother) TLS expert says fine, then I will revise my views. I won't appeal, or raise this again. But I have also expressed concern over transport, the description of the differences between TCP and UDP, which, for me, do not exist at the protocol level, rather at the implementation detail of what code libraries are currently available. I have reservations about how much of that should be normative specification in a RFC, and think that this goes too far. Again, I have said this all already and don't plan to say any more but would appreciate a review by the Transport Directorate. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, February 02, 2010 3:50 PM Subject: [Isms] dtls document writeup > Hi, > > now that we have cleared up the counters, I believe we are pretty much > done with the (D)TLS transport mapping. I plan to deliver the > document to our AD by the end of this week. Attached is my document > writeup in case you want to review it before it goes to Pasi. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > Document: draft-ietf-isms-dtls-tm-08.txt > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > Juergen Schoenwaelder is the document shepherd. I have reviewed the > document several times including thef latest version and I believe it > is ready for forwarding it to the IESG for publication. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > The document has received WG last call reviews from > > - Andrew Donati > - Pasi Eronen > - Juergen Schoenwaelder > - Hamid Mukhtar > - Alan Luchuk > - Joe Salowey > - David Harrington > - Tom Petch > - Robert Story > > and I do not have any concerns regarding the level of review for this > document. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > The document might benefit from a review of the TLS certificate > handling procedures by some TLS expert; perhaps this can be dealt with > as part of the security directorate review. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > I do not have any specific concerns. > No IPR disclosure been filed as far as we know. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > The document has WG consensus and the WG wants the document to be > published as a Proposed Standard. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > No-one has threatened with an appeal or expressed extreme discontent. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > The document has been checked with idnits 2.12.00 and the warnings > generated are all intentional or bugs in the tool. The document > contains a MIB module and should go through the MIB doctor review > processs. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > References are split in Normative and Informative. All normative > documents have been published. > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > > The document requests a number of assignment in existing registries. > It does not create any new registries. I believe the IANA instructions > are clear. > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The MIB module has been checked using smilint for syntactic > correctness. > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > 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. > > Working Group Summary > > The working group went over several revisions of this document > and the document and all WG last call comments have been > resolved. There has been strong WG consensus to publish this > document as Proposed Standard. > > Document Quality > There are two known implementations in progress of the > (D)TLS Transport Model. > From j.schoenwaelder@jacobs-university.de Fri Feb 5 04:27: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 D809028C0DD for ; Fri, 5 Feb 2010 04:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 ZOs2b4vlQpcm for ; Fri, 5 Feb 2010 04:27:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3201428C115 for ; Fri, 5 Feb 2010 04:27:47 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09449C0324; Fri, 5 Feb 2010 13:28:37 +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 gJLWFilzSJv3; Fri, 5 Feb 2010 13:28:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9C4AC0323; Fri, 5 Feb 2010 13:28:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F5551043235; Fri, 5 Feb 2010 13:28:22 +0100 (CET) Date: Fri, 5 Feb 2010 13:28:22 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100205122822.GA60673@elstar.local> Mail-Followup-To: "tom.petch" , "isms@ietf.org" References: <20100202145048.GA9823@elstar.local> <004301caa654$715d8b20$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301caa654$715d8b20$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] dtls document writeup 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 Feb 2010 12:27:49 -0000 On Fri, Feb 05, 2010 at 09:41:18AM +0100, tom.petch wrote: > I think that the document should also be pointed at the Transport > Directorate in 1c). [...] > But I have also expressed concern over transport, the description of > the differences between TCP and UDP, which, for me, do not exist at > the protocol level, rather at the implementation detail of what code > libraries are currently available. I have reservations about how > much of that should be normative specification in a RFC, and think > that this goes too far. Again, I have said this all already and > don't plan to say any more but would appreciate a review by the > Transport Directorate. Please help me by naming the section(s) in the document you think the Transport Directorate should look at. /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 Fri Feb 5 04:44: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 A1BF63A6EAE for ; Fri, 5 Feb 2010 04:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 PKzI94oQT2Ib for ; Fri, 5 Feb 2010 04:44:04 -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 AEC263A6C0B for ; Fri, 5 Feb 2010 04:44:04 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id eBKs1d0051wpRvQ5ECkvvN; Fri, 05 Feb 2010 12:44:55 +0000 Received: from NEWTON603 ([71.232.143.198]) by omta18.westchester.pa.mail.comcast.net with comcast id eClp1d0074H2mdz3eClp23; Fri, 05 Feb 2010 12:45:49 +0000 From: "Dave Nelson" To: References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> Date: Fri, 5 Feb 2010 07:45:08 -0500 Message-ID: <570CF0B3A65846D091760F46ADC50893@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqmRnS9g39XZ6TzQYmZiSKZwWHpZQAGYfKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20100205093423.GA41873@elstar.local> Subject: Re: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 12:44:05 -0000 Juergen Schoenwaelder writes... > In other words, unless Lars raises a flag that SNMP over UDP > is not acceptable anymore after 20+ years of deployment, I am > reluctant to add explicit text concerning DCCP. My personal view on this is that there has historically been a tendency in the IETF to stimulate demand for deployment of new transport protocols by placing a requirement to use them in any vaguely appropriate application layer document that happens to be coming along at the time. My opinion is that's not always appropriate. I won't suggest that's necessarily the case here, because I haven't been following the work on syslog. Just sayin' ... > This was discussed in the ISMS WG and I think we concluded that the > TLS specs define mandatory to implement cipher suites and that it is > counter productive to have our own list since we want to pick up new > mandatory cipher suites in case TLS specs move on because e.g. a > cipher is broken. Agreed. From cfinss@dial.pipex.com Fri Feb 5 06:58: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 2FEBF3A6DC8; Fri, 5 Feb 2010 06:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 VA+g4XNROCbl; Fri, 5 Feb 2010 06:58:13 -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 5331B3A6C05; Fri, 5 Feb 2010 06:58:12 -0800 (PST) X-Trace: 236593456/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.10/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.10 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: AhMGAD/Ba0s+vGkK/2dsb2JhbACCJoVViQHGaQyCRIICBA X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="236593456" X-IP-Direction: IN Received: from 1cust10.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.10]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Feb 2010 14:58:59 +0000 Message-ID: <022b01caa66b$4bbd7760$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "David Harrington" References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> Date: Fri, 5 Feb 2010 14:56:59 +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: syslog@ietf.org, isms@ietf.org Subject: Re: [Isms] [Syslog] syslog/dtls and snmp/dtls 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 Feb 2010 14:58:14 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, February 05, 2010 10:34 AM > On Wed, Feb 03, 2010 at 10:37:38PM +0100, David Harrington wrote: > > > -- DoS -- > > > > syslog: > > Implementations MUST support > > the denial of service countermeasures defined by DTLS. When these > > countermeasures are enabled, the transport receiver responds with a > > DTLS Hello Verify Request containing a cookie. > > snmp: > > DTLS Transport > > Model server implementations MUST support DTLS cookies. > > > > Implementations are not required to perform the stateless > > cookie > > exchange for every DTLS handshake, but in environments where an > > overload on server side resources is detectable by the > > implementation it is RECOMMENDED that the cookie exchange is > > utilized by the implementation. > > > > My impression is that syslog allows an admin to enable this as a > > deployment option; tlstm seems to depend on the implementation. (and I > > have difficulty knowing how an implementation will know if overlaod on > > server side is detectable, unless it is doing the detection itself.) > > 1) Is enable/disable capability a MUST implement for DTLS cookie > > exchange? As Robert said, it is a SHOULD in RFC4347 which I think enough. > > 2) Should tlstm recognize whether it is enabled/disabled? > > 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in > > syslog when the implementation can detect an overload on server > > resources? see above > > 4) in syslog, would it be better to specify the actions of the DTLS > > entity rather than "the transport receiver"? No. SNMP subdivides the solution space into many more pieces, introducing EOPs, ASIs, etc in order to do so. syslog takes a much simpler view of what the implementer needs to be told, and I think there is no merit in subdividing the stack further. Once started, where do you stop? Adding tlstm section 5.5.1?:-) > > Does the draft spell out > > clearly whether the "transport receiver" is the DTLS client or DTLS > > server? syslog-dtls 5.2. Port Assignment A SYSLOG transport sender is always a DTLS client and a transport receiver is always a DTLS server. > > When a syslog entity can act as both sender and receiver, what > > is that implementation REQUIRED to support in terms of DTLS client and > > DTLS server? I didn't see that in the text prior to section 5.3.1; > > should this be made clear in the terminology section? Should there be > > mandatory-to-implement text about this? > > I suggest that some DTLS expert suggests text that is adequate. It > seems to me that the ISMS text is better than the SYSLOG text but I am > not too deeply involved in DTLS matters. > > > -- DCCP -- > > > > syslog/dtls supports the dccp transport: > > As the Internet best runs on the basis of appropriate resource > > sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this > > document. For systems where DCCP is either not available or not > > usable (such as the afformentioned situation), DTLS over UDP is > > also > > defined. In those circumstances where reliability or ordering is > > important, SYSLOG over TLS is appropriate. Syslog over TLS does > > not > > provide application layer acknowledgements and therefore is not a > > fully reliable solution. > > and > > DTLS can run over multiple transports. Implementations of this > > specification MUST support DTLS over UDP and SHOULD support DTLS > > over > > DCCP [RFC5238]. > > and > > When TCP is used syslog over DTLS MUST NOT be used. If a secure > > transport is required with TCP then the appropriate mechanism is > > syslog over TLS. > > > > although we are discussing: > > Based on some advice from Lars, I recommend > > s/Implementations of this specification MUST support DTLS over UDP and > > SHOULD support DTLS over DCCP [RFC5238]. / > > Implementations of this specification MUST support both DTLS over UDP > > and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but To follow a sentence saying this is a MUST with one that says it is not does not seem like an improvement to me. > > implementations of this specification MUST be prepared to support DCCP > > where it is available." > > > > I notice DCCP is not mentioned by TLSTM. > > I'm not sure how much extra work it would take to add DCCP support to > > snmp/dtls. > > Nobody ever asked for DCCP and I am reluctant to start new efforts to > add DCCP support. SNMP runs over UDP for more than 20 years and for a > single CG-CR transport, transactions are pretty much stop-and-wait > (multi-threaded retrievals like those described in RFC 1187 never > really took off because they spoil the caching on typical > agents). SYSLOG is quite different here since it is fire-and-forget > and as such a SYSLOG sender will never adapt to the speed of the > network. In other words, unless Lars raises a flag that SNMP over UDP > is not acceptable anymore after 20+ years of deployment, I am > reluctant to add explicit text concerning DCCP. And if Lars > successfully raises a flag that SNMP over UDP is not acceptable > anymore, we do have a bigger problem to solve. agree > > -- ports -- > > > > Since DTLS can run over DCCP, tlstm might want to define a domain for > > that while you're at it (or not). > > The ISMS WG never asked for DCCP and unless the IESG requires us to > add DCCP support, I do not think we need to do this. > > > -- cipher suites -- > > > > syslog: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support > > the > > mandatory to implement cipher suite, which is > > TLS_RSA_WITH_AES_128_CBC_SHA. > > tsltm: > > does not define a mandatory-to-implement cipher suite. > > > > Could this impact interoperability? I know this is one of those points > > that keeps getting discussed. > > 1) A mandatory-to-implement cipher suite ensures that different > > implementations will have at least one suite that cna be used for > > interoperability. > > 2) But doesn't DTLS already define mandatory-to-implement cipher > > suites? Do we need to do that here as well? Isn't it inherited from > > DTLS? > > This was discussed in the ISMS WG and I think we concluded that the > TLS specs define mandatory to implement cipher suites and that it is > counter productive to have our own list since we want to pick up new > mandatory cipher suites in case TLS specs move on because e.g. a > cipher is broken. In short, it is the job of the TLS specs to define > mandatory to implement ciphers. The counter argument is twofold. One is that the (D)TLS specs move on in a world of their own, probably leading edge and out of this world for many users thereof. Thus the recent discussions on renegotiation have highlighted how many people are using SSL and how many implementations do not conform to the enhancements introduced in TLS1.0 ie (a part of) the real world is 11 years behind the cryptographic experts. Including the current received wisdom gives a sanity check. Second, users have to go find it, they have to navigate their way through the RFC chain, understanding that RFC are never re-issued but may be superseded, so if they want the latest view, they need to consult and understand rfc-index. What I am hinting at here is that my experience of the syslog list is very different to that on eg OPSAWG or isms; the former has less of the IETF culture, more of people doing their own thing and needing a little steer in the right direction. I did survey the then current specs of application-over-TLS for this and found that some do, some don't, and that 'do' seemed right for syslog. Tom Petch > /js From cfinss@dial.pipex.com Fri Feb 5 11:35: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 9215928C164 for ; Fri, 5 Feb 2010 11:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, 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 P42WyzJheKTt for ; Fri, 5 Feb 2010 11:35:28 -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 62AE928C0EC for ; Fri, 5 Feb 2010 11:35:28 -0800 (PST) X-Trace: 236713680/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.233/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.233 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: AhMGALIBbEs+vGnp/2dsb2JhbACCJoVViQG5eQmNPQIKglGBdQQ X-IronPort-AV: E=Sophos;i="4.49,414,1262563200"; d="scan'208";a="236713680" X-IP-Direction: IN Received: from 1cust233.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.233]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Feb 2010 19:36:17 +0000 Message-ID: <00be01caa692$09447d80$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20100202145048.GA9823@elstar.local> <004301caa654$715d8b20$0601a8c0@allison> <20100205122822.GA60673@elstar.local> Date: Fri, 5 Feb 2010 19:25:26 +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] dtls document writeup 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 Feb 2010 19:35:29 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Subject: Re: [Isms] dtls document writeup > On Fri, Feb 05, 2010 at 09:41:18AM +0100, tom.petch wrote: > > > I think that the document should also be pointed at the Transport > > Directorate in 1c). > > [...] > > > But I have also expressed concern over transport, the description of > > the differences between TCP and UDP, which, for me, do not exist at > > the protocol level, rather at the implementation detail of what code > > libraries are currently available. I have reservations about how > > much of that should be normative specification in a RFC, and think > > that this goes too far. Again, I have said this all already and > > don't plan to say any more but would appreciate a review by the > > Transport Directorate. > > Please help me by naming the section(s) in the document you think the > Transport Directorate should look at. Sections 5.1, 5.1.1, 5.1.2 Tom Petch > /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 Feb 5 21:17: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 EB72B3A6914; Fri, 5 Feb 2010 21:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 RK0vPQ-Gz12Z; Fri, 5 Feb 2010 21:17:56 -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 9341628C0D9; Fri, 5 Feb 2010 21:17:55 -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 o165IYO6021828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 00:18:35 -0500 (EST) Date: Sat, 06 Feb 2010 00:18:34 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Juergen Schoenwaelder , David Harrington Message-ID: <4AD43B85C08C08969E7BB71E@MINBAR.FAC.CS.CMU.EDU> In-Reply-To: <23259_1265381948_o15Ex76K028706_022b01caa66b$4bbd7760$0601a8c0@allison> References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> <23259_1265381948_o15Ex76K028706_022b01caa66b$4bbd7760$0601a8c0@allison> 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: syslog@ietf.org, isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] [Syslog] syslog/dtls and snmp/dtls 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 Feb 2010 05:17:58 -0000 --On Friday, February 05, 2010 02:56:59 PM +0100 "tom.petch" wrote: >> Nobody ever asked for DCCP and I am reluctant to start new efforts to >> add DCCP support. SNMP runs over UDP for more than 20 years and for a >> single CG-CR transport, transactions are pretty much stop-and-wait >> (multi-threaded retrievals like those described in RFC 1187 never >> really took off because they spoil the caching on typical >> agents). SYSLOG is quite different here since it is fire-and-forget >> and as such a SYSLOG sender will never adapt to the speed of the >> network. In other words, unless Lars raises a flag that SNMP over UDP >> is not acceptable anymore after 20+ years of deployment, I am >> reluctant to add explicit text concerning DCCP. And if Lars >> successfully raises a flag that SNMP over UDP is not acceptable >> anymore, we do have a bigger problem to solve. > > agree As do I From j.schoenwaelder@jacobs-university.de Mon Feb 8 02:11: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 A94F53A733C; Mon, 8 Feb 2010 02:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 CGWQL91+TX3z; Mon, 8 Feb 2010 02:11:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0E40B3A7338; Mon, 8 Feb 2010 02:11:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAD5AC0020; Mon, 8 Feb 2010 11:12:10 +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 zD2jHK9sxWnL; Mon, 8 Feb 2010 11:12:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C0ADC0064; Mon, 8 Feb 2010 11:12:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 50401104D21E; Mon, 8 Feb 2010 11:11:55 +0100 (CET) Date: Mon, 8 Feb 2010 11:11:55 +0100 From: Juergen Schoenwaelder To: Pasi Eronen Message-ID: <20100208101155.GB33606@elstar.local> Mail-Followup-To: Pasi Eronen , iesg-secretary@ietf.org, 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) Cc: iesg-secretary@ietf.org, isms@ietf.org Subject: [Isms] Request to publish draft-ietf-isms-dtls-tm-08.txt as Proposed Standard RFC 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 Feb 2010 10:11:24 -0000 Pasi, the ISMS chairs believe that the ISMS WG has reached concensus on draft-ietf-isms-dtls-tm-08.txt and we request publication of this document as Proposed Standard RFC. Below is the document shepherd writeup for draft-ietf-isms-dtls-tm-08.txt. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including thef latest version and I believe it is ready for forwarding it to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received WG last call reviews from - Andrew Donati - Pasi Eronen - Juergen Schoenwaelder - Hamid Mukhtar - Alan Luchuk - Joe Salowey - David Harrington - Tom Petch - Robert Story and I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document might benefit from a review of the TLS certificate handling procedures by some TLS expert; perhaps this can be dealt with as part of the security directorate review. Note that there are TLS transport mapping documents for other management protocol produced by other working groups (NETCONF over TLS [RFC 5539], SYSLOG over TLS [RFC5425], SYSLOG over DTLS [draft-ietf-syslog-dtls-01.txt]); while the authors/editors of these documents were aware of the other documents and tried to align things, an independent review of consistency of operations between these protocols might be useful. Sections 5.1, 5.1.1, 5.1.2 should be reviewed by the transport area directors (or the transport directorate) to ensure the multiplexing language is correct. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been checked with idnits 2.12.00 and the warnings generated are all intentional or bugs in the tool. The document contains a MIB module and should go through the MIB doctor review processs. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document requests a number of assignment in existing registries. It does not create any new registries. I believe the IANA instructions are clear. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module has been checked using smilint for syntactic correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary 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. Working Group Summary The working group went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality There are two known implementations in progress of the (D)TLS Transport Model. /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 Feb 8 02:21: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 689183A7341 for ; Mon, 8 Feb 2010 02:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185, 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 WOd+m8WOSitx for ; Mon, 8 Feb 2010 02:21:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 702073A7310 for ; Mon, 8 Feb 2010 02:21:07 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22E7EC0018 for ; Mon, 8 Feb 2010 11:22:09 +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 kAjYdmX3ozks; Mon, 8 Feb 2010 11:22:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26292C0014; Mon, 8 Feb 2010 11:22:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C915104D295; Mon, 8 Feb 2010 11:21:55 +0100 (CET) Date: Mon, 8 Feb 2010 11:21:55 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100208102155.GC33606@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] comment on the dtls submission to the ad/iesg 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 Feb 2010 10:21:12 -0000 Hi, the ISMS chairs believe that the dtls document, after extensive WG last call periods, has reached WG concensus and hence we decided to submit the document via our AD to the IESG for publication as Proposed Standard. Any concerns that this document is inconsistent with other specifications being developed by other WGs can be raised as IETF last call comments and then be resolved with the active involvement of the respective IESG members. Special review requests have been included in the document writeup. /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 Mon Feb 8 09:22:27 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 002093A7247; Mon, 8 Feb 2010 09:22: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 buBPDQsSCqq4; Mon, 8 Feb 2010 09:22:26 -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 E79C23A720D; Mon, 8 Feb 2010 09:21:56 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 2AA4B980DB; Mon, 8 Feb 2010 09:21:49 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> Date: Mon, 08 Feb 2010 09:21:48 -0800 In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 3 Feb 2010 16:37:38 -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: syslog@ietf.org, isms@ietf.org Subject: Re: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 17:22:27 -0000 >>>>> On Wed, 3 Feb 2010 16:37:38 -0500, "David Harrington" said: [cut to just the ISMS document's wording:] DH> DTLS Transport Model server implementations MUST support DTLS DH> cookies. DH> Implementations are not required to perform the stateless cookie DH> exchange for every DTLS handshake, but in environments where an DH> overload on server side resources is detectable by the DH> implementation it is RECOMMENDED that the cookie exchange is DH> utilized by the implementation. [And your comments:] DH> My impression is that syslog allows an admin to enable this as a DH> deployment option; tlstm seems to depend on the implementation. (and I DH> have difficulty knowing how an implementation will know if overlaod on DH> server side is detectable, unless it is doing the detection itself.) DH> Actually, we require it to be implemented but we're rather flexible on how it's actually used. Intentionally. I decided that there wouldn't be problems if different implementations did different things. Some implementations could have it configurable; others could do automatic detection, etc. So we certainly support the same case that syslog is doing, but we also allow implementations more flexibility. I don't believe this impacts interoperability of our base protocol. DH> 1) Is enable/disable capability a MUST implement for DTLS cookie DH> exchange? Not currently. DH> 2) Should tlstm recognize whether it is enabled/disabled? That's diving into protocol layers we said we wouldn't dive into. Specifically, I was requested not mention DTLS specific protocol message types in the document (like the syslog/DTLS document does). DH> 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in DH> syslog when the implementation can detect an overload on server DH> resources? Then that would prohibit an implementation from doing a runtime on/off/maybe setting. So personally, no, I don't see the need. But I also don't feel strongly about it. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Feb 8 09:23:18 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 57A2C28C156; Mon, 8 Feb 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 Cm725qfWbd-o; Mon, 8 Feb 2010 09:23:17 -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 BEBCC28C140; Mon, 8 Feb 2010 09:23:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id F210D9806D; Mon, 8 Feb 2010 09:23:18 -0800 (PST) From: Wes Hardaker To: David Harrington Organization: Sparta References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> Date: Mon, 08 Feb 2010 09:23:18 -0800 In-Reply-To: <20100205093423.GA41873@elstar.local> (Juergen Schoenwaelder's message of "Fri, 5 Feb 2010 10:34:23 +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: "syslog@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] syslog/dtls and snmp/dtls 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 Feb 2010 17:23:18 -0000 >>>>> On Fri, 5 Feb 2010 10:34:23 +0100, Juergen Schoenwaelder said: >> -- cipher suites -- JS> This was discussed in the ISMS WG and I think we concluded that the JS> TLS specs define mandatory to implement cipher suites and that it is JS> counter productive to have our own list since we want to pick up new JS> mandatory cipher suites in case TLS specs move on because e.g. a JS> cipher is broken. In short, it is the job of the TLS specs to define JS> mandatory to implement ciphers. I agree; that's my recollection too (and one I agree with). -- Wes Hardaker Cobham Analytic Solutions From Pasi.Eronen@nokia.com Thu Feb 25 05:22: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 D4A3B28C2D2 for ; Thu, 25 Feb 2010 05:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 nl2R9qWAyLPL for ; Thu, 25 Feb 2010 05:22:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 99DBA28C280 for ; Thu, 25 Feb 2010 05:22:02 -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 o1PDO8t4008677 for ; Thu, 25 Feb 2010 07:24:12 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 15:23:55 +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); Thu, 25 Feb 2010 15:23:55 +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; Thu, 25 Feb 2010 14:23:54 +0100 From: To: Date: Thu, 25 Feb 2010 14:23:53 +0100 Thread-Topic: AD review comments for draft-ietf-isms-dtls-tm-08 Thread-Index: Acq2HcZ0tkcwx5yLTDSj8MmBzFfQvw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> 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: 25 Feb 2010 13:23:55.0257 (UTC) FILETIME=[C79A5E90:01CAB61D] X-Nokia-AV: Clean Subject: [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: Thu, 25 Feb 2010 13:22:05 -0000 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 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 =3D 1 (specified) tlstmCertToTSNSecurityName =3D "blueberry" NEW: tlstmCertToTSNMapType =3D tlstmCertSpecified tlstmCertToTSNData =3D "blueberry" - C.2: OLD tlstmCertToTSNMapType =3D 2 (bySubjectAltName) tlstmCertToTSNSANType =3D 1 (any) NEW: tlstmCertToTSNMapType =3D tlstmCertSANAny tlstmCertToTSNData =3D "" (not used) - Overall: "certificate authority" -> "certification authority" Best regards, Pasi From wjhns1@hardakers.net Thu Feb 25 18:50: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 E14A628C2AF for ; Thu, 25 Feb 2010 18:50:44 -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 oAgkfXzUctjg for ; Thu, 25 Feb 2010 18:50:44 -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 09D9728C147 for ; Thu, 25 Feb 2010 18:50:44 -0800 (PST) Received: from localhost (unknown [166.203.28.140]) by mail.hardakers.net (Postfix) with ESMTPSA id 6B9F49AD02; Thu, 25 Feb 2010 18:52:54 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7758480C36CA@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 25 Feb 2010 18:52:53 -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: Fri, 26 Feb 2010 02:50:45 -0000 PE> I've now done my AD review for draft-ietf-isms-dtls-tm-08, and bunch PE> of comments. Thanks for the comments Pasi. I'll review them and respond to them hopefully on Monday. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Thu Feb 25 22:11: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 37E4C28C1CB for ; Thu, 25 Feb 2010 22:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 SncGzHvM5vAR for ; Thu, 25 Feb 2010 22:11:30 -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 455AD28C173 for ; Thu, 25 Feb 2010 22:11:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DKLbw9ivAsPy0l2Z/he/zdrm4CsxuKK71v6mkXcTdtDGaqkDx5V8Q9w/3LrWkv+Q; 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.60.5.228] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NktSI-00045v-Di for isms@ietf.org; Fri, 26 Feb 2010 01:13:42 -0500 Message-ID: <000c01cab6ab$88e5b9e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:18:36 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b405f2759968a11edaca4451c4c1681abd0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 06:11:33 -0000 Hi - The current i-d (draft-ietf-isms-radius-vacm-03.txt) contains several counters. Working through the elements of procedure, I've come to the conclusion that they'd really not be much help in the operational situations I've been able to think of. To be even potentially useful, one would need to know for which user / security model combination the error occurred. In those cases, the number of occurrances isn't as interesting as whether and when the event occurred. To me this means that if we bother tracking these corner cases at all (and I'm NOT convinced that they're worth tracking!) that Notifications, rather than counters would be appropriate. (A notification could carry the entry from the extVacmSecurityToGroupTable, which would be all the interesting stuff a security administrator would need to diagnose a problem.) The corner case remaining is where memory allocation fails for the extVacmSecurityToGroupTable. Frankly, this case seems exceedingly pathological. I can't come up with a realistic recovery strategy that a network manager might undertake in this case, and don't see the point in counting it. For the implementations I'm familiar with, if internal memory is so tight that the extVacmSecurityToGroupTable allocation would fail, there'd be serious doubt whether *any* response at all would get out of the (sub)agent. As a strawman position, I propose eliminating *all* the counters in the MIB module. If we find that they (or notifications) are useful during early implementation efforts, we can add the ones with proven utility at that time. Randy From randy_presuhn@mindspring.com Thu Feb 25 22:12: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 5FFA528C1CB for ; Thu, 25 Feb 2010 22:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.182, 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 xKPABUaJ9QRS for ; Thu, 25 Feb 2010 22:12: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 3F85228C199 for ; Thu, 25 Feb 2010 22:12:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WbrqTb5DAxyUZUgFH91+UJIWothYYeQrRsize5lqB5PdkxgLGmwKs78XTOF5bd9k; 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.60.5.228] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NktT9-0005Qh-Dq for isms@ietf.org; Fri, 26 Feb 2010 01:14:35 -0500 Message-ID: <000d01cab6ab$a9897060$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:19:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4039264748d4c64d8558b573e5d7ce1859350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [Isms] VACM/RADIUS issue: on/off switch 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, 26 Feb 2010 06:12:24 -0000 Hi - Should the RADIUS/VACM integration have an off switch? Randy From randy_presuhn@mindspring.com Thu Feb 25 22:16: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 E476A28C199 for ; Thu, 25 Feb 2010 22:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 v4fg5nwNoDLA for ; Thu, 25 Feb 2010 22:16:03 -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 B2CEC3A861F for ; Thu, 25 Feb 2010 22:16:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QpIKfqhNFuRG3tPT6Q+RH4IxBAzSqda6ROOhvmAU6rDCiLrm7JJ5UwO/YNsjYIuF; 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.60.5.228] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NktWh-0006PZ-RU for isms@ietf.org; Fri, 26 Feb 2010 01:18:16 -0500 Message-ID: <001301cab6ac$2cf27dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:23:12 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b408f13692a3fd275848c80fb672f00f8cb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [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: Fri, 26 Feb 2010 06:16:05 -0000 Hi - The current i-d has this open issue: 1. Is this document an amendment or update to RFC 3514? Or is it simply a standalone document that describes how to provision certain MIB Objects defined in RFC 3514, along with an extended set of augmenting table columns? I propose closing this one. We have a standalone document that describes how to (internally to an implementation) provision certain MIB objects defined in RFC 3514. Randy From randy_presuhn@mindspring.com Thu Feb 25 22:17: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 EC11D3A873D for ; Thu, 25 Feb 2010 22:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 NOmNPNjGn7im for ; Thu, 25 Feb 2010 22:17:48 -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 767E128C199 for ; Thu, 25 Feb 2010 22:17:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BDZouMepVwD/JRB2KBDBzahfpbipNdotC5KudpFhMZinMu5sMo3yyZKcsqyQlyjL; 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.60.5.228] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NktYO-0006zF-Lw for isms@ietf.org; Fri, 26 Feb 2010 01:20:00 -0500 Message-ID: <001901cab6ac$6b69b3c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:24:57 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40948d7d894717c035a487604c5338299d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [Isms] RADIUS/VACM 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: Fri, 26 Feb 2010 06:17:51 -0000 Hi - The existing issue list says: 2. Does this document need to make any reference to the Elements of Procedure in RFC 3514, or does is simply need its own Elements of Procedure for updating the group mapping table? I believe we can close this one. We don't change the RFC 3514 elements of procedure in any way. Other than saying just that, we don't need to reference those elements of procedure. Randy From randy_presuhn@mindspring.com Thu Feb 25 22:20: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 CFE8228C508 for ; Thu, 25 Feb 2010 22:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 K0fghWp3xqdw for ; Thu, 25 Feb 2010 22:20:46 -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 742D228C4F4 for ; Thu, 25 Feb 2010 22:20:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ijHAXoYWnMZixB2yQphph8VggBkUU1v8jP9y23ElewfVI8l6APahqV6W1RG4nZU4; 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.60.5.228] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NktbH-0000iM-KW for isms@ietf.org; Fri, 26 Feb 2010 01:22:59 -0500 Message-ID: <001f01cab6ac$d60a2660$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:27:56 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40d8aeffd36993ba25ecc4c04293a80963350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [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: Fri, 26 Feb 2010 06:20:47 -0000 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. Randy From randy_presuhn@mindspring.com Thu Feb 25 22:28: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 62D1928C50F for ; Thu, 25 Feb 2010 22:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 D7EgRaEfd5oW for ; Thu, 25 Feb 2010 22:28:25 -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 460153A861F for ; Thu, 25 Feb 2010 22:28:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Id2aNJaK5Irs8m7EgC4C74tEkVo5c4uhH5BArE2JEYLeUSMSCbsgcOLsjVvmTitk; 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.60.5.228] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nktig-0002Vf-D3 for isms@ietf.org; Fri, 26 Feb 2010 01:30:38 -0500 Message-ID: <000c01cab6ad$e75e6100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:35:34 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b402afee46c103b20d2ef6d7fc02bdbd597350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [Isms] RADIUS/VACM 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, 26 Feb 2010 06:28:26 -0000 Hi - Currently, there is this item in the issue list - 4. The Groups and Conformance sections of the MIB Module need to be checked and kept in alignment with the definitions. I think this can be removed - the groups and conformance material are aligned with the rest of the document. Randy From randy_presuhn@mindspring.com Thu Feb 25 22:33:33 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 87A483A8742 for ; Thu, 25 Feb 2010 22:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 IZli4aPP5Uhl for ; Thu, 25 Feb 2010 22:33:32 -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 5C4A53A863E for ; Thu, 25 Feb 2010 22:33:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J2iJs0zxiBfA2uARRsRznyNGABibXhLxTPzwELKwUWdT1vmtHXCks1Wze70eTwUi; 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.60.5.228] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nktnd-0004oR-OI for isms@ietf.org; Fri, 26 Feb 2010 01:35:46 -0500 Message-ID: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 25 Feb 2010 22:40:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40562127fd7c7ebf3b2ee8d9ccba8f708c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [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: Fri, 26 Feb 2010 06:33:33 -0000 Hi - Currently there is this issue in the list - 6. for session tracking use tlstmSessionID? I propose closing it. The current table organization does have a session ID. My working copy says: 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." ::= { extVacmSecurityToGroupEntry 3 } So this *could* be tlstmSessionID, and that would be the easiest thing for an implementation to use, but there's no reason to require it, as far as I know. Randy From j.schoenwaelder@jacobs-university.de Thu Feb 25 23:23: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 9DF5A3A8621 for ; Thu, 25 Feb 2010 23:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, HELO_EQ_DE=0.35, TRACKER_ID=2.003] 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 3nYdlb9-PY4g for ; Thu, 25 Feb 2010 23:23:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6BEDC3A7B06 for ; Thu, 25 Feb 2010 23:23:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C297DC0007; Fri, 26 Feb 2010 08:25:22 +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 GtNfG5VB6JGA; Fri, 26 Feb 2010 08:25: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 EE609C0002; Fri, 26 Feb 2010 08:25:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B69E6109A4F3; Fri, 26 Feb 2010 08:25:03 +0100 (CET) Date: Fri, 26 Feb 2010 08:25:03 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226072503.GC32786@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000c01cab6ab$88e5b9e0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cab6ab$88e5b9e0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 07:23:10 -0000 On Fri, Feb 26, 2010 at 07:18:36AM +0100, Randy Presuhn wrote: [...] > As a strawman position, I propose eliminating *all* the counters in > the MIB module. If we find that they (or notifications) are useful > during early implementation efforts, we can add the ones with proven > utility at that time. I am fine with the strawman position. However, it is important to note that these counters track error situations during the processing of a RADIUS message by the NAS, so normal SNMP error handling does not apply and I guess this was the motivation to add these counters. extVacmResourceError: What is common practice in RADIUS land if a NAS is being told to do something but fails to do so due to resource constraints? Am I right that specs tend to be silent about this and implementors simply use syslog? extVacmNoPolicy Looks like the counter is ill defined. It is not an error to point to a non-existing access table in VACM; it is perfectly valid to do so to say "no access". The description in section 6.1.3 also does not seem to be consistent with the counter definition. I think both places benfit if the counter goes away. extVacmSecurityNameConflict This could be a useful counter or event to report. However, creating a static entry can also be a means to (temporarily) disable the automatic creation of mappings, which would then lead to regular counter increments or notifications. That said, I am fine with the strategy of leaving the counter out until we have more implementation experience. /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 Feb 25 23:27: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 A63D63A873E for ; Thu, 25 Feb 2010 23:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, 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 R36HLPt-Gzzg for ; Thu, 25 Feb 2010 23:27:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 73DEA3A8635 for ; Thu, 25 Feb 2010 23:27:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD039C0007; Fri, 26 Feb 2010 08:29:41 +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 RXwxE2NfIQMs; Fri, 26 Feb 2010 08:29:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF607C0002; Fri, 26 Feb 2010 08:29:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7C32E109A59C; Fri, 26 Feb 2010 08:29:25 +0100 (CET) Date: Fri, 26 Feb 2010 08:29:25 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226072925.GD32786@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000d01cab6ab$a9897060$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01cab6ab$a9897060$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] VACM/RADIUS issue: on/off switch 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, 26 Feb 2010 07:27:29 -0000 On Fri, Feb 26, 2010 at 07:19:32AM +0100, Randy Presuhn wrote: > Should the RADIUS/VACM integration have an off switch? Is a global on/off switch not the same as a switch to enable/disable the NAS? Can we expect some RADIUS configuration interface to provide such a switch? My understanding is that once the NAS has received the RADIUS decision, it has to do what the RADIUS server told the NAS. If we can switch off the VACM part, what does the NAS do? It likely then has to reject the whole session since it can't do what the RADIUS server told it to do. So would the switch not better be placed in the NAS itself? /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 Feb 25 23:54:18 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 25EB63A8720 for ; Thu, 25 Feb 2010 23:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 uhsjJdTEF4BT for ; Thu, 25 Feb 2010 23:54:17 -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 60EE73A864B for ; Thu, 25 Feb 2010 23:54:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=l7yu9AejmCLdiGon+SGW+SdEuju37FtCWTRwo/Q0D5SHbGyvOxmIYRLf3g7Ek014; 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.5.228] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nkv3m-000260-OB for isms@ietf.org; Fri, 26 Feb 2010 02:56:31 -0500 Message-ID: <000401cab6b9$e5e251e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000d01cab6ab$a9897060$6801a8c0@oemcomputer> <20100226072925.GD32786@elstar.local> Date: Fri, 26 Feb 2010 00:01:25 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40e9c7bb6f3c7ffcc6c2c38183a002f1a6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: Re: [Isms] VACM/RADIUS issue: on/off switch 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, 26 Feb 2010 07:54:18 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, February 25, 2010 11:29 PM > Subject: Re: [Isms] VACM/RADIUS issue: on/off switch > > On Fri, Feb 26, 2010 at 07:19:32AM +0100, Randy Presuhn wrote: > > > Should the RADIUS/VACM integration have an off switch? > > Is a global on/off switch not the same as a switch to enable/disable > the NAS? Can we expect some RADIUS configuration interface to provide > such a switch? My understanding is that once the NAS has received the > RADIUS decision, it has to do what the RADIUS server told the NAS. If > we can switch off the VACM part, what does the NAS do? It likely then > has to reject the whole session since it can't do what the RADIUS > server told it to do. So would the switch not better be placed in the > NAS itself? Ok, so I guess we can just close this one as "not our problem" and no action needed. :-) Randy From randy_presuhn@mindspring.com Fri Feb 26 00:03: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 D70C23A7B03 for ; Fri, 26 Feb 2010 00:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 H1wtQil3j6+G for ; Fri, 26 Feb 2010 00:03:16 -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 0F3AB3A7929 for ; Fri, 26 Feb 2010 00:03:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TKsIYPqYEyZx+1XgxRggp6ZbuqNrVM59czChw0o0TKG7eqYiwbwnP0RwyUo2MXjm; 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.5.228] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NkvCT-0008Ct-BV for isms@ietf.org; Fri, 26 Feb 2010 03:05:29 -0500 Message-ID: <000901cab6bb$2788d960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000c01cab6ab$88e5b9e0$6801a8c0@oemcomputer> <20100226072503.GC32786@elstar.local> Date: Fri, 26 Feb 2010 00:10:25 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a9025872028b791b4ac2476dfe4496ea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: Re: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 08:03:21 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, February 25, 2010 11:25 PM > Subject: Re: [Isms] VACM/RADIUS issue: counters ... > > As a strawman position, I propose eliminating *all* the counters in > > the MIB module. If we find that they (or notifications) are useful > > during early implementation efforts, we can add the ones with proven > > utility at that time. > > I am fine with the strawman position. However, it is important to note > that these counters track error situations during the processing of a > RADIUS message by the NAS, so normal SNMP error handling does not > apply and I guess this was the motivation to add these counters. Though I'm starting to think that we really don't even need to mention RADIUS message processing, but rather just session initiation / termination indications from the secure transport model in question. But that's another discussion. > extVacmResourceError: > > What is common practice in RADIUS land if a NAS is being told to > do something but fails to do so due to resource constraints? Am I > right that specs tend to be silent about this and implementors > simply use syslog? That would make more sense - an implementation that hits this situation is in such trouble that I wouldn't even count on syslog working terribly well. > extVacmNoPolicy > > Looks like the counter is ill defined. It is not an error to point > to a non-existing access table in VACM; it is perfectly valid to > do so to say "no access". The description in section 6.1.3 also > does not seem to be consistent with the counter definition. I > think both places benfit if the counter goes away. Strongly agree. I think the VACM semantics for non-existant groups/policies work out very well here. We can't really distinguish this case from a policy which only allows access to things that don't exist. :-) > extVacmSecurityNameConflict > > This could be a useful counter or event to report. However, > creating a static entry can also be a means to (temporarily) > disable the automatic creation of mappings, which would then lead > to regular counter increments or notifications. That said, I am > fine with the strategy of leaving the counter out until we have > more implementation experience. Ok, so unless someone really really wants them, I'll get rid of them. It's easier to add such things to a clean-up EOP than it is to try to clean up the EOP while keeping counters that may or may not be operationally justified. Randy From j.schoenwaelder@jacobs-university.de Fri Feb 26 00:42: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 4EB0B3A84EE for ; Fri, 26 Feb 2010 00:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.168, 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 89HOkSNpELKy for ; Fri, 26 Feb 2010 00:42:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 455713A84D7 for ; Fri, 26 Feb 2010 00:42:37 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2017C0013; Fri, 26 Feb 2010 09:44:50 +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 2GxD6QyZxOTV; Fri, 26 Feb 2010 09:44:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D05FC0002; Fri, 26 Feb 2010 09:44:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2830109A78D; Fri, 26 Feb 2010 09:44:33 +0100 (CET) Date: Fri, 26 Feb 2010 09:44:33 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226084433.GA33124@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001301cab6ac$2cf27dc0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301cab6ac$2cf27dc0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) 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 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, 26 Feb 2010 08:42:38 -0000 On Fri, Feb 26, 2010 at 07:23:12AM +0100, Randy Presuhn wrote: > The current i-d has this open issue: > 1. Is this document an amendment or update to RFC 3514? Or is it > simply a standalone document that describes how to provision > certain MIB Objects defined in RFC 3514, along with an extended > set of augmenting table columns? > > I propose closing this one. We have a standalone document that > describes how to (internally to an implementation) provision > certain MIB objects defined in RFC 3514. As far as I recall, we do not touch any of the RFC 3514 semantics and hence it seems reasonable that we do not claim to update RFC 3514. /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 Feb 26 00:43: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 14C9C3A845B for ; Fri, 26 Feb 2010 00:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, 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 F2czqUzZb6yl for ; Fri, 26 Feb 2010 00:43:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 41EB73A8405 for ; Fri, 26 Feb 2010 00:43:13 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9BA1C0007; Fri, 26 Feb 2010 09:45:26 +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 06FZPMJ6hU5k; Fri, 26 Feb 2010 09:45:26 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15400C0002; Fri, 26 Feb 2010 09:45:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D8050109A7BE; Fri, 26 Feb 2010 09:45:10 +0100 (CET) Date: Fri, 26 Feb 2010 09:45:10 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226084510.GB33124@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001901cab6ac$6b69b3c0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901cab6ac$6b69b3c0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM 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: Fri, 26 Feb 2010 08:43:14 -0000 On Fri, Feb 26, 2010 at 07:24:57AM +0100, Randy Presuhn wrote: > Hi - > > The existing issue list says: > 2. Does this document need to make any reference to the Elements of > Procedure in RFC 3514, or does is simply need its own Elements of > Procedure for updating the group mapping table? > > I believe we can close this one. We don't change the RFC 3514 elements > of procedure in any way. Other than saying just that, we don't need > to reference those elements of procedure. Agreed. /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 Feb 26 00:43: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 2DEAC3A764F for ; Fri, 26 Feb 2010 00:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 HdH2O9yul+tZ for ; Fri, 26 Feb 2010 00:43: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 6D8BE3A72CE for ; Fri, 26 Feb 2010 00:43:52 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15FFAC0013; Fri, 26 Feb 2010 09:46:06 +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 sqma0m3usQ1F; Fri, 26 Feb 2010 09:46:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD0E5C0007; Fri, 26 Feb 2010 09:46:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96B58109A814; Fri, 26 Feb 2010 09:45:49 +0100 (CET) Date: Fri, 26 Feb 2010 09:45:49 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226084549.GC33124@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001f01cab6ac$d60a2660$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01cab6ac$d60a2660$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM 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: Fri, 26 Feb 2010 08:43:53 -0000 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 From j.schoenwaelder@jacobs-university.de Fri Feb 26 00:44: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 49E353A764F for ; Fri, 26 Feb 2010 00:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 2yOZzBUbKbnB for ; Fri, 26 Feb 2010 00:44: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 623F43A72CE for ; Fri, 26 Feb 2010 00:44:56 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AC01C0015; Fri, 26 Feb 2010 09:47:10 +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 i7Gts4U-NxEp; Fri, 26 Feb 2010 09:47: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 37BA9C0013; Fri, 26 Feb 2010 09:47:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 01F79109A868; Fri, 26 Feb 2010 09:46:53 +0100 (CET) Date: Fri, 26 Feb 2010 09:46:53 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226084653.GD33124@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000c01cab6ad$e75e6100$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cab6ad$e75e6100$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM issue 4 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, 26 Feb 2010 08:44:57 -0000 On Fri, Feb 26, 2010 at 07:35:34AM +0100, Randy Presuhn wrote: > Hi - > > Currently, there is this item in the issue list - > 4. The Groups and Conformance sections of the MIB Module need to be > checked and kept in alignment with the definitions. > > I think this can be removed - the groups and conformance material > are aligned with the rest of the document. Great. /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 Feb 26 00:51:00 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 102893A84EF for ; Fri, 26 Feb 2010 00:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 tb5diG1rNu9g for ; Fri, 26 Feb 2010 00:50:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 09F8E3A72CE for ; Fri, 26 Feb 2010 00:50:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9F47C0015; Fri, 26 Feb 2010 09:53:12 +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 X0xa7Y+SpTXy; Fri, 26 Feb 2010 09:53:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23501C0013; Fri, 26 Feb 2010 09:53:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0EBD109A8E2; Fri, 26 Feb 2010 09:52:55 +0100 (CET) Date: Fri, 26 Feb 2010 09:52:55 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226085255.GE33124@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM issue 6 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, 26 Feb 2010 08:51:00 -0000 On Fri, Feb 26, 2010 at 07:40:42AM +0100, Randy Presuhn wrote: > Hi - > > Currently there is this issue in the list - > > 6. for session tracking use tlstmSessionID? > > I propose closing it. The current table organization does > have a session ID. My working copy says: > > 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." > ::= { extVacmSecurityToGroupEntry 3 } > > So this *could* be tlstmSessionID, and that would be the easiest thing > for an implementation to use, but there's no reason to require it, > as far as I know. 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? /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 Feb 26 01:05:39 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 EB6D73A6774 for ; Fri, 26 Feb 2010 01:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 K7I7CsNvhCof for ; Fri, 26 Feb 2010 01:05:39 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 8EBD43A8633 for ; Fri, 26 Feb 2010 01:05:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CQN9uiJc3Mff2qr1K6eV0y/JOdTRLTkPe034Co0YRvkkEXYTTCl0vVkUpfzcrqcs; 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.5.228] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NkwAq-000837-9q for isms@ietf.org; Fri, 26 Feb 2010 04:07:52 -0500 Message-ID: <001c01cab6c3$de47b600$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> <20100226085255.GE33124@elstar.local> Date: Fri, 26 Feb 2010 01:12:48 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40f9a801c0b69c0c9d56bf5f8ba186214b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 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: Fri, 26 Feb 2010 09:05:40 -0000 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 From root@core3.amsl.com Fri Feb 26 01: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 D0E873A866F; Fri, 26 Feb 2010 01: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: <20100226093001.D0E873A866F@core3.amsl.com> Date: Fri, 26 Feb 2010 01:30:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-04.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: Fri, 26 Feb 2010 09: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 : Extensions to the View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-04.txt Pages : 20 Date : 2010-02-26 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) and 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-26012513.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Fri Feb 26 01:30: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 34A2928C0E9 for ; Fri, 26 Feb 2010 01:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 svkH2NdaxgZv for ; Fri, 26 Feb 2010 01:30:54 -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 B66D53A8670 for ; Fri, 26 Feb 2010 01:30:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jPTFz6f8XcXAYCydn/GCgrV1mQSZ70cdqEQ4JwCeCE2nbXne6o5HEw1ta0LZEPAH; 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.60.5.228] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NkwZE-0000HL-Es for isms@ietf.org; Fri, 26 Feb 2010 04:33:04 -0500 Message-ID: <002801cab6c7$638fdc40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Fri, 26 Feb 2010 01:38:00 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4036ce95c1d8e39ca4acd9a14569418faa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.228 Subject: [Isms] RADIUS/VACM id 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, 26 Feb 2010 09:30:55 -0000 Hi - I've submitted an updated I-D; the announcement should soon appear. I've made fairly substantial changes based on the discussion so far. There's still quite a bit of redundancy, in my opinion, but I think the *function* is what we've agreed on. Let me know if I've gotten something wrong, or if I've cut something important. Randy From j.schoenwaelder@jacobs-university.de Fri Feb 26 01:41: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 113693A8279 for ; Fri, 26 Feb 2010 01:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 ywdO+6kBPp4Q for ; Fri, 26 Feb 2010 01:41:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 076C63A8684 for ; Fri, 26 Feb 2010 01:41:05 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7620C0017; Fri, 26 Feb 2010 10:43:18 +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 U+47ldOlwBa6; Fri, 26 Feb 2010 10:43:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B911C0015; Fri, 26 Feb 2010 10:43:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8401D109AA72; Fri, 26 Feb 2010 10:43:01 +0100 (CET) Date: Fri, 26 Feb 2010 10:43:00 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100226094259.GA33319@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001201cab6ae$9e9351a0$6801a8c0@oemcomputer> <20100226085255.GE33124@elstar.local> <001c01cab6c3$de47b600$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01cab6c3$de47b600$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM issue 6 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, 26 Feb 2010 09:41:06 -0000 On Fri, Feb 26, 2010 at 10:12:48AM +0100, Randy Presuhn wrote: > 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 } I like this better, gives a clear hint that tlstmSessionID satisfies the requirements. /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 Fri Feb 26 08:29: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 5A2253A83CF for ; Fri, 26 Feb 2010 08:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TRACKER_ID=2.003] 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 JpJoKu6bmEzp for ; Fri, 26 Feb 2010 08:29:22 -0800 (PST) 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 2137E3A82FA for ; Fri, 26 Feb 2010 08:29:22 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id md9x1d0070mv7h054gXdYx; Fri, 26 Feb 2010 16:31:37 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta11.westchester.pa.mail.comcast.net with comcast id mgXd1d0092PzLBw3XgXdg1; Fri, 26 Feb 2010 16:31:37 +0000 Date: Fri, 26 Feb 2010 16:31:37 +0000 (UTC) From: d.b.nelson@comcast.net To: Juergen Schoenwaelder Message-ID: <448749644.1208261267201897508.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <20100226072503.GC32786@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [166.137.139.229] X-Mailer: Zimbra 5.0.19_GA_3172.RHEL5_64 (zclient/5.0.19_GA_3172.RHEL5_64) Cc: isms@ietf.org Subject: Re: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 16:29:23 -0000 Please forgive the lack of message trimming. I'm at home with no power and email only via iPhone. I think removing the error counters is a big mistake. I'll elaborate when I can do so using a real keyboard. ;-) ----- Original Message ----- From: Juergen Schoenwaelder To: Randy Presuhn Cc: isms@ietf.org Sent: Fri, 26 Feb 2010 07:25:03 +0000 (UTC) Subject: Re: [Isms] VACM/RADIUS issue: counters On Fri, Feb 26, 2010 at 07:18:36AM +0100, Randy Presuhn wrote: [...] > As a strawman position, I propose eliminating *all* the counters in > the MIB module. If we find that they (or notifications) are useful > during early implementation efforts, we can add the ones with proven > utility at that time. I am fine with the strawman position. However, it is important to note that these counters track error situations during the processing of a RADIUS message by the NAS, so normal SNMP error handling does not apply and I guess this was the motivation to add these counters. extVacmResourceError: What is common practice in RADIUS land if a NAS is being told to do something but fails to do so due to resource constraints? Am I right that specs tend to be silent about this and implementors simply use syslog? extVacmNoPolicy Looks like the counter is ill defined. It is not an error to point to a non-existing access table in VACM; it is perfectly valid to do so to say "no access". The description in section 6.1.3 also does not seem to be consistent with the counter definition. I think both places benfit if the counter goes away. extVacmSecurityNameConflict This could be a useful counter or event to report. However, creating a static entry can also be a means to (temporarily) disable the automatic creation of mappings, which would then lead to regular counter increments or notifications. That said, I am fine with the strategy of leaving the counter out until we have more implementation experience. /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 randy_presuhn@mindspring.com Fri Feb 26 12: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 8DC9E3A8841 for ; Fri, 26 Feb 2010 12:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 iBRG-0OF4ZEZ for ; Fri, 26 Feb 2010 12:07:21 -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 56E643A8839 for ; Fri, 26 Feb 2010 12:07:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MwaM5t4K5QG2QtdpABC9642c+sA+CltD3XD4xJtXUceFiDH6mp93RbW2tl72V0HU; 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.26.29] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nl6VE-0006dr-U1 for isms@ietf.org; Fri, 26 Feb 2010 15:09:37 -0500 Message-ID: <002901cab720$4f1cbb80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <448749644.1208261267201897508.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> Date: Fri, 26 Feb 2010 12:14:31 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4026739531eed7dba7aff0bd91dea5332b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.26.29 Subject: Re: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 20:07:22 -0000 Hi - Here are all the events I can think of that someone might conceivably find interesting. These don't *exactly* match the ones that were in previous versions of the draft, but some are pretty close. (1) radius server fails to provide a user/group mapping - Since, however, its possible that a suitable mapping already exists in VACM, this isn't necessarily an error. Even if it *is* an error, a counter by itself isn't useful. What would be needed would be the security model and security name. Since the elements of procedure do not (currently) create an extVacmSecurityToGroupEntry in this case, we would need to add accessible-for-notify objects along with a notification definition to carry this information. If a security administrator has subscribed to this notification, what next? (2) the security model / security name / session ID triple corresponds to an extVacmSecurityToGroupEntry which already exists. With RADIUS this would suggest an internal logic error, with some other AAA protocol it might (I'm imagining) be the result of the user of an existing session having been assiged to a different group while the session was up. The most robust thing to do in this case seems to me to treat is an an update of the user/group mapping. In any case, once again a simple counter wouldn't provide enough information to be useful. A notification could carry the information, but would beg the question of whether it should carry the old group, the new group, or both. If a security administrator has subscribed to this notification, what "recovery action" (if it is an error) would he/she take? (3) insufficient memory to allocate a new extVacmSecurityToGroupEntry - Do we expect security administrators to poll this? What recovery action would be possible? In many implementations, several malloc() operations can happen in the course of processing an SNMP message, but we certainly *don't* treat all these possible points of failure/recovery as countable events. Requiring a notification in this case would be even worse, because notification generation logic is almost certain to have greater malloc() requirements than an entry in the extVacmTable. (4) the group name provided by RADIUS currently is not in use by the vacmAccessTable - Operationally, I don't see how this is any different from a security adminstrator creating a group called "NoAccessAllowed" with no corresponding entries in the vacmAccessTable. In terms of how VACM functions, the results are exactly the same. If we did track this condition, once again it would be best conveyed in a notification, since any conceivable recovery action would need to know which user and which group was the problem. However, *if* we go down this path, wouldn't we also want to consider the case where, for example, due to a security administrator's updates to the vacmAccessTable, all the entries indexed by a particular group are deleted, even though they may have been present at the time the extVacmTableEntry was created? I think this goes far beyond the point of diminishing returns. (5) Insufficient memory to create / update vacmSecurityToGroupEntry - See (3) above. (6) Session termination indication refers to a non-existent session - A notification would be the appropriate vehicle for this, though it would require adding some accessible-for-notify objects to carry the information. I can't imagine what a security administrator could do to recover from this kind of internal logic error, except perhaps for cycling power. (7) No vacmSecurityToGroupEntry exists corresponding to the extVacmSecurityToGroupEntry which has just been deleted - This could happen, for example, when a security administrator has deleted the vacmSecurityToGroupEntry in question. A notification would be the sensible vehicle for this. Since the extVacmSecurityToGroupEntry in question would already have been deleted by the time this condition is detected, we'd need to add accessible-for-notify objects to report it. I have no idea what meaningful action a security administrator could take upon receipt of this notification, other than perhaps to make sure that it was indeed one of his/her authorized colleagues or applications that deleted the entry in question. As a technical contributor, I remain unconvinced that any of these would be worth the specification or implementation effort. As an editor, I'll happily put back or add whatever the WG gets consensus on. Randy From randy_presuhn@mindspring.com Fri Feb 26 13:50:39 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 499193A8861 for ; Fri, 26 Feb 2010 13:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 7-B-6qePaDmC for ; Fri, 26 Feb 2010 13:50:36 -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 692E13A8855 for ; Fri, 26 Feb 2010 13:50:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dHLBqjfjYBKW2EeXOYIucxfUJF1s+7iZZCQbE8AiMRkKb3xpIRCa1tl9Nhqrhas/; 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.26.29] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nl87A-000600-3r for isms@ietf.org; Fri, 26 Feb 2010 16:52:52 -0500 Message-ID: <002301cab72e$bc98f580$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <448749644.1208261267201897508.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <002901cab720$4f1cbb80$6801a8c0@oemcomputer> Date: Fri, 26 Feb 2010 13:57:47 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40eaeb8ae1497d28f7772058f457095368350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.26.29 Subject: Re: [Isms] VACM/RADIUS issue: counters 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, 26 Feb 2010 21:50:39 -0000 Hi - > From: "Randy Presuhn" > To: > Sent: Friday, February 26, 2010 12:14 PM > Subject: Re: [Isms] VACM/RADIUS issue: counters ... > (6) Session termination indication refers to a non-existent session - > > A notification would be the appropriate vehicle for this, though > it would require adding some accessible-for-notify objects to > carry the information. > > I can't imagine what a security administrator could do to recover > from this kind of internal logic error, except perhaps for cycling power. ... Upon further refleciton... As the elements of procedure are currently formulated, this situation is indistinguishable from the case where the start-of-session indication did not (for whatever reason) trigger the creation of an extVacmIUserToGroupEntry. If we *really* care about distinguishing this case, we'd need a extVacmUserToGroupEntry corresponding to *every* start-of-session indication, including those providing no (or a zero-length) group mapping. Doing so could *slightly* simplify the elements of procedure, but whether we do so or not, I remain unconvinced that this case is worth tracking. Randy From randy_presuhn@mindspring.com Sun Feb 28 21:15: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 3E4BA3A88C3 for ; Sun, 28 Feb 2010 21:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 bA6uYt9FRkwW for ; Sun, 28 Feb 2010 21:15:13 -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 622E43A860D for ; Sun, 28 Feb 2010 21:15:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rPmjdXHnW7J+hQUhqnIBcKUvzlpB16QKD/qp+yXNngNUt5FpyCxPjgKp/eJ6v569; 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.55.174.152] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NlxyL-0000Pe-Hs for isms@ietf.org; Mon, 01 Mar 2010 00:15:13 -0500 Message-ID: <000c01cab8fe$4dca7bc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Sun, 28 Feb 2010 21:16:08 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b407d7d6baf1ce0b7c19776b971966cde5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.152 Subject: [Isms] RADIUS/VACM document structure 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 05:15:14 -0000 Hi - In draft-ietf-isms-radius-vacm-04.txt, the structure of section 6 seems a bit over-wrought: 6. Relationship to Other MIB Modules 6.1. Relationship to the VACM MIB 6.1.1. Extended VACM for RADIUS Authorization 6.1.2. VACM Extension for RADIUS Authorization 6.1.2.1. Dynamic Update of VACM and Extended VACM MIB Module Objects 6.1.2.2. Purging Entries in the Extended VACM MIB Module 6.1.3. Elements of Procedure for Extended VACM 6.2. MIB modules required for IMPORTS Furthermore, there is substantial redundancy between 6.1.1 through 6.1.2.2 and 6.1.3. I'd like to propose a re-organization / collapse to something like this: 6. Relationship to Other MIB Modules 6.1. Relationship to the VACM MIB 6.2. MIB modules required for IMPORTS 7. Elements of Procedure 7.1. Sequencing Requirements 7.2. Actions Upon Session Establishment Indication 7.2.1. Creation of Entries in extVacmSecurityToGroupTable 7.2.2. Creation of Entries in vacmSecurityToGroupTable 7.2.3. Update of vacmGroupName 7.3. Actions Upon Session Termination Indication 7.3.1. Deletion of Entries from extVacmSecurityToGroupTable 7.3.2. Deletion of Entries from vacmSecurityToGroupTable I think this would make the document easier to read, understand, and implement. Comments? Randy From j.schoenwaelder@jacobs-university.de Sun Feb 28 22:00: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 A1FA828C212 for ; Sun, 28 Feb 2010 22:00:19 -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 XaO2I5xrkmGi for ; Sun, 28 Feb 2010 22:00:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9105B28C24E for ; Sun, 28 Feb 2010 22:00:18 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23AAFC0007; Mon, 1 Mar 2010 07:00:18 +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 LzK1XnUKBpYP; Mon, 1 Mar 2010 07:00: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 6C020C0004; Mon, 1 Mar 2010 07:00:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 77144109F384; Mon, 1 Mar 2010 07:00:00 +0100 (CET) Date: Mon, 1 Mar 2010 07:00:00 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100301060000.GB40151@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000c01cab8fe$4dca7bc0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cab8fe$4dca7bc0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] RADIUS/VACM document structure 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, 01 Mar 2010 06:00:19 -0000 On Mon, Mar 01, 2010 at 06:16:08AM +0100, Randy Presuhn wrote: > In draft-ietf-isms-radius-vacm-04.txt, the structure of section 6 > seems a bit over-wrought: > > 6. Relationship to Other MIB Modules > 6.1. Relationship to the VACM MIB > 6.1.1. Extended VACM for RADIUS Authorization > 6.1.2. VACM Extension for RADIUS Authorization > 6.1.2.1. Dynamic Update of VACM and Extended VACM MIB > Module Objects > 6.1.2.2. Purging Entries in the Extended VACM MIB Module > 6.1.3. Elements of Procedure for Extended VACM > 6.2. MIB modules required for IMPORTS > > Furthermore, there is substantial redundancy between > 6.1.1 through 6.1.2.2 and 6.1.3. > > I'd like to propose a re-organization / collapse to something > like this: > > 6. Relationship to Other MIB Modules > 6.1. Relationship to the VACM MIB > 6.2. MIB modules required for IMPORTS > > 7. Elements of Procedure > 7.1. Sequencing Requirements > 7.2. Actions Upon Session Establishment Indication > 7.2.1. Creation of Entries in extVacmSecurityToGroupTable > 7.2.2. Creation of Entries in vacmSecurityToGroupTable > 7.2.3. Update of vacmGroupName > 7.3. Actions Upon Session Termination Indication > 7.3.1. Deletion of Entries from extVacmSecurityToGroupTable > 7.3.2. Deletion of Entries from vacmSecurityToGroupTable > > I think this would make the document easier to read, understand, and > implement. Comments? Makes sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103