From wjhns1@hardakers.net Tue Apr 6 16:59: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 243A63A684B for ; Tue, 6 Apr 2010 16:59:47 -0700 (PDT) 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_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TImTcqFcDFUa for ; Tue, 6 Apr 2010 16:59:46 -0700 (PDT) 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 7DF2A3A659C for ; Tue, 6 Apr 2010 16:59:39 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D28D598192; Tue, 6 Apr 2010 16:59:36 -0700 (PDT) From: Wes Hardaker To: Michael Peck Organization: Sparta Date: Tue, 06 Apr 2010 16:59:36 -0700 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: [Isms] Responses to Michael Peck's comments for last call 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, 06 Apr 2010 23:59:47 -0000 Mike, Thank's for your comments during IETF last call. I've simply addressed most of them but do have some comments below that you may wish to review. Pasi, I'd specifically like you to look at item #6 below since the issue comes from text you contributed to the document. The WG should also consider the matter carefully and provide responses. 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 Section 2.1 ~~~~~~~~~~~~~~~~~~~ "TLS Transport Model SHOULD support the message encryption" change to: "TLS Transport Model SHOULD support message encryption" + WH: done 2 DONE 4.1 ~~~~~~~~~~~ Change "; Other" to "; other" + WH: done 3 DONE 4.1.1 ~~~~~~~~~~~~~ Trusted public keys.. certificates, MUST - Remove the comma before MUST + WH: done 4 DONE 5.1.1 Step 2a ~~~~~~~~~~~~~~~~~~~~~ Missing letter "I" (as in If) at the beginning of the paragraph 5 DONE 5.3.1 Step 4, 5.3.2 Paragraph 2: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These both imply transmitting can begin before the TLS handshake is complete as long as the certificates have been transmitted/verified? I think you want to say that the TLS handshake has successfully completed first. + WH: How's this for new text replacing the previous sentence: The (D)TLS client MUST NOT transmit SNMP messages until the server certificate has been authenticated, the client certificate has been transmitted and the TLS connection has been fully established. 6 DISCUSS 5.3.2 Paragraph 1: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "authenticating... through a path validation process.. or through a certificate fingerprint verification" Just to clarify, does this mean that if a certificate directly matches the fingerprint in the MIB, then RFC5280 path validation is not performed and nothing else about the certificate is checked? I think that may be okay. For example, it would provide an override mechanism to be able to manage the device even if the certificate (or the certificates above it in the chain) has expired, rather than potentially being locked out of the device completely. + WH: That's correct: a matching fingerprint can be used to not require chaining to a trust anchor. The current text actually comes from Pasi and the interesting side-effect is that we don't discuss date ranges and I'm not sure we should do this. I'm more tempted to say we need to add in text describing that the date validity should be checked. I don't think anyone intended for this to be a way to trump other issues with it other than trust anchor chaining. 6.1 DONE "fingerprints configure" -> "fingerprints configured" =============================================================== + WH: done 6.2 DONE "establishment MUST fail, the" -> "establishment MUST fail, and the" ============================================================================== + WH: done 7 DONE tlstmCertToTSNTable: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change "CA certificate or self-signed public certificate" to "trust anchor, which could be represented as a self-signed certificate" A CA certificate or self-signed certificate provides a means for representing a trust anchor - other formats exist, such as the Trust Anchor Format recently published by PKIX. For your document's purposes it doesn't matter which format is used (it can be implementation dependent). Usually a certification path doesn't begin with any CA certificate (for example, an intermediary CA certificate), it begins with a root CA certificate, which is typically represented as a self-signed certificate. However, someone could choose to designate the intermediary CA certificate as a trust anchor and just start the path validation there if they wanted to. + WH: I've made this change. I was originally shying away from using the term "trust anchor" since the current PKIX work hasn't finished yet (ie, it's not an RFC yet). But I do agree the wording is better. 8 WONTDO "However, the usage of the CommonName field is deprecated" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think the usage of CommonName is deprecated for representing hostnames (SubjectAltName dNSName should be used instead), but the general usage of CommonName is not deprecated. + WH: I believe that it shouldn't be used as a unique identifier. Though I agree that it hasn't been deprecated to name someone, I think the rfc822Name is a better unique naming for principals. If others have opinions on this subject, please speak up! 9 DONE tlsTmParamsClientFingerprint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change "should store the hash of a locally held X.509 certificate (and the corresponding private key) that should be used" to: "should store the hash of a locally held X.509 certificate that should be used (along with the corresponding private key)" to make it clear that the private key is not part of what is hashed, only the certificate + WH: done -- Wes Hardaker Cobham Analytic Solutions From Pasi.Eronen@nokia.com Wed Apr 7 00:19: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 BC2AB3A689F for ; Wed, 7 Apr 2010 00:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 DN2Q4xkKJzuJ for ; Wed, 7 Apr 2010 00:19:40 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 92C263A685B for ; Wed, 7 Apr 2010 00:19:37 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o377JND1004683; Wed, 7 Apr 2010 02:19:31 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 10:19:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 10:19:21 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 7 Apr 2010 09:17:40 +0200 From: To: , Date: Wed, 7 Apr 2010 09:17:38 +0200 Thread-Topic: Responses to Michael Peck's comments for last call Thread-Index: AcrV5T/gd874j/1LTCmfTDjA5osfxwAOMexg Message-ID: <808FD6E27AD4884E94820BC333B2DB77591C1331E6@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2010 07:19:21.0725 (UTC) FILETIME=[A4E602D0:01CAD622] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] Responses to Michael Peck's comments for last call 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, 07 Apr 2010 07:19:47 -0000 Wes Hardaker wrote: > Mike, >=20 > Thank's for your comments during IETF last call. I've simply addressed > most of them but do have some comments below that you may wish to > review. Pasi, I'd specifically like you to look at item #6 below since > the issue comes from text you contributed to the document. The WG > should also consider the matter carefully and provide responses. > 6 DISCUSS 5.3.2 Paragraph 1: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "authenticating... through a path validation process.. or > through a certificate fingerprint verification" >=20 > Just to clarify, does this mean that if a certificate directly > matches the fingerprint in the MIB, then RFC5280 path > validation is not performed and nothing else about the > certificate is checked? I think that may be okay. For > example, it would provide an override mechanism to be able to > manage the device even if the certificate (or the certificates > above it in the chain) has expired, rather than potentially > being locked out of the device completely. >=20 > + WH: That's correct: a matching fingerprint can be used to not > require chaining to a trust anchor. The current text > actually comes from Pasi and the interesting side-effect is > that we don't discuss date ranges and I'm not sure we should > do this. I'm more tempted to say we need to add in text > describing that the date validity should be checked. I > don't think anyone intended for this to be a way to trump > other issues with it other than trust anchor chaining. AFAIK the intent was that if the fingerprint matches, the only field used from the certificate is SubjectPublicKeyInfo (since that's needed by TLS) -- everything else (such as validity dates, subject, subjectAltName, key usages, constraints, policies, etc.) is ignored. (But the main use case for this is self-signed certificates -- where nobody is really certifying that those ignored fields contain anything meaningful -- but I guess nothing prevents one from using it as an override mechanism...) > 7 DONE tlstmCertToTSNTable: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > Change "CA certificate or self-signed public certificate" to > "trust anchor, which could be represented as a self-signed > certificate" >=20 > A CA certificate or self-signed certificate > provides a means for representing a trust anchor - other > formats exist, such as the Trust Anchor Format recently > published by PKIX. For your document's purposes it doesn't > matter which format is used (it can be implementation > dependent). Usually a certification path doesn't begin with > any CA certificate (for example, an intermediary CA > certificate), it begins with a root CA certificate, which is > typically represented as a self-signed certificate. However, > someone could choose to designate the intermediary CA > certificate as a trust anchor and just start the path > validation there if they wanted to. >=20 > + WH: I've made this change. I was originally shying away > from using the term "trust anchor" since the current PKIX > work hasn't finished yet (ie, it's not an RFC yet). But I > do agree the wording is better. I think the intent was slightly different here: the client's certificate can *either* be validated with a trust anchor, or it can directly match a row (in which case it's probably self-signed -- but doesn't have to be). But it looks like the text indeed says something else: the third paragraph says this table is consulted only after the certificate has been found authentic, so a self-signed certificate would never match... Proposed rephrasing: This table is used by a (D)TLS server to map the (D)TLS client's presented X.509 certificate to a tmSecurityName. On an incoming (D)TLS/SNMP connection the client's presented certificate must either be validated based on an established trust anchor, or it must directly match a fingerprint in this table. This table does not provide any mechanisms for configuring the trust anchors; the transfer of any needed trusted certificates for path validation is expected to occur through an out-of-band transfer. Once the certificate has been found acceptable (either by path validation or directly matching a fingerprint in this table), this table is consulted to determine the appropriate tmSecurityName to identify with the remote connection. [...] Best regards, Pasi From wjhns1@hardakers.net Wed Apr 7 09:06: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 C364E3A67F6 for ; Wed, 7 Apr 2010 09:06:22 -0700 (PDT) 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 PtG1JKbJbVrs for ; Wed, 7 Apr 2010 09:06:22 -0700 (PDT) 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 48F413A6AF4 for ; Wed, 7 Apr 2010 09:06:11 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5878E98178; Wed, 7 Apr 2010 09:06:08 -0700 (PDT) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB77591C1331E6@NOK-EUMSG-01.mgdnok.nokia.com> Date: Wed, 07 Apr 2010 09:06:08 -0700 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB77591C1331E6@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Wed, 7 Apr 2010 09:17:38 +0200") 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, mike@thecouch.ncsc.mil Subject: Re: [Isms] Responses to Michael Peck's comments for last call 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, 07 Apr 2010 16:06:22 -0000 >>>>> On Wed, 7 Apr 2010 09:17:38 +0200, said: PE> AFAIK the intent was that if the fingerprint matches, the only field PE> used from the certificate is SubjectPublicKeyInfo (since that's needed PE> by TLS) -- everything else (such as validity dates, subject, PE> subjectAltName, key usages, constraints, policies, etc.) is ignored. Ok; I was willing to go either way as I consider both ways useful. (actually, if this was earlier in the game I might have pushed for another column to dictate whether the date should be checked or not). PE> But it looks like the text indeed says something else: the third PE> paragraph says this table is consulted only after the certificate has PE> been found authentic, so a self-signed certificate would never PE> match... That's a good point. PE> Proposed rephrasing: And I've installed that text, which I agree better describes what the WG solution was expecting. Thanks! -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Apr 7 09:43:16 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62513A6979; Wed, 7 Apr 2010 09:43:15 -0700 (PDT) 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 mofU+wPUTImX; Wed, 7 Apr 2010 09:43:14 -0700 (PDT) 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 A735B3A6973; Wed, 7 Apr 2010 09:42:56 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6BB87981AE; Wed, 7 Apr 2010 09:42:53 -0700 (PDT) From: Wes Hardaker To: Juergen Schoenwaelder Organization: Sparta References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> Date: Wed, 07 Apr 2010 09:42:53 -0700 In-Reply-To: <20100407065512.GA4199@elstar.local> (Juergen Schoenwaelder's message of "Wed, 7 Apr 2010 08:55:12 +0200") 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: Amanda Baber via RT , "ietf@hardakers.net" , "iesg@ietf.org" , "isms-chairs@tools.ietf.org" , isms@ietf.org Subject: Re: [Isms] [IANA #305455] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:43:16 -0000 >>>>> On Wed, 7 Apr 2010 08:55:12 +0200, Juergen Schoenwaelder said: >> Decimal Name Description References >> ------- ---- ----------- ---------- >> xxxx tlstm The TLS Transport [RFC-isms-dtls-tm-09] JS> According to the MIB module, this would be named tlstmMIB not tlstm JS> (but the IANA instructions were not clear). Wes, the MIB module says JS> "snmpModules xxxx" where it should be "mib-2 189". Actually, it needs to be 'mib-2 xxxx' and I've changed it to such. JS> Since RFC 5592 prefixes everything with 'snmp', I am wondering JS> whether we should have done the same and even have called the module JS> SNMP-TLS-TM-MIB for consistency with SNMP-SSH-TM-MIB instead of JS> TLSTM-MIB. Interestingly, the error counters are prefixed with JS> 'snmp'. I know, this naming issues comes up very late now but I JS> thought I still raise it. Perhaps we really need a good MIB doctor JS> review. ;-) I've changed this as well as renamed the MIB to SNMP-TLS-TM-MIB. I worry about getting all the references in the document correctly to rename all the objects, but I'll go through the work in doing so if that's what we feel is the right thing to do. >> Upon approval of this document, IANA will make the following >> assignments in "iso.org.dod.internet.snmpv2.snmpDomains (1.3.6.1.6.1)" at >> http://www.iana.org/assignments/smi-numbers >> >> Decimal Name Description Reference >> ------- ----------------- ----------------------------- --------- >> xx snmpTLSTCPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09] >> yy snmpTLSDUDPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09] JS> (I am wondering what is really TCP/UDP specific in this document.) JS> Anyway, the second assignment is clearly wrong, the document requests JS> snmpDTLSUDPDomain not snmpTLSDUDPDomain. Yep. Both TLS and DTLS can be run over things other than their common TCP and UDP cases so I think it's important we distinguish them appropriately both for understanding today as well as matching future naming if someone wants to expand the suite later. But the assignment in the second one above definitely should be snmpDTLSUDPDomain and I think the text already says this clearly and the above example assignment was simply a human error. >> Action #3 >> >> Upon approval of this document, IANA will make the following >> assignments in the "SNMP Transport Domains" registry at >> http://www.iana.org/assignments/snmp-number-spaces >> >> Prefix snmpDomains Reference >> ------- ----------------------------- --------- >> tls snmpTLSTCPDomain [RFC-isms-dtls-tm-09] >> dudp snmpDTLSUDPDomain [RFC-isms-dtls-tm-09] JS> This is correct with regard to -09 but it seems the second prefix JS> really should be 'dtls' and not 'dudp'. (And since we do not JS> distinguish the transports here, perhaps we also do not need to do JS> this for the *Domain names?) dudp was the request we made originally because we were going to support multiple instances of DTLS so we had dudp and dsct as well. If we're only going to do dtls/udp now then we should either pick: 1) 'tls' and 'dtls' as prefixes. 2) 'ttcp' and 'dudp' as prefixes (letting future 'tsct' and 'dsct' match future (D)TLS over SCTP match existing naming assignments). >> Upon approval of this document, IANA will assign the following >> registered port numbers at >> http://www.iana.org/assignments/port-numbers >> >> Keyword Decimal Description References >> ------- ------- ----------- ---------- >> smtptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] >> TBD1/udp SNMPv3-TLS [RFC-isms-dtls-tm-09] >> smtpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] >> TBD2/udp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] JS> This should be snmptls and snmptls-trap, as requested in the document. I'm thinking that the snmptls should not be the proper name for DTLS/UDP case though. It's not TLS it's DTLS. I think we really should end up with is: Keyword Decimal Description References ------- ------- ----------- ---------- snmptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] snmpdtls TBD1/udp SNMPv3-DTLS [RFC-isms-dtls-tm-09] snmpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] snmpdtls-trap TBD2/udp SNMPv3-Trap-DTLS [RFC-isms-dtls-tm-09] (note the 'dtls') Thoughts? -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Apr 7 10:25: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 5EC2F3A6868 for ; Wed, 7 Apr 2010 10:25:12 -0700 (PDT) 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 Kw9pNMzNgv7i for ; Wed, 7 Apr 2010 10:25:11 -0700 (PDT) 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 356113A690C for ; Wed, 7 Apr 2010 10:25:11 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 38F2398177 for ; Wed, 7 Apr 2010 10:25:08 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> Date: Wed, 07 Apr 2010 10:25:07 -0700 In-Reply-To: (Wes Hardaker's message of "Wed, 07 Apr 2010 09:42:53 -0700") 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 TLSTM "pre" document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:25:12 -0000 >>>>> On Wed, 07 Apr 2010 09:42:53 -0700, Wes Hardaker said: WH> I worry about getting all the references in the document correctly to WH> rename all the objects, but I'll go through the work in doing so if WH> that's what we feel is the right thing to do. FYI, I've gone ahead and done this. The new and updated document reflecting all the outstanding issues I have in my list, including Michael Peck's and IANA issues, can be found at: http://www.hardakers.net/temp/draft-ietf-isms-dtls-tm-10pre1.txt And the diff comparison can be found at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-isms-dtls-tm-09.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-dtls-tm-10pre1.txt -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Wed Apr 7 10:32: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 487E928C0FE for ; Wed, 7 Apr 2010 10:32:47 -0700 (PDT) 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 Qlx3UByCmn5Z for ; Wed, 7 Apr 2010 10:32:44 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id B2E043A69C3 for ; Wed, 7 Apr 2010 10:32:43 -0700 (PDT) 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 o37HWaPC017357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 13:32:36 -0400 (EDT) Date: Wed, 07 Apr 2010 13:32:36 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , Michael Peck Message-ID: <007FC6B8CA1383B51EB8E177@minbar.fac.cs.cmu.edu> In-Reply-To: <2142_1270598387_o36NxkXW025660_sdochwdtef.fsf@wjh.hardakers.net> References: <2142_1270598387_o36NxkXW025660_sdochwdtef.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.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Responses to Michael Peck's comments for last call 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, 07 Apr 2010 17:32:47 -0000 --On Tuesday, April 06, 2010 04:59:36 PM -0700 Wes Hardaker wrote: > 6 DISCUSS 5.3.2 Paragraph 1: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "authenticating... through a path validation process.. or > through a certificate fingerprint verification" > > Just to clarify, does this mean that if a certificate directly > matches the fingerprint in the MIB, then RFC5280 path > validation is not performed and nothing else about the > certificate is checked? I think that may be okay. For > example, it would provide an override mechanism to be able to > manage the device even if the certificate (or the certificates > above it in the chain) has expired, rather than potentially > being locked out of the device completely. > > + WH: That's correct: a matching fingerprint can be used to not > require chaining to a trust anchor. The current text > actually comes from Pasi and the interesting side-effect is > that we don't discuss date ranges and I'm not sure we should > do this. I'm more tempted to say we need to add in text > describing that the date validity should be checked. I > don't think anyone intended for this to be a way to trump > other issues with it other than trust anchor chaining. On the contrary, a certificate is an assertion from the issuer. If you're not going to use the fact that some issuer has made an assertion in deciding whether the key is any good, then the certificate becomes just a convenient way to represent a key. In that case, everything but the key becomes irrelevant, because it's all just signed assertions that you're not relying on. The validity times in a certificate indicate when the certificate itself is valid; particularly, the expiration time describes the expiration of the issuer's assertion that the signed key belongs to a particular subject. It does _not_ describe the expiration of the subject's key, and it is common to obtain new certificates with the same key pair. -- Jeff From ietfdbh@comcast.net Wed Apr 7 16:53: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 6AD7D3A6847 for ; Wed, 7 Apr 2010 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.937, 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 lbHtay1cfEQ7 for ; Wed, 7 Apr 2010 16:53:44 -0700 (PDT) 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 0165F3A6811 for ; Wed, 7 Apr 2010 16:53:43 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 2nni1e0091uE5Es5Bntiop; Wed, 07 Apr 2010 23:53:42 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id 2nyd1e00S2JQnJT3cnydaw; Wed, 07 Apr 2010 23:58:39 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'Juergen Schoenwaelder'" References: <20100308151656.523C53A69FB@core3.amsl.com><20100407065512.GA4199@elstar.local> Date: Wed, 7 Apr 2010 19:53:30 -0400 Message-ID: <085601cad6ad$883ff6a0$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: AcrWcWzjWGT13/MQSqq8LxAXSB7kUgAPAhRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: 'Amanda Baber via RT' , ietf@hardakers.net, iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] [IANA #305455] Last Call: draft-ietf-isms-dtls-tm(Transport Layer Security (TLS) Transport Model for SNMP) toProposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 23:53:44 -0000 what is the ltls in snmpltls? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, April 07, 2010 12:43 PM > To: Juergen Schoenwaelder > Cc: Amanda Baber via RT; ietf@hardakers.net; iesg@ietf.org; > isms-chairs@tools.ietf.org; isms@ietf.org > Subject: Re: [Isms] [IANA #305455] Last Call: > draft-ietf-isms-dtls-tm(Transport Layer Security (TLS) > Transport Model for SNMP) toProposed Standard > > >>>>> On Wed, 7 Apr 2010 08:55:12 +0200, Juergen > Schoenwaelder said: > > >> Decimal Name Description References > >> ------- ---- ----------- ---------- > >> xxxx tlstm The TLS Transport [RFC-isms-dtls-tm-09] > > JS> According to the MIB module, this would be named tlstmMIB > not tlstm > JS> (but the IANA instructions were not clear). Wes, the MIB > module says > JS> "snmpModules xxxx" where it should be "mib-2 189". > > Actually, it needs to be 'mib-2 xxxx' and I've changed it to such. > > JS> Since RFC 5592 prefixes everything with 'snmp', I am wondering > JS> whether we should have done the same and even have called > the module > JS> SNMP-TLS-TM-MIB for consistency with SNMP-SSH-TM-MIB instead of > JS> TLSTM-MIB. Interestingly, the error counters are prefixed with > JS> 'snmp'. I know, this naming issues comes up very late now but I > JS> thought I still raise it. Perhaps we really need a good MIB doctor > JS> review. ;-) > > I've changed this as well as renamed the MIB to SNMP-TLS-TM-MIB. > > I worry about getting all the references in the document correctly to > rename all the objects, but I'll go through the work in doing so if > that's what we feel is the right thing to do. > > >> Upon approval of this document, IANA will make the following > >> assignments in "iso.org.dod.internet.snmpv2.snmpDomains > (1.3.6.1.6.1)" at > >> http://www.iana.org/assignments/smi-numbers > >> > >> Decimal Name Description Reference > >> ------- ----------------- ----------------------------- --------- > >> xx snmpTLSTCPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09] > >> yy snmpTLSDUDPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09] > > JS> (I am wondering what is really TCP/UDP specific in this document.) > JS> Anyway, the second assignment is clearly wrong, the > document requests > JS> snmpDTLSUDPDomain not snmpTLSDUDPDomain. > > Yep. Both TLS and DTLS can be run over things other than their common > TCP and UDP cases so I think it's important we distinguish them > appropriately both for understanding today as well as matching future > naming if someone wants to expand the suite later. > > But the assignment in the second one above definitely should be > snmpDTLSUDPDomain and I think the text already says this > clearly and the > above example assignment was simply a human error. > > >> Action #3 > >> > >> Upon approval of this document, IANA will make the following > >> assignments in the "SNMP Transport Domains" registry at > >> http://www.iana.org/assignments/snmp-number-spaces > >> > >> Prefix snmpDomains Reference > >> ------- ----------------------------- --------- > >> tls snmpTLSTCPDomain [RFC-isms-dtls-tm-09] > >> dudp snmpDTLSUDPDomain [RFC-isms-dtls-tm-09] > > JS> This is correct with regard to -09 but it seems the second prefix > JS> really should be 'dtls' and not 'dudp'. (And since we do not > JS> distinguish the transports here, perhaps we also do not need to do > JS> this for the *Domain names?) > > dudp was the request we made originally because we were going > to support > multiple instances of DTLS so we had dudp and dsct as well. If we're > only going to do dtls/udp now then we should either pick: > > 1) 'tls' and 'dtls' as prefixes. > 2) 'ttcp' and 'dudp' as prefixes (letting future 'tsct' and > 'dsct' match > future (D)TLS over SCTP match existing naming assignments). > > >> Upon approval of this document, IANA will assign the following > >> registered port numbers at > >> http://www.iana.org/assignments/port-numbers > >> > >> Keyword Decimal Description References > >> ------- ------- ----------- ---------- > >> smtptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] > >> TBD1/udp SNMPv3-TLS [RFC-isms-dtls-tm-09] > >> smtpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] > >> TBD2/udp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] > > JS> This should be snmptls and snmptls-trap, as requested in > the document. > > I'm thinking that the snmptls should not be the proper name > for DTLS/UDP > case though. It's not TLS it's DTLS. I think we really should end up > with is: > > Keyword Decimal Description References > ------- ------- ----------- ---------- > snmptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] > snmpdtls TBD1/udp SNMPv3-DTLS [RFC-isms-dtls-tm-09] > snmpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] > snmpdtls-trap TBD2/udp SNMPv3-Trap-DTLS [RFC-isms-dtls-tm-09] > > (note the 'dtls') > > Thoughts? > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From Robert.Story@cobham.com Thu Apr 8 05:35: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 5FC7728C13B; Thu, 8 Apr 2010 05:35:37 -0700 (PDT) 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_63=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 gkdricGiK8tM; Thu, 8 Apr 2010 05:35:36 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A3B9028C13A; Thu, 8 Apr 2010 05:35:35 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o38CUl6U000987; Thu, 8 Apr 2010 07:30:47 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o38CUidx026764; Thu, 8 Apr 2010 07:30:44 -0500 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, 8 Apr 2010 08:30:43 -0400 Date: Thu, 8 Apr 2010 08:30:53 -0400 From: Robert Story To: Wes Hardaker Message-ID: <20100408083053.2a47ebb5@sparta.com> In-Reply-To: References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ENi8Gs.J=46Goee_wTFNq//"; protocol="application/pgp-signature" X-OriginalArrivalTime: 08 Apr 2010 12:30:43.0766 (UTC) FILETIME=[4EACFD60:01CAD717] Cc: isms@ietf.org, Baber via RT , "isms-chairs@tools.ietf.org" , "ietf@hardakers.net" , "iesg@ietf.org" , Amanda Subject: Re: [Isms] [IANA #305455] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 12:35:37 -0000 --Sig_/ENi8Gs.J=46Goee_wTFNq// Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 7 Apr 2010 09:42:53 -0700 Wes wrote: WH> JS> Since RFC 5592 prefixes everything with 'snmp', I am wondering WH> JS> whether we should have done the same and even have called the module WH> JS> SNMP-TLS-TM-MIB for consistency with SNMP-SSH-TM-MIB instead of WH> JS> TLSTM-MIB. WH>=20 WH> I've changed this as well as renamed the MIB to SNMP-TLS-TM-MIB. Ugh. I, for one, hate these ever expanding object names. I don't mind the MIB names so much. Given that many tools prefix object names with the MIB names, prefixing objects just makes the name longer,not any clearer. Picking an example from this mib, we've gone from TLSTM-MIB::tlstmCertToTSNStorageType to SNMP-TLS-TM-MIB::snmpTlstmCertToTSNStorageType when SNMP-TLS-TM-MIB::certToTSNStorageType is quite clear. My $.02, anyways. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/ENi8Gs.J=46Goee_wTFNq// Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAku9zIIACgkQ7/fVLLY1mnhLUACfVxWER4+Mm3MKjkg8FZjgce/1 2QAAnj/w3jdq05Aapd2cQOYmEZ1wjH9g =NSwJ -----END PGP SIGNATURE----- --Sig_/ENi8Gs.J=46Goee_wTFNq//-- From wjhns1@hardakers.net Thu Apr 8 06:27: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 76E8C3A68A0; Thu, 8 Apr 2010 06:27:41 -0700 (PDT) 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 fJ46FyRHM6ur; Thu, 8 Apr 2010 06:27:39 -0700 (PDT) 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 40CBE3A6A6E; Thu, 8 Apr 2010 06:27:14 -0700 (PDT) Received: from localhost (unknown [32.177.253.209]) by mail.hardakers.net (Postfix) with ESMTPSA id 7891198188; Thu, 8 Apr 2010 06:27:05 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> <085601cad6ad$883ff6a0$0600a8c0@china.huawei.com> Date: Thu, 08 Apr 2010 06:27:00 -0700 In-Reply-To: <085601cad6ad$883ff6a0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 7 Apr 2010 19:53:30 -0400") 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, 'Amanda Baber via RT' , isms-chairs@tools.ietf.org, ietf@hardakers.net, iesg@ietf.org Subject: Re: [Isms] [IANA #305455] Last Call: draft-ietf-isms-dtls-tm(Transport Layer Security (TLS) Transport Model for SNMP) toProposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:27:41 -0000 >>>>> On Wed, 7 Apr 2010 19:53:30 -0400, "David Harrington" said: DH> what is the ltls in snmpltls? That's that rare and elusive typo inserted by IANA folks and copied by me! (and now fixed) -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Apr 8 06: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 8C7E83A68C8; Thu, 8 Apr 2010 06:29:14 -0700 (PDT) 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 bWTU420D9wWw; Thu, 8 Apr 2010 06:29:13 -0700 (PDT) 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 B6E0F3A68C1; Thu, 8 Apr 2010 06:29:13 -0700 (PDT) Received: from localhost (unknown [32.177.253.209]) by mail.hardakers.net (Postfix) with ESMTPSA id A5E4398186; Thu, 8 Apr 2010 06:29:07 -0700 (PDT) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> <20100408083053.2a47ebb5@sparta.com> Date: Thu, 08 Apr 2010 06:29:03 -0700 In-Reply-To: <20100408083053.2a47ebb5@sparta.com> (Robert Story's message of "Thu, 8 Apr 2010 08:30:53 -0400") 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, Amanda Baber via RT , "isms-chairs@tools.ietf.org" , "ietf@hardakers.net" , "iesg@ietf.org" Subject: Re: [Isms] [IANA #305455] Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:29:14 -0000 >>>>> On Thu, 8 Apr 2010 08:30:53 -0400, Robert Story said: RS> Ugh. I, for one, hate these ever expanding object names. I don't mind RS> the MIB names so much. Me too, but they should ideally match the SSH draft. And traditionally objects that are manipulating things that have to do with management of the snmp protocol itself (like these) have 'snmp' as a prefix. We continue making things unreadable by tradition (and for uniqueness insurance). -- Wes Hardaker Cobham Analytic Solutions From dromasca@avaya.com Mon Apr 12 05:45: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 20DF93A67AF for ; Mon, 12 Apr 2010 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=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 VuYDg8oSOkRe for ; Mon, 12 Apr 2010 05:44:53 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 05DFC3A6827 for ; Mon, 12 Apr 2010 05:44:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="txt'?scan'208,217";a="213069443" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Apr 2010 08:44:47 -0400 X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="txt'?scan'208,217";a="463664036" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Apr 2010 08:44:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CADA3D.E950B99A" Date: Mon, 12 Apr 2010 14:44:37 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm Thread-Index: AcrWAqseR3I3Cd1DSGKEWCEXHobLoAAAKR8gAQ6RvcA= From: "Romascanu, Dan (Dan)" To: Subject: [Isms] FW: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm 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, 12 Apr 2010 12:45:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADA3D.E950B99A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CADA3D.E950B99A" ------_=_NextPart_002_01CADA3D.E950B99A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not sure if this review made it to the ISMS WG mail list. =20 Dan ________________________________ From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, April 07, 2010 6:41 AM To: tsv-dir@ietf.org Cc: ops-dir@ietf.org Subject: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm =09 =09 Background =20 I had previously been asked to review this document for the OPS-DIR as well as TSV-DIR. At the time I sent my OPS-DIR review (prior to IETF 77), I didn't find any major issues. Then at IETF 77, I chaired a discussion of DTLS-related transport issues for another protocol (RADIUS over DTLS), and the question occurred to me that some of the issues encountered there might also be relevant to SNMP over DTLS. As a result, I thought I would post some of those thoughts to both the TSV-DIR and OPS-DIR. In general, it occurs to me that the issues raised in this (and other WGs) relating to use of DTLS transport might be worthy of a document in their own right. In practice, it might be helpful for the IETF to provide some guidelines on how to use DTLS, much as we provided guidelines for using IPsec. =20 =20 Summary: =20 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. =20 =20 General Observations =20 Since the abstract claims that the document describes a transport model for SNMP, I was expecting to find the kind of discussion one normally expects in a transport model document, namely discussion of transport issues. In general, those kind of details are not present. To some extent this is because transport issues are covered in two of the normatively referenced documents, namely: =20 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590 , June 2009. =20 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591 , June 2009. =20 However, after looking through both of these documents, as well as this one, I'm still missing some basic details that I have seen discussed in other DTLS transport documents (such as RADIUS over DTLS). One of these details concerns how a deployment transitions from conventional UDP to DTLS. There are a number of issues that come up in a transition like this, such as whether DTLS and UDP are to be sent on the same port, and if so, how that works. In real deployments there is typically no "flag day" so that (D)TLS and uprotected SNMP may coexist for a while. It can be onerous to have to track the upgrade state of every device on the network, since they may not be uniform. =20 =20 From the documents, it appears that the transition is expected to be handled via the MIB and explicit management, but I'd like to see this issue discussed explicitly. =20 =20 In the RADIUS over DTLS transport doc, the assumption was that the RADIUS sever is upgraded to support DTLS first, and that the RADIUS clients are upgraded over time, so that during the transition there can be a mixture of DTLS and non-DTLS clients. Once a client is upgraded to support DTLS it is assumed to stay that way, so that the server can set a "toggle" that the client has been upgraded, expecting that future sessions from that client will be DTLS protected. Eventually when all the clients have been upgraded, a switch can be set on the server only permitting DTLS sessions. However, during the transition, it is not assumed that there is a master list of all the clients that support DTLS. Rather, the server derives this list dynamically based on its interaction with clients, and therefore can provide reports to the administrator on the status of the transition. The goal is to enable a transition to DTLS operation which is relatively secure (e.g protecting against downgrade attacks), while being easy to manage.=20 =20 While Section 8.1 does talk about sessions and heartbeats, it doesn't provide the details of how implementations are expected to toggle between DTLS and unprotected SNMPv3. For example, if DTLS and regular SNMPv3 packets can be sent to the same port, how do implementation distinguish DTLS packets from conventional SNMPv3 packets? In some cases this can be done by looking at the initial packet and deciding whether DTLS or uprotected SNMP is being used. Once that decision is made, then a toggle is set. The toggle can be based on the 5 tuple (source IP, dest IP, source port, dest port, UDP) or it could be based on the source IP. One the toggle is set for DTLS, only DTLS packets will be accepted for that 5 tuple or IP address. The toggle might be kept in memory, or it might be saved to stable storage. =20 ------_=_NextPart_002_01CADA3D.E950B99A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am=20 not sure if this review made it to the ISMS WG mail = list.
 
Dan

From: ops-dir-bounces@ietf.org=20 [mailto:ops-dir-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, April 07, 2010 6:41 AM
To:=20 tsv-dir@ietf.org
Cc: ops-dir@ietf.org
Subject: = [OPS-DIR]=20 (Yet another) Review of draft-ietf-isms-dtls-tm

Background

 

I had previously = been asked to=20 review this document for the OPS-DIR as well as TSV-DIR.  At the = time I=20 sent my OPS-DIR review (prior to IETF 77), I didn’t find any = major=20 issues.  Then at IETF 77, I chaired a discussion of DTLS-related=20 transport issues for another protocol (RADIUS over DTLS), and the = question=20 occurred to me that some of the issues encountered there might also be = relevant to SNMP over DTLS.  As a result, I thought I would post = some of=20 those thoughts to both the TSV-DIR and OPS-DIR.  In general, it = occurs to=20 me that the issues raised in this (and other WGs) relating to use of = DTLS=20 transport might be worthy of a document in their own right.  In = practice,=20 it might be helpful for the IETF to provide some guidelines on how to = use=20 DTLS, much as we provided guidelines for using IPsec.  

 

Summary:

 

   This =
document describes a Transport Model for the Simple =
Network
   Management Protocol (SNMP), =
that uses either the Transport Layer
   =
Security protocol or the Datagram Transport Layer Security =
(DTLS)
   protocol.  The TLS and =
DTLS protocols provide authentication =
and
   privacy services for SNMP =
applications.  This document describes =
how
   the TLS Transport Model (TLSTM) =
implements the needed features of a
   =
SNMP Transport Subsystem to make this protection possible in =
an
   interoperable =
way.
 
 
  
General Observations

  
 

  
Since the abstract claims that the document =
describes a=20
  transport model for SNMP, I was expecting to find the kind of =
discussion one=20
  normally expects in a transport model document, namely discussion of =
transport=20
  issues.  In general, those kind of details are not =
present.  =20
  To some extent this is because transport issues are covered in two of =
the=20
  normatively referenced documents, namely:

  
 
   [RFC5590]  Harrington, D. =
and J. Schoenwaelder, "Transport =
Subsystem
       =
       for the Simple Network Management =
Protocol =
(SNMP)",
       &=
nbsp;      RFC 5590, June =
2009.
 
   [RFC5591]  Harrington, D. =
and W. Hardaker, "Transport Security =
Model
       &nbs=
p;      for the Simple Network Management =
Protocol =
(SNMP)",
       &=
nbsp;      RFC 5591, June =
2009.

  
 

  
However, after looking through both of these =
documents, as=20
  well as this one, I’m still missing some basic details that I =
have seen=20
  discussed in other DTLS transport documents (such as RADIUS over =
DTLS).=20
    One of these details concerns how a deployment transitions =
from=20
  conventional UDP to DTLS.    There are a number of =
issues that=20
  come up in a transition like this, such as whether DTLS and UDP are to =
be sent=20
  on the same port, and if so, how that works.  In real deployments =
there=20
  is typically no “flag day” so that (D)TLS and uprotected =
SNMP may coexist for=20
  a while.  It can be onerous to have to track the upgrade state of =
every=20
  device on the network, since they may not be uniform.  =


  
 

  
From the documents, it appears that the =
transition is=20
  expected to be handled via the MIB and explicit management, but =
 I’d like=20
  to see this issue discussed explicitly.  

  
 

  
In the RADIUS over DTLS transport doc, the =
assumption was=20
  that the RADIUS sever is upgraded to support DTLS first, and that the =
RADIUS=20
  clients are upgraded over time, so that during the transition there =
can be a=20
  mixture of DTLS and non-DTLS clients.  Once a client is upgraded =
to=20
  support DTLS it is assumed to stay that way, so that the server can =
set a=20
  “toggle” that the client has been upgraded, expecting that =
future sessions=20
  from that client will be DTLS protected.  Eventually when all the =
clients=20
  have been upgraded, a switch can be set on the server only permitting =
DTLS=20
  sessions.  However, during the transition, it is not assumed that =
there=20
  is a master list of all the clients that support DTLS.  Rather, =
the=20
  server derives this list dynamically based on its interaction with =
clients,=20
  and therefore can provide reports to the administrator on the status =
of the=20
  transition.  The goal is to enable a transition to DTLS operation =
which=20
  is relatively secure (e.g protecting against downgrade attacks), while =
being=20
  easy to manage. 

  
 

  
While Section 8.1 does talk about sessions and =
heartbeats,=20
  it doesn’t provide the details of how implementations are =
expected to toggle=20
  between DTLS and unprotected SNMPv3.  For example, if DTLS and =
regular=20
  SNMPv3 packets can be sent to the same port, how do implementation =
distinguish=20
  DTLS packets from conventional SNMPv3 packets?  In some cases =
this can be=20
  done by looking at the initial packet and deciding whether DTLS or =
uprotected=20
  SNMP is being used.  Once that decision is made, then a toggle is =

  set.  The toggle can be based on the 5 tuple (source IP, dest IP, =
source=20
  port, dest port, UDP) or it could be based on the source IP.  One =
the=20
  toggle is set for DTLS, only DTLS packets will be accepted for that 5 =
tuple or=20
  IP address.   The toggle might be kept in memory, or it =
might be=20
  saved to stable storage.  

  
 
------_=_NextPart_002_01CADA3D.E950B99A-- ------_=_NextPart_001_01CADA3D.E950B99A Content-Type: text/plain; name="ATT7013209.txt" Content-Transfer-Encoding: base64 Content-Description: ATT7013209.txt Content-Disposition: inline; filename="ATT7013209.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QUy1ESVIg bWFpbGluZyBsaXN0DQpPUFMtRElSQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29wcy1kaXINCg== ------_=_NextPart_001_01CADA3D.E950B99A-- From j.schoenwaelder@jacobs-university.de Mon Apr 12 08:25: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 F37E13A6808; Mon, 12 Apr 2010 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_40=-0.185, HELO_EQ_DE=0.35, J_CHICKENPOX_51=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 23rxveQlB6QD; Mon, 12 Apr 2010 08:25:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5E97A3A67EB; Mon, 12 Apr 2010 08:25:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 115F4C0004; Mon, 12 Apr 2010 17:25:10 +0200 (CEST) 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 aQGYnc044vuT; Mon, 12 Apr 2010 17:25:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33CECC000D; Mon, 12 Apr 2010 17:24:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 03BB8118062A; Mon, 12 Apr 2010 17:24:55 +0200 (CEST) Date: Mon, 12 Apr 2010 17:24:55 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" , tsv-dir@ietf.org, ops-dir@ietf.org Message-ID: <20100412152455.GB13603@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , tsv-dir@ietf.org, ops-dir@ietf.org, "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] FW: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm 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, 12 Apr 2010 15:25:17 -0000 On Mon, Apr 12, 2010 at 02:44:37PM +0200, Romascanu, Dan (Dan) wrote: > I am not sure if this review made it to the ISMS WG mail list. I think it did not - thanks for forwarding. Perhaps you can channel my response back since I am not sure where to send it either since I am not on the -dir lists myself... > ________________________________ > From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, April 07, 2010 6:41 AM > To: tsv-dir@ietf.org > Cc: ops-dir@ietf.org > Subject: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm [...] > However, after looking through both of these documents, as well as > this one, I?m still missing some basic details that I have seen > discussed in other DTLS transport documents (such as RADIUS over > DTLS). One of these details concerns how a deployment transitions > from conventional UDP to DTLS. There are a number of issues that > come up in a transition like this, such as whether DTLS and UDP are > to be sent on the same port, and if so, how that works. In real > deployments there is typically no ?flag day? so that (D)TLS and > uprotected SNMP may coexist for a while. It can be onerous to have > to track the upgrade state of every device on the network, since > they may not be uniform. SNMP transports in general co-exist and this is also true for DTLS and UDP. The document requests a separate port for TLS/DTLS transports, see the IANA consideration and the relevant *Domain definitions. Since the document requires bidrectional authentication, a client needs a proper certificate and thus some configuration effort is required to enable DTLS and once a client is configured to use DTLS, we do not assume it to fall back to an alternate transport. > From the documents, it appears that the transition is expected to be > handled via the MIB and explicit management, but I?d like to see > this issue discussed explicitly. Since keys and certificates are requires, I can not see how such a transition can ever work without explicit management. > In the RADIUS over DTLS transport doc, the assumption was that the > RADIUS sever is upgraded to support DTLS first, and that the RADIUS > clients are upgraded over time, so that during the transition there > can be a mixture of DTLS and non-DTLS clients. Once a client is > upgraded to support DTLS it is assumed to stay that way, so that the > server can set a ?toggle? that the client has been upgraded, > expecting that future sessions from that client will be DTLS > protected. Eventually when all the clients have been upgraded, a > switch can be set on the server only permitting DTLS sessions. > However, during the transition, it is not assumed that there is a > master list of all the clients that support DTLS. Rather, the > server derives this list dynamically based on its interaction with > clients, and therefore can provide reports to the administrator on > the status of the transition. The goal is to enable a transition to > DTLS operation which is relatively secure (e.g protecting against > downgrade attacks), while being easy to manage. The SNMP world generally does not deal with such policy issues or more specifically the existing SNMPv3 MIBs do not allow to express such client specific state. In fact, in the SNMPv3 world, the identifier of a client is its snmpEngineID and not its current transport endpoint. And this perfectly makes sense in situations are IP addresses are not assigned statically. To do what you suggest would require some major surgery on SNMPv3 MIB modules the ISMS WG is not chartered to do. > While Section 8.1 does talk about sessions and heartbeats, it > doesn?t provide the details of how implementations are expected to > toggle between DTLS and unprotected SNMPv3. For example, if DTLS > and regular SNMPv3 packets can be sent to the same port, how do > implementation distinguish DTLS packets from conventional SNMPv3 > packets? In some cases this can be done by looking at the initial > packet and deciding whether DTLS or uprotected SNMP is being used. > Once that decision is made, then a toggle is set. The toggle can be > based on the 5 tuple (source IP, dest IP, source port, dest port, > UDP) or it could be based on the source IP. One the toggle is set > for DTLS, only DTLS packets will be accepted for that 5 tuple or IP > address. The toggle might be kept in memory, or it might be saved > to stable storage. As mentioned above, both transports can co-exist and use different port numbers and SNMP architecturally separates the identity of an SNMP engine from its transport endpoint location. /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 Apr 12 11:51:16 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009593A6AA3; Mon, 12 Apr 2010 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUMS+r9NHAnX; Mon, 12 Apr 2010 11:51:15 -0700 (PDT) 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 0A9363A68AA; Mon, 12 Apr 2010 11:51:15 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 350CA98225; Mon, 12 Apr 2010 11:51:09 -0700 (PDT) From: Wes Hardaker To: "Romascanu\, Dan \(Dan\)" Organization: Sparta References: <20100412152455.GB13603@elstar.local> Date: Mon, 12 Apr 2010 11:51:08 -0700 In-Reply-To: <20100412152455.GB13603@elstar.local> (Juergen Schoenwaelder's message of "Mon, 12 Apr 2010 17:24:55 +0200") 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: ops-dir@ietf.org, "isms@ietf.org" , tsv-dir@ietf.org Subject: Re: [Isms] FW: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm 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, 12 Apr 2010 18:51:16 -0000 >>>>> On Mon, 12 Apr 2010 17:24:55 +0200, Juergen Schoenwaelder said: JS> As mentioned above, both transports can co-exist and use different JS> port numbers and SNMP architecturally separates the identity of an JS> SNMP engine from its transport endpoint location. I think one important thing to note is that the concerns discussed are actually all handled by the existing transport configuration mechanisms discussed in RFC3413 (a normative reference of this document). IE, we already have the ability to distinguish between who is talking to what using what protocols and that configuration mechanism has been around for a long time within the SNMP-TARGET-MIB and related MIB constructs. Combined with the newly requested ports, that Juergen already mentioned, this issue has already been discussed in the larger set of documents that define how SNMPv3 works in the larger system. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Apr 13 02:55: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 219363A68BF for ; Tue, 13 Apr 2010 02:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=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 3smBtZUZmaoD for ; Tue, 13 Apr 2010 02:55:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DA9CD3A68AB for ; Tue, 13 Apr 2010 02:55:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5B16C0010; Tue, 13 Apr 2010 11:55:24 +0200 (CEST) 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 CLsGwZ18jWu8; Tue, 13 Apr 2010 11:55:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7332AC0009; Tue, 13 Apr 2010 11:55:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B98E11828AA; Tue, 13 Apr 2010 11:55:19 +0200 (CEST) Date: Tue, 13 Apr 2010 11:55:19 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100413095519.GE15769@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@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] Updated TLSTM "pre" document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 09:55:32 -0000 On Wed, Apr 07, 2010 at 07:25:07PM +0200, Wes Hardaker wrote: > >>>>> On Wed, 07 Apr 2010 09:42:53 -0700, Wes Hardaker said: > > WH> I worry about getting all the references in the document correctly to > WH> rename all the objects, but I'll go through the work in doing so if > WH> that's what we feel is the right thing to do. > > FYI, I've gone ahead and done this. The new and updated document > reflecting all the outstanding issues I have in my list, including > Michael Peck's and IANA issues, can be found at: > > http://www.hardakers.net/temp/draft-ietf-isms-dtls-tm-10pre1.txt > > And the diff comparison can be found at: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-isms-dtls-tm-09.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-dtls-tm-10pre1.txt Thanks for the update. If I look at the IANA considerations, requesting on the one hand snmptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] snmpdtls TBD1/udp SNMPv3-DTLS [RFC-isms-dtls-tm-09] snmpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] snmpdtls-trap TBD2/udp SNMPv3-Trap-DTLS [RFC-isms-dtls-tm-09] and on the other hand 5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the SNMP Transport Model registry, 6. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in the SNMP Transport Model registry, does not seem consistent. Suppose we have SNMP over DTLS/SCTP and SNMP over DTLS/DCCP, would the ports be named as follows? snmpdtls TBD/sctp snmpdtls TBD/dccp I am also wondering whether having different prefixes for dtls over different transports really is needed. My understanding is that the prefixes are used by TSM (RFC 5591) to map tls:joe and ssh:joe to different security names. If we allocate "dtls" for DTLS, we can distinguish dtls:joe from tls:joe and ssh:joe. But is it really necessary to distinguish dtls-over-udp:joe from dtls-over-dccp:joe? /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 Apr 13 06:44: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 955923A69A2 for ; Tue, 13 Apr 2010 06:44:37 -0700 (PDT) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=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 Lqmgh4L6Pf8p for ; Tue, 13 Apr 2010 06:44:36 -0700 (PDT) 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 9E14F3A6A30 for ; Tue, 13 Apr 2010 06:44:32 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3E46A981FD; Tue, 13 Apr 2010 06:44:26 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20100308151656.523C53A69FB@core3.amsl.com> <20100407065512.GA4199@elstar.local> <20100413095519.GE15769@elstar.local> Date: Tue, 13 Apr 2010 06:44:26 -0700 In-Reply-To: <20100413095519.GE15769@elstar.local> (Juergen Schoenwaelder's message of "Tue, 13 Apr 2010 11:55:19 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] Updated TLSTM "pre" document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:44:37 -0000 >>>>> On Tue, 13 Apr 2010 11:55:19 +0200, Juergen Schoenwaelder said: JS> snmptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09] JS> snmpdtls TBD1/udp SNMPv3-DTLS [RFC-isms-dtls-tm-09] JS> snmpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09] JS> snmpdtls-trap TBD2/udp SNMPv3-Trap-DTLS [RFC-isms-dtls-tm-09] JS> and on the other hand Right, those need to be unique per transport (udp vs tcp level transport). JS> 5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the JS> SNMP Transport Model registry, JS> 6. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in JS> the SNMP Transport Model registry, Those need to be unique everywhere. JS> does not seem consistent. Suppose we have SNMP over DTLS/SCTP and SNMP JS> over DTLS/DCCP, would the ports be named as follows? JS> snmpdtls TBD/sctp JS> snmpdtls TBD/dccp That's what I'd probably pick, yes. It's the port for the DTLS protocol over each transport all of which blend nicely with DTLS over UDP as well. JS> I am also wondering whether having different prefixes for dtls over JS> different transports really is needed. My understanding is that the JS> prefixes are used by TSM (RFC 5591) to map tls:joe and ssh:joe to JS> different security names. If we allocate "dtls" for DTLS, we can JS> distinguish dtls:joe from tls:joe and ssh:joe. But is it really JS> necessary to distinguish dtls-over-udp:joe from dtls-over-dccp:joe? Well, that's a perfectly valid question. In my mind I was assuming every prefix instance would need to be unique, but you're right I don't think we have to assume that. Assigning them all to be just "dtls" is a reasonable thing to do. Anyone else with thoughts or comments on this subject? -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Tue Apr 13 10:23: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 4E1EC3A6A5B for ; Tue, 13 Apr 2010 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=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 x6E3kd7CcBQ7 for ; Tue, 13 Apr 2010 10:23:40 -0700 (PDT) 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 7E0BA3A6A4A for ; Tue, 13 Apr 2010 10:22:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ChXRznw1zkeDfL9gkUCP4K2PRMiK1VeReWqZ6VCUmQSkepoxzrSpYZmbi6H4ev8+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.49.241] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1O1jp0-0005zz-Oi for isms@ietf.org; Tue, 13 Apr 2010 13:22:47 -0400 Message-ID: <002801cadb2e$15e099e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100308151656.523C53A69FB@core3.amsl.com><20100407065512.GA4199@elstar.local><20100413095519.GE15769@elstar.local> Date: Tue, 13 Apr 2010 10:23:50 -0700 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035cff77eefd04859ae19008d83852edee0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.49.241 Subject: Re: [Isms] Updated TLSTM "pre" document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:23:41 -0000 Hi - > From: "Wes Hardaker" > To: "Wes Hardaker" > Cc: > Sent: Tuesday, April 13, 2010 6:44 AM > Subject: Re: [Isms] Updated TLSTM "pre" document ... > JS> I am also wondering whether having different prefixes for dtls over > JS> different transports really is needed. My understanding is that the > JS> prefixes are used by TSM (RFC 5591) to map tls:joe and ssh:joe to > JS> different security names. If we allocate "dtls" for DTLS, we can > JS> distinguish dtls:joe from tls:joe and ssh:joe. But is it really > JS> necessary to distinguish dtls-over-udp:joe from dtls-over-dccp:joe? > > Well, that's a perfectly valid question. In my mind I was assuming > every prefix instance would need to be unique, but you're right I don't > think we have to assume that. Assigning them all to be just "dtls" is > a reasonable thing to do. > > Anyone else with thoughts or comments on this subject? The only case I can think of where the distinction might potentially be useful would be in cases where outgoing notification streams are permitted on either transport, but certain notification types (perhaps because they potentially occur frequently) are to be limited via VACM to just one of the transports (probably DCCP). Seems kinda Rube-Goldberg to me, but you never know. :-) Randy From wjhns1@hardakers.net Wed Apr 14 15:43: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 2E33028C131 for ; Wed, 14 Apr 2010 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 kroaXHdMAFzc for ; Wed, 14 Apr 2010 15:43:37 -0700 (PDT) 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 56EF828C12D for ; Wed, 14 Apr 2010 15:43:37 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id DF116981E5; Wed, 14 Apr 2010 15:43:30 -0700 (PDT) From: Wes Hardaker To: Sean Turner Organization: Sparta Date: Wed, 14 Apr 2010 15:43:30 -0700 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: "G. R. Mundy" , isms@ietf.org Subject: [Isms] New TLSTM draft posted: fixes all outstanding issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:43:38 -0000 I just posted a draft-ietf-isms-dtls-tm-10 document that fixes all issues found during IETF last call and the issues brought forth by the gen-art review and the mib-doctor review (which were submitted yesterday). Sean and the chairs: I believe there is nothing left on my end to send this document to the IESG for their review of it. Let me know if you think I missed anything. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Wed Apr 14 15:45:03 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 DB2E13A68BE; Wed, 14 Apr 2010 15:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100414224503.DB2E13A68BE@core3.amsl.com> Date: Wed, 14 Apr 2010 15:45:03 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-10.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, 14 Apr 2010 22: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-10.txt Pages : 63 Date : 2010-04-14 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14154053.I-D@ietf.org> --NextPart-- From turners@ieca.com Thu Apr 15 05:23:10 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D768C28C2C4 for ; Thu, 15 Apr 2010 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 lgt0RStf1+Sk for ; Thu, 15 Apr 2010 05:22:58 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id B714528C226 for ; Thu, 15 Apr 2010 05:17:29 -0700 (PDT) Received: (qmail 90836 invoked from network); 15 Apr 2010 12:17:23 -0000 Received: from thunderfish.local (turners@71.191.4.114 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 15 Apr 2010 05:17:23 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Nunrso8VM1mabYZk4Po8JOX55AfBtliS7XtNhe5vqGFfu8dmchmABLPK1daUdKGVDN45N4wI72vQJb8l92GjRQUyLAt0u.WkWTlb9pzVh_B4FjWkc7HfNdnxH_NvCeX7vbdSY0PVbluwR5jzd8XNoCOk93Ws2pFV54jfgwRjZNQ53H_swt2UP2EJJreK7rmiWp17wEV9AAzgW50dDw0MSQRRV7Mb81h.KqYgkVGzgh_iALHrOjrzk2GHFkReABInzBp8ngJkj_zhY_bV5wHg9EbXyWQqyHcr2H46LkY9pcZskd8ipxeiol6QGvEMbyLAa4Uc0hAR6Dnpoa0.LmFl8VefD_0qHqGszaycVcEE05SdAsnBTKu_varajUPuzszYeNtQSOoati28Xo3tk9fEsYNBSftwuTFba3hqTQ_geVzvXhwFHwuxmSAkIgFw9OTpMNbaDM8pVgm7.g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BC703D2.7000409@ieca.com> Date: Thu, 15 Apr 2010 08:17:22 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: isms@ietf.org References: <20100414224503.DB2E13A68BE@core3.amsl.com> In-Reply-To: <20100414224503.DB2E13A68BE@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Isms] I-D Action:draft-ietf-isms-dtls-tm-10.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, 15 Apr 2010 12:23:10 -0000 Internet-Drafts@ietf.org wrote: > 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-10.txt > Pages : 63 > Date : 2010-04-14 > > This document describes a Transport Model for the Simple Network > Management Protocol (SNMP), that uses either the Transport Layer > Security protocol or the Datagram Transport Layer Security (DTLS) > protocol. The TLS and DTLS protocols provide authentication and > privacy services for SNMP applications. This document describes how > the TLS Transport Model (TLSTM) implements the needed features of a > SNMP Transport Subsystem to make this protection possible in an > interoperable way. > > This transport model is designed to meet the security and operational > needs of network administrators. It supports sending of SNMP > messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of > TCP's improved support for larger packet sizes and the DTLS mode > provides potentially superior operation in environments where a > connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS > integrate well into existing public keying infrastructures. > > This document also defines a portion of the Management Information > Base (MIB) for use with network management protocols. In particular > it defines objects for managing the TLS Transport Model for SNMP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-10.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. I added this ID to the May 6th IESG telechat. I would have added it to the April 22nd telechat, but there are already 20+ documents on the agenda. spt From wjhns1@hardakers.net Thu Apr 15 05:42: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 1E5DC28C223 for ; Thu, 15 Apr 2010 05:42:15 -0700 (PDT) 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 3orJljMbm5It for ; Thu, 15 Apr 2010 05:42:11 -0700 (PDT) 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 506E128C24B for ; Thu, 15 Apr 2010 05:37:51 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9590798200; Thu, 15 Apr 2010 05:37:44 -0700 (PDT) From: Wes Hardaker To: Sean Turner Organization: Sparta References: <20100414224503.DB2E13A68BE@core3.amsl.com> <4BC703D2.7000409@ieca.com> Date: Thu, 15 Apr 2010 05:37:44 -0700 In-Reply-To: <4BC703D2.7000409@ieca.com> (Sean Turner's message of "Thu, 15 Apr 2010 08:17:22 -0400") 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] I-D Action:draft-ietf-isms-dtls-tm-10.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, 15 Apr 2010 12:42:15 -0000 >>>>> On Thu, 15 Apr 2010 08:17:22 -0400, Sean Turner said: ST> I added this ID to the May 6th IESG telechat. I would have added it ST> to the April 22nd telechat, but there are already 20+ documents on the ST> agenda. Thanks for the update Sean. -- Wes Hardaker Cobham Analytic Solutions From turners@ieca.com Mon Apr 19 16:39: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 B95AB3A69B8 for ; Mon, 19 Apr 2010 16:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 MDbMlysdjNJC for ; Mon, 19 Apr 2010 16:39:05 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 5D8593A67A3 for ; Mon, 19 Apr 2010 16:39:03 -0700 (PDT) Received: (qmail 63399 invoked from network); 19 Apr 2010 23:38:54 -0000 Received: from thunderfish.local (turners@71.191.11.39 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2010 16:38:54 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _DCMWN4VM1kAYSORe1NOgnLu0ee2k6Hm3O_vKrj_4TKYMb4jgWVI4iVx4Gp587Rz5bsd1acOZEBXI5551gmlUe3PHeQ0dWU6OLJZn8xlvu98Ex9DYk2H4uMkkrWxi.haGcLt2mAKx9NTSUbT4KSQEWrkPTy3PkmPWVsJefJdThWIkVtyD7aQT4XKAnG3AAP4JEQJhCj7Sl1sp5MiG7T9YaBNWJcr8RNal.VOSE_JWVJLyOGF2KGbTFCkZFNnRxlpFjXXbEhSUo0h.g1o8wKTr3gHv2ux5RwikUN0324Brwuk.9gVetQHC.bbP.VL3Eo9thg3jLCs14PpfQjZU5FhizlWOBLk1RrrzQLsm7Y.Dlf7LInk1zurFhl0t9hSVfz8IU.wukI0xVCJY.8.9aXdboBsrv_9owHDgcHU3N6VqXqw8rJQuNejC03yWfbVR2Oa.wvGoPqpdAFAIw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCCE98D.2040305@ieca.com> Date: Mon, 19 Apr 2010 19:38:53 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dave Nelson , 'RFC Errata System' , "kaushik_narayan@yahoo.com" , "dnelson@elbrysnetworks.com" , "turners@ieca.com" , "tim.polk@nist.gov" , "Russ.Mundy@sparta.com" , "mbj@tail-f.com" , "isms@ietf.org" References: <20100331113222.82098E0791@rfc-editor.org> <19B58DD12A14429AA8E5B3787900F393@NEWTON603> <20100331231806.GA3901@elstar.local> In-Reply-To: <20100331231806.GA3901@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Isms] [Editorial Errata Reported] RFC5608 (2100) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:39:06 -0000 I'll fix this in the errata note section. spt Juergen Schoenwaelder wrote: > On Wed, Mar 31, 2010 at 01:38:57PM +0200, Dave Nelson wrote: > >> I recommend that this errata report and the proposed correction be accepted. > > I agree. While perhaps obvious, it might be useful to mention that the > term Inactivity-Timeout appears twice in Section 2.3 and both > occurances should be replaced. > > /js > >>> -----Original Message----- >>> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of >>> RFC Errata System >>> Sent: Wednesday, March 31, 2010 7:32 AM >>> To: kaushik_narayan@yahoo.com; dnelson@elbrysnetworks.com; >>> turners@ieca.com; tim.polk@nist.gov; Russ.Mundy@sparta.com; >>> j.schoenwaelder@jacobs-university.de >>> Cc: mbj@tail-f.com; isms@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Isms] [Editorial Errata Reported] RFC5608 (2100) >>> >>> >>> The following errata report has been submitted for RFC5608, >>> "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple >>> Network Management Protocol (SNMP) Transport Models". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5608&eid=2100 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Martin Bjvrklund >>> >>> Section: 2.3 >>> >>> Original Text >>> ------------- >>> Inactivity-Timeout >>> >>> Corrected Text >>> -------------- >>> Idle-Timeout >>> >>> Notes >>> ----- >>> The list of attributes in section 3 correctly lists the Idle-Timeout >>> attribute. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5608 (draft-ietf-isms-radius-usage-07) >>> -------------------------------------- >>> Title : Remote Authentication Dial-In User Service (RADIUS) >>> Usage for Simple Network Management Protocol (SNMP) Transport Models >>> Publication Date : August 2009 >>> Author(s) : K. Narayan, D. Nelson >>> Category : PROPOSED STANDARD >>> Source : Integrated Security Model for SNMP >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >