From j.schoenwaelder@jacobs-university.de Fri Jan 1 03:52: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 784E73A6803 for ; Fri, 1 Jan 2010 03:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.763 X-Spam-Level: **** X-Spam-Status: No, score=4.763 tagged_above=-999 required=5 tests=[AWL=-6.545, BAYES_50=0.001, FH_DATE_PAST_20XX=10.357, 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 gACbA79wlCg2 for ; Fri, 1 Jan 2010 03:52:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 60D9B3A67F0 for ; Fri, 1 Jan 2010 03:52:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43E13C0009; Fri, 1 Jan 2010 12:52: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 cVJZ5OcTa9XM; Fri, 1 Jan 2010 12:52: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 E2973C0002; Fri, 1 Jan 2010 12:52:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96160FA9A22; Fri, 1 Jan 2010 12:52:05 +0100 (CET) Date: Fri, 1 Jan 2010 12:52:05 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100101115205.GA28799@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits 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, 01 Jan 2010 11:52:33 -0000 On Thu, Dec 31, 2009 at 04:13:48PM +0100, tom.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" j.schoenwaelder@jacobs-university.de > Sent: Thursday, December 31, 2009 1:51 PM > > > On Thu, Dec 31, 2009 at 09:42:57AM +0100, tom.petch wrote: > > > > > 4366 requires the HostName to be a fully qualified DNS name > > > so if we follow that RFC, we would require our securityNames-to-be > > > to be fully qualified DNS names. I think that wrong. > > > > Why? > > You seem to be suggesting that your principal names are > fully qualified DNS names. I know of none such so forcing > the SNI to be a fully qualified DNS name, which is my > reading of RFC4366, means yet another mapping table > to be configured by the admin, mapping fully qualified > DNS names into what admins actually assign to users. My understanding of the server-name extension is that it is used by a client to indicate to which server it is talking. This is important for HTTP where a single server can serve multiple different "sites" by way of the HTTP Host: header. Since the server needs to pick the cert before the Host: header is sent, the server-name extension is used to communicate the host name. I am not sure why this problem would be relevant for SNMP. If it is, I would argue that a host name to identify the SNMP engine is kind of best practice (through it should really be the SnmpEngineID). > I see a need for another case allowing snmpAdminString format. It seems you are looking at a mechanism to tell the server to establish a session with certs for foo@domain.example.org or just foo@ while talking to a given transport endpoint. In this case, I think we are talking about another TLS extension to identify a 'user' or 'principal' and this extension should likely be independent of the server-name extension. I have no clue whether someone has already invented this but I suspect that such a thing should go via the TLS working group since it likely has much broader applicability if done right. /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 Jan 4 16:28: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 D144B3A6801 for ; Mon, 4 Jan 2010 16:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJzgOWNJVgp3 for ; Mon, 4 Jan 2010 16:28:32 -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 D5BBB3A62C1 for ; Mon, 4 Jan 2010 16:28:31 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 61AEF98065; Mon, 4 Jan 2010 16:28:29 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <001901ca89f4$2eaa03c0$0601a8c0@allison> Date: Mon, 04 Jan 2010 16:28:29 -0800 In-Reply-To: <001901ca89f4$2eaa03c0$0601a8c0@allison> (tom petch's message of "Thu, 31 Dec 2009 09:30:41 +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] TLSTM -04 draft being published: some more edits 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, 05 Jan 2010 00:28:32 -0000 >>>>> On Thu, 31 Dec 2009 09:30:41 +0100, "tom.petch" said: tp> Some editorial suggestions, of grammar, semantics and clarity. I've made the changes you requested. Thanks for specifying precisely what you wanted the wording to be for most of them. Notes on some: tp> 3.1.2 tp> " and the type and address associated " tp> suggest "and the transport type and address associated " tp> type on its own left me floundering Actually used: "... address authenticated principal, the transport type and the transport addresss associated with an incoming message." tp> 3.1.3 tp> "Each unique combination of these tp> parameters MUST have a locally-chosen unique tlstmSessionID tp> associated for active sessions. " tp> The last clause seems barely grammatical; suggest removing 'associated tp> for active sessions' If you want to limit this to active sessions, suggest tp> 'for each active session' Used the suffix, since I think it's important. tp> 3.2 "(e.g..," an extra period to go with ... Actually, I removed a period instead. tp> 5.2 5 4b (eh???? but that is what it says:-( I don't understand that comment. tp> 5.3 3b tp> "The (D)TLS client side of the connection MUST verify that tp> authenticated identity of the (D)TLS server's presented tp> certificate is the expected certificate" tp> ie 'the authenticated identity is the certificate' tp> ok grammatically, but for me, not semantically; identities and certificates tp> come from different universes Actually, grammatically it was missing a 'the'. I changed the sentence to just: "The (D)TLS client side of the connection MUST verify that the (D)TLS server's presented certificate is the expected certificate." since the (new in -04) next sentence actually states that it must be authenticated too. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 4 16:33:41 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6883A69D9 for ; Mon, 4 Jan 2010 16:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3NpT2Mmtqz3 for ; Mon, 4 Jan 2010 16:33:40 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 2FDFF3A6837 for ; Mon, 4 Jan 2010 16:33:40 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D8F5E98077; Mon, 4 Jan 2010 16:33:38 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20091231051339.GA26661@elstar.local> Date: Mon, 04 Jan 2010 16:33:38 -0800 In-Reply-To: <20091231051339.GA26661@elstar.local> (Juergen Schoenwaelder's message of "Thu, 31 Dec 2009 06:13:39 +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] TLSTM -04 draft being published: wraps up all outstanding edits 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, 05 Jan 2010 00:33:41 -0000 >>>>> On Thu, 31 Dec 2009 06:13:39 +0100, Juergen Schoenwaelder said: JS> I heard David Harrington, Randy Presuhn, Andrew Donati and myself (as JS> technical contributor) speaking in favour of II.b) and all three JS> provided different arguments for choosing II.b): To support this I've simply removed all the text describing fate sharing entirely, which brings us back to the SMI default of "none": --- a/draft/draft-ietf-isms-dtls-tm.xml +++ b/draft/draft-ietf-isms-dtls-tm.xml @@ -2166,13 +2166,7 @@ tlstmParamsRowStatus OBJECT-TYPE An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in - an inconsistentValue error. - - If this row is deleted it has no effect on the corresponding - row in the targetParamsTable. - - If the corresponding row in the targetParamsTable is deleted - then this row must be automatically removed." + an inconsistentValue error." ::= { tlstmParamsEntry 3 } -- Lists expected certificate fingerprints to be presented by a DTLS @@ -2325,13 +2319,7 @@ tlstmAddrRowStatus OBJECT-TYPE An attempt to set these objects while the value of tlstmAddrRowStatus is active(1) will result in - an inconsistentValue error. - - If this row is deleted it has no effect on the corresponding - row in the targetAddrTable. - - If the corresponding row in the targetAddrTable is deleted - then this row must be automatically removed." + an inconsistentValue error." ::= { tlstmAddrEntry 4 } -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 4 16:56: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 5A4E928C0E7 for ; Mon, 4 Jan 2010 16:56:07 -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 CZz9T3OvSE+D for ; Mon, 4 Jan 2010 16:56:06 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 683FD3A67AD for ; Mon, 4 Jan 2010 16:56:06 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 27E4D98079; Mon, 4 Jan 2010 16:56:05 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> Date: Mon, 04 Jan 2010 16:56:04 -0800 In-Reply-To: <20100101115205.GA28799@elstar.local> (Juergen Schoenwaelder's message of "Fri, 1 Jan 2010 12:52:05 +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] TLSTM -04 draft being published: wraps up all outstanding edits 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, 05 Jan 2010 00:56:07 -0000 >>>>> On Fri, 1 Jan 2010 12:52:05 +0100, Juergen Schoenwaelder said: JS> I am not sure why this problem would be relevant for SNMP. If it is, I JS> would argue that a host name to identify the SNMP engine is kind of JS> best practice (through it should really be the SnmpEngineID). The relevancy primarily comes from the long standing desire expressed in various places to send notifications to a single port but to multiple identities. In practice, I've never been convinced this is used in the wild, but people have talked about a notification receiver application that "routes" notifications to the right principal after it receives and processes them. This was possible with USM and people have said it should be possible with any ISMS related solutions as well. The server-name extension for TLS lets you do this by telling the server which certificate it should be using (IE, which identity it should be receiving the notification for). I agree I don't think we should get in the habit, as you've suggested, as specifying *how* this is done within (D)TLS. The best we can do is reference an existing specification (eg, 4366) and say you should use that. Maybe the right thing to do would be to say something more generic. IE: OLD: Servers that wish to support multiple principals at a particular port SHOULD make use of the Server Name Indication extension defined in Section 3.1 of [RFC4366]. NEW: Servers that wish to support multiple principals at a particular port SHOULD make use of +++a (D)TLS extension that allows server-side principal selection like+++ the Server Name Indication extension defined in Section 3.1 of [RFC4366]. I have not made this change and merely pose it here as a possibility. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Jan 5 02:15: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 7C0803A6903 for ; Tue, 5 Jan 2010 02:15:38 -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 ccNqdE3rW0XE for ; Tue, 5 Jan 2010 02:15: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 5D6D43A6816 for ; Tue, 5 Jan 2010 02:15:37 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C06BAC001C; Tue, 5 Jan 2010 11:15:35 +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 AXBj4H5K0htD; Tue, 5 Jan 2010 11:15:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8F90C0004; Tue, 5 Jan 2010 11:15:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A9C68FAD1B7; Tue, 5 Jan 2010 11:15:31 +0100 (CET) Date: Tue, 5 Jan 2010 11:15:31 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100105101531.GB34323@elstar.local> Mail-Followup-To: Wes Hardaker , David Harrington , "isms@ietf.org" References: <20091216105240.GA78492@elstar.local> <062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> <006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] issue #12: fate sharing 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, 05 Jan 2010 10:15:38 -0000 On Mon, Jan 04, 2010 at 09:18:24PM +0100, Wes Hardaker wrote: > >>>>> On Wed, 30 Dec 2009 13:36:06 -0500, "David Harrington" said: > > DH> I assume the information in the tlstmParamsTable and the > DH> tlstmAddrTable must be manually configured by an administrator. We > DH> usually expect such information to be persistent across reboots. I > DH> didn't see text in the MIB that said this. > > That's sort of the point of the tlstmParamsStorageType object. Note > that the text in that column is nearly identical to the text in the > corresponding snmpTargetParamsStorageType where it also doesn't discuss > reboots (because that's implied in the TC). Do you still think > something needs to be added, if so please provide text and a location > for it to go. I think the tlstmParamsStorageType addresses the issue. /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 Tue Jan 5 02:21:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66223A68B3 for ; Tue, 5 Jan 2010 02:21:45 -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 arFlA5cpST6N for ; Tue, 5 Jan 2010 02:21:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B30273A6903 for ; Tue, 5 Jan 2010 02:21:44 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 996A5C001A; Tue, 5 Jan 2010 11:21:43 +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 RzWaFn-gZ-E1; Tue, 5 Jan 2010 11:21:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 186BBC0004; Tue, 5 Jan 2010 11:21:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A69F1FAD2E9; Tue, 5 Jan 2010 11:21:39 +0100 (CET) Date: Tue, 5 Jan 2010 11:21:39 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100105102139.GA34452@elstar.local> Mail-Followup-To: Wes Hardaker , "tom.petch" , "isms@ietf.org" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits 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, 05 Jan 2010 10:21:46 -0000 On Tue, Jan 05, 2010 at 01:56:04AM +0100, Wes Hardaker wrote: > IE: > > OLD: > Servers that wish to support multiple principals at a particular port > SHOULD make use of the Server Name Indication extension defined in > Section 3.1 of [RFC4366]. > > NEW: > Servers that wish to support multiple principals at a particular port > SHOULD make use of +++a (D)TLS extension that allows server-side > principal selection like+++ the Server Name Indication extension > defined in Section 3.1 of [RFC4366]. > > I have not made this change and merely pose it here as a possibility. Speaking as technical contributor, I like this proposed NEW text. /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 Tue Jan 5 04:18:17 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51683A6915 for ; Tue, 5 Jan 2010 04:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4p3Tf0xICZ6 for ; Tue, 5 Jan 2010 04:18:16 -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 6AA743A68BF for ; Tue, 5 Jan 2010 04:18:16 -0800 (PST) X-Trace: 227385426/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.22/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.22 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: ApQGAIq8Qks+vGQW/2dsb2JhbACCUS2FLIhXwjgKgiIOgXYEjVc X-IronPort-AV: E=Sophos;i="4.47,505,1257120000"; d="scan'208";a="227385426" X-IP-Direction: IN Received: from 1cust22.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.22]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jan 2010 12:18:12 +0000 Message-ID: <01c901ca8df8$ce358420$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <001901ca89f4$2eaa03c0$0601a8c0@allison> Date: Tue, 5 Jan 2010 11:41: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] TLSTM -04 draft being published: some more edits 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: Tue, 05 Jan 2010 12:18:17 -0000 Wes Picking up on a couple of points: tp> 5.2 5 4b (eh???? but that is what it says:-( I don't understand that comment Section 5.2 has a sub-section 5 which then has sub-sub-sections 4b and 4a.; there are no sub-sub-sections 1, 2, 3; looks odd - I would have made the sub-sub-sections just a) and b) as secshell did. tp> 5.3 3b tp> "The (D)TLS client side of the connection MUST verify that tp> authenticated identity of the (D)TLS server's presented tp> certificate is the expected certificate" tp> ie 'the authenticated identity is the certificate' tp> ok grammatically, but for me, not semantically; identities and certificates tp> come from different universes Actually, grammatically it was missing a 'the'. I like your replacement sentence. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Wes Hardaker" ; Sent: Tuesday, January 05, 2010 1:28 AM Subject: Re: TLSTM -04 draft being published: some more edits > >>>>> On Thu, 31 Dec 2009 09:30:41 +0100, "tom.petch" said: > > tp> Some editorial suggestions, of grammar, semantics and clarity. > > I've made the changes you requested. Thanks for specifying precisely > what you wanted the wording to be for most of them. Notes on some: > > tp> 3.1.2 > tp> " and the type and address associated " > tp> suggest "and the transport type and address associated " > tp> type on its own left me floundering > > Actually used: "... address authenticated principal, the transport type > and the transport addresss associated with an > incoming message." > > tp> 3.1.3 > tp> "Each unique combination of these > tp> parameters MUST have a locally-chosen unique tlstmSessionID > tp> associated for active sessions. " > tp> The last clause seems barely grammatical; suggest removing 'associated > tp> for active sessions' If you want to limit this to active sessions, suggest > tp> 'for each active session' > > Used the suffix, since I think it's important. > > tp> 3.2 "(e.g..," an extra period to go with ... > > Actually, I removed a period instead. > > tp> 5.2 5 4b (eh???? but that is what it says:-( > > I don't understand that comment. > > tp> 5.3 3b > tp> "The (D)TLS client side of the connection MUST verify that > tp> authenticated identity of the (D)TLS server's presented > tp> certificate is the expected certificate" > tp> ie 'the authenticated identity is the certificate' > tp> ok grammatically, but for me, not semantically; identities and certificates > tp> come from different universes > > Actually, grammatically it was missing a 'the'. > > I changed the sentence to just: > > "The (D)TLS client side of the connection MUST verify that the (D)TLS > server's presented certificate is the expected certificate." > > since the (new in -04) next sentence actually states that it must be > authenticated too. > > -- > Wes Hardaker > Cobham Analytic Solutions From cfinss@dial.pipex.com Tue Jan 5 04:18: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 C25B43A688B for ; Tue, 5 Jan 2010 04:18: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 3J1oTzf-dUOb for ; Tue, 5 Jan 2010 04:18:17 -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 9BE353A6916 for ; Tue, 5 Jan 2010 04:18:17 -0800 (PST) X-Trace: 227385434/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.22/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.22 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: ApQGAIq8Qks+vGQW/2dsb2JhbACCUS2FLIhXwjgKgiEBggQEjVc X-IronPort-AV: E=Sophos;i="4.47,505,1257120000"; d="scan'208";a="227385434" X-IP-Direction: IN Received: from 1cust22.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.22]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jan 2010 12:18:14 +0000 Message-ID: <01ca01ca8df8$cf38ea60$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local> Date: Tue, 5 Jan 2010 11:48:50 +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] TLSTM -04 draft being published: wraps up all outstanding edits 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: Tue, 05 Jan 2010 12:18:18 -0000 Wes I am easy either way. My original point was that it should be 4366bis rather than 4366 which obviously raises a dependency which some do not like. Incidentally, it was Joe that originally raised this (6Dec09) so I would value his comments on the current state of this topic. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Wes Hardaker" ; Sent: Tuesday, January 05, 2010 1:56 AM Subject: Re: TLSTM -04 draft being published: wraps up all outstanding edits > >>>>> On Fri, 1 Jan 2010 12:52:05 +0100, Juergen Schoenwaelder said: > > JS> I am not sure why this problem would be relevant for SNMP. If it is, I > JS> would argue that a host name to identify the SNMP engine is kind of > JS> best practice (through it should really be the SnmpEngineID). > > The relevancy primarily comes from the long standing desire expressed in > various places to send notifications to a single port but to multiple > identities. In practice, I've never been convinced this is used in the > wild, but people have talked about a notification receiver application > that "routes" notifications to the right principal after it receives and > processes them. This was possible with USM and people have said it > should be possible with any ISMS related solutions as well. > > The server-name extension for TLS lets you do this by telling the server > which certificate it should be using (IE, which identity it should be > receiving the notification for). > > I agree I don't think we should get in the habit, as you've suggested, > as specifying *how* this is done within (D)TLS. The best we can do is > reference an existing specification (eg, 4366) and say you should use > that. Maybe the right thing to do would be to say something more > generic. > > IE: > > OLD: > Servers that wish to support multiple principals at a particular port > SHOULD make use of the Server Name Indication extension defined in > Section 3.1 of [RFC4366]. > > NEW: > Servers that wish to support multiple principals at a particular port > SHOULD make use of +++a (D)TLS extension that allows server-side > principal selection like+++ the Server Name Indication extension > defined in Section 3.1 of [RFC4366]. > > I have not made this change and merely pose it here as a possibility. > -- > Wes Hardaker > Cobham Analytic Solutions From cfinss@dial.pipex.com Tue Jan 5 04:18: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 4E0053A688B for ; Tue, 5 Jan 2010 04:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MthzNbtXTvRG for ; Tue, 5 Jan 2010 04:18:19 -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 D99753A6915 for ; Tue, 5 Jan 2010 04:18:18 -0800 (PST) X-Trace: 227385446/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.22/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.22 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: ApQGAIq8Qks+vGQW/2dsb2JhbACCUS2FLIhXwjgKgiGCBQQ X-IronPort-AV: E=Sophos;i="4.47,505,1257120000"; d="scan'208";a="227385446" X-IP-Direction: IN Received: from 1cust22.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.22]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jan 2010 12:18:16 +0000 Message-ID: <01cb01ca8df8$d0889be0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local> Date: Tue, 5 Jan 2010 12:01:33 +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] TLSTM -04 draft being published: s5.1.1 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: Tue, 05 Jan 2010 12:18:23 -0000 " DTLS over UDP is significantly different in terms of session handling than when TLS or DTLS is run over session based streaming protocols like TCP or SCTP. Specifically, the DTLS protocol, when run over UDP, does not have a session identifier that allows implementations to determine through which session a packet arrived. " I have read this several times and think that I am missing an important point. If I have a stream of UDP data arriving at a host, then I identify that stream by a 4-tuple of source and destination IP address and port. If I have a stream of TCP data arriving at a host, then I identify that stream by a 4-tuple of source and destination IP address and port. If I have DTLS over UDP or TLS over TCP, then then I identify that stream by a 4-tuple of source and destination IP address and port. What is the difference? Given the length of the description of processing that follows, this is something big, which I am totally missing. The TCP protocol does not have a session identifier, it uses the 4-tuple of source and destination IP address and port (as in the TCP MIB module RFC4022:-) Tom Petch ----- Original Message ----- From: "Wes Hardaker" From cfinss@dial.pipex.com Tue Jan 5 04:18: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 4526B28C0E8 for ; Tue, 5 Jan 2010 04:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5Ifv3osAI8h for ; Tue, 5 Jan 2010 04:18:22 -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 2D79228C0CE for ; Tue, 5 Jan 2010 04:18:19 -0800 (PST) X-Trace: 227385456/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.22/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.22 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: ApQGAIq8Qks+vGQW/2dsb2JhbACCUS2FLIhXwjgKhCYE X-IronPort-AV: E=Sophos;i="4.47,505,1257120000"; d="scan'208";a="227385456" X-IP-Direction: IN Received: from 1cust22.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.22]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jan 2010 12:18:18 +0000 Message-ID: <01cc01ca8df8$d12eee00$0601a8c0@allison> From: "tom.petch" To: "isms" , "Wes Hardaker" Date: Tue, 5 Jan 2010 12:17:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] Fw: TLSTM -04 draft being published: s3.2 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: Tue, 05 Jan 2010 12:18:24 -0000 Resending as this seems to have fallen into the great Y2.01K spam hole. Tom Petch ----- Original Message ----- From: "tom.petch" Sent: Saturday, January 02, 2010 12:07 PM > Section 3.2 puzzles me; I am not clear what the aim of it is. > > The second paragraph covers a client using sendMessage and passing parameters > from tlsTM to TLS, eg a Get message. > > The first paragraph covers a server receiving a message, updating the cache and > passing parameters from tlsTM to the SM, eg a Get message. > > Does tlsTM include Response messages:-) Only there are two cases missing, a > server sending eg a Response message and a client receiving eg a Response > message. > > It seems to me that either four paragraphs are needed, or else the client > paragraph needs to cover send and receive, or else the second paragraph needs to > cover client and server send or .... > > Tom Petch > > > ----- Original Message ----- > > From: "Wes Hardaker" > > To: > > Sent: Wednesday, December 30, 2009 6:11 PM > > Subject: [Isms] TLSTM -04 draft being published: wraps up all outstandingedits From j.schoenwaelder@jacobs-university.de Tue Jan 5 04:31:31 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2413A691D for ; Tue, 5 Jan 2010 04:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=0.333, 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 9yT3TKHMfXBG for ; Tue, 5 Jan 2010 04:31:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B7A5D3A68BF for ; Tue, 5 Jan 2010 04:31:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8139AC001C; Tue, 5 Jan 2010 13:31:28 +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 F4iifvZ+rnAv; Tue, 5 Jan 2010 13:31:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF8F9C001A; Tue, 5 Jan 2010 13:31:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B4C84FADC87; Tue, 5 Jan 2010 13:31:24 +0100 (CET) Date: Tue, 5 Jan 2010 13:31:24 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100105123124.GB34963@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01cb01ca8df8$d0889be0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Tue, 05 Jan 2010 12:31:31 -0000 On Tue, Jan 05, 2010 at 12:01:33PM +0100, tom.petch wrote: > " DTLS over UDP is significantly different in terms of session handling > than when TLS or DTLS is run over session based streaming protocols > like TCP or SCTP. Specifically, the DTLS protocol, when run over > UDP, does not have a session identifier that allows implementations > to determine through which session a packet arrived. " > > I have read this several times and think that I am missing an important point. > > If I have a stream of UDP data arriving at a host, then I identify that stream > by a 4-tuple of source and destination IP address and port. > > If I have a stream of TCP data arriving at a host, then I identify that stream > by a 4-tuple of source and destination IP address and port. > > If I have DTLS over UDP or TLS over TCP, then then I identify that stream by a > 4-tuple of source and destination IP address and port. > > What is the difference? Given the length of the description of processing > that follows, this is something big, which I am totally missing. > > The TCP protocol does not have a session identifier, it uses the 4-tuple of > source and destination IP address and port (as in the TCP MIB module RFC4022:-) Common TCP implementations give you a separate socket for each connection. With UDP, this is usually not the case. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Jan 5 12:57: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 908273A691A for ; Tue, 5 Jan 2010 12:57:07 -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 nFhTctXJW+j2 for ; Tue, 5 Jan 2010 12:57:06 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 5830D3A68CB for ; Tue, 5 Jan 2010 12:57:06 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id RplB1d0060SCNGk52wx6T1; Tue, 05 Jan 2010 20:57:06 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Rwx51d00B284sdk3Vwx55P; Tue, 05 Jan 2010 20:57:06 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Wes Hardaker'" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local> <20100105102139.GA34452@elstar.local> Date: Tue, 5 Jan 2010 15:57:04 -0500 Message-ID: <028d01ca8e49$a306f760$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: AcqN8OSTsWGqwuHqSjOXZlaMaDm94QAVzakA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20100105102139.GA34452@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits 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, 05 Jan 2010 20:57:07 -0000 Hi, I prefer the NEW text to the old text, but I am not convinced we need to discuss multiple principals on a port. I have worked on applications that provided support for multiple principles on a port, particularly for receiving different sets of traps, and I think this is an engineering implementation decision. It is really quite simple to use different ports for different applications; demultiplexing a single port across multiple applications adds complexity and requires some type of registration/subscription mechanism. I am not convinced ISMS needs to address this port-sharing approach, especially since using different ports is so much easier. If we believe cross-vendor interoperability for this feature is really important, then we should standardize the feature more strongly than either the old or new text does. I smell significant feature-creep here, and the more complex we make the transport model, the less likely it will be implemented and deployed. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, January 05, 2010 5:22 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] TLSTM -04 draft being published: wraps up > all outstanding edits > > On Tue, Jan 05, 2010 at 01:56:04AM +0100, Wes Hardaker wrote: > > > IE: > > > > OLD: > > Servers that wish to support multiple principals at a > particular port > > SHOULD make use of the Server Name Indication extension > defined in > > Section 3.1 of [RFC4366]. > > > > NEW: > > Servers that wish to support multiple principals at a > particular port > > SHOULD make use of +++a (D)TLS extension that allows server-side > > principal selection like+++ the Server Name Indication extension > > defined in Section 3.1 of [RFC4366]. > > > > I have not made this change and merely pose it here as a > possibility. > > Speaking as technical contributor, I like this proposed NEW text. > > /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 wjhns1@hardakers.net Tue Jan 5 16:56: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 C982D28C110 for ; Tue, 5 Jan 2010 16:56: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 s8d5l7RCNhY9 for ; Tue, 5 Jan 2010 16:56: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 DE95228C10F for ; Tue, 5 Jan 2010 16:56:50 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 1955498494; Tue, 5 Jan 2010 16:56:49 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> Date: Tue, 05 Jan 2010 16:56:48 -0800 In-Reply-To: <20100105123124.GB34963@elstar.local> (Juergen Schoenwaelder's message of "Tue, 5 Jan 2010 13:31:24 +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] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 00:56:51 -0000 >>>>> On Tue, 5 Jan 2010 13:31:24 +0100, Juergen Schoenwaelder said: JS> Common TCP implementations give you a separate socket for each JS> connection. With UDP, this is usually not the case. Exactly; it's an implementation hint. Others people who are either implementing it or thinking about it have told me that the description helped them. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jan 5 16:59:34 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEC128C11A for ; Tue, 5 Jan 2010 16:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv655qF1shMf for ; Tue, 5 Jan 2010 16:59:33 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B153E28C113 for ; Tue, 5 Jan 2010 16:59:33 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 38FEA9849B; Tue, 5 Jan 2010 16:59:32 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <20100105102139.GA34452@elstar.local> Date: Tue, 05 Jan 2010 16:59:32 -0800 In-Reply-To: <20100105102139.GA34452@elstar.local> (Juergen Schoenwaelder's message of "Tue, 5 Jan 2010 11:21:39 +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] TLSTM -04 draft being published: wraps up all outstanding edits 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, 06 Jan 2010 00:59:34 -0000 >>>>> On Tue, 5 Jan 2010 11:21:39 +0100, Juergen Schoenwaelder said: JS> On Tue, Jan 05, 2010 at 01:56:04AM +0100, Wes Hardaker wrote: >> NEW: >> Servers that wish to support multiple principals at a particular port >> SHOULD make use of +++a (D)TLS extension that allows server-side >> principal selection like+++ the Server Name Indication extension >> defined in Section 3.1 of [RFC4366]. JS> Speaking as technical contributor, I like this proposed NEW text. I like it a lot better because we really shouldn't care how it's done per say, just that it can be. I've changed my local copy (but can obviously change it back if others have issues with it). -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jan 5 17:01:05 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3593A6801 for ; Tue, 5 Jan 2010 17:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt3qQb53yj+H for ; Tue, 5 Jan 2010 17:01:04 -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 93F313A62C1 for ; Tue, 5 Jan 2010 17:01:04 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 25735984A1; Tue, 5 Jan 2010 17:01:03 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <001901ca89f4$2eaa03c0$0601a8c0@allison> <01c901ca8df8$ce358420$0601a8c0@allison> Date: Tue, 05 Jan 2010 17:01:02 -0800 In-Reply-To: <01c901ca8df8$ce358420$0601a8c0@allison> (tom petch's message of "Tue, 5 Jan 2010 11:41:26 +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] TLSTM -04 draft being published: some more edits 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, 06 Jan 2010 01:01:05 -0000 >>>>> On Tue, 5 Jan 2010 11:41:26 +0100, "tom.petch" said: tp> 5.2 5 4b (eh???? but that is what it says:-( tp> I don't understand that comment tp> Section 5.2 has a sub-section 5 which then has sub-sub-sections 4b and 4a.; tp> there are no sub-sub-sections 1, 2, 3; looks odd - I would have made the tp> sub-sub-sections just a) and b) as secshell did. Ahh.... Gotcha. fixed! Thanks! -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jan 5 17:04:13 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338AF3A62C1 for ; Tue, 5 Jan 2010 17:04:13 -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 MIe31UhU9RG2 for ; Tue, 5 Jan 2010 17:04:12 -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 3E9313A657C for ; Tue, 5 Jan 2010 17:04:12 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C917A983D1; Tue, 5 Jan 2010 17:04:10 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <01cc01ca8df8$d12eee00$0601a8c0@allison> Date: Tue, 05 Jan 2010 17:04:10 -0800 In-Reply-To: <01cc01ca8df8$d12eee00$0601a8c0@allison> (tom petch's message of "Tue, 5 Jan 2010 12:17:21 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] Fw: IsmsTLSTM -04 draft being published: s3.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: Wed, 06 Jan 2010 01:04:13 -0000 >>>>> On Tue, 5 Jan 2010 12:17:21 +0100, "tom.petch" said: tp> Resending as this seems to have fallen into the great Y2.01K spam tp> hole. It's definitely one of the more interesting bugs recently. Shows how all the mail in the world seems to be dependent on one software package ;-) >> Section 3.2 puzzles me; I am not clear what the aim of it is. >> >> The second paragraph covers a client using sendMessage and passing >> parameters from tlsTM to TLS, eg a Get message. >> >> The first paragraph covers a server receiving a message, updating the >> cache and passing parameters from tlsTM to the SM, eg a Get message. >> >> Does tlsTM include Response messages:-) Only there are two cases missing, a >> server sending eg a Response message and a client receiving eg a Response >> message. >> >> It seems to me that either four paragraphs are needed, or else the >> client paragraph needs to cover send and receive, or else the second >> paragraph needs to cover client and server send or .... The section is certainly highly abstract as it relies on the framework provided by RFC5590 that we're bulding upon. However, I'm not going to change the text since we don't have a concrete proposal at this point and are still way beyond last call and you're talking about a major revamp of the section. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Tue Jan 5 20:29: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 E371D3A6863 for ; Tue, 5 Jan 2010 20:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAs5V5I3VLGj for ; Tue, 5 Jan 2010 20:29:14 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 139E93A67FA for ; Tue, 5 Jan 2010 20:29:14 -0800 (PST) Received: from ATLANTIS.PC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o064T1Q0020477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 23:29:03 -0500 (EST) Date: Tue, 05 Jan 2010 23:29:00 -0500 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , "tom.petch" Message-ID: <73863BFD1C18DD01EA857F90@atlantis.pc.cs.cmu.edu> In-Reply-To: <28790_1262694692_o05CVVww027018_20100105123124.GB34963@elstar.local> References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <28790_1262694692_o05CVVww027018_20100105123124.GB34963@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 04:29:15 -0000 --On Tuesday, January 05, 2010 01:31:24 PM +0100 Juergen Schoenwaelder wrote: >> The TCP protocol does not have a session identifier, it uses the 4-tuple >> of source and destination IP address and port (as in the TCP MIB module >> RFC4022:-) > > Common TCP implementations give you a separate socket for each > connection. With UDP, this is usually not the case. Also, TCP identifies connections by a pair of addresses and ports _at a particular point in time_, and its state machine goes to a fair bit of effort to insure that there are never two connections named by the same 5-tuple at the same time. UDP does no connection tracking, and so does not inherently provide a way to tell whether a received message is part of the "same" connection as some previous message. From cfinss@dial.pipex.com Wed Jan 6 02:07: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 950A73A681D for ; Wed, 6 Jan 2010 02:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 OwAhZDXM1cvq for ; Wed, 6 Jan 2010 02:07:36 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 91FF63A6830 for ; Wed, 6 Jan 2010 02:07:36 -0800 (PST) X-Trace: 170971010/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.33/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.33 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: AqAFANDvQ0s+vGkh/2dsb2JhbACCUYVZiFi3MgmKWQIIgiEcgWkE X-IronPort-AV: E=Sophos;i="4.49,228,1262563200"; d="scan'208";a="170971010" X-IP-Direction: IN Received: from 1cust33.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.33]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Jan 2010 10:07:33 +0000 Message-ID: <002101ca8eaf$b71e07a0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> Date: Wed, 6 Jan 2010 10:06:33 +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] TLSTM -04 draft being published: s5.1.1 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: Wed, 06 Jan 2010 10:07:37 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Tuesday, January 05, 2010 1:31 PM > On Tue, Jan 05, 2010 at 12:01:33PM +0100, tom.petch wrote: > > > > If I have DTLS over UDP or TLS over TCP, then then I identify that stream by a > > 4-tuple of source and destination IP address and port. > > > > The TCP protocol does not have a session identifier, it uses the 4-tuple of > > source and destination IP address and port (as in the TCP MIB module RFC4022:-) > > Common TCP implementations give you a separate socket for each > connection. With UDP, this is usually not the case. Right, so what we are talking about here is an implementation specific detail for some of the currently available DTLS over UDP libraries. Should that not belong in an appendix, with just a line or two here that a session is identified by these parameters and for one way to achieve this, see appendix? 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 j.schoenwaelder@jacobs-university.de Wed Jan 6 03:16: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 B65613A6816 for ; Wed, 6 Jan 2010 03:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.200, 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 gu8efgg29-sF for ; Wed, 6 Jan 2010 03:16: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 A9BF83A67B0 for ; Wed, 6 Jan 2010 03:16:06 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A200C002C; Wed, 6 Jan 2010 12:16:05 +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 emg8dac+aNWY; Wed, 6 Jan 2010 12:16: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 73F13C0029; Wed, 6 Jan 2010 12:16:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2EA0BFB02C5; Wed, 6 Jan 2010 12:16:01 +0100 (CET) Date: Wed, 6 Jan 2010 12:16:01 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100106111601.GB36984@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101ca8eaf$b71e07a0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 11:16:07 -0000 On Wed, Jan 06, 2010 at 10:06:33AM +0100, tom.petch wrote: > Right, so what we are talking about here is an implementation > specific detail for some of the currently available DTLS over UDP > libraries. Should that not belong in an appendix, with just a line > or two here that a session is identified by these parameters and for > one way to achieve this, see appendix? I do not really care much but I also do not see the big difference whether the text is inline or in an appendix. What do you think does improve by moving this to an appendix? /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 Wed Jan 6 03:48:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA9A3A68F1 for ; Wed, 6 Jan 2010 03:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 tccgJTf1t6E6 for ; Wed, 6 Jan 2010 03:48:44 -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 1CC0F3A68ED for ; Wed, 6 Jan 2010 03:48:43 -0800 (PST) X-Trace: 316728648/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.240/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.240 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: ArwEAAMHREs+vGnw/2dsb2JhbACCUYVZiFjBOwqEJgSNMQ X-IronPort-AV: E=Sophos;i="4.49,229,1262563200"; d="scan'208";a="316728648" X-IP-Direction: IN Received: from 1cust240.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.240]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Jan 2010 11:48:35 +0000 Message-ID: <017c01ca8ebd$d51d22a0$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "Juergen Schoenwaelder" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <28790_1262694692_o05CVVww027018_20100105123124.GB34963@elstar.local> <73863BFD1C18DD01EA857F90@atlantis.pc.cs.cmu.edu> Date: Wed, 6 Jan 2010 10:37:27 +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, jhutz@cmu.edu Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.1 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: Wed, 06 Jan 2010 11:48:45 -0000 ----- Original Message ----- From: "Jeffrey Hutzelman" To: "Juergen Schoenwaelder" ; "tom.petch" Cc: ; Sent: Wednesday, January 06, 2010 5:29 AM Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.1 > --On Tuesday, January 05, 2010 01:31:24 PM +0100 Juergen Schoenwaelder > wrote: > > >> The TCP protocol does not have a session identifier, it uses the 4-tuple > >> of source and destination IP address and port (as in the TCP MIB module > >> RFC4022:-) > > > > Common TCP implementations give you a separate socket for each > > connection. With UDP, this is usually not the case. > > Also, TCP identifies connections by a pair of addresses and ports _at a > particular point in time_, and its state machine goes to a fair bit of > effort to insure that there are never two connections named by the same > 5-tuple at the same time. > > UDP does no connection tracking, and so does not inherently provide a way > to tell whether a received message is part of the "same" connection as some > previous message. Agreed, but this is DTLS over UDP and TLS most definitely has the concept of a TLS connection, regardless of the underlying UDP, SCTP or TCP. One could hope that DTLS over UDP libraries would recognise this and provide a connection-oriented API at some stage. I see this detail as an Informative appendix, not a Normative part of the specification. Tom Petch From wjhns1@hardakers.net Wed Jan 6 07:07: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 D98623A659B for ; Wed, 6 Jan 2010 07:07: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 xa2kogFVRYVx for ; Wed, 6 Jan 2010 07:07:57 -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 F20EC3A6812 for ; Wed, 6 Jan 2010 07:07:56 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 55C6D98069; Wed, 6 Jan 2010 07:07:55 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <28790_1262694692_o05CVVww027018_20100105123124.GB34963@elstar.local> <73863BFD1C18DD01EA857F90@atlantis.pc.cs.cmu.edu> <017c01ca8ebd$d51d22a0$0601a8c0@allison> Date: Wed, 06 Jan 2010 07:07:55 -0800 In-Reply-To: <017c01ca8ebd$d51d22a0$0601a8c0@allison> (tom petch's message of "Wed, 6 Jan 2010 10:37:27 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 15:07:58 -0000 >>>>> On Wed, 6 Jan 2010 10:37:27 +0100, "tom.petch" said: tp> Agreed, but this is DTLS over UDP and TLS most definitely has the tp> concept of a TLS connection, regardless of the underlying UDP, SCTP tp> or TCP. One could hope that DTLS over UDP libraries would recognise tp> this and provide a connection-oriented API at some stage. One would hope, yes. But one of the most popular stacks out there *does not do this*. I suspect many other TLS stacks were developed in similar ways and made internal assumptions about how the underlying transport handles stuff because the software was written with the state of mind that it would never run over an unconnected transport. Anyway, I doubt anything in there actually hurts the document and since I've received multiple side-comments from peoples saying that it helps I certainly don't see a reason to remove it. tp> I see this detail as an Informative appendix, not a Normative part of the tp> specification. It's normative because it's *required* that implementations that are self-handling stuff don't send out multiple DTLS session data through the same port or else implementations on the other side won't be able to cope well. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Jan 6 07:10: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 9F4C73A63C9 for ; Wed, 6 Jan 2010 07:10:11 -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 lTGsY3BUeq5x for ; Wed, 6 Jan 2010 07:10:10 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 90ADF3A659B for ; Wed, 6 Jan 2010 07:10:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 0B0FB98069; Wed, 6 Jan 2010 07:10:09 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <20100105102139.GA34452@elstar.local> <028d01ca8e49$a306f760$0600a8c0@china.huawei.com> Date: Wed, 06 Jan 2010 07:10:08 -0800 In-Reply-To: <028d01ca8e49$a306f760$0600a8c0@china.huawei.com> (David Harrington's message of "Tue, 5 Jan 2010 15:57:04 -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] TLSTM -04 draft being published: wraps up all outstanding edits 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, 06 Jan 2010 15:10:11 -0000 >>>>> On Tue, 5 Jan 2010 15:57:04 -0500, "David Harrington" said: DH> I smell significant feature-creep here, and the more complex we make DH> the transport model, the less likely it will be implemented and DH> deployed. Well, I'm not necessarily against removing it per-say. But I don't think the current small paragraph describing a hint-ish type text seems like a complexity hit on the document. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed Jan 6 07:39: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 B4C183A67AE for ; Wed, 6 Jan 2010 07:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 Un7i2c-UMW6i for ; Wed, 6 Jan 2010 07:39:37 -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 899F73A63C9 for ; Wed, 6 Jan 2010 07:39:37 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id SCAy1d0060bG4ec55FfW6a; Wed, 06 Jan 2010 15:39:30 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA03.westchester.pa.mail.comcast.net with comcast id SFfb1d00X284sdk3PFfc53; Wed, 06 Jan 2010 15:39:36 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'tom.petch'" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><01cb01ca8df8$d0889be0$0601a8c0@allison><20100105123124.GB34963@elstar.local><002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> Date: Wed, 6 Jan 2010 10:39:34 -0500 Message-ID: <033a01ca8ee6$73004420$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: AcqOwaYZsQaW6UKGTrOlx3bMKIjj+wAJDv2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20100106111601.GB36984@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 15:39:39 -0000 Hi, Like Tom, I am a bit concerned about implementation hints being interspersed with normative text. The draft should be clear and unambiguous about what is in the standard and what is not. Moving implementation hints to a separate section or appendix makes this distinction clear. Another approach would be to prefix each separate paragraph that contains implementation hints with "Implementation hint:" dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, January 06, 2010 6:16 AM > To: tom.petch > Cc: isms@ietf.org > Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.1 > > On Wed, Jan 06, 2010 at 10:06:33AM +0100, tom.petch wrote: > > > Right, so what we are talking about here is an implementation > > specific detail for some of the currently available DTLS over UDP > > libraries. Should that not belong in an appendix, with just a line > > or two here that a session is identified by these parameters and for > > one way to achieve this, see appendix? > > I do not really care much but I also do not see the big difference > whether the text is inline or in an appendix. What do you think does > improve by moving this to an appendix? > > /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 wjhns1@hardakers.net Wed Jan 6 08:04:31 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010E23A6896 for ; Wed, 6 Jan 2010 08:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkmWwmQbAuj7 for ; Wed, 6 Jan 2010 08:04:30 -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 0C25B3A68EB for ; Wed, 6 Jan 2010 08:04:30 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id ABECC9805C; Wed, 6 Jan 2010 08:04:26 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> Date: Wed, 06 Jan 2010 08:04:26 -0800 In-Reply-To: <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 6 Jan 2010 10:39:34 -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] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 16:04:31 -0000 >>>>> On Wed, 6 Jan 2010 10:39:34 -0500, "David Harrington" said: DH> Like Tom, I am a bit concerned about implementation hints being DH> interspersed with normative text. The draft should be clear and DH> unambiguous about what is in the standard and what is not. I'd be happy to mark (preferred) or move (less preferred) any text you feel needs moved. Please let me know exactly which text you're thinking about. Note that the requirement that a separate port/address combination is not an implementation hint. It's a requirement. Tom seemed to think that this wasn't required text and was one of the things he suggested moving to an appendix. The following text: When establishing a new session implementations MUST use a different UDP source port number for each connection to a remote destination IP- address/port-number combination to ensure the remote entity can easily disambiguate between multiple sessions from a host to the same port on a server. is *not* an implementation hint. It's a hard requirement so that implementations are even possible. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Jan 6 08:18:25 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7FD28C113 for ; Wed, 6 Jan 2010 08:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.475, 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 rdgpkmkBtzhf for ; Wed, 6 Jan 2010 08:18:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C937028C103 for ; Wed, 6 Jan 2010 08:18:23 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18494C002F; Wed, 6 Jan 2010 17:18: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 JZHThPPVBx+f; Wed, 6 Jan 2010 17:18:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59FDBC002D; Wed, 6 Jan 2010 17:18:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0F942FB0C82; Wed, 6 Jan 2010 17:18:17 +0100 (CET) Date: Wed, 6 Jan 2010 17:18:17 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100106161817.GC37430@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , "isms@ietf.org" References: <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 16:18:25 -0000 On Wed, Jan 06, 2010 at 04:39:34PM +0100, David Harrington wrote: > Like Tom, I am a bit concerned about implementation hints being > interspersed with normative text. The draft should be clear and > unambiguous about what is in the standard and what is not. > > Moving implementation hints to a separate section or appendix makes > this distinction clear. Another approach would be to prefix each > separate paragraph that contains implementation hints with > "Implementation hint:" Can you tell us which part of the text you consider an implementation hint so that we can easily check and either agree or disagree? /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 Wed Jan 6 10:46: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 1217C28C143 for ; Wed, 6 Jan 2010 10:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qLP4HCUkPZGd for ; Wed, 6 Jan 2010 10:46:26 -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 E17273A6805 for ; Wed, 6 Jan 2010 10:46:25 -0800 (PST) X-Trace: 227744336/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.156/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.156 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: Ah4FAHJpREs+vBGc/2dsb2JhbACCUBiFPohawX8KhCYE X-IronPort-AV: E=Sophos;i="4.49,230,1262563200"; d="scan'208";a="227744336" X-IP-Direction: IN Received: from 1cust156.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.156]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Jan 2010 18:46:20 +0000 Message-ID: <000901ca8ef8$306a8000$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "David Harrington" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><01cb01ca8df8$d0889be0$0601a8c0@allison><20100105123124.GB34963@elstar.local><002101ca8eaf$b71e07a0$0601a8c0@allison><20100106111601.GB36984@elstar.local><033a01ca8ee6$73004420$0600a8c0@china.huawei.com> Date: Wed, 6 Jan 2010 18:45:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.1 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: Wed, 06 Jan 2010 18:46:27 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Wednesday, January 06, 2010 5:04 PM > >>>>> On Wed, 6 Jan 2010 10:39:34 -0500, "David Harrington" said: > > DH> Like Tom, I am a bit concerned about implementation hints being > DH> interspersed with normative text. The draft should be clear and > DH> unambiguous about what is in the standard and what is not. > > I'd be happy to mark (preferred) or move (less preferred) any text you > feel needs moved. Please let me know exactly which text you're thinking > about. > > Note that the requirement that a separate port/address combination is > not an implementation hint. It's a requirement. Tom seemed to think > that this wasn't required text and was one of the things he suggested > moving to an appendix. The following text: > > When establishing a new session implementations MUST use a different > UDP source port number for each connection to a remote destination > IP- address/port-number combination to ensure the remote entity can > easily disambiguate between multiple sessions from a host to the same > port on a server. > > is *not* an implementation hint. It's a hard requirement so that > implementations are even possible. No, I agree that sessions can only be differentiated by a 5-tuple of protocol, source/destination port/address (be they UDP or TCP:-). They differ in that UDP applications may be sloppy in their use of the source port which makes it impossible to set up a stream of data and libraries may be careless of the need to pass this information on. So I would make 5.1.1 something like "A session over UDP is identified by a unique combination of the remote address, remote port number, local address and local port number and this information MUST be available to the Transport Model for each and every incoming datagram in order to derive the corresponding tlstmSessionID. Since DTLS may not make this information available, this may require an incoming datagram to be preprocessed by the Transport Model in order to derive the tlstmSessionID prior to passing the datagram to DTLS. One mechanism to achieve this is described in Appendix ... but any mechanism that achieves the same result conforms to this specification. Note too that entities MUST use a unique UDP source port number for each session (connection?) to a remote destination IP- address/port-number combination so that the remote entity can distinguish one session from another." The rest of the current 5.1.1 is not wrong and is undoubtedly helpful, as Wes reports, it just seems more like motherhood than a protocol specification:-) so I would move it more or less as is to Appendix ... Incidentally, the DTLS specification sort of recognises this issue with the paragraph " Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number." I like the "presumably":-) Tom Petch > -- > Wes Hardaker > Cobham Analytic Solutions From jhutz@cmu.edu Wed Jan 6 14:44: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 67D643A67D9 for ; Wed, 6 Jan 2010 14:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCx0gO+9ASfZ for ; Wed, 6 Jan 2010 14:44:57 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 90A8E3A67D4 for ; Wed, 6 Jan 2010 14:44:57 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o06MheKi020487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 17:43:40 -0500 (EST) Date: Wed, 06 Jan 2010 17:43:40 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Wes Hardaker , David Harrington Message-ID: <52C1B99B801B86A0E8AB9F07@minbar.fac.cs.cmu.edu> In-Reply-To: <9116_1262803588_o06IkRCh030320_000901ca8ef8$306a8000$0601a8c0@allison> References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison><20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison><20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <9116_1262803588_o06IkRCh030320_000901ca8ef8$306a8000$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.197 Cc: isms , jhutz@cmu.edu Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Wed, 06 Jan 2010 22:44:58 -0000 --On Wednesday, January 06, 2010 06:45:09 PM +0100 "tom.petch" wrote: > " Note that unlike IPsec, DTLS records do not contain any association > identifiers. Applications must arrange to multiplex between > associations. With UDP, this is presumably done with host/port > number." > > I like the "presumably":-) DTLS says "presumably". TLSTM strenghtens this to MUST. From jsalowey@cisco.com Wed Jan 6 20:33: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 D86473A67BE for ; Wed, 6 Jan 2010 20:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 cqogAOF8m4P2 for ; Wed, 6 Jan 2010 20:33:55 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1C4013A680D for ; Wed, 6 Jan 2010 20:33:55 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAELzREurR7Ht/2dsb2JhbAC+OJNrhDAE X-IronPort-AV: E=Sophos;i="4.49,233,1262563200"; d="scan'208";a="129525881" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2010 04:33:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o074Xriu011620; Thu, 7 Jan 2010 04:33:53 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 20:33:53 -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, 6 Jan 2010 20:33:52 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt Thread-Index: AcqJamP8++yViQFMTIK10mkRBp+TPwF6CHag References: <000401ca895b$a54a0000$0601a8c0@allison><004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "Wes Hardaker" , "David Harrington" X-OriginalArrivalTime: 07 Jan 2010 04:33:53.0531 (UTC) FILETIME=[9E0E54B0:01CA8F52] Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.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: Thu, 07 Jan 2010 04:33:55 -0000 =20 > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net]=20 > Sent: Wednesday, December 30, 2009 8:08 AM > To: David Harrington > Cc: 'tom.petch'; 'Wes Hardaker'; Joseph Salowey (jsalowey);=20 > isms@ietf.org > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt >=20 > >>>>> On Wed, 30 Dec 2009 10:31:53 -0500, "David Harrington"=20 > said: >=20 > DH> Personally, I recommend against having a reference to the bis=20 > DH> document. We are in WGLC and don't want publication held=20 > up because=20 > DH> of a reference to bis. >=20 > I agree; I was trying not to specify which versions of the=20 > TLS based protocols we are requiring because I don't think=20 > there are any features of the newer ones that we need. There=20 > is no reason that future versions of TLS and DTLS couldn't be=20 > used as well assuming they didn't introduce a technical=20 > conflict with our document, which is unlikely. [Joe] Agreed, referencing the current RFC should be fine. =20 > -- > Wes Hardaker > Cobham Analytic Solutions >=20 From jsalowey@cisco.com Wed Jan 6 20:46:56 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5AD28C191 for ; Wed, 6 Jan 2010 20:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 H48RVLGPg0ai for ; Wed, 6 Jan 2010 20:46:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F5D628C123 for ; Wed, 6 Jan 2010 20:46:55 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIr2REurR7Hu/2dsb2JhbAC+IJNqhDAE X-IronPort-AV: E=Sophos;i="4.49,233,1262563200"; d="scan'208";a="462858864" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2010 04:46:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o074krQ3017491; Thu, 7 Jan 2010 04:46:53 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 20:46:53 -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, 6 Jan 2010 20:46:52 -0800 Message-ID: In-Reply-To: <00d301ca8a19$74ad7260$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt Thread-Index: AcqJ/IdoqpBi1S+WR9qdA3aUwSEyiAAHIFhgAU6qnUA= References: <000401ca895b$a54a0000$0601a8c0@allison><004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> <001a01ca89f4$30015660$0601a8c0@allison> <00d301ca8a19$74ad7260$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "tom.petch" , "Wes Hardaker" X-OriginalArrivalTime: 07 Jan 2010 04:46:53.0559 (UTC) FILETIME=[6EFD2870:01CA8F54] Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.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: Thu, 07 Jan 2010 04:46:56 -0000 The TLS extensions draft is in IESG review. I believe there have been some issues raised with the SNI, I need to follow up to see if they require substantial changes to the document. In any case the revision would need to be backward compatible with what is in 4366, if you were going to define a new name type then there may be additional considerations. =20 Joe > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, December 31, 2009 5:02 AM > To: 'tom.petch'; 'Wes Hardaker' > Cc: Joseph Salowey (jsalowey); isms@ietf.org; 'Pasi Eronen' > Subject: RE: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt >=20 > My experience tells me that getting a document through the=20 > IESG approval process can take a year, more likely 6 months.=20 > If the bis status changes we can always change the reference=20 > later. But I don't get the sense that the bis will beat our=20 > document through the system, so I would prefer to point to=20 > the stable document unless, as Juergen points out, there is a=20 > real technical distinction. >=20 > dbh >=20 > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Thursday, December 31, 2009 3:32 AM > > To: Wes Hardaker > > Cc: David Harrington; 'Joseph Salowey (jsalowey)';=20 > isms@ietf.org; Pasi=20 > > Eronen > > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > >=20 > > ----- Original Message ----- > > From: "Wes Hardaker" > > Sent: Wednesday, December 30, 2009 5:36 PM > > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > >=20 > > > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker > > > > said: > > > > > > DH> Personally, I recommend against having a reference to the bis=20 > > > DH> document. We are in WGLC and don't want publication > > held up because of > > > DH> a reference to bis. > > > > > > WH> I agree; I was trying not to specify which versions of > > the TLS based > > > WH> protocols we are requiring because I don't think there > > are any features > > > WH> of the newer ones that we need. There is no reason > > that future versions > > > WH> of TLS and DTLS couldn't be used as well assuming they > > didn't introduce > > > WH> a technical conflict with our document, which is unlikely. > > > > > > Whoops. Having re-read everything I realized I was > > confused about which > > > of the two issues David was talking about. I responded > > about the DTLS > > > reference but the discussion was surrounding the fact that > > RFC4366 is > > > the only RFC that documents the server name extension until > > a new one > > > gets published. Because of that, we'd either have to keep > > referencing > > > the older one (which doesn't cause any technical problems > > that I'm aware > > > of) or reference the ID and hope it completes soon. Pasi may have > a > > > better idea about how the other document is progressing, > > but unless it's > > > almost identically timed I don't think it buys us much to > > reference the ID. > >=20 > > Um > >=20 > > My point was rather that RFC4366 is obsoleted by RFC5246=20 > because the=20 > > description of the extension technique has been removed=20 > from the TLS=20 > > extension document and made part of the base document, ie=20 > extensions=20 > > are base TLS as of TLS 1.2 (a key feature of current TLS list=20 > > discussions). > >=20 > > 4366-bis will only contain details of specific extensions. > >=20 > > SNI does appear in both RFC4366 and 4366-bis so from that point of=20 > > view, either will do, so it is a choice of being allowed to=20 > depend on=20 > > an obsoleted document versus having to wait for an I-D to=20 > progress - I=20 > > think the latter far preferable, the former a short term=20 > expedient. =20 > > The latter gives us the chance to request another case for SNI, the=20 > > current hostname insisting on a fully qualified DNS name=20 > which isn't=20 > > really right for a securityName. > >=20 > > My personal view is that, currently, the TLS WG is rather=20 > preoccupied=20 > > with fixing the hole in renegotiation and I expect it will be some=20 > > months before 4366bis gets the attention it > deserves. > >=20 > > Tom Petch > >=20 > > > Wes Hardaker > > > Cobham Analytic Solutions > >=20 > >=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Jan 6 23:30:03 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0745B3A67F4 for ; Wed, 6 Jan 2010 23:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.080, 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 3LrhK9UKV6Yj for ; Wed, 6 Jan 2010 23:30:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9BBA73A6954 for ; Wed, 6 Jan 2010 23:30:01 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F083C0011; Thu, 7 Jan 2010 08:29:59 +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 nf-S0vkzx5qu; Thu, 7 Jan 2010 08:29:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9D53C000A; Thu, 7 Jan 2010 08:29:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C1D88FB1FA3; Thu, 7 Jan 2010 08:29:54 +0100 (CET) Date: Thu, 7 Jan 2010 08:29:54 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100107072954.GA38654@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , David Harrington , isms References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901ca8ef8$306a8000$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: isms Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.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: Thu, 07 Jan 2010 07:30:03 -0000 On Wed, Jan 06, 2010 at 06:45:09PM +0100, tom.petch wrote: > So I would make 5.1.1 something like > > "A session over UDP is identified by a unique combination of the remote > address, remote port number, local address and local port number and this > information MUST be available to the Transport Model for each and every incoming > datagram in order to derive the corresponding tlstmSessionID. > > Since DTLS may not make this information available, this may require an incoming > datagram to be preprocessed by the Transport Model in order to derive the > tlstmSessionID prior to passing the datagram to DTLS. One mechanism to achieve > this is described in Appendix ... but any mechanism that achieves the same > result conforms to this specification. > > Note too that entities MUST use a unique UDP source port number for each session > (connection?) to a remote destination IP- > address/port-number combination so that the remote entity can > distinguish one session from another." > > The rest of the current 5.1.1 is not wrong and is undoubtedly helpful, as Wes > reports, it just seems more like motherhood than a protocol specification:-) so > I would move it more or less as is to Appendix ... The text you want to move contains elements of procedure like this: 4) The UDP packet and the tlstmSessionID are passed to DTLS for integrity checking and decryption. If the message fails integrity checks or other (D)TLS security processing then increment the tlstmDTLSProtectionErrors counter, discard and stop processing the message. I consider text like this not appropriate for a non-normative appendix since the text details when certain normative counters are incremented. So if we make this multiplexing non-normative, we need to change what is counted. I still don't see what we gain by making this text non-normative. Are there any concrete systems out there that can't implement the multiplexing this way? /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 Thu Jan 7 03:44:40 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8013A68A5 for ; Thu, 7 Jan 2010 03:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 5j2v5e9wD5pC for ; Thu, 7 Jan 2010 03:44:39 -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 688AE28C11A for ; Thu, 7 Jan 2010 03:44:39 -0800 (PST) X-Trace: 282244054/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.227/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.227 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: AuwEAJNXRUs+vGnj/2dsb2JhbACCUIVWiFfAUwqEJgQ X-IronPort-AV: E=Sophos;i="4.49,234,1262563200"; d="scan'208";a="282244054" X-IP-Direction: IN Received: from 1cust227.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.227]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Jan 2010 11:44:31 +0000 Message-ID: <002401ca8f86$6c0a89a0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Juergen Schoenwaelder'" , "'Wes Hardaker'" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><20100105102139.GA34452@elstar.local> <028d01ca8e49$a306f760$0600a8c0@china.huawei.com> Date: Thu, 7 Jan 2010 11:25:00 +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] TLSTM -04 draft being published: wraps up alloutstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 11:44:40 -0000 ----- Original Message ----- From: "David Harrington" Sent: Tuesday, January 05, 2010 9:57 PM > Hi, > > I prefer the NEW text to the old text, but I am not convinced we need > to discuss multiple principals on a port. > > I have worked on applications that provided support for multiple > principles on a port, particularly for receiving different sets of > traps, and I think this is an engineering implementation decision. It > is really quite simple to use different ports for different > applications; demultiplexing a single port across multiple > applications adds complexity and requires some type of > registration/subscription mechanism. I am not convinced ISMS needs to > address this port-sharing approach, especially since using different > ports is so much easier. If we believe cross-vendor interoperability > for this feature is really important, then we should standardize the > feature more strongly than either the old or new text does. > > I smell significant feature-creep here, and the more complex we make > the transport model, the less likely it will be implemented and > deployed. David The TLS list, and to some extent the TLS documents, contain many references to the high cost of establishing a TLS session, in arriving at a MasterSecret. One consequence of this is the ability to reuse the MasterSecret to generate multiple sets of security credentials (which costs less to do) for use in multiple TLS connections. This is seen as necessary in https: where the client wants to download multiple objects in parallel. This function - and DTLS is the same - is probably of no use to SNMP but the idea that setting up a TLS session is expensive and to be avoided whenever possible looks more relevant. Hence the desire to multiplex principals across a TLS session; yes, it costs the application but saves in TLS. Tom Petch > dbh > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, January 05, 2010 5:22 AM From cfinss@dial.pipex.com Thu Jan 7 03:44:41 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C0C3A68A5 for ; Thu, 7 Jan 2010 03:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 G+7ocFqDopJ6 for ; Thu, 7 Jan 2010 03:44:40 -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 0A57E28C11D for ; Thu, 7 Jan 2010 03:44:39 -0800 (PST) X-Trace: 282244059/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.227/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.227 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: AuwEAJNXRUs+vGnj/2dsb2JhbACCUIVWiFfAUwqEJgQ X-IronPort-AV: E=Sophos;i="4.49,234,1262563200"; d="scan'208";a="282244059" X-IP-Direction: IN Received: from 1cust227.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.227]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Jan 2010 11:44:33 +0000 Message-ID: <002501ca8f86$6d6b0400$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Juergen Schoenwaelder'" , "'Wes Hardaker'" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><20100105102139.GA34452@elstar.local> <028d01ca8e49$a306f760$0600a8c0@china.huawei.com> Date: Thu, 7 Jan 2010 11:42:43 +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: [Isms] TLSTM -04 draft being published: wraps up alloutstanding edits - sessions X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 11:44:41 -0000 One of dbh's earlier comments on 5.1.1 was dbh So there can be only one DTLS session that exists between two endpoints? There cannot be two with different security principals or different securityLevels? + WH: where endpoints is srcaddr/srcport/dstaddr/dstport, yes. As is described as a MUST in multiple places. dbh I think that contradicts something I read earlier about securityLevels and mappings to crypto suites. + WH: I don't believe so. Let me know if you find a conflict. I wonder if dbh had s3.1.2 in mind which says " If a suitable interface between the TLS Transport Model and the (D)TLS Handshake Protocol is implemented to allow the selection of security level dependent algorithms (for example a security level to cipher_suites mapping table) then different security levels may be utilized by the application." Clearly not the case for DTLS between a given pair of endpoints. Tom Petch From ietfdbh@comcast.net Thu Jan 7 05:50: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 18E0E3A683C for ; Thu, 7 Jan 2010 05:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SARE_LWSHORTT=1.24] 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 Li4yG9ogT4kx for ; Thu, 7 Jan 2010 05:50:53 -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 980563A67EA for ; Thu, 7 Jan 2010 05:50:53 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA14.westchester.pa.mail.comcast.net with comcast id SbcP1d0040vyq2s5EdqsQA; Thu, 07 Jan 2010 13:50:52 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Sdqs1d001284sdk3Rdqs8c; Thu, 07 Jan 2010 13:50:52 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'tom.petch'" , "'Wes Hardaker'" References: <000401ca895b$a54a0000$0601a8c0@allison><004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> <001a01ca89f4$30015660$0601a8c0@allison> <00d301ca8a19$74ad7260$0600a8c0@china.huawei.com> Date: Thu, 7 Jan 2010 08:50:51 -0500 Message-ID: <041e01ca8fa0$6ced49b0$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: AcqJ/IdoqpBi1S+WR9qdA3aUwSEyiAAHIFhgAU6qnUAAExu2QA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.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: Thu, 07 Jan 2010 13:50:55 -0000 Hi, If we cite the older version, and the new version gets approved, and the new version either updates or obsoletes the older version, then the rfc-editor will probably ask our editors which is the correct reference. If we cite the newer version then the rfc-editor will not allow our document to be published until the new version is approved. Either way, this can be addressed during the IESG approval/RFC-editor queue process. dbh > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, January 06, 2010 11:47 PM > To: David Harrington; tom.petch; Wes Hardaker > Cc: isms@ietf.org; Pasi Eronen > Subject: RE: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > The TLS extensions draft is in IESG review. I believe there have been > some issues raised with the SNI, I need to follow up to see if they > require substantial changes to the document. In any case the revision > would need to be backward compatible with what is in 4366, if you were > going to define a new name type then there may be additional > considerations. > > Joe > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, December 31, 2009 5:02 AM > > To: 'tom.petch'; 'Wes Hardaker' > > Cc: Joseph Salowey (jsalowey); isms@ietf.org; 'Pasi Eronen' > > Subject: RE: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > > > My experience tells me that getting a document through the > > IESG approval process can take a year, more likely 6 months. > > If the bis status changes we can always change the reference > > later. But I don't get the sense that the bis will beat our > > document through the system, so I would prefer to point to > > the stable document unless, as Juergen points out, there is a > > real technical distinction. > > > > dbh > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Thursday, December 31, 2009 3:32 AM > > > To: Wes Hardaker > > > Cc: David Harrington; 'Joseph Salowey (jsalowey)'; > > isms@ietf.org; Pasi > > > Eronen > > > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > > > > > ----- Original Message ----- > > > From: "Wes Hardaker" > > > Sent: Wednesday, December 30, 2009 5:36 PM > > > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > > > > > > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker > > > > > > said: > > > > > > > > DH> Personally, I recommend against having a reference > to the bis > > > > DH> document. We are in WGLC and don't want publication > > > held up because of > > > > DH> a reference to bis. > > > > > > > > WH> I agree; I was trying not to specify which versions of > > > the TLS based > > > > WH> protocols we are requiring because I don't think there > > > are any features > > > > WH> of the newer ones that we need. There is no reason > > > that future versions > > > > WH> of TLS and DTLS couldn't be used as well assuming they > > > didn't introduce > > > > WH> a technical conflict with our document, which is unlikely. > > > > > > > > Whoops. Having re-read everything I realized I was > > > confused about which > > > > of the two issues David was talking about. I responded > > > about the DTLS > > > > reference but the discussion was surrounding the fact that > > > RFC4366 is > > > > the only RFC that documents the server name extension until > > > a new one > > > > gets published. Because of that, we'd either have to keep > > > referencing > > > > the older one (which doesn't cause any technical problems > > > that I'm aware > > > > of) or reference the ID and hope it completes soon. > Pasi may have > > a > > > > better idea about how the other document is progressing, > > > but unless it's > > > > almost identically timed I don't think it buys us much to > > > reference the ID. > > > > > > Um > > > > > > My point was rather that RFC4366 is obsoleted by RFC5246 > > because the > > > description of the extension technique has been removed > > from the TLS > > > extension document and made part of the base document, ie > > extensions > > > are base TLS as of TLS 1.2 (a key feature of current TLS list > > > discussions). > > > > > > 4366-bis will only contain details of specific extensions. > > > > > > SNI does appear in both RFC4366 and 4366-bis so from that > point of > > > view, either will do, so it is a choice of being allowed to > > depend on > > > an obsoleted document versus having to wait for an I-D to > > progress - I > > > think the latter far preferable, the former a short term > > expedient. > > > The latter gives us the chance to request another case > for SNI, the > > > current hostname insisting on a fully qualified DNS name > > which isn't > > > really right for a securityName. > > > > > > My personal view is that, currently, the TLS WG is rather > > preoccupied > > > with fixing the hole in renegotiation and I expect it > will be some > > > months before 4366bis gets the attention it > > deserves. > > > > > > Tom Petch > > > > > > > Wes Hardaker > > > > Cobham Analytic Solutions > > > > > > > > > > > From Robert.Story@cobham.com Thu Jan 7 07:35: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 DAB1B3A6850 for ; Thu, 7 Jan 2010 07:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 rz1+HDwAX1QW for ; Thu, 7 Jan 2010 07:35:19 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 16B013A67FB for ; Thu, 7 Jan 2010 07:35:18 -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 o07FZALK000398; Thu, 7 Jan 2010 09:35:10 -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 o07FZ4IB019151; Thu, 7 Jan 2010 09:35:04 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 10:35:03 -0500 Date: Thu, 7 Jan 2010 10:34:57 -0500 From: Robert Story To: "tom.petch" Message-ID: <20100107103457.5bad055f@sparta.com> In-Reply-To: <002501ca8f86$6d6b0400$0601a8c0@allison> References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <20100105102139.GA34452@elstar.local> <028d01ca8e49$a306f760$0600a8c0@china.huawei.com> <002501ca8f86$6d6b0400$0601a8c0@allison> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/aR.va_o5Ep02aw6VzKVzvVu"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 07 Jan 2010 15:35:03.0585 (UTC) FILETIME=[FB403110:01CA8FAE] Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up alloutstanding edits - sessions 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, 07 Jan 2010 15:35:20 -0000 --Sig_/aR.va_o5Ep02aw6VzKVzvVu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 7 Jan 2010 11:42:43 +0100 tom.petch wrote: TP> One of dbh's earlier comments on 5.1.1 was=20 TP> dbh So there can be only one DTLS session that exists between two TP> endpoints? TP>=20 TP> There cannot be two with different security principals or TP> different securityLevels? TP>=20 TP> + WH: where endpoints is srcaddr/srcport/dstaddr/dstport, TP> yes. As is described as a MUST in multiple places. TP>=20 TP> dbh I think that contradicts something I read TP> earlier about securityLevels and mappings to crypto suites. TP> + WH: I don't believe so. Let me know if you find a conflict. maybe the last paragraph of 5.3? Servers that wish to support multiple principals at a particular port SHOULD make use of the Server Name Indication extension defined in Section 3.1 of [RFC4366]. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/aR.va_o5Ep02aw6VzKVzvVu Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktF/ycACgkQ7/fVLLY1mnhidwCaAkrbwjjzkkBSE569wJwmYrcm uxgAoItJn4Gd+IaPaIZ6diSftjnAQRee =Mjpw -----END PGP SIGNATURE----- --Sig_/aR.va_o5Ep02aw6VzKVzvVu-- From wjhns1@hardakers.net Thu Jan 7 07:50: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 02C863A686B for ; Thu, 7 Jan 2010 07:50: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 DKT63PxhPDSN for ; Thu, 7 Jan 2010 07:50:35 -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 075D23A6857 for ; Thu, 7 Jan 2010 07:50:34 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 1B2579806D; Thu, 7 Jan 2010 07:50:33 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <000401ca895b$a54a0000$0601a8c0@allison> <004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> <001a01ca89f4$30015660$0601a8c0@allison> <00d301ca8a19$74ad7260$0600a8c0@china.huawei.com> <041e01ca8fa0$6ced49b0$0600a8c0@china.huawei.com> Date: Thu, 07 Jan 2010 07:50:32 -0800 In-Reply-To: <041e01ca8fa0$6ced49b0$0600a8c0@china.huawei.com> (David Harrington's message of "Thu, 7 Jan 2010 08:50:51 -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] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.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: Thu, 07 Jan 2010 15:50:37 -0000 >>>>> On Thu, 7 Jan 2010 08:50:51 -0500, "David Harrington" said: DH> Either way, this can be addressed during the IESG approval/RFC-editor DH> queue process. Agreed. I think that's the right change (and the new wording also says you can use any sort of selection method, not just 4366, to make it generic since we really don't care which is used). JS> if you were going to define a new name type then there may be JS> additional considerations. We're not. Though that might be useful, I think if we want to do that it warrants a new document at this point and probably within the TLS WG itself anyway. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Thu Jan 7 08: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 DE6113A68B7 for ; Thu, 7 Jan 2010 08:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Zupu7FQ1lxGl for ; Thu, 7 Jan 2010 08:12:18 -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 BE33D3A6850 for ; Thu, 7 Jan 2010 08:12:12 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA13.westchester.pa.mail.comcast.net with comcast id SeDN1d00B0cZkys5DgCCq9; Thu, 07 Jan 2010 16:12:12 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA10.westchester.pa.mail.comcast.net with comcast id SgCB1d002284sdk3WgCB5F; Thu, 07 Jan 2010 16:12:12 +0000 From: "David Harrington" To: "'Robert Story'" , "'tom.petch'" References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><20100105102139.GA34452@elstar.local><028d01ca8e49$a306f760$0600a8c0@china.huawei.com><002501ca8f86$6d6b0400$0601a8c0@allison> <20100107103457.5bad055f@sparta.com> Date: Thu, 7 Jan 2010 11:12:09 -0500 Message-ID: <044b01ca8fb4$2adcf750$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: AcqPrwF1UGSbf52uTFmQESJvvkP4qwAAFQrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20100107103457.5bad055f@sparta.com> Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up alloutstanding edits - sessions 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, 07 Jan 2010 16:12:24 -0000 Hi, My earlier comment was about multiple securityLevels multiplexed via the same port. I am less concerned about multiple principals using the same port. I do not think support for multiple security levels is really needed in TLSTM. It was added to USM, but except for very specific tasks like non-secure autodiscovery and non-secure Reports, it is not being used to my knowledge for normal communications. And since USM is mandatory-to-implement, it makes sense to use USM for these special non-secure tasks, and use SSHTM and TLSTM only for secure communications. I question whether support for multiple security levels is really needed in TLSTM. If not, it is added complexity without significant corresponding benefit. If a single port will be multiplexed for multiple securityLevels, then we need to make sure that a reduced-security connection doesn't somehow get used where a secure connection is expected. However, as we learned in the SSHTM work, we actually have no way of knowing the actual securityLevel of an underlying transport session, unless we have far more access into the underlying transport processing than we agreed we should have. It is up to the admin to actually configure the underlying transport to deliver that expected level of security. So the SNMP engine should always assume a secure transport model is being used to provide authPriv secure transport, and make the admin aware of that expectation. For comparison, this is from RFC 5592: The SSH Transport Model determines from SSH the identity of the authenticated principal and the type and address associated with an incoming message, and provides this information to SSH for an outgoing message. The SSH transport-layer algorithms used to provide authentication, data integrity, and encryption SHOULD NOT be exposed to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided this and settled for an assertion by the Security Model that the requirements of securityLevel were met. The SSH Transport Model has no mechanisms by which it can test whether an underlying SSH connection provides auth or priv, so the SSH Transport Model trusts that the underlying SSH connection has been properly configured to support authPriv security characteristics. An SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption that meets the highest level of SNMP security (authPriv). Outgoing messages specified with a securityLevel of noAuthNoPriv or authNoPriv are actually sent by the SSH Transport Model with authPriv-level protection. dbh > -----Original Message----- > From: Robert Story [mailto:Robert.Story@cobham.com] > Sent: Thursday, January 07, 2010 10:35 AM > To: tom.petch > Cc: David Harrington; 'Juergen Schoenwaelder'; 'Wes > Hardaker'; isms@ietf.org > Subject: Re: [Isms] TLSTM -04 draft being published: wraps up > alloutstanding edits - sessions > > On Thu, 7 Jan 2010 11:42:43 +0100 tom.petch wrote: > TP> One of dbh's earlier comments on 5.1.1 was > TP> dbh So there can be only one DTLS session that exists between two > TP> endpoints? > TP> > TP> There cannot be two with different security principals or > TP> different securityLevels? > TP> > TP> + WH: where endpoints is srcaddr/srcport/dstaddr/dstport, > TP> yes. As is described as a MUST in multiple places. > TP> > TP> dbh I think that contradicts something I read > TP> earlier about securityLevels and mappings to crypto suites. > TP> + WH: I don't believe so. Let me know if you find a conflict. > > maybe the last paragraph of 5.3? > > Servers that wish to support multiple principals at a > particular port > SHOULD make use of the Server Name Indication extension defined in > Section 3.1 of [RFC4366]. > > -- > Robert Story > Senior Software Engineer > SPARTA (dba Cobham Analytic Soloutions) > From adonati@motorola.com Fri Jan 8 06:19: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 DDCC43A6970 for ; Fri, 8 Jan 2010 06:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZnUNxinpLI1 for ; Fri, 8 Jan 2010 06:19:14 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id F093D3A6958 for ; Fri, 8 Jan 2010 06:19:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1262960349!52913085!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 18542 invoked from network); 8 Jan 2010 14:19:10 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jan 2010 14:19:10 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o08EJ9Ij022360 for ; Fri, 8 Jan 2010 07:19:09 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o08EJ9RF003213 for ; Fri, 8 Jan 2010 08:19:09 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o08EJ89j002626 for ; Fri, 8 Jan 2010 08:19:08 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 09:18:46 -0500 Message-ID: In-Reply-To: <044b01ca8fb4$2adcf750$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] TLSTM -04 draft being published: wraps up alloutstandingedits - sessions Thread-Index: AcqPrwF1UGSbf52uTFmQESJvvkP4qwAAFQrgAC70HxA= References: <20091231051339.GA26661@elstar.local><002701ca89f5$44721340$0601a8c0@allison><20091231125105.GB27340@elstar.local><02a601ca8a3c$a4fb8ba0$0601a8c0@allison><20100101115205.GA28799@elstar.local><20100105102139.GA34452@elstar.local><028d01ca8e49$a306f760$0600a8c0@china.huawei.com><002501ca8f86$6d6b0400$0601a8c0@allison><20100107103457.5bad055f@sparta.com> <044b01ca8fb4$2adcf750$0600a8c0@china.huawei.com> From: "Donati Andrew-MGIA0477" To: "David Harrington" , "Robert Story" , "tom.petch" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up alloutstandingedits - sessions 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, 08 Jan 2010 14:19:15 -0000 I am in agreement with the following opinion. dbh> I do not think support for multiple security levels is really needed in TLSTM. ... dbh> I question whether support for multiple security levels is really needed in TLSTM. dbh> If not, it is added complexity without significant corresponding benefit. Andy Donati=20 From root@core3.amsl.com Fri Jan 8 10:45:04 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 319B63A68B6; Fri, 8 Jan 2010 10:45:03 -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: <20100108184504.319B63A68B6@core3.amsl.com> Date: Fri, 8 Jan 2010 10:45:04 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-05.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:45:04 -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-05.txt Pages : 64 Date : 2010-01-08 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-08103621.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Fri Jan 8 11:00:01 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C3F3A683D for ; Fri, 8 Jan 2010 11:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 m4ioSopDHyXX for ; Fri, 8 Jan 2010 11:00:01 -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 F3B8D3A6838 for ; Fri, 8 Jan 2010 11:00:00 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id E4CE09808A for ; Fri, 8 Jan 2010 10:59:58 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Fri, 08 Jan 2010 10:59:58 -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 Subject: [Isms] TLSTM draft -05 published 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, 08 Jan 2010 19:00:02 -0000 I've published a -05 copy of the draft that has the following changes in it: 1) Miscellaneous small wording items pointed out mostly by Tom. 2) Other wording suggestions and clarifications discussed and agreed to on the list since -04 was published (most of the suggestions were by David H). - client/server wording - identity/principal consistency - sessionID/port-uniqueness consistency - certificate verification terminology consistency - Agreed-upon text surrounding the 4366 reference to make it more generic and reference it as an example. - removal of the text describing fate-sharing between the target mib and the tlstm mib. No fate sharing exists now, per WG consensus. 3) Implementation hint markings. Both David and Tom wanted to see them explicitly spelled out, so I went back through my mail archives and found the two places in addition to 5.1.1 that were talked about as being hints. I've added prefixes to the text in these places so they're now explicitly marked as advice. I didn't mark 5.1.1 that way since the text already describes that the section is discussing one possible approach and thus is already marked as a hint. A eventual link that should work for comparing the documents should be: http://tools.ietf.org/wg/isms/draft-ietf-isms-dtls-tm/draft-ietf-isms-dtls-tm-05-from-04.diff.html But it's not yet active. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Fri Jan 8 11:31:40 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC543A6835 for ; Fri, 8 Jan 2010 11:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.273, 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 jcPXoO3uskwG for ; Fri, 8 Jan 2010 11:31:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7095D3A67FB for ; Fri, 8 Jan 2010 11:31:39 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 456AAC0015; Fri, 8 Jan 2010 20:31: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 c1qdJzSb7djh; Fri, 8 Jan 2010 20:31: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 26035C0011; Fri, 8 Jan 2010 20:31:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B647FB60F9; Fri, 8 Jan 2010 20:31:33 +0100 (CET) Date: Fri, 8 Jan 2010 20:31:32 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100108193132.GA41994@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] TLSTM draft -05 published 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, 08 Jan 2010 19:31:40 -0000 On Fri, Jan 08, 2010 at 07:59:58PM +0100, Wes Hardaker wrote: > I've published a -05 copy of the draft that has the following > changes in it: [...] Thanks for the update. I think we are getting pretty close to delivery. WG last call reviewers, please check the changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jsalowey@cisco.com Fri Jan 8 15:46: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 B23153A67D4 for ; Fri, 8 Jan 2010 15:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.869 X-Spam-Level: X-Spam-Status: No, score=-9.869 tagged_above=-999 required=5 tests=[AWL=0.730, 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 HdyPtQxxFMBb for ; Fri, 8 Jan 2010 15:46:07 -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 E933A3A6405 for ; Fri, 8 Jan 2010 15:46:05 -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: ApoEAIdSR0urRN+K/2dsb2JhbADCJJQOgiuCBAQ X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208";a="72085943" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Jan 2010 23:46:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o08Nk4DP017682 for ; Fri, 8 Jan 2010 23:46:04 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 15:46:04 -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: Fri, 8 Jan 2010 15:46:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on TlstmAddrEntry and TlstmCertToTSNEntry Thread-Index: AcqQvLz0KxZkBnBGTDO74vArzXA24Q== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 08 Jan 2010 23:46:04.0322 (UTC) FILETIME=[BDA1A820:01CA90BC] Subject: [Isms] Question on TlstmAddrEntry and TlstmCertToTSNEntry 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, 08 Jan 2010 23:46:07 -0000 The text in these MIB modules seems to indicate that the tlstmAddrServerFingerprint object can only be used to match a specific certificate.=20 On the other hand it seems the tlstmCertToTSNFingerprint object can be used to match either a specific end-entity certificate or a CA certificate.=20 Why are these two cases treated differently? Why not allow the tlstmAddrServerFingerprint to reference a CA and use the tlstmAddrServerIdentity for identity? If the tlstmAddrServerFingerprint is present is tlstmAddrServerIdentity ignored?=20 Joe From wjhns1@hardakers.net Fri Jan 8 17:15:21 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D413A6911 for ; Fri, 8 Jan 2010 17:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2YZnY+JIgsW for ; Fri, 8 Jan 2010 17:15:14 -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 4784B3A6908 for ; Fri, 8 Jan 2010 17:15:12 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BED9198046; Fri, 8 Jan 2010 17:15:08 -0800 (PST) From: Wes Hardaker To: "Joseph Salowey \(jsalowey\)" Organization: Sparta References: Date: Fri, 08 Jan 2010 17:15:08 -0800 In-Reply-To: (Joseph Salowey's message of "Fri, 8 Jan 2010 15:46:03 -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] IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry 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, 09 Jan 2010 01:15:21 -0000 >>>>> On Fri, 8 Jan 2010 15:46:03 -0800, "Joseph Salowey (jsalowey)" said: JS> The text in these MIB modules seems to indicate that the JS> tlstmAddrServerFingerprint object can only be used to match a specific JS> certificate. JS> On the other hand it seems the tlstmCertToTSNFingerprint object can be JS> used to match either a specific end-entity certificate or a CA JS> certificate. JS> Why are these two cases treated differently? They're different cases, admittedly similar. The real result is that for the mapping to a securityName it really needed to be done to make the resulting SNMPv3/TLS protocol even usable (IE, if we don't have a securityName in the end of the mapping we're sunk). The WG in Stockholm (I'm pretty sure; I'd have to go back and look at the minutes and/or audio tape to be 100% confident) decided that we shouldn't do a full set of trust-anchor configuration objects because that was beyond scope of the WG. But we should support referencing a single fingerprint to support self-signed certificates (one primary reason is that the syslog WG decided they should do it, so we should too). So that's exactly what the object does: fingerprints of the presented certificate, and only the presented certificate. Note that the elements of procedure allows for other trust verification paths to succeed if no row exists in the table though (IE, other 5280 or similar processes can be used instead). I find it interesting that there are a number of WGs that have produced psuedo-requirements for having a trust anchor management solution. I suspect that "soon" would be a good time to start such a management endeavor within the TLS WG. -- Wes Hardaker Cobham Analytic Solutions From jsalowey@cisco.com Sat Jan 9 17:48: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 EF36B3A67FA for ; Sat, 9 Jan 2010 17:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.015 X-Spam-Level: X-Spam-Status: No, score=-10.015 tagged_above=-999 required=5 tests=[AWL=0.584, 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 X1yA86SAmc1V for ; Sat, 9 Jan 2010 17:48:05 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2164C3A6407 for ; Sat, 9 Jan 2010 17:48:05 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANrASEurRN+K/2dsb2JhbADBCpNFhC8E X-IronPort-AV: E=Sophos;i="4.49,249,1262563200"; d="scan'208";a="130915099" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2010 01:47:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0A1lnVQ003879; Sun, 10 Jan 2010 01:47:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Jan 2010 17:47:50 -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: Sat, 9 Jan 2010 17:47:46 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry Thread-Index: AcqQyTEYzPhA0HNOQDKzDLe80LoHmwAzFnfA References: From: "Joseph Salowey (jsalowey)" To: "Wes Hardaker" X-OriginalArrivalTime: 10 Jan 2010 01:47:50.0000 (UTC) FILETIME=[EA916700:01CA9196] Cc: isms@ietf.org Subject: Re: [Isms] IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry 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: Sun, 10 Jan 2010 01:48:06 -0000 =20 > JS> The text in these MIB modules seems to indicate that the=20 > JS> tlstmAddrServerFingerprint object can only be used to match a=20 > JS> specific certificate. >=20 > JS> On the other hand it seems the tlstmCertToTSNFingerprint=20 > object can=20 > JS> be used to match either a specific end-entity certificate or a CA=20 > JS> certificate. >=20 > JS> Why are these two cases treated differently? >=20 > They're different cases, admittedly similar. The real result=20 > is that for the mapping to a securityName it really needed to=20 > be done to make the resulting SNMPv3/TLS protocol even usable=20 > (IE, if we don't have a securityName in the end of the=20 > mapping we're sunk). >=20 [Joe] Correct operation of the protocol requires the server certificate to be authenticated and authorized, its not any less important than SecurityName mapping. =20 > The WG in Stockholm (I'm pretty sure; I'd have to go back and=20 > look at the minutes and/or audio tape to be 100% confident)=20 > decided that we shouldn't do a full set of trust-anchor=20 > configuration objects because that was beyond scope of the=20 > WG. But we should support referencing a single fingerprint=20 > to support self-signed certificates (one primary reason is=20 > that the syslog WG decided they should do it, so we should=20 > too). So that's exactly what the object does: fingerprints=20 > of the presented certificate, and only the presented=20 > certificate. Note that the elements of procedure allows for=20 > other trust verification paths to succeed if no row exists in=20 > the table though (IE, other 5280 or similar processes can be=20 > used instead). >=20 [Joe] I definitely agree with having fingerprint support. Another common deployment would be to have a common trust root that issues certificates for devices. The document already covers this case for security name, it seems a little odd not to cover this case for the server certificate as well. =20 > I find it interesting that there are a number of WGs that=20 > have produced psuedo-requirements for having a trust anchor=20 > management solution. I suspect that "soon" would be a good=20 > time to start such a management endeavor within the TLS WG. >=20 [Joe] Perhaps. There is some trust anchor management work going on in PKIX and the apps area is working on basic common validations procedures for certificates.=20 >=20 > -- > Wes Hardaker > Cobham Analytic Solutions >=20 From j.schoenwaelder@jacobs-university.de Mon Jan 11 00:09: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 347293A6905 for ; Mon, 11 Jan 2010 00:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=-0.951, 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 yS6EBMttczAT for ; Mon, 11 Jan 2010 00:09: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 274E13A68AB for ; Mon, 11 Jan 2010 00:09:48 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E77A1C001C for ; Mon, 11 Jan 2010 09:09:45 +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 yxKnzbLTBQPS; Mon, 11 Jan 2010 09:09:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 970B9C0019; Mon, 11 Jan 2010 09:09:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4585EFC358F; Mon, 11 Jan 2010 09:09:38 +0100 (CET) Date: Mon, 11 Jan 2010 09:09:38 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100111080938.GB27502@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] multiple security levels in the dtls transport model 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, 11 Jan 2010 08:09:50 -0000 Hi, it seems that we are getting really close to being done with the DTLS document. There is, however, one open issue remaining concerning the support for multiple security levels in the (D)TLS transport model. The document current spells out how you check security levels in every direction to make sure that the requested security level matches the transport, etc. Just search for "tmRequestedSecurityLevel" or "security level" to find the sections where this discussion takes place. David Harrington raised a last-call comments that this adds unneeded complexity and he wants to always assume authPriv for all D(TLS) transports (which was done in SSH). Tom has agreed with David> and he would prefer to only support authPriv. As it stands, the document leaves the details how a requested security level is mapped to (D)TLS open for implementations: [...] It is also implementation-dependent and possibly policy-dependent how tmRequestedSecurityLevel will be used to influence the security capabilities provided by the (D)TLS session. However this is done, the security capabilities provided by (D)TLS MUST be at least as high as the level of security indicated by the tmRequestedSecurityLevel parameter. The WG needs to come to a conclusion whether the support for multiple security levels should remain in the document or taken out. To better understand the issue, I would like those who like to have this feature to provide use cases how noAuthNoPriv maps to a DTLS transport or how authNoPriv maps to a DTLS transport and what the requirements are that are driving the need for such a feature. /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 Jan 11 09:00:31 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A3D3A6898 for ; Mon, 11 Jan 2010 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfC4ydZ3lBDq for ; Mon, 11 Jan 2010 09:00:31 -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 D84CC3A687A for ; Mon, 11 Jan 2010 09:00:30 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5DC6398077; Mon, 11 Jan 2010 09:00:27 -0800 (PST) From: Wes Hardaker To: "Joseph Salowey \(jsalowey\)" Organization: Sparta References: Date: Mon, 11 Jan 2010 09:00:27 -0800 In-Reply-To: (Joseph Salowey's message of "Sat, 9 Jan 2010 17:47:46 -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] IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry 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, 11 Jan 2010 17:00:31 -0000 >>>>> On Sat, 9 Jan 2010 17:47:46 -0800, "Joseph Salowey (jsalowey)" said: JS> [Joe] Correct operation of the protocol requires the server certificate JS> to be authenticated and authorized, its not any less important than JS> SecurityName mapping. True; didn't mean to imply that's not the case. JS> [Joe] I definitely agree with having fingerprint support. Another JS> common deployment would be to have a common trust root that issues JS> certificates for devices. The document already covers this case for JS> security name, it seems a little odd not to cover this case for the JS> server certificate as well. The split/difference was because in one side we have to derive information (the securityName) from the presented certificate and just "accepting the connection" isn't enough. On the client side, though, we don't need to do that. It would certainly be nice to support configuration for a list of trust anchors that are acceptable to use for connection establishment but it's was considered beyond scope of the WG because that would be getting involved with CA trust anchor certificate management. I'd actually like to see that work done (somewhere). It'd require a few mib configuration tables, though, and tables that aren't necessarily specific to SNMP even. On the other hand, adding a CA column to the existing tlstmAddrTable isn't a good solution because it requires a row-per-connection and if you have a device set up to make connections to 100 other places then when the CA certificate changed you have to update 100 different rows. It would need to be in another table that listed it singularly as a valid CA to use for any outgoing connection. And since that is not necessarily protocol dependent, it should really go into a TLS-CA-MIB or TLS-TA-MIB or something. >> I find it interesting that there are a number of WGs that >> have produced psuedo-requirements for having a trust anchor >> management solution. I suspect that "soon" would be a good >> time to start such a management endeavor within the TLS WG. >> JS> [Joe] Perhaps. There is some trust anchor management work going on in JS> PKIX and the apps area is working on basic common validations procedures JS> for certificates. Yep; I'm aware of the TAMP work in PKIX as well. They're not quite a complete solution for us, though. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 11 09:19:03 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3483A67FB for ; Mon, 11 Jan 2010 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 W4IgRKPXczDX for ; Mon, 11 Jan 2010 09:19:02 -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 188513A62C1 for ; Mon, 11 Jan 2010 09:19:02 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5746198078 for ; Mon, 11 Jan 2010 09:18:59 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20100111080938.GB27502@elstar.local> Date: Mon, 11 Jan 2010 09:18:59 -0800 In-Reply-To: <20100111080938.GB27502@elstar.local> (Juergen Schoenwaelder's message of "Mon, 11 Jan 2010 09:09:38 +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] Ismsmultiple security levels in the dtls transport model 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, 11 Jan 2010 17:19:03 -0000 >>>>> On Mon, 11 Jan 2010 09:09:38 +0100, Juergen Schoenwaelder said: JS> [...] It is also implementation-dependent and possibly JS> policy-dependent how tmRequestedSecurityLevel will be used to JS> influence the security capabilities provided by the (D)TLS JS> session. However this is done, the security capabilities JS> provided by (D)TLS MUST be at least as high as the level of JS> security indicated by the tmRequestedSecurityLevel parameter. One other important point to consider about this is that by dictating directly that every TLS connection is authPriv even when the security in TLS has been turned off via a NULL algorithm selection (eg), you actually prevent any implementation from implementing this feature. IE, it becomes impossible for an implementation to follow the spec and to have a product-differentiation feature that would map authNoPriv to a particular TLS algorithm set, etc. JS> The WG needs to come to a conclusion whether the support for multiple JS> security levels should remain in the document or taken out. To better JS> understand the issue, I would like those who like to have this feature JS> to provide use cases how noAuthNoPriv maps to a DTLS transport or how JS> authNoPriv maps to a DTLS transport and what the requirements are that JS> are driving the need for such a feature. The intent of that text is to allow for the following combinations: | | noAuthNoPriv | authNoPriv | authPriv | | Authentication | NULL | something* | something | | Encryption | NULL | NULL | something | But to explicitly disallow: | | noAuthNoPriv | authNoPriv | authPriv | | Authentication | | NULL | NULL | | Encryption | | | NULL | It allows for an implementation to select algorithms based on what traffic needs to go over the connection, just as SNMPv3 has always allowed in USM. I've heard of people specifically wanting authNoPriv support because they didn't want the encryption overhead (especially on small devices). It's absolutely true to say that it's not our job to define what is and what isn't acceptable levels of authentication or encryption. Some may consider DES sufficient for allowing the priv bit to be turned on and usable. Others may not. Certainly I don't think anyone thinks the NULL encryption algorithm is an ok choice for protecting traffic marked with the priv bit. Note that the document already allows an implementation to ignore this whole issue since it says: Implementations MAY choose to force (D)TLS to only allow cipher_suites that provide both authentication and privacy to guarantee this assertion. IE, an implementation is free to use the "no complexity" route already and assume every tunnel can handle authPriv or lower. -- Wes Hardaker Cobham Analytic Solutions From jsalowey@cisco.com Mon Jan 11 09:33:40 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AB73A6817 for ; Mon, 11 Jan 2010 09:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.112 X-Spam-Level: X-Spam-Status: No, score=-10.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 Uo44d-sQY3ZX for ; Mon, 11 Jan 2010 09:33:39 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 329EA3A67FD for ; Mon, 11 Jan 2010 09:33:39 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANbvSkurRN+K/2dsb2JhbADFDJNohC8E X-IronPort-AV: E=Sophos;i="4.49,257,1262563200"; d="scan'208";a="131504699" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2010 17:33:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0BHXaq6015451; Mon, 11 Jan 2010 17:33:36 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:33:36 -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: Mon, 11 Jan 2010 09:33:34 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry Thread-Index: AcqS36LDePfBV5t2QJqtUqe16WnR1wAAnBmw References: From: "Joseph Salowey (jsalowey)" To: "Wes Hardaker" X-OriginalArrivalTime: 11 Jan 2010 17:33:36.0117 (UTC) FILETIME=[344D7250:01CA92E4] Cc: isms@ietf.org Subject: Re: [Isms] IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry 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, 11 Jan 2010 17:33:40 -0000 =20 > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net]=20 > Sent: Monday, January 11, 2010 9:00 AM > To: Joseph Salowey (jsalowey) > Cc: Wes Hardaker; isms@ietf.org > Subject: Re: IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry >=20 > >>>>> On Sat, 9 Jan 2010 17:47:46 -0800, "Joseph Salowey=20 > (jsalowey)" said: >=20 > JS> [Joe] Correct operation of the protocol requires the server=20 > JS> certificate to be authenticated and authorized, its not any less=20 > JS> important than SecurityName mapping. >=20 > True; didn't mean to imply that's not the case. >=20 > JS> [Joe] I definitely agree with having fingerprint support.=20 > Another=20 > JS> common deployment would be to have a common trust root=20 > that issues=20 > JS> certificates for devices. The document already covers=20 > this case for=20 > JS> security name, it seems a little odd not to cover this=20 > case for the=20 > JS> server certificate as well. >=20 > The split/difference was because in one side we have to=20 > derive information (the securityName) from the presented=20 > certificate and just "accepting the connection" isn't enough.=20 > On the client side, though, we don't need to do that. It=20 > would certainly be nice to support configuration for a list=20 > of trust anchors that are acceptable to use for connection=20 > establishment but it's was considered beyond scope of the WG=20 > because that would be getting involved with CA trust anchor=20 > certificate management. I'd actually like to see that work=20 > done (somewhere). It'd require a few mib configuration=20 > tables, though, and tables that aren't necessarily specific=20 > to SNMP even. >=20 [Joe] It seems you are doing trust anchor management for the other side. I think even if you do a generic trust anchor management interface you would still need to make specific entries for applications. I can see your argument that even given this a generic solution might be better. I think we can take this off line and see what it might look like. =20 One question/nit: in section 5.3, 3b - says that path validation like 5280 MUST be followed, isn't this only the case if a fingerprint match was not available?=20 =20 > On the other hand, adding a CA column to the existing=20 > tlstmAddrTable isn't a good solution because it requires a=20 > row-per-connection and if you have a device set up to make=20 > connections to 100 other places then when the CA certificate=20 > changed you have to update 100 different rows. > It would need to be in another table that listed it=20 > singularly as a valid CA to use for any outgoing connection. =20 > And since that is not necessarily protocol dependent, it=20 > should really go into a TLS-CA-MIB or TLS-TA-MIB or something. > >> I find it interesting that there are a number of WGs that have=20 > >> produced psuedo-requirements for having a trust anchor management=20 > >> solution. I suspect that "soon" would be a good time to=20 > start such a=20 > >> management endeavor within the TLS WG. > >>=20 > JS> [Joe] Perhaps. There is some trust anchor management work=20 > going on=20 > JS> in PKIX and the apps area is working on basic common validations=20 > JS> procedures for certificates. >=20 > Yep; I'm aware of the TAMP work in PKIX as well. They're not=20 > quite a complete solution for us, though. >=20 [Joe] Yup.=20 > -- > Wes Hardaker > Cobham Analytic Solutions >=20 From j.schoenwaelder@jacobs-university.de Mon Jan 11 11:25: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 95DA63A68A0 for ; Mon, 11 Jan 2010 11:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.312, 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 gWHY7IslnlWT for ; Mon, 11 Jan 2010 11:25:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 99CF63A68E0 for ; Mon, 11 Jan 2010 11:25:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E23CDC0019; Mon, 11 Jan 2010 20:25:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YlDCOOPUYc5O; Mon, 11 Jan 2010 20:25:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0465EC001F; Mon, 11 Jan 2010 20:25:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D801EFC60BF; Mon, 11 Jan 2010 20:25:24 +0100 (CET) Date: Mon, 11 Jan 2010 20:25:24 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100111192524.GC30199@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20100111080938.GB27502@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismsmultiple security levels in the dtls transport model 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, 11 Jan 2010 19:25:37 -0000 On Mon, Jan 11, 2010 at 06:18:59PM +0100, Wes Hardaker wrote: > >>>>> On Mon, 11 Jan 2010 09:09:38 +0100, Juergen Schoenwaelder said: > > JS> [...] It is also implementation-dependent and possibly > JS> policy-dependent how tmRequestedSecurityLevel will be used to > JS> influence the security capabilities provided by the (D)TLS > JS> session. However this is done, the security capabilities > JS> provided by (D)TLS MUST be at least as high as the level of > JS> security indicated by the tmRequestedSecurityLevel parameter. > > One other important point to consider about this is that by dictating > directly that every TLS connection is authPriv even when the security in > TLS has been turned off via a NULL algorithm selection (eg), you > actually prevent any implementation from implementing this feature. IE, > it becomes impossible for an implementation to follow the spec and to > have a product-differentiation feature that would map authNoPriv to a > particular TLS algorithm set, etc. Yes, but this is what the WG decided to do with SSH. So why is (D)TLS different? > JS> The WG needs to come to a conclusion whether the support for multiple > JS> security levels should remain in the document or taken out. To better > JS> understand the issue, I would like those who like to have this feature > JS> to provide use cases how noAuthNoPriv maps to a DTLS transport or how > JS> authNoPriv maps to a DTLS transport and what the requirements are that > JS> are driving the need for such a feature. > > The intent of that text is to allow for the following combinations: > > | | noAuthNoPriv | authNoPriv | authPriv | > | Authentication | NULL | something* | something | > | Encryption | NULL | NULL | something | > > But to explicitly disallow: > > | | noAuthNoPriv | authNoPriv | authPriv | > | Authentication | | NULL | NULL | > | Encryption | | | NULL | > > It allows for an implementation to select algorithms based on what > traffic needs to go over the connection, just as SNMPv3 has always > allowed in USM. I've heard of people specifically wanting authNoPriv > support because they didn't want the encryption overhead (especially on > small devices). Can you give me an example for something you consider an authNoPriv setting for (D)TLS? I understand the SNMP side of things, not so much the (D)TLS side of creating something that maps authNoPriv. > It's absolutely true to say that it's not our job to define what is and > what isn't acceptable levels of authentication or encryption. Some may > consider DES sufficient for allowing the priv bit to be turned on and > usable. Others may not. Certainly I don't think anyone thinks the NULL > encryption algorithm is an ok choice for protecting traffic marked with > the priv bit. > > Note that the document already allows an implementation to ignore this > whole issue since it says: > > Implementations MAY choose to force (D)TLS to only allow > cipher_suites that provide both authentication and privacy to > guarantee this assertion. > > IE, an implementation is free to use the "no complexity" route already > and assume every tunnel can handle authPriv or lower. I am trying to understand why we decided to not go into crypto algorithm details for the SSH TM and why we should do different for the D(TLS) TM. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Robert.Story@cobham.com Mon Jan 11 15:50: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 872623A6881 for ; Mon, 11 Jan 2010 15:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 sE5r8wssDPBS for ; Mon, 11 Jan 2010 15:50:31 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7B9A33A6835 for ; Mon, 11 Jan 2010 15:50: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 o0BNoRAh022494; Mon, 11 Jan 2010 17:50:27 -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 o0BNoRO4028720; Mon, 11 Jan 2010 17:50:27 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 18:50:26 -0500 Date: Mon, 11 Jan 2010 18:50:12 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100111185012.42da15af@sparta.com> In-Reply-To: <20100111192524.GC30199@elstar.local> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/gpWjmMRU=cBcPgu2hTBdzC4"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 11 Jan 2010 23:50:26.0490 (UTC) FILETIME=[D92291A0:01CA9318] Cc: "isms@ietf.org" Subject: Re: [Isms] Ismsmultiple security levels in the dtls transport model 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, 11 Jan 2010 23:50:32 -0000 --Sig_/gpWjmMRU=cBcPgu2hTBdzC4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 11 Jan 2010 20:25:24 +0100 Juergen wrote: JS> Yes, but this is what the WG decided to do with SSH. So why is (D)TLS=20 JS> different? I'm sure there was some debate on the issue then. Maybe someone who took part in that debate could summarize the issue? I haven't had the time to participate in IETF work recently, so I missed the opportunity to participate in the SSH decision, but I'll throw in my 2 bits on the issue now.=20 - RFC 3411 says "it is explicitly allowed to send messages which do not require authentication or privacy." I think there should be a very good reason for a security model to limit applications/users further. - customers with secure and/or private networks don't want the overhead of encryption on simple traffic monitoring packets. This is most likely why noAuthNoPriv was created in the first place. JS> Can you give me an example for something you consider an authNoPriv JS> setting for (D)TLS? I understand the SNMP side of things, not so much JS> the (D)TLS side of creating something that maps authNoPriv. I took a quick peek at 5246, and was disappointed to find that they define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit negotiating it (it is only used at start of session, before real suite is negotiated). So noAuthNoPriv is out. That leaves authNoPriv as the next best choice. The cipher suites section (A.5) of 5246 defines 3 suites without encryption: TLS_RSA_WITH_NUL= L_MD5, TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256. JS> > Note that the document already allows an implementation to ignore this JS> > whole issue since it says: JS> >=20 JS> > Implementations MAY choose to force (D)TLS to only allow JS> > cipher_suites that provide both authentication and privacy to JS> > guarantee this assertion. I think this offers a good compromise. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/gpWjmMRU=cBcPgu2hTBdzC4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktLuUEACgkQ7/fVLLY1mniOcgCfQUsQTxeCxerIxbXRCHSGXRUY Gk0Anj3/R8FHUENgp28M1YS7NxPqoohz =nIc+ -----END PGP SIGNATURE----- --Sig_/gpWjmMRU=cBcPgu2hTBdzC4-- From wjhns1@hardakers.net Mon Jan 11 16:32:54 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 3D9C03A68FE for ; Mon, 11 Jan 2010 16:32:54 -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 EMWyyvHE4Ds6 for ; Mon, 11 Jan 2010 16:32:53 -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 4A1D93A67E4 for ; Mon, 11 Jan 2010 16:32:53 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 430EC9806C; Mon, 11 Jan 2010 16:32:50 -0800 (PST) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> Date: Mon, 11 Jan 2010 16:32:49 -0800 In-Reply-To: <20100111185012.42da15af@sparta.com> (Robert Story's message of "Mon, 11 Jan 2010 18:50: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] Ismsmultiple security levels in the dtls transport model 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, 12 Jan 2010 00:32:54 -0000 >>>>> On Mon, 11 Jan 2010 18:50:12 -0500, Robert Story said: JS> Can you give me an example for something you consider an authNoPriv JS> setting for (D)TLS? I understand the SNMP side of things, not so much JS> the (D)TLS side of creating something that maps authNoPriv. RS> I took a quick peek at 5246, and was disappointed to find that they RS> define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit RS> negotiating it (it is only used at start of session, before real suite RS> is negotiated). So noAuthNoPriv is out. I actually agree with everyone else here that there is no real benefit to providing noAuthNoPriv support for DTLS; we really only care about protecting traffic in either the authNoPriv states or the authPriv states. RS> That leaves authNoPriv as the next best choice. The cipher suites RS> section (A.5) of 5246 defines 3 suites without encryption: RS> TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and RS> TLS_RSA_WITH_NULL_SHA256. That's very useful information, so thanks for looking it up (I was planning on looking up the exact suite names since I couldn't remember them but hadn't yet). JS> > Note that the document already allows an implementation to ignore this JS> > whole issue since it says: JS> > JS> > Implementations MAY choose to force (D)TLS to only allow JS> > cipher_suites that provide both authentication and privacy to JS> > guarantee this assertion. RS> I think this offers a good compromise. If an implementation wanted to choose not to support any of the algorithms you mention above they wouldn't even have to have if() statements for checking the snmpv3 bits. I agree. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Jan 11 23:52:43 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BE93A68A8 for ; Mon, 11 Jan 2010 23:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.295, 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 chJIZOexHksx for ; Mon, 11 Jan 2010 23:52:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 553BC3A6765 for ; Mon, 11 Jan 2010 23:52:42 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E56A4C0010; Tue, 12 Jan 2010 08:52:39 +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 KIm0aLwb7ytF; Tue, 12 Jan 2010 08:52:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42B97C000B; Tue, 12 Jan 2010 08:52:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 02921FC70E7; Tue, 12 Jan 2010 08:52:31 +0100 (CET) Date: Tue, 12 Jan 2010 08:52:31 +0100 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100112075231.GA31341@elstar.local> Mail-Followup-To: Robert Story , Wes Hardaker , "isms@ietf.org" References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100111185012.42da15af@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 07:52:43 -0000 On Tue, Jan 12, 2010 at 12:50:12AM +0100, Robert Story wrote: > I'm sure there was some debate on the issue then. Maybe someone who > took part in that debate could summarize the issue? As far as I recall, the decision was to resist the temptation to peek inside the internals of the security protocol, that is the negotiation of the crypto algorithms. So it was more an architectural and layering decision. People commonly associate authentication and encryption with SSH (even though SSH has NULL algorithms). The same might be true for (D)TLS. > I haven't had the time to participate in IETF work recently, so I > missed the opportunity to participate in the SSH decision, but I'll > throw in my 2 bits on the issue now. > > - RFC 3411 says "it is explicitly allowed to send messages which do not > require authentication or privacy." I think there should be a very good > reason for a security model to limit applications/users further. The SNMP application can send noAuthNoPriv messages but the transport ships them via an authPriv "tunnel". The WG concluded that providing a higher level of security on the wire than what was requested by the SNMP application is acceptable. > - customers with secure and/or private networks don't want the overhead > of encryption on simple traffic monitoring packets. This is most > likely why noAuthNoPriv was created in the first place. Note that the performance equation looks slightly different with (D)TLS and SSH. The big performance hit is session key generation - so the first thing you have to worry about is to avoid unnecessary session key generation. But yes, encryption has some price. > JS> Can you give me an example for something you consider an authNoPriv > JS> setting for (D)TLS? I understand the SNMP side of things, not so much > JS> the (D)TLS side of creating something that maps authNoPriv. > > I took a quick peek at 5246, and was disappointed to find that they > define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit > negotiating it (it is only used at start of session, before real suite > is negotiated). So noAuthNoPriv is out. > > That leaves authNoPriv as the next best choice. The cipher suites > section (A.5) of 5246 defines 3 suites without encryption: > TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and > TLS_RSA_WITH_NULL_SHA256. Thanks, this is what I was looking for. > JS> > Note that the document already allows an implementation to ignore this > JS> > whole issue since it says: > JS> > > JS> > Implementations MAY choose to force (D)TLS to only allow > JS> > cipher_suites that provide both authentication and privacy to > JS> > guarantee this assertion. > > I think this offers a good compromise. There was a concern raised during WG last call that the support for different security levels adds complexity to the EoP. The WG needs to come to a conclusion whether this additional complexity is well justified or not. I understand that at least two WG members with some implementation background like to have the flexibility to map authNoPriv to an appropriate (D)TLS cipher suite. I guess it is now up to those who are concerned about the complexity to make a point why the price is too high to support this feature by pointing to concrete parts of the ID. Please do so as soon as possible so that we can get this issue resolved in a timely manner. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Jan 12 06:08:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17F93A6910 for ; Tue, 12 Jan 2010 06:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 BRIKa-1Ahqvy for ; Tue, 12 Jan 2010 06:08:07 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 1847B3A6782 for ; Tue, 12 Jan 2010 06:08:06 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id UdmG1d0071swQuc51e80MC; Tue, 12 Jan 2010 14:08:00 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta15.westchester.pa.mail.comcast.net with comcast id Ue8K1d003284sdk3be8K1W; Tue, 12 Jan 2010 14:08:20 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Robert Story'" References: <20100111080938.GB27502@elstar.local><20100111192524.GC30199@elstar.local><20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> Date: Tue, 12 Jan 2010 09:08:03 -0500 Message-ID: <072701ca9390$a849e830$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: AcqTXDptcdRGXXXjRcG4MfUR7ve11AAMCGnA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20100112075231.GA31341@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 14:08:08 -0000 With SSHTM, we worked very hard to keep the transport model from knowing about the underlying ciphersuites. We had massive discussions about this topic, and it was extremely difficult editing the SSHTM docs without getting into mentioning the specific authentication or encryption mechanisms in use in the lower layer. But WG consensus was clear - the SNMP engine should NOT have visibility into the algorithms or cipher suites being used at the lower layers. The operator was responsible for configuring the lower layer to provide security. And since SNMP had no insight into which suites were being used, SNMP could not determine whether the operator's configuration did or did not provide auth and priv. The transport model had to trust that the operator had configured things correctly. period. Now this whole discussion of supporting mutliple security levels goes directly against that WG consensus to not reveal the underlying mechanisms or ciphersuites. If we are going to support multiple securityLevels, then I think the standard should identify the mandatory-to-implement ciphersuites to support each securityLevel, so we have interoperability. And that begins to open a whole can of worms ... Now we need to start thinking about how to configure the SNMP to decide which traps to send over which securitylevel, and which OIDs have sensitive information and which are not sensitive, and yada yada yada ... Added complexity with no real benefit because people will not do this level of data access control. If we do not get into discussing specific ciphersuites and algorithms, then we can treat all SNMP communications over TLS as being one securityLevel. The operator can configure all SNMP/(D)TLS to work using one assumed securityLevel. Honestly it doesn't matter much which securitylevel is supported, although we should make strong security (authpriv) mandatory-to-implement, as per BCP 61. If the operator wants to deploy a TLS configuration that only provides authNoPriv, then that is a deployment decision. If the operator wants to deploy their TLS environment to provide one level of security from node A to node B, and have a different level of security between nodes A and C, then they can do so by configuring the TLS-layer negotiations to use specific suites (in an implementation-dependent manner). This type of deployment decision might be made for small devices, but also in environments where encryption is not permitted (by company policy or by law). The real point is that SNMP shouldn't need to know about multiple securityLevels - design TLSTM to assume one securityLevel per address pair, and let the operator choose how to deploy the underlying security - they are the people who best understand the demands of their TLS environment. Moving that knowledge into SNMP adds unnecessary complexity to VACM configuration, and to TARGET-MIB configuration, and so on. We do not need this complexity in SNMP, because we are "outsourcing" security configuration to the underlying TLS layer. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, January 12, 2010 2:53 AM > To: Robert Story > Cc: isms@ietf.org > Subject: Re: [Isms] multiple security levels in the dtls > transport model > > On Tue, Jan 12, 2010 at 12:50:12AM +0100, Robert Story wrote: > > > I'm sure there was some debate on the issue then. Maybe someone who > > took part in that debate could summarize the issue? > > As far as I recall, the decision was to resist the temptation to peek > inside the internals of the security protocol, that is the negotiation > of the crypto algorithms. So it was more an architectural and layering > decision. People commonly associate authentication and encryption with > SSH (even though SSH has NULL algorithms). The same might be true for > (D)TLS. > > > I haven't had the time to participate in IETF work recently, so I > > missed the opportunity to participate in the SSH decision, but I'll > > throw in my 2 bits on the issue now. > > > > - RFC 3411 says "it is explicitly allowed to send messages > which do not > > require authentication or privacy." I think there should > be a very good > > reason for a security model to limit applications/users further. > > The SNMP application can send noAuthNoPriv messages but the transport > ships them via an authPriv "tunnel". The WG concluded that providing a > higher level of security on the wire than what was requested by the > SNMP application is acceptable. > > > - customers with secure and/or private networks don't want > the overhead > > of encryption on simple traffic monitoring packets. This is most > > likely why noAuthNoPriv was created in the first place. > > Note that the performance equation looks slightly different with > (D)TLS and SSH. The big performance hit is session key generation - so > the first thing you have to worry about is to avoid unnecessary > session key generation. But yes, encryption has some price. > > > JS> Can you give me an example for something you consider > an authNoPriv > > JS> setting for (D)TLS? I understand the SNMP side of > things, not so much > > JS> the (D)TLS side of creating something that maps authNoPriv. > > > > I took a quick peek at 5246, and was disappointed to find that they > > define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit > > negotiating it (it is only used at start of session, before > real suite > > is negotiated). So noAuthNoPriv is out. > > > > That leaves authNoPriv as the next best choice. The cipher suites > > section (A.5) of 5246 defines 3 suites without encryption: > > TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and > > TLS_RSA_WITH_NULL_SHA256. > > Thanks, this is what I was looking for. > > > JS> > Note that the document already allows an > implementation to ignore this > > JS> > whole issue since it says: > > JS> > > > JS> > Implementations MAY choose to force (D)TLS to only allow > > JS> > cipher_suites that provide both authentication and > privacy to > > JS> > guarantee this assertion. > > > > I think this offers a good compromise. > > There was a concern raised during WG last call that the support for > different security levels adds complexity to the EoP. The WG needs to > come to a conclusion whether this additional complexity is well > justified or not. > > I understand that at least two WG members with some implementation > background like to have the flexibility to map authNoPriv to an > appropriate (D)TLS cipher suite. I guess it is now up to those who are > concerned about the complexity to make a point why the price is too > high to support this feature by pointing to concrete parts of the ID. > Please do so as soon as possible so that we can get this issue > resolved in a timely manner. > > /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 j.schoenwaelder@jacobs-university.de Tue Jan 12 07:35: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 2408B3A6A31 for ; Tue, 12 Jan 2010 07:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.279, 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 Dhf0Z3CUcbhN for ; Tue, 12 Jan 2010 07:35: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 184273A6A2F for ; Tue, 12 Jan 2010 07:35:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 267A4C0029; Tue, 12 Jan 2010 16:35:53 +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 Ygki66On53Wu; Tue, 12 Jan 2010 16:35:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5F83C0028; Tue, 12 Jan 2010 16:35:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B660FFC849D; Tue, 12 Jan 2010 16:35:45 +0100 (CET) Date: Tue, 12 Jan 2010 16:35:45 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100112153545.GB32588@elstar.local> Mail-Followup-To: David Harrington , 'Robert Story' , "isms@ietf.org" References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072701ca9390$a849e830$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" , 'Robert Story' Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 15:35:57 -0000 On Tue, Jan 12, 2010 at 03:08:03PM +0100, David Harrington wrote: > Moving that knowledge into SNMP adds unnecessary complexity to VACM > configuration, and to TARGET-MIB configuration, and so on. We do not > need this complexity in SNMP, because we are "outsourcing" security > configuration to the underlying TLS layer. But to be fair, the complexity in VACM etc. already exists and is part of the SNMPv3 standards. I can't judge how much authNoPriv or even mixtures of authNoPriv and authPriv are used in practice and it is likely that nobody really has any reliable hard data. The question for me really is whether one can expect APIs to expose the details of ciphersuites (and thus the security level) to the applications using a secure transport. Some well known SSH implementations did not start their life as embeddable libraries, while this was a common approach for TLS implementations. So we have notable differences at least in open source implementations of SSH and TLS. (There are meanwhile decent SSH C libraries that might expose proper APIs but they came along just in recent years.) Anyway, to resolve this issue, it might help us to understand what the complexity saving is if we do not support multiple security levels in the (D)TLS document. VACM does not matter here - we need to talk about the complexity of the (D)TLS transport since this is the document we have to complete. /js (speaking as technical contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Robert.Story@cobham.com Tue Jan 12 08:07: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 5FD133A69EA for ; Tue, 12 Jan 2010 08:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 DslFv-8rxX5w for ; Tue, 12 Jan 2010 08:07:09 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EDABC3A676A for ; Tue, 12 Jan 2010 08:07:08 -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 o0CG74Of030605; Tue, 12 Jan 2010 10:07:04 -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 o0CG74uX017173; Tue, 12 Jan 2010 10:07:04 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 11:07:04 -0500 Date: Tue, 12 Jan 2010 11:06:59 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100112110659.50dd5a24@sparta.com> In-Reply-To: <20100112075231.GA31341@elstar.local> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Tl0kkyjH5rgsEmC=OYZ6LNo"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 12 Jan 2010 16:07:04.0447 (UTC) FILETIME=[483D38F0:01CA93A1] Cc: "isms@ietf.org" Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 16:07:10 -0000 --Sig_/Tl0kkyjH5rgsEmC=OYZ6LNo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jan 2010 08:52:31 +0100 Juergen wrote: JS> The SNMP application can send noAuthNoPriv messages but the transport JS> ships them via an authPriv "tunnel". The WG concluded that providing a JS> higher level of security on the wire than what was requested by the JS> SNMP application is acceptable. I'll agree that the inverse in unacceptable. But I think that the user should be able to configure whether or not an authNoPriv session can be created and used for authNoPriv messages. JS> Note that the performance equation looks slightly different with JS> (D)TLS and SSH. The big performance hit is session key generation - so JS> the first thing you have to worry about is to avoid unnecessary JS> session key generation. But yes, encryption has some price. I could only find one paper [1] that compared SSL/TLS performance with and without encryption. That paper found an almost 4-fold performance gain when disabling encryption. That's a significant gain, and one that I'd like to be able to take advantage of. JS> There was a concern raised during WG last call that the support for JS> different security levels adds complexity to the EoP. The WG needs to JS> come to a conclusion whether this additional complexity is well JS> justified or not. I argue that the intent of the original SNMPv3 specs was to provide authNoPriv, and the WG needs to justify restricting this option. As far as complexity goes, I think that most implementations are already going to have to maintain a list of acceptable cipher_suites for an authPriv session (if nothing else, to exclude the NULL encryption options). All that's needed is another list of acceptable cipher_suites for an authNoPriv session. [1] http://user.informatik.uni-goettingen.de/~fu/ptls/santoshb.ps --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/Tl0kkyjH5rgsEmC=OYZ6LNo Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktMnicACgkQ7/fVLLY1mni2JgCgm3TF5YZTUOzcHUS99vrtaDAd IfEAn1VWmBF7Zi4Qp1M+UhgKt9izAf48 =UxUl -----END PGP SIGNATURE----- --Sig_/Tl0kkyjH5rgsEmC=OYZ6LNo-- From Robert.Story@cobham.com Tue Jan 12 08:07:21 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208AE3A6891 for ; Tue, 12 Jan 2010 08:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Lt7YkbUeGFlj for ; Tue, 12 Jan 2010 08:07:20 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DA5FE3A676A for ; Tue, 12 Jan 2010 08:07:19 -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 o0CG7C08030617; Tue, 12 Jan 2010 10:07:12 -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 o0CG7BKU017205; Tue, 12 Jan 2010 10:07:11 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 11:07:10 -0500 Date: Tue, 12 Jan 2010 11:07:07 -0500 From: Robert Story To: "David Harrington" Message-ID: <20100112110707.45d08c83@sparta.com> In-Reply-To: <072701ca9390$a849e830$0600a8c0@china.huawei.com> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/iKgY63.71EgIVz1PXvuFaJ8"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 12 Jan 2010 16:07:10.0994 (UTC) FILETIME=[4C243720:01CA93A1] Cc: isms@ietf.org Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 16:07:21 -0000 --Sig_/iKgY63.71EgIVz1PXvuFaJ8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jan 2010 09:08:03 -0500 David wrote: DH> The operator was DH> responsible for configuring the lower layer to provide security. And DH> since SNMP had no insight into which suites were being used, SNMP DH> could not determine whether the operator's configuration did or did DH> not provide auth and priv. The transport model had to trust that the DH> operator had configured things correctly. period. DH>=20 DH> Now this whole discussion of supporting mutliple security levels goes DH> directly against that WG consensus to not reveal the underlying DH> mechanisms or ciphersuites.=20 In what way? We aren't currently saying anything about what ciphersuites are acceptable for an authPriv connection. We don't need to get into the underlying ciphersuites, all we need to say is that an authPriv session MUST NOT use a ciphersuite that does not offer both authentication and encryption. For authNoPriv, we just need to say that an authNoPriv session MUST NOT use a ciphersuite that does not offer authentication. Note that this does not prohibit using encryption, should the user desire to configure it that way. I'd also like to point out that section 8 of 5591 says: This Security Model SHOULD always be used with Transport Models that provide adequate security, but "adequate security" is a configuration and/or run-time decision of the operator or management application. DH> If we are going to support multiple securityLevels, then I think the DH> standard should identify the mandatory-to-implement ciphersuites to DH> support each securityLevel, so we have interoperability. And that DH> begins to open a whole can of worms ... I disagree. TLS already specifies a mandatory to implement ciphersuite (TLS_RSA_WITH_AES_128_CBC_SHA), so I think all we need to say is that an implementation MUST always offer that suite as an option. That would guarantee interoperability at the cost of possibly having authNoPriv sessions encrypted. I can live with that. DH> Now we need to start thinking about how to configure the SNMP to DH> decide which traps to send over which securitylevel, and which OIDs DH> have sensitive information and which are not sensitive, and yada yada DH> yada ... Added complexity with no real benefit because people will not DH> do this level of data access control. The same holds true for SNMP with USM. there is no difference here. DH> If we do not get into discussing specific ciphersuites and algorithms, DH> then we can treat all SNMP communications over TLS as being one DH> securityLevel. The operator can configure all SNMP/(D)TLS to work DH> using one assumed securityLevel. Honestly it doesn't matter much which DH> securitylevel is supported, although we should make strong security DH> (authpriv) mandatory-to-implement, I agree that authPriv should be mandatory-to-implement. I don't agree that it should be mandatory to use for all sessions. DH> If the operator wants to deploy a TLS configuration that only DH> provides authNoPriv, then that is a deployment decision. I don't agree with that. As I said earlier, I think we should require that implementations not allow non-encrypted ciphersuites for authPriv sessions. DH> If the operator wants to deploy DH> their TLS environment to provide one level of security from node A to DH> node B, and have a different level of security between nodes A and C, DH> then they can do so by configuring the TLS-layer negotiations to use DH> specific suites (in an implementation-dependent manner). agreed. DH> The real point is that SNMP shouldn't need to know about DH> multiple securityLevels SNMPv3 specifies multiple securityLevel, so I don't see how you can make that statement. DH> design TLSTM to assume one securityLevel per DH> address pair, and let the operator choose how to deploy the underlying DH> security - they are the people who best understand the demands of DH> their TLS environment. I agree that they best understand their environment. I disagree that single level of security per address pair will provide them with the flexibility that they want. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/iKgY63.71EgIVz1PXvuFaJ8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktMni4ACgkQ7/fVLLY1mng/ogCgg81y0wvrHrHDnw0bX2VEj1YS a4MAniy50Ys3lcH54ujBJGWKITJjCh90 =djd6 -----END PGP SIGNATURE----- --Sig_/iKgY63.71EgIVz1PXvuFaJ8-- From Robert.Story@cobham.com Tue Jan 12 08: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 7740C3A68BC for ; Tue, 12 Jan 2010 08:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ath9HXi0pc8A for ; Tue, 12 Jan 2010 08:18:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 836053A6870 for ; Tue, 12 Jan 2010 08:18:45 -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 o0CGIfAO030888; Tue, 12 Jan 2010 10:18:41 -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 o0CGIgmo018026; Tue, 12 Jan 2010 10:18:42 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 11:18:41 -0500 Date: Tue, 12 Jan 2010 11:18:37 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100112111837.5eb88783@sparta.com> In-Reply-To: <20100112153545.GB32588@elstar.local> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> <20100112153545.GB32588@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/wx7B2bZmco+6XeYL99R_3In"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 12 Jan 2010 16:18:41.0920 (UTC) FILETIME=[E7F72800:01CA93A2] Cc: "isms@ietf.org" Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 16:18:46 -0000 --Sig_/wx7B2bZmco+6XeYL99R_3In Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 12 Jan 2010 16:35:45 +0100 Juergen wrote: JS> The question for me really is whether one can expect APIs to expose JS> the details of ciphersuites (and thus the security level) to the JS> applications using a secure transport. Isn't that putting the cart before the horse? We shouldn't be designing to existing APIs. We should be designing what we want, and the APIs should follow. Having said that: =E2=80=94 Function: int gnutls_priority_set (gnutls_session_t session, gnutls_priority_t priority) session: is a gnutls_session_t structure. priority: is a gnutls_priority_t structure. Sets the priorities to use on the ciphers, key exchange methods, macs and compression methods.=20 - int SSL_set_cipher_list(SSL *ssl, const char *str); DESCRIPTION SSL_CTX_set_cipher_list() sets the list of available ciphers for ctx using the control string str. So, yes, APIs exist that allow the application to specify ciphersuites. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/wx7B2bZmco+6XeYL99R_3In Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktMoOEACgkQ7/fVLLY1mnj+SQCfRTEkc4tQQ5i6Tj2XDUUid5Ta UjcAn300uxyf5bu5gpTXSP8vD29vvyty =0K21 -----END PGP SIGNATURE----- --Sig_/wx7B2bZmco+6XeYL99R_3In-- From ietfdbh@comcast.net Tue Jan 12 08:25:21 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50AB3A67FC for ; Tue, 12 Jan 2010 08:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlEuu3jHvoAe for ; Tue, 12 Jan 2010 08:25:21 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id BEE973A6804 for ; Tue, 12 Jan 2010 08:25:20 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta12.westchester.pa.mail.comcast.net with comcast id UdQi1d00C1GhbT85CgRKvd; Tue, 12 Jan 2010 16:25:19 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta07.westchester.pa.mail.comcast.net with comcast id UgRJ1d00X284sdk3TgRK9q; Tue, 12 Jan 2010 16:25:19 +0000 From: "David Harrington" To: Date: Tue, 12 Jan 2010 11:25:17 -0500 Message-ID: <074501ca93a3$d43054d0$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: AcqTo9PVWdiWkrPoSxG9lXbEGzCkGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] multiple securityLevels 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, 12 Jan 2010 16:25:21 -0000 Hi, I am unlikely to ever implement snmp/dtls, so if Robert and Wes feel support for multiple securitylevels is really needed, let it happen. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From j.schoenwaelder@jacobs-university.de Tue Jan 12 08:44:02 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391AF3A6A50 for ; Tue, 12 Jan 2010 08:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.265, 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 IcpiKDzcLqSB for ; Tue, 12 Jan 2010 08:44:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 276063A6A46 for ; Tue, 12 Jan 2010 08:44:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED854C0028; Tue, 12 Jan 2010 17:43:58 +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 fBOU+hLzxuAh; Tue, 12 Jan 2010 17:43:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A85CEC002A; Tue, 12 Jan 2010 17:43:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2BA6FC8A5D; Tue, 12 Jan 2010 17:43:21 +0100 (CET) Date: Tue, 12 Jan 2010 17:43:21 +0100 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100112164321.GA33412@elstar.local> Mail-Followup-To: Robert Story , David Harrington , "isms@ietf.org" References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> <20100112153545.GB32588@elstar.local> <20100112111837.5eb88783@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100112111837.5eb88783@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 16:44:02 -0000 On Tue, Jan 12, 2010 at 05:18:37PM +0100, Robert Story wrote: > Isn't that putting the cart before the horse? We shouldn't be designing > to existing APIs. We should be designing what we want, and the APIs > should follow. Yes, but then designing something that can't be implemented easily is also not a good recipe for success. Perhaps we even have to revise the SSH TM decision once there is more implementation experience and we know that authNoPriv can be reasonably supported with SSH libraries and there is a demand for this. In the case of (D)TLS, the libraries allowing authNoPriv support are available and some WG members seem to have demand for this feature. /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 Tue Jan 12 08:45:59 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 7A8013A6A55 for ; Tue, 12 Jan 2010 08:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.253, 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 nUKPHEHIMgf7 for ; Tue, 12 Jan 2010 08:45:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A774C3A6A50 for ; Tue, 12 Jan 2010 08:45:58 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1632DC002A; Tue, 12 Jan 2010 17:45:56 +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 QtmVm9bORLXo; Tue, 12 Jan 2010 17:45:55 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12E99C0028; Tue, 12 Jan 2010 17:45:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 233D7FC8AC7; Tue, 12 Jan 2010 17:45:49 +0100 (CET) Date: Tue, 12 Jan 2010 17:45:49 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100112164549.GB33412@elstar.local> Mail-Followup-To: David Harrington , "isms@ietf.org" References: <074501ca93a3$d43054d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <074501ca93a3$d43054d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] multiple securityLevels 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, 12 Jan 2010 16:45:59 -0000 On Tue, Jan 12, 2010 at 05:25:17PM +0100, David Harrington wrote: > I am unlikely to ever implement snmp/dtls, so if Robert and Wes feel > support for multiple securitylevels is really needed, let it happen. Unless there are any other opinions and arguments, I assume we will continue with what we have in the current ID and leave the support for multiple securityLevels in. /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 Tue Jan 12 11:55: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 0FA873A68AE for ; Tue, 12 Jan 2010 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC8ivtX0w5Fh for ; Tue, 12 Jan 2010 11:55:46 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 255BC3A68DA for ; Tue, 12 Jan 2010 11:55:43 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o0CJtZZE012343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 14:55:35 -0500 (EST) Date: Tue, 12 Jan 2010 14:55:35 -0500 From: Jeffrey Hutzelman To: David Harrington , "'Juergen Schoenwaelder'" , "'Robert Story'" Message-ID: <5C6DD01E22AD22FB4A39B8A9@minbar.fac.cs.cmu.edu> In-Reply-To: <22227_1263305290_o0CE88hD015012_072701ca9390$a849e830$0600a8c0@china.huawei.com> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <22227_1263305290_o0CE88hD015012_072701ca9390$a849e830$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 19:55:47 -0000 --On Tuesday, January 12, 2010 09:08:03 AM -0500 David Harrington wrote: > Now this whole discussion of supporting mutliple security levels goes > directly against that WG consensus to not reveal the underlying > mechanisms or ciphersuites. Oh, I think we could reasonably come to a consensus that the right thing for (D)TLS is different from the right thing for SSH. But I don't think we should; the same principles are at work, and should result in the same answer -- the TM has no business peeking below the abstraction layer, and that means not knowing or caring what ciphersuites have what properties. Thus, we should simply treat all (D)TLS sessions as AuthPriv and mandate that TLS be configured so as to insure this is the case. > If we are going to support multiple securityLevels, then I think the > standard should identify the mandatory-to-implement ciphersuites to > support each securityLevel, so we have interoperability. Yes, though I think we could reasonably defer that question to TLS itself, which already has mandatory-to-implement ciphersuites, and further say (as we already have) that it is OK for a secure transport to provide better security than the application asked for. > Now we need to start thinking about how to configure the SNMP to > decide which traps to send over which securitylevel, and which OIDs > have sensitive information and which are not sensitive, and yada yada > yada ... Added complexity with no real benefit because people will not > do this level of data access control. _That_ is not in any way unique to our work; it would apply just as well to USM. I propose that we treat such questions as out of scope, at least for now, and possibly indefinitely. So, my position is that there is little benefit to supporting multiple securityLevels in TLSTM. From jhutz@cmu.edu Tue Jan 12 12:05:34 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21013A6912 for ; Tue, 12 Jan 2010 12:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Np2QLVxRc5 for ; Tue, 12 Jan 2010 12:05:33 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 146D13A6863 for ; Tue, 12 Jan 2010 12:05:33 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o0CK5Rrn026220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 15:05:28 -0500 (EST) Date: Tue, 12 Jan 2010 15:05:27 -0500 From: Jeffrey Hutzelman To: Robert Story , Juergen Schoenwaelder Message-ID: <0FE85F6F1B348AEE1B2EAB64@minbar.fac.cs.cmu.edu> In-Reply-To: <2865_1263313127_o0CGIkxq013690_20100112111837.5eb88783@sparta.com> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> <20100112153545.GB32588@elstar.local> <2865_1263313127_o0CGIkxq013690_20100112111837.5eb88783@sparta.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 20:05:34 -0000 --On Tuesday, January 12, 2010 11:18:37 AM -0500 Robert Story wrote: > On Tue, 12 Jan 2010 16:35:45 +0100 Juergen wrote: > JS> The question for me really is whether one can expect APIs to expose > JS> the details of ciphersuites (and thus the security level) to the > JS> applications using a secure transport. > > Isn't that putting the cart before the horse? We shouldn't be designing > to existing APIs. We should be designing what we want, and the APIs > should follow. True, to an extent. However, what we _should_ be talking about is not API's, but the abstraction that TLS intends to export to the layer above. If we need something that is part of the abstraction, but nothing implements it, then we can decide whether it is worthwhile to require people to implement more of TLS in order to use TLSTM. But if what we want is _not_ part of the abstraction, then we should not be using it, regardless of whether it happens to be exposed anyway by some APIs. I argue that ciphersuite selection, and the question of what ciphersuites are available and what properties they have, is below the abstraction. To decide whether a particular TLS session is suitable for a given security level, TLSTM would not only need to know what ciphersuite is in use; it would have to have some means of deciding whether that ciphersuite is suitable for a specified secuirty level. When trying to establish a new session known to be suitable for a given securityLevel, the situation is even worse. That kind of knowledge badly violates the abstraction, and is impractical to boot. I keep using the word "abstraction", but not just because it sounds cool. Abstractions and the modularity they imply are _essential_ to keeping security analysis of our protocols manageable. -- Jeff From randy_presuhn@mindspring.com Tue Jan 12 12:26: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 9E3DA3A6890 for ; Tue, 12 Jan 2010 12:26: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 h+XKKAxTW0pM for ; Tue, 12 Jan 2010 12:26:43 -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 A1A643A6842 for ; Tue, 12 Jan 2010 12:26:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=shYvDtS8zvyEejIW+XHVPNaNbJQDA+RR3pMSHBcxemVj+0yq5sFZoTjgsO5okfif; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.55.57] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NUnK4-0005sn-Oi for isms@ietf.org; Tue, 12 Jan 2010 15:26:41 -0500 Message-ID: <000801ca93c5$fc5d6520$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local><20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local><072701ca9390$a849e830$0600a8c0@china.huawei.com><20100112153545.GB32588@elstar.local><2865_1263313127_o0CGIkxq013690_20100112111837.5eb88783@sparta.com> <0FE85F6F1B348AEE1B2EAB64@minbar.fac.cs.cmu.edu> Date: Tue, 12 Jan 2010 12:29:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4092f5eac3863f03edf4653b4b72d15214350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.57 Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 20:26:44 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Robert Story" ; "Juergen Schoenwaelder" > Cc: ; > Sent: Tuesday, January 12, 2010 12:05 PM > Subject: Re: [Isms] multiple security levels in the dtls transport model ... > I argue that ciphersuite selection, and the question of what ciphersuites > are available and what properties they have, is below the abstraction. To > decide whether a particular TLS session is suitable for a given security > level, TLSTM would not only need to know what ciphersuite is in use; it > would have to have some means of deciding whether that ciphersuite is > suitable for a specified secuirty level. No. The "level of security" is a service user / service provider interface abstraction . It does *not* require that the service user (SNMP) know what ciphersuites are available. It merely requires the service provider (TLS implementation) be able to honor a request to carry information at a given level of security (or better) using whatever ciphersuites it chooses, and, in the case of incoming information, to be able to inform the service user what level of security had been given to the arriving information. This sort of requirement is not peculiar to SNMP. > When trying to establish a new > session known to be suitable for a given securityLevel, the situation is > even worse. That kind of knowledge badly violates the abstraction, and is > impractical to boot. On the contrary, the need to be able specify whether information needs no particular protection, requires authentication, or requires confidentiality is a requirement that would be imposed by almost any application I can think of that would need the services of a security protocol. This does not entail requiring the service interface to expose details of ciphersuite selection. > I keep using the word "abstraction", but not just because it sounds cool. > Abstractions and the modularity they imply are _essential_ to keeping > security analysis of our protocols manageable. And an essential part of the abstract service interface provided by a security layer is an abstract (e.g. at the granuality of "AuthNoPriv" rather than "SHA/HMAC") characterization of the service provided. Randy From Robert.Story@cobham.com Tue Jan 12 12:51: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 A473E3A68C9 for ; Tue, 12 Jan 2010 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 1hEnJXMLSi39 for ; Tue, 12 Jan 2010 12:51:57 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9950C3A6911 for ; Tue, 12 Jan 2010 12:51:57 -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 o0CKpqvS003885; Tue, 12 Jan 2010 14:51:52 -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 o0CKpq3o000890; Tue, 12 Jan 2010 14:51:53 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 15:51:51 -0500 Date: Tue, 12 Jan 2010 15:51:46 -0500 From: Robert Story To: Jeffrey Hutzelman Message-ID: <20100112155146.68b465bc@sparta.com> In-Reply-To: <5C6DD01E22AD22FB4A39B8A9@minbar.fac.cs.cmu.edu> References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <22227_1263305290_o0CE88hD015012_072701ca9390$a849e830$0600a8c0@china.huawei.com> <5C6DD01E22AD22FB4A39B8A9@minbar.fac.cs.cmu.edu> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/PAKTnVYYMCcvZUqeDauY/jD"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 12 Jan 2010 20:51:51.0771 (UTC) FILETIME=[1113F2B0:01CA93C9] Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 20:51:58 -0000 --Sig_/PAKTnVYYMCcvZUqeDauY/jD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jan 2010 14:55:35 -0500 Jeffrey wrote: JH> [...] the TM has no business peeking below the abstraction layer, and=20 JH> that means not knowing or caring what ciphersuites have what properties= .=20 agreed JH> Thus, we should simply treat all (D)TLS sessions as AuthPriv but I don't see how that follows. JH> and mandate that TLS be configured so as to insure this is the case. As David said, we have to trust that an app/implementation actually follows this mandate. If we can trust them to do this for authPriv, I don't see why we can't also trust them to do it for authNoPriv. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/PAKTnVYYMCcvZUqeDauY/jD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktM4OYACgkQ7/fVLLY1mnjxJQCggVBuFS+6/JdQNxSLmo7u4uKM ZwMAoJdsP6eaDOkj4V8pgP14B/Llxu7M =msnF -----END PGP SIGNATURE----- --Sig_/PAKTnVYYMCcvZUqeDauY/jD-- From wjhns1@hardakers.net Tue Jan 12 12:57: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 E312D3A6840 for ; Tue, 12 Jan 2010 12:57: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 gs-opKrbzJi3 for ; Tue, 12 Jan 2010 12:57:13 -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 65BF53A681A for ; Tue, 12 Jan 2010 12:57:13 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 7041C98064; Tue, 12 Jan 2010 12:57:10 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20100111080938.GB27502@elstar.local> <20100111192524.GC30199@elstar.local> <20100111185012.42da15af@sparta.com> <20100112075231.GA31341@elstar.local> <072701ca9390$a849e830$0600a8c0@china.huawei.com> <20100112153545.GB32588@elstar.local> <2865_1263313127_o0CGIkxq013690_20100112111837.5eb88783@sparta.com> <0FE85F6F1B348AEE1B2EAB64@minbar.fac.cs.cmu.edu> Date: Tue, 12 Jan 2010 12:57:09 -0800 In-Reply-To: <0FE85F6F1B348AEE1B2EAB64@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 12 Jan 2010 15:05:27 -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, Robert Story Subject: Re: [Isms] multiple security levels in the dtls transport model 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, 12 Jan 2010 20:57:15 -0000 [this is somewhat responding to multiple threads... It's somewhat more coherent together and I won't repost under each thread though.] >>>>> On Tue, 12 Jan 2010 15:05:27 -0500, Jeffrey Hutzelman said: JH> I argue that ciphersuite selection, and the question of what JH> ciphersuites are available and what properties they have, is below the JH> abstraction. I agree. In particular, I don't think we should define what is and what is not an appropriate level of privacy protection or appropriate level of authentication. What we can say, and what the document does say, is that you must use at least *a* form of authentication to pass traffic with the Auth bit set. And you must use *a* form of privacy to pass traffic with the Priv bit set. IE, you MUST NOT use NULL. That's all it says in terms of how you protect the traffic being sent by the application. It does not say that "1DES sucks and you shouldn't use it", because that's best left to local policy choices. We state that local policy/configuration decisions may affect which algorithms are selected or are acceptable. This does *not* introduce any new failure cases that aren't already present in TLS negotiations today. It's *already* possible that a SNMP/DTLS server may reject a client because they couldn't agree on algorithms. It's *already* possible that an SSH establishment would fail for the same reasons. The real question is, in my mind, should we allow a product to offer two forms of protection of different levels (authNoPriv and authPriv). We allow this for SNMPv3 because we thought it was important. I fail to buy the argument "use USM if you want authNoPriv at different cryptography". The whole reason we're using TLS instead of USM is because people don't want to use USM. No where have people said "we don't need authNoPriv". In fact, I know of a lot of users that are using it (maybe because they're clueless, I don't know, but I do know they're using it). I fail to see the purpose of putting in wording that actually *restricts* an application from offering different levels of service (authNoPriv and authPriv) to mean different things. We *already* have text that lets an implementation bail out and *not* offer tunnels without both authentication and encryption. IE, the current text says: 1) if you don't want the bit-checking complexity in your code, only offer TLS algorithms with at least minimal auth/priv protection mechanisms. 2) if you want to offer different levels of service you can. As far as checking on the client side we already know it's possible for most TLS suites out there (and I agree; it wasn't for SSH at the time 5592 was written). Go to firefox, open a https session to your local bank and click on the lock icon. It'll tell you exactly what method of protection you're being protected with. This *is* exposed to TLS clients today. I think the current document strikes a perfect balance: it allows implementations to be picky and protective if they want, and it allows implementations not to. We're not diving into "this security method is better than that one". I don't think we're violating layering either. SNMPv3/USM has strong knowledge of crypto algorithms. TSM doesn't, and nothing in the current document says it needs to. The TLSTM layer must be able to at least impose minimal (non-NULL) selections, which we know existing TLS layers allow for (in fact, OpenSSL's selection APIs are much more complex than we need). Is it different than the SSH solution? Yes. Should it have to be the same? No! I realize that "we already discussed that for another protocol" is one argument you could make. But we could have also made the argument that "we already have a secure protocol and don't need another one" is an approach we could have used to say "we don't need DTLS", but the WG decided to adopt the TLS work. It's also an approach we could have used to throw out SSHTM too, but again we decided that we needed something else. What's the harm in keeping multiple security levels in the document? 1) People have said "complexity"; for them: don't implement it and only offer secure transports. Problem solved. 2) Layer violations: I've explained again that I don't buy that argument based on how existing TLS applications work. Again, only offer secure transports and the problem solved. You don't have to expose the connection details beyond the TLSTM. At least we're getting good discussion out of this topic :-) Is that a good thing or a bad thing? -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jan 12 13:03: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 499463A6833 for ; Tue, 12 Jan 2010 13:03: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 kME8DnoyPe1c for ; Tue, 12 Jan 2010 13:03:25 -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 619EB3A681A for ; Tue, 12 Jan 2010 13:03:25 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id AD0BE98046; Tue, 12 Jan 2010 13:03:22 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <074501ca93a3$d43054d0$0600a8c0@china.huawei.com> Date: Tue, 12 Jan 2010 13:03:22 -0800 In-Reply-To: <074501ca93a3$d43054d0$0600a8c0@china.huawei.com> (David Harrington's message of "Tue, 12 Jan 2010 11:25:17 -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] Ismsmultiple securityLevels 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, 12 Jan 2010 21:03:26 -0000 >>>>> On Tue, 12 Jan 2010 11:25:17 -0500, "David Harrington" said: DH> I am unlikely to ever implement snmp/dtls, so if Robert and Wes feel DH> support for multiple securitylevels is really needed, let it happen. FYI, I actually have plans to implement it. Half the problem is that the text that people want to have inserted (everything is considered authPriv) actually *prevents* me from implementing and conforming to the standard. -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Wed Jan 13 01:53: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 B7F2E3A6AA2 for ; Wed, 13 Jan 2010 01:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=-2.308, BAYES_50=0.001, SUBJ_ALL_CAPS=2.077] 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 4KluI2PNzT2A for ; Wed, 13 Jan 2010 01:53:07 -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 D7D803A6407 for ; Wed, 13 Jan 2010 01:53:06 -0800 (PST) X-Trace: 283714028/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 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: ApIFABEnTUs+vGRy/2dsb2JhbACCUYVXiHCLMLh2CoQmBA X-IronPort-AV: E=Sophos;i="4.49,267,1262563200"; d="scan'208";a="283714028" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Jan 2010 09:52:50 +0000 Message-ID: <001501ca942d$d20a25c0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> <20100107072954.GA38654@elstar.local> Date: Wed, 13 Jan 2010 09:49:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: [Isms] TLSTM -05 TLS 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: Wed, 13 Jan 2010 09:53:07 -0000 Juergen I think that this, like its predecessors, deserves a wider review for what it says about TLS. Now that the storm on the TLS list has died down, I would suggest asking them to review it. I am concerned that what it says about TLS is not quite right, especially with the focus of this I-D on authentication. IMO, what it says is not good, but may be it is good enough; I am unsure. I do not want details of what goes on under the covers of TLS but do want a fair representation of what TLS does and does not offer. Tom Petch From cfinss@dial.pipex.com Wed Jan 13 01:53:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0C53A6407 for ; Wed, 13 Jan 2010 01:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 BeySckZteQcH for ; Wed, 13 Jan 2010 01:53:07 -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 7EE733A68B2 for ; Wed, 13 Jan 2010 01:53:07 -0800 (PST) X-Trace: 283714101/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 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: AlMFABEnTUs+vGRy/2dsb2JhbACCUYVXiHDEJgqCIYIFBA X-IronPort-AV: E=Sophos;i="4.49,267,1262563200"; d="scan'208";a="283714101" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Jan 2010 09:53:02 +0000 Message-ID: <001601ca942d$d3384580$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> <20100107072954.GA38654@elstar.local> Date: Wed, 13 Jan 2010 09:51:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: [Isms] TLSTM -05 bits of MIB module 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: Wed, 13 Jan 2010 09:53:08 -0000 Juergen Comments by Jeff and Joe prompted me to look into fingerprints which in turn forced me to read parts of the MIB module. This is what I found from the bits of the MIB module I looked at - if I looked at more, I suspect that I would find more. 1) tlstmCertSpecified OBJECT-IDENTITY ... /value or contains/value or contain/ 2) tlstmCertSANRFC822Name /FooBar@exmaple.com/FooBar@example.com/ 3a) tlstmCertSANAny dNSName presumably uses the capitalisation of RFC5280 in which case it should be 'iPAddress' and presumably tlstmCertSANIPAddress, here and in other places. 3b) I agree with Jeff's comment in December that this could be better named. 4) snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE "I.E., a cryptographic validation occurred during certificate validation processing." This seems to be telling me that cryptographic validation occurred during cryptographic validation:-) 5a) tlstmCertToTSNTable OBJECT-TYPE "A table listing the X.509 certificates known to the entity..." Not really, it list fingerprints, which is not the only way they could be listed; suggest "A table listing the fingerprints of X.509 certificates known to the entity" 5b)"public certificate (e.g. RFC5280). " This seems a bit bald. Is it a reference? if so make it one, give it a clause. And why EG; what other examples had the author in mind? 5c) "Subject field but usage of the CommonName field is deprecated." This sounds to me like a SHOULD NOT. 6) tlstmCertToTSNID OBJECT-TYPE "A unique, prioritized index for the given entry." How are they prioritized, what represents high and what low priority? I am sure that some people will come to the opposite view to that of the author. 7) tlstmCertToTSNData OBJECT-TYPE "Axillary " Has our object tree sprouted axils? 8) -- Lists expected certificate fingerprints to be presented by a DTLS -- server Why DTLS and not (D)TLS? I was going to say client not server, since this immediately follows the client table but then I realised that this relates to three objects hence. If it is going to say 'Lists expected certificate fingerprints ' then I think that it should immediately precede tlstmAddrTable not be separated by two other objects. 9) tlstmAddrTable /columnshould/column should/ 10) tlstmAddrServerIdentity OBJECT-TYPE This references draft-saintandre-tls-server-id-check which goes into detail about the use of asterisk and about which fields to use, but then includes text about asterisks with nothing about fields. This is potentially contradictory and ambiguous. Are you saying anything in draft-saintandre-tls-server-id-check goes, are you saying that draft-saintandre-tls-server-id-check applies unless overridden by the description clause or what? Given that draft-saintandre-tls-server-id-check is still under discussion and yet to be finalised, this issue needs more attention. Tom Petch From dave.shield@googlemail.com Wed Jan 13 03:12:31 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B733A6AD6 for ; Wed, 13 Jan 2010 03:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 7c4S08+eE-5A for ; Wed, 13 Jan 2010 03:12:30 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id C71E03A6AD3 for ; Wed, 13 Jan 2010 03:12:29 -0800 (PST) Received: by fxm5 with SMTP id 5so1644510fxm.29 for ; Wed, 13 Jan 2010 03:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=t3ukRIWHER9g9pwruiEX/jDbBC6KR+UuIA2LTRi2IIk=; b=AiH6PDX1ZslYV45x143mIQ8ZH/j4fjXAcYUBrPm79iP2Dgl+5knLcqWNAUvSiLRfp6 QC2R6X7hk4CObgRFaLkKCKatWwpJZKPSGV+oyKOlbFbIpW14qTlLfzfUm64fLEabDITJ D9AkcF8Z3uznIHCqElXopXNQhpgNVHdwEFPOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=h6ovd4l0LyKYs6rouNEx9LtdTY6+IEwd+EeaEdvd456r0VlTNek9QsI49r4V6w7cME t4pP39wQd6Oohz8fJakx58Zc1ZMmOXpcbEAWZf6T2Q+M9t8bkyRvgfpbOi2m+7JPmpZr RUqx+8wfwgXAuyUDphA/KbRqyrO2vF3m5Wzk8= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.223.161.215 with SMTP id s23mr3418711fax.44.1263381144001; Wed, 13 Jan 2010 03:12:24 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Jan 2010 11:12:23 +0000 X-Google-Sender-Auth: d24f224c8bb6a653 Message-ID: From: Dave Shield To: Wes Hardaker Content-Type: text/plain; charset=ISO-8859-1 Cc: isms@ietf.org Subject: Re: [Isms] TLSTM draft -05 published 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, 13 Jan 2010 11:12:31 -0000 2010/1/8 Wes Hardaker : > I've published a -05 copy of the draft I still need to catch up with the most recent discussions, but the following comments from earlier versions still seem to be relevant to the 05 draft. Mostly wordsmithing for clarity, or typos. Feel free to adopt/ignore as you wish. Dave 3.1.1 Step 3, para 2 s/sequencing ability/sequencing ability,/ s/sequence number for/sequence number used for/ 3.1.2 para 2 s/through the cache, the application/it also/ 3.3 para 3 The bulk of this paragraph seems to be discussing how to populate the target-related MIB tables, when used with a DTLS transport destination. All except the last sentence, which is more concerned with access control. Suggestion: Insert a new paragraph break before "The securityName defined ...." 4.1.1 para 1 s/through a trusted out of band mechanism into the server/ into the server through a trusted out of band mechanism,/ s/its authenticity/their authenticity/ 4.1.1 para 2, bullets s/type and value/value/ Given that the name-based mapping is the preferred approach, (as indicated immediately following), might it be worth switching the order of these two bullet items? 4.1.1 para 6 s/by the security model. A security model, like the TSM security model [RFC5591], may perform/ by a security model, such as the TSM security model [RFC5591]. This security model may perform/ 4.1.1 diagram Most of the elements in this diagram are modules from the (transport-extended) SNMPv3 architecture. However 'tmSecurityName' and 'securityName' are values passed (via the cache) from one module to another. Might it be useful to distinguish these different cases within the diagram. E.g. by omitting the boxes: +-------+ tmSecurityName +-----+ | TLSTM | -------------------> | TSM | +-------+ +-----+ 4.3.1 statusInformation s/passing of the message/sending of the message/ destTransportDomain s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/ outgoingMessage s/send to (D)TLS for encapsulation/ pass to (D)TLS for encapsulation and transmission/ 4.3.2 transportDomain s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/ incomingMessage s/removed of/removal of/ 5 para 2 s/first prior/prior/ 5.1 Suggested text: This section describes the procedures followed by the (D)TLS Transport Model when it receives a (D)TLS protected packet. The required functionality is broken into two different sections. Section 5.1.1 described the processing required for de-multiplexing multiple DTLS sessions, which is specifically needed for DTLS over UDP sessions. It is assumed that TLS and DTLS/SCP protocol implementations already provide appropriate message demultiplexing. Section 5.1.2 describes the transport processing required once the (D)TLS processing has been completed. This will be needed for all (D)TLS-based sessions. 5.1.1 para 1 s/always critical/critical/ s/implementations be able/implementations are always able/ 5.1.1 para 2 s/wholeMessage/incomingMessage/ s/wholeMessageLength/incomingMessageLength/ [as per RFC 5590] 5.1.1 step 2, para 1 s/ and its tlsSnmpSessionID// [The session ID is retrieved in step 3] 5.1.1 step 2, para 3 s/both above and in Section 5.3/in Section 5.3/ 5.1.1 step 5 s/in the Section 5.1.2/in Section 5.1.2/ 5.1.2 Is it worth numbering these processing steps? E.g. 1) Create a tmStateReference .... 2) The wholeMessage and the wholeMessageLength .... 3) The TLS Transport Model .... 5.1.2 step 2 The incomingMessage and incomingMessageLength are assigned values from the (D)TLS processing. 5.1.2 step 3 s/wholeMessage/incomingMessage/ s/wholeMessageLength/incomingMessageLength/ [as per RFC 5590] 6.2 bullet 1 s/New TransportDomain and TransportAddress formats/ A new TransportAddress format/ [The TransportDomains are objects, not TCs] 7 tlstmCertSpecified a/the mapping will be considered a failure/ , and an alternative mapping looked for/ 7 tlstmCertSANRFC822Name s/exmaple/example/ Should this description mention the 32-character limit for security names, and describe what should happen if the RFC822 name is longer than this? [The required behaviour is covered in the descriptions of tlstmCertToTSNTable and tlstmCertToSNMapType, but it might be worth mentioning it here too.] 7 tlstmCertSANDNSName 7 tlstmCertCommonName Again, should these descriptions touch on the 32-character limit? [e.g. using similar wording to tlstmCertSpecified) 7 tlstmCertToTSNTable, para 4, step 2 s/CA certificated/CA certificate/ From cfinss@dial.pipex.com Wed Jan 13 04:43: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 4D6BB3A67D8 for ; Wed, 13 Jan 2010 04:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 2Hyz3A62aeVf for ; Wed, 13 Jan 2010 04:43:32 -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 5B95D3A67BE for ; Wed, 13 Jan 2010 04:43:32 -0800 (PST) X-Trace: 229502672/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.88/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.88 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: AlMFAKNOTUs+vBNY/2dsb2JhbACCUYVXiHHFGAqCIYIFBA X-IronPort-AV: E=Sophos;i="4.49,268,1262563200"; d="scan'208";a="229502672" X-IP-Direction: IN Received: from 1cust88.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.88]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Jan 2010 12:43:26 +0000 Message-ID: <006301ca9445$a0fefc40$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" Date: Wed, 13 Jan 2010 12:41:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: [Isms] TLSTM -05 More bits of MIB module 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: Wed, 13 Jan 2010 12:43:33 -0000 I find the processing of server certificates by clients unclear when a connection is being established as a result of the SNMP-TARGET-MIB module. 5.3 3 b talks of server identity being configured or not configured, the DESCRIPTION clause talks of matching but does not say what is being matched. If a row has fingerprint and no server identity, can this produce a match? The DESCRIPTION clause says "This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS server-side certificate identifier to .." no mention of the server identity there implying that a match can take place on the certificate identifier ie the fingerprint. If not, then I think the text needs clarifying as to just what is being checked. And, what if the table produces multiple matches? *.server.example.com and *.example.com or perhaps multiple SANs of different types. As Joe has pointed out, there are differences for which the reasons are unclear between the server's processing of a client certificate and the client's processing of a server's certificate. Tom Petch From wjhns1@hardakers.net Wed Jan 13 06:56:59 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 875063A6928 for ; Wed, 13 Jan 2010 06:56:59 -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 MtWI+sEdumtV for ; Wed, 13 Jan 2010 06:56:58 -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 A74C63A6824 for ; Wed, 13 Jan 2010 06:56:58 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B3D5F9808E; Wed, 13 Jan 2010 06:56:55 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> <20100107072954.GA38654@elstar.local> <001501ca942d$d20a25c0$0601a8c0@allison> Date: Wed, 13 Jan 2010 06:56:55 -0800 In-Reply-To: <001501ca942d$d20a25c0$0601a8c0@allison> (tom petch's message of "Wed, 13 Jan 2010 09:49:10 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] IsmsTLSTM -05 TLS 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, 13 Jan 2010 14:56:59 -0000 >>>>> On Wed, 13 Jan 2010 09:49:10 +0100, "tom.petch" said: tp> I think that this, like its predecessors, deserves a wider review tp> for what it says about TLS. Now that the storm on the TLS list has tp> died down, I would suggest asking them to review it. It should be noted that a TLS WG chair (Joe Salowey) reviewed it already and his comments have already been responded to. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Jan 13 06:57:54 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 34B703A698F for ; Wed, 13 Jan 2010 06:57:54 -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 x4a6PXq1jpIw for ; Wed, 13 Jan 2010 06:57:53 -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 5BA9B3A6824 for ; Wed, 13 Jan 2010 06:57:53 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 94D869808F; Wed, 13 Jan 2010 06:57:50 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> <20100107072954.GA38654@elstar.local> <001601ca942d$d3384580$0601a8c0@allison> Date: Wed, 13 Jan 2010 06:57:50 -0800 In-Reply-To: <001601ca942d$d3384580$0601a8c0@allison> (tom petch's message of "Wed, 13 Jan 2010 09:51:35 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 bits of MIB module 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, 13 Jan 2010 14:57:54 -0000 >>>>> On Wed, 13 Jan 2010 09:51:35 +0100, "tom.petch" said: tp> Comments by Jeff and Joe prompted me to look into fingerprints which tp> in turn forced me to read parts of the MIB module. This is what I tp> found from the bits of the MIB module I looked at - if I looked at tp> more, I suspect that I would find more. Given that these new comments are months beyond the last call, I'll wait for the WG chairs to decide whether I should address them now or wait until IETF last call to look at them. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Jan 13 06:58:12 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FCB3A6928 for ; Wed, 13 Jan 2010 06:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P-HS95Fc-fL for ; Wed, 13 Jan 2010 06:58: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 4F3DC3A6824 for ; Wed, 13 Jan 2010 06:58:11 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 676C198090; Wed, 13 Jan 2010 06:58:08 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <006301ca9445$a0fefc40$0601a8c0@allison> Date: Wed, 13 Jan 2010 06:58:08 -0800 In-Reply-To: <006301ca9445$a0fefc40$0601a8c0@allison> (tom petch's message of "Wed, 13 Jan 2010 12:41:16 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 More bits of MIB module 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, 13 Jan 2010 14:58:12 -0000 >>>>> On Wed, 13 Jan 2010 12:41:16 +0100, "tom.petch" said: tp> I find the processing of server certificates by clients unclear when a tp> connection is being established as a result of the SNMP-TARGET-MIB tp> module. Given that these new comments are months beyond the last call, I'll wait for the WG chairs to decide whether I should address them now or wait until IETF last call to look at them. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Jan 13 06:58: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 4470D3A67AF for ; Wed, 13 Jan 2010 06:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ombxq-FV9AUe for ; Wed, 13 Jan 2010 06:58:22 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 6A1D23A6928 for ; Wed, 13 Jan 2010 06:58:22 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9AA7E9808F; Wed, 13 Jan 2010 06:58:19 -0800 (PST) From: Wes Hardaker To: Dave Shield Organization: Sparta References: Date: Wed, 13 Jan 2010 06:58:19 -0800 In-Reply-To: (Dave Shield's message of "Wed, 13 Jan 2010 11:12:23 +0000") 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] TLSTM draft -05 published 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, 13 Jan 2010 14:58:23 -0000 >>>>> On Wed, 13 Jan 2010 11:12:23 +0000, Dave Shield said: DS> I still need to catch up with the most recent discussions, DS> but the following comments from earlier versions still seem DS> to be relevant to the 05 draft. Mostly wordsmithing for DS> clarity, or typos. Feel free to adopt/ignore as you wish. Given that these new comments are months beyond the last call, I'll wait for the WG chairs to decide whether I should address them now or wait until IETF last call to look at them. -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Wed Jan 13 07:08: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 8EA653A698F for ; Wed, 13 Jan 2010 07:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 oNJFU8RCGNrF for ; Wed, 13 Jan 2010 07:08:18 -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 A53053A6940 for ; Wed, 13 Jan 2010 07:08:18 -0800 (PST) X-Trace: 229558373/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.146/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.146 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: AlMFAKlwTUs+vBOS/2dsb2JhbACCUIVXiHHGDQqEJgQ X-IronPort-AV: E=Sophos;i="4.49,268,1262563200"; d="scan'208";a="229558373" X-IP-Direction: IN Received: from 1cust146.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.146]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Jan 2010 15:08:13 +0000 Message-ID: <006901ca9459$dabb7940$0601a8c0@allison> From: "tom.petch" To: "tom.petch" , "Juergen Schoenwaelder" Date: Wed, 13 Jan 2010 15:04:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: [Isms] TLSTM -05 Yet more bits of MIB module 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: Wed, 13 Jan 2010 15:08:19 -0000 Appendix C. Target and /Notificaton/Notification/ C.1. Configuring the Notification /Generator/Originator/ For notification /generators/originators/ The certificate that the notification /generator/originator/ In passing, aplogies that my e-mail service is something of a one-way street at present; I will respond to replies as I see them. Tom Petch From j.schoenwaelder@jacobs-university.de Wed Jan 13 14:23:53 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D453A68A3 for ; Wed, 13 Jan 2010 14:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 hiP6uMbjgki1 for ; Wed, 13 Jan 2010 14:23:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 873383A688B for ; Wed, 13 Jan 2010 14:23:52 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81B0EC0012 for ; Wed, 13 Jan 2010 23:23:49 +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 DfrLRq1gvAL2; Wed, 13 Jan 2010 23:23:47 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF0B6C0003; Wed, 13 Jan 2010 23:23:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C3259FCC1B1; Wed, 13 Jan 2010 23:23:41 +0100 (CET) Date: Wed, 13 Jan 2010 23:23:41 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100113222341.GA36338@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] dtls document status and next steps X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 22:23:53 -0000 I like to clarify the process around the dtls document. The WG last call started on October 29th with a deadline of November 14. Due to the IETF meeting in between and initially a lack of reviews, I asked for additional reviews on November 16th. The document revision under last call was . Some additional reviews were received and I noted down the following reviewers: - Andrew Donati - Pasi Eronen - Juergen Schoenwaelder - Hamid Mukhtar - Alan Luchuk - Joe Salowey - David Harrington - Tom Petch Wes then started to process the comments, leading to the publication of revisions -02, -03, -04, and -05. The last two issues related to -05 were just resolved on the mailing list but now it seems new issues are being raised - some editorial some perhaps more substantial. In order to meet our goal to deliver the document in January to the AD, I hereby set a firm deadline for a final check of the latest revision (posted on January 8th) to January 19th. After January 19th, fwe will resolve the comments, if needed Wes will post revision -06, which I then intend to send to the AD. If you have technical comments, please make sure that they are precisely defined and ideally accompanied with concrete suggestions how to fix the issue in the document. /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 Thu Jan 14 11:34:25 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364363A69A3 for ; Thu, 14 Jan 2010 11:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 cNeM-3p-SLNY for ; Thu, 14 Jan 2010 11:34:24 -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 D99F63A69A2 for ; Thu, 14 Jan 2010 11:34:23 -0800 (PST) X-Trace: 230014855/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.249/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.249 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: Ah4GADwAT0s+vGT5/2dsb2JhbACCUS6FKYh4x14KgiGCBQQ X-IronPort-AV: E=Sophos;i="4.49,276,1262563200"; d="scan'208";a="230014855" X-IP-Direction: IN Received: from 1cust249.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.249]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Jan 2010 19:34:18 +0000 Message-ID: <009501ca9548$2fc36940$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <006301ca9445$a0fefc40$0601a8c0@allison> Date: Thu, 14 Jan 2010 17:52:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] TLSTM -05 More bits of MIB module X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 19:34:25 -0000 Juergen Thanks for the clarification on the process; my apologies for not being around at the time of the Last Call - I was away from when it started until long after it had finished - hence my lateness in reviewing and commenting. My comments on -05 are mostly editorial suggestions, but in two places, I find the I-D unclear and will be happy to suggest text once I am clear what the I-D is intending. Both relate to the checking performed by a client on a server certificate when the TARGET-MIB module is used. I am confused as to what the checking is. "This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS server-side certificate identifier .." Elsewhere certificates are located by a fingerprint so 'certificate identifier' - not host, or entity or engine identifier - sounds a lot like a fingerprint. So does the client fingerprint the incoming certificate and look for a match in the table (as well as looking for other matches such as in the subjectAltName field)? I see that as one reading of the text. If it is a wrong reading, then I think that the text needs clarifying; tell me and I will suggest text. Further on, I find no clarity about what is taken from draft-saintandre-tls-server-id-check and what is taken from the text here; which takes precedence, especially as draft-saintandre-tls-server-id-check forbids the use of * in the reference identity whereas the DESCRIPTION of tlstmAddrServerIdentity explicitly allows it? Finally, I am now reasonably confident that the tlstmAddrTable and the tlstmParamsTable are only used when a session is being established as a result of an entry in the TARGET-MIB module; this question confused me for a long time. I think that that needs explicitly stating in the DESCRIPTION clauses of the two tables and will also propose text for that. One reading of the current text is that you create entries in three tables (TARGET, tlstmAddr, tlstmParams) so that certificates get checked even if the session setup does not itself use the TARGET-MIB module. These comments are not intended to be technical changes, just clarity on what it meant. Tom Petch ----- Original Message ----- From: "tom.petch" To: "Juergen Schoenwaelder" Cc: "isms" Sent: Wednesday, January 13, 2010 12:41 PM Subject: [Isms] TLSTM -05 More bits of MIB module > I find the processing of server certificates by clients unclear when a > connection is being established as a result of the SNMP-TARGET-MIB module. > > 5.3 3 b talks of server identity being configured or not configured, the > DESCRIPTION clause talks of matching but does not say what is being matched. > > If a row has fingerprint and no server identity, can this produce a match? The > DESCRIPTION clause says > "This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable > with an expected (D)TLS server-side certificate identifier to .." > no mention of the server identity there implying that a match can take place on > the certificate identifier ie the fingerprint. > > If not, then I think the text needs clarifying as to just what is being checked. > > And, what if the table produces multiple matches? *.server.example.com and > *.example.com or perhaps multiple SANs of different types. > > As Joe has pointed out, there are differences for which the reasons are unclear > between the server's processing of a client certificate and the client's > processing of a server's certificate. > > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From wjhns1@hardakers.net Tue Jan 19 09:40:01 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B983A69C2 for ; Tue, 19 Jan 2010 09:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYwhtkd1n5iF for ; Tue, 19 Jan 2010 09:40:00 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 7C9043A6931 for ; Tue, 19 Jan 2010 09:40:00 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5D7E898073; Tue, 19 Jan 2010 09:39:56 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <006301ca9445$a0fefc40$0601a8c0@allison> <009501ca9548$2fc36940$0601a8c0@allison> Date: Tue, 19 Jan 2010 09:39:56 -0800 In-Reply-To: <009501ca9548$2fc36940$0601a8c0@allison> (tom petch's message of "Thu, 14 Jan 2010 17:52:13 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 More bits of MIB module 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, 19 Jan 2010 17:40:01 -0000 >>>>> On Thu, 14 Jan 2010 17:52:13 +0100, "tom.petch" said: tp> My comments on -05 are mostly editorial suggestions Thanks for those changes; I'll make sure to get to them after the end of the last-last-call today. tp> I am confused as to what the checking is. "This table extends the tp> SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS tp> server-side certificate identifier .." Elsewhere certificates are tp> located by a fingerprint so 'certificate identifier' - not host, or tp> entity or engine identifier - sounds a lot like a fingerprint. Good catch. The "certificate identifier" wording actually came from an earlier version of the certificate fingerprint TC where we weren't necessarily assuming a cryptgraphic hash as a fingerprint. Originally I was trying to be generic so that any unique identifier could be used. I'll be sure to change that text to say "fingerprint" again. tp> So does the client fingerprint the incoming certificate and look for tp> a match in the table Yes. tp> Further on, I find no clarity about what is taken from tp> draft-saintandre-tls-server-id-check and what is taken from the text tp> here; which takes precedence, especially as tp> draft-saintandre-tls-server-id-check forbids the use of * in the tp> reference identity whereas the DESCRIPTION of tp> tlstmAddrServerIdentity explicitly allows it? I think that is definitely a clash and I need to look into it. In fact, another person already pointed out that potential issue. So you're not alone in finding that the particular issue needs addressing. tp> Finally, I am now reasonably confident that the tlstmAddrTable and tp> the tlstmParamsTable are only used when a session is being tp> established as a result of an entry in the TARGET-MIB module Correct. They're extensions to the TARGET-MIB so I don't know why they'd be used otherwise. tp> this question confused me for a long time. I think that that needs tp> explicitly stating in the DESCRIPTION clauses of the two tables and tp> will also propose text for that. Ok; as they're extensions I think can be derived but I'm all for stating things clearly and explicitly. Please do propose text ASAP. Thanks for the questions and comments. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Jan 20 04:26: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 743683A6A65 for ; Wed, 20 Jan 2010 04:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 68pdB7jJ3t8I for ; Wed, 20 Jan 2010 04:26: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 1B8CC3A6836 for ; Wed, 20 Jan 2010 04:26:37 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15BD9C004D for ; Wed, 20 Jan 2010 13:26:33 +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 mTh85alWJsds; Wed, 20 Jan 2010 13:26:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F4C4C0017; Wed, 20 Jan 2010 13:26:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CE5201001C2D; Wed, 20 Jan 2010 13:26:22 +0100 (CET) Date: Wed, 20 Jan 2010 13:26:22 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100120122622.GA806@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] js review of draft-ietf-isms-radius-vacm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:26:38 -0000 Hi, I just took a look at the RADIUS VACM document and here are number of editorial issues and some more technical comments. a) I do not like the structure 1 Introduction 1.1 General 2 The Internet-Standard ... 3 Conventions What is the point of having 1.1 if there is no 1.2? I believe a more compact organization is this: 1 Introduction 1.1 General 1.2 The Internet-Standard ... 1.3 Conventions This avoids toplevel sections consisting of just one sentence. b) The first paragraph does not read well as an introduction. It is just a list of concepts that exist in SNMP without giving much clue why this list is provided or relevant. c) s/and interacts/and how it interacts/ d) s/RAIDUS/RADIUS/ e) s/imlementation/implementation f) s/RADIUS client function in the NAS and the SNMP engine in the NAS/ RADIUS client function and the SNMP engine/ g) s/extendedVacmSecurityToGroupTable/extVacmSecurityToGroupTable/ h) Remove "These rows are dynamically updated from RADIUS authorization data." since this has already been stated in the sentence before. i) s/make not update/make no update/ j) s/cab be/can be/ k) Spell out the complete name of 'rowCreatedBy' and 'rowLifetime'. l) s/secture/secure/ m) s/basedon/based on/ n) s/user-authenticaed/user-authenticated/ o) In 2.A., I assume secureTransportSecurityModel means Transport Security Model (TSM). But I like to raise the question whether this really should be hard wired. What happens if we eventually have to replace TSM with say TSM++? p) s/row.If/row. If/ q) s/incerment/increment/ r) s/casues/causes/ s) s/rwo/row/ t) The DESCRIPTION of the MODULE-IDENTITY might need adaptation to the legal trust boilerplate of the day. u) I do not understand why we have extVacmSecurityModel, extVacmSecurityName, extVacmGroupName, extVacmSecurityToGroupStorageType, and extVacmSecurityToGroupStatus since the idea is to create a row in the vacmSecurityToGroupTable. v) In step 2.E, the 'volatile' obviously belongs to the previous line w) s/exprires/expires/ x) It is unclear what extVacmRowLifetime reports - is this a ticking number running backwards until it reaches zero? Or is this the absolute value? In that case, the value is relatively meaningless unless someone know the time the entry was created. There probably should also be a UNITS clause. y) The security considerations should be added to the open issues list since they need to be filled in and there might be text needed concerning trust relationships to RADIUS and the interaction with statically configured policy. /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 Wed Jan 20 04:33:12 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128633A6ABD for ; Wed, 20 Jan 2010 04:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 0MGsYwQTJkji for ; Wed, 20 Jan 2010 04:33:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 15E3D3A69F3 for ; Wed, 20 Jan 2010 04:33:11 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11B94C0030 for ; Wed, 20 Jan 2010 13:33:07 +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 DreMJ529b9u3; Wed, 20 Jan 2010 13:33: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 2FB3BC0017; Wed, 20 Jan 2010 13:33:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7844B1001C94; Wed, 20 Jan 2010 13:32:57 +0100 (CET) Date: Wed, 20 Jan 2010 13:32:57 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100120123257.GB806@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] wg status update X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:33:12 -0000 Hi, I like to briefly talk about the WG status. We have two documents on our charter to be delivered in January 2010: - The (D)TLS transport is I believe in a pretty good state. The deadline to raise any new issues has passed without more issues being raised and I expect that Wes will followup on the remaining comments, leading to a new revision that should then be ready to go to the AD. - The RADIUS VACM document has not seen much review since it was updated in early December. This is not a difficult document but surely it requires more review and likely a few more updates before it can be submitted to the AD. So please, start taking a closer look at this document. - I do not plan to ask for an ISMS session at the next IETF since I assume that we have delivered both chartered documents by the Anaheim meeting and I am not aware of any strong push to pick up additional work items. (If I am wrong, let the chairs know.) /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 Wed Jan 20 04:33:25 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BA53A6ABD for ; Wed, 20 Jan 2010 04:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 FTJfQO6bZy3r for ; Wed, 20 Jan 2010 04:33:24 -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 02EB73A69F3 for ; Wed, 20 Jan 2010 04:33:23 -0800 (PST) X-Trace: 320831039/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.204/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.204 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: Ag0HABuHVks+vGTM/2dsb2JhbACCUoVYiHnGZAqCJIIIBA X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208";a="320831039" X-IP-Direction: IN Received: from 1cust204.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.204]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Jan 2010 12:33:18 +0000 Message-ID: <01e601ca99c4$596c7400$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <006301ca9445$a0fefc40$0601a8c0@allison><009501ca9548$2fc36940$0601a8c0@allison> Date: Wed, 20 Jan 2010 12:31:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] TLSTM -05 More bits of MIB module 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: Wed, 20 Jan 2010 12:33:25 -0000 Wes My suggested DESCRIPTION clauses based on my current understanding (which may still be imperfect). tlstmParamsTable "This table is used by a (D)TLS client when a (D)TLS session is being set up using an entry in the SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's snmpTargetParamsTable with a fingerprint of a certificate to use when establishing such a (D)TLS connection." tlstmAddrTable This table is used by a (D)TLS client when a (D)TLS session 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 validate the certificate that the server presents. 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), then the fingerprint of the server's certificate is compared with the value of the tlstmAddrServerFingerprint column. If fingerprint does not match, then the connection MUST NOT be established. If the row exists with a zero-length tlstmAddrServerFingerprint value and the certificate can be validated through another certificate validation path (such as the path validation procedures defined in [RFC5280]) then the server's presented identity should be checked against the value of the tlstmAddrServerIdentity column following the procedures specified in draft-saintandre-tls-server-id-check. If the server's identity does not match the reference identity found in the tlstmAddrServerIdentity column then the connection MUST NOT be established. A tlstmAddrServerIdentity may contain a '*' to match any server's identity or may contain a '*.' prefix to match any server identity from a given domain (e.g. '*.example.com'). Note that this overrides the provision specified in draft-saintandre-tls-server-id-check. If there is no row in this table corresponding to an entry in the SNMP-TARGET-MIB and another certificate validation path algorithm (such as the path validation procedures defined in [RFC5280]) can be followed to a configured trust anchor, then the connection SHOULD still proceed." Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Juergen Schoenwaelder" ; "isms" Sent: Tuesday, January 19, 2010 6:39 PM Subject: Re: TLSTM -05 More bits of MIB module > >>>>> On Thu, 14 Jan 2010 17:52:13 +0100, "tom.petch" said: > > tp> My comments on -05 are mostly editorial suggestions > > Thanks for those changes; I'll make sure to get to them after the end of > the last-last-call today. > > tp> I am confused as to what the checking is. "This table extends the > tp> SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS > tp> server-side certificate identifier .." Elsewhere certificates are > tp> located by a fingerprint so 'certificate identifier' - not host, or > tp> entity or engine identifier - sounds a lot like a fingerprint. > > Good catch. The "certificate identifier" wording actually came from an > earlier version of the certificate fingerprint TC where we weren't > necessarily assuming a cryptgraphic hash as a fingerprint. Originally I > was trying to be generic so that any unique identifier could be used. > I'll be sure to change that text to say "fingerprint" again. > > tp> So does the client fingerprint the incoming certificate and look for > tp> a match in the table > > Yes. > > tp> Further on, I find no clarity about what is taken from > tp> draft-saintandre-tls-server-id-check and what is taken from the text > tp> here; which takes precedence, especially as > tp> draft-saintandre-tls-server-id-check forbids the use of * in the > tp> reference identity whereas the DESCRIPTION of > tp> tlstmAddrServerIdentity explicitly allows it? > > I think that is definitely a clash and I need to look into it. In fact, > another person already pointed out that potential issue. So you're not > alone in finding that the particular issue needs addressing. > > tp> Finally, I am now reasonably confident that the tlstmAddrTable and > tp> the tlstmParamsTable are only used when a session is being > tp> established as a result of an entry in the TARGET-MIB module > > Correct. They're extensions to the TARGET-MIB so I don't know why > they'd be used otherwise. > > tp> this question confused me for a long time. I think that that needs > tp> explicitly stating in the DESCRIPTION clauses of the two tables and > tp> will also propose text for that. > > Ok; as they're extensions I think can be derived but I'm all for stating > things clearly and explicitly. Please do propose text ASAP. > > Thanks for the questions and comments. > -- > Wes Hardaker > Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 10:28: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 DDD393A67F2 for ; Mon, 25 Jan 2010 10:28: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=[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 YKSpkO5I7NZY for ; Mon, 25 Jan 2010 10:28: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 E33683A67E9 for ; Mon, 25 Jan 2010 10:28:35 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 7965399CD9 for ; Mon, 25 Jan 2010 10:28:42 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 25 Jan 2010 10:28:42 -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 Subject: [Isms] TLSTM counters issue 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, 25 Jan 2010 18:28:37 -0000 Robert Story sent me comments on the draft as well (in between the first last call and Juergen's request for final comments by the 19th) and I was looking into his comments. One issue that he brought up is that with the current MIB we have the following two counters: snmpSshtmSessionOpens snmpSshtmSessionCloses These both describe "client" side connection open and closes. This exactly mirrors the SSHTM MIB. But he brings up a good point that it would be useful to have similar counters on the server side. So, the choices are: 1) Don't add them (SSH doesn't have server side counters) 2) Add them and change the name of the originals so we have: snmpSshtmSessionClientOpens snmpSshtmSessionClientCloses snmpSshtmSessionServerOpens snmpSshtmSessionServerCloses 3) Change the current counters so they summarize both client and server side connections. Note that I don't think this is a valid option since if I recall the original counter text actually was counting both sides and the WG wanted the counters to mirror the client-side behavior of the SSH document. So I think the only valid choices, based on the past history, are #1 and #2 above. Thoughts? The new counters, if desired, would be: snmpTlstmSessionServerOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a (D)TLS session has been successfully established on a (D)TLS server. " ::= { snmpTlstmSession N } snmpTlstmSessionServerCloses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a (D)TLS session has been closed on a (D)TLS server. " ::= { snmpTlstmSession N } Note that the client side text is a bit different since we're really counting ASI invocations regardless of whether they succeed or fail: "The number of times an openSession() request has been executed as an (D)TLS client, whether it succeeded or failed." On the server, you can't necessarily count failed session invocations to you. And I'm not sure how you'd a failed closed session, since you'd always delete it from your session list which is functionally always closed on the server side. -- Wes Hardaker Cobham Analytic Solutions From Robert.Story@cobham.com Mon Jan 25 11:04: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 7AFD63A6834 for ; Mon, 25 Jan 2010 11:04:53 -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 VzHcUsGPqBaG for ; Mon, 25 Jan 2010 11:04:52 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 715A23A679C for ; Mon, 25 Jan 2010 11:04:52 -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 o0PJ4vrI004102; Mon, 25 Jan 2010 13:04:57 -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 o0PJ4vw5027716; Mon, 25 Jan 2010 13:04:57 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 14:04:57 -0500 Date: Mon, 25 Jan 2010 14:04:53 -0500 From: Robert Story To: Wes Hardaker Message-ID: <20100125140453.4c7feb24@sparta.com> In-Reply-To: References: Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/cFZ6c+JQIQxAWtam4NsqAYu"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 25 Jan 2010 19:04:57.0211 (UTC) FILETIME=[491284B0:01CA9DF1] Cc: isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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, 25 Jan 2010 19:04:53 -0000 --Sig_/cFZ6c+JQIQxAWtam4NsqAYu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 25 Jan 2010 10:28:42 -0800 Wes wrote: WH>=20 WH> Robert Story sent me comments on the draft as well (in between the first WH> last call and Juergen's request for final comments by the 19th) and I WH> was looking into his comments. One issue that he brought up is that WH> with the current MIB we have the following two counters: WH>=20 WH> snmpSshtmSessionOpens WH> snmpSshtmSessionCloses I assume you mean snmpTlstmSession*, here and below. WH> 2) Add them and change the name of the originals so we have: WH> snmpSshtmSessionClientOpens WH> snmpSshtmSessionClientCloses WH> snmpSshtmSessionServerOpens WH> snmpSshtmSessionServerCloses I vote for this option. I'd like to be able to know how much use (D)TLS is getting on the server side... WH> On the server, you can't necessarily count failed session invocations to WH> you. But you could count the number of times that the certificate presented by the client wasn't accepted, right? So I'd think there should be a snmpTlstmSessionServerOpenErrors as well. Which raises the question of why there aren't tlstmClient(CertificateUnknown|InvalidCertificate) notifications as well. [Did I ask before why it's not UnknownCertificate instead of CertificateUnknown? Everythwere else in the mib is XxxCertificate.] WH> And I'm not sure how you'd a failed closed session, since you'd WH> always delete it from your session list which is functionally always WH> closed on the server side. You could get an error from the TLS close_notify... Though I'm not even sure why the server would ever initiate closing a session. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/cFZ6c+JQIQxAWtam4NsqAYu Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktd61gACgkQ7/fVLLY1mniTpwCgjbC0BquHgwwhFg8s/kPQlN1x aioAoI186dfTA6WMF+EVCbxsV0ZBiHrH =aFjt -----END PGP SIGNATURE----- --Sig_/cFZ6c+JQIQxAWtam4NsqAYu-- From wjhns1@hardakers.net Mon Jan 25 11:42:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AEC3A68DD for ; Mon, 25 Jan 2010 11:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wa5crK9njvl for ; Mon, 25 Jan 2010 11:42:45 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id F386F3A6834 for ; Mon, 25 Jan 2010 11:42:44 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D02AE99D61; Mon, 25 Jan 2010 11:42:51 -0800 (PST) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100125140453.4c7feb24@sparta.com> Date: Mon, 25 Jan 2010 11:42:51 -0800 In-Reply-To: <20100125140453.4c7feb24@sparta.com> (Robert Story's message of "Mon, 25 Jan 2010 14:04:53 -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] TLSTM counters issue 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, 25 Jan 2010 19:42:45 -0000 >>>>> On Mon, 25 Jan 2010 14:04:53 -0500, Robert Story said: RS> I assume you mean snmpTlstmSession*, here and below. Yep. My bad; I copied from the other document since I was comparing them and forgot which I was staring it. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Jan 25 13:37:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACA43A68F0 for ; Mon, 25 Jan 2010 13:37:45 -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 vTBvhKD9UIIj for ; Mon, 25 Jan 2010 13:37:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D0E9E3A67F3 for ; Mon, 25 Jan 2010 13:37:44 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1CDEC0011; Mon, 25 Jan 2010 22:37:51 +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 giMpAqRnyfLB; Mon, 25 Jan 2010 22:37:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E1C5C0005; Mon, 25 Jan 2010 22:37:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A19D01011AC3; Mon, 25 Jan 2010 22:37:40 +0100 (CET) Date: Mon, 25 Jan 2010 22:37:40 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100125213740.GA50176@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] TLSTM counters issue 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, 25 Jan 2010 21:37:46 -0000 On Mon, Jan 25, 2010 at 07:28:42PM +0100, Wes Hardaker wrote: > > Robert Story sent me comments on the draft as well (in between the first > last call and Juergen's request for final comments by the 19th) and I > was looking into his comments. One issue that he brought up is that > with the current MIB we have the following two counters: > > snmpSshtmSessionOpens > snmpSshtmSessionCloses > > These both describe "client" side connection open and closes. This > exactly mirrors the SSHTM MIB. But he brings up a good point that it > would be useful to have similar counters on the server side. > > So, the choices are: > > 1) Don't add them (SSH doesn't have server side counters) > 2) Add them and change the name of the originals so we have: > snmpSshtmSessionClientOpens > snmpSshtmSessionClientCloses > snmpSshtmSessionServerOpens > snmpSshtmSessionServerCloses > 3) Change the current counters so they summarize both client and server > side connections. Note that I don't think this is a valid option > since if I recall the original counter text actually was counting > both sides and the WG wanted the counters to mirror the client-side > behavior of the SSH document. So I think the only valid choices, > based on the past history, are #1 and #2 above. > > Thoughts? It is not clear to me what "D(TLS) session successfully established" means - how deep I have to peek into D(TLS) to implement these counters. The EoP do not describe when snmpTlstmSessionOpens is incremented (perhaps an omission, there is text for snmpTlstmSessionCloses). > The new counters, if desired, would be: > > snmpTlstmSessionServerOpens OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of times a (D)TLS session has been > successfully established on a (D)TLS server. > " > ::= { snmpTlstmSession N } It is not clear to me whether this includes successful (D)TLS exchanges and if so which ones. How deep do I have to peek into (D)TLS to implement this counter? /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 Jan 25 13:41:54 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 AF75E3A67F3 for ; Mon, 25 Jan 2010 13:41:54 -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 Qsg2O8TSSg9j for ; Mon, 25 Jan 2010 13:41:54 -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 C1E193A6778 for ; Mon, 25 Jan 2010 13:41:53 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 01E7399E29; Mon, 25 Jan 2010 13:41:59 -0800 (PST) From: Wes Hardaker To: "Joseph Salowey \(jsalowey\)" Organization: Sparta References: Date: Mon, 25 Jan 2010 13:41:58 -0800 In-Reply-To: (Joseph Salowey's message of "Mon, 11 Jan 2010 09:33:34 -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] IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry 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, 25 Jan 2010 21:41:54 -0000 >>>>> On Mon, 11 Jan 2010 09:33:34 -0800, "Joseph Salowey (jsalowey)" said: JS> One question/nit: in section 5.3, 3b - says that path validation like JS> 5280 MUST be followed, isn't this only the case if a fingerprint match JS> was not available? I changed the text to the following to resolve this issue: Validation procedures (like the path validation procedures defined in or through the use of fingerprints as defined by the tlstmAddrServerIdentity column) MUST be followed. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Mon Jan 25 13:48: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 8F4043A6905 for ; Mon, 25 Jan 2010 13:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s48HGqV4plqI for ; Mon, 25 Jan 2010 13:48:22 -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 3F9333A68F1 for ; Mon, 25 Jan 2010 13:48:22 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id ZnmE1d0050ldTLk5ExoWG2; Mon, 25 Jan 2010 21:48:30 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta04.westchester.pa.mail.comcast.net with comcast id ZxoV1d00F284sdk3QxoVUX; Mon, 25 Jan 2010 21:48:30 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Wes Hardaker'" References: <20100125213740.GA50176@elstar.local> Date: Mon, 25 Jan 2010 16:48:28 -0500 Message-ID: <04c101ca9e08$2177b260$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: <20100125213740.GA50176@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqeBqinbR0rNBz2Qg+xe1dJNTq6rgAARm0g Cc: isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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, 25 Jan 2010 21:48:23 -0000 in SSHTM, the open sessions counter is incremented before any open processing actually occurs; it counts the number of times the openSession ASI is called. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, January 25, 2010 4:38 PM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] TLSTM counters issue > > On Mon, Jan 25, 2010 at 07:28:42PM +0100, Wes Hardaker wrote: > > > > Robert Story sent me comments on the draft as well (in > between the first > > last call and Juergen's request for final comments by the > 19th) and I > > was looking into his comments. One issue that he brought up is that > > with the current MIB we have the following two counters: > > > > snmpSshtmSessionOpens > > snmpSshtmSessionCloses > > > > These both describe "client" side connection open and closes. This > > exactly mirrors the SSHTM MIB. But he brings up a good > point that it > > would be useful to have similar counters on the server side. > > > > So, the choices are: > > > > 1) Don't add them (SSH doesn't have server side counters) > > 2) Add them and change the name of the originals so we have: > > snmpSshtmSessionClientOpens > > snmpSshtmSessionClientCloses > > snmpSshtmSessionServerOpens > > snmpSshtmSessionServerCloses > > 3) Change the current counters so they summarize both > client and server > > side connections. Note that I don't think this is a valid option > > since if I recall the original counter text actually was counting > > both sides and the WG wanted the counters to mirror the > client-side > > behavior of the SSH document. So I think the only valid choices, > > based on the past history, are #1 and #2 above. > > > > Thoughts? > > It is not clear to me what "D(TLS) session successfully established" > means - how deep I have to peek into D(TLS) to implement these > counters. The EoP do not describe when snmpTlstmSessionOpens is > incremented (perhaps an omission, there is text for > snmpTlstmSessionCloses). > > > The new counters, if desired, would be: > > > > snmpTlstmSessionServerOpens OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "The number of times a (D)TLS session has been > > successfully established on a (D)TLS server. > > " > > ::= { snmpTlstmSession N } > > It is not clear to me whether this includes successful (D)TLS > exchanges and if so which ones. How deep do I have to peek into (D)TLS > to implement this counter? > > /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 wjhns1@hardakers.net Mon Jan 25 13:52:54 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 B31F13A68E1 for ; Mon, 25 Jan 2010 13:52:54 -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 uTTGaUq8DU3S for ; Mon, 25 Jan 2010 13:52:54 -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 C9F283A67F3 for ; Mon, 25 Jan 2010 13:52:53 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D253B99E2E; Mon, 25 Jan 2010 13:53:00 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20100125213740.GA50176@elstar.local> <04c101ca9e08$2177b260$0600a8c0@china.huawei.com> Date: Mon, 25 Jan 2010 13:53:00 -0800 In-Reply-To: <04c101ca9e08$2177b260$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 25 Jan 2010 16:48:28 -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] TLSTM counters issue 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, 25 Jan 2010 21:52:54 -0000 >>>>> On Mon, 25 Jan 2010 16:48:28 -0500, "David Harrington" said: DH> in SSHTM, the open sessions counter is incremented before any open DH> processing actually occurs; it counts the number of times the DH> openSession ASI is called. Thanks; that makes sense. And in light of that and in Juergen's analysis I have to agree with the way it was done in SSHTM. I'm not sure how possible it is (in all implementations) to determine when a successful (D)TLS negotiation has succeeded and thus the server side counters may be impossible to detect without specific state tracking looking for the first SNMP packet to traverse a connection and counting the "firsts". And I don't think that's worth it. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 13:57: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 42EF13A6917 for ; Mon, 25 Jan 2010 13:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q7ll5p0lhpe for ; Mon, 25 Jan 2010 13:57:22 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D43433A63C9 for ; Mon, 25 Jan 2010 13:57:21 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id ED2E299E2E; Mon, 25 Jan 2010 13:57:28 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <006301ca9445$a0fefc40$0601a8c0@allison> <009501ca9548$2fc36940$0601a8c0@allison> <01e601ca99c4$596c7400$0601a8c0@allison> Date: Mon, 25 Jan 2010 13:57:28 -0800 In-Reply-To: <01e601ca99c4$596c7400$0601a8c0@allison> (tom petch's message of "Wed, 20 Jan 2010 12:31:57 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 More bits of MIB module 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, 25 Jan 2010 21:57:23 -0000 Tom, Regarding your suggested text replacements for some of the tables I have the following action summary for what I've done with your suggestions. Markings reminders: My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it 1 DONE tlstmParamsTable ~~~~~~~~~~~~~~~~~~~~~~~~ "This table is used by a (D)TLS client when a (D)TLS session is being set up using an entry in the SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's snmpTargetParamsTable with a fingerprint of a certificate to use when establishing such a (D)TLS connection." 2 DONE tlstmAddrTable ~~~~~~~~~~~~~~~~~~~~~~ This table is used by a (D)TLS client when a (D)TLS session 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 validate the certificate that the server presents. 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), then the fingerprint of the server's certificate is compared with the value of the tlstmAddrServerFingerprint column. If fingerprint does not match, then the connection MUST NOT be established. If the row exists with a zero-length tlstmAddrServerFingerprint value and the certificate can be validated through another certificate validation path (such as the path validation procedures defined in [RFC5280]) then the server's presented identity should be checked against the value of the tlstmAddrServerIdentity column following the procedures specified in draft-saintandre-tls-server-id-check. If the server's identity does not match the reference identity found in the tlstmAddrServerIdentity column then the connection MUST NOT be established. A tlstmAddrServerIdentity may contain a '*' to match any server's identity or may contain a '*.' prefix to match any server identity from a given domain (e.g. '*.example.com'). Note that this overrides the provision specified in draft-saintandre-tls-server-id-check. If there is no row in this table corresponding to an entry in the SNMP-TARGET-MIB and another certificate validation path algorithm (such as the path validation procedures defined in [RFC5280]) can be followed to a configured trust anchor, then the connection SHOULD still proceed." + WH: I used a slightly modified version of your text. Most specifically: + I didn't include a reference to the draft-saintandre-tls-server-id-check document since we're unsure of it's future progress and it's not the only way that an identity could be checked. + I removed support completely for wildcards; I vaguely recall this request coming from a discussion in Stockholm but it is clearly not acceptable practice and I'd rather remove it. That paragraph now says: A tlstmAddrServerIdentity may contain a single ASCII '*' character (ASCII code 0x2a) to match any server's identity if the tlstmAddrServerFingerprint column is not blank. A row MUST NOT contain both a blank tlstmAddrServerFingerprint column and a '*' in the tlstmAddrServerIdentity column since this would insecurely accept any presented certificate. And the RowStatus column now also says: Rows MUST NOT be active if the tlstmAddrServerFingerprint column is blank and the tlstmAddrServerIdentity is set to '*' since this would insecurely accept any presented certificate. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 13:58:43 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357713A63C9 for ; Mon, 25 Jan 2010 13:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WZ916MwCqV81 for ; Mon, 25 Jan 2010 13:58:42 -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 40ED73A67CC for ; Mon, 25 Jan 2010 13:58:42 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5EA1399E2F; Mon, 25 Jan 2010 13:58:49 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <006901ca9459$dabb7940$0601a8c0@allison> Date: Mon, 25 Jan 2010 13:58:49 -0800 In-Reply-To: <006901ca9459$dabb7940$0601a8c0@allison> (tom petch's message of "Wed, 13 Jan 2010 15:04:10 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 Yet more bits of MIB module 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, 25 Jan 2010 21:58:43 -0000 My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it 1 DONE Appendix C. Target and /Notificaton/Notification/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 DONE C.1. Configuring the Notification /Generator/Originator/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 DONE For notification /generators/originators/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 DONE The certificate that the notification /generator/originator/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 14:00: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 04F6B28C104 for ; Mon, 25 Jan 2010 14:00:39 -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 omVCTK-0dM4J for ; Mon, 25 Jan 2010 14:00:37 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 448A328C101 for ; Mon, 25 Jan 2010 14:00:37 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 635AA99E31; Mon, 25 Jan 2010 14:00:44 -0800 (PST) From: Wes Hardaker To: Dave Shield Organization: Sparta References: Date: Mon, 25 Jan 2010 14:00:44 -0800 In-Reply-To: (Dave Shield's message of "Wed, 13 Jan 2010 11:12:23 +0000") 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] TLSTM draft -05 published 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, 25 Jan 2010 22:00:39 -0000 >>>>> On Wed, 13 Jan 2010 11:12:23 +0000, Dave Shield said: DS> I still need to catch up with the most recent discussions, DS> but the following comments from earlier versions still seem DS> to be relevant to the 05 draft. Mostly wordsmithing for DS> clarity, or typos. Feel free to adopt/ignore as you wish. Thanks for the suggestions Dave, they've certainly helped the document's readability. Below are my responses/actions to your comments. My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it * DONE 3.1.1 Step 3, para 2 s/sequencing ability/sequencing ability,/ s/sequence number for/sequence number used for/ * DONE 3.1.2 para 2 s/through the cache, the application/it also/ * DONE 3.3 para 3 The bulk of this paragraph seems to be discussing how to populate the target-related MIB tables, when used with a DTLS transport destination. All except the last sentence, which is more concerned with access control. Suggestion: Insert a new paragraph break before "The securityName defined ...." * DONE 4.1.1 para 1 s/through a trusted out of band mechanism into the server/ into the server through a trusted out of band mechanism,/ s/its authenticity/their authenticity/ * DONE 4.1.1 para 2, bullets s/type and value/value/ Given that the name-based mapping is the preferred approach, (as indicated immediately following), might it be worth switching the order of these two bullet items? * WONTDO 4.1.1 para 6 s/by the security model. A security model, like the TSM security model [RFC5591], may perform/ by a security model, such as the TSM security model [RFC5591]. This security model may perform/ + WH: The TSM security model is the only current one that does a mapping of some kind, but your text uses "This" which I don't think is appropriate since it gives the impression that the TSM will be the only one (which may or may not be true). * DONE 4.1.1 diagram Most of the elements in this diagram are modules from the (transport-extended) SNMPv3 architecture. However 'tmSecurityName' and 'securityName' are values passed (via the cache) from one module to another. Might it be useful to distinguish these different cases within the diagram. E.g. by omitting the boxes: +-------+ tmSecurityName +-----+ | TLSTM | -------------------> | TSM | +-------+ +-----+ + WH: Ok, see what you think of the new picture. * DONE 4.3.1 statusInformation s/passing of the message/sending of the message/ destTransportDomain s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/ outgoingMessage s/send to (D)TLS for encapsulation/ pass to (D)TLS for encapsulation and transmission/ * DONE 4.3.2 transportDomain s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/ incomingMessage s/removed of/removal of/ * DONE 5 para 2 s/first prior/prior/ * DONE 5.1 Suggested text: This section describes the procedures followed by the (D)TLS Transport Model when it receives a (D)TLS protected packet. The required functionality is broken into two different sections. Section 5.1.1 described the processing required for de-multiplexing multiple DTLS sessions, which is specifically needed for DTLS over UDP sessions. It is assumed that TLS and DTLS/SCP protocol implementations already provide appropriate message demultiplexing. Section 5.1.2 describes the transport processing required once the (D)TLS processing has been completed. This will be needed for all (D)TLS-based sessions. + WH: text changed to the above-ish: + s/5.1.1 described/5.1.1 describes/ + 3 paragraphs were used instead of 2 (the first broken into two). * DONE 5.1.1 para 1 s/always critical/critical/ s/implementations be able/implementations are always able/ * DONE 5.1.1 para 2 s/wholeMessage/incomingMessage/ s/wholeMessageLength/incomingMessageLength/ [as per RFC 5590] * DONE 5.1.1 step 2, para 1 s/ and its tlsSnmpSessionID// [The session ID is retrieved in step 3] * WONTDO 5.1.1 step 2, para 3 s/both above and in Section 5.3/in Section 5.3/ + WH: No, it's described directly above. We could change it to be more explicitly stated like "in the last paragraph and in Section 5.3". Would that be better? * DONE 5.1.1 step 5 s/in the Section 5.1.2/in Section 5.1.2/ * DONE 5.1.2 Is it worth numbering these processing steps? E.g. 1) Create a tmStateReference .... 2) The wholeMessage and the wholeMessageLength .... 3) The TLS Transport Model .... + WH: Sure. makes sense. * DONE 5.1.2 step 2 The incomingMessage and incomingMessageLength are assigned values from the (D)TLS processing. * DONE 5.1.2 step 3 s/wholeMessage/incomingMessage/ s/wholeMessageLength/incomingMessageLength/ [as per RFC 5590] * DONE 6.2 bullet 1 s/New TransportDomain and TransportAddress formats/ A new TransportAddress format/ [The TransportDomains are objects, not TCs] * DONE 7 tlstmCertSpecified a/the mapping will be considered a failure/ , and an alternative mapping looked for/ + WH: actually it was far more broken than even that would fix. I changed the text to: The tlstmCertToTSNData column must contain a non-zero length SnmpAdminString compliant value or the mapping described in this row must be considered a failure. * DONE 7 tlstmCertSANRFC822Name s/exmaple/example/ * WONTDO 7 tlstmCertSANRFC822Name Should this description mention the 32-character limit for security names, and describe what should happen if the RFC822 name is longer than this? [The required behaviour is covered in the descriptions of tlstmCertToTSNTable and tlstmCertToSNMapType, but it might be worth mentioning it here too.] + WH: I think mentioning it in every object-identity mapping is more text than is needed and is over kill. * WONTDO 7 tlstmCertSANDNSName + WH: I think mentioning it in every object-identity mapping is more text than is needed and is over kill. * WONTDO 7 tlstmCertCommonName Again, should these descriptions touch on the 32-character limit? [e.g. using similar wording to tlstmCertSpecified) + WH: I think mentioning it in every object-identity mapping is more text than is needed and is over kill. tlstmCertSpecified doesn't contain text describing the 32 character issue. It contains text describing special ramifications of the values populated into the tlstmCertToSNData column. * DONE 7 tlstmCertToTSNTable, para 4, step 2 s/CA certificated/CA certificate/ -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 14: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 D2DF428C0F3 for ; Mon, 25 Jan 2010 14: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 O++Nj0h3Rv5c for ; Mon, 25 Jan 2010 14: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 392C528C0EB for ; Mon, 25 Jan 2010 14:02:46 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 42F0199E34; Mon, 25 Jan 2010 14:02:50 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> <20100101115205.GA28799@elstar.local> <01cb01ca8df8$d0889be0$0601a8c0@allison> <20100105123124.GB34963@elstar.local> <002101ca8eaf$b71e07a0$0601a8c0@allison> <20100106111601.GB36984@elstar.local> <033a01ca8ee6$73004420$0600a8c0@china.huawei.com> <000901ca8ef8$306a8000$0601a8c0@allison> <20100107072954.GA38654@elstar.local> <001601ca942d$d3384580$0601a8c0@allison> Date: Mon, 25 Jan 2010 14:02:50 -0800 In-Reply-To: <001601ca942d$d3384580$0601a8c0@allison> (tom petch's message of "Wed, 13 Jan 2010 09:51:35 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 bits of MIB module 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, 25 Jan 2010 22:02:47 -0000 Thanks again for your various comments on the document; they've certainly helped improve the overall readability of it. My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it * DONE 1) tlstmCertSpecified OBJECT-IDENTITY ... /value or contains/value or contain/ + WH: text actually changed entirely (see Dave S's comments) * DONE 2) tlstmCertSANRFC822Name /FooBar@exmaple.com/FooBar@example.com/ * DONE 3a) tlstmCertSANAny dNSName presumably uses the capitalisation of RFC5280 in which case it should be 'iPAddress' and presumably tlstmCertSANIPAddress, here and in other places. * WONTDO 3b) I agree with Jeff's comment in December that this could be better named. + WH: What could be better named? Your comment doesn't list what you are referring to, nor does it propose alternate names. * WONTDO 4) snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE "I.E., a cryptographic validation occurred during certificate validation processing." This seems to be telling me that cryptographic validation occurred during cryptographic validation:-) + WH: Actually I think it points out that cryptographic validation failed when doing 'certificate' processing. You didn't propose any replacement text so I'm not sure what to do in the first place since I find the current text sufficient. * DONE 5a) tlstmCertToTSNTable OBJECT-TYPE "A table listing the X.509 certificates known to the entity..." Not really, it list fingerprints, which is not the only way they could be listed; suggest "A table listing the fingerprints of X.509 certificates known to the entity" * ANSWERED 5b)"public certificate (e.g. RFC5280). " This seems a bit bald. Is it a reference? if so make it one, give it a clause. And why EG; what other examples had the author in mind? + WH: It's shying away from specifying that *only* 5280 path validation procedures must be used; others could be appropriate. * DONE 5c) "Subject field but usage of the CommonName field is deprecated." This sounds to me like a SHOULD NOT. + WH: Changed to "Certificates may also be mapped to tmSecurityNames using the CommonName portion of the Subject field. However, the usage of the CommonName field is deprecated and thus this usage is NOT RECOMMENDED." * DONE 6) tlstmCertToTSNID OBJECT-TYPE "A unique, prioritized index for the given entry." How are they prioritized, what represents high and what low priority? I am sure that some people will come to the opposite view to that of the author. + WH: I added "Lower numbers indicate a higher priority." (note, however, that it discusses this in other portions of the document. It's still wise to put the extra text in this DESCRIPTION as well). * DONE 7) tlstmCertToTSNData OBJECT-TYPE "Axillary " Has our object tree sprouted axils? + WH: never blindly trust the first replacement choice from a spelling checker. * DONE 8) -- Lists expected certificate fingerprints to be presented by a DTLS -- server Why DTLS and not (D)TLS? I was going to say client not server, since this immediately follows the client table but then I realised that this relates to three objects hence. If it is going to say 'Lists expected certificate fingerprints ' then I think that it should immediately precede tlstmAddrTable not be separated by two other objects. WH: Actually, I don't think the comment is needed at all. The descriptions in the objects are much better than that comment, so I've removed it. * DONE 9) tlstmAddrTable /columnshould/column should/ * DONE 10) tlstmAddrServerIdentity OBJECT-TYPE This references draft-saintandre-tls-server-id-check which goes into detail about the use of asterisk and about which fields to use, but then includes text about asterisks with nothing about fields. This is potentially contradictory and ambiguous. Are you saying anything in draft-saintandre-tls-server-id-check goes, are you saying that draft-saintandre-tls-server-id-check applies unless overridden by the description clause or what? Given that draft-saintandre-tls-server-id-check is still under discussion and yet to be finalised, this issue needs more attention. + WH: The text has been changed. It no longer allows for *.example.com. It still allows for a single '*' to indicate accept anything when the fingerprint column is specified. It is illegal, now, to have a blank fingerprint column and a '*' wildcard though. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Jan 25 14:11:15 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 E70973A67F3 for ; Mon, 25 Jan 2010 14:11: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 rkCwFtxxzD0r for ; Mon, 25 Jan 2010 14:11:12 -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 A2EF43A67D7 for ; Mon, 25 Jan 2010 14:11:11 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BF4D699E5A; Mon, 25 Jan 2010 14:11:18 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 25 Jan 2010 14:11:18 -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: Robert Story Subject: [Isms] Responses to Robert Story's about the TLSTM draft 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, 25 Jan 2010 22:11:15 -0000 Robert, Thanks for your comments about the document. They've definitely been helpful in improving readability. Although some of them were duplicates of others, there are other good points that no one else caught (like duplicate paragraphs!) Below are my responses. Note that because your comments were sent to me outside the WG many working group members may not have seen these yet, but I don't think they're continuous. I'd still encourage other WG participants to read them and my responses though. My responses are prefixed below with "WH:" if you want to search for them. The status of each item is as follows: DONE: Suggestion was acted on WONTDO: Nothing was done; refer to the WH: response for reasons why DISCUSS: There is an outstanding question back to you ANSWERED: A question was answered but had no action resulting from it A note of disclosure: Robert and I do work for the same employer. He has not had the opportunity before recently to read the draft, however, and send the comments to me after the end of the last WG last call but before the last 19th cut-off date so I decided to act on them just as I had everyone else's comments to the list. * DONE section 1, in diagram, 'LCD' is used, but not expanded until section 5.1.1. LCD is not used as an acronym in 5590 or 5591. + WH: removed LCD from the diagram; I don't think it's needed. * DONE section 1.1, + DONE paragraphs starting with "Authentication in this document typically ..." and "The terms "manager" and "agent" are not used in this document ..." are both repeated (though slightly differently worded). + WH: good catch; thanks. (the first set of wording was copied from 5592 and the second set should have been removed). + DONE paragraph starting with "Throughout this document, the terms "client" and "server" ..." talks about ends of connections, then says 'either SNMP entity'... 3411 defines more than 2 SNMP entities... + WH: oddly, 5592 has the same issue. However, our text was already fixed due to other suggested text replaced. * DONE section 3.2 "e.g..," should be "e.g.". "transport- related" should be "transport-related". * DONE section 4.3.1, + DONE destTransportDomain description contains and extraneous quote after snmpDTLSSCTPDomain. + DONE delete 'handle/' from tmStateReference description. 5590 consistenly uses 'reference'. * DONE section 4.3.2 + DONE destTransportDomain description contains and extraneous quote after snmpDTLSSCTPDomain. + DONE "incomingMessage: The whole SNMP message after being processed by (D)TLS and removed of the (D)TLS transport layer data." "removed of the" isn't grammatically correct. reword. + DONE delete 'handle/' from tmStateReference description. 5590 consistenly uses 'reference'. * DONE section 5, paragraph 2, "...should be overwritten appropriately first prior..." is awkward... delete 'first'. * DONE 5.1.1 + DONE 5.1.1 nitpick?. "When establishing a new session implementations MUST use a different UDP source port number for each connection to a remote destination IP- address/port-number combination".. this implies that UDP source ports can't be reused once a session is closed. maybe say '... for each active connection ...'? I haven't seen anything yet about closing sessions - is that an explicit action? i.e. if the client must/should close a session, then the server should know when a packet from the same source port is a new session.. + WH: added "active"; good suggestion, thanks. + WONTDO paragraph 2 "... although any implementation-dependent method should be suitable as long as the results are deterministic." is a bit wishy-wash. seems like there should be a MUST there (e.g results MUST be deterministic). + WH: I'd need a specific proposal. + WONTDO step 2) first paragraph: "to determine if a session already exists and its tlstmSessionID." is awkward. "to determine the tlstmSessionID of an existing session." or " to determine if a session already exists, and if so, to retrieve its tlstmSessionID." + WH: actually, it was truncated because someone else pointed out that the sessionID extraction already appears below. + WONTDO second paragraph: "If DTLS returns success then stop processing of this message. If DTLS returns an error then increment the snmpTlstmSessionNoSessions counter and stop processing the message." I'm confused by the 'stop processing of this message' in BOTH cases. Shouldn't success continue processing? I'd think that success meant that a new tlstmSessionID would now be in the LCD for use in step 3. + WH: No, actually it should stop either way. If we didn't have a tlstmSessionID then there won't be a SNMP message to act on after this step. + WONTDO Note: maybe section 5.3 on establishing a session should be moved before processing incoming and outgoing messages? seems like it'd be less confusing. + WH: Actually, no... It's historical. 5592 does it in that order so we're mirroring it. + DONE third paragraph: "Note that an entry would already exist if the client and server's session establishment procedures had been successfully completed previously (as described both above and in Section 5.3)" I note that section 5.3 makes no mention of putting anything in the LCD. + WH: Good point. Added: The tlstmSessionID is also stored in the LCD for later lookup during processing of incoming messages (). * DONE 5.2 + WONTDO step 5; "..suitable to send the message over." seems awkward. I'd just end the sentence with "... if there is a corresponding entry in the LCD." + WH: while I agree it may be a bit awkward, it think it's important to leave the concept of "suitable" in since it reminds the reader that authNoPriv messages can go over an authPriv channel. + DONE step 5 has sub-steps 4a and 4b. Probably should be 5a and 5b. + DONE step 5b (aka step 4b) typo "tmStateReferenc" -> "tmStateReference" + DONE step 6 references a tmSessionID 'resulting from a previous step (3 or 4)", I think a step was added, and this should be step 4 or 5. * WONTDO 5.3, step 3b. paragraph 3: "If the connection is being established for other reasons then configuration and procedures outside the scope of this document should be followed." I'm not clear on what 'other reasons' means, since there haven't been any reasons mentioned yet. + WH: the TARGET-MIB was the reason mentioned. Other reasons would be a non TARGET-MIB based instance (ie, snmpget ...). You should take the configuration given to you from the command line options here. * DONE one where you seem to be violating the requirements of a referenced draft: "tlstmAddrServerIdentity mentions wildcards for domain names, but the specified reference [draft-saintandre-tls-server-id-check] specifically states that 'in the case of domain names, the reference identity MUST NOT contain the wildcard character ...' (section 2, conventions)." + WH: Yep; this has been changed. one that makes me think working is wrong or additional counters are needed: * WONTDO snmpTlstmSession(Opens|Closes) both qualify themselves with 'as an (D)TLS client'. To me, this implies that Opens/Closes counters are only incremented when originating a message. I was expecting to find later counters for a (D)TLS server, to count Opens/Closes for incoming connections to a server. There is snmpTlstmSessionInvalidClientCertificates for failed (D)TLS server sessions, but nothing for successful connections. + WH: The complexities of detecting server side connections are difficult (see the list discussion). Client side is much easier, and although it would be helpful it has been decided by the WG both previously and recently that only the client side connections could be easily counted. * DONE snmpDTLSUDPDomain description uses 'dudp' as the prefix, but the second rfc ed note says "replace 'dudp' ... if 'dtls' is not assigned..." suspect 'dtls' should be 'dudp' * DONE snmpDTLSSCTPDomain description uses 'dsct' as the prefix, but the second rfc ed note says "replace 'dsct' ... if 'dtls' is not assigned..." suspect 'dtls' should be 'dudp' + WH: you meant 'dsct', but done. * DONE tlstmIdentities.* could use a comment block to state that these 'Identities' are actually identity types to be used in the tlstmCertToTSNTable. Personally, I would have used an enum for the various types, instead of a long OID string. + WH: the OID solution was based on working group consensus in order to allow for easy future extensibility. This is necessary to support 3rd-party definitions of otherName subjectAltName mappings. Comment added though: -- Identities for use in the tlstmCertToTSNTable * DONE tlstmCertSANRFC822Name typo in example ("... is mapped to tmSecurityName: FooBar@exmaple.com" (s/exmap/examp/). * DONE tlstmCertSANAny: "... certificate any of the above types .." should probably be "... certificate _of_ any of the above types ..." * DONE snmpTlstmSessionUnknownServerCertificate: "... to known certificate authority." should be "... to _a_ knowns certificate authority." * DONE snmpTlstmSessionInvalidServerCertificates: any real reason to mention 'cryptographic validation' twice?. suggest striking "even if the fingerprint or expected validation path was known. I.E., a cryptographic validation occurred during certificate validation processing." + because there is other types of certificate processing, I think it's necessary to say this counts validation processing. * DONE tlstmAddrTable + DONE : "... expect when establishing a new (D)TLS connections." should either be 'establishing a new .. connection.' or 'establishing new .. connections.' (number agreement) + WH: this text was largely rewritten (by Tom) and doesn't contain that issue any longer. + DONE this object is the first use of 'trust anchor' in the document. the rest of the document (including earlier in this object) use something like 'certificate validation path'. + WH: changed to the following, which completely removes the only instance of "trust anchor" in the document. tlstmAddrEntry changed as well. If there is no row in this table corresponding to an entry in the SNMP-TARGET-MIB and another certificate validation path algorithm (such as the path validation procedures defined in [RFC5280]) can be used, then the connection SHOULD still proceed." * DONE tlstmServerCertificateUnknown: "...this may result because..." is awkward, if not outright wrong. mabye "... this may be because...". * DONE section 9 'RECOMMENDEDs' (RECOMMENDs?) 'that implementers also support this cookie exchange, but 3.1.1 items 5 sates that "DTLS Transport Model server implementations MUST support DTLS cookies." + Changed to talk about the users and changed the text so the 2119 keywords work: 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. * WONTDO 9.3, "Even if the network itself is secure (for example by using IPsec), even then,", suggest deleting second use of even ('even then'). + WH: This is copied from 5592. Every time I've tried to fix text that was copied from the sibling document I've gotten in trouble ;-) -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Mon Jan 25 14:38:41 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A823A67D7 for ; Mon, 25 Jan 2010 14:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 zlTXfrQ1x2Fp for ; Mon, 25 Jan 2010 14:38:40 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 753EB3A684D for ; Mon, 25 Jan 2010 14:38:40 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o0PMcQWX014745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 17:38:26 -0500 (EST) Date: Mon, 25 Jan 2010 17:38:25 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: In-Reply-To: <12458_1264456385_o0PLr4dU016131_sdvdep6edf.fsf@wjh.hardakers.net> References: <20100125213740.GA50176@elstar.local> <04c101ca9e08$2177b260$0600a8c0@china.huawei.com> <12458_1264456385_o0PLr4dU016131_sdvdep6edf.fsf@wjh.hardakers.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] TLSTM counters issue 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, 25 Jan 2010 22:38:41 -0000 --On Monday, January 25, 2010 01:53:00 PM -0800 Wes Hardaker wrote: >>>>>> On Mon, 25 Jan 2010 16:48:28 -0500, "David Harrington" >>>>>> said: > > DH> in SSHTM, the open sessions counter is incremented before any open > DH> processing actually occurs; it counts the number of times the > DH> openSession ASI is called. > > Thanks; that makes sense. > > And in light of that and in Juergen's analysis I have to agree with the > way it was done in SSHTM. I'm not sure how possible it is (in all > implementations) to determine when a successful (D)TLS negotiation has > succeeded and thus the server side counters may be impossible to detect > without specific state tracking looking for the first SNMP packet to > traverse a connection and counting the "firsts". And I don't think > that's worth it. Thinking about this a bit, I agree. The counters we have in the transport mapping are about the ASI's in the transport mapping. Defining MIB's for SSH and for (D)TLS, whereever they are used, is a separate project. -- Jeff From Robert.Story@cobham.com Tue Jan 26 05:23: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 2A0603A6359 for ; Tue, 26 Jan 2010 05:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HvNPO8rUGZfm for ; Tue, 26 Jan 2010 05:23:18 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0A0573A672F for ; Tue, 26 Jan 2010 05:23:17 -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 o0QDNPfS014682; Tue, 26 Jan 2010 07:23:25 -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 o0QDNOWb024706; Tue, 26 Jan 2010 07:23:24 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 08:23:23 -0500 Date: Tue, 26 Jan 2010 08:23:10 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100126082310.47565917@sparta.com> In-Reply-To: <20100125213740.GA50176@elstar.local> References: <20100125213740.GA50176@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/BAtPeQr4gOS.j4lXKyg/Tab"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 26 Jan 2010 13:23:24.0085 (UTC) FILETIME=[BCA16650:01CA9E8A] Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 13:23:19 -0000 --Sig_/BAtPeQr4gOS.j4lXKyg/Tab Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 25 Jan 2010 22:37:40 +0100 Juergen wrote: JS> > The new counters, if desired, would be: JS> >=20 JS> > snmpTlstmSessionServerOpens OBJECT-TYPE JS> > SYNTAX Counter32 JS> > MAX-ACCESS read-only JS> > STATUS current JS> > DESCRIPTION "The number of times a (D)TLS session has been JS> > successfully established on a (D)TLS server. JS> > " JS> > ::=3D { snmpTlstmSession N } JS>=20 JS> It is not clear to me whether this includes successful (D)TLS JS> exchanges and if so which ones. How deep do I have to peek into (D)TLS JS> to implement this counter? I don't think we need to peek very far at all. We already have a requirement (in section 5.1.2) for a tmSessionID "which MUST be a unique session identifier for this (D)TLS connection." Seems like whenever we create this new session identifier would be a good time to increment the counter. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/BAtPeQr4gOS.j4lXKyg/Tab Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkte7MMACgkQ7/fVLLY1mnjt1gCdEmIXonGVvC1AUDPdckTM9meH xJMAnj6y2xAGtcNZcAdmeq+t112w5Eri =7BbJ -----END PGP SIGNATURE----- --Sig_/BAtPeQr4gOS.j4lXKyg/Tab-- From Robert.Story@cobham.com Tue Jan 26 05:37: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 9EBF83A67BD for ; Tue, 26 Jan 2010 05:37:39 -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 n7kmfazw4k0Y for ; Tue, 26 Jan 2010 05:37:38 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C4FEF3A6359 for ; Tue, 26 Jan 2010 05:37:38 -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 o0QDblFT014831; Tue, 26 Jan 2010 07:37:47 -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 o0QDblEx025154; Tue, 26 Jan 2010 07:37:47 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 08:37:47 -0500 Date: Tue, 26 Jan 2010 08:37:35 -0500 From: Robert Story To: Wes Hardaker Message-ID: <20100126083735.616f8688@sparta.com> In-Reply-To: References: <20100125213740.GA50176@elstar.local> <04c101ca9e08$2177b260$0600a8c0@china.huawei.com> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/z+/hT14DlXENFd7fO8kDA.T"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 26 Jan 2010 13:37:47.0204 (UTC) FILETIME=[BF16E840:01CA9E8C] Cc: isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 13:37:39 -0000 --Sig_/z+/hT14DlXENFd7fO8kDA.T Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 25 Jan 2010 13:53:00 -0800 Wes wrote: WH> I'm not sure how possible it is (in all WH> implementations) to determine when a successful (D)TLS negotiation has WH> succeeded But it isn't a (D)TLS negotiation counter, it's a snmpTlstmSession counter, A unique tmSessionID must be created for each session, so I think that's a nice clean place to increment the counter. If we want to complain about having to peek inside (D)TLS processing, I'd be more worried about tlstmTLSProtectionErrors, which is _explicitly_ defined as counting (D)TLS processing errors. All the other counters are about tlstmSessions. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/z+/hT14DlXENFd7fO8kDA.T Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkte8CMACgkQ7/fVLLY1mnhP2ACcCIVEf0UMxHP9sjw2D84i17qs TUQAnAv7XN/qHGpARAKAwHdZyh4SCv8D =2YsG -----END PGP SIGNATURE----- --Sig_/z+/hT14DlXENFd7fO8kDA.T-- From j.schoenwaelder@jacobs-university.de Tue Jan 26 05:43: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 A26DF3A6909 for ; Tue, 26 Jan 2010 05:43:27 -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 2bj-St8NpSCG for ; Tue, 26 Jan 2010 05:43:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 95ACB3A680D for ; Tue, 26 Jan 2010 05:43:26 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EC39C0034; Tue, 26 Jan 2010 14:43:36 +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 PeZQtx28IbDu; Tue, 26 Jan 2010 14:43:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CADDFC0039; Tue, 26 Jan 2010 14:43:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1DEEF10138B9; Tue, 26 Jan 2010 14:43:24 +0100 (CET) Date: Tue, 26 Jan 2010 14:43:24 +0100 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100126134324.GA54185@elstar.local> Mail-Followup-To: Robert Story , Wes Hardaker , "isms@ietf.org" References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100126082310.47565917@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 13:43:27 -0000 On Tue, Jan 26, 2010 at 02:23:10PM +0100, Robert Story wrote: > On Mon, 25 Jan 2010 22:37:40 +0100 Juergen wrote: > JS> > The new counters, if desired, would be: > JS> > > JS> > snmpTlstmSessionServerOpens OBJECT-TYPE > JS> > SYNTAX Counter32 > JS> > MAX-ACCESS read-only > JS> > STATUS current > JS> > DESCRIPTION "The number of times a (D)TLS session has been > JS> > successfully established on a (D)TLS server. > JS> > " > JS> > ::= { snmpTlstmSession N } > JS> > JS> It is not clear to me whether this includes successful (D)TLS > JS> exchanges and if so which ones. How deep do I have to peek into (D)TLS > JS> to implement this counter? > > I don't think we need to peek very far at all. We already have a > requirement (in section 5.1.2) for a tmSessionID "which MUST be a > unique session identifier for this (D)TLS connection." Seems like > whenever we create this new session identifier would be a good time to > increment the counter. The description is at least ambiguous. So when do you think this counter is incremented? Straight after the TCP layer accept()? At least then the name would be confusing... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Robert.Story@cobham.com Tue Jan 26 06:45:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7153A6819 for ; Tue, 26 Jan 2010 06:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7vkagulk-CR8 for ; Tue, 26 Jan 2010 06:45:44 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 98F523A688B for ; Tue, 26 Jan 2010 06:45:44 -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 o0QEjqm2015822; Tue, 26 Jan 2010 08:45:52 -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 o0QEjrJZ028278; Tue, 26 Jan 2010 08:45:53 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 09:45:52 -0500 Date: Tue, 26 Jan 2010 09:45:44 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100126094544.4677fd47@sparta.com> In-Reply-To: <20100126134324.GA54185@elstar.local> References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/OUd9wNW3dKPYcSqk8y0S7d4"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 26 Jan 2010 14:45:52.0513 (UTC) FILETIME=[421F9710:01CA9E96] Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 14:45:45 -0000 --Sig_/OUd9wNW3dKPYcSqk8y0S7d4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 26 Jan 2010 14:43:24 +0100 Juergen wrote: JS> > I don't think we need to peek very far at all. We already have a JS> > requirement (in section 5.1.2) for a tmSessionID "which MUST be a JS> > unique session identifier for this (D)TLS connection." Seems like JS> > whenever we create this new session identifier would be a good time to JS> > increment the counter. JS>=20 JS> The description is at least ambiguous. So when do you think this JS> counter is incremented? Straight after the TCP layer accept()? I don't think so. This is a TlstmSession counter, not a TLS counter.=20 We don't have an implementation for TLS yet, but looking at Wes' "proof of concept" code for UDP, I find a comment: /* if we don't have a cachep for this connection then we're receiving something new and are the server side */ which looks like a good place to set a flags (say, newConnection). A little further down in the code, after the SSL read is ok (which I think means the certificate was validated), the counter could be incremented if newConnection was set. And if the SSL read failed, I'd increment the (non-existent-but-I-think-we-should-add) snmpTlstmSessionServerOpenErrors counter. As I said in my earlier messages, section 5.1.2 says we have to create a tmStateReference and have a unique session id. Wherever that code is would be a logical place to increment a session open counter. I seem to be fighting a losing battle, though, so unless someone else sees the light and speaks up, I'll defer to the group wisdom. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/OUd9wNW3dKPYcSqk8y0S7d4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAktfABsACgkQ7/fVLLY1mnhQ2ACaA3vkZM7LYxemnqL/6vRPyBQ1 o3MAn2tFTOykKLYL3UvdhELtben0UyPP =HTKb -----END PGP SIGNATURE----- --Sig_/OUd9wNW3dKPYcSqk8y0S7d4-- From j.schoenwaelder@jacobs-university.de Tue Jan 26 07:01: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 D97873A6803 for ; Tue, 26 Jan 2010 07:01:53 -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 AQw4KTfi8lFq for ; Tue, 26 Jan 2010 07:01:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6B983A67A1 for ; Tue, 26 Jan 2010 07:01:52 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C6DFC0040; Tue, 26 Jan 2010 16:02:02 +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 jljdzfqfOgZY; Tue, 26 Jan 2010 16:02:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88659C0034; Tue, 26 Jan 2010 16:02:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0D2D1013DB1; Tue, 26 Jan 2010 16:01:51 +0100 (CET) Date: Tue, 26 Jan 2010 16:01:51 +0100 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100126150151.GB54456@elstar.local> Mail-Followup-To: Robert Story , Wes Hardaker , "isms@ietf.org" References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100126094544.4677fd47@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 15:01:53 -0000 On Tue, Jan 26, 2010 at 03:45:44PM +0100, Robert Story wrote: > As I said in my earlier messages, section 5.1.2 says we have to create a > tmStateReference and have a unique session id. Wherever that code is > would be a logical place to increment a session open counter. > > I seem to be fighting a losing battle, though, so unless someone else > sees the light and speaks up, I'll defer to the group wisdom. Robert, the counter needs to have clear semantics spelled out in the DESCRIPTION clause and without references to source code of one particular implementation. This means we need to agree at which stage of the processing this counter is incremented - otherwise implementations will end up counting different things. It will matter to people if some implementations simply count TCP accepts while others count successful TLS certificate exchanges and validations while others count something in between. /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 Jan 26 07:09: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 99F153A68CC for ; Tue, 26 Jan 2010 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OTf3CDL18bDI for ; Tue, 26 Jan 2010 07:09:54 -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 B43DD3A688C for ; Tue, 26 Jan 2010 07:09:54 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id EB1749A359; Tue, 26 Jan 2010 07:10:03 -0800 (PST) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100125213740.GA50176@elstar.local> <04c101ca9e08$2177b260$0600a8c0@china.huawei.com> <20100126083735.616f8688@sparta.com> Date: Tue, 26 Jan 2010 07:10:03 -0800 In-Reply-To: <20100126083735.616f8688@sparta.com> (Robert Story's message of "Tue, 26 Jan 2010 08:37:35 -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] TLSTM counters issue 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, 26 Jan 2010 15:09:55 -0000 >>>>> On Tue, 26 Jan 2010 08:37:35 -0500, Robert Story said: RS> If we want to complain about having to peek inside (D)TLS processing, RS> I'd be more worried about tlstmTLSProtectionErrors, which is RS> _explicitly_ defined as counting (D)TLS processing errors. All the RS> other counters are about tlstmSessions. That's a good point. Maybe we should remove that one since I agree it's somewhat over the line of where we should be looking. In the end, I think these sorts of counters are very useful. But they probably belong in a separate MIB devoted exclusively to TLS and would contain many more counters for tracking individual issues. (e.g. "number of configured CA certificates" and "unable to successfully negotiate algorithms" and ...) -- Wes Hardaker Cobham Analytic Solutions From Robert.Story@cobham.com Tue Jan 26 08:11: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 07A583A695A for ; Tue, 26 Jan 2010 08:11:53 -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 VnMZTfn-YbSe for ; Tue, 26 Jan 2010 08:11:49 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D38EA3A694F for ; Tue, 26 Jan 2010 08:11:48 -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 o0QGBv6G017427; Tue, 26 Jan 2010 10:11:57 -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 o0QGBv6j000747; Tue, 26 Jan 2010 10:11:57 -0600 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 11:11:57 -0500 Date: Tue, 26 Jan 2010 11:11:48 -0500 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100126111148.586f5228@sparta.com> In-Reply-To: <20100126150151.GB54456@elstar.local> References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.3 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/DmW0HRthPmaUhHateGNPJge"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-OriginalArrivalTime: 26 Jan 2010 16:11:57.0308 (UTC) FILETIME=[4894C3C0:01CA9EA2] Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 26 Jan 2010 16:11:53 -0000 --Sig_/DmW0HRthPmaUhHateGNPJge Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 26 Jan 2010 16:01:51 +0100 Juergen wrote: JS> the counter needs to have clear semantics spelled out in the JS> DESCRIPTION clause and without references to source code of one JS> particular implementation. This means we need to agree at which stage JS> of the processing this counter is incremented [...] Section 5.1.2 says [...] These steps describe the processing of a singular SNMP message after it has been delivered from the (D)TLS stream. Create a tmStateReference cache for the subsequent reference and assign the following values within it: That seems like a nice clear place. When you create the tmStateReference cache for the first SNMP message received over a new session, increment the counter. Alternatively, Section 5.3 would also work, by appending "Increment the snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the appropriate counter (snmpTlstmSessionClientOpens or snmpTlstmSessionServerOpens)" to step 4. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/DmW0HRthPmaUhHateGNPJge Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEUEARECAAYFAktfFEoACgkQ7/fVLLY1mnjraACeJHkUDcBkpEaiCMVTC8CPK+I0 isEAmJEhhQqiuEzGC5BDRlm60sI9SZI= =JCDA -----END PGP SIGNATURE----- --Sig_/DmW0HRthPmaUhHateGNPJge-- From cfinss@dial.pipex.com Tue Jan 26 08:59:01 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E373A67CC for ; Tue, 26 Jan 2010 08:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xN7DGJ-nAKe for ; Tue, 26 Jan 2010 08:59:00 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 2338C3A67B6 for ; Tue, 26 Jan 2010 08:58:59 -0800 (PST) X-Trace: 176600766/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.239/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.239 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: AtIFAJquXks+vGnv/2dsb2JhbACCUS6FKYkAyXkJhDAE X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="176600766" X-IP-Direction: IN Received: from 1cust239.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.239]) by smtp.pipex.tiscali.co.uk with SMTP; 26 Jan 2010 16:59:08 +0000 Message-ID: <012901ca9ea0$757d91c0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <006901ca9459$dabb7940$0601a8c0@allison> Date: Tue, 26 Jan 2010 16:57:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms Subject: Re: [Isms] TLSTM -05 Yet more bits of MIB module 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: Tue, 26 Jan 2010 16:59:01 -0000 Good stuff. Doubtless the table of contents will reflect the change of heading for C.1 but there is another notification generator in s.3.3 para 2 that I am not sure if any of us have mentioned. And should the reference for Fingerprint ::= TEXTUAL-CONVENTION be to the IANA registry as at http://www.iana.org/assignments/tls-parameters/tls-parameters.txt (rather than the RFC5246 that provided the initial contents? In the long run, the two will diverge. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Juergen Schoenwaelder" ; "Wes Hardaker" ; "isms" Sent: Monday, January 25, 2010 10:58 PM Subject: Re: TLSTM -05 Yet more bits of MIB module > > My responses are prefixed below with "WH:" if you want to search for > them. The status of each item is as follows: > > DONE: Suggestion was acted on > WONTDO: Nothing was done; refer to the WH: response for reasons why > DISCUSS: There is an outstanding question back to you > ANSWERED: A question was answered but had no action resulting from it > > 1 DONE Appendix C. Target and /Notificaton/Notification/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2 DONE C.1. Configuring the Notification /Generator/Originator/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 3 DONE For notification /generators/originators/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 4 DONE The certificate that the notification /generator/originator/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > Wes Hardaker > Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jan 26 09:06:02 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A8B3A67D9 for ; Tue, 26 Jan 2010 09:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJBQ6ltXxlsD for ; Tue, 26 Jan 2010 09:06:01 -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 2EF533A63EC for ; Tue, 26 Jan 2010 09:06:01 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 816659A48B; Tue, 26 Jan 2010 09:06:11 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <006901ca9459$dabb7940$0601a8c0@allison> <012901ca9ea0$757d91c0$0601a8c0@allison> Date: Tue, 26 Jan 2010 09:06:11 -0800 In-Reply-To: <012901ca9ea0$757d91c0$0601a8c0@allison> (tom petch's message of "Tue, 26 Jan 2010 16:57:17 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms Subject: Re: [Isms] TLSTM -05 Yet more bits of MIB module 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, 26 Jan 2010 17:06:02 -0000 >>>>> On Tue, 26 Jan 2010 16:57:17 +0100, "tom.petch" said: tp> Doubtless the table of contents will reflect the change of heading Automatically, yes. tp> for C.1 but there is another notification generator in s.3.3 para 2 tp> that I am not sure if any of us have mentioned. Yep. Thanks. tp> And should the reference for Fingerprint ::= TEXTUAL-CONVENTION be tp> to the IANA registry as at tp> http://www.iana.org/assignments/tls-parameters/tls-parameters.txt tp> (rather than the RFC5246 that provided the initial contents? In the tp> long run, the two will diverge. I've added http://www.iana.org/assignments/tls-parameters/ as a reference in addition to (instead of replacing) the reference to 5246. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Jan 27 03:50:30 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970CE3A6A58 for ; Wed, 27 Jan 2010 03:50:30 -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 g2ygQ6wpl23x for ; Wed, 27 Jan 2010 03:50:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 89DC73A6A61 for ; Wed, 27 Jan 2010 03:50:29 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B3F5C0013; Wed, 27 Jan 2010 12:50:43 +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 PspInFPW4p8M; Wed, 27 Jan 2010 12:50:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C282FC0007; Wed, 27 Jan 2010 12:50:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE07C101D1FA; Wed, 27 Jan 2010 12:50:31 +0100 (CET) Date: Wed, 27 Jan 2010 12:50:31 +0100 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100127115031.GA90288@elstar.local> Mail-Followup-To: Robert Story , Wes Hardaker , "isms@ietf.org" References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100126111148.586f5228@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 11:50:30 -0000 On Tue, Jan 26, 2010 at 05:11:48PM +0100, Robert Story wrote: > On Tue, 26 Jan 2010 16:01:51 +0100 Juergen wrote: > JS> the counter needs to have clear semantics spelled out in the > JS> DESCRIPTION clause and without references to source code of one > JS> particular implementation. This means we need to agree at which stage > JS> of the processing this counter is incremented [...] > > Section 5.1.2 says > > [...] These steps describe the processing of a > singular SNMP message after it has been delivered from the (D)TLS > stream. > > Create a tmStateReference cache for the subsequent reference and > assign the following values within it: > > That seems like a nice clear place. When you create the tmStateReference > cache for the first SNMP message received over a new session, increment > the counter. > > Alternatively, Section 5.3 would also work, by appending "Increment the > snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the > appropriate counter (snmpTlstmSessionClientOpens or > snmpTlstmSessionServerOpens)" to step 4. OK. Adding explicit text to the EoP would make it clear what is being counted. /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 Wed Jan 27 07:22:41 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5903A695E for ; Wed, 27 Jan 2010 07:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 slNgC9ISKPfE for ; Wed, 27 Jan 2010 07:22:40 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 6EAAF3A6A5C for ; Wed, 27 Jan 2010 07:22:40 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 870749AC25; Wed, 27 Jan 2010 07:22:54 -0800 (PST) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100125213740.GA50176@elstar.local> <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> Date: Wed, 27 Jan 2010 07:22:53 -0800 In-Reply-To: <20100127115031.GA90288@elstar.local> (Juergen Schoenwaelder's message of "Wed, 27 Jan 2010 12:50: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] TLSTM counters issue 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, 27 Jan 2010 15:22:41 -0000 >>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen Schoenwaelder said: >> Alternatively, Section 5.3 would also work, by appending "Increment the >> snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the >> appropriate counter (snmpTlstmSessionClientOpens or >> snmpTlstmSessionServerOpens)" to step 4. JS> OK. Adding explicit text to the EoP would make it clear what is being JS> counted. The opinions still seem to be split on this issue. Other opinions or confirmations that this shouldn't be done would be good to help me determine on which side of the issue the WG currently relies. It appears at this time: For adding server counters: Robert S Juergen S? Against: David H Jeffrey H Ambivalent: Me. Sort of. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed Jan 27 08:21:59 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 456783A6359 for ; Wed, 27 Jan 2010 08:21:59 -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 mEZoxhm4V9SO for ; Wed, 27 Jan 2010 08:21:56 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 557513A6965 for ; Wed, 27 Jan 2010 08:21:54 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id afTm1d00316LCl05BgNAdg; Wed, 27 Jan 2010 16:22:10 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta06.westchester.pa.mail.comcast.net with comcast id agN91d00R284sdk3SgN9Ng; Wed, 27 Jan 2010 16:22:10 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'Robert Story'" References: <20100125213740.GA50176@elstar.local><20100126082310.47565917@sparta.com><20100126134324.GA54185@elstar.local><20100126094544.4677fd47@sparta.com><20100126150151.GB54456@elstar.local><20100126111148.586f5228@sparta.com><20100127115031.GA90288@elstar.local> Date: Wed, 27 Jan 2010 11:22:08 -0500 Message-ID: <060601ca9f6c$dfb84400$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: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqfZJw42fggndfxRImfj0Xx0akAqgAAx6ng Cc: isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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, 27 Jan 2010 16:21:59 -0000 Hi, The only comment I have made on this issue is to point out where in the EOP the counter gets incremented in SSTM. It does this before actually entering the SSH open session processing. It just counts the number of times the OpenSession ASI is called. I have no issue with having server open/close counters as long as the counters are tracking ASI usage, and have no specific knowledge of the (D)TLS internal processing. I can see that it could be useful information. What I heard Jeff saying is that he agrees with that position - count the ASI calls, but not the (D)TLS internal processing. So you can put me in the For group - if we can increment it based on TLSTM EOP location and not tls implementation details. Then we can talk about the specifics of where to increment the counters. I would prefer that the SSHTM counters and TLSTM counters be parallel in meaning, so operators don't need to interpret sshtm opensession counters differently than they interpret tlstm opensession counters. So incrementing the client open counter should be the first thing done in the (client) opensession EOP. it is important to make sure the counters count the same things, so the counter in DTLSTM should be placed to count the same things - making sure any "abort" situations for sshtm that are handled after incrementing the counter happen in the same relative sequence in tlstm, as much as makes protocol sense. If I were doing this in sshtm, I think I would have tried to place this at the point where a new server-side sessionID was assigned (5.1 4), or at a new 5.1 5 - at the point where the receiveMessage ASI is being called, and the message is passing from the TM to the dispatcher. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, January 27, 2010 10:23 AM > To: Robert Story > Cc: isms@ietf.org > Subject: Re: [Isms] TLSTM counters issue > > >>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen > Schoenwaelder said: > > >> Alternatively, Section 5.3 would also work, by appending > "Increment the > >> snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the > >> appropriate counter (snmpTlstmSessionClientOpens or > >> snmpTlstmSessionServerOpens)" to step 4. > > JS> OK. Adding explicit text to the EoP would make it clear > what is being > JS> counted. > > The opinions still seem to be split on this issue. Other opinions or > confirmations that this shouldn't be done would be good to help me > determine on which side of the issue the WG currently relies. It > appears at this time: > > For adding server counters: > Robert S > Juergen S? > > Against: > David H > Jeffrey H > > Ambivalent: > Me. Sort of. > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From cfinss@dial.pipex.com Wed Jan 27 10:19:17 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D5A3A67D3 for ; Wed, 27 Jan 2010 10:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 BluKqT-U0KKv for ; Wed, 27 Jan 2010 10:19:16 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 5E0873A681F for ; Wed, 27 Jan 2010 10:19:16 -0800 (PST) X-Trace: 177019771/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.54/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.54 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: Al8GAOUSYEs+vBE2/2dsb2JhbACCLYVOiQfIYgqELwQ X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="177019771" X-IP-Direction: IN Received: from 1cust54.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.54]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jan 2010 18:19:29 +0000 Message-ID: <007401ca9f74$d8a51280$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Juergen Schoenwaelder" References: <20100125213740.GA50176@elstar.local><20100126082310.47565917@sparta.com><20100126134324.GA54185@elstar.local><20100126094544.4677fd47@sparta.com><20100126150151.GB54456@elstar.local><20100126111148.586f5228@sparta.com><20100127115031.GA90288@elstar.local> Date: Wed, 27 Jan 2010 17:07:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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: Wed, 27 Jan 2010 18:19:17 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Wednesday, January 27, 2010 4:22 PM > >>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen Schoenwaelder said: > > >> Alternatively, Section 5.3 would also work, by appending "Increment the > >> snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the > >> appropriate counter (snmpTlstmSessionClientOpens or > >> snmpTlstmSessionServerOpens)" to step 4. > > JS> OK. Adding explicit text to the EoP would make it clear what is being > JS> counted. > > The opinions still seem to be split on this issue. Other opinions or > confirmations that this shouldn't be done would be good to help me > determine on which side of the issue the WG currently relies. It > appears at this time: > > For adding server counters: > Robert S > Juergen S? > > Against: > David H > Jeffrey H Against Tom Petch (I agree with Jeff's summary) > > Ambivalent: > Me. Sort of. > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From jhutz@cmu.edu Wed Jan 27 10:44:30 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8383A3A6927 for ; Wed, 27 Jan 2010 10:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 vDcJCB+0NAQ7 for ; Wed, 27 Jan 2010 10:44:29 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id B4FC03A68AF for ; Wed, 27 Jan 2010 10:44:29 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o0RIiWcg001866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 13:44:32 -0500 (EST) Date: Wed, 27 Jan 2010 13:44:32 -0500 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" , "'Robert Story'" Message-ID: In-Reply-To: <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> References: <20100125213740.GA50176@elstar.local><20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local><20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local><20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] TLSTM counters issue 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, 27 Jan 2010 18:44:30 -0000 --On Wednesday, January 27, 2010 11:22:08 AM -0500 David Harrington wrote: > I have no issue with having server open/close counters as long as the > counters are tracking ASI usage, and have no specific knowledge of the > (D)TLS internal processing. I can see that it could be useful > information. > > What I heard Jeff saying is that he agrees with that position - count > the ASI calls, but not the (D)TLS internal processing. Yes, pretty much, But see below. > I would prefer that the SSHTM counters and TLSTM counters be parallel > in meaning, so operators don't need to interpret sshtm opensession > counters differently than they interpret tlstm opensession counters. Me too. That means one thing we should _not_ have is a single counter that includes both incoming and outgoing connections, because SSHTM doesn't do that. However, I'm not opposed to counting them both, separately, subject to the same concerns David discusses. -- Jeff From blueroofmusic@gmail.com Wed Jan 27 14:14: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 C0B2C3A67A4 for ; Wed, 27 Jan 2010 14:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 YWH6Rkndgc+3 for ; Wed, 27 Jan 2010 14:14:43 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 68E3F3A680C for ; Wed, 27 Jan 2010 14:14:43 -0800 (PST) Received: by fxm7 with SMTP id 7so59736fxm.28 for ; Wed, 27 Jan 2010 14:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HIzCeTjrtOz7ASsmdgssDkvQTw8HicUdRs4GZYT5uxo=; b=H9sJyOuI/c156PoUkKhRhmSzTo+Bb1Ys5eyqh5zwDY+DpwgRxQ9lhELX5O8BT4/Zo3 V8OEkwv9qMoutbIJr7f2sZeCJQMldiBVXa3yRX1Sp7EVSz/fprkQk1fDGRZ0W30NSMGF yYDkPn7v+Vtnjt//K7b9lmndpCX0bt1muwaUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o0C5Yq59IoxPZ7u4C4oUZpqueg4M9LliTmH3sRIq+QKc86scj2EFBz6bD8r3Be80r+ /cYFh3Zo/YzpVAQ4DQ0336Z2WbPVcCP2b2Ck+WkBLVfD0okqm12o4nLw8kgnfSxdvYPR AHEMaeWD++6gQbDSfzDLR8O7Vwu4Pj3Q6X5Qc= MIME-Version: 1.0 Received: by 10.223.76.141 with SMTP id c13mr719687fak.31.1264630495108; Wed, 27 Jan 2010 14:14:55 -0800 (PST) In-Reply-To: References: <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> Date: Wed, 27 Jan 2010 17:14:54 -0500 Message-ID: From: Ira McDonald To: Jeffrey Hutzelman , Ira McDonald Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Story , isms@ietf.org Subject: Re: [Isms] TLSTM counters issue 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, 27 Jan 2010 22:14:44 -0000 Hi, I agree that having separate client and server session counters is desirable and that they should be based on ASI invocations and NOT on peeking at the internals of TLS or SSH. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 From wjhns1@hardakers.net Wed Jan 27 14:51:13 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA673A69EE for ; Wed, 27 Jan 2010 14:51:13 -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 KXj2MbLdltGW for ; Wed, 27 Jan 2010 14:51:13 -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 040AC3A679C for ; Wed, 27 Jan 2010 14:51:12 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 2E61D9AD24; Wed, 27 Jan 2010 14:51:28 -0800 (PST) From: Wes Hardaker To: Ira McDonald Organization: Sparta References: <20100126082310.47565917@sparta.com> <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> Date: Wed, 27 Jan 2010 14:51:26 -0800 In-Reply-To: (Ira McDonald's message of "Wed, 27 Jan 2010 17:14:54 -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: Robert Story , isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] TLSTM counters issue 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, 27 Jan 2010 22:51:13 -0000 >>>>> On Wed, 27 Jan 2010 17:14:54 -0500, Ira McDonald said: IM> I agree that having separate client and server IM> session counters is desirable and that they IM> should be based on ASI invocations and NOT IM> on peeking at the internals of TLS or SSH. Ok, I think there is now plenty of consensus to add them. So here's what I'm gonna do: 1) publish -06 without them. 2) publish -07 with them to clearly show what was done via diffs I think there may be a problem deciding when the closed ASI is called as a server or a client, but I need to go dive in to the text to see if there is a good place to delineate that. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Jan 27 15:28: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 5F8A33A68D5 for ; Wed, 27 Jan 2010 15:28:37 -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=[AWL=0.000, 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 qKHynlO+zezG for ; Wed, 27 Jan 2010 15:28:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5562D3A67D7 for ; Wed, 27 Jan 2010 15:28:35 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF958C0022; Thu, 28 Jan 2010 00:28: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 dDUQM1r-KGsH; Thu, 28 Jan 2010 00:28: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 49438C0013; Thu, 28 Jan 2010 00:28:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7D826101E801; Thu, 28 Jan 2010 00:28:39 +0100 (CET) Date: Thu, 28 Jan 2010 00:28:39 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100127232839.GB92073@elstar.local> Mail-Followup-To: Wes Hardaker , Ira McDonald , Robert Story , "isms@ietf.org" , Jeffrey Hutzelman References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeffrey Hutzelman , "isms@ietf.org" , Robert Story Subject: Re: [Isms] TLSTM counters issue X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:28:37 -0000 On Wed, Jan 27, 2010 at 11:51:26PM +0100, Wes Hardaker wrote: > >>>>> On Wed, 27 Jan 2010 17:14:54 -0500, Ira McDonald said: > > IM> I agree that having separate client and server > IM> session counters is desirable and that they > IM> should be based on ASI invocations and NOT > IM> on peeking at the internals of TLS or SSH. > > Ok, I think there is now plenty of consensus to add them. So here's > what I'm gonna do: > > 1) publish -06 without them. > 2) publish -07 with them to clearly show what was done via diffs > > I think there may be a problem deciding when the closed ASI is called as > a server or a client, but I need to go dive in to the text to see if > there is a good place to delineate that. I do not think a separate ID is needed for every change. It should also be easy to identify the section where changes for the counter(s) were made in an email message. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Wed Jan 27 15:30:02 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 77C843A68D7; Wed, 27 Jan 2010 15:30:02 -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: <20100127233002.77C843A68D7@core3.amsl.com> Date: Wed, 27 Jan 2010 15:30:02 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-06.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: Wed, 27 Jan 2010 23:30:02 -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-06.txt Pages : 64 Date : 2010-01-27 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-27152433.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Jan 27 16: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 D08CC3A6996; Wed, 27 Jan 2010 16: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: <20100128003001.D08CC3A6996@core3.amsl.com> Date: Wed, 27 Jan 2010 16:30:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-07.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: Thu, 28 Jan 2010 00:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-07.txt Pages : 65 Date : 2010-01-27 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-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-27162400.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Wed Jan 27 16:41: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 10FA828C0EF for ; Wed, 27 Jan 2010 16:41: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 0w3SVd2jW-FZ for ; Wed, 27 Jan 2010 16:41: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 DB86928C0EE for ; Wed, 27 Jan 2010 16:41:47 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 796269AFEA for ; Wed, 27 Jan 2010 16:42:03 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 27 Jan 2010 16:42:03 -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 Subject: [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: Thu, 28 Jan 2010 00:41:49 -0000 I've just published new versions of the WG's TLSTM draft. The -06 version incorporates all the changes identified until the January 19th cutoff date set by Juergen, except the most recent discussion involving server side counters and properly counting only things identified via the ASI handling. The -07 version contains changes to reflect the new server-side counters and some checks to ensure all counters are properly updated during the EoP. One counter was removed, the snmpTlstmTLSProtectionErrors counter, which was diving into TLS details and was only discussed during the DTLS specific EoP handling in the first place. Normal TLS implementations would probably never be able to increment this counter within the confines of the SNMPv3 architecture. The diffs for the -05 to -06 changes are found in the following URL: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-isms-dtls-tm-06.txt The diffs for the -06 to -07 changes are found in the following URL: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-isms-dtls-tm-06.txt 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. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Thu Jan 28 16:54:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1163A6999 for ; Thu, 28 Jan 2010 16:54:08 -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 AlmZW2raxOje for ; Thu, 28 Jan 2010 16:54:07 -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 20C343A6407 for ; Thu, 28 Jan 2010 16:54:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OCp6JEkOcm2Rf+vAqBLE9E4ZAI+Wi//+TT3b4iAOMwglMzf9U8YfXEbWKPvHqNTa; 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.7.165] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Naf7y-00036C-Li for isms@ietf.org; Thu, 28 Jan 2010 19:54:27 -0500 Message-ID: <000401caa07e$1f4f61e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 16:58:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40fd0338c828b27ca48bc950efe75c3f2a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-01.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, 29 Jan 2010 00:54:08 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... I'd like to thank Juergen for the detailed comments. It's been a week now, and no one has objected to any of his proposals. As editor I intend to apply the vast majority of his suggestions and put up an updated i-d. I will start a new thread for each of those few comments where I think further discussion is needed before I make corresponding changes to the document. Randy From randy_presuhn@mindspring.com Thu Jan 28 17:26:35 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACA93A68F2 for ; Thu, 28 Jan 2010 17:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_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 xg-LZL3Pg2RZ for ; Thu, 28 Jan 2010 17:26:34 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id BFDF13A68DC for ; Thu, 28 Jan 2010 17:26:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HobXxZWXubV+cOqFO7IZWWxhnpbaT6obDHtkBaCNx+TY//Vn0gPRPw3zuqsDSwN2; 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.7.165] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NafdO-00009n-Fq for isms@ietf.org; Thu, 28 Jan 2010 20:26:54 -0500 Message-ID: <000b01caa082$a6b2aa80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 17:30:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40329e15234573231fb4c1affe2fd7aded350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: [Isms] JSa: 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: Fri, 29 Jan 2010 01:26:35 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... > a) I do not like the structure > > 1 Introduction > 1.1 General > 2 The Internet-Standard ... > 3 Conventions > > What is the point of having 1.1 if there is no 1.2? I believe a > more compact organization is this: > > 1 Introduction > 1.1 General > 1.2 The Internet-Standard ... > 1.3 Conventions > > This avoids toplevel sections consisting of just one sentence. ... While I agree with the thrust of the comment, it puts me in a bit of a bind with respect to the agreement that the document was to be made to look more like an SNMP / MIB document. I think the structure Juergen proposes makes sense, but, unfortunately, that's not what typical MIB documents look like. Consequently, I'd like either a ruling from the chair or to hear others voice their opinions before I make the change. Randy From randy_presuhn@mindspring.com Thu Jan 28 18:48:41 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C135C3A692D for ; Thu, 28 Jan 2010 18:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 SbibqhrO+IIe for ; Thu, 28 Jan 2010 18:48:41 -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 CAA143A692A for ; Thu, 28 Jan 2010 18:48:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=p2s1zctTZ6RAlsowkcE0UH3mkIsCiiVqeteO2hd+HiUKIhvSjNU60sbqrLxwwEdH; 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.7.165] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Naguq-0007Fm-PQ for isms@ietf.org; Thu, 28 Jan 2010 21:49:01 -0500 Message-ID: <001001caa08e$2074b4c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 18:52:41 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40618a70ab7cc442e5cc1a682935cb2c2b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-01.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, 29 Jan 2010 02:48:41 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... These are the items where I've tried to apply Juergen's proposals. > b) The first paragraph does not read well as an introduction. It is > just a list of concepts that exist in SNMP without giving much clue > why this list is provided or relevant. Ok, I've added some explanatory text. I agree that the list seems excessive, and hope that in the next round of comments we can trim it down. > c) s/and interacts/and how it interacts/ Fixed. > d) s/RAIDUS/RADIUS/ Fixed. > e) s/imlementation/implementation Fixed. > f) s/RADIUS client function in the NAS and the SNMP engine in the NAS/ > RADIUS client function and the SNMP engine/ Fixed. > g) s/extendedVacmSecurityToGroupTable/extVacmSecurityToGroupTable/ Fixed. > h) Remove "These rows are dynamically updated from RADIUS > authorization data." since this has already been stated in the > sentence before. Fixed. > i) s/make not update/make no update/ Fixed. > j) s/cab be/can be/ Fixed. > k) Spell out the complete name of 'rowCreatedBy' and 'rowLifetime'. Fixed. Also replaced "radiusextVacmRowLifetime" with "extVacmRowLifetime" > l) s/secture/secure/ Fixed. > m) s/basedon/based on/ Fixed. > n) s/user-authenticaed/user-authenticated/ Fixed. ... > p) s/row.If/row. If/ Fixed. > q) s/incerment/increment/ Fixed. > r) s/casues/causes/ Fixed. > s) s/rwo/row/ Fixed. ... > v) In step 2.E, the 'volatile' obviously belongs to the previous line Fixed. > w) s/exprires/expires/ Fixed. > x) It is unclear what extVacmRowLifetime reports - is this a ticking > number running backwards until it reaches zero? Or is this the > absolute value? In that case, the value is relatively meaningless > unless someone know the time the entry was created. There probably > should also be a UNITS clause. Agreed. I've added what I hope are reasonable words. > y) The security considerations should be added to the open issues list > since they need to be filled in and there might be text needed > concerning trust relationships to RADIUS and the interaction with > statically configured policy. Agreed, added. Randy From randy_presuhn@mindspring.com Thu Jan 28 18:58: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 B72F33A692A for ; Thu, 28 Jan 2010 18:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 ZeKTOLJFwVUu for ; Thu, 28 Jan 2010 18:58:44 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 2861B3A67DD for ; Thu, 28 Jan 2010 18:58:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=daPp7TmfNtWjX9bxGwbgBxoEy70JMLZVWQ2S2HrRBc3mwRPm5LJH2rLwLSD+YE68; 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.7.165] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nah4W-0008GU-2w for isms@ietf.org; Thu, 28 Jan 2010 21:59:00 -0500 Message-ID: <001701caa08f$8599d820$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 19:02:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b405538a1de939c5bb48ae210e82449c292350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: [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: Fri, 29 Jan 2010 02:58:44 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... > o) In 2.A., I assume secureTransportSecurityModel means Transport > Security Model (TSM). But I like to raise the question whether this > really should be hard wired. What happens if we eventually have to > replace TSM with say TSM++? ... I think that's the intent. As a technical contributor, I'd suggest that it should simply use the value of SnmpSecurityModel that was registered with the security model in use, rather than specifying the exact value here. For the reason you describe, I'd prefer to treat TSM as an example, rather than a normative requirement, throughout this document. I don't think that doing so would significantly impact the complexity of this document or of implementations, and would certainly make it easier to apply this specification in other contexts. Randy From root@core3.amsl.com Thu Jan 28 19: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 79A743A692C; Thu, 28 Jan 2010 19: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: <20100129030001.79A743A692C@core3.amsl.com> Date: Thu, 28 Jan 2010 19:00:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-02.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, 29 Jan 2010 03:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Extensions to View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-02.txt Pages : 20 Date : 2010-01-28 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes a backward-compatible extension to the View-based Access Control Model (VACM) for SNMPv3 for use with RADIUS and other AAA services to provide authorization of MIB database access, and defines objects for managing this extension. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-28184906.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Thu Jan 28 19:11:48 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 7CF383A67E2 for ; Thu, 28 Jan 2010 19:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 QcgoY1H-VfGb for ; Thu, 28 Jan 2010 19:11:43 -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 38E693A68F6 for ; Thu, 28 Jan 2010 19:11:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=em16wGCmWux0Y7TkBue2y/ekhaE3UH4EcSTTySraXoqLCSt1R+hfTmdKk/UFfmBd; 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.7.165] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NahH6-0007RY-Au for isms@ietf.org; Thu, 28 Jan 2010 22:12:00 -0500 Message-ID: <002501caa091$55b97500$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 19:15:38 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40e7bd1ab43e58af6ae5ab7b8138a99655350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: [Isms] JSt: legalese for embedding in MIB modules 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, 29 Jan 2010 03:11:48 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... > t) The DESCRIPTION of the MODULE-IDENTITY might need adaptation to > the legal trust boilerplate of the day. ... Agreed. Does anyone know what the correct incantation is now? The section of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf spelling out what needs to be included in IETF documents leaves me no wiser than before. Is there a URL that will always point to the current sequence of bits that will appease the lawyers? I think one possible reading of the TLP document is that since we consider a MIB module "code", it's automatically covered by the relevant sections of the TLP. But is such a reading correct? For the meantime, this has been added to the issues list. Randy From randy_presuhn@mindspring.com Thu Jan 28 20:18:12 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751623A6898 for ; Thu, 28 Jan 2010 20:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 Z4BWL4Ai0dDX for ; Thu, 28 Jan 2010 20:17:11 -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 309753A67A7 for ; Thu, 28 Jan 2010 20:17:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MC5iN0AgLrX4vBGuBAdBeWUkoVTiAsRnN/Dkk01ANTwZ+yPNjVnD49H8FFfqPjsP; 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.7.165] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NaiIQ-0000DH-Uf for isms@ietf.org; Thu, 28 Jan 2010 23:17:27 -0500 Message-ID: <003101caa09a$7a8191c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100120122622.GA806@elstar.local> Date: Thu, 28 Jan 2010 20:21:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b402c48eab585d1e8f9ea3270ed2d6e6da5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.165 Subject: [Isms] JSu: table simplification 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, 29 Jan 2010 04:18:13 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 20, 2010 4:26 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt ... > u) I do not understand why we have extVacmSecurityModel, > extVacmSecurityName, extVacmGroupName, > extVacmSecurityToGroupStorageType, and extVacmSecurityToGroupStatus > since the idea is to create a row in the vacmSecurityToGroupTable. ... Agreed. The details of what we can get rid of, however, depend on some details of the use cases we want to support. I think key questions are: (1) does the user->group mapping supplied by RADIUS apply (a) only to the specific security model that triggered the retrieval (b) only to a specific security model idenitified in the data from RADIUS (c) to a *set* of security models identified in the data from RADIUS (d) to all security models supported by the implementation (2) when a new mapping arriving from RADIUS refers to a (vacmSecurityModel, vacmSecurityName) pair for which an entry already exists in the vacmSecurityToGroupTable, do we (a) ignore it, and honor the administratively configured settings (b) apply the new mapping, and revert to the old one upon expiration (c) replace the administratively configured settings with the new mapping (3) does it make sense for data delivered by RADIUS to be made persistent / nonvolatile? (4) Do we provide a way to administratively purge RADIUS-provided data? (e.g., force immediate expiration / cleanup of created entries) (5) how is the lifetime of information from RADIUS-land managed? (a) a lifetime is provided by RADIUS, clean up on expiry (b) lifetime is that of corresponding connection(s), clean up on termination of last connection using an entry (6) how much of the internal processing do we need/want to make externally visible? The answers strongly affect what the tables would look like. For example, my answers would be 1: a -or- b, 2: a, 3: no, 4: yes (but I'm not adamant), 5: b (only because I think the behaviour is non-surprising and very easy to implement; I'm not adamantly opposed to a), 6: very little - I prefer to expose things only when there's a clear use case for them being expose via a management interface With those answers, we'd only need a table indexed by vacmSecurityModel and vacmSecurityName, and perhaps by extVacmTransportSessionID if we want to make that aspect visible, and extVacmSecurityToGroupStatus to permit administrative termination of a specific entry. extVacmGroupName is redundant, and I think it leads our thinking down the path of having RADIUS-supplied entries *temporarily* override administratively configured VACM policies. I think such an approach seriously violates the principle of least surprise. If a policy has been administratively configured for a system, I doubt that having dynamic RADIUS data overide that configuration would be a good thing. (Though I'm sure answers will vary depending on how folks feel about question #1) I think extVacmSecurityToGroupStorageType should be eliminated. I think having RADIUS-supplied stuff indefinitely surviving reboots/ power outages would be a very bad thing. I think extVacmSecurityToGroupStatus is only useful for providing a way for an administrator to kill a specific entry. I could easily be convinced that that is not needed, especially if we provided a "clear the extVacmSecurityToGroupTable" button. I think we don't need extVacmRowCreatedBy, unless we get really wild in our answers to (1). The utility of extVacmRowLifetime depends on the answer to (5) above. extVacmTransportSessionID makes sense to me only if (a) folks like to see reference-counting in action if entry lifetimes correspond to session lifetimes. If used as an index (and it would have to be, to be useful) it would work against using extVacmSecurityToGroupStatus as some kind of single-session policy kill switch, since another entry having the same model and user would be enough to maintain the group mapping. It probably would be nice to have a extVacmEnable switch, in order to enable/disable/shutdown the extension. As I see it, extVacmSecurityToGroup just needs to be indexed by security model, user, and perhaps sessionid, depending on how we want to handle row lifetimes when there are multiple sessions belonging to the same user / security model combination. Anyway, all the above means I agree with Juergen's point, but the edits will depend heavily on the details we agree to. Randy From cfinss@dial.pipex.com Fri Jan 29 00:53:31 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B273A67DD for ; Fri, 29 Jan 2010 00:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_05=-1.11] 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 QCjIGTMbvWfx for ; Fri, 29 Jan 2010 00:53:30 -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 E077B3A6452 for ; Fri, 29 Jan 2010 00:53:29 -0800 (PST) X-Trace: 323458401/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.58/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.58 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: AtwFAEoxYks+vGQ6/2dsb2JhbACCJ4VRiQm8IwmNUQqCRIFyBA X-IronPort-AV: E=Sophos;i="4.49,366,1262563200"; d="scan'208";a="323458401" X-IP-Direction: IN Received: from 1cust58.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.58]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Jan 2010 08:53:48 +0000 Message-ID: <002001caa0b8$2586d360$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20100126082310.47565917@sparta.com><20100126134324.GA54185@elstar.local><20100126094544.4677fd47@sparta.com><20100126150151.GB54456@elstar.local><20100126111148.586f5228@sparta.com><20100127115031.GA90288@elstar.local><11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> Date: Fri, 29 Jan 2010 08:50:17 +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] TLSTM counters issue 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, 29 Jan 2010 08:53:31 -0000 Juergen I agree that there is rough consensus to add counters for servers but that does not make it a good idea. As 3.3 says "(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP appplications that initiate communications" no mention of servers because servers do not initiate sessions. I cannot see a server issuing an openSession so if snmpTlstmSessionServerOpens "The number of times an openSession request has been executed as an (D)TLS server, ..." ever changes, I would think that that is an engine on the way to self-destruction. Nor can an SNMP engine reliably tell if its stack is the recipient of an open. If a client opens a session in anticipation of sending Notifications but, it is a fair day and none are ever sent, then all the server may see is a request to validate a certificate and may not see that if the certificate has already been validated. If data does arrive, then a server can compare the tlstm session id and treat a new one, or one it has not seen for a while, as a session open, but who knows what that represents under the abstraction layer in terms of ClientHello, rehandshake, renegotiation, session resumption and all the other murky waters of TLS? As has already been said, this work belongs in the TLS MIB module. Tom Petch ----- Original Message ----- From: "Ira McDonald" To: "Jeffrey Hutzelman" ; "Ira McDonald" Cc: "Robert Story" ; Sent: Wednesday, January 27, 2010 11:14 PM Subject: Re: [Isms] TLSTM counters issue > Hi, > > I agree that having separate client and server > session counters is desirable and that they > should be based on ASI invocations and NOT > on peeking at the internals of TLS or SSH. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > email: blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Fri Jan 29 03:07: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 DD2ED3A693E for ; Fri, 29 Jan 2010 03:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq8O2mMcwF+u for ; Fri, 29 Jan 2010 03:07: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 8AB6B3A6A22 for ; Fri, 29 Jan 2010 03:07:09 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF13CC005F; Fri, 29 Jan 2010 12:07:30 +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 AqSxyO7wBquf; Fri, 29 Jan 2010 12:07:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19B88C005E; Fri, 29 Jan 2010 12:07:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 785ED1023F91; Fri, 29 Jan 2010 12:07:17 +0100 (CET) Date: Fri, 29 Jan 2010 12:07:17 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100129110715.GB96725@elstar.local> Mail-Followup-To: "tom.petch" , "isms@ietf.org" , Wes Hardaker References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local> <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com> <002001caa0b8$2586d360$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002001caa0b8$2586d360$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM counters issue 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, 29 Jan 2010 11:07:11 -0000 On Fri, Jan 29, 2010 at 08:50:17AM +0100, tom.petch wrote: > I agree that there is rough consensus to add counters for servers > but that does not make it a good idea. As 3.3 says > "(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP > appplications that initiate communications" > no mention of servers because servers do not initiate sessions. I > cannot see a server issuing an openSession so if > snmpTlstmSessionServerOpens > "The number of times an openSession request has been > executed as an (D)TLS server, ..." > ever changes, I would think that that is an engine on the way to > self-destruction. But this sounds like a wording issue. I personally agree that snmpTlstmSessionServerOpens is a somewhat unfortunate choice. A server accepts sessions, it does not open them. snmpTlstmSessionOpens snmpTlstmSessionClientCloses snmpTlstmSessionOpenErrors snmpTlstmSessionAccepts snmpTlstmSessionServerCloses snmpTlstmSessionAcceptErrors It appears to me that the server is also not really executing the openSession() ASI - if so, the desription text needs to reflect that. NIT: Step 4) in section 5.2 refers to a step 4b) which I think should be 5b). NIT: There are references to snmpTlstmSessionOpenErrors which has been renamed; we need to make sure that renamings are applied everywhere. > Nor can an SNMP engine reliably tell if its stack is the recipient > of an open. If a client opens a session in anticipation of sending > Notifications but, it is a fair day and none are ever sent, then all > the server may see is a request to validate a certificate and may > not see that if the certificate has already been validated. Well, the current text in 3a) in section 5.3 leaves it implementation specific how the counter is incremented, that is whether this is delayed until the first payload arrives or not. At least that is my reading. You have a problem with that? > If data does arrive, then a server can compare the tlstm session id > and treat a new one, or one it has not seen for a while, as a > session open, but who knows what that represents under the > abstraction layer in terms of ClientHello, rehandshake, > renegotiation, session resumption and all the other murky waters of > TLS? As has already been said, this work belongs in the TLS MIB > module. The counters by design does not tell anything inside of (D)TLS. If you want counters giving you more insight, then yes someone needs to write a (D)TLS MIB module. /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 Jan 29 03:37: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 A0A413A68D5 for ; Fri, 29 Jan 2010 03:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_05=-1.11, 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 WWOJRsozPaq1 for ; Fri, 29 Jan 2010 03:37: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 99DBC3A676A for ; Fri, 29 Jan 2010 03:37:23 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EFF2C001F; Fri, 29 Jan 2010 12:37:45 +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 dl58KuOLp9la; Fri, 29 Jan 2010 12:37:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19D1BC000B; Fri, 29 Jan 2010 12:37:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 239431024259; Fri, 29 Jan 2010 12:37:34 +0100 (CET) Date: Fri, 29 Jan 2010 12:37:34 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100129113734.GF96725@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: Fri, 29 Jan 2010 11:37:24 -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 like to ask everybody to check the edits and to raise any issues with the edits by Tuesday 2nd the latest. /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 Jan 29 04:22: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 72F6F3A6A20 for ; Fri, 29 Jan 2010 04:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdiIeie-zfm8 for ; Fri, 29 Jan 2010 04:22:36 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 169803A6A19 for ; Fri, 29 Jan 2010 04:22:35 -0800 (PST) X-Trace: 177653914/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.34/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.34 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: AqkFAIVhYks+vGQi/2dsb2JhbACCJxaFO4kGyhYKgiuCDQQ X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="eml'208?scan'208,208";a="177653914" X-IP-Direction: IN Received: from 1cust34.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.34]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Jan 2010 12:22:51 +0000 Message-ID: <000201caa0d5$599b2b20$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , "isms" References: <20100120122622.GA806@elstar.local> <002501caa091$55b97500$6801a8c0@oemcomputer> Date: Fri, 29 Jan 2010 11:57:50 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_011E_01CAA0DA.47F78940" 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] JSt: legalese for embedding in MIB modules 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, 29 Jan 2010 12:22:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_011E_01CAA0DA.47F78940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Randy Try the attached e-mail from Jorge to the IETF list in December last. A new Trust Legal Provisions has come out since then but it, like all of them and unlike RFC3978, does not include any section on Legends to be Included in Code Components in an IETF Document. Perhaps we need to revise the Trust Legal Provisions (again:-). Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Friday, January 29, 2010 4:15 AM Subject: [Isms] JSt: legalese for embedding in MIB modules > Hi - > > > From: "Juergen Schoenwaelder" > > To: > > Sent: Wednesday, January 20, 2010 4:26 AM > > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt > ... > > t) The DESCRIPTION of the MODULE-IDENTITY might need adaptation to > > the legal trust boilerplate of the day. > ... > > Agreed. Does anyone know what the correct incantation is now? > > The section of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf > spelling out what needs to be included in IETF documents leaves me > no wiser than before. Is there a URL that will always point to the current > sequence of bits that will appease the lawyers? I think one possible > reading of the TLP document is that since we consider a MIB module > "code", it's automatically covered by the relevant sections of the TLP. > But is such a reading correct? > > For the meantime, this has been added to the issues list. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_011E_01CAA0DA.47F78940 Content-Type: message/rfc822; name="need advice on reproducing code (Relax NG) from RFC 4287 (The Atom Syndication Format).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="need advice on reproducing code (Relax NG) from RFC 4287 (The Atom Syndication Format).eml" Return-path: Envelope-to: sisyphus@dial.pipex.com Delivery-date: Tue, 22 Dec 2009 01:22:55 +0000 Received: from mk-filter-6.mail.uk.tiscali.com ([212.139.137.133]) by mk-delivery-1.b2b.uk.tiscali.com with esmtp (Exim 4.69) (envelope-from ) id 1NMt2t-000MoA-Vv for sisyphus@dial.pipex.com; Tue, 22 Dec 2009 00:56:15 +0000 Received-SPF: None identity=pra; client-ip=64.170.98.32; receiver=mk-inboundfilter-2-a-1.b2b.uk.tiscali.com; envelope-from="ietf-bounces@ietf.org"; x-sender="ietf-bounces@ietf.org"; x-conformance=sidf_compatible Received-SPF: Pass identity=mailfrom; client-ip=64.170.98.32; receiver=mk-inboundfilter-2-a-1.b2b.uk.tiscali.com; envelope-from="ietf-bounces@ietf.org"; x-sender="ietf-bounces@ietf.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None identity=helo; client-ip=64.170.98.32; receiver=mk-inboundfilter-2-a-1.b2b.uk.tiscali.com; envelope-from="ietf-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=sidf_compatible X-Trace: 1439617231/mk-filter-6.mail.uk.tiscali.com/ListenerSBRS/$ACCEPTED/UNKNOWNLIST/64.170.98.32/4.2/ietf-bounces@ietf.org X-SBRS: 4.2 Received: from mail.ietf.org ([64.170.98.32]) by mk-inboundfilter-2-a-1.b2b.uk.tiscali.com with ESMTP; 22 Dec 2009 00:56:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13853A6AB5; Mon, 21 Dec 2009 16:56:11 -0800 (PST) X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0373A68CB for ; Mon, 21 Dec 2009 16:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aQnfvCQPYXB for ; Mon, 21 Dec 2009 16:56:08 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 774F53A6891 for ; Mon, 21 Dec 2009 16:56:08 -0800 (PST) Received: by fxm7 with SMTP id 7so5510264fxm.29 for ; Mon, 21 Dec 2009 16:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=/HH+fp8K5BJKgUtT4rruDg3gPYHgq38il4p6PISkVLk=; b=LPKn+2qK1nHWuU7eMD7MT4jmkpI+WK839hlNKVvvRN1Gyf6CRDhfMBIPQr8/wQ5zMu JQbTLw7bNqzBFulVJpfsT+KcfDlvPRs9JwG4lZFfI2kErB2UwzTvEIkYJfLA5Iyq5OJV 06lkja/hRusBNgCd+FBAHx8kdcFSCkDZM4AMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Y8DE83pqP5HrzCOn9kY7tJTuS+nStb2u+fLmpHsXXqXzJiDDv5JpZ9w1h/PhJ/w/1d 0OjKK6xnTBOpeRIdiUWv+hvVlY9AEaA5d9j5zgFuaZGNRs4u9C2aZzH8h9gbsRPf47fa gtd/My7tRuGfJSmVZflUx7WhGnmeHEgPG/AXQ= MIME-Version: 1.0 Received: by 10.103.127.7 with SMTP id e7mr1599198mun.2.1261443349270; Mon, 21 Dec 2009 16:55:49 -0800 (PST) Date: Mon, 21 Dec 2009 19:55:49 -0500 Message-ID: Subject: need advice on reproducing code (Relax NG) from RFC 4287 (The Atom Syndication Format) From: Jorge Contreras To: ietf@ietf.org, julian.reschke@gmx.de, Olaf Kolkman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0065700227==" Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org --===============0065700227== Content-Type: multipart/alternative; boundary=0016e65c88acbcd303047b46aa44 --0016e65c88acbcd303047b46aa44 Content-Type: text/plain; charset=ISO-8859-1 Julian -- your understanding is consistent with mine. That seems to be the right legend. Regards, Jorge ------------------------------ - *From*: Julian Reschke > - *To*: IETF Discussion > - *Cc*: Paul Hoffman / IMC > - *Date*: Sun, 20 Dec 2009 19:53:07 +0100 ------------------------------ Hi, the OASIS CMIS TC would like to ship their spec with an XML Schema describing the Atom feed syntax. That schema can be produced from Appendix B of RFC 4287 using Jim Clark's "trang". The license for RFC 4287 is defined by BCP 78, of which RFC 3978 was the current version when RFC 4287 was published. Section 5.6 of RFC 3978 has: -- snip -- a. in MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." ... For other types of components than "MIB", substitute "MIB module" with an appropriate identifier. In the case of MIB and PIB modules this statement should be placed in the DESCRIPTION clause of the MODULE-IDENTITY macro. Variations of these abbreviated notices are not permitted except in cases where the material to be extracted is the product of a joint development effort between the IETF and another standards development organization or is a republication of the work of another standards organization. Such variations must be approved on an individual basis by the IAB. -- snip -- (). Question: does the Relax NG schema qualify as "code component"? It certainly does according to < http://trustee.ietf.org/docs/Code-Components-List-4-23-09.txt>, but that's data from 2009. Assuming it does qualify as code component, would the following notice on the extracted Relaxg NG schema be OK? "Copyright (C) The Internet Society 2005. This version of this RelaxNG schema is part of RFC 4287; see the RFC itself for full legal notices." Best regards, Julian --0016e65c88acbcd303047b46aa44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Julian -- your understanding is consistent with mine.= =A0 That seems to be the right legend.

Regards,
Jorge

  • From: Julian Reschke <julian.reschke at gmx.de>=20
  • To: IETF Discussion <= ietf at ietf.org>=20
  • Cc: Paul Hoffman / IMC <phoffman at imc.org>=20
  • Date: Sun, 20 Dec 2009 19:53:07 +0100 
    • Hi,
    the OASIS CMIS TC would like to ship their spec with an XML Schem= a describing the Atom feed syntax. That schema can be produced fro= m Appendix B of RFC 4287 using Jim Clark's "trang". = 
    The license for RFC 4287 is defined by BCP 78, of which RFC 3978 =
was the current version when RFC 4287 was published. 
    Section 5.6 of RFC 3978 has:

-- snip --
   a. in MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

         "Copyright (C) The Internet Society <year>.  This versi=
on of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      ...

      For other types of components than "MIB", substitute "=
MIB module"
      with an appropriate identifier.  In the case of MIB and PIB
      modules this statement should be placed in the DESCRIPTION clause
      of the MODULE-IDENTITY macro.

      Variations of these abbreviated notices are not permitted except
      in cases where the material to be extracted is the product of a
      joint development effort between the IETF and another standards
      development organization or is a republication of the work of
      another standards organization.  Such variations must be approved
      on an individual basis by the IAB.
-- snip --

(<http://tools.ietf.org/html/rfc3978#section-5.6>).


    Question: does the Relax NG schema qualify as "code componen=
t"? It certainly does according to <http://trustee.ietf.org/docs/Code-Components-List-4-23-09.txt>, b=
ut that's data from 2009. 
    Assuming it does qualify as code component, would the following n=
otice on the extracted Relaxg NG schema be OK? 
             "Copyright (C) The Internet Society 2005.  This =
version of
         this RelaxNG schema is part of RFC 4287; see the RFC itself for
         full legal notices."

Best regards, Julian

    

--0016e65c88acbcd303047b46aa44--

--===============0065700227==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

--===============0065700227==--
------=_NextPart_000_011E_01CAA0DA.47F78940--


From ietfdbh@comcast.net  Fri Jan 29 05:26: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 0A0533A6A24 for ; Fri, 29 Jan 2010 05:26:11 -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 t8pXb8dv1kKt for ; Fri, 29 Jan 2010 05:26:10 -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 071ED3A6956 for ; Fri, 29 Jan 2010 05:26:09 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id bQAM1d0070QuhwU5DRSYPV; Fri, 29 Jan 2010 13:26:32 +0000
Received: from Harrington73653 ([24.147.240.98]) by omta02.westchester.pa.mail.comcast.net with comcast id bRSY1d002284sdk3NRSY20; Fri, 29 Jan 2010 13:26:32 +0000
From: "David Harrington" 
To: "'Randy Presuhn'" , 
References: <20100120122622.GA806@elstar.local> <001701caa08f$8599d820$6801a8c0@oemcomputer>
Date: Fri, 29 Jan 2010 08:26:31 -0500
Message-ID: <073e01caa0e6$ab8f7bf0$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: <001701caa08f$8599d820$6801a8c0@oemcomputer>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcqgjwZNZamvEl1YR2e3Cde/mrtjvAAV6Ggw
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: Fri, 29 Jan 2010 13:26:11 -0000

+1

dbh 

> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On 
> Behalf Of Randy Presuhn
> Sent: Thursday, January 28, 2010 10:03 PM
> To: isms@ietf.org
> Subject: [Isms] JSo: hard-wire to TSM?
> 
> Hi -
> 
> > From: "Juergen Schoenwaelder"

> > To: 
> > Sent: Wednesday, January 20, 2010 4:26 AM
> > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt
> ...
> > o) In 2.A., I assume secureTransportSecurityModel means Transport
> >    Security Model (TSM). But I like to raise the question 
> whether this
> >    really should be hard wired. What happens if we 
> eventually have to
> >    replace TSM with say TSM++?
> ...
> 
> I think that's the intent.
> 
> As a technical contributor, I'd suggest that it should simply use
> the value of SnmpSecurityModel that was registered with the
> security model in use, rather than specifying the exact value here.
> For the reason you describe, I'd prefer to treat TSM as an example,
> rather than a normative requirement, throughout this document.
> I don't think that doing so would significantly impact the
complexity
> of this document or of implementations, and would certainly make
> it easier to  apply this specification in other contexts.
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 


From ietfdbh@comcast.net  Fri Jan 29 05:40: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 279AA28C14F for ; Fri, 29 Jan 2010 05:40:33 -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 coS8TKlfc89K for ; Fri, 29 Jan 2010 05:40:32 -0800 (PST)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 1EB3B3A6A22 for ; Fri, 29 Jan 2010 05:40:32 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id bPFn1d0091YDfWL5CRgvJb; Fri, 29 Jan 2010 13:40:55 +0000
Received: from Harrington73653 ([24.147.240.98]) by omta20.westchester.pa.mail.comcast.net with comcast id bRhT1d005284sdk3gRhUTB; Fri, 29 Jan 2010 13:41:28 +0000
From: "David Harrington" 
To: "'Juergen Schoenwaelder'" , "'tom.petch'" 
References: <20100126134324.GA54185@elstar.local><20100126094544.4677fd47@sparta.com><20100126150151.GB54456@elstar.local><20100126111148.586f5228@sparta.com><20100127115031.GA90288@elstar.local><11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com><002001caa0b8$2586d360$0601a8c0@allison> <20100129110715.GB96725@elstar.local>
Date: Fri, 29 Jan 2010 08:40:53 -0500
Message-ID: <073f01caa0e8$adc758a0$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: <20100129110715.GB96725@elstar.local>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acqg00PUkhjBiyRgRNCb4+KHX9F5nQAFPBNA
Cc: isms@ietf.org
Subject: Re: [Isms] TLSTM counters issue
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, 29 Jan 2010 13:40:33 -0000

 
> It appears to me that the server is also not really executing the
> openSession() ASI - if so, the desription text needs to reflect
that.
> 

+1

> Well, the current text in 3a) in section 5.3 leaves it
implementation
> specific how the counter is incremented, that is whether this is
> delayed until the first payload arrives or not. At least that is my
> reading. You have a problem with that?

I think the serveropens should be tied to the first message received;
I don't think we assign a sessionID until there is an incoming
message.

> The counters by design does not tell anything inside of (D)TLS. If
you
> want counters giving you more insight, then yes someone needs to
write
> a (D)TLS MIB module.

+1

dbh


From d.b.nelson@comcast.net  Fri Jan 29 05:49:21 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247813A68CC for ; Fri, 29 Jan 2010 05:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 UyI0fccnw1j2 for ; Fri, 29 Jan 2010 05:49:20 -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 361293A68BC for ; Fri, 29 Jan 2010 05:49:20 -0800 (PST)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id bPqG1d0020cZkys56RpiGA; Fri, 29 Jan 2010 13:49:42 +0000
Received: from NEWTON603 ([71.232.143.198]) by omta10.westchester.pa.mail.comcast.net with comcast id bRph1d0064H2mdz3WRphiV; Fri, 29 Jan 2010 13:49:42 +0000
From: "Dave Nelson" 
To: 
References: <20100120122622.GA806@elstar.local> <001701caa08f$8599d820$6801a8c0@oemcomputer>
Date: Fri, 29 Jan 2010 08:49:40 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <001701caa08f$8599d820$6801a8c0@oemcomputer>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcqgjwZNYqNmEeZKRQOvW5IrInRIAQAWeayw
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: Fri, 29 Jan 2010 13:49:21 -0000

> As a technical contributor, I'd suggest that it should simply
> use the value of SnmpSecurityModel that was registered with the
> security model in use, rather than specifying the exact value 
> here.

With caveats, that's probably OK.

> For the reason you describe, I'd prefer to treat TSM as an
> example, rather than a normative requirement, throughout this
> document.

Yes, but not all security models have the same security properties.  Given
that the premise of this document is to bind principal identity to access
control policy via an external AAA server, it makes no sense to apply the
mechanism described in this document to non-AAA-aware security models.  I
agree that tying this usage to a *specific* security model is undesirable,
for all the usual SNMP architectural modularity reasons.  However, I think
there is a normative requirement to tie it to a *class* of security models
that embrace principal authentication via AAA services, such as RADIUS.
Otherwise, I feel we will create a significant security risk.



From ietfdbh@comcast.net  Fri Jan 29 05:57:11 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B65A28C159 for ; Fri, 29 Jan 2010 05:57:11 -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 EKgBoCtmA8H5 for ; Fri, 29 Jan 2010 05:57:10 -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 5D0583A6A62 for ; Fri, 29 Jan 2010 05:57:10 -0800 (PST)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id bPyL1d0081HzFnQ56RxZTE; Fri, 29 Jan 2010 13:57:33 +0000
Received: from Harrington73653 ([24.147.240.98]) by omta14.westchester.pa.mail.comcast.net with comcast id bRxZ1d008284sdk3aRxZ03; Fri, 29 Jan 2010 13:57:33 +0000
From: "David Harrington" 
To: "'Randy Presuhn'" , 
References: <20100120122622.GA806@elstar.local> <000b01caa082$a6b2aa80$6801a8c0@oemcomputer>
Date: Fri, 29 Jan 2010 08:57:32 -0500
Message-ID: <074001caa0eb$00dc0b60$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: <000b01caa082$a6b2aa80$6801a8c0@oemcomputer>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcqggibDIq7SKIkyQdaWCav5V9FSmAAZ1sOA
Subject: Re: [Isms] JSa: 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: Fri, 29 Jan 2010 13:57:11 -0000

Hi,

I agree the 1.1 numbering and indent is not needed; just promote it to
1.
So you should have:
1.  Introduction
2.  The Internet-Standard Management Framework 
3.  Conventions
4.  Overview

RFC4181 (BCP 111) only says that the MIB boilerplate must be included.
RFC5249 (BCP 139) points to the MIB document templates at
tools.ietf.org. 
The templates show:
--start--
1.  Introduction

   This memo defines a portion of the Management Information Base
(MIB)
   for use with network management protocols.  In particular it
defines
   objects for managing the [TEMPLATE TODO].

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7
of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store,
termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a
MIB
   module that is compliant to the SMIv2, which is described in STD
58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Overview
5.  Structure of the MIB Module
etc.
--end --

dbh


> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On 
> Behalf Of Randy Presuhn
> Sent: Thursday, January 28, 2010 8:31 PM
> To: isms@ietf.org
> Subject: [Isms] JSa: structure
> 
> Hi -
> 
> > From: "Juergen Schoenwaelder"

> > To: 
> > Sent: Wednesday, January 20, 2010 4:26 AM
> > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt
> ...
> > a) I do not like the structure
> > 
> >    1 Introduction
> >    1.1 General
> >    2 The Internet-Standard ...
> >    3 Conventions
> > 
> >    What is the point of having 1.1 if there is no 1.2? I believe a
> >    more compact organization is this:
> > 
> >    1 Introduction
> >    1.1 General
> >    1.2 The Internet-Standard ...
> >    1.3 Conventions
> > 
> >    This avoids toplevel sections consisting of just one sentence.
> ...
> 
> While I agree with the thrust of the comment, it puts me in a 
> bit of a bind
> with respect to the agreement that the document was to be made to
look
> more like an SNMP / MIB document.  I think the structure 
> Juergen proposes
> makes sense, but, unfortunately, that's not what typical MIB 
> documents look like.
> Consequently, I'd like either a ruling from the chair or to 
> hear others voice
> their opinions before I make the change.
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 


From j.schoenwaelder@jacobs-university.de  Fri Jan 29 07:20: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 312C43A6916 for ; Fri, 29 Jan 2010 07:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level: 
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.131,  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 kSDE8WD7CobK for ; Fri, 29 Jan 2010 07:19: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 020923A6833 for ; Fri, 29 Jan 2010 07:19:59 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BE41C004C; Fri, 29 Jan 2010 16:20:21 +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 Cj9Ph2Ow6CaE; Fri, 29 Jan 2010 16:20:19 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6591C0049; Fri, 29 Jan 2010 16:20:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8818E1024AB0; Fri, 29 Jan 2010 16:20:09 +0100 (CET)
Date: Fri, 29 Jan 2010 16:20:09 +0100
From: Juergen Schoenwaelder 
To: David Harrington 
Message-ID: <20100129152009.GB97812@elstar.local>
Mail-Followup-To: David Harrington , 'Randy Presuhn' , "isms@ietf.org" 
References: <20100120122622.GA806@elstar.local> <000b01caa082$a6b2aa80$6801a8c0@oemcomputer> <074001caa0eb$00dc0b60$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <074001caa0eb$00dc0b60$0600a8c0@china.huawei.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "isms@ietf.org" 
Subject: Re: [Isms] JSa: 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: Fri, 29 Jan 2010 15:20:00 -0000

On Fri, Jan 29, 2010 at 02:57:32PM +0100, David Harrington wrote:
> Hi,
> 
> I agree the 1.1 numbering and indent is not needed; just promote it to
> 1.
> So you should have:
> 1.  Introduction
> 2.  The Internet-Standard Management Framework 
> 3.  Conventions
> 4.  Overview
> 
> RFC4181 (BCP 111) only says that the MIB boilerplate must be included.
> RFC5249 (BCP 139) points to the MIB document templates at
> tools.ietf.org. 
> The templates show:
> --start--
> 1.  Introduction
> 
>    This memo defines a portion of the Management Information Base
> (MIB)
>    for use with network management protocols.  In particular it
> defines
>    objects for managing the [TEMPLATE TODO].
> 
> 2.  The Internet-Standard Management Framework
> 
>    For a detailed overview of the documents that describe the current
>    Internet-Standard Management Framework, please refer to section 7
> of
>    RFC 3410 [RFC3410].
> 
>    Managed objects are accessed via a virtual information store,
> termed
>    the Management Information Base or MIB.  MIB objects are generally
>    accessed through the Simple Network Management Protocol (SNMP).
>    Objects in the MIB are defined using the mechanisms defined in the
>    Structure of Management Information (SMI).  This memo specifies a
> MIB
>    module that is compliant to the SMIv2, which is described in STD
> 58,
>    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
>    [RFC2580].
> 
> 3.  Conventions
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> 4.  Overview
> 5.  Structure of the MIB Module
> etc.
> --end --
> 
> dbh

I personally strongly dislike one sentence top-level sections. And
having this level of document structure prescribed does not really
solve any problem I can think of.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From dnelson@elbrysnetworks.com  Fri Jan 29 08:07:41 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B1228C159 for ; Fri, 29 Jan 2010 08:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 JGNIqltthc2Z for ; Fri, 29 Jan 2010 08:07:40 -0800 (PST)
Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id B84B928C15F for ; Fri, 29 Jan 2010 08:07:39 -0800 (PST)
Received: (qmail 4089 invoked from network); 29 Jan 2010 16:08:00 -0000
Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 29 Jan 2010 16:08:00 -0000
From: "David B. Nelson" 
To: Randy Presuhn 
In-Reply-To: <003101caa09a$7a8191c0$6801a8c0@oemcomputer>
X-Priority: 3
References: <20100120122622.GA806@elstar.local> <003101caa09a$7a8191c0$6801a8c0@oemcomputer>
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 29 Jan 2010 11:08:00 -0500
X-Mailer: Apple Mail (2.936)
Cc: isms@ietf.org
Subject: Re: [Isms] JSu: table simplification
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, 29 Jan 2010 16:07:41 -0000

On Jan 28, 2010, at 11:21 PM, Randy Presuhn wrote:

>   I think key questions are:
>
>   (1) does the user->group mapping supplied by RADIUS apply
>         (a) only to the specific security model that triggered the  
> retrieval

It would likely only apply to the security model that triggered the  
retrieval, and certainly would only apply to security models wherein  
the authentication of the principal's identity is obtained via  
RADIUS.  As we are all likely aware, RADIUS doesn't  support the  
separation of authorization from authentication.

>         (b) only to a specific security model idenitified in the  
> data from RADIUS

RADIUS has no way to specifically identify a security model (at least  
via the attributes defined n RFC 5607).

>         (c) to a *set* of security models identified in the data  
> from RADIUS

Perhaps to a "set" of security models that are known to be RADIUS- 
aware.  There is always the possibility of an inadvertent de-coupling  
of authentication from authorization unless the implementation takes  
some care to keep track of these things, or the system / security  
administrator does so via configuration.

>         (d) to all security models supported by the implementation

I think that would give rise to significant security risks.

>  (2) when a new mapping arriving from RADIUS refers to a  
> (vacmSecurityModel,
>        vacmSecurityName) pair for which an entry already exists in the
>        vacmSecurityToGroupTable, do we
>        (a) ignore it, and honor the administratively configured  
> settings

Probably yes, on the assumption that the system administrator /  
security administrator intended this local override  I think it is  
important that this increment a counter, as it might equally well be  
the result of a misconfiguration.

>        (b) apply the new mapping, and revert to the old one upon  
> expiration

That's a reasonable choice in terms of getting the expected behavior  
in a RADIUS environment.  It certainly adds complexity, however.

>        (c) replace the administratively configured settings with the  
> new mapping

I think that would be wrong.

>  (3) does it make sense for data delivered by RADIUS to be made
>        persistent / nonvolatile?

No.  I see no valid use case for that approach.

>  (4) Do we provide a way to administratively purge RADIUS-provided  
> data?
>        (e.g., force immediate expiration / cleanup of created entries)

Umm.. maybe It's called reboot.  :-)  Generally speaking, customers  
will use RADIUS because that's where their user authentication,  
authorization and policy data resides.  I think situations in which  
customer will want to circumvent RADIUS authorization are indeed  
corner cases.  They either use RADIUS in their network infrastructure  
or they don't.  You would need a "back-up" means of AAA, of course,  
for when RADIUS is unreachable, and that might be via USM

>  (5) how is the lifetime of information from RADIUS-land managed?
>        (a) a lifetime is provided by RADIUS, clean up on expiry

That's what RFC 5607 specifies.

>        (b) lifetime is that of corresponding connection(s), clean up
>              on termination of last connection using an entry

If there is a reliable way to determine that the data is no longer in  
use, e;;g. that all "connections" relying on that data have  
terminated, then that might also be considered.

>   (6) how much of the internal processing do we need/want to make
>         externally visible?

I don't understand.


From ietfdbh@comcast.net  Fri Jan 29 08:09:24 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E756E3A67EB for ; Fri, 29 Jan 2010 08:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 j3KeiYwEKlsA for ; Fri, 29 Jan 2010 08:09:23 -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 44EA43A695C for ; Fri, 29 Jan 2010 08:09:23 -0800 (PST)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id bThw1d00S0cZkys5DU9mko; Fri, 29 Jan 2010 16:09:46 +0000
Received: from Harrington73653 ([24.147.240.98]) by omta10.westchester.pa.mail.comcast.net with comcast id bU9j1d002284sdk3WU9jTk; Fri, 29 Jan 2010 16:09:43 +0000
From: "David Harrington" 
To: "'Juergen Schoenwaelder'" 
References: <20100120122622.GA806@elstar.local> <000b01caa082$a6b2aa80$6801a8c0@oemcomputer> <074001caa0eb$00dc0b60$0600a8c0@china.huawei.com> <20100129152009.GB97812@elstar.local>
Date: Fri, 29 Jan 2010 11:09:41 -0500
Message-ID: <075101caa0fd$778782a0$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: <20100129152009.GB97812@elstar.local>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acqg9pSpJBXuErdmR+yUzp5J4MH1ygAAnK5Q
Cc: isms@ietf.org
Subject: Re: [Isms] JSa: 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: Fri, 29 Jan 2010 16:09:25 -0000

Hi,

I recommend that the current 1.1 General section be the 1. section.
It has more than one sentence.
section 2 has more than one sentence.
section 3 is the only one with a single sentence, but the RFC2119
boilerplate is often in its own section in IETF documents, and the
xml2rfc template published by the EDU team puts this in a separate
section.
section 4 and higher would all have more than one sentence.
So I don't see the issue of one-sentence sections.

BCP 139 went through MIB Doctor and gen-art and secdir reviews, plus
AD, IESG, IETF LC and RFC editor reviews, plus an Alfred Hines review,
and the consensus was to approve the structure used in the template.

I am not promoting this as the best design; nor am I saying it is not
- personally, I don't much care. I am responding to Randy's request
for feedback. As editor, I documented the consensus on the design. The
IETF and its leadership approved this as a BCP.  This is the format
recommended for use in new MIB documents. I think we should have a
solid reason for ignoring the IETF consensus on the BCP, especially
since many of us are recognized as leaders in the MIB domain.

I don't see that your opinion represents the IETF consensus. But
you're the chair, and if you want to impose your personal preference
over the consensus of the rest of the IETF, I suppose that's in your
power.  

I just don't really see an issue here, myself.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: Friday, January 29, 2010 10:20 AM
> To: David Harrington
> Cc: 'Randy Presuhn'; isms@ietf.org
> Subject: Re: [Isms] JSa: structure
> 
> On Fri, Jan 29, 2010 at 02:57:32PM +0100, David Harrington wrote:
> > Hi,
> > 
> > I agree the 1.1 numbering and indent is not needed; just 
> promote it to
> > 1.
> > So you should have:
> > 1.  Introduction
> > 2.  The Internet-Standard Management Framework 
> > 3.  Conventions
> > 4.  Overview
> > 
> > RFC4181 (BCP 111) only says that the MIB boilerplate must 
> be included.
> > RFC5249 (BCP 139) points to the MIB document templates at
> > tools.ietf.org. 
> > The templates show:
> > --start--
> > 1.  Introduction
> > 
> >    This memo defines a portion of the Management Information Base
> > (MIB)
> >    for use with network management protocols.  In particular it
> > defines
> >    objects for managing the [TEMPLATE TODO].
> > 
> > 2.  The Internet-Standard Management Framework
> > 
> >    For a detailed overview of the documents that describe 
> the current
> >    Internet-Standard Management Framework, please refer to section
7
> > of
> >    RFC 3410 [RFC3410].
> > 
> >    Managed objects are accessed via a virtual information store,
> > termed
> >    the Management Information Base or MIB.  MIB objects are 
> generally
> >    accessed through the Simple Network Management Protocol (SNMP).
> >    Objects in the MIB are defined using the mechanisms 
> defined in the
> >    Structure of Management Information (SMI).  This memo specifies
a
> > MIB
> >    module that is compliant to the SMIv2, which is described in
STD
> > 58,
> >    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 
> 58, RFC 2580
> >    [RFC2580].
> > 
> > 3.  Conventions
> > 
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
> "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> > this
> >    document are to be interpreted as described in RFC 2119 
> [RFC2119].
> > 
> > 4.  Overview
> > 5.  Structure of the MIB Module
> > etc.
> > --end --
> > 
> > dbh
> 
> I personally strongly dislike one sentence top-level sections. And
> having this level of document structure prescribed does not really
> solve any problem I can think of.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> 


From dnelson@elbrysnetworks.com  Fri Jan 29 08:14: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 B4E873A6A0D for ; Fri, 29 Jan 2010 08:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2z4Jl-tFlDk for ; Fri, 29 Jan 2010 08:14:04 -0800 (PST)
Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 102893A694D for ; Fri, 29 Jan 2010 08:14:03 -0800 (PST)
Received: (qmail 4324 invoked from network); 29 Jan 2010 16:14:26 -0000
Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 29 Jan 2010 16:14:26 -0000
Message-Id: 
From: "David B. Nelson" 
To: isms@ietf.org
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-2-859141198
Mime-Version: 1.0 (Apple Message framework v936)
X-Priority: 3
Date: Fri, 29 Jan 2010 11:14:26 -0500
References: <20100120122622.GA806@elstar.local> <003101caa09a$7a8191c0$6801a8c0@oemcomputer> 
X-Mailer: Apple Mail (2.936)
Subject: Re: [Isms] JSu: table simplification
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, 29 Jan 2010 16:14:06 -0000

--Apple-Mail-2-859141198
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jan 29, 2010, at 11:08 AM, David B. Nelson wrote:

>> (5) how is the lifetime of information from RADIUS-land managed?
>>       (a) a lifetime is provided by RADIUS, clean up on expiry
>
> That's what RFC 5607 specifies.

Actually, I think this in in RFC 5608 [as well].


--Apple-Mail-2-859141198
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit


    On Jan 29, 2010, at 11:08 AM, David B. Nelson wrote:

     (5) how is the lifetime of information from RADIUS-land managed?
           (a) a lifetime is provided by RADIUS, clean up on expiry

    That's what RFC 5607 specifies.

    Actually, I think this in in RFC 5608 [as well].

    
--Apple-Mail-2-859141198--

From cfinss@dial.pipex.com  Fri Jan 29 10:41: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 2DB923A6A35 for ; Fri, 29 Jan 2010 10:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 t2F5FvfpBxmS for ; Fri, 29 Jan 2010 10:41:18 -0800 (PST)
Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id C2A773A6405 for ; Fri, 29 Jan 2010 10:41:17 -0800 (PST)
X-Trace: 177778571/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.83/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.83
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: AqsGAJ+6Yks+vGRT/2dsb2JhbAA8gWsWhTuJBrt8CY1aAgiCRoFyBA
X-IronPort-AV: E=Sophos;i="4.49,370,1262563200"; d="scan'208";a="177778571"
X-IP-Direction: IN
Received: from 1cust83.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.83]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Jan 2010 18:41:37 +0000
Message-ID: <000401caa10a$439280a0$0601a8c0@allison>
From: "tom.petch" 
To: "Juergen Schoenwaelder" 
References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local>  <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com>   <002001caa0b8$2586d360$0601a8c0@allison> <20100129110715.GB96725@elstar.local>
Date: Fri, 29 Jan 2010 14:07:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: isms@ietf.org
Subject: Re: [Isms] TLSTM counters issue
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, 29 Jan 2010 18:41:19 -0000

----- Original Message ----- 
From: "Juergen Schoenwaelder" 
Sent: Friday, January 29, 2010 12:07 PM


> On Fri, Jan 29, 2010 at 08:50:17AM +0100, tom.petch wrote:
>  
> > I agree that there is rough consensus to add counters for servers
> > but that does not make it a good idea.  As 3.3 says
> > "(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP
> >    appplications that initiate communications"
> > no mention of servers because servers do not initiate sessions.  I
> > cannot see a server issuing an openSession so if
> > snmpTlstmSessionServerOpens
> > "The number of times an openSession request has been
> >        executed as an (D)TLS server, ..."
> > ever changes, I would think that that is an engine on the way to
> > self-destruction.
> 
> But this sounds like a wording issue. I personally agree that
> snmpTlstmSessionServerOpens is a somewhat unfortunate choice. A 
> server accepts sessions, it does not open them.
> 
> snmpTlstmSessionOpens
> snmpTlstmSessionClientCloses
> snmpTlstmSessionOpenErrors
> snmpTlstmSessionAccepts
> snmpTlstmSessionServerCloses
> snmpTlstmSessionAcceptErrors
> 
> It appears to me that the server is also not really executing the
> openSession() ASI - if so, the desription text needs to reflect that.
> 
> NIT: Step 4) in section 5.2 refers to a step 4b) which I think should
>      be 5b).
> 
> NIT: There are references to snmpTlstmSessionOpenErrors which has been
>      renamed; we need to make sure that renamings are applied
>      everywhere.
> 
> > Nor can an SNMP engine reliably tell if its stack is the recipient
> > of an open.  If a client opens a session in anticipation of sending
> > Notifications but, it is a fair day and none are ever sent, then all
> > the server may see is a request to validate a certificate and may
> > not see that if the certificate has already been validated.
> 
> Well, the current text in 3a) in section 5.3 leaves it implementation
> specific how the counter is incremented, that is whether this is
> delayed until the first payload arrives or not. At least that is my
> reading. You have a problem with that?

Yes!

The server can count the number of times it is asked to validate a certificate,
it can count the number of seemingly new session IDs there are, but both
are only a loose approximation to the openSessions that the client issues.

By all means count certificate validations and new session IDs, just don't
pretend that they are 'openSessions', just something from which the number
of session accepts can be guesstimated with some degree of error.  This
is more than wording, it is a question of what we are counting and who 
should draw what inferences from them; the MIB module should not be
drawing the inferences.

Tom Petch


>  
> > If data does arrive, then a server can compare the tlstm session id
> > and treat a new one, or one it has not seen for a while, as a
> > session open, but who knows what that represents under the
> > abstraction layer in terms of ClientHello, rehandshake,
> > renegotiation, session resumption and all the other murky waters of
> > TLS? As has already been said, this work belongs in the TLS MIB
> > module.
> 
> The counters by design does not tell anything inside of (D)TLS. If you
> want counters giving you more insight, then yes someone needs to write
> a (D)TLS MIB module.
> 
> /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 Jan 29 10:41:21 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CAB28C0DE for ; Fri, 29 Jan 2010 10:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.320,  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 gxoHdZcD3aDZ for ; Fri, 29 Jan 2010 10:41:20 -0800 (PST)
Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 6FC113A6405 for ; Fri, 29 Jan 2010 10:41:20 -0800 (PST)
X-Trace: 177778591/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.83/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.83
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: AqsGAJ+6Yks+vGRT/2dsb2JhbAA8gWsWhTuJBrt8CY1aAgiCKxuBcgQ
X-IronPort-AV: E=Sophos;i="4.49,370,1262563200"; d="scan'208";a="177778591"
X-IP-Direction: IN
Received: from 1cust83.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.83]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Jan 2010 18:41:41 +0000
Message-ID: <000601caa10a$45e59860$0601a8c0@allison>
From: "tom.petch" 
To: "Juergen Schoenwaelder" , "Wes Hardaker" 
References:  <20100129113734.GF96725@elstar.local>
Date: Fri, 29 Jan 2010 14:50:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: isms 
Subject: Re: [Isms] 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: Fri, 29 Jan 2010 18:41:21 -0000

Almost

tlstmCertSANIpAddress OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps a subjectAltName's iPAddress to a
should I think be 
tlstmCertSANIPAddress
here, and in tlstmCertSANAny.

and Wes said 25Jan2010
 
              + I didn't include a reference to the
                 draft-saintandre-tls-server-id-check document since
                 we're unsure of it's future progress and it's not the
                 only way that an identity could be checked.

In fact, there are still references to the I-D both in the MIB module and
in the earlier text.  I am ok with that, my previous problem was the 
contradiction between that I-D as it currently stands and with 
the MIB module but that contradiction has now gone. 

Tom Petch

----- Original Message ----- 
From: "Juergen Schoenwaelder" 
To: "Wes Hardaker" 
Cc: 
Sent: Friday, January 29, 2010 12:37 PM
Subject: Re: [Isms] updated TLS drafts published: -06 and -07


> 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 like to ask everybody to check the edits and to raise any issues
> with the edits by Tuesday 2nd the latest.
> 
> /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 wjhns1@hardakers.net  Fri Jan 29 11:22:25 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBE33A6A41 for ; Fri, 29 Jan 2010 11:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx1ARJtu0vKW for ; Fri, 29 Jan 2010 11:22:24 -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 14DF53A6961 for ; Fri, 29 Jan 2010 11:22:23 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C65689B734; Fri, 29 Jan 2010 11:22:43 -0800 (PST)
From: Wes Hardaker 
To: "tom.petch" 
Organization: Sparta
References:  <20100129113734.GF96725@elstar.local> <000601caa10a$45e59860$0601a8c0@allison>
Date: Fri, 29 Jan 2010 11:22:43 -0800
In-Reply-To: <000601caa10a$45e59860$0601a8c0@allison> (tom petch's message of "Fri, 29 Jan 2010 14:50:03 +0100")
Message-ID: 
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: isms 
Subject: Re: [Isms] 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: Fri, 29 Jan 2010 19:22:25 -0000

>>>>> On Fri, 29 Jan 2010 14:50:03 +0100, "tom.petch"  said:

tp> Almost

I'm not sure what "almost" means there and whether you expect action
based on it.

tp> + I didn't include a reference to the
tp> draft-saintandre-tls-server-id-check document
...

I should have said "hard reference" there.  We do use "fuzzy references"
for a number of things to allow other architectures to be used where we
don't require a hard-reference ("this and only this" reference).
-- 
Wes Hardaker
Cobham Analytic Solutions

From wjhns1@hardakers.net  Fri Jan 29 11:28: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 65C683A6A41 for ; Fri, 29 Jan 2010 11:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTztnnxeBoxk for ; Fri, 29 Jan 2010 11:28:21 -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 925403A6838 for ; Fri, 29 Jan 2010 11:28:21 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 787D49B79F; Fri, 29 Jan 2010 11:28:44 -0800 (PST)
From: Wes Hardaker 
To: "tom.petch" 
Organization: Sparta
References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local>  <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com>   <002001caa0b8$2586d360$0601a8c0@allison> <20100129110715.GB96725@elstar.local>
Date: Fri, 29 Jan 2010 11:28:44 -0800
In-Reply-To: <20100129110715.GB96725@elstar.local> (Juergen Schoenwaelder's message of "Fri, 29 Jan 2010 12:07:17 +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] TLSTM counters issue
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, 29 Jan 2010 19:28:22 -0000

>>>>> On Fri, 29 Jan 2010 12:07:17 +0100, Juergen Schoenwaelder  said:

JS> NIT: Step 4) in section 5.2 refers to a step 4b) which I think should
JS> be 5b).

JS> NIT: There are references to snmpTlstmSessionOpenErrors which has been
JS> renamed; we need to make sure that renamings are applied
JS> everywhere.

FYI, I just fixed those; thanks for catching them.  I've also verified
that any reference to any of the older names don't exist besides the two
references to snmpTlstmSessionOpenErrors, both of which were changed to
snmpTlstmSessionClientOpenErrors.
-- 
Wes Hardaker
Cobham Analytic Solutions

From wjhns1@hardakers.net  Fri Jan 29 11:31: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 C93B23A6A6C for ; Fri, 29 Jan 2010 11:31:11 -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 WiLTbCFLAlQw for ; Fri, 29 Jan 2010 11:31:10 -0800 (PST)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 4AA9C3A6A67 for ; Fri, 29 Jan 2010 11:31:10 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 220799B7A9; Fri, 29 Jan 2010 11:31:33 -0800 (PST)
From: Wes Hardaker 
To: "David Harrington" 
Organization: Sparta
References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local>  <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com>   <002001caa0b8$2586d360$0601a8c0@allison> <20100129110715.GB96725@elstar.local> <073f01caa0e8$adc758a0$0600a8c0@china.huawei.com>
Date: Fri, 29 Jan 2010 11:31:32 -0800
In-Reply-To: <073f01caa0e8$adc758a0$0600a8c0@china.huawei.com> (David Harrington's message of "Fri, 29 Jan 2010 08:40:53 -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] TLSTM counters issue
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, 29 Jan 2010 19:31:11 -0000

>>>>> On Fri, 29 Jan 2010 08:40:53 -0500, "David Harrington"  said:

>> Well, the current text in 3a) in section 5.3 leaves it implementation
>> specific how the counter is incremented, that is whether this is
>> delayed until the first payload arrives or not. At least that is my
>> reading. You have a problem with that?

DH> I think the serveropens should be tied to the first message received;
DH> I don't think we assign a sessionID until there is an incoming
DH> message.

I think you need to be careful there in the wording, because the
different sides treat things differently:

1) client: openSession() is used and the sessionID is established there
   (step 4).

2) server: currently implementation dependent as to when the sessionID
   is established.  I think the consensus is currently leaning toward
   fixing this so that in the "processing incoming" section we detect a
   missing sessionID and discuss assigning it *then* and incrementing
   the counter *then*.

   I'll work on text for that, but I suspect that this is what everyone
   would prefer?

-- 
Wes Hardaker
Cobham Analytic Solutions

From wjhns1@hardakers.net  Fri Jan 29 11:32:56 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EC13A6A75 for ; Fri, 29 Jan 2010 11:32:56 -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 xCjk1fAQAVxe for ; Fri, 29 Jan 2010 11:32:55 -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 939A03A6A67 for ; Fri, 29 Jan 2010 11:32:55 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6C9CE9B797; Fri, 29 Jan 2010 11:33:18 -0800 (PST)
From: Wes Hardaker 
To: Wes Hardaker 
Organization: Sparta
References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local>  <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com>    <20100127232839.GB92073@elstar.local>
Date: Fri, 29 Jan 2010 11:33:18 -0800
In-Reply-To: <20100127232839.GB92073@elstar.local> (Juergen Schoenwaelder's message of "Thu, 28 Jan 2010 00:28:39 +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: Jeffrey Hutzelman , "isms@ietf.org" , Robert Story 
Subject: Re: [Isms] TLSTM counters issue
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, 29 Jan 2010 19:32:56 -0000

>>>>> On Thu, 28 Jan 2010 00:28:39 +0100, Juergen Schoenwaelder  said:

JS> I do not think a separate ID is needed for every change.

Needed, no.  But it's certainly helpful to read the specific changes
associated with that delta since it was so recently discussed and
everyone was concerned about it.

The whole purpose of the "rapid update" and "diff viewer" of the tools
page is specifically for helping discussions like this one where when
we're at the wire we need to be very accurate in what we're talking
about.

There is no negative that I know of, on the other hand.

-- 
Wes Hardaker
Cobham Analytic Solutions

From randy_presuhn@mindspring.com  Fri Jan 29 11:32:59 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 C28793A6A6D for ; Fri, 29 Jan 2010 11:32:59 -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 vJvEkLqHYyNF for ; Fri, 29 Jan 2010 11:32:59 -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 004A33A6A67 for ; Fri, 29 Jan 2010 11:32:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IQ/PYnGnEIO610kdjrTQQO8umAhD9jlEpBIoMlufd/vkNiwDjvhWLiqL6yI5UqN4; 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.33.94.231] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nawan-0000U2-Rs for isms@ietf.org; Fri, 29 Jan 2010 14:33:22 -0500
Message-ID: <003f01caa11a$70086360$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "isms" 
References: <20100120122622.GA806@elstar.local> <002501caa091$55b97500$6801a8c0@oemcomputer> <000201caa0d5$599b2b20$0601a8c0@allison>
Date: Fri, 29 Jan 2010 11:37:04 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a94b98c427cc2f375448a07ea92a415d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
Subject: Re: [Isms] JSt: legalese for embedding in MIB modules
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, 29 Jan 2010 19:32:59 -0000

Hi -

> From: "tom.petch" 
> To: "Randy Presuhn" ; "isms" 
> Sent: Friday, January 29, 2010 2:57 AM
> Subject: Re: [Isms] JSt: legalese for embedding in MIB modules
...
> Try the attached e-mail from Jorge to the IETF list in December last.

Current text is:
                  Copyright (C) The Internet Society (2009)."

Is the proposal to make it say this?
                  Copyright (C) The Internet Society 2010.  This version of
                  this MIB module is part of RFC XXXX; see the RFC itself for
                  full legal notices."

> A new Trust Legal Provisions has come out since then but it, like all of them
> and unlike RFC3978, does not include any section on Legends to be Included in
> Code Components in an IETF Document.
> 
> Perhaps we need to revise the Trust Legal Provisions (again:-).

But not here, please!

Randy


From wjhns1@hardakers.net  Fri Jan 29 11:35: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 E76A93A68AA for ; Fri, 29 Jan 2010 11:35:33 -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 iMGDTY7j5PUZ for ; Fri, 29 Jan 2010 11:35:33 -0800 (PST)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 1E80C3A681E for ; Fri, 29 Jan 2010 11:35:33 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 07B7F9B7C0; Fri, 29 Jan 2010 11:35:56 -0800 (PST)
From: Wes Hardaker 
To: "tom.petch" 
Organization: Sparta
References: <20100126134324.GA54185@elstar.local> <20100126094544.4677fd47@sparta.com> <20100126150151.GB54456@elstar.local> <20100126111148.586f5228@sparta.com> <20100127115031.GA90288@elstar.local>  <11639_1264609336_o0RGMFPu029007_060601ca9f6c$dfb84400$0600a8c0@china.huawei.com>   <002001caa0b8$2586d360$0601a8c0@allison> <20100129110715.GB96725@elstar.local>
Date: Fri, 29 Jan 2010 11:35:55 -0800
In-Reply-To: <20100129110715.GB96725@elstar.local> (Juergen Schoenwaelder's message of "Fri, 29 Jan 2010 12:07:17 +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] TLSTM counters issue
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, 29 Jan 2010 19:35:34 -0000

>>>>> On Fri, 29 Jan 2010 12:07:17 +0100, Juergen Schoenwaelder  said:

JS> But this sounds like a wording issue. I personally agree that
JS> snmpTlstmSessionServerOpens is a somewhat unfortunate choice.

I actually don't like it either, and I'd be happy to change it.  The
name was chosen because it was suggested as a name to use.

JS> A server accepts sessions, it does not open them.

Well, I'd actually disagree with the wording semantics.  Both sides
actually need to "open" the connection to some extent and neither side
can fulfill the "opening" of the session entirely by themselves.

snmpTlstmSessionServerAccepts doesn't seem right either.
snmpTlstmSessionServerEstablishments is probably closer, though over 32
characters.

Opinions welcome :-)
-- 
Wes Hardaker
Cobham Analytic Solutions

From wjhns1@hardakers.net  Fri Jan 29 11:38: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 711973A6925 for ; Fri, 29 Jan 2010 11:38: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=[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 9seNEGcHhLZ5 for ; Fri, 29 Jan 2010 11:38:35 -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 8010E3A67F2 for ; Fri, 29 Jan 2010 11:38:35 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6EE2B9B7CE; Fri, 29 Jan 2010 11:38:58 -0800 (PST)
From: Wes Hardaker 
To: "Randy Presuhn" 
Organization: Sparta
References: <20100120122622.GA806@elstar.local> <002501caa091$55b97500$6801a8c0@oemcomputer> <000201caa0d5$599b2b20$0601a8c0@allison> <003f01caa11a$70086360$6801a8c0@oemcomputer>
Date: Fri, 29 Jan 2010 11:38:58 -0800
In-Reply-To: <003f01caa11a$70086360$6801a8c0@oemcomputer> (Randy Presuhn's message of "Fri, 29 Jan 2010 11:37:04 -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 
Subject: Re: [Isms] JSt: legalese for embedding in MIB modules
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, 29 Jan 2010 19:38:36 -0000

>>>>> On Fri, 29 Jan 2010 11:37:04 -0800, "Randy Presuhn"  said:

RP> Is the proposal to make it say this?
RP> Copyright (C) The Internet Society 2010.  This version of
RP> this MIB module is part of RFC XXXX; see the RFC itself for
RP> full legal notices."

The wording I was told (by Juergen) was the right wording for the top of
the MIB was the following for the DTLS draft:

        Copyright (c) FILLYEAR IETF Trust and the persons identified as
        the document authors.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        This version of this MIB module is part of RFC XXXX;
        see the RFC itself for full legal notices."

-- 
Wes Hardaker
Cobham Analytic Solutions

From randy_presuhn@mindspring.com  Fri Jan 29 11:48: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 927163A6803 for ; Fri, 29 Jan 2010 11:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3stTQ5ERFdp for ; Fri, 29 Jan 2010 11:48:51 -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 A8E6B3A6800 for ; Fri, 29 Jan 2010 11:48:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZeWD8KXXm3IFWWM4tYCJc6v4I/KbzhMzjk/jay2qSGEAT6E9wMZj19uer1HakhIT; 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.33.94.231] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NawqA-0000oM-Kc for isms@ietf.org; Fri, 29 Jan 2010 14:49:14 -0500
Message-ID: <007d01caa11c$a80a8b60$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "isms" 
References: <20100120122622.GA806@elstar.local><002501caa091$55b97500$6801a8c0@oemcomputer><000201caa0d5$599b2b20$0601a8c0@allison><003f01caa11a$70086360$6801a8c0@oemcomputer> 
Date: Fri, 29 Jan 2010 11:52:56 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b407bcf151d08402c4e8705f3ca4bd0c7cb350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
Subject: Re: [Isms] JSt: legalese for embedding in MIB modules
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, 29 Jan 2010 19:48:52 -0000

Hi -

Ok, unless someone objects, I'll use the incantation Wes provided.

Randy

> From: "Wes Hardaker" 
> To: "Randy Presuhn" 
> Cc: "isms" 
> Sent: Friday, January 29, 2010 11:38 AM
> Subject: Re: JSt: legalese for embedding in MIB modules
>
> >>>>> On Fri, 29 Jan 2010 11:37:04 -0800, "Randy Presuhn"  said:
> 
> RP> Is the proposal to make it say this?
> RP> Copyright (C) The Internet Society 2010.  This version of
> RP> this MIB module is part of RFC XXXX; see the RFC itself for
> RP> full legal notices."
> 
> The wording I was told (by Juergen) was the right wording for the top of
> the MIB was the following for the DTLS draft:
> 
>         Copyright (c) FILLYEAR IETF Trust and the persons identified as
>         the document authors.  All rights reserved.
> 
>         Redistribution and use in source and binary forms, with or
>         without modification, is permitted pursuant to, and subject
>         to the license terms contained in, the Simplified BSD License
>         set forth in Section 4.c of the IETF Trust's Legal Provisions
>         Relating to IETF Documents
>         (http://trustee.ietf.org/license-info).
> 
>         This version of this MIB module is part of RFC XXXX;
>         see the RFC itself for full legal notices."
> 
> -- 
> Wes Hardaker
> Cobham Analytic Solutions


From randy_presuhn@mindspring.com  Fri Jan 29 14:29:41 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EC83A67E1 for ; Fri, 29 Jan 2010 14:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtXI1CNivQNY for ; Fri, 29 Jan 2010 14:29:40 -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 45EF73A677C for ; Fri, 29 Jan 2010 14:29:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d1bF4ie1uCZMY/pOXp3/CxiadgAjrrGOkTDH+8mlfWvXoKTT/v/v89byTWQx55X8; 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.33.94.231] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NazLk-0004Bf-Ly for isms@ietf.org; Fri, 29 Jan 2010 17:30:02 -0500
Message-ID: <002301caa133$1dc60080$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20100120122622.GA806@elstar.local> <000b01caa082$a6b2aa80$6801a8c0@oemcomputer> <074001caa0eb$00dc0b60$0600a8c0@china.huawei.com> <20100129152009.GB97812@elstar.local> <075101caa0fd$778782a0$0600a8c0@china.huawei.com>
Date: Fri, 29 Jan 2010 14:33:43 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40dc8896b988c1d8ae8c15cc372a31b86f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
Subject: Re: [Isms] JSa: 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: Fri, 29 Jan 2010 22:29:41 -0000

Hi -

While I very much agree with Juergen's point about excessive number
of "top level" sections, I don't think this is the place to try to change
MIB document practice.  (The complete lack of comments on
draft-presuhn-opsawg-rfc4181bis-03.txt suggests that there is
no groundswell of support for revisiting the issue.)

So, here's what I intend to do as editor: collapse the current 1.1
into section 1. 

Randy

----- Original Message ----- 
> From: "David Harrington" 
> To: "'Juergen Schoenwaelder'" 
> Cc: "'Randy Presuhn'" ; 
> Sent: Friday, January 29, 2010 8:09 AM
> Subject: RE: [Isms] JSa: structure
>
> Hi,
> 
> I recommend that the current 1.1 General section be the 1. section.
> It has more than one sentence.
> section 2 has more than one sentence.
> section 3 is the only one with a single sentence, but the RFC2119
> boilerplate is often in its own section in IETF documents, and the
> xml2rfc template published by the EDU team puts this in a separate
> section.
> section 4 and higher would all have more than one sentence.
> So I don't see the issue of one-sentence sections.
> 
> BCP 139 went through MIB Doctor and gen-art and secdir reviews, plus
> AD, IESG, IETF LC and RFC editor reviews, plus an Alfred Hines review,
> and the consensus was to approve the structure used in the template.
> 
> I am not promoting this as the best design; nor am I saying it is not
> - personally, I don't much care. I am responding to Randy's request
> for feedback. As editor, I documented the consensus on the design. The
> IETF and its leadership approved this as a BCP.  This is the format
> recommended for use in new MIB documents. I think we should have a
> solid reason for ignoring the IETF consensus on the BCP, especially
> since many of us are recognized as leaders in the MIB domain.
> 
> I don't see that your opinion represents the IETF consensus. But
> you're the chair, and if you want to impose your personal preference
> over the consensus of the rest of the IETF, I suppose that's in your
> power.  
> 
> I just don't really see an issue here, myself.
> 
> dbh
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder 
> > [mailto:j.schoenwaelder@jacobs-university.de] 
> > Sent: Friday, January 29, 2010 10:20 AM
> > To: David Harrington
> > Cc: 'Randy Presuhn'; isms@ietf.org
> > Subject: Re: [Isms] JSa: structure
> > 
> > On Fri, Jan 29, 2010 at 02:57:32PM +0100, David Harrington wrote:
> > > Hi,
> > > 
> > > I agree the 1.1 numbering and indent is not needed; just 
> > promote it to
> > > 1.
> > > So you should have:
> > > 1.  Introduction
> > > 2.  The Internet-Standard Management Framework 
> > > 3.  Conventions
> > > 4.  Overview
> > > 
> > > RFC4181 (BCP 111) only says that the MIB boilerplate must 
> > be included.
> > > RFC5249 (BCP 139) points to the MIB document templates at
> > > tools.ietf.org. 
> > > The templates show:
> > > --start--
> > > 1.  Introduction
> > > 
> > >    This memo defines a portion of the Management Information Base
> > > (MIB)
> > >    for use with network management protocols.  In particular it
> > > defines
> > >    objects for managing the [TEMPLATE TODO].
> > > 
> > > 2.  The Internet-Standard Management Framework
> > > 
> > >    For a detailed overview of the documents that describe 
> > the current
> > >    Internet-Standard Management Framework, please refer to section
> 7
> > > of
> > >    RFC 3410 [RFC3410].
> > > 
> > >    Managed objects are accessed via a virtual information store,
> > > termed
> > >    the Management Information Base or MIB.  MIB objects are 
> > generally
> > >    accessed through the Simple Network Management Protocol (SNMP).
> > >    Objects in the MIB are defined using the mechanisms 
> > defined in the
> > >    Structure of Management Information (SMI).  This memo specifies
> a
> > > MIB
> > >    module that is compliant to the SMIv2, which is described in
> STD
> > > 58,
> > >    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 
> > 58, RFC 2580
> > >    [RFC2580].
> > > 
> > > 3.  Conventions
> > > 
> > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
> > "SHALL NOT",
> > >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> > > this
> > >    document are to be interpreted as described in RFC 2119 
> > [RFC2119].
> > > 
> > > 4.  Overview
> > > 5.  Structure of the MIB Module
> > > etc.
> > > --end --
> > > 
> > > dbh
> > 
> > I personally strongly dislike one sentence top-level sections. And
> > having this level of document structure prescribed does not really
> > solve any problem I can think of.
> > 
> > /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 Jan 29 14:49: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 6AA123A68A9 for ; Fri, 29 Jan 2010 14:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VVUxiFYRi+Zv for ; Fri, 29 Jan 2010 14:49:49 -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 46C403A688A for ; Fri, 29 Jan 2010 14:49:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=moh5hPhffaJcErfWMehATg1PAvpURh9seb41MS1d6pdPGrtZsGcFvFLfQvd1WeBe; 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.33.94.231] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NazfI-0000y7-BK for isms@ietf.org; Fri, 29 Jan 2010 17:50:12 -0500
Message-ID: <004601caa135$f0024660$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20100120122622.GA806@elstar.local><001701caa08f$8599d820$6801a8c0@oemcomputer> 
Date: Fri, 29 Jan 2010 14:53:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40ee34a0dbee0abeb6f13332e83977191e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
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: Fri, 29 Jan 2010 22:49:50 -0000

Hi -

Ok,  using some of Dave's words, I'll update the procedural text to
say:

   The value used for vacmSecurityModel is the registered value for
   the security model in use.
   Note that the security model SHOULD be one
   which binds principal identity to access control policy via an
   external AAA server, such as the Transport Security Model.  To
   do otherwise potentially creates a security risk.

I think SHOULD ("if you don't do this, you should have a really really good
reason") is appropriate.  I could be persuaded to say MUST, but I think
that is overkill.  (I could imagine using a service that didn't use an external
AAA server without introducing additional risk.)


Randy

----- Original Message ----- 
> From: "Dave Nelson" 
> To: 
> Sent: Friday, January 29, 2010 5:49 AM
> Subject: Re: [Isms] JSo: hard-wire to TSM?
>
> > As a technical contributor, I'd suggest that it should simply
> > use the value of SnmpSecurityModel that was registered with the
> > security model in use, rather than specifying the exact value 
> > here.
> 
> With caveats, that's probably OK.
> 
> > For the reason you describe, I'd prefer to treat TSM as an
> > example, rather than a normative requirement, throughout this
> > document.
> 
> Yes, but not all security models have the same security properties.  Given
> that the premise of this document is to bind principal identity to access
> control policy via an external AAA server, it makes no sense to apply the
> mechanism described in this document to non-AAA-aware security models.  I
> agree that tying this usage to a *specific* security model is undesirable,
> for all the usual SNMP architectural modularity reasons.  However, I think
> there is a normative requirement to tie it to a *class* of security models
> that embrace principal authentication via AAA services, such as RADIUS.
> Otherwise, I feel we will create a significant security risk.
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms


From dnelson@elbrysnetworks.com  Fri Jan 29 15:09:48 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 E353D3A67FE for ; Fri, 29 Jan 2010 15:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level: 
X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.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 yUlIp0c17Yze for ; Fri, 29 Jan 2010 15:09:48 -0800 (PST)
Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id DE44E3A67B2 for ; Fri, 29 Jan 2010 15:09:47 -0800 (PST)
Received: (qmail 26021 invoked from network); 29 Jan 2010 23:10:07 -0000
Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 29 Jan 2010 23:10:07 -0000
From: "David B. Nelson" 
To: "Randy Presuhn" 
In-Reply-To: <004601caa135$f0024660$6801a8c0@oemcomputer>
X-Priority: 3
References: <20100120122622.GA806@elstar.local><001701caa08f$8599d820$6801a8c0@oemcomputer>  <004601caa135$f0024660$6801a8c0@oemcomputer>
Message-Id: <535F86B2-A867-4E16-AB94-E7FC123AFD1C@elbrysnetworks.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 29 Jan 2010 18:10:07 -0500
X-Mailer: Apple Mail (2.936)
Cc: isms@ietf.org
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: Fri, 29 Jan 2010 23:09:49 -0000

On Jan 29, 2010, at 5:53 PM, Randy Presuhn wrote:

> I think SHOULD ("if you don't do this, you should have a really  
> really good
> reason") is appropriate.  I could be persuaded to say MUST, but I  
> think
> that is overkill.  (I could imagine using a service that didn't use  
> an external
> AAA server without introducing additional risk.)

Could you elaborate on such a use case?

It's true that the mechanisms described in this document could be used  
with something other than RADIUS (or another AAA) to dynamically  
provision access control policy for specific principals.  It seems to  
me, however, that unless that other "something" has a a very solid  
basis to know that principal "foo" as identified via the access  
control system ASI is the same "foo" as has been mapped in the VACM  
tables, there exists the risk of one "foo" impersonating another.  In  
other words, in order to assure that the proper access rights are  
being conferred, it is necessary for the "binding" of the two  
instances of identity to be secure.  That might be obtained in a very  
controlled environment, without making the restriction that the same  
AAA service is involved in the authentication and authorization  
phases, but that seems to be a very special case indeed.



From randy_presuhn@mindspring.com  Fri Jan 29 15: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 3D91328C0ED for ; Fri, 29 Jan 2010 15: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 bR+V-Rc9eO3b for ; Fri, 29 Jan 2010 15:50:43 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2D23E3A698F for ; Fri, 29 Jan 2010 15:50:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ApVGMEyky8+aOslw/ctysGG7TpDsrwJPBs5MhQ3QLzbJA3kNC9yKHzJRN8fVcn4y; 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.33.94.231] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nb0cE-0004qf-Ju for isms@ietf.org; Fri, 29 Jan 2010 18:51:06 -0500
Message-ID: <004d01caa13e$72136b40$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20100120122622.GA806@elstar.local> <003101caa09a$7a8191c0$6801a8c0@oemcomputer> 
Date: Fri, 29 Jan 2010 15:54:49 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4001c5847c68773bde9ba92e1ce933e4d1350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
Subject: Re: [Isms] JSu: table simplification
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, 29 Jan 2010 23:50:44 -0000

Hi -

A few second-level questions emerge, based on these answers.

> From: "David B. Nelson" 
> To: "Randy Presuhn" 
> Cc: 
> Sent: Friday, January 29, 2010 8:08 AM
> Subject: Re: [Isms] JSu: table simplification
....
> >   (1) does the user->group mapping supplied by RADIUS apply
> >         (a) only to the specific security model that triggered the  
> >              retrieval

It sounds like we're agreed on this as the path for now.
I think this means we can get rid of extVacmRowCreatedBy,
because its redundant with respect to extVacmSecurityModel,
which is redundant with respect to vacmSecurityModel.

> >  (2) when a new mapping arriving from RADIUS refers to a  
> > (vacmSecurityModel,
> >        vacmSecurityName) pair for which an entry already exists in the
> >        vacmSecurityToGroupTable, do we
> >        (a) ignore it, and honor the administratively configured  
> > settings
> 
> Probably yes, on the assumption that the system administrator /  
> security administrator intended this local override  I think it is  
> important that this increment a counter, as it might equally well be  
> the result of a misconfiguration.

Ok.  For now, let's go with choice (a).  That reduces the need for
extVacmSecurityToGroupStatus.


Making the counter *useful* would be a bit tougher.
A scalar won't tell us which securityModel / securityName pair is
having trouble - the security administrator would have to scan the
vacmSecurityToGroupTable to find possible conflicts.  If we're
really worried about this case, a notification might make more
sense than a counter.  (Though perhaps pathological if the session
in question is one for carrying outbound notifications.  :-)

I'm not convinced that the counters we currently have would
really be terribly useful, even though I do agree that being
able to know when this situation is occurring is important.

...
> >  (3) does it make sense for data delivered by RADIUS to be made
> >        persistent / nonvolatile?
> 
> No.  I see no valid use case for that approach.

Ok, we can eliminate  extVacmSecurityToGroupStorageType.
 
> >  (4) Do we provide a way to administratively purge RADIUS-provided  
> > data?
> >        (e.g., force immediate expiration / cleanup of created entries)
> 
> Umm.. maybe It's called reboot.  :-)  Generally speaking, customers  
> will use RADIUS because that's where their user authentication,  
> authorization and policy data resides.  I think situations in which  
> customer will want to circumvent RADIUS authorization are indeed  
> corner cases.  They either use RADIUS in their network infrastructure  
> or they don't.  You would need a "back-up" means of AAA, of course,  
> for when RADIUS is unreachable, and that might be via USM

Ok, then we can eliminate extVacmSecurityToGroupStatus.

> >  (5) how is the lifetime of information from RADIUS-land managed?
> >        (a) a lifetime is provided by RADIUS, clean up on expiry
> 
> That's what RFC 5607 specifies.
> 
> >        (b) lifetime is that of corresponding connection(s), clean up
> >              on termination of last connection using an entry
> 
> If there is a reliable way to determine that the data is no longer in  
> use, e;;g. that all "connections" relying on that data have  
> terminated, then that might also be considered.
> 
> >   (6) how much of the internal processing do we need/want to make
> >         externally visible?
> 
> I don't understand.

(5) and (6) go together.  The only reason I can see for making
extVacmTransportSessionID visible would be as an index
as part of a (5b) strategy.  If we go with (5a), AND if we
update extVacmRowLifetime whenever (for this
user/model combination) a Lifetime value arrives which is
greater than the current one, then we can eliminate
extVacmTransportSessionID.

I think I understand the edits.  :-)  Should I go ahead and
post an update?

Randy


From randy_presuhn@mindspring.com  Fri Jan 29 16:00:43 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E29E3A6978 for ; Fri, 29 Jan 2010 16:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OR4I9UKOTa8t for ; Fri, 29 Jan 2010 16:00:42 -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 8096F3A6829 for ; Fri, 29 Jan 2010 16:00:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mfc0kx5m8KAnx/PKjRlC4+jApHDLpfa04AK9qKvvW8otoPEeNiOox9lPjQiIskjX; 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.33.94.231] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nb0lu-0005Ub-3n for isms@ietf.org; Fri, 29 Jan 2010 19:01:06 -0500
Message-ID: <005401caa13f$d7ae0cc0$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20100120122622.GA806@elstar.local><001701caa08f$8599d820$6801a8c0@oemcomputer>  <004601caa135$f0024660$6801a8c0@oemcomputer> <535F86B2-A867-4E16-AB94-E7FC123AFD1C@elbrysnetworks.com>
Date: Fri, 29 Jan 2010 16:04:49 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40cc6a6584eecde5705f1c8fe36e386ab1350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
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: Sat, 30 Jan 2010 00:00:43 -0000

Hi -

> From: "David B. Nelson" 
> To: "Randy Presuhn" 
> Cc: 
> Sent: Friday, January 29, 2010 3:10 PM
> Subject: Re: [Isms] JSo: hard-wire to TSM?
>
> On Jan 29, 2010, at 5:53 PM, Randy Presuhn wrote:
> 
> > I think SHOULD ("if you don't do this, you should have a really  
> > really good
> > reason") is appropriate.  I could be persuaded to say MUST, but I  
> > think
> > that is overkill.  (I could imagine using a service that didn't use  
> > an external
> > AAA server without introducing additional risk.)
> 
> Could you elaborate on such a use case?
> 
> It's true that the mechanisms described in this document could be used  
> with something other than RADIUS (or another AAA) to dynamically  
> provision access control policy for specific principals.  It seems to  
> me, however, that unless that other "something" has a a very solid  
> basis to know that principal "foo" as identified via the access  
> control system ASI is the same "foo" as has been mapped in the VACM  
> tables, there exists the risk of one "foo" impersonating another.  In  
> other words, in order to assure that the proper access rights are  
> being conferred, it is necessary for the "binding" of the two  
> instances of identity to be secure.  That might be obtained in a very  
> controlled environment, without making the restriction that the same  
> AAA service is involved in the authentication and authorization  
> phases, but that seems to be a very special case indeed.

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.

Randy


From wjhns1@hardakers.net  Fri Jan 29 17:23: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 2E9653A67D7 for ; Fri, 29 Jan 2010 17:23:20 -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 VgwXR1dSXRJ9 for ; Fri, 29 Jan 2010 17:23:18 -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 381783A6774 for ; Fri, 29 Jan 2010 17:23:17 -0800 (PST)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 12FBF9B82A for ; Fri, 29 Jan 2010 17:23:41 -0800 (PST)
From: Wes Hardaker 
To: isms@ietf.org
Organization: Sparta
Date: Fri, 29 Jan 2010 17:23:40 -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
Subject: [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: Sat, 30 Jan 2010 01:23:20 -0000

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.  I'll want to read them
once more before I consider them done when my head is fresh again.  I'll
publish a new copy Monday-ish.

Counters:

  snmpTlstmSession           OBJECT IDENTIFIER ::= { tlstmObjects 1 }

  snmpTlstmSessionOpens  OBJECT-TYPE
      SYNTAX       Counter32
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
         "The number of times an openSession() request has been
         executed as an (D)TLS client, whether it succeeded or failed."
      ::= { snmpTlstmSession 1 }

  snmpTlstmSessionClientCloses  OBJECT-TYPE
      SYNTAX       Counter32
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
          "The number of times a closeSession() request has been
          executed as an (D)TLS client, whether it succeeded or failed."
      ::= { snmpTlstmSession 2 }

  snmpTlstmSessionOpenErrors  OBJECT-TYPE
      SYNTAX       Counter32
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
          "The number of times an openSession() request failed to open a
          session as a (D)TLS client, for any reason."
      ::= { snmpTlstmSession 3 }

  snmpTlstmSessionAccepts  OBJECT-TYPE
      SYNTAX       Counter32
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
         "The number of times a server has accepted a (D)TLS session and
         at least one SNMP message has been accepted through it."
      ::= { snmpTlstmSession 4 }

  snmpTlstmSessionServerCloses  OBJECT-TYPE
      SYNTAX       Counter32
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
          "The number of times a closeSession() request has been
          executed as an (D)TLS server, whether it succeeded or failed."
      ::= { snmpTlstmSession 5 }

Incoming processing:

  5.1.2.  Transport Processing for Incoming SNMP Messages

     The procedures in this section describe how the TLS Transport Model
     should process messages that have already been properly extracted
     from the (D)TLS stream.  Note that care must be taken when processing
     messages originating from either TLS or DTLS to ensure they're
     complete and single.  For example, multiple SNMP messages can be
     passed through a single DTLS message and partial SNMP messages may be
     received from a TLS stream.  These steps describe the processing of a
     singular SNMP message after it has been delivered from the (D)TLS
     stream.

     1)  Determine the tlstmSessionID for the incoming message.  The
         tlstmSessionID MUST be a unique session identifier for this
         (D)TLS connection.  The contents and format of this identifier
         are implementation-dependent as long as it is unique to the
         session.  A session identifier MUST NOT be reused until all
         references to it are no longer in use.  The tmSessionID is equal
         to the tlstmSessionID discussed in Section 5.1.1. tmSessionID
         refers to the session identifier when stored in the
         tmStateReference and tlstmSessionID refers to the session
         identifier when stored in the LCD.  They MUST always be equal
         when processing a given session's traffic.

         If this is the first message received through this session and
         the session does not have an assigned tlstmSessionID yet then the
         snmpTlstmSessionAccepts counter is incremented and a
         tlstmSessionID for the session is created.  This will only happen
         on the server side of a connection because a client would have
         already assigned a tlstmSessionID during the openSession()
         invocation.  Implementations may have performed the procedures
         described in Section 5.3.2 prior to this point or they may
         perform them now, but the procedures described in Section 5.3.2
         MUST be performed before continuing beyond this point.

     2)  Create a tmStateReference cache for the subsequent reference and
         assign the following values within it:

         tmTransportDomain  = snmpTLSTCPDomain, snmpDTLSUDPDomain or
            snmpDTLSSCTPDomain as appropriate.

         tmTransportAddress  = The address the message originated from.

         tmSecurityLevel  = The derived tmSecurityLevel for the session,
            as discussed in Section 3.1.2 and Section 5.3.

         tmSecurityName  = The derived tmSecurityName for the session as
            discussed in Section 5.3.  This value MUST be constant during
            the lifetime of the (D)TLS session.

         tmSessionID  = The tlstmSessionID described in step 1 above.

     3)  The incomingMessage and incomingMessageLength are assigned values
         from the (D)TLS processing.

     4)  The TLS Transport Model passes the transportDomain,
         transportAddress, incomingMessage, and incomingMessageLength to
         the Dispatcher using the receiveMessage ASI:

         statusInformation =
         receiveMessage(
         IN   transportDomain     -- snmpTLSTCPDomain, snmpDTLSUDPDomain,
                                  -- or snmpDTLSSCTPDomain
         IN   transportAddress    -- address for the received message
         IN   incomingMessage        -- the whole SNMP message from (D)TLS
         IN   incomingMessageLength  -- the length of the SNMP message
         IN   tmStateReference    -- transport info
          )

Establishing Section:

  5.3.  Establishing or Accepting a Session

     Establishing a (D)TLS session as either a client or a server requires
     slightly different processing.  The following two sections describe
     the necessary processing steps.

  5.3.1.  Establishing a Session as a Client

     The TLS Transport Model provides the following primitive for use by a
     client to establish a new (D)TLS session:


     statusInformation =           -- errorIndication or success
     openSession(
     IN   tmStateReference         -- transport information to be used
     OUT  tmStateReference         -- transport information to be used
     IN   maxMessageSize           -- of the sending SNMP entity
     )

     The following describes the procedure to follow when establishing a
     SNMP over (D)TLS session between SNMP engines for exchanging SNMP
     messages.  This process is followed by any SNMP client's engine when
     establishing a session for subsequent use.

     This MAY be done automatically for an SNMP application that initiates
     a transaction, such as a command generator, a notification
     originator, or a proxy forwarder.

     1)  The snmpTlstmSessionOpens counter is incremented.

     2)  The client selects the appropriate certificate and cipher_suites
         for the key agreement based on the tmSecurityName and the
         tmRequestedSecurityLevel for the session.  For sessions being
         established as a result of a SNMP-TARGET-MIB based operation, the
         certificate will potentially have been identified via the
         tlstmParamsTable mapping and the cipher_suites will have to be
         taken from system-wide or implementation-specific configuration.
         Otherwise, the certificate and appropriate cipher_suites will
         need to be passed to the openSession() ASI as supplemental
         information or configured through an implementation-dependent
         mechanism.  It is also implementation-dependent and possibly
         policy-dependent how tmRequestedSecurityLevel will be used to
         influence the security capabilities provided by the (D)TLS

         session.  However this is done, the security capabilities
         provided by (D)TLS MUST be at least as high as the level of
         security indicated by the tmRequestedSecurityLevel parameter.
         The actual security level of the session is reported in the
         tmStateReference cache as tmSecurityLevel.  For (D)TLS to provide
         strong authentication, each principal acting as a command
         generator SHOULD have its own certificate.

     3)  Using the destTransportDomain and destTransportAddress values,
         the client will initiate the (D)TLS handshake protocol to
         establish session keys for message integrity and encryption.

         If the attempt to establish a session is unsuccessful, then
         snmpTlstmSessionOpenErrors is incremented, an error indication is
         returned, and processing stops.  If the session failed to open
         because the presented server certificate was unknown or invalid
         then the snmpTlstmSessionUnknownServerCertificate or
         snmpTlstmSessionInvalidServerCertificates MUST be incremented and
         a tlstmServerCertificateUnknown or tlstmServerInvalidCertificate
         notification SHOULD be sent as appropriate.  Reasons for server
         certificate invalidation includes, but is not limited to,
         cryptographic validation failures and an unexpected presented
         certificate identity.

     4)  The (D)TLS client MUST then verify that the (D)TLS server's
         presented certificate is the expected certificate.  The (D)TLS
         client MUST NOT transmit SNMP messages until the server
         certificate has been authenticated and the client certificate has
         been transmitted.

         If the connection is being established from configuration based
         on SNMP-TARGET-MIB configuration then the procedures in the
         tlstmAddrTable DESCRIPTION clause should be followed to determine
         if the presented identity matches the expectations of the
         configuration.  Validation procedures (like the path validation
         procedures defined in [RFC5280] or through the use of
         fingerprints as defined by the tlstmAddrServerIdentity column)
         MUST be followed.  If a server identity name has been configured
         in the tlstmAddrServerIdentity column then this reference
         identity must be compared against the presented identity (for
         example using procedures described in
         [I-D.saintandre-tls-server-id-check]).

         If the connection is being established for reasons other than
         configuration found in the SNMP-TARGET-MIB then configuration and
         procedures outside the scope of this document should be followed.

     5)  (D)TLS provides assurance that the authenticated identity has
         been signed by a trusted configured certificate authority.  If
         verification of the server's certificate fails in any way (for
         example because of failures in cryptographic verification or the
         presented identity did not match the expected named entity) then
         the session establishment MUST fail, the
         snmpTlstmSessionInvalidServerCertificates object is incremented.
         If the session can not be opened for any reason at all, including
         cryptographic verification failures, then the
         snmpTlstmSessionOpenErrors counter is incremented and processing
         stops.

     6)  The TLSTM-specific session identifier (tlstmSessionID) is set in
         the tmSessionID of the tmStateReference passed to the TLS
         Transport Model to indicate that the session has been established
         successfully and to point to a specific (D)TLS session for future
         use.  The tlstmSessionID is also stored in the LCD for later
         lookup during processing of incoming messages (Section 5.1.2).

  5.3.2.  Accepting a Session as a Server

     A (D)TLS server should accept new session connections from any client
     that it is able to verify the client's credentials for.  This is done
     by authenticating the client's presented certificate through a
     certificate path validation process (e.g.  [RFC5280]) or through
     certificate fingerprint verification using fingerprints configure in
     the tlstmCertToTSNTable.  Afterward the server will determine the
     identity of the remote entity using the following procedures.

     The (D)TLS server identifies the authenticated identity from the
     (D)TLS client's principal certificate using configuration information
     from the tlstmCertToTSNTable mapping table.  The (D)TLS server MUST
     request and expect a certificate from the client and MUST NOT accept
     SNMP messages over the (D)TLS session until the client has sent a
     certificate and it has been authenticated.  The resulting derived
     tmSecurityName is recorded in the tmStateReference cache as
     tmSecurityName.  The details of the lookup process are fully
     described in the DESCRIPTION clause of the tlstmCertToTSNTable MIB
     object.  If any verification fails in any way (for example because of
     failures in cryptographic verification or because of the lack of an
     appropriate row in the tlstmCertToTSNTable) then the session
     establishment MUST fail, the
     snmpTlstmSessionInvalidClientCertificates object is incremented.  If
     the session can not be opened for any reason at all, including
     cryptographic verification failures, then the
     snmpTlstmSessionOpenErrors counter is incremented and processing
     stops.

     Servers that wish to support multiple principals at a particular port
     SHOULD make use of a (D)TLS extension that allows server-side
     principal selection like the Server Name Indication extension defined
     in Section 3.1 of [RFC4366].  Supporting this will allow, for
     example, sending notifications to a specific principal at a given
     TCP, UDP or SCTP port.



-- 
Wes Hardaker
Cobham Analytic Solutions

From root@core3.amsl.com  Fri Jan 29 19:45:02 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 615983A6860; Fri, 29 Jan 2010 19:45:02 -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: <20100130034502.615983A6860@core3.amsl.com>
Date: Fri, 29 Jan 2010 19:45:02 -0800 (PST)
Cc: isms@ietf.org
Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-03.txt
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jan 2010 03:45:02 -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-03.txt
	Pages           : 19
	Date            : 2010-01-29

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols.  In particular, it
describes a backward-compatible extension 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 extension.  This
extension is intended to be used in conjunction with secure SNMP
Transport Models that facilitate RADIUS authentication, such as the
Secure Shell Transport Model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-03.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-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-29193237.I-D@ietf.org>


--NextPart--

From randy_presuhn@mindspring.com  Fri Jan 29 19:47: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 49ABA3A68DC for ; Fri, 29 Jan 2010 19:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 SQ36Znni1v3b for ; Fri, 29 Jan 2010 19:47:23 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 862CD3A68AD for ; Fri, 29 Jan 2010 19:47:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Bw7xqSJ6hfWzIMAgLbJzyoLtwac/GvPldZo4vggFgXjueOxcfbz9LUoCaJpZ2kiD; 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.33.94.231] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nb4JH-00059O-RM for isms@ietf.org; Fri, 29 Jan 2010 22:47:48 -0500
Message-ID: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
Date: Fri, 29 Jan 2010 19:51:26 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40757a52e8263e67bc5b3a2e1e81e57789350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.94.231
Subject: [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: Sat, 30 Jan 2010 03:47:24 -0000

Hi -

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.

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.

Opinions?

Randy


From j.schoenwaelder@jacobs-university.de  Sat Jan 30 07: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 C85B13A687A for ; Sat, 30 Jan 2010 07:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level: 
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116,  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 Y3hqPRUFDc48 for ; Sat, 30 Jan 2010 07:14:38 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8343E3A67CF for ; Sat, 30 Jan 2010 07:14:38 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5711CC0006; Sat, 30 Jan 2010 16:15:04 +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 BmYypdWZDoaZ; Sat, 30 Jan 2010 16:15:03 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A86DC0003; Sat, 30 Jan 2010 16:15:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 227B710261CD; Sat, 30 Jan 2010 16:14:53 +0100 (CET)
Date: Sat, 30 Jan 2010 16:14:53 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20100130151453.GA99563@elstar.local>
Mail-Followup-To: Randy Presuhn , "isms@ietf.org" 
References: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "isms@ietf.org" 
Subject: Re: [Isms] extVacmRowLifetime
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: Sat, 30 Jan 2010 15:14:39 -0000

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.

/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  Sat Jan 30 08:00: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 114263A68B7 for ; Sat, 30 Jan 2010 08:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1op8FabHqtz for ; Sat, 30 Jan 2010 08:00:23 -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 062533A688D for ; Sat, 30 Jan 2010 08:00:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=te7Xvx+RqyFgB1E3K1NeqoznZonFXvq4USHQThcfI7b+o5C7aV8Y1t1bt6P8rZoV; 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.55.175.237] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NbFke-0005zT-TW for isms@ietf.org; Sat, 30 Jan 2010 11:00:49 -0500
Message-ID: <000401caa1c5$e96f5fa0$6801a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer> <20100130151453.GA99563@elstar.local>
Date: Sat, 30 Jan 2010 08:04:30 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40d3cfaeb750e8185a4f68bd429d6dbce0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.55.175.237
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: Sat, 30 Jan 2010 16:00:24 -0000

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.

Randy


From j.schoenwaelder@jacobs-university.de  Sat Jan 30 08:13:21 2010
Return-Path: 
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF473A687A for ; Sat, 30 Jan 2010 08:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.145
X-Spam-Level: 
X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104,  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 OPtAPJX7CH8i for ; Sat, 30 Jan 2010 08:13:19 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 251F23A68B0 for ; Sat, 30 Jan 2010 08:13:19 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76B64C0003; Sat, 30 Jan 2010 17:13:45 +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 boyiDhCZQU2Z; Sat, 30 Jan 2010 17:13:44 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 896BDC0006; Sat, 30 Jan 2010 17:13:44 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5333010263ED; Sat, 30 Jan 2010 17:13:34 +0100 (CET)
Date: Sat, 30 Jan 2010 17:13:34 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20100130161334.GC99563@elstar.local>
Mail-Followup-To: Randy Presuhn , "isms@ietf.org" 
References: <000c01caa15f$807fbaa0$6801a8c0@oemcomputer> <20100130151453.GA99563@elstar.local> <000401caa1c5$e96f5fa0$6801a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000401caa1c5$e96f5fa0$6801a8c0@oemcomputer>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "isms@ietf.org" 
Subject: Re: [Isms] extVacmRowLifetime
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: Sat, 30 Jan 2010 16:13:21 -0000

On Sat, Jan 30, 2010 at 05:04:30PM +0100, Randy Presuhn wrote:
 
> 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 agree. However, the dynamic vacm entry inherits the lifetime from
the security model and this is the only thing we can deal with here.
But (speaking as technical contributor), I am fine with not exposing
this lifetime.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103