From root@core3.amsl.com Wed Dec 2 00:15:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B099F3A694F; Wed, 2 Dec 2009 00:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091202081501.B099F3A694F@core3.amsl.com> Date: Wed, 2 Dec 2009 00:15:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.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, 02 Dec 2009 08:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Extensions to View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-00.txt Pages : 18 Date : 2009-12-01 This memo describes a backward-compatible extension to the View-based Access Control Model for SNMPv3 for use with RADIUS and other AAA services to provide authorization of MIB database access. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-02000941.I-D@ietf.org> --NextPart-- From ietfdbh@comcast.net Wed Dec 2 05:42:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F103A6AB7 for ; Wed, 2 Dec 2009 05:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, 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 MxUtNyfqHBsM for ; Wed, 2 Dec 2009 05:42:54 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 020763A689F for ; Wed, 2 Dec 2009 05:42:53 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id CCzs1d0020vyq2s57DinAc; Wed, 02 Dec 2009 13:42:47 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA05.westchester.pa.mail.comcast.net with comcast id CDim1d00c284sdk3RDimEz; Wed, 02 Dec 2009 13:42:47 +0000 From: "David Harrington" To: References: <20091202081501.B099F3A694F@core3.amsl.com> Date: Wed, 2 Dec 2009 08:42:45 -0500 Message-ID: <108701ca7355$5480c4e0$a1135d85@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091202081501.B099F3A694F@core3.amsl.com> Thread-Index: AcpzJ4oFo9lM/UiyTIO3YB9WR496VAAI6J7A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.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, 02 Dec 2009 13:42:55 -0000 Hi, I took a quick look at the document. Most of my comments are editorial and could have been done by David and Kaushik had I pointed these out earlier. I apologize for not providing this guidance earlier. Open Issue #7: Generally make the document look like an SNMP document. The MIB Doctors have described certain sections they like to have in a MIB module in keeping with RFC4181. The templates at http://tools.ietf.org/tools/templates/mib-doc-template-xml.txt (annotated xml2rfc template) and http://tools.ietf.org/tools/templates/mib-doc-template-advice.txt (annotated plain text) describe this recommended layout: Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 5 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 5.2. The [TEMPLATE TODO] Subtree . . . . . . . . . . . . . . . 5 5.3. The Notifications Subtree . . . . . . . . . . . . . . . . 5 5.4. The Table Structures . . . . . . . . . . . . . . . . . . . 5 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 5 6.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 6 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 6 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.3. URL References . . . . . . . . . . . . . . . . . . . . . . 10 Organizing the information in this manner makes it easier for expert review since the discussion of topics that MIB Doctors typically check for are clearly identified. The current document does not provide sections 2,3,4,5,6, or 8. Section 2 is boilerplate. The latest version can be cut and pasted from ops.ietf.org. Section 3 usually just contains the RFC2119 boilerplate, plus any new terminology. Section 1 and section 4 are usually used to deacribe the general problem statement and a design overview of how the technology being modeled in the MIB module works. The current sections 1-3 could be split into a section 1 Introduction, and a section 4 Overview. Portions of the current section 3 discuss some table-specific handling. These discussions could be split out into a recommended section 5 Structure of the MIB Module. The first paragraph in section 5 could be moved and expanded to become the recommended section 6. Section 8 is boilerplate, also available from ops.ietf.org, to be filled in with lists of sensitive objects. Section 9 is mostly boilerplate, to be filled in with the requested OID (once open issue #3 is decided) I think this would help to make the current document look more like other MIB module documents, and make it easier to determine if all the "normal" requirements of MIB module documents have been addressed. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, December 02, 2009 3:15 AM > To: i-d-announce@ietf.org > Cc: isms@ietf.org > Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Integrated Security Model > for SNMP Working Group of the IETF. > > > Title : Extensions to View-based Access > Control Model for use with RADIUS > Author(s) : K. Narayan, et al. > Filename : draft-ietf-isms-radius-vacm-00.txt > Pages : 18 > Date : 2009-12-01 > > This memo describes a backward-compatible extension to the View-based > Access Control Model for SNMPv3 for use with RADIUS and other AAA > services to provide authorization of MIB database access. This > extension is intended to be used in conjunction with secure SNMP > Transport Models that facilitate RADIUS authentication, such as the > Secure Shell Transport Model. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-00.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. > From ietfdbh@comcast.net Wed Dec 2 06:05:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54CC3A6A5C for ; Wed, 2 Dec 2009 06:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 XjBXIu4RBOmg for ; Wed, 2 Dec 2009 06:05:37 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id DC19E3A6A2F for ; Wed, 2 Dec 2009 06:05:36 -0800 (PST) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA11.westchester.pa.mail.comcast.net with comcast id CCum1d0031wpRvQ5BE5WP3; Wed, 02 Dec 2009 14:05:30 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA18.westchester.pa.mail.comcast.net with comcast id CE5Y1d00L284sdk3eE5Ygl; Wed, 02 Dec 2009 14:05:32 +0000 From: "David Harrington" To: Date: Wed, 2 Dec 2009 09:05:28 -0500 Message-ID: <109c01ca7358$80e10fb0$a1135d85@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: AcpzWIBKJtUCeaVJRGmQGEtgDt5ncw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] Issue#3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:05:37 -0000 3. Where should the MIB Module defined in this document be rooted? (under snmpModules or mib-2?) I recommend mib-2. That's where we typically put new modules. It is where we put the SNMP-SSH-TM-MIB. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From randy_presuhn@mindspring.com Wed Dec 2 08:34:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFB33A6933 for ; Wed, 2 Dec 2009 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yoNzdbIy4EJZ for ; Wed, 2 Dec 2009 08:34:30 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 336A33A6839 for ; Wed, 2 Dec 2009 08:34:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I3XmTOGrkhrH39wTumcVbtBviAGQvRskPgkNfUQ7Z4C+23VOYsfvNcuFnPanJRZL; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.141] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NFs9l-0001ZU-Vj for isms@ietf.org; Wed, 02 Dec 2009 11:34:22 -0500 Message-ID: <000601ca736d$7dc3e4a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091202081501.B099F3A694F@core3.amsl.com> <108701ca7355$5480c4e0$a1135d85@china.huawei.com> Date: Wed, 2 Dec 2009 08:35:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9281928086922bf9061db97ddb77afe40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.141 Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.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, 02 Dec 2009 16:34:31 -0000 Hi - As an editor... If there are no objections, I will make these changes. Randy > From: "David Harrington" > To: > Sent: Wednesday, December 02, 2009 5:42 AM > Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt > > Hi, > > I took a quick look at the document. > > Most of my comments are editorial and could have been done by David > and Kaushik had I pointed these out earlier. I apologize for not > providing this guidance earlier. > > Open Issue #7: Generally make the document look like an SNMP document. > > The MIB Doctors have described certain sections they like to have in a > MIB module in keeping with RFC4181. > The templates at > http://tools.ietf.org/tools/templates/mib-doc-template-xml.txt > (annotated xml2rfc template) and > http://tools.ietf.org/tools/templates/mib-doc-template-advice.txt > (annotated plain text) describe this recommended layout: > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > 4 > 2. The Internet-Standard Management Framework . . . . . . . . . . > 4 > 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . > 4 > 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . > 5 > 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . > 5 > 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . > 5 > 5.2. The [TEMPLATE TODO] Subtree . . . . . . . . . . . . . . . > 5 > 5.3. The Notifications Subtree . . . . . . . . . . . . . . . . > 5 > 5.4. The Table Structures . . . . . . . . . . . . . . . . . . . > 5 > 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . > 5 > 6.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . > 6 > 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . > 6 > 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . > 6 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . > 7 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 8 > 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . > 9 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . > 9 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . > 9 > 11.2. Informative References . . . . . . . . . . . . . . . . . . > 10 > 11.3. URL References . . . . . . . . . . . . . . . . . . . . . . > 10 > > > Organizing the information in this manner makes it easier for expert > review since the discussion of topics that MIB Doctors typically check > for are clearly identified. > > The current document does not provide sections 2,3,4,5,6, or 8. > > Section 2 is boilerplate. The latest version can be cut and pasted > from ops.ietf.org. > Section 3 usually just contains the RFC2119 boilerplate, plus any new > terminology. > > Section 1 and section 4 are usually used to deacribe the general > problem statement and a design overview of how the technology being > modeled in the MIB module works. The current sections 1-3 could be > split into a section 1 Introduction, and a section 4 Overview. > > Portions of the current section 3 discuss some table-specific > handling. These discussions could be split out into a recommended > section 5 Structure of the MIB Module. > > The first paragraph in section 5 could be moved and expanded to become > the recommended section 6. > Section 8 is boilerplate, also available from ops.ietf.org, to be > filled in with lists of sensitive objects. > Section 9 is mostly boilerplate, to be filled in with the requested > OID (once open issue #3 is decided) > > I think this would help to make the current document look more like > other MIB module documents, and make it easier to determine if all the > "normal" requirements of MIB module documents have been addressed. > > dbh > > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, December 02, 2009 3:15 AM > > To: i-d-announce@ietf.org > > Cc: isms@ietf.org > > Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Integrated Security Model > > for SNMP Working Group of the IETF. > > > > > > Title : Extensions to View-based Access > > Control Model for use with RADIUS > > Author(s) : K. Narayan, et al. > > Filename : draft-ietf-isms-radius-vacm-00.txt > > Pages : 18 > > Date : 2009-12-01 > > > > This memo describes a backward-compatible extension to the > View-based > > Access Control Model for SNMPv3 for use with RADIUS and other AAA > > services to provide authorization of MIB database access. This > > extension is intended to be used in conjunction with secure SNMP > > Transport Models that facilitate RADIUS authentication, such as the > > Secure Shell Transport Model. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-00.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. > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Wed Dec 2 08:50:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0073A6AD6 for ; Wed, 2 Dec 2009 08:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYByjV5iK8FQ for ; Wed, 2 Dec 2009 08:50:50 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 22C5C3A6870 for ; Wed, 2 Dec 2009 08:50:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WYfhkdcj/otLz6UukA0Ov156M/3QNlVxAl3unHC8EiFmXB54PK2M+Dbxj3Dpn7bv; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.141] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NFsPZ-0006Kh-W7 for isms@ietf.org; Wed, 02 Dec 2009 11:50:42 -0500 Message-ID: <004b01ca736f$c705f160$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <109c01ca7358$80e10fb0$a1135d85@china.huawei.com> Date: Wed, 2 Dec 2009 08:52:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9d17298f177501255ee89c7fbe8a199f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.141 Subject: Re: [Isms] Issue#3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:50:51 -0000 Hi - As an editor... If there are no objections I will make the change as suggested. Randy ----- Original Message ----- > From: "David Harrington" > To: > Sent: Wednesday, December 02, 2009 6:05 AM > Subject: [Isms] Issue#3 > > 3. Where should the MIB Module defined in this document be rooted? > (under snmpModules or mib-2?) > > I recommend mib-2. That's where we typically put new modules. It is > where we put the SNMP-SSH-TM-MIB. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From dnelson@elbrysnetworks.com Wed Dec 2 09:10:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B9728C217 for ; Wed, 2 Dec 2009 09:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 cUe9LknY7Hsy for ; Wed, 2 Dec 2009 09:10:52 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 8A2D128C0EE for ; Wed, 2 Dec 2009 09:10:51 -0800 (PST) Received: (qmail 11980 invoked from network); 2 Dec 2009 17:10:40 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 2 Dec 2009 17:10:40 -0000 From: "David B. Nelson" To: "Randy Presuhn" In-Reply-To: <000601ca736d$7dc3e4a0$6801a8c0@oemcomputer> X-Priority: 3 References: <20091202081501.B099F3A694F@core3.amsl.com> <108701ca7355$5480c4e0$a1135d85@china.huawei.com> <000601ca736d$7dc3e4a0$6801a8c0@oemcomputer> Message-Id: <511AB124-E466-495C-8C0A-FC2EE1CADB3F@elbrysnetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 12:10:40 -0500 X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.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, 02 Dec 2009 17:10:53 -0000 On Dec 2, 2009, at 11:35 AM, Randy Presuhn wrote: > As an editor... > If there are no objections, I will make these changes. I think following the document organizational structure that Dave Harrington suggests may be useful. After all, there are really only two major items of content, the EOP and the MIB module. Having said that, this document is not *just* a MIB module definition. As long as the other (important) elements can be located in logical and appropriately titled sections within this organizational template, and not be tucked away under a non-obvious section heading, I'm supportive of Dave's suggestion. From root@core3.amsl.com Wed Dec 2 11:45:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5BD793A6AF9; Wed, 2 Dec 2009 11:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091202194501.5BD793A6AF9@core3.amsl.com> Date: Wed, 2 Dec 2009 11:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Extensions to View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-01.txt Pages : 19 Date : 2009-12-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes a backward-compatible extension to the View-based Access Control Model (VACM) for SNMPv3 for use with RADIUS and other AAA services to provide authorization of MIB database access, and defines objects for managing this extension. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-02114253.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Wed Dec 2 11:59:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3F33A687D for ; Wed, 2 Dec 2009 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0+GGua5D3YQ for ; Wed, 2 Dec 2009 11:59:51 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 08D8C3A6829 for ; Wed, 2 Dec 2009 11:59:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=H494t8p3p3oZswyQ09/galsn7cP4a5YuRH77ZW65OBtXLx/w2uHBhZMri9SlvZs4; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.141] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NFvMU-0002qh-RX for isms@ietf.org; Wed, 02 Dec 2009 14:59:43 -0500 Message-ID: <002a01ca738a$2fbee080$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091202194501.5BD793A6AF9@core3.amsl.com> Date: Wed, 2 Dec 2009 12:01:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9d7f888e1cdb9f6bb0779a50a25106d76350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.141 Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:59:51 -0000 Hi - > From: > To: > Cc: > Sent: Wednesday, December 02, 2009 11:45 AM > Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-01.txt Major changes from previous version: anchored MIB from mib-2 re-organized document according to MIB boilerplate If you have specific comments, please be kind to your editor by starting a new thread for each issue. Randy From ietfdbh@comcast.net Wed Dec 2 13:31:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986F93A6912 for ; Wed, 2 Dec 2009 13:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 ZmchIr4-g8mZ for ; Wed, 2 Dec 2009 13:31:17 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 7B17F3A681B for ; Wed, 2 Dec 2009 13:31:17 -0800 (PST) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA09.westchester.pa.mail.comcast.net with comcast id CCun1d0071wpRvQ59MXAWY; Wed, 02 Dec 2009 21:31:10 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA18.westchester.pa.mail.comcast.net with comcast id CMXD1d008284sdk3eMXDnU; Wed, 02 Dec 2009 21:31:13 +0000 From: "David Harrington" To: "'David B. Nelson'" , "'Randy Presuhn'" References: <20091202081501.B099F3A694F@core3.amsl.com><108701ca7355$5480c4e0$a1135d85@china.huawei.com><000601ca736d$7dc3e4a0$6801a8c0@oemcomputer> <511AB124-E466-495C-8C0A-FC2EE1CADB3F@elbrysnetworks.com> Date: Wed, 2 Dec 2009 16:31:09 -0500 Message-ID: <110501ca7396$c370f910$a1135d85@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <511AB124-E466-495C-8C0A-FC2EE1CADB3F@elbrysnetworks.com> Thread-Index: AcpzcmpHBF9zryjJRg2jTZiaft7q4gAI63Pw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.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, 02 Dec 2009 21:31:18 -0000 Hi, I also noticed the need to have sections that describe the underlying functionality. There is some in-depth stuff about RADIUS and VACM in the current document. That can be done either as clearly marked subsections of the Overview, or in a separate section. The editors can make that call as far as I'm concerned. The important point about the template was to make sure all the i's were dotted and t's were crossed for a MIB module document, to make it easy for subsequent review, not to constrain the section numbers to match the template ;-) dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Wednesday, December 02, 2009 12:11 PM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt > > On Dec 2, 2009, at 11:35 AM, Randy Presuhn wrote: > > > As an editor... > > If there are no objections, I will make these changes. > > I think following the document organizational structure that Dave > Harrington suggests may be useful. After all, there are really only > two major items of content, the EOP and the MIB module. Having said > that, this document is not *just* a MIB module definition. > As long as > the other (important) elements can be located in logical and > appropriately titled sections within this organizational > template, and > not be tucked away under a non-obvious section heading, I'm > supportive > of Dave's suggestion. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Wed Dec 2 17:19:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98413A68DE for ; Wed, 2 Dec 2009 17:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 HelwcU2EHpIy for ; Wed, 2 Dec 2009 17:19:26 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 14DB83A6358 for ; Wed, 2 Dec 2009 17:19:23 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 7E097982A8 for ; Wed, 2 Dec 2009 17:19:15 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 02 Dec 2009 17:19:14 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 01:19:27 -0000 --=-=-= I've been plugging away at resolving the outstanding comments received during the last call round and most of them don't require a heavy amount of discussion and review. But a few I wanted to run by the WG in advance before publication to see if they meet the expectations based on those who participated in the WG discussions. The first issue presented at the WG meeting was surrounding the need to map otherName data in a securityName. The solution agreed to during the WG meeting was to use OBJECT-IDENTITY clauses for defining matching so that the system is extensible in the future when someone wishes to define an otherName mapping, for example. (But we wouldn't define an otherName mapping at all at this point). The results of implementing this are as follows: 1) The new table looks like this: TlstmCertToSNEntry ::= SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, tlstmCertToSNType INTEGER (specific(1), mapped(2)), tlstmCertToSNSecurityName SnmpAdminString, tlstmCertToSNMapType AutonomousType, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } And the tlstmCertToSNMapType is used to refer to external identities, of which the draft defines these five: tlstmCertSANRFC822Name tlstmCertSANDNSName tlstmCertSANIpAddress tlstmCertSANAny tlstmCertCommonName The full patch is attached below as is the full MIB so you can read all the nitty-gritty details. However, there is another potential solution that I wanted to see if anyone had opinions on: Specifically, the "specific" mapping (which directly says "use the securityName found in the tlstmCertToSNSecurityName column) could also be turned into an identity, though an extension field is still needed. 2) Thus the second alternative is to do this instead: TlstmCertToSNEntry ::= SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, * tlstmCertToSNMapType AutonomousType, * tlstmCertToSNMapData OCTET STRING, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } The *'d fields would then be used to do *any* type of mapping, and the 'specified' enum would then be converted to a OBJECT-IDENTITY which would say to directly use the data found in the now generic tlstmCertToSNMapData column. The advantage of this would be that any other future extensions could have a spare column of data to help configure the OBJECT-IDENTITY's behavior. The downside is that making it generic makes it "less straightforward". So, my question to the WG is: should I: 1) use the approach defined in #1 above and the patch/mib below? 2) use the approach described in #2 to make it "really generic"? -- Wes Hardaker Cobham Analytic Solutions --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=issue1.patch diff --git a/draft/draft-ietf-isms-dtls-tm.xml b/draft/draft-ietf-isms-dtls-tm.xml index 520040d..6f30ebc 100644 --- a/draft/draft-ietf-isms-dtls-tm.xml +++ b/draft/draft-ietf-isms-dtls-tm.xml @@ -1539,7 +1539,8 @@ IMPORTS OBJECT-IDENTITY, snmpModules, snmpDomains, Counter32, Unsigned32, NOTIFICATION-TYPE FROM SNMPv2-SMI - TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType + TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, + AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF @@ -1637,8 +1638,9 @@ tlstmMIB MODULE-IDENTITY -- ************************************************ tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 } -tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 1 } -tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 2 } +tlstmIdentities OBJECT IDENTIFIER ::= { tlstmMIB 1 } +tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 2 } +tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 3 } -- ************************************************ -- tlstmObjects - Objects @@ -1907,6 +1909,78 @@ Fingerprint ::= TEXTUAL-CONVENTION " SYNTAX OCTET STRING (SIZE (1..255)) +-- Identities + +tlstmCertToSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 } + +tlstmCertSANRFC822Name OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's rfc822Name to a SNMPv3 + securityName. The local part of the rfc822Name is + passed unaltered but the host-part of the name must + be passed in lower case. + + Example rfc822Name Field: FooBar@Example.COM + is mapped to securityName: FooBar@exmaple.com" + ::= { tlstmCertToSNMIdentities 1 } + +tlstmCertSANDNSName OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's dNSName to a SNMPv3 + securityName by directly passing the value without + any transformations." + ::= { tlstmCertToSNMIdentities 2 } + +tlstmCertSANIpAddress OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's ipAddress to a SNMPv3 + securityName by transforming the binary encoded + address as follows: + + + 1) for IPv4 the value is converted into a decimal + dotted quad address (e.g. '192.0.2.1') + + 2) for IPv6 addresses the value is converted into a + 32-character hexadecimal string without any colon + separators. + + Note that the resulting length is the maximum + length supported by the View-Based Access Control + Model (VACM). Note that using both the Transport + Security Model's support for transport prefixes + (see the SNMP-TSM-MIB's + snmpTsmConfigurationUsePrefix object for details) + will result in securityName lengths that exceed + what VACM can handle." + ::= { tlstmCertToSNMIdentities 3 } + +tlstmCertSANAny OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps any of the following fields using the + corresponding mapping algorithms: + + |------------+------------------------| + | Type | Algorithm | + |------------+------------------------| + | rfc822Name | tlstmCertSANRFC822Name | + | dNSName | tlstmCertSANDNSName | + | ipAddress | tlstmCertSANIpAddress | + |------------+------------------------| + + The first matching subjectAltName value found in the + certificate any of the above types MUST be used when + deriving the securityName." + ::= { tlstmCertToSNMIdentities 4 } + +tlstmCertCommonName OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a certificate's CommonName to a SNMPv3 + securityName by directly passing the value without + any transformations." + ::= { tlstmCertToSNMIdentities 5 } + + -- The tlstmSession Group tlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 } @@ -2098,9 +2172,9 @@ tlstmCertToSNEntry OBJECT-TYPE TlstmCertToSNEntry ::= SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, - tlstmCertToSNMapType INTEGER, + tlstmCertToSNType INTEGER, tlstmCertToSNSecurityName SnmpAdminString, - tlstmCertToSNSANType INTEGER, + tlstmCertToSNMapType AutonomousType, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } @@ -2124,8 +2198,8 @@ tlstmCertToSNFingerprint OBJECT-TYPE is dictated by the tlstmCertToSNMapType column." ::= { tlstmCertToSNEntry 2 } -tlstmCertToSNMapType OBJECT-TYPE - SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) } +tlstmCertToSNType OBJECT-TYPE + SYNTAX INTEGER { specified(1), mapped(2) } MAX-ACCESS read-create STATUS current DESCRIPTION @@ -2140,41 +2214,27 @@ tlstmCertToSNMapType OBJECT-TYPE column's value is ignored for all other tlstmCertToSNMapType values. - bySubjectAltName(2): - The securityName that should be used to + mapped(2): The securityName that should be used to associate with the session should be taken from - the subjectAltName(s) portion of the client's - X.509 certificate. The subjectAltName used MUST - be the first encountered subjectAltName type - indicated by the tlstmCertToSNSANType column. - - If the resulting mapped value from the - subjectAltName component is not compatible with - the needed requirements of a securityName (e.g., + client's X.509 certificate. The exact mechanism + used to derive the securityName from the + certificate is indicated by the + tlstmCertToSNMapType column. + + If the resulting mapped value from the necessary + certificate component is not compatible with the + needed requirements of a securityName (e.g., VACM imposes a 32-octet-maximum length and the certificate derived securityName could be - longer) then the next appropriate subjectAltName - of the correct type should be used if available. + longer) then the next appropriate value should + be used if one is available (e.g. it is possible + for a certificate to include multiple + subjectAltName values of the same type). - If no appropriate subjectAltName of the given - type is found within the certificate then - additional rows in the tlstmCertToSNTable must - be searched for additional - tlstmCertToSNFingerprint matches. - - byCN(3): The securityName that should be used to - associate with the session should be taken from - the CommonName portion of the Subject field from - the client's presented X.509 certificate. - - If the value of the CommonName component is not - compatible with the needed requirements of a - securityName (e.g., VACM imposes a - 32-octet-maximum length and the certificate - derived securityName could be longer) then - additional rows in the tlstmCertToSNTable must - be searched for additional - tlstmCertToSNFingerprint matches." + If no appropriate value for the given type is + found within the certificate then additional + rows in the tlstmCertToSNTable must be searched + for additional tlstmCertToSNFingerprint matches." DEFVAL { specified } ::= { tlstmCertToSNEntry 3 } @@ -2195,48 +2255,16 @@ tlstmCertToSNSecurityName OBJECT-TYPE DEFVAL { "" } ::= { tlstmCertToSNEntry 4 } -tlstmCertToSNSANType OBJECT-TYPE - SYNTAX INTEGER { any(1), rfc822Name(2), dNSName(3), - ipAddress(4), otherName(5) } +tlstmCertToSNMapType OBJECT-TYPE + SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the subjectAltName type that may be used to extract - the securityName from. - - The any(1) value indicates the (D)TLS server should use the - first value found for any of the following subjectAltName - value types for the securityName: rfc822Name, dNSName, and - ipAddress. - - When multiple types for a given subjectAltName type are - encountered within a certificate the first legally usable - value is the one selected. - - Values for type ipAddress(4) are converted to a valid - securityName by: - - 1) for IPv4 the value is converted into a decimal dotted - quad address (e.g. '192.0.2.1') - - 2) for IPv6 addresses the value is converted into a - 32-character hexadecimal string without any colon - separators. - - Note that the resulting length is the maximum length - supported by the View-Based Access Control Model - (VACM). Note that using both the Transport Security - Model's support for transport prefixes (see the - SNMP-TSM-MIB::snmpTsmConfigurationUsePrefix object for - details) will result in securityName lengths that - exceed what VACM can handle. - - Values for type otherName(5) are converted to a valid - securityName by using only the decoded value portion of the - OtherName sequence. I.E. the OBJECT IDENTIFIER portion of the - OtherName sequence is not included as part of the resulting - securityName." - DEFVAL { any } + the securityName from. Details for mapping of a particular + type SHALL be specified in the DESCRIPTION clause of the + OBJECT-IDENTITY that describes the mapping." + DEFVAL { tlstmCertSANAny } ::= { tlstmCertToSNEntry 5 } tlstmCertToSNStorageType OBJECT-TYPE @@ -2267,16 +2295,16 @@ tlstmCertToSNRowStatus OBJECT-TYPE tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until - the corresponding tlstmCertToSNFingerprint, - tlstmCertToSNMapType, tlstmCertToSNSecurityName, and - tlstmCertToSNSANType columns have been set. + the corresponding tlstmCertToSNFingerprint, tlstmCertToSNType, + tlstmCertToSNSecurityName, and tlstmCertToSNMapType columns + have been set. The following objects may not be modified while the value of this object is active(1): - tlstmCertToSNFingerprint - - tlstmCertToSNMapType + - tlstmCertToSNType - tlstmCertToSNSecurityName - - tlstmCertToSNSANType + - tlstmCertToSNMapType An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error." @@ -2525,10 +2553,14 @@ tlstmAddrRowStatus OBJECT-TYPE -- ************************************************ tlstmServerCertNotFound NOTIFICATION-TYPE + OBJECTS { tlstmSessionInvalidServerCertificates } STATUS current DESCRIPTION "Notification that the server certificate presented by a SNMP - over (D)TLS server could not be found in the tlstmAddrTable." + over (D)TLS server was invalid. Reasons for + invalidation includes, but is not limited to, cryptographic + validation failures and an unexpected presented certificate + identity." ::= { tlstmNotifications 1 } tlstmServerAuthFailure NOTIFICATION-TYPE @@ -2591,9 +2623,9 @@ tlstmIncomingGroup OBJECT-GROUP tlstmCertToSNCount, tlstmCertToSNTableLastChanged, tlstmCertToSNFingerprint, - tlstmCertToSNMapType, + tlstmCertToSNType, tlstmCertToSNSecurityName, - tlstmCertToSNSANType, + tlstmCertToSNMapType, tlstmCertToSNStorageType, tlstmCertToSNRowStatus } --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=TLSTM-MIB TLSTM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules, snmpDomains, Counter32, Unsigned32, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB snmpTargetParamsName, snmpTargetAddrName FROM SNMP-TARGET-MIB ; tlstmMIB MODULE-IDENTITY LAST-UPDATED "200807070000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de Russ Mundy SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 USA Co-editors: Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 USA ietf@hardakers.net " DESCRIPTION " The TLS Transport Model MIB Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note REVISION "200807070000Z" DESCRIPTION "The initial version, published in RFC XXXX." -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note ::= { snmpModules xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note -- ************************************************ -- subtrees of the TLSTM-MIB -- ************************************************ tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 } tlstmIdentities OBJECT IDENTIFIER ::= { tlstmMIB 1 } tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 2 } tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 3 } -- ************************************************ -- tlstmObjects - Objects -- ************************************************ snmpTLSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over TLS transport domain. The corresponding transport address is of type SnmpTLSAddress. The securityName prefix to be associated with the snmpTLSDomain is 'tls'. This prefix may be used by security models or other components to identify which secure transport infrastructure authenticated a securityName." ::= { snmpDomains xx } -- RFC Ed.: replace xx with IANA-assigned number and -- remove this note -- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string -- if 'tls' is not assigned to this document. snmpDTLSUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over DTLS/UDP transport domain. The corresponding transport address is of type SnmpDTLSUDPAddress. When an SNMP entity uses the snmpDTLSUDPDomain transport model, it must be capable of accepting messages up to the maximum MTU size for an interface it supports, minus the needed IP, UDP, DTLS and other protocol overheads. The securityName prefix to be associated with the snmpDTLSUDPDomain is 'dudp'. This prefix may be used by security models or other components to identify which secure transport infrastructure authenticated a securityName." ::= { snmpDomains yy } -- RFC Ed.: replace yy with IANA-assigned number and -- remove this note -- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string -- if 'dtls' is not assigned to this document. snmpDTLSSCTPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over DTLS/SCTP transport domain. The corresponding transport address is of type SnmpDTLSSCTPAddress. The securityName prefix to be associated with the snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by security models or other components to identify which secure transport infrastructure authenticated a securityName." ::= { snmpDomains zz } -- RFC Ed.: replace zz with IANA-assigned number and -- remove this note -- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string -- if 'dtls' is not assigned to this document. SnmpTLSAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a TCP connection address for an IPv4 address, an IPv6 address or an US-ASCII encoded hostname and port number. An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be a colon separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. A hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention may not be directly usable as transport-layer addressing information, and may require run-time resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpTLSAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation." REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 " SYNTAX OCTET STRING (SIZE (1..255)) SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a UDP connection address for an IPv4 address, an IPv6 address or an US-ASCII encoded hostname and port number. An IPv4 address must be a dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be a colon separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. A hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention may not be directly usable as transport-layer addressing information, and may require run-time resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpDTLSUDPAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation." REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 4347: Datagram Transport Layer Security RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 " SYNTAX OCTET STRING (SIZE (1..255)) SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a SCTP connection address for an IPv4 address, an IPv6 address or an US-ASCII encoded hostname and port number. An IPv4 address must be a dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be a colon separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. A hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention may not be directly usable as transport-layer addressing information, and may require run-time resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpDTLSSCTPAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation." SYNTAX OCTET STRING (SIZE (1..255)) Fingerprint ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:254x" STATUS current DESCRIPTION "A Fingerprint value that can be used to uniquely reference other data of potentially arbitrary length. A Fingerprint value is composed of a 1-octet hashing algorithm type. The octet value encoded is taken from the IANA TLS HashAlgorithm Registry (RFC5246). The remaining octets are filled using the results of the hashing algorithm. This TEXTUAL-CONVENTION SHOULD NOT be used as a form of cryptographic verification and a data source with a matching fingerprint should not be considered authenticated because the value matches. This TEXTUAL-CONVENTION is only intended for use as a reference to a stored copy of a longer data source. The contents of full data source referenced by this fingerprint needs to be compared against to assure collisions have not resulted." REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 4347: Datagram Transport Layer Security RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 " SYNTAX OCTET STRING (SIZE (1..255)) -- Identities tlstmCertToSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 } tlstmCertSANRFC822Name OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's rfc822Name to a SNMPv3 securityName. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lower case. Example rfc822Name Field: FooBar@Example.COM is mapped to securityName: FooBar@exmaple.com" ::= { tlstmCertToSNMIdentities 1 } tlstmCertSANDNSName OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's dNSName to a SNMPv3 securityName by directly passing the value without any transformations." ::= { tlstmCertToSNMIdentities 2 } tlstmCertSANIpAddress OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's ipAddress to a SNMPv3 securityName by transforming the binary encoded address as follows: 1) for IPv4 the value is converted into a decimal dotted quad address (e.g. '192.0.2.1') 2) for IPv6 addresses the value is converted into a 32-character hexadecimal string without any colon separators. Note that the resulting length is the maximum length supported by the View-Based Access Control Model (VACM). Note that using both the Transport Security Model's support for transport prefixes (see the SNMP-TSM-MIB's snmpTsmConfigurationUsePrefix object for details) will result in securityName lengths that exceed what VACM can handle." ::= { tlstmCertToSNMIdentities 3 } tlstmCertSANAny OBJECT-IDENTITY STATUS current DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms: |------------+------------------------| | Type | Algorithm | |------------+------------------------| | rfc822Name | tlstmCertSANRFC822Name | | dNSName | tlstmCertSANDNSName | | ipAddress | tlstmCertSANIpAddress | |------------+------------------------| The first matching subjectAltName value found in the certificate any of the above types MUST be used when deriving the securityName." ::= { tlstmCertToSNMIdentities 4 } tlstmCertCommonName OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a certificate's CommonName to a SNMPv3 securityName by directly passing the value without any transformations." ::= { tlstmCertToSNMIdentities 5 } -- The tlstmSession Group tlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 } tlstmSessionOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request has been executed as an (D)TLS client, whether it succeeded or failed." ::= { tlstmSession 1 } tlstmSessionCloses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a closeSession() request has been executed as an (D)TLS client, whether it succeeded or failed." ::= { tlstmSession 2 } tlstmSessionOpenErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request failed to open a session as a (D)TLS client, for any reason." ::= { tlstmSession 3 } tlstmSessionNoAvailableSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an outgoing message was dropped because the session associated with the passed tmStateReference was no longer (or was never) available." ::= { tlstmSession 4 } tlstmSessionInvalidClientCertificates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an incoming session was not established on an (D)TLS server because the presented client certificate was invalid. Reasons for invalidation includes, but is not limited to, cryptographic validation failures and lack of a suitable mapping row in the tlstmCertToSNTable." ::= { tlstmSession 5 } tlstmSessionInvalidServerCertificates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an outgoing session was not established on an (D)TLS client because the presented server certificate was invalid. Reasons for invalidation includes, but is not limited to, cryptographic validation failures and an unexpected presented certificate identity." ::= { tlstmSession 6 } tlstmTLSProtectionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times (D)TLS processing resulted in a message being discarded because it failed its integrity test, decryption processing or other (D)TLS processing." ::= { tlstmSession 7 } -- Configuration Objects tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 2 } -- Certificate mapping tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 } tlstmCertToSNCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of entries in the tlstmCertToSNTable" ::= { tlstmCertificateMapping 1 } tlstmCertToSNTableLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime.0 when the tlstmCertToSNTable was last modified through any means, or 0 if it has not been modified since the command responder was started." ::= { tlstmCertificateMapping 2 } tlstmCertToSNTable OBJECT-TYPE SYNTAX SEQUENCE OF TlstmCertToSNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing the X.509 certificates known to the entity and the associated method for determining the SNMPv3 security name from a certificate. On an incoming (D)TLS/SNMP connection the client's presented certificate must be examined and validated based on an established trusted path from a CA certificate or self-signed public certificate (e.g. RFC5280). This table provides a mapping from a validated certificate to a SNMPv3 securityName. This table does not provide any mechanisms for uploading trusted certificates; the transfer of any needed trusted certificates for path validation is expected to occur through an out-of-band transfer. Once the authenticity of a certificate has been verified, this table is consulted to determine the appropriate securityName to identify with the remote connection. This is done by considering each active row from this table in prioritized order according to its tlstmCertToSNID value. Each row's tlstmCertToSNFingerprint value determines whether the row is a match for the incoming connection: 1) If the row's tlstmCertToSNFingerprint value identifies the presented certificate and the contents of the presented certificate match a locally cached copy of the certificate then consider the row as a successful match. 2) If the row's tlstmCertToSNFingerprint value identifies a locally held copy of a trusted CA certificate and that CA certificated was used to validate the path to the presented certificate then consider the row as a successful match. Once a matching row has been found, the tlstmCertToSNMapType value can be used to determine how the securityName to associate with the session should be determined. See the tlstmCertToSNMapType column's DESCRIPTION for details on determining the securityName value. If it is impossible to determine a securityName from the row's data combined with the data presented in the certificate then additional rows MUST be searched looking for another potential match. If a resulting securityName mapped from a given row is not compatible with the needed requirements of a securityName (e.g., VACM imposes a 32-octet-maximum length and the certificate derived securityName could be longer) then it must be considered an invalid match and additional rows MUST be searched looking for another potential match. Missing values of tlstmCertToSNID are acceptable and implementations should continue to the next highest numbered row. E.G., the table may legally contain only two rows with tlstmCertToSNID values of 10 and 20. Users are encouraged to make use of certificates with subjectAltName fields that can be used as securityNames so that a single root CA certificate can allow all child certificate's subjectAltName to map directly to a securityName via a 1:1 transformation. However, this table is flexible to allow for situations where existing deployed certificate infrastructures do not provide adequate subjectAltName values for use as SNMPv3 securityNames. Certificates may also be mapped to securityNames using the CommonName portion of the Subject field but usage of the CommonName field is deprecated. Direct mapping from each individual certificate fingerprint to a securityName is also possible but requires one entry in the table per securityName and requires more management operations to completely configure a device." ::= { tlstmCertificateMapping 3 } tlstmCertToSNEntry OBJECT-TYPE SYNTAX TlstmCertToSNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the tlstmCertToSNTable that specifies a mapping for an incoming (D)TLS certificate to a securityName to use for a connection." INDEX { tlstmCertToSNID } ::= { tlstmCertToSNTable 1 } TlstmCertToSNEntry ::= SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, tlstmCertToSNType INTEGER, tlstmCertToSNSecurityName SnmpAdminString, tlstmCertToSNMapType AutonomousType, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } tlstmCertToSNID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique, prioritized index for the given entry." ::= { tlstmCertToSNEntry 1 } tlstmCertToSNFingerprint OBJECT-TYPE SYNTAX Fingerprint MAX-ACCESS read-create STATUS current DESCRIPTION "A cryptographic hash of a X.509 certificate. The results of a successful matching fingerprint to either the trusted CA in the certificate validation path or to the certificate itself is dictated by the tlstmCertToSNMapType column." ::= { tlstmCertToSNEntry 2 } tlstmCertToSNType OBJECT-TYPE SYNTAX INTEGER { specified(1), mapped(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The mapping type used to obtain the securityName from the certificate. The possible values of use and their usage methods are defined as follows: specified(1): The securityName that should be used to associate with the session is directly specified in the tlstmCertToSNSecurityName column from this table. Note: The tlstmCertToSNSecurityName column's value is ignored for all other tlstmCertToSNMapType values. mapped(2): The securityName that should be used to associate with the session should be taken from client's X.509 certificate. The exact mechanism used to derive the securityName from the certificate is indicated by the tlstmCertToSNMapType column. If the resulting mapped value from the necessary certificate component is not compatible with the needed requirements of a securityName (e.g., VACM imposes a 32-octet-maximum length and the certificate derived securityName could be longer) then the next appropriate value should be used if one is available (e.g. it is possible for a certificate to include multiple subjectAltName values of the same type). If no appropriate value for the given type is found within the certificate then additional rows in the tlstmCertToSNTable must be searched for additional tlstmCertToSNFingerprint matches." DEFVAL { specified } ::= { tlstmCertToSNEntry 3 } tlstmCertToSNSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The securityName that the session should use if the tlstmCertToSNMapType is set to specified(1), otherwise the value in this column should be ignored. If tlstmCertToSNMapType is set to specifed(1) and this column contains a zero-length string (which is not a legal securityName value) this row is effectively disabled and the match will not be considered successful and other rows in the table will need to be searched for a proper match." DEFVAL { "" } ::= { tlstmCertToSNEntry 4 } tlstmCertToSNMapType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the subjectAltName type that may be used to extract the securityName from. Details for mapping of a particular type SHALL be specified in the DESCRIPTION clause of the OBJECT-IDENTITY that describes the mapping." DEFVAL { tlstmCertSANAny } ::= { tlstmCertToSNEntry 5 } tlstmCertToSNStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { tlstmCertToSNEntry 6 } tlstmCertToSNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmCertToSNFingerprint, tlstmCertToSNType, tlstmCertToSNSecurityName, and tlstmCertToSNMapType columns have been set. The following objects may not be modified while the value of this object is active(1): - tlstmCertToSNFingerprint - tlstmCertToSNType - tlstmCertToSNSecurityName - tlstmCertToSNMapType An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error." ::= { tlstmCertToSNEntry 7 } -- Maps securityNames to certificates for use by the SNMP-TARGET-MIB tlstmParamsCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of entries in the tlstmParamsTable" ::= { tlstmCertificateMapping 4 } tlstmParamsTableLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime.0 when the tlstmParamsTable was last modified through any means, or 0 if it has not been modified since the command responder was started." ::= { tlstmCertificateMapping 5 } tlstmParamsTable OBJECT-TYPE SYNTAX SEQUENCE OF TlstmParamsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the SNMP-TARGET-MIB's snmpTargetParamsTable with an additional (D)TLS client-side certificate fingerprint identifier to use when establishing new (D)TLS connections." ::= { tlstmCertificateMapping 6 } tlstmParamsEntry OBJECT-TYPE SYNTAX TlstmParamsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row containing a fingerprint hash of a locally held certificate for a given snmpTargetParamsEntry. The values in this row should be ignored if the connection that needs to be established, as indicated by the SNMP-TARGET-MIB infrastructure, is not a certificate and (D)TLS based connection. The connection SHOULD NOT be established if the certificate fingerprint stored in this entry does not point to a valid locally held certificate or if it points to an unusable certificate (such as might happen when the certificate's expiration date has been reached)." INDEX { IMPLIED snmpTargetParamsName } ::= { tlstmParamsTable 1 } TlstmParamsEntry ::= SEQUENCE { tlstmParamsClientFingerprint Fingerprint, tlstmParamsStorageType StorageType, tlstmParamsRowStatus RowStatus } tlstmParamsClientFingerprint OBJECT-TYPE SYNTAX Fingerprint MAX-ACCESS read-create STATUS current DESCRIPTION "A cryptographic hash of a X.509 certificate. This object should store the hash of a locally held X.509 certificate that should be used when initiating a (D)TLS connection as a (D)TLS client." ::= { tlstmParamsEntry 1 } tlstmParamsStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { tlstmParamsEntry 2 } tlstmParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmParamsClientFingerprint column has been set. The tlstmParamsClientFingerprint object may not be modified while the value of this object is active(1). An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error. If this row is deleted it has no effect on the corresponding row in the targetParamsTable. If the corresponding row in the targetParamsTable is deleted then this row must be automatically removed." ::= { tlstmParamsEntry 3 } -- Lists expected certificate fingerprints to be presented by a DTLS -- server tlstmAddrCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of entries in the tlstmAddrTable" ::= { tlstmCertificateMapping 7 } tlstmAddrTableLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime.0 when the tlstmAddrTable was last modified through any means, or 0 if it has not been modified since the command responder was started." ::= { tlstmCertificateMapping 8 } tlstmAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF TlstmAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS server-side certificate identifier to expect when establishing a new (D)TLS connections. If a matching row in this table exists and the row is active then a local copy of the certificate matching the fingerprint identifier should be compared against the certificate being presented by the server. If the certificate presented by the server does not match the locally held copy then the connection MUST NOT be established. If no matching row exists in this table then the connection SHOULD still proceed if another certificate validation path algorithm (e.g. RFC5280) can be followed to a configured trust anchor. " ::= { tlstmCertificateMapping 9 } tlstmAddrEntry OBJECT-TYPE SYNTAX TlstmAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row containing a copy of a locally held certificate's fingerprint for a given snmpTargetAddrEntry. The values in this row should be ignored if the connection that needs to be established, as indicated by the SNMP-TARGET-MIB infrastructure, is not a (D)TLS based connection. If an tlstmAddrEntry exists for a given snmpTargetAddrEntry then the presented server certificate MUST match or the connection MUST NOT be established. If a row in this table does not exist to match a snmpTargetAddrEntry row then the connection SHOULD still proceed if some other certificate validation path algorithm (e.g. RFC5280) can be followed to a configured trust anchor." INDEX { IMPLIED snmpTargetAddrName } ::= { tlstmAddrTable 1 } TlstmAddrEntry ::= SEQUENCE { tlstmAddrServerFingerprint Fingerprint, tlstmAddrStorageType StorageType, tlstmAddrRowStatus RowStatus } tlstmAddrServerFingerprint OBJECT-TYPE SYNTAX Fingerprint MAX-ACCESS read-create STATUS current DESCRIPTION "A cryptographic hash of a public X.509 certificate. This object should store the hash of a local copy of the public X.509 certificate that the remote server should present during the (D)TLS connection setup. The presented certificate and the locally held copy, referred to by this hash value, MUST match exactly or the connection MUST NOT be established." ::= { tlstmAddrEntry 1 } tlstmAddrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { tlstmAddrEntry 2 } tlstmAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmAddrRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmAddrServerFingerprint column has been set. The tlstmAddrServerFingerprint object may not be modified while the value of this object is active(1). An attempt to set these objects while the value of tlstmAddrRowStatus is active(1) will result in an inconsistentValue error. If this row is deleted it has no effect on the corresponding row in the targetAddrTable. If the corresponding row in the targetAddrTable is deleted then this row must be automatically removed." ::= { tlstmAddrEntry 3 } -- ************************************************ -- tlstmNotifications - Notifications Information -- ************************************************ tlstmServerCertNotFound NOTIFICATION-TYPE OBJECTS { tlstmSessionInvalidServerCertificates } STATUS current DESCRIPTION "Notification that the server certificate presented by a SNMP over (D)TLS server was invalid. Reasons for invalidation includes, but is not limited to, cryptographic validation failures and an unexpected presented certificate identity." ::= { tlstmNotifications 1 } tlstmServerAuthFailure NOTIFICATION-TYPE OBJECTS { tlstmAddrServerFingerprint } STATUS current DESCRIPTION "Notification that the server certificate presented by an SNMP over (D)TLS server was found, but the connection could not be established because of a cryptographic validation failure." ::= { tlstmNotifications 2 } -- ************************************************ -- tlstmCompliances - Conformance Information -- ************************************************ tlstmCompliances OBJECT IDENTIFIER ::= { tlstmConformance 1 } tlstmGroups OBJECT IDENTIFIER ::= { tlstmConformance 2 } -- ************************************************ -- Compliance statements -- ************************************************ tlstmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the TLSTM-MIB" MODULE MANDATORY-GROUPS { tlstmStatsGroup, tlstmIncomingGroup, tlstmOutgoingGroup, tlstmNotificationGroup } ::= { tlstmCompliances 1 } -- ************************************************ -- Units of conformance -- ************************************************ tlstmStatsGroup OBJECT-GROUP OBJECTS { tlstmSessionOpens, tlstmSessionCloses, tlstmSessionOpenErrors, tlstmSessionNoAvailableSessions, tlstmSessionInvalidClientCertificates, tlstmSessionInvalidServerCertificates, tlstmTLSProtectionErrors } STATUS current DESCRIPTION "A collection of objects for maintaining statistical information of an SNMP engine which implements the SNMP TLS Transport Model." ::= { tlstmGroups 1 } tlstmIncomingGroup OBJECT-GROUP OBJECTS { tlstmCertToSNCount, tlstmCertToSNTableLastChanged, tlstmCertToSNFingerprint, tlstmCertToSNType, tlstmCertToSNSecurityName, tlstmCertToSNMapType, tlstmCertToSNStorageType, tlstmCertToSNRowStatus } STATUS current DESCRIPTION "A collection of objects for maintaining incoming connection certificate mappings to securityNames of an SNMP engine which implements the SNMP TLS Transport Model." ::= { tlstmGroups 2 } tlstmOutgoingGroup OBJECT-GROUP OBJECTS { tlstmParamsCount, tlstmParamsTableLastChanged, tlstmParamsClientFingerprint, tlstmParamsStorageType, tlstmParamsRowStatus, tlstmAddrCount, tlstmAddrTableLastChanged, tlstmAddrServerFingerprint, tlstmAddrStorageType, tlstmAddrRowStatus } STATUS current DESCRIPTION "A collection of objects for maintaining outgoing connection certificates to use when opening connections as a result of SNMP-TARGET-MIB settings." ::= { tlstmGroups 3 } tlstmNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { tlstmServerCertNotFound, tlstmServerAuthFailure } STATUS current DESCRIPTION "Notifications" ::= { tlstmGroups 4 } END --=-=-=-- From jhutz@cmu.edu Wed Dec 2 17:32:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12C03A6872 for ; Wed, 2 Dec 2009 17:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2prvrxEI7zjT for ; Wed, 2 Dec 2009 17:32:56 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 0D58D3A6358 for ; Wed, 2 Dec 2009 17:32:55 -0800 (PST) Received: from ATLANTIS.WV.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nB31WfLo023447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 20:32:41 -0500 (EST) Date: Wed, 02 Dec 2009 20:32:41 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , isms@ietf.org Message-ID: In-Reply-To: <3466_1259803165_nB31JM1J029228_sdeincdfcd.fsf@wjh.hardakers.net> References: <3466_1259803165_nB31JM1J029228_sdeincdfcd.fsf@wjh.hardakers.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: jhutz@cmu.edu Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 01:32:56 -0000 --On Wednesday, December 02, 2009 05:19:14 PM -0800 Wes Hardaker wrote: > tlstmCertSANAny I'm not sure what this is supposed to do. It sounds like "pick any arbitrary SAN you see in the certificate, and turn it into a securityName". But that leaves unspecified which one to pick if there is more than one, and how to turn arbitrary otherName types into an SNMP securityName. Now, I'm fine with having a mapping type that essentially means the mapping is locally defined and not guaranteed to be interoperable. In fact, I argued for having such a thing. But I'd call it something like tlstmCertLocalMapping. > The *'d fields would then be used to do *any* type of mapping, and the > 'specified' enum would then be converted to a OBJECT-IDENTITY which > would say to directly use the data found in the now generic > tlstmCertToSNMapData column. The advantage of this would be that any > other future extensions could have a spare column of data to help > configure the OBJECT-IDENTITY's behavior. The downside is that making > it generic makes it "less straightforward". This sounds like a good idea, particularly since it provides a nice hole for future (or private) mapping types to use for configuration. You might consider ANY DEFINED BY tlstmCertToSNMapType instead of OCTET STRING; I don't know how people feel about such constructs in MIB's. -- Jeff From wjhns1@hardakers.net Wed Dec 2 18:48:32 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E661128C0EB for ; Wed, 2 Dec 2009 18:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7ajBJSf71TH for ; Wed, 2 Dec 2009 18:48:32 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D9C0A3A68B4 for ; Wed, 2 Dec 2009 18:48:31 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6768E982DD; Wed, 2 Dec 2009 18:48:23 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <3466_1259803165_nB31JM1J029228_sdeincdfcd.fsf@wjh.hardakers.net> Date: Wed, 02 Dec 2009 18:48:22 -0800 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 02 Dec 2009 20:32:41 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 02:48:33 -0000 >>>>> On Wed, 02 Dec 2009 20:32:41 -0500, Jeffrey Hutzelman said: JH> I'm not sure what this is supposed to do. It sounds like "pick any JH> arbitrary SAN you see in the certificate, and turn it into a JH> securityName". But that leaves unspecified which one to pick if there JH> is more than one, and how to turn arbitrary otherName types into an JH> SNMP securityName. You'll find if you read the definition in the MIB/patch I sent as well that it limits it to one of the other 3 existing types (rfc822, dns, ipaddress). And it says you pick the first of them. JH> Now, I'm fine with having a mapping type that essentially means the JH> mapping is locally defined and not guaranteed to be interoperable. In JH> fact, I argued for having such a thing. But I'd call it something JH> like tlstmCertLocalMapping. Everything I left is completely deterministic. Locally defined will require an OID to be defined either in standards space or enterprises space and will achieve 100% interoperability as well. We aren't supporting anything in the included MIB that says "interoperate on your own" but left it extensible so vendors or future standards can define new mappings, which I think is the right way to go. Please do read the text in the included patch/MIB for details. JH> You might consider ANY DEFINED BY tlstmCertToSNMapType instead of JH> OCTET STRING; I don't know how people feel about such constructs in JH> MIB's. You can't use them in MIBs. The best you can do in a MIB for generic is "OCTET STRING" (actually, there is OPAQUE too but that's a can of worms you don't want to get near and is in fact even deprecated if I recall). -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Wed Dec 2 18:50:03 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F91328C11F for ; Wed, 2 Dec 2009 18:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzaN7VvYFRRL for ; Wed, 2 Dec 2009 18:50:02 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id B51533A68B4 for ; Wed, 2 Dec 2009 18:50:02 -0800 (PST) Received: from ATLANTIS.WV.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nB32np0W009274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 21:49:52 -0500 (EST) Date: Wed, 02 Dec 2009 21:49:51 -0500 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: In-Reply-To: References: <3466_1259803165_nB31JM1J029228_sdeincdfcd.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.196 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 02:50:03 -0000 --On Wednesday, December 02, 2009 06:48:22 PM -0800 Wes Hardaker wrote: >>>>>> On Wed, 02 Dec 2009 20:32:41 -0500, Jeffrey Hutzelman >>>>>> said: > > JH> I'm not sure what this is supposed to do. It sounds like "pick any > JH> arbitrary SAN you see in the certificate, and turn it into a > JH> securityName". But that leaves unspecified which one to pick if there > JH> is more than one, and how to turn arbitrary otherName types into an > JH> SNMP securityName. > > You'll find if you read the definition in the MIB/patch I sent as well > that it limits it to one of the other 3 existing types (rfc822, dns, > ipaddress). And it says you pick the first of them. Nevermind. > JH> You might consider ANY DEFINED BY tlstmCertToSNMapType instead of > JH> OCTET STRING; I don't know how people feel about such constructs in > JH> MIB's. > > You can't use them in MIBs. The best you can do in a MIB for generic is > "OCTET STRING" (actually, there is OPAQUE too but that's a can of worms > you don't want to get near and is in fact even deprecated if I recall). That's fine; I'm quite familiar with the OCTET STRING approach since that's what Kerberos does. From randy_presuhn@mindspring.com Wed Dec 2 19:20:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B861B3A69B0 for ; Wed, 2 Dec 2009 19:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AasINUMEfm1 for ; Wed, 2 Dec 2009 19:20:07 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 994693A69B5 for ; Wed, 2 Dec 2009 19:20:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SkBrfqREQTTzEP90LvxPLqH/EAZSgVkiydbpT2tmbuTlqFXXJ1e5oHXN6TlUzvS6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.227.190] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NG2EY-0007pH-N0 for isms@ietf.org; Wed, 02 Dec 2009 22:19:59 -0500 Message-ID: <00c301ca73c7$b1272820$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <3466_1259803165_nB31JM1J029228_sdeincdfcd.fsf@wjh.hardakers.net> Date: Wed, 2 Dec 2009 19:21:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9a0433d7ac0931d955eb2540d41605871350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.190 Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherNamemapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 03:20:08 -0000 Hi - > From: "Wes Hardaker" > To: "Jeffrey Hutzelman" > Cc: > Sent: Wednesday, December 02, 2009 6:48 PM > Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherNamemapping resolution ... > JH> You might consider ANY DEFINED BY tlstmCertToSNMapType instead of > JH> OCTET STRING; I don't know how people feel about such constructs in > JH> MIB's. > > You can't use them in MIBs. The best you can do in a MIB for generic is > "OCTET STRING" (actually, there is OPAQUE too but that's a can of worms > you don't want to get near and is in fact even deprecated if I recall). Opaque would be the right thing, but almost nobody ever got it right, so RFC 2578 says: |7.1.9. Opaque | | The Opaque type is provided solely for backward-compatibility, and | shall not be used for newly-defined object types. You're stuck with OCTET STRING. Randy From j.schoenwaelder@jacobs-university.de Wed Dec 2 23:12:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA5E3A696F for ; Wed, 2 Dec 2009 23:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-NGLxyRMjct for ; Wed, 2 Dec 2009 23:12:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECC233A69DB for ; Wed, 2 Dec 2009 23:12:04 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8396EC000F; Thu, 3 Dec 2009 08:11:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wXBSf8jZWCtB; Thu, 3 Dec 2009 08:11:55 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CB19C000D; Thu, 3 Dec 2009 08:11:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 10367E429D6; Thu, 3 Dec 2009 08:11:53 +0100 (CET) Date: Thu, 3 Dec 2009 08:11:53 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091203071153.GA8385@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 07:12:10 -0000 On Thu, Dec 03, 2009 at 02:19:14AM +0100, Wes Hardaker wrote: > 2) Thus the second alternative is to do this instead: > > TlstmCertToSNEntry ::= SEQUENCE { > tlstmCertToSNID Unsigned32, > tlstmCertToSNFingerprint Fingerprint, > * tlstmCertToSNMapType AutonomousType, > * tlstmCertToSNMapData OCTET STRING, > tlstmCertToSNStorageType StorageType, > tlstmCertToSNRowStatus RowStatus > } > > The *'d fields would then be used to do *any* type of mapping, and the > 'specified' enum would then be converted to a OBJECT-IDENTITY which > would say to directly use the data found in the now generic > tlstmCertToSNMapData column. The advantage of this would be that any > other future extensions could have a spare column of data to help > configure the OBJECT-IDENTITY's behavior. The downside is that making > it generic makes it "less straightforward". Is this not sufficient? TlstmCertToSNEntry ::= SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, tlstmCertToSNMapType AutonomousType, tlstmCertToSNSecurityName SnmpAdminString, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } Do we have a concrete example where an OCTET STRING value is needed as input to the mapping for a cert field? We usually do not provide OCTET STRING blobs in MIB modules just because they might be useful at some time in the future. So I like the idea to do away with tlstmCertToSNType but I am not convinced yet an opaque tlstmCertToSNMapData is needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From adonati@motorola.com Thu Dec 3 08:54:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E52D3A69F1 for ; Thu, 3 Dec 2009 08:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 yQVdxjYk61N7 for ; Thu, 3 Dec 2009 08:54:39 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 6E1723A66B4 for ; Thu, 3 Dec 2009 08:54:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1259859270!10557540!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 9431 invoked from network); 3 Dec 2009 16:54:30 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-5.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Dec 2009 16:54:30 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id nB3GsT4o013407 for ; Thu, 3 Dec 2009 09:54:29 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id nB3GsTh6028851 for ; Thu, 3 Dec 2009 10:54:29 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id nB3GsToa028842 for ; Thu, 3 Dec 2009 10:54:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 11:54:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] TLSTM Issue #1: proposed text for otherName mappingresolution Thread-Index: AcpztqldLoqMphs8S4+izJk/03rb+gAgNI6g References: From: "Donati Andrew-MGIA0477" To: "Wes Hardaker" , X-CFilter-Loop: Reflected Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mappingresolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 16:54:40 -0000 Wes, WH> So, my question to the WG is: should I: WH> 1) use the approach defined in #1 above and the patch/mib below? WH> 2) use the approach described in #2 to make it "really generic"? I am leaning toward approach #2 for the reason that depending on what value is specified in tlstmCertToSNType, one other column in that table is always invalidated. To address this, we can have the table be indexed by , but having a double index can complicate the prioritized search. Using approach #2 eliminates these small complexities caused by tlstmCertToSNType. - Andy Donati=20 -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Wes Hardaker Sent: Wednesday, December 02, 2009 8:19 PM To: isms@ietf.org Subject: [Isms] TLSTM Issue #1: proposed text for otherName mappingresolution I've been plugging away at resolving the outstanding comments received during the last call round and most of them don't require a heavy amount of discussion and review. But a few I wanted to run by the WG in advance before publication to see if they meet the expectations based on those who participated in the WG discussions. The first issue presented at the WG meeting was surrounding the need to map otherName data in a securityName. The solution agreed to during the WG meeting was to use OBJECT-IDENTITY clauses for defining matching so that the system is extensible in the future when someone wishes to define an otherName mapping, for example. (But we wouldn't define an otherName mapping at all at this point). The results of implementing this are as follows: 1) The new table looks like this: TlstmCertToSNEntry ::=3D SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, tlstmCertToSNType INTEGER (specific(1), mapped(2)), tlstmCertToSNSecurityName SnmpAdminString, tlstmCertToSNMapType AutonomousType, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } And the tlstmCertToSNMapType is used to refer to external identities, of which the draft defines these five: tlstmCertSANRFC822Name tlstmCertSANDNSName tlstmCertSANIpAddress tlstmCertSANAny tlstmCertCommonName The full patch is attached below as is the full MIB so you can read all the nitty-gritty details. However, there is another potential solution that I wanted to see if anyone had opinions on: Specifically, the "specific" mapping (which directly says "use the securityName found in the tlstmCertToSNSecurityName column) could also be turned into an identity, though an extension field is still needed. 2) Thus the second alternative is to do this instead: TlstmCertToSNEntry ::=3D SEQUENCE { tlstmCertToSNID Unsigned32, tlstmCertToSNFingerprint Fingerprint, * tlstmCertToSNMapType AutonomousType, * tlstmCertToSNMapData OCTET STRING, tlstmCertToSNStorageType StorageType, tlstmCertToSNRowStatus RowStatus } The *'d fields would then be used to do *any* type of mapping, and the 'specified' enum would then be converted to a OBJECT-IDENTITY which would say to directly use the data found in the now generic tlstmCertToSNMapData column. The advantage of this would be that any other future extensions could have a spare column of data to help configure the OBJECT-IDENTITY's behavior. The downside is that making it generic makes it "less straightforward". So, my question to the WG is: should I: 1) use the approach defined in #1 above and the patch/mib below? 2) use the approach described in #2 to make it "really generic"? -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Dec 3 09:00:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2D3A6942 for ; Thu, 3 Dec 2009 09:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 twExAEDmmLD7 for ; Thu, 3 Dec 2009 09:00:40 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id C85BE3A66B4 for ; Thu, 3 Dec 2009 09:00:39 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 88C4A9817F; Thu, 3 Dec 2009 09:00:28 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20091203071153.GA8385@elstar.local> Date: Thu, 03 Dec 2009 09:00:28 -0800 In-Reply-To: <20091203071153.GA8385@elstar.local> (Juergen Schoenwaelder's message of "Thu, 3 Dec 2009 08:11:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 17:00:40 -0000 >>>>> On Thu, 3 Dec 2009 08:11:53 +0100, Juergen Schoenwaelder said: JS> Is this not sufficient? JS> TlstmCertToSNEntry ::= SEQUENCE { JS> tlstmCertToSNID Unsigned32, JS> tlstmCertToSNFingerprint Fingerprint, JS> tlstmCertToSNMapType AutonomousType, JS> tlstmCertToSNSecurityName SnmpAdminString, JS> tlstmCertToSNStorageType StorageType, JS> tlstmCertToSNRowStatus RowStatus JS> } That is sufficient for handling the directly specified securityName, yes, as all that is needed is a SnmpAdminString. The above, though, limits the extra field for use only using the directly specified securityName. My real question was: can we envision other cases where other MapTypes may want a configuration field. EG, you could imagine (I suppose) a kerberos otherName field that would want a configuration option saying "but only those kerberos principals in the realm '@example.com'". JS> Do we have a concrete example where an OCTET STRING value is needed as JS> input to the mapping for a cert field? Only hypothetical ones like the above. JS> So I like the idea to do away with tlstmCertToSNType but I am not JS> convinced yet an opaque tlstmCertToSNMapData is needed. Thanks for the input. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Dec 3 09:58:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782A33A6856 for ; Thu, 3 Dec 2009 09:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c58ATHAJ6-3J for ; Thu, 3 Dec 2009 09:58:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 44C173A67FA for ; Thu, 3 Dec 2009 09:58:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65796C0038; Thu, 3 Dec 2009 18:57:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f+ZqHhkY+D5O; Thu, 3 Dec 2009 18:57:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D64C6C000D; Thu, 3 Dec 2009 18:57:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F022E44549; Thu, 3 Dec 2009 18:57:45 +0100 (CET) Date: Thu, 3 Dec 2009 18:57:45 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091203175745.GA10744@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20091203071153.GA8385@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:58:02 -0000 On Thu, Dec 03, 2009 at 06:00:28PM +0100, Wes Hardaker wrote: > >>>>> On Thu, 3 Dec 2009 08:11:53 +0100, Juergen Schoenwaelder said: > > JS> Is this not sufficient? > > JS> TlstmCertToSNEntry ::= SEQUENCE { > JS> tlstmCertToSNID Unsigned32, > JS> tlstmCertToSNFingerprint Fingerprint, > JS> tlstmCertToSNMapType AutonomousType, > JS> tlstmCertToSNSecurityName SnmpAdminString, > JS> tlstmCertToSNStorageType StorageType, > JS> tlstmCertToSNRowStatus RowStatus > JS> } > > That is sufficient for handling the directly specified securityName, > yes, as all that is needed is a SnmpAdminString. The above, though, > limits the extra field for use only using the directly specified > securityName. My real question was: can we envision other cases where > other MapTypes may want a configuration field. EG, you could imagine (I > suppose) a kerberos otherName field that would want a configuration > option saying "but only those kerberos principals in the realm > '@example.com'". Let me see whether I understand things correctly. As long as I ignore fingerprints matching trusted CA certificates, I have one row per client certificate. If this is correct, it does not reall matter whether I provision information to a magic mapping function or simply write down the securityName. If I am correct, that the only interesting situation is when the fingerprint refers to trusted CA certificates since then I might accept a number of N certificates. What you are saying that for this case we should provision an opaque OCTET STRING that can be used for filtering purposes in case we ever define cert type specific mappings. The alternative would be to simply augment that table with cert type specific filters once we define mappings that need filters. For me, this all still sounds a bit hypothetic - but then I am not working in an environment where certificates are heavily used. It would help if those who are intensively work in such environments can comment on this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jhutz@cmu.edu Thu Dec 3 12:22:14 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CEC28C1AD for ; Thu, 3 Dec 2009 12:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 sVIKuYj9cw9s for ; Thu, 3 Dec 2009 12:22:13 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 8ACB828C1AE for ; Thu, 3 Dec 2009 12:22:13 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nB3KLlBn019800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 15:21:48 -0500 (EST) Date: Thu, 03 Dec 2009 15:21:47 -0500 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , Wes Hardaker Message-ID: In-Reply-To: <20915_1259863077_nB3HvueE016669_20091203175745.GA10744@elstar.local> References: <20091203071153.GA8385@elstar.local> <20915_1259863077_nB3HvueE016669_20091203175745.GA10744@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 20:22:14 -0000 --On Thursday, December 03, 2009 06:57:45 PM +0100 Juergen Schoenwaelder wrote: > Let me see whether I understand things correctly. As long as I ignore > fingerprints matching trusted CA certificates, I have one row per > client certificate. That's my understanding as well. > What you are saying that for this case we should provision an opaque > OCTET STRING that can be used for filtering purposes in case we ever > define cert type specific mappings. The alternative would be to simply > augment that table with cert type specific filters once we define > mappings that need filters. It's not the same. "We" aren't necessarily defining new mappings; anyone can do so. After all, they're named by OID's. Wes provided a hypothetical but realistic example; I might want to turn a KRB5PrincipalName SAN into an ASN.1 security name; that would require at least specifying what realm I'm interested in, and possibly other things. Actually, that same argument can be made for RFC822 names, where one might want to handle only names with a particular domain-part. Unfortunately, algorithmic mapping of data in client certificates to useful application-specific identifiers does not seem to be an area that has been explored very widely. Of course, it's easy for every site to say "we're doing it this way", but that doesn't really help with standardization. From wjhns1@hardakers.net Thu Dec 3 12:42:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2E93A695C for ; Thu, 3 Dec 2009 12:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rszz1rNqUDuq for ; Thu, 3 Dec 2009 12:42:15 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 1920028C1B1 for ; Thu, 3 Dec 2009 12:42:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 530C598221; Thu, 3 Dec 2009 12:41:31 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20091203071153.GA8385@elstar.local> <20091203175745.GA10744@elstar.local> Date: Thu, 03 Dec 2009 12:41:31 -0800 In-Reply-To: <20091203175745.GA10744@elstar.local> (Juergen Schoenwaelder's message of "Thu, 3 Dec 2009 18:57:45 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 03 Dec 2009 20:42:15 -0000 >>>>> On Thu, 3 Dec 2009 18:57:45 +0100, Juergen Schoenwaelder said: JS> } >> >> That is sufficient for handling the directly specified securityName, >> yes, as all that is needed is a SnmpAdminString. The above, though, >> limits the extra field for use only using the directly specified >> securityName. My real question was: can we envision other cases where >> other MapTypes may want a configuration field. EG, you could imagine (I >> suppose) a kerberos otherName field that would want a configuration >> option saying "but only those kerberos principals in the realm >> '@example.com'". JS> Let me see whether I understand things correctly. As long as I ignore JS> fingerprints matching trusted CA certificates, I have one row per JS> client certificate. If this is correct, it does not reall matter JS> whether I provision information to a magic mapping function or simply JS> write down the securityName. If I am correct, that the only JS> interesting situation is when the fingerprint refers to trusted CA JS> certificates since then I might accept a number of N certificates. JS> What you are saying that for this case we should provision an opaque JS> OCTET STRING that can be used for filtering purposes in case we ever JS> define cert type specific mappings. The alternative would be to simply JS> augment that table with cert type specific filters once we define JS> mappings that need filters. You're correct. I think. The interesting cases are (I'm using DATA here as the column for the yet-to-be-decided column; IE, it'll either be a generic OCTET STRING or will be the securityName SnmpAdminString like you're wishing for): 1) fingerprint directly matches a presented server certificate and we want to directly map it to a securityName: tlstmCertToSNFingerprint = the server's fingerprint tlstmCertToSNMapType = OID for 'specified' tlstmCertToDATA = 'wes' 2) fingerprint matches a CA certificate used to verify the presented server certificate and we want to pull data from the subjectAltName: tlstmCertToSNFingerprint = the CA fingerprint tlstmCertToSNMapType = OID for 'specified' tlstmCertToDATA = '' (empty and not used and any value ignored) 3) fingerprint matches a CA certificate used to verify the presented server certificate and we want to pull data from an as-yet-undocumented identifier like a kerberos otherName principal. It may be defined such that "if tlstmCertToDATA contains a non-zero length string then it should be used as a must-match against the kerberos realm name" tlstmCertToSNFingerprint = the CA fingerprint tlstmCertToSNMapType = OID for 'specified' tlstmCertToDATA = 'example.com' So only kerberos principals ending in @example.com would be accepted as valid securityNames to use. I don't know if we want to support #3 or not, which was most of my questioning. Jeff indicated he'd like this extensibility. Donati seemed to indicate he favored it as well. -- Wes Hardaker Cobham Analytic Solutions From jsalowey@cisco.com Sun Dec 6 23:19:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F29228C118 for ; Sun, 6 Dec 2009 23:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 TCNCgahvUsTL for ; Sun, 6 Dec 2009 23:19:05 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5A2323A6863 for ; Sun, 6 Dec 2009 23:19:04 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPg6HEurR7H+/2dsb2JhbADAS5V8hDME X-IronPort-AV: E=Sophos;i="4.47,353,1257120000"; d="scan'208";a="277721190" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2009 07:18:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB77Islf003309 for ; Mon, 7 Dec 2009 07:18:54 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 23:18:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Dec 2009 23:18:53 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-isms-dtls-tm-01.txt Thread-Index: Acp3DYf0ia/kZ4j6QUieiX8K8CPONA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 07 Dec 2009 07:18:54.0618 (UTC) FILETIME=[88C20FA0:01CA770D] Subject: [Isms] Review of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:19:17 -0000 I've had a chance to take a look at draft-ietf-isms-dtls-tm-01. In general I think the document is clear and well done. I have a few comments below, I haven't gotten all the way through the MIB definition or the appendices yet. =20 1) Section 2.1. =20 I find it hard to reconcile a SHOULD for authentication of both client and server. Why not a MUST?. The next bullet seems to be a MUST for client authentication. Without server authentication there can be serious problems such as man-in-the-middle. I'm concerned that it is not required here. =20 2) Section 3.1.3 The document is slightly ambiguous as to the (D)TLS to transport mapping. DTLS can be run over UDP, TCP and SCTP and TLS can be run over TCP or SCTP. I think the document should be more clear that DTLS is used for SCTP and UDP and TLS is used for TCP. This is clear in the IANA considerations, but it would be better if it were spelled out earlier in the document. =20 3) Section 3.3 and 4.1.1 These sections describe the mechanisms to map client certificates to security names and provisioning mechanism for this. After reading these sections I was left wondering about the server side. Section 5, does cover most of this in detail, but it seems some mention of this is appropriate earlier on in the document. =20 4) Section 5.3, 2b It seems that referencing I-D.saintandre-tls-server-id-check should be enough, why do you need the last sentence about Common Name and subjectAltNAme? 5) Section 5.3 last paragraph TLS does define a Server Name Indication extension for identifying the server you connect to (http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt). Right now the only type of name defined is host name, which may not be very useful for this case. New name types could be developed if it would solve a real problem. =20 6) Section 9.1 TLS also supports extensions to communicate OCSP in the case the client does not have access to an OCSP server. I'm not sure if OCSP would be operationally useful for SNMP. =20 7) Section 10 Do you really need low number ports? Unless we really need them it might be best to just ask for reserved ports. =20 Cheers, Joe From root@core3.amsl.com Tue Dec 8 15:00:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 65D3F3A6966; Tue, 8 Dec 2009 15:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091208230001.65D3F3A6966@core3.amsl.com> Date: Tue, 8 Dec 2009 15:00:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-02.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-02.txt Pages : 63 Date : 2009-12-08 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/SCTP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-08145146.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Tue Dec 8 15:27:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05023A6949 for ; Tue, 8 Dec 2009 15:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILcfnfwnPwfW for ; Tue, 8 Dec 2009 15:27:37 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 2FF543A68E4 for ; Tue, 8 Dec 2009 15:27:36 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3B28A981BC for ; Tue, 8 Dec 2009 15:27:21 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 08 Dec 2009 15:27:21 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] Updated TLSTM document posted X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 08 Dec 2009 23:27:38 -0000 I've updated the TLSTM document to address all the outstanding WG issues and comments received to date (roughly 130 comment items were received, though some were duplicates). The current version (-02) can be found here: http://tools.ietf.org/id/draft-ietf-isms-dtls-tm-02.txt (It's currently still redirecting to -01, but I'm sure that will be fixed once the publication finishes propagating) Diffs since last time can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-dtls-tm-02.txt I'll be sending out responses to each person that submitted comments shortly. Thanks to everyone who did send in comments as they were all very helpful. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Dec 8 16:10:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11193A6915 for ; Tue, 8 Dec 2009 16:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 x7Qhb7xz9-zL for ; Tue, 8 Dec 2009 16:10:20 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 629EA3A6803 for ; Tue, 8 Dec 2009 16:10:20 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B17ED981BE; Tue, 8 Dec 2009 16:10:08 -0800 (PST) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: <20091029111229.GA20307@elstar.local> Date: Tue, 08 Dec 2009 16:10:08 -0800 In-Reply-To: (Donati Andrew-MGIA's message of "Sun, 1 Nov 2009 09:57:49 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:10:21 -0000 >>>>> On Sun, 1 Nov 2009 09:57:49 -0500, "Donati Andrew-MGIA0477" said: DA> I read the (d)tls transport model document and here is the full DA> summary of my comments: (The first 3 items were posted to the list DA> previously) Thanks for the comments and suggestions. 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 * DONE tlstmServerAuthFailure notification. Will it be helpful for network administrators to know the current count of how many times the presented server certificate is invalid in each tlstmServerAuthFailure notification? If so, it may be useful to have tlstmSessionInvalidServerCertificates as an additional binding, especially if this object is the trigger. + WH: After WG discussion I did add these requested objects. They've also been restructured a touch since the last time you read them to make them more clear (due to other comments). * DONE Standard authentication failure notification. There may have been some previous discussions about possibly using the standard authenticationFailure trap for tlstm (client) authentication failures. Will this be used or mentioned in the document? + WH: I added a entry in the EoP to discuss when this should be sent during the establishing a session rules. * DONE tlstmServerCertNotFound Will it be feasible to have a scalar object that serves as a counter for this event? If implemented, it can be added to this notification. + WH: The two notifications, as discussed above, were cleaned up and a counter was added. Please see if the new text meets your needs. * DONE Section 6.4 Configuration Tables There is double verb, (is are), in the 2nd sentence. + WH: fixed, thanks! * DONE Section 6.4.1 Notifications This section mentions a notification (tlstmServerAuthFailure) that alerts management stations when the server's presented certificate does not meet the expected value but does not appear to have a statement that directly refers to the tlstmServerCertNotFound notification. + WH: Good point; I changed the text to this: The TLSTM-MIB defines notifications to alert management stations when a (D)TLS connection fails because a server's presented certificate did not meet an expected value (tlstmServerCertNotFound) or because cryptographic validation failed (tlstmServerAuthFailure). -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Dec 8 16:19:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAAD28B23E for ; Tue, 8 Dec 2009 16:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCr9D5JEK2mw for ; Tue, 8 Dec 2009 16:19:20 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A36EC3A68E4 for ; Tue, 8 Dec 2009 16:19:15 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A3C7D981FC; Tue, 8 Dec 2009 16:19:04 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <20091029111229.GA20307@elstar.local> <808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 08 Dec 2009 16:19:04 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 6 Nov 2009 12:15:14 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:19:24 -0000 >>>>> On Fri, 6 Nov 2009 12:15:14 +0100, said: PE> Some random comments scribbled on printout during my flight earlier PE> today (or yesterday, depending on your point of view :-): Pasi, Thanks for the comments and suggestions. 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 * DONE Technical + DONE How the notification originator authenticates the other end (TLS server) when fingerprints are not used is very unclear (the fingerprint case is clear). Section 5.3, step 3b, suggests we could use path validation, but it doesn't e.g. say what the "reference identity" (in draft-saintandre-tls-server-id-check terminology) would be. Perhaps the MIB should allow specifying that reference identity. (MIB, tlstmAddrTable, is relevant here.) + WH: This was discussed in a past WG meeting and it was determined that it was out of scope to establish X.509 path validation management. So that's left up to possible future work, possibly within the PKIX or other working group that wants to take on creating an X.509 TA MIB. I will state this fact more clearly and make sure it's declared as implementation dependent. + WH: I've reworded the section to make it much clearer about exactly what must be done. See if the new wording fixes your issues. + DONE (I guess this applies to command generators, too, to some degree at least -- they also act as TLS clients, and have to authenticate the server somehow.) + WH: correct... They're in the same boat. If there is no fingerprint for outgoing connections it's expected they do path validation through another out-of-scope process. + DONE While TLS supports several different authentication mechanism (X.509 certs, OpenPGP certs, pre-shared keys, Kerberos, SRP, ...), TLSTM supports only one of them (X.509 certs). This should be mentioned in e.g. Section 1 and Section 4.1. + WH: I've added sentences to both those locations stating that other authentication forms are outside the scope of this specification. + DONE Section 1.1, 2nd to last paragraph, and Section 3.1.3: These parts should probably explicitly say that the concept of "session" here is totally unrelated to TLS sessions in RFC 5246 (which are TLS-internal optimization detail not visible to TLSTM). But the name "tlsSessionID" is very poorly chosen, since it's very different from the TLS SessionID in RFC 5246. + WH: How does tlsSnmpSessionID sound? I've changed it to this. + WH: Note that I think it's possible to use the same sessionID for both uses. It gets a bit more trick after renegotiation though since the SNMP session ID can't change. I've added text describing this potential conflict. + DONE Section 5.3 (last para) and Section 8.2: (D)TLS does have the "server_name" extension that does allow doing this. + WH: Added a reference to RFC4366. + DONE MIB, Snmp*Address TCs: do we need four pages worth of new TCs to just describe (IPv4 address/IPv6 address/hostname)+port? Surely many existing MIBs use address+port, too, and we could import from somewhere? + WH: per discussion at IETF, I've changed this so it's a single address TC now and the 3 Domains all use it. + DONE MIB, Fingerprint TC, last paragraph: this is not really consistent with how certificate fingerprints are used in many other protocols -- usually we compare just the fingerprint (not the whole certificate), and assume it's produced by a good hash function. + WH: Per IETF discussion I've made it so that fingerprints can be used as the method of comparison. (Originally the text was actually written to allow for "cheap" referencing methods (beyond just hash fingerprints)). + DONE MIB, tlstmCertToSNSANType: is SecurityName case sensitive? If it is, you need to specify the case for IPv6 address, and probably normalize the dNSName and domain part of rfc822name (e.g., convert to lower case). + WH: Modified per discussion results during the IETF meeting. + DONE MIB, tlstmCertToSNSANType: how would othername be converted to SnmpAdminString? (which is UTF-8, so "take the raw DER" does not work, and it would be very administator-unfriendly, too) + WH: As per discussion from the IETF, we're no longer directly defining otherName mappings but do have an extensible OID selection mechanism so future documents can define an otherName mapping. + DONE Sections 3.3 and others: the document has snmpTLSDomain, snmpDTLSUDPDomain and snmpDTLSSCTPDomain. Probably for consistency, the first should be snmpTLSTCPDomain, since SCTP would also normally use TLS, not DTLS (there's a draft proposing how to run DTLS over SCTP, but it's just work in progress, not something that can be done today). + WH: Ok, I've changed it. + DONE Section 2.1: if the CG/NO is always the (D)TLS client, and it MUST be authenticated (2nd bullet), then why is authenticating the client only SHOULD? (1st bullet) + WH: Because I changed one from a SHOULD to a MUST and missed the second. Thanks for the catch. I also cleaned up the wording a bit more to make it clearer. + DONE The openSession ASI in Section 4.4.1 looks very different from the SSHTM ASI -- is this intentional? + WH: The SSH document changed from the point where that text was copied and I didn't catch it. I've realigned the document to the published RFC. + DONE Section 4.4.1: "this restriction is not needed for TLS or DTLS over SCTP": this restriction is present in TLS-over-TCP/SCTP, too, but TCP/SCTP take care of ensuring that is unique. + WH: That section was actually dropped as it was TLS specific ASIs and is no longer included with the document. + DONE Section 4.4.2 and 4.4.3: I think these sections should be just deleted -- these are TLS internal details. Furthermore, for normal TLS (or DTLS, when a single datagram contains multiple DTLS records), TLSTM cannot even determine "wholeTlsMsgLength", since that would require parsing the TLS messages (which would be a layering violation). + WH: I agree and per discussion during the WG meeting, I've removed them. + DONE Section 5.1.1 is also a bit questionable; it also seems to suggest parsing DTLS records by TLSTM. And the details aren't quite right: the same demultiplexing (mapping incoming UDP packet, based on tuple, to the right DTLS connection/context) has to happen for DTLS handshake messages, too, not just DTLS application data messages. + WH: Per discussion at the IETF I've simplified it quite a bit so it still discusses demultiplexing within UDP but doesn't talk about (D)TLS specific packet types. See if the new text looks better to you. + DONE Section 8.1, 1st paragraph: the last sentence of this paragraph is very confusing, since the sessions this document talks about are totally unrelated to TLS sessions (and TLS session resumption). Besides, all TLS implementations support session resumption, so this SHOULD is not really needed in this document. + WH: I've dropped the sentence + DONE Section 8.1, 2nd paragraph: Separate ports might be a reasonable idea, but I don't understand what the rest of the paragraph is saying... + WH: It's discussing SNMP specific message types. But I agree it's not needed. Not only that, we're asking for separate ports from IANA anyway. So... I've deleted the whole paragraph as I don't think any of it is necessary. + DONE Section 10: SSHTM uses ports >1023 -- should be good enough for TLSTM, too (the criteria for allocating ports <1023 is much stricter). + WH: I don't mind something higher and at the WG meeting everyone agreed. Changed. + DONE In normal SNMP-over-UDP, if e.g. the notification receiver restarts, that's not a problem: at least if the notification generator didn't send anything exactly when the restart was ongoing, everything will continue just fine after the restart. But when using DTLS-over-UDP, if the notification receiver restarts, the notification generator has to know that it needs to start a new DTLS "connection" (because otherwise the receiver will just silently drop all the packets it gets). The same problem has been discussed for syslog-over-DTLS recently, and draft-seggelmann-tls-dtls-heartbeat proposes one possible solution. In SNMP most requests result in a response, so if no response is seen, *some* component will know there's something wrong. But since TLSTM isn't supposed to know about PDU types, it might be architecturally slightly tricky how opening a new DTLS "connection" should be triggered here. But the document should probably say something about this issue. + WH: Per discussion in the WG meeting text was added to reference the heartbeat work and to recommend that users implement a dead-peer detection mechanism. + DONE Should the document say something about MTU/avoiding fragmentation for DTLS-over-UDP? + WH: I added a paragraph in the operational considerations section that functionally says we can't summarize all those problems but readers should be aware of them. I think if we dove down into it in depth it would amount to pages of discussions about the ramifications of each selection choice. + DONE DTLS allows multiple DTLS records in a single datagram -- should the document say something about this? + WH: I've added some text describing this during the incoming processing EOPs. + DONE Should the document say something about SCTP Partial Reliability, or use of SCTP streams? + WH: I think this falls into the text already added for "understand what's beneath you" in the operational considerations. * DONE Minor editorial comments: + DONE The document title should have the acronym "TLS" in it. + WH: Added + DONE Section 4.1.1: While the actual details of how self-signed certificates can be used in TLSTM (in the rest of the spec) look mostly OK, I would recommend against using the term "trust anchor" to refer to self-signed end-entity certificates. + WH: You're right it's another over-used term and is confusing depending on your definition of it (some use it as the keying material, but 5280 seems to declare it the entity producing the keying material)... How does this sound: "Trusted public keys from either CA certificates and/or self-signed certificates, must be installed through a trusted out of band mechanism into the server and its authenticity MUST be verified before access is granted." + DONE Section 3.1.1, item 4, 2nd paragraph: this is quite unclear, and goes into details that are IMHO not relevant for TLSTM. Perhaps something like "Most TLS cipher suites do encryption" ? + I removed the offending text and shortened it so that it really says "(D)TLS" supports encryption. + DONE Section 3.1.1, item 5,: the sentence about "amplification" is quite unclear; the main purpose of DTLS cookie exchange is to limit server-side resource consumption, not amplification (and "detecting" amplification could be tricky). + WH: You're absolutely right about this. I'm surprised no one (myself included) has caught this before. Thanks for pointing it out. I've changed it to: "Implementations are not required to perform the stateless cookie exchange for every DTLS handshake, but in environments where an overload on server side resources is detectable it is RECOMMENDED that the cookie exchange is utilized." + DONE Section 3.1.2: This text should probably mention that TLS does not have any NULL integrity cipher suites. + WH: I tried to clean this up a bit, but I'm not sure it should be our job to describe what TLS has and what it doesn't. (There is nothing prohibiting one from being created in the future, EG.) + DONE MIB, tlstmParamsEntry: should "usable" be "unusable"? + WH: Yep; Juergen caught this too. + WONTDO Section 9, "DTLS is more vulnerable to denial of service attacks". Well, a hypothetical version of DTLS that didn't include the cookie exchange might be more vulnerable, but since we don't have such a version, this isn't really true. + WH: I think the text following that statement functionally says just this so I don't think any changes are needed. The paragraph is really there to remind users that they need to use cookies. + DONE Global: s/US-US-ASCII/US-ASCII/; + WH: Whoops; that was a search-and-replace gone awry + DONE The reference [x509] looks wrong. + WH: I think that was originally a reference to RSA which I removed long ago. I've changed it to reference the ITU doc. + WONTDO Appendix A and B: I would suggest deleting these. + WH: The WG decided that these contained useful information but should move to an appendix. + DONE Appendix C: "blueberry" is not a valid rfc822Name ("blueberry@example.com" would be) + WH: changed -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Dec 8 16:24:11 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDEA3A6803 for ; Tue, 8 Dec 2009 16:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 JoD7SoMkZSd9 for ; Tue, 8 Dec 2009 16:24:09 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 2C0B03A68E4 for ; Tue, 8 Dec 2009 16:24:05 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3CEB2981FE; Tue, 8 Dec 2009 16:23:54 -0800 (PST) From: Wes Hardaker To: Alan Luchuk Organization: Sparta References: <200911202038.PAA05533@adminfs.snmp.com> Date: Tue, 08 Dec 2009 16:23:53 -0800 In-Reply-To: <200911202038.PAA05533@adminfs.snmp.com> (Alan Luchuk's message of "Fri, 20 Nov 2009 15:38:37 -0500 (EST)") 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] IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:24:11 -0000 AL> I have reviewed draft-ietf-isms-dtls-tm-01.txt; my comments are included AL> below. My apology for my late review of this document. ... AL> My company has not implemented SNMP over (D)TLS, but we are interested in AL> doing so. We have customer demand for SNMP over (D)TLS. Thanks for the comments and suggestions. 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 I'm certainly happy to hear you have customer demand for the solution! * DONE Section 1: Page 6, only sentence: (wording) Suggest changing "equally as legitimate." to "equally valid." + WH: Changed, thanks! * DONE Section 2.1 Page 8, first bulleted item: (clarification) The text reads: The TLS Transport Model SHOULD always use authentication of both the server and the client. An explanation of why this is true would be helpful for implementors who do not understand security as thoroughly as those on the ISMS WG. + WH: This text has changed to be more clear. I think you'll find it better. * WONTDO Section 2.1 Page 8: (formatting/typo) There is a straggling item number 3 that appears to be the heading "How the TLSTM fits into the Transport Subsystem". Suggest fixing this. + WH: I don't think it's straggling. That's actually the section 3 header. If you still think something is wrong, please let me know. * WONTDO Section 2.1 Page 9: (formatting) If possible, fixing the page breaks so that the diagram appears on a single page. This applies to other diagrams as well. + WH: unfortunately, I don't think this is easily possible via xml2rfc. * DONE Section 3.1.1 Page 10, item number 1: (wording) The text reads: 1. Modification of Information - The modification threat is the danger that some unauthorized entity may alter in-transit SNMP ^^^^ Suggest change: 1. Modification of Information - The modification threat is the danger that an unauthorized entity may alter in-transit SNMP ^^ + WH: Done and thanks! * DONE Section 3.1.1 Page 12, item number 5, second to last paragraph: (typo) The text reads: Implementations are not required to perform the stateless cookie exchange for every DTLS handshakes but in environments where ^ Suggest removing the "s" from "handshakes". + WH: Thanks; caught previously so already fixed. * DONE Section 4.1.1 Page 15, second bulleted text, fourth paragraph: (typo) The text reads: o Identifies a certificate issuer's fingerprint and allows a child certificate's subjectAltName or CommonName to be mapped to the tmSecurityNome." ^ Suggest changing "tmSecurityNome." to "tmSecurityName." + WH: Thanks; caught previously so already fixed. * DONE Section 4.3.1 Page 17, first paragraph, last sentence: (wording) The text reads: This document specifies three TLS and DTLS based Transport Domains for use: the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain. Suggested text change: This document specifies the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. There are a few other places in the document where this suggested change could be made. + WH: I like you're wording better too; thanks. * WONTDO Section 4.3.1 Page 17, second paragraph: (wording) The text reads: destTransportAddress: The transport address of the destination TLS Transport Model in a format specified by the SnmpTLSAddress, the SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTIONs. Question: Does the format into the API really matter? Would omitting the format clause be better, or suggesting the intended format? + WH: The ASIs are really oddly on the standardization line of what should and shouldn't be defined. I think, however, leaving the format documented as-is is more beneficial than harmful. * WONTDO Section 4.3.2 Page 17: (content error) The text reads: statusInformation = receiveMessage( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN incomingMessage -- the message received IN incomingMessageLength -- its length IN tmStateReference -- reference to transport state ) I _think_ the ASI arguments all specify items that are returned to the ASI caller, so I _think_ it should be: statusInformation = receiveMessage( OUT transportDomain -- origin transport domain OUT transportAddress -- origin transport address OUT incomingMessage -- the message received OUT incomingMessageLength -- its length OUT tmStateReference -- reference to transport state ) Now, in a programming language, one would pass pointers into an API, which would then be populated by the API, then returned to the caller. Thus, if receiveMessage() specified an _API_ (not an _ASI_), then the original _might_ be correct. But the original obscures the fact that the informa- tion items specified by the arguments are _returned_ by the ASI. Thus, the original seems to obscure the information flow. I note that this diagram comes from RFC 5590, section 6.3, on page 25, which I _think_ is incorrect also. Am I missing something here? + WH: I think it could be argued either way! If you consider the ASI from the perspective of the module implementing it (the dispatcher) then you'll find that the stuff is being passed *into* the dispatcher and hence the reasons for the INs. It's also worth noting that the same receiveMessage ASI in 5592 (the SSH TM) is also listed with INs. In order to be consistent, I'm not going to change it. But I agree it can be confusing. * WONTDO Section 4.3.2 Page 18, first paragraph: (wording) The text reads: transportAddress: The transport address of the source of the received message in a format specified by the SnmpTLSAddress, the SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION. Question: Does the format into the API really matter? Would omitting the format clause be better, or suggesting the intended format? + WH: The ASIs are really oddly on the standardization line of what should and shouldn't be defined. I think, however, leaving the format documented as-is is more beneficial than harmful. * DONE Section 4.4 Page 18, first paragraph: (typo/content error) The text reads: This section describes the services provided by the (D)TLS Transport Model with their inputs and outputs." ^^^ Suggested change: This section describes the services provided by the TLS Transport Model with their inputs and outputs. + WH: good catch, thanks! * WONTDO Section 4.4 Page 18, first paragraph: (clarification) The text reads: The following sections describe services for establishing and closing a session and for passing messages between the (D)TLS transport Suggested change: The following sections describe services for establishing and closing a (D)TLS session and for passing messages between the (D)TLS transport ^^^^^^ + WH: After working group discussion this section was entirely removed. * WONTDO Section 4.4.1 Page 19, sixth paragraph: (clarification/wording) The text reads: Neither DTLS or UDP provides a session de-multiplexing mechanism and it is possible that implementations will only be able to identify a unique session based on a unique combination of source address, destination address, source UDP port number and destination UDP port number. Because of this, when establishing a new sessions implementations MUST use a different UDP source port number for each connection to a given remote destination IP-address/port-number combination to ensure the remote entity can properly disambiguate between multiple sessions from a host to the same port on a server. TLS and DTLS over SCTP provide session de-multiplexing so this restriction is not needed for TLS or DTLS over SCTP implementations. Suggested changes: Neither DTLS or UDP provides a session de-multiplexing mechanism and it is possible that implementations will only be able to identify a unique DTLS session based on a unique combination of source address, ^^^^ destination address, source UDP port number and destination UDP port number. Because of this, when establishing a new sessions with different security parameters, ^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementations MUST use a different UDP source port number for each connection to a given remote destination IP-address/port-number combination to ensure the remote entity can properly differentiate ^^^^^^^^^^^^^ between multiple sessions from a host to the same port on a server. TLS and DTLS over SCTP provide session de-multiplexing so this restriction is not needed for TLS or DTLS over SCTP implementations. I _think_ "disambiguate" is jargon, not a real word. + WH: After working group discussion this section was entirely removed. * WONTDO Section 4.4.1 Page 19, last paragraph, second line: (typo) Add a comma after the clause "if the process was successful". + WH: After working group discussion this section was entirely removed. * WONTDO Section 4.4.2 Page 19, first paragraph: (clarification) The text reads: When the TLS Transport Model invokes the (D)TLS record layer to verify proper security for the incoming message, it must use the following ASI: Suggested change: The TLS Transport Model invokes the tlsRead ASI to verify proper security for the incoming message: + WH: After working group discussion this section was entirely removed. * 4.4.2 Page 20, third paragraph: (attaboy) Thanks for the implementation hint in the paragraph about the "tlsSessionID"! + WH: After working group discussion this section was entirely removed. However, I think we've provided the same hint elsewhere anyway. Glad you found the removed section useful though! Hmm... * DONE Section 5.1.1 Page 22, second paragraph: (typo) Add a hyphen between "implementation dependent" in the fourth line. + WH: Done * DONE Section 5.1.1 Page 22, second paragraph: (wording) The text reads: accomplish this, although any implementation dependent method should be suitable as long as the results are consistently deterministic. Suggested change: accomplish this, although any implementation dependent method should be suitable as long as the results are consistent. The phrase "consistently deterministic" is redundant. + WH: Yep; changed. * WONTDO Section 5.1.1 Page 23, item 5: (typo) Change "tlsWholeMsg" to "wholeTlsMsg". + WH: This section was actually reworded entirely after dropping the TLS specific ASIs and to remove some of the TLS protocol specific components (due to WG discussion). I hope you'll find the new wording better. * DONE Section 5.1.2 Page 23, heading: (clarification) The text reads: 5.1.2. Transport Processing for Incoming Messages Should it read: 5.1.2. Transport Processing for Incoming SNMP Messages There are a few other places in the text of this section where adding a clue about whether the message is SNMP might clarify the text. + WH: Thanks; that's a good idea. * DONE Section 5.1.2 Page 24, third paragraph: (wording) The text reads: tmTransportAddress = The address the message originated from, determined in an implementation dependent way. Suggested change: tmTransportAddress = The address the message originated from. Does the phrase "determined in an implementation dependent way" matter? + WH: Good point; changed. * DONE Section 5.2 Page 25, heading: (clarification) The text reads: 5.2. Procedures for an Outgoing Message Should it read: 5.2. Procedures for an Outgoing SNMP Message There are a few other places in the text of this section where adding a clue about the message is SNMP might clarify the text. + WH: Good point; changed. * DONE Section 5.2 Page 25, bulleted item 4b: (typo) The text reads: same cache entry. If an error is returned from OpenSession(), then discard the message, increment the ^ Suggested change: same cache entry. If an error is returned from openSession(), then discard the message, increment the ^ I _think_ this refers to the "openSession() ASI. + WH: Yep, thanks. * DONE Section 5.3 Page 27, bulleted item 3: (wording) The text reads: 3) Once a (D)TLS secured session is established and both sides have performed any appropriate certificate authentication verification Suggested change: 3) Once a (D)TLS secured session is established and both sides have verified the authenticity of the peer's certificate The original phrase "certificate authentication verification" sounds confusing. + WH: Yep. Your wording is MUCH better; thank you. * DONE Section 5.4 Page 28, bulleted item 2: (wording) The text reads: 2) If there is no session open associated with the tmStateReference, ^^^^^^^^^^^^ then closeSession processing is completed. Suggested change: 2) If there is no open session associated with the tmStateReference, ^^^^^^^^^^^^ then closeSession processing is completed. + WH: Changed; thanks. * DONE Section 6.3 Page 29: (typo) Change "statical" to "statistical". + WH: thanks (caught by someone else as well). * DONE Section 6.3 Page 29: (wording) Change "feedback" to "information". + WH: Done * DONE Section 7 Page 34 sixth paragraph under "SnmpTLSAddress": (typo) Change the case of "snmpTLSAddress" to "SnmpTLSAddress". + WH: Good catch; thanks. * DONE Section 7 Page 36 sixth paragraph under "SnmpDTLSUDPAddress": (typo) Change the case of "snmpDTLSUDPAddress" to "SnmpDTLSUDPAddress". + WH: These actually merged so the typo was pre-fixed when I got to this comment. * DONE Section 7 Page 37 sixth paragraph under "SnmpDTLSSCTPAddress": (typo) Change the case of "snmpDTLSSCTPAddress" to "SnmpDTLSSCTPAddress". + WH: These actually merged so the typo was pre-fixed when I got to this comment. * DONE Section 7 Page 39 under tlstmSessionInvalidClientCertificates: (wording) The text reads: DESCRIPTION "The number of times an incoming session was not established on an (D)TLS server because the presented client certificate was invalid. Reasons for invalidation includes, but is not ^ ^^ limited to, cryptographic validation failures and lack of a ^^^ suitable mapping row in the tlstmCertToSNTable." Suggested change: DESCRIPTION "The number of times an incoming session was not established on an (D)TLS server because the presented client certificate was invalid. Reasons for invalidation include, but are not ^^^ limited to, cryptographic validation failures, or a lack of a ^ ^^ suitable mapping row in the tlstmCertToSNTable." + WH: Thanks; changed. * DONE Section 7 Page 39 under tlstmSessionInvalidServerCertificates: (wording) Same change in the DESCRIPTION clause as described above for the tlstmSessionInvalidClientCertificates DESCRIPTION clause. + WH: Changed; thanks * WONTDO Section 7 Page 40: (technical) I suggest adding: tlstmCertToSNTableLastChangedEngineBoots OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of snmpEngineBoots.0 when the tlstmCertToSNTable was last modified through any means." just above the "tlstmCertToSNTableLastChanged" object. Having an engine boots and "tlstmCertToSNTableLastChanged" values would simplify the reliable detection of changes to the tlstmCertToSNTable. Without an engine boots value, one cannot reliably detect changes to the tlstmCertToSNTable. I also suggest adding analogous engine boots values before the "tlstmParamsTableLastChanged" and "tlstmAddrTableLastChanged" objects. + WH: The tables are constructed currently according to the typical ways in which they're done in the rest of the IETF MIBs. In particular, it's assumed that managers are also watching the sysUptime.0 object for detecting time-since-boot changes for restarts. I'm not going to change this since we're already doing the "recommended" way of creating LastChanged objects. * WONTDO Section 7 Page 42 under "tlstmCertToSNFingerprint": (clarification) How is the actual Fingerprint of a certificate generated, and how is this MIB object populated? I _assume_ the Fingerprint is generated by reading in, then hashing, the certificate. Or is the Fingerprint already _in_ the certificate and just needs to be extracted? A similar clarification under "tlstmParamsClientFingerprint", and "tlstmAddrServerFingerprint" would be nice. Or just providing the clarification under the "Fingerprint" TEXTUAL-CONVENTION might be sufficient. + WH: I'm deliberating not specifying exactly how the fingerprints are generated in great detail to allow for flexibility in the system. However, the most recent draft has also switched the fingerprint type to the standard methods defined in RFC 5246 so it's now better documented through a reference. * DONE Section 8.1 Page 54 first paragraph: (clarification) The text reads: use separate ports for Notification sessions and for Command sessions. If this implementation recommendation is followed, (D)TLS Are these "listen" ports, or "connect" ports? + WH: Actually, I've removed the text entirely as we're already documenting multiple ports to use via the IANA consideration section. But "both" was really going to be the answer anyway ;-) * DONE Section 8.1 Page 54 first paragraph: (typo) Should REQUEST and RESPONSE be in lowercase? Change "Request- Response" to "request-response" + WH: Actually that whole paragraph was removed. * ANSWERED Section 8.2 Page 54: (attaboy) Thanks for the nice explanation! + WH: Thanks! I love good feedback too! * ANSWERED Section 9.1 Page 56 second paragraph: (clarification) The text reads: The instructions found in the DESCRIPTION clause of the tlstmCertToSNTable object must be followed exactly. It is also important that the rows of the table be searched in prioritized order starting with the row containing the lowest numbered tlstmCertToSNID value. Why _must_ the procedure be followed exactly, and why is it important that the rows of the table be searched in prioritized order? + WH: Simply because to do otherwise would lead let two different implementations of the MIB behave very differently under identical configuration, which would *be very bad* (TM). * DONE Section 11 Page 59 second paragraph: (typo) Add a second space after the colon after the phrase "(in alphabetical order):" + WH: Thanks; done! * ANSWERED Section A.1 Page 62 third bulleted item: (typo/clarification) The text reads: o Messages are protected against replay. (D)TLS uses explicit sequence numbers and integrity checks. DTLS uses a sliding window to protect against replay of messages within a session. Are (D)TLS and DTLS used properly here? + WH: Yep. DTLS has a sliding window mechanism but TLS doesn't need one (since the TCP transport wouldn't let them arrive out of order). * DONE Section B Page 63 first paragraph: (typo) Jettison the extra space between "challenge- response". + WH: Done. * DONE Section B Page 64 last two paragraphs: (clarification) The very last paragraph discusses "decrypted information", but no explan- ation of where the "encrypted information" originated. I _believe_ I understand this, but persons new to PKIX might not. The understanding of how/where the certificate hashes are encrypted and stored, then decrypted and compared, is critical to the understanding of PKIX. + WH: You're right; the text is broken. I'm fixing it because "decryption" is not the right verb there. * DONE Section C.1 Page 65 first paragraph: (typo) Change "Notification Generator's" to "Notification Generators". + WH: Thanks; fixed. * DONE Section C.2 Page 66 second to the last paragraph: (typo) Change "issuing certificate" to "issuing certificate". Change "1 to 1" to "one-to-one". + WH: thanks; done -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Dec 8 16:25:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369743A680D for ; Tue, 8 Dec 2009 16:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 WjQyShcve905 for ; Tue, 8 Dec 2009 16:25:28 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 995BF3A68E4 for ; Tue, 8 Dec 2009 16:25:27 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BB8B1981FE; Tue, 8 Dec 2009 16:25:16 -0800 (PST) From: Wes Hardaker To: "Joseph Salowey \(jsalowey\)" Organization: Sparta References: Date: Tue, 08 Dec 2009 16:25:16 -0800 In-Reply-To: (Joseph Salowey's message of "Sun, 6 Dec 2009 23:18:53 -0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:25:29 -0000 >>>>> On Sun, 6 Dec 2009 23:18:53 -0800, "Joseph Salowey (jsalowey)" said: JS> I've had a chance to take a look at draft-ietf-isms-dtls-tm-01. In JS> general I think the document is clear and well done. I have a few JS> comments below, I haven't gotten all the way through the MIB definition JS> or the appendices yet. Thanks for the comments and suggestions. 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 * DONE Section 2.1. I find it hard to reconcile a SHOULD for authentication of both client and server. Why not a MUST?. The next bullet seems to be a MUST for client authentication. Without server authentication there can be serious problems such as man-in-the-middle. I'm concerned that it is not required here. + Yep. As discussed in responses to others: the text actually came from others and I changed one SHOULD to a MUST but missed the other. The new document now has MUSTs for supporting authentication on both sides. * DONE Section 3.1.3 The document is slightly ambiguous as to the (D)TLS to transport mapping. DTLS can be run over UDP, TCP and SCTP and TLS can be run over TCP or SCTP. I think the document should be more clear that DTLS is used for SCTP and UDP and TLS is used for TCP. This is clear in the IANA considerations, but it would be better if it were spelled out earlier in the document. + I added a sentence to the introduction and abstract in order to make sure this is well spelled out. If you have other places you think it needs to be clearly stated, please suggest text. Note that the section you referenced above was already cleaned up lately so I believe it's already somewhat better. + Second, in looking for places to add a new sentence I noticed another typo that no one had caught yet; so thanks for that too! * DONE Section 3.3 and 4.1.1 These sections describe the mechanisms to map client certificates to security names and provisioning mechanism for this. After reading these sections I was left wondering about the server side. Section 5, does cover most of this in detail, but it seems some mention of this is appropriate earlier on in the document. + This section has gotten a lot of attention due to comments from other people as well. If you wish to re-read it to make sure they address your issues that would be great! * DONE Section 5.3, 2b It seems that referencing I-D.saintandre-tls-server-id-check should be enough, why do you need the last sentence about Common Name and subjectAltNAme? + That text has also changed and should be significantly better and more clear based on results from the last WG discussions. * DONE Section 5.3 last paragraph TLS does define a Server Name Indication extension for identifying the server you connect to ([http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt]). Right now the only type of name defined is host name, which may not be very useful for this case. New name types could be developed if it would solve a real problem. + I did add a reference to 4366 (Pasi mentioned it as well). + I found it interesting to note that 5246 is marked as obsoleting 4366 even though not everything in 4366 is in 5246 (and in fact 5246 *references* 4366). I suspect a bug in the RFC status DB. * WONTDO Section 9.1 TLS also supports extensions to communicate OCSP in the case the client does not have access to an OCSP server. I'm not sure if OCSP would be operationally useful for SNMP. + I doubt it fits wonderfully into the expected usage model. But if you have text you'd like to add, please propose it! Generally we've tried to make SNMP available offline as much, although the recent move into radius-based authentication is possibly changing that attitude. * DONE Section 10 Do you really need low number ports? Unless we really need them it might be best to just ask for reserved ports. + Nope. In fact, I mentioned this to you in the airport too and said we'd likely be changing it. And I did! -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Tue Dec 8 17:49:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46693A69FA for ; Tue, 8 Dec 2009 17:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[AWL=-1.790, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux0KwUEMszXv for ; Tue, 8 Dec 2009 17:49:37 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id C51873A68D6 for ; Tue, 8 Dec 2009 17:49:36 -0800 (PST) Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Eol41d04Q1ZXKqc55ppSs6; Wed, 09 Dec 2009 01:49:26 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA21.westchester.pa.mail.comcast.net with comcast id Eppl1d00Y284sdk3hppmu8; Wed, 09 Dec 2009 01:49:47 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: <20091029111229.GA20307@elstar.local><808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 8 Dec 2009 20:49:23 -0500 Message-ID: <016f01ca7871$d6186140$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acp4ZUBXkFXA92GPRD+vfOsVPfrC2QAC0gMg Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 01:49:38 -0000 Re: sessions These parts should probably explicitly say that the concept of "session" here is totally unrelated to TLS sessions in RFC 5246 (which are TLS-internal optimization detail not visible to TLSTM). But the name "tlsSessionID" is very poorly chosen, since it's very different from the TLS SessionID in RFC 5246. + WH: How does tlsSnmpSessionID sound? I've changed it to this. SNMP does not have sessions. RFC5590 says: The architecture defined in [RFC3411] and the Transport Subsystem defined in this document do not support SNMP sessions or include a session selector in the Abstract Service Interfaces. The Transport Subsystem might support transport sessions. [...] However, because the handling of transport sessions is specific to each Transport Model, some Transport Models MAY restrict selecting a particular transport session. [...] Implementations SHOULD be able to maintain some reasonable number of concurrent transport sessions, [...] and from RFC5591: The Transport Security Model does not work with transport sessions directly. Instead the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName, and securityLevel, and is referenced via the tmStateReference parameter. How and if this is mapped to a particular transport or channel is the responsibility of the Transport Subsystem. So any session ID here is specific to the TLS Transport Model Ergo, I recommend tlstmSessionID. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Tuesday, December 08, 2009 7:19 PM > To: Pasi.Eronen@nokia.com > Cc: isms@ietf.org > Subject: Re: [Isms] wg last call on the (d)tls transport model > > >>>>> On Fri, 6 Nov 2009 12:15:14 +0100, said: > > PE> Some random comments scribbled on printout during my > flight earlier > PE> today (or yesterday, depending on your point of view :-): > > Pasi, > > Thanks for the comments and suggestions. 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 > > > * DONE Technical > + DONE How the notification originator authenticates the > other end (TLS > server) when fingerprints are not used is very unclear (the > fingerprint case is clear). Section 5.3, step 3b, > suggests we could > use path validation, but it doesn't e.g. say what the "reference > identity" (in draft-saintandre-tls-server-id-check > terminology) would > be. Perhaps the MIB should allow specifying that > reference identity. > (MIB, tlstmAddrTable, is relevant here.) > > + WH: This was discussed in a past WG meeting and it was > determined that it was out of scope to establish X.509 > path validation management. So that's left up to possible > future work, possibly within the PKIX or other working > group that wants to take on creating an X.509 TA MIB. I > will state this fact more clearly and make sure it's > declared as implementation dependent. > > + WH: I've reworded the section to make it much clearer about > exactly what must be done. See if the new wording fixes > your issues. > > + DONE (I guess this applies to command generators, too, to > some degree > at least -- they also act as TLS clients, and have to authenticate > the server somehow.) > + WH: correct... They're in the same boat. If there is no > fingerprint for outgoing connections it's expected they do > path validation through another out-of-scope process. > > + DONE While TLS supports several different authentication > mechanism (X.509 certs, OpenPGP certs, pre-shared keys, > Kerberos, SRP, ...), TLSTM supports only one of them (X.509 > certs). This should be mentioned in e.g. Section 1 and Section > 4.1. > + WH: I've added sentences to both those locations stating that > other authentication forms are outside the scope of this > specification. > > + DONE Section 1.1, 2nd to last paragraph, and Section 3.1.3: > These parts should probably explicitly say that the concept > of "session" here is totally unrelated to TLS sessions in > RFC 5246 (which are TLS-internal optimization detail not > visible to TLSTM). But the name "tlsSessionID" is very > poorly chosen, since it's very different from the TLS > SessionID in RFC 5246. > + WH: How does tlsSnmpSessionID sound? I've changed it to this. > + WH: Note that I think it's possible to use the same sessionID > for both uses. It gets a bit more trick after > renegotiation though since the SNMP session ID can't > change. I've added text describing this potential conflict. > > + DONE Section 5.3 (last para) and Section 8.2: (D)TLS does > have the > "server_name" extension that does allow doing this. > + WH: Added a reference to RFC4366. > > + DONE MIB, Snmp*Address TCs: do we need four pages worth > of new TCs > to just describe (IPv4 address/IPv6 address/hostname)+port? > Surely many existing MIBs use address+port, too, and we could > import from somewhere? > + WH: per discussion at IETF, I've changed this so it's a single > address TC now and the 3 Domains all use it. > > + DONE MIB, Fingerprint TC, last paragraph: this is not really > consistent with how certificate fingerprints are used in many > other protocols -- usually we compare just the fingerprint > (not the whole certificate), and assume it's produced by a > good hash function. > + WH: Per IETF discussion I've made it so that fingerprints can > be used as the method of comparison. (Originally the text > was actually written to allow for "cheap" referencing > methods (beyond just hash fingerprints)). > > + DONE MIB, tlstmCertToSNSANType: is SecurityName case > sensitive? If it > is, you need to specify the case for IPv6 address, and probably > normalize the dNSName and domain part of rfc822name > (e.g., convert to > lower case). > + WH: Modified per discussion results during the IETF meeting. > > + DONE MIB, tlstmCertToSNSANType: how would othername be > converted to > SnmpAdminString? (which is UTF-8, so "take the raw DER" > does not work, > and it would be very administator-unfriendly, too) > + WH: As per discussion from the IETF, we're no longer directly > defining otherName mappings but do have an extensible OID > selection mechanism so future documents can define an > otherName mapping. > > + DONE Sections 3.3 and others: the document has snmpTLSDomain, > snmpDTLSUDPDomain and snmpDTLSSCTPDomain. Probably for > consistency, > the first should be snmpTLSTCPDomain, since SCTP would > also normally > use TLS, not DTLS (there's a draft proposing how to run DTLS over > SCTP, but it's just work in progress, not something that > can be done > today). > + WH: Ok, I've changed it. > > + DONE Section 2.1: if the CG/NO is always the (D)TLS > client, and it MUST > be authenticated (2nd bullet), then why is authenticating > the client > only SHOULD? (1st bullet) > + WH: Because I changed one from a SHOULD to a MUST and missed the > second. Thanks for the catch. I also cleaned up the wording a > bit more to make it clearer. > > + DONE The openSession ASI in Section 4.4.1 looks very different > from the SSHTM ASI -- is this intentional? > + WH: The SSH document changed from the point where that text > was copied and I didn't catch it. I've realigned the > document to the published RFC. > > + DONE Section 4.4.1: "this restriction is not needed for > TLS or DTLS over > SCTP": this restriction is present in TLS-over-TCP/SCTP, too, but > TCP/SCTP take care of ensuring that dst IP, dst port> > is unique. > + WH: That section was actually dropped as it was TLS specific > ASIs and is no longer included with the document. > > + DONE Section 4.4.2 and 4.4.3: I think these sections should be > just deleted -- these are TLS internal details. Furthermore, > for normal TLS (or DTLS, when a single datagram contains > multiple DTLS records), TLSTM cannot even determine > "wholeTlsMsgLength", since that would require parsing the TLS > messages (which would be a layering violation). > + WH: I agree and per discussion during the WG meeting, I've > removed them. > > + DONE Section 5.1.1 is also a bit questionable; it also seems to > suggest parsing DTLS records by TLSTM. And the details aren't > quite right: the same demultiplexing (mapping incoming UDP > packet, based on tuple, to > the right DTLS connection/context) has to happen for DTLS > handshake messages, too, not just DTLS application data > messages. > + WH: Per discussion at the IETF I've simplified it quite a bit > so it still discusses demultiplexing within UDP but > doesn't talk about (D)TLS specific packet types. See if > the new text looks better to you. > > + DONE Section 8.1, 1st paragraph: the last sentence of this > paragraph is very confusing, since the sessions this document > talks about are totally unrelated to TLS sessions (and TLS > session resumption). Besides, all TLS implementations support > session resumption, so this SHOULD is not really needed in > this document. > + WH: I've dropped the sentence > > + DONE Section 8.1, 2nd paragraph: Separate ports might be a > reasonable idea, but I don't understand what the rest of the > paragraph is saying... > + WH: It's discussing SNMP specific message types. But I agree > it's not needed. Not only that, we're asking for separate > ports from IANA anyway. So... I've deleted the whole > paragraph as I don't think any of it is necessary. > > + DONE Section 10: SSHTM uses ports >1023 -- should be good enough > for TLSTM, too (the criteria for allocating ports <1023 is > much stricter). > + WH: I don't mind something higher and at the WG meeting > everyone agreed. Changed. > > + DONE In normal SNMP-over-UDP, if e.g. the notification receiver > restarts, that's not a problem: at least if the notification > generator didn't send anything exactly when the restart was > ongoing, everything will continue just fine after the restart. > > But when using DTLS-over-UDP, if the notification receiver > restarts, the notification generator has to know that it needs > to start a new DTLS "connection" (because otherwise the > receiver will just silently drop all the packets it gets). The > same problem has been discussed for syslog-over-DTLS recently, > and draft-seggelmann-tls-dtls-heartbeat proposes one possible > solution. > > In SNMP most requests result in a response, so if no > response is seen, > *some* component will know there's something wrong. But > since TLSTM > isn't supposed to know about PDU types, it might be > architecturally > slightly tricky how opening a new DTLS "connection" > should be triggered > here. But the document should probably say something > about this issue. > > + WH: Per discussion in the WG meeting text was added to > reference the heartbeat work and to recommend that users > implement a dead-peer detection mechanism. > > + DONE Should the document say something about MTU/avoiding > fragmentation > for DTLS-over-UDP? > + WH: I added a paragraph in the operational considerations > section that functionally says we can't summarize all > those problems but readers should be aware of them. I > think if we dove down into it in depth it would amount to > pages of discussions about the ramifications of each > selection choice. > > + DONE DTLS allows multiple DTLS records in a single > datagram -- should > the document say something about this? > + WH: I've added some text describing this during the incoming > processing EOPs. > > + DONE Should the document say something about SCTP Partial > Reliability, > or use of SCTP streams? > + WH: I think this falls into the text already added for > "understand what's beneath you" in the operational > considerations. > > * DONE Minor editorial comments: > > + DONE The document title should have the acronym "TLS" in it. > + WH: Added > > + DONE Section 4.1.1: While the actual details of how self-signed > certificates can be used in TLSTM (in the rest of the spec) look > mostly OK, I would recommend against using the term > "trust anchor" to > refer to self-signed end-entity certificates. > + WH: You're right it's another over-used term and is confusing > depending on your definition of it (some use it as the > keying material, but 5280 seems to declare it the entity > producing the keying material)... How does this sound: > > "Trusted public keys from either CA certificates and/or > self-signed certificates, must be installed through a > trusted out of band mechanism into the server and its > authenticity MUST be verified before access is granted." > > + DONE Section 3.1.1, item 4, 2nd paragraph: this is quite > unclear, and goes > into details that are IMHO not relevant for TLSTM. > Perhaps something > like "Most TLS cipher suites do encryption" ? > + I removed the offending text and shortened it so that it really > says "(D)TLS" supports encryption. > > + DONE Section 3.1.1, item 5,: the sentence about > "amplification" is quite > unclear; the main purpose of DTLS cookie exchange is to limit > server-side resource consumption, not amplification (and > "detecting" > amplification could be tricky). > + WH: You're absolutely right about this. I'm surprised > no one (myself > included) has caught this before. Thanks for pointing it > out. I've changed it to: > > "Implementations are not required to perform the stateless > cookie exchange for every DTLS handshake, but in > environments where an overload on server side resources is > detectable it is RECOMMENDED that the cookie exchange is > utilized." > > + DONE Section 3.1.2: This text should probably mention that TLS > does not have any NULL integrity cipher suites. > + WH: I tried to clean this up a bit, but I'm not sure it should > be our job to describe what TLS has and what it doesn't. > (There is nothing prohibiting one from being created in the > future, EG.) > > + DONE MIB, tlstmParamsEntry: should "usable" be "unusable"? > + WH: Yep; Juergen caught this too. > > + WONTDO Section 9, "DTLS is more vulnerable to denial of > service attacks". > Well, a hypothetical version of DTLS that didn't include > the cookie > exchange might be more vulnerable, but since we don't have such > a version, this isn't really true. > + WH: I think the text following that statement functionally says > just this so I don't think any changes are needed. The > paragraph is really there to remind users that they need to > use cookies. > + DONE Global: s/US-US-ASCII/US-ASCII/; > + WH: Whoops; that was a search-and-replace gone awry > > + DONE The reference [x509] looks wrong. > + WH: I think that was originally a reference to RSA which I > removed long ago. I've changed it to reference the ITU doc. > > + WONTDO Appendix A and B: I would suggest deleting these. > + WH: The WG decided that these contained useful information but > should move to an appendix. > > + DONE Appendix C: "blueberry" is not a valid rfc822Name > ("blueberry@example.com" would be) > + WH: changed > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Wed Dec 9 18:18:43 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1883A68EA for ; Wed, 9 Dec 2009 18:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 e5z6T9LMud9I for ; Wed, 9 Dec 2009 18:18:41 -0800 (PST) Received: from QMTA12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 998EE3A69E0 for ; Wed, 9 Dec 2009 18:18:40 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA12.westchester.pa.mail.comcast.net with comcast id FCa21d00F0Fqzac5CEJWoS; Thu, 10 Dec 2009 02:18:30 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA08.westchester.pa.mail.comcast.net with comcast id FEJV1d00T284sdk3UEJWab; Thu, 10 Dec 2009 02:18:30 +0000 From: "David Harrington" To: Date: Wed, 9 Dec 2009 21:18:29 -0500 Message-ID: <020b01ca793f$1044b800$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acp5Pw/JkvaQIYcCRxGWTuAuz927Mw== Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 02:18:43 -0000 Hi, I reviewed draft-ietf-isms-dtls-tm-02.txt and have comments. section 1 s/defines supports/supports/ paragraph 4 repeats the last sentence of paragrah 1. I recommend eliminating paragraph 4. section 1 says The Transport Model in this document is referred to as the Transport Layer Security Transport Model (TLSTM). But the diagram shows DTLS TM TSM is used in the diagram before being mentioned in the text. Diagram s/Notification Responder/Notification Receiver/ s/NOTIFICATION ORIGINATOR applications/NOTIFICATION ORIGINATOR application/ section 1.1 Some changes have been made to the wording and/or capitalizations in the conventions section, compared to RFC5592. Some of those wordings were done at the request of the rfc editor. I recommend not making changes between the SSH-TM and TLS-TM documents unless there is a valid technical reason to do so. Consistency in the conventions is a good thing. Many of the conventions relate to SNMP in general, and some relate to the specifics of this transport model. I recommend the tlstm-specific conventions be positioned after the general conventions. I would move the paragraph starting "Large portions" after the discussions of agent/manager and principal. This would be consistent with the arrangement in the SSH-TM document. Because you use the (D)TLS term in the client/server discussion, the paragraph starting "Large portions" should precede the client/server discussion. section 2.1 first paragraph is a bit hard to parse. It could use wordsmithing. Section 2 mentions authentication, data message integrity, and privacy. Section 2.1 discusses mutual authentication and encryption. Section 3.1 discusses a broader range of threats addressed by the model. I think it would be good to put the discussion of what threats TLSTM addresses, and how it addresses them, in one place, and couples that with the MUST support features from section 2.1 (which is part of how it addresses them). The "primary goal paragraph in section 2 says a goal is source authentication, but section 1 explicitly says Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. There is a mismatch between how many in the security community define "source authentication" and the authentication done in a transport model. That's why SSHTM and TSM do not use the term "source authentication". section 2 doesn't actuallly describe TLS or DTLS at all. I think it should provide a quick architectural overview for SNMP readers (you know, TLS for Dummies ;-). section 3 In paragraph 2, unencrypted/encrypted was changed to unprotected/protected. RFC5592 used unencrypted because any unencryption (decryption) is expected to be done before the message is passed to the MPM. This is important for the elements of procedure to work, and it is important to understand how the transport model fits into the architecture - the purpose of this section. I don't know what unprotected means in this context. Remember we are NOT trying to be consistent with other security terminology; we are supposed to remain consistent with other SNMP terminology (as described under conventions). We had a serious debate about whether to be consistent with SNMP or with a Security Glossary that was being published. Consensus was to remain consistent with other SNMP documents. We don't use "protected" and "unprotected" in other SNMP documents. I don't know why you added the "authenticated and intergity-checked" text here, because that has nothing to do with how the transport model fits into the architecture. The RFC Editor questioned the inconsistency of capitalization for terms like Dispatcher and the applications between RFC5592 and other SNMP document, so we aligned them (probably imperfectly). You obviously prefer the opposite of the way our other ISMS documents have been handled. In the section about establishing channels/sessions, RFC5592 says multiple message sMAY be passed in the same channel. I think the same is accurate for (D)TLS. But you expanded this to add a SHOULD here. I would be very careful about this. We had significant debate about requests/responses having to go through the same channel/session. This SHOULD that you added could be misinterpreted in that context. I think the wording in RFC5592 fit the consensus, and your changes might conflict with that consensus. I would be really careful about all these minor unnecessary editorial changes to text that had WG consensus. Some of the original text was written as it is for very specific reasons. section 3.1.1 was written to describe how SSH addressed the threat. IIRC, the WG decided it was not necessary to describe the threat, since that was already done in RFC3411. Did the WG change its mind on this point? The application names are incorrect in the masquerade bullet. I think think it is incorrect to say that TLSTM authenticates the applications. TLSTM authenticates the TLS server and TLS client. The text does not describe the connection between X.509 certificates and the Access Control models that prevent masquerade. I would be careful using the word Privacy in the Disclosure paragraph. Privacy in SNMP means encryption; it has a very different meaning in the security community, usually related to a person's control of data pertaining to them. I would just use the term encryption: The TLS and DTLS protocols provide support for encryption tp prevent unauthorized disclosure of data. or to be consistent with RFC5592: 4. Disclosure - (D)TLS provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines. Denial of Service: Implementations are not required to perform the stateless cookie exchange for every DTLS handshake, but in environments where an overload on server side resources is detectable it is RECOMMENDED that the cookie exchange is utilized. /detectable/detectable by the implementation/ /utilized/utilized by the implementation/ This is purely an implementation decision, not a deployment decision, correct? section 3.1.2 /Message Protection/Message Authentication/ The TLS Transport Model determines from (D)TLS the identity of the authenticated principal, and the type and address associated with an incoming message. The TLS Transport Model provides this information to (D)TLS for an outgoing message. not really; the identity provided to (D)TLS for Requests is not yet authenticated. The identity provided to (D)TLS for Notifications is authorized, but not yet authenticated, except implicitly. If a suitable interface between the TLS Transport Model and the (D)TLS Handshake Protocol is implemented to allow the selection of security level dependent algorithms (for example a security level to cipher_suites mapping table) then different security levels may be utilized by the application. Will this be interoperable with engines that do not support selection of security dependent algorithms? /trust of particular algorithms and implementations should offer/ trust of particular algorithms. Implementations should offer/ (the current wording made it look like "algorithms and implementations" rather than the start of a new point. time. Implementers are encouraged to plan for changes in operator trust of particular algorithms and implementations should offer configuration settings for mapping algorithms to SNMPv3 security levels. The SNMP community has historically deliberately avoided any attempts to classify algorithms or crypto suites by strength. If different engines use different mappings, then the assumptions of the sender may not match those of the receiver, and security vulnerabilities could result. I am not sure that would be true of a TLS environment, but we have traditionally steered clear of this approach in SNMP standards. s/tlsSnmpSessionID/tlstmSessionID/ DTLS sessions, when used over UDP, are uniquely identified within the The UDP portion of the paragraph doesn't talk about the need for a unique address/port pairing; this is only mentioned when TCP/SCTP are said to NOT need it. I think the UDP section should talk about this requirement, or the TCP/SCTP should not discuss it. I am not certain it needs to be discussed here. The tlsSnmpSessionID MAY be the same as the (D)TLS internal SessionID but caution must be exercised since the (D)TLS internal SessionID may change over the life of the connection as seen by the TLSTM (for example during renegotiation). The tlsSnmpSessionID identifier MUST NOT change during the entire duration of the connection from the TLSTM's perspective. This paragraph seems to encourage the match between tlstmSessionID and the TLS session ID, which we know has potential problems. Wouldn't it be better to say implementers SHOULD NOT do this because ... are translated by the TLS Transport Model into security parameters for the TLS Transport Model and security model (i.e., securityLevel, RFC5592 says translated by the Transport Model into security parameters independent of the Transport and Security Models. The Transport This was very deliberate because securityLevel, securityName, and transport address are suposed to be independent of the models to maintain modularity. provided by the dispatcher in the sendMessage() Abstract Service Interface (ASI) and input from the tmStateReference cache. The The ASI includes the tmStateReference, so this is redundant. s/Interface (ASI) and input from the tmStateReference cache./Interface (ASI)./ (D)TLS sessions may be initiated by (D)TLS clients on behalf of command generators, notification originators or proxy forwarders. The applications that can do this should not be constrained by a list like this. New applications could be developed. I notice RFC5592 uses an even shorter list - whoops! s/originators or proxy forwarders/originators, proxy forwarders, and possibly other applications/ notification originators and proxy forwarders are usually unmanned automated processes. The targets to whom notifications should be sent is typically determined and configured by a network administrator. You added proxy forwarders to unmanned processes, but then only talk about configuring notifications. Admins also need to configure the proxy relationships. object and an appropriate snmpTLSAddress value. The snmpTargetParamsMPModel column of the snmpTargetParamsTable should be set to a value of 3 to indicate the SNMPv3 message processing model. Is that a SHOULD be? IIRC, Operators can send SNMPv1 messages over USM and SSHTM. The RFC3411 architecture calls for these to be modular, so an SNMPv3 message, for example, might be sent over this transport. Requiring this to be a 3 violates RFC3411 modularity. Operators should be able to send any message version over this transport; the document should discuss the implications of doing so. section 4.1 Should this section say that support of X.509 certs is REQUIRED for interoperability purposes? 4.1.1 Authentication using (D)TLS will require that SNMP entities are provisioned with certificates, which are signed by trusted certificate authorities. Furthermore, SNMP entities will most s/certificate authorities./certificate authorities (possibly itself). Trusted public keys from either CA certificates and/or self-signed certificates, must be installed through a trusted out of band mechanism into the server and its authenticity MUST be verified before access is granted. s/through a trusted out of band mechanism/, e.g., through a trusted out of band mechanism/ s/must be installed/MUST be installed/ authenticated tmSecurityName of the principal is derived up using the "derived up"? entity can use for certificate verification. SNMP entities SHOULD also be provisioned with a X.509 certificate revocation mechanism we don't that to be a MUST? potential tlstmCertToTSNTable mapping exists before performing s/potential// you want it there already, right? potential means the mappng can be added in the future. How will the engine know what potentially might be configured in the future? Implementations MAY choose to discard any connections for which no potential tlstmCertToTSNTable mapping exists before performing certificate verification to avoid expending computational resources associated with certificate verification. This is an implementation optimization. We probably should not be discussing it unless it impacts interoperability. If ti impacts interoperability, then we should probably be stating a SHOULD or a MUST here. The typical enterprise configuration will map a "subjectAltName" component of the tbsCertificate to the TLSTM specific tmSecurityName. How do you know what a typical configuration will look like? If this is a recommendation, then use SHOULD, not "typical" tbsCertificate is not mentioned yet in the document. I recommend you mention the cert in earlier discussions of X.509, and then point the reader to Appendix B for more information. You talk about mapping to a securityName, but I think you miss some very important rules about tmSecurityName: The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in the Elements of Procedure. The tmSecurityName MUST be constant for all traffic passing through a TLSTM session. Messages MUST NOT be sent through an existing TLS session that was established using a different tmSecurityName. The mapping discussion happens in a section called "Provisioning for the certificate" - but the mapping is not about provisioning, is it? section 4.2 within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP messages from being sent that exceeds the maximum DTLS message size. What are the acceptable exceptions that justify a SHOULD here, rather than a MUST? What will likely happen if the SNMP engine sends messages of excessive size? Transport Model. This document specifies the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. why do we need three different domains? destTransportAddress. This parameter may also be used by the transport subsystem to route the message to the appropriate Transport Model. This document specifies the snmpTLSDomain, the Isn't that exactly why we have three domains? Becaise the domain is used by the transport subsystem to decide which transport model to use? So should there be ONE domain the subsystem needs to know about, since all three combinations go to the same transport model? Does the transport model have nay way to determine which combionation to use, or does it have to rely on the domain to determine that? tmStateReference: A handle/reference to tmSecurityData to be used by the security model. I believe this is incorrect. This is a reference to the tmState cache, not the security cache. 4.4.1 Actually, tlstm does have specific responsibilities. It creates the tmSecurityName via the mapping tables, and creates the tmSessionID. This is the place where those discussions really belong. s/first prior/prior/ 5.1.1 DTLS is significantly different in terms of session handling than ^ over UDP 2) The TLS Transport Model queries the LCD using the transport parameters (source and destination addresses and ports) to determine if a session already exists and its tlsSnmpSessionID. So there can be only one DTLS session that exists between two endpoints? There cannot be two with different security principals or different securityLevels? I think that contradicts something I read earlier about securityLevels and mappings to crypto suites. Which table in the LCD does this query? Is the table only for DTLS/UDP sessions? s/through what session/through which session/ If a matching entry in the LCD does not exist then the message is passed to DTLS for processing without a corresponding tlsSnmpSessionID. The incoming packet may result in a new session being established if the receiving entity is acting as a DTLS server. If DTLS returns success then stop processing of this message. If DTLS returns an error then and the the tlstmSessionNoAvailableSessions counter and stop processing the message. If I read this correctly, then whether DTLS returns success or returns an error, we stop processing the message at this point. What is DTLS doing with this packet we pass it? Does it return something to us other than an error code? I have difficulty following the purpose and logic in this paragraph. The last sentence needs to be rewritten. I am not sure what it meant to say. "rogue" is used withiout being defined. Is this a malicious message? Can you proivde a reference so I can understand what a rogue message is? Is this an SNMP message? I don't recognize the term from other SNMP documents. I didn't review the DTLS spec. Is it accurate that DTLS receives a packet, passes it to the application for demultiplexing, which passes it back to DTLS to create a session(?), then DTLS passes it back to the application, to record the sessionID, and then the application passes it back to DTLS for decryption, which then passses the decrypted packet to the application? Boy, so much for layering. 5.1.2 singular? would single work here - just one at a time? or is the usage of singular that means outstanding or unusual - does singular have a special meaning in the DTLS world? If so, then the definition should be discussed. 5.2 you don't check that the tmStateReference refers to a cache containing the required values. This is something the WG decided needed to be done. you don't extract the transportDomain from tmStateReference, but you will need that to know whuch security mechansism and which underlying transport to use if you have to establish a new session. I notice that the snmpSshtmSessionNoSessions and tlstmSessionNoAvailableSessions counters have different name contructions, but count the same types of errors. Can we contruct the names in a similar fashion to make it easier for operators? 3) If tmSameSecurity is false and tmSessionID refers to a session that is no longer available then an implementation SHOULD open a new session using the openSession() ASI (described in greater detail in step 4b). An implementation MAY choose to return an error to the calling module and stop processing of the message. Shouldn't we have standardization in this handling? Why do we need to allow implementers to return an error rather than trying to open a new session? Which error counter gets returned if the implementation makes this choice? Would this choice be better inside the openSession() processing? what does an undefined tmSessionID look like? 4) If tmSessionID is undefined, then use tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel to see if there is a corresponding entry in the LCD suitable to send the message over. Does this decision consider DTLS vs TLS, and UDP vs TCP vs SCTP? Domain isn't mentioned. Section 5.3). Implementations MAY wish to offer message buffering to prevent redundant openSession() calls for the same cache entry. I am not sure what type of message buffering you refer to here. How will you get redundant openSession() calls? In 5592, if openSession fails, the tmtateReference being created is also discarded. Should it be discarded here? 5.3. Establishing a Session The TLS Transport Model provides the following primitive to establish a new (D)TLS session (previously discussed in Section 5.3): I don't think this was previously discussed in section 5.3, since we just entered section 5.3. [I have now spent 14 hours on this review and am one third of the way through the document. I'll let you start addressing these, and I'll try to continue the review later this week and next week.] David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From j.schoenwaelder@jacobs-university.de Thu Dec 10 00:53:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210E53A6A63 for ; Thu, 10 Dec 2009 00:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5nX7BqdFgXH for ; Thu, 10 Dec 2009 00:53:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 09BCB3A69DB for ; Thu, 10 Dec 2009 00:53:03 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFC18C000B for ; Thu, 10 Dec 2009 09:52:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WHzWcwLk1MTp for ; Thu, 10 Dec 2009 09:52:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4103C0003 for ; Thu, 10 Dec 2009 09:52:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5BBD9F51FF3; Thu, 10 Dec 2009 09:52:48 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Thu, 10 Dec 2009 09:52:48 +0100 Resent-Message-ID: <20091210085248.GG61275@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.2.213.0; Thu, 10 Dec 2009 09:26:44 +0100 Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 931CAC0012 for ; Thu, 10 Dec 2009 09:26:44 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mIxBxuhXBm4j; Thu, 10 Dec 2009 09:26:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91B98C0003; Thu, 10 Dec 2009 09:26:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2B17F51D82; Thu, 10 Dec 2009 09:26:40 +0100 (CET) From: Juergen Schoenwaelder To: Wes Hardaker Date: Thu, 10 Dec 2009 09:26:40 +0100 Thread-Topic: Ismstlstm last call comments from js Thread-Index: Acp5coIEWOT5hcODTaCXA4QrGOj5ZA== Message-ID: <20091210082640.GC61275@elstar.local> References: <20091029111902.GB20307@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US user-agent: Mutt/1.5.20 (2009-06-14) x-virus-scanned: amavisd-new at jacobs-university.de Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isms@ietf.org" Subject: Re: [Isms] Ismstlstm last call comments from js X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 08:53:05 -0000 On Wed, Dec 09, 2009 at 01:06:19AM +0100, Wes Hardaker wrote: [...] Thanks for your work. The following comments are written in my role as a technical contributor. > + DISCUSS There is no explicit text talking about clearing (and=20 > setting up) multiplexing state. But I guess this needs to be > discussed where multiplexing is discussed and this likely > requires some timer to do something equivalent as TCP's > TIME_WAIT. > + WH: To be honest, I'm not sure I understand this comment at > all? Which aspect of multiplexing are you referring to > and with what portion of the solution? I could > extrapolate a number of ideas from this comment but I'm > not sure which you're concerned with. Let me try be way of an example: Suppose I run 'snmpwalk', I press C-C in the middle of the walk and I immediately restart it - will the multiplexing to do the right thing or is the server going to consider the packets for the new session "garbage" entering the old session? And even if this is handled properly by DTLS (I do not know), what happens if packets are reordered in the network and a late packet from the first DTLS sessions spills over into the new session? > + DISCUSS The LAST-UPDATED and REVISION timestamps are likely wrong. Al= so=20 > note that there is again a shorter copyright notice that can be > used. > + WH: changed the date to be current when-built > + WH: copyright is what's in the SSH document. Are you > suggesting we use only what is found on > [http://www.ietf.org/iesg/statement/mib-copyright.html] instead? This web page has a note directing you to a page that directs you to the Trust Legal Provisions (TLP) and then you have lots of stuff to read. My understanding is that with the TLP in place, we can use this short text: Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). At least this is what we now have in the YANG modules. Note that I am not tracking the TLP in detail - perhaps Dan can confirm what the latest boilerplate is and update the web page you pointed at above. > + WONTDO There is text in the DESCRIPTION of SnmpTLSAddress talking abo= ut=20 > TransportAddress, TransportAddressType, TransportDomain and this > seems to be a cut'n'paste error. (This text is in all *Address TC > definitions and need to be fixed in all instances.) > + WH: I think if you re-read the text you'll see it makes sense. > Note that it's identical text to what's in the SSH RFC. > It's functionally saying that you shouldn't use objects of > that specific type and should be using the more generic > ones instead but read the description clauses of the > generic ones for any resolving issues. My comment was related to the fact that the SNMPv3 MIB modules (and this is where these TCs matter for us) use TDomain/TAddress and _not_ TransportAddressType, TransportAddressDomain and TransportAddress. There is also no reference to RFC 3419 and I think this is fine. I note that similar text is in RFC 5592 - I am now wondering why the text is there as well. Since the TC is called SnmpTLSAddress, I assume this TC is SNMP specific and thus belongs to the generic TAddress family of TCs and not to the TransportAddress family of TCs. > + WONTDO Lifecycle of tlstmParamsEntry: It seems I can create an=20 > entry while there is no target entry yet. But then, when I > delete a target, the tlstmParamsEntry goes away. I find this > inconsistent. > + WH: fate sharing as is was the result of a previous WG > discussion (in stockholm I think). The only option would > be to disallow making the target mib row active when a TLS > based domain was used until the row in the tlstmParamsTable > had been configured. This would be a significantly more > complex management operation than repopulating the > tlstmParamsTable ahead of the target mib table. I think > leaving the row so that it be pre-created is the only > sensible solution. > =20 > In the WG meeting (I think) the participants were heavily > in favor of having the row deleted if the corresponding > TARGET row was deleted. I think this makes sense from a > management issue, though I understand your view that it > looks inconsistent. It's likely what the manager will want > most (if not all) of the time though. I am not sure this is "likely what the manager will want most (if not all) of the time though" but if the WG believes this I won't object. I just do not recall that any of the other SNMPv3 tables do this kind of automatic deletion and hence this automatic delete comes as a surprise. I can very well imagine that I may want to change a target during a renumbering exercise where I do not want to loose the TLS parameters or that I want to disable a target for some time without loosing the TLS parameters. But again, if the WG believes this automatic delete is a feature, I will shutup. =20 /js --=20 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 Fri Dec 11 08:46:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6341B3A67A4 for ; Fri, 11 Dec 2009 08:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 zxEocrL+zhIM for ; Fri, 11 Dec 2009 08:46:53 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 8133F3A69BB for ; Fri, 11 Dec 2009 08:46:53 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id DD8C598153; Fri, 11 Dec 2009 08:46:40 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <020b01ca793f$1044b800$6601a8c0@china.huawei.com> Date: Fri, 11 Dec 2009 08:46:40 -0800 In-Reply-To: <020b01ca793f$1044b800$6601a8c0@china.huawei.com> (David Harrington's message of "Wed, 9 Dec 2009 21:18:29 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 16:46:54 -0000 DH> I reviewed draft-ietf-isms-dtls-tm-02.txt and have comments. Thanks for the comments David. I'll start reviewing them for needed changes to the document. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Dec 16 02:52:59 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4D03A688C for ; Wed, 16 Dec 2009 02:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIZzFg6XpQvj for ; Wed, 16 Dec 2009 02:52:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 61CDA3A695B for ; Wed, 16 Dec 2009 02:52:58 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69D66C001B for ; Wed, 16 Dec 2009 11:52:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SQPcP9UsSE6E; Wed, 16 Dec 2009 11:52:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 743B0C0015; Wed, 16 Dec 2009 11:52:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7ED1EF75D45; Wed, 16 Dec 2009 11:52:40 +0100 (CET) Date: Wed, 16 Dec 2009 11:52:40 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20091216105240.GA78492@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:52:59 -0000 Hi, at the last IETF meeting, we did run out of time on issue #12. Here is the content of Wes' slide: -- #12: Fate Sharing Currently: - Can create TLSTM-MIB entries in advance of TARGET-MIB entries being created - When TARGET-MIB entries are deleted, corresponding TLSTM-MIB entries are deleted Juergen finds this inconsistent. - Second bullet decided in previous WG Proposal: leave as is -- A more detailed explanation: The tlstmParamsEntry, which is conceptually a (D)TLS specific extension of the SNMP-TARGET-MIB's snmpTargetParamsTable, currently has has the following text in the description of tlstmParamsRowStatus: If this row is deleted it has no effect on the corresponding row in the targetParamsTable. If the corresponding row in the targetParamsTable is deleted then this row must be automatically removed. I (speaking as technical contributor) find this second sentence somewhat surprising for essentially two reasons: - First, we specify here something that at the end affects the implementation of targetParamsTable, which may or may not be our business (but I guess is unavoidable for behaviours like this). - Second, while we allow to provision entries in tlstmParamsEntry for later use (once targetParamsTable entries are created), we forbid to reuse those provisioned entries once a targetParamsTable using it gets removed - which can be considered somewhat inconsistent. As a chair, I do not have a strong opinion about this and by default we will continue with the text currently in the document. If WG members support a change of the text (i.e. removal of the second quoted sentence), then please speak up now. Silence will be read as agreement to the current text. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Wed Dec 16 05:40:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125963A6405 for ; Wed, 16 Dec 2009 05:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 mkcRUGvdPgfS for ; Wed, 16 Dec 2009 05:40:09 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id DCF203A6892 for ; Wed, 16 Dec 2009 05:40:08 -0800 (PST) Received: from localhost (unknown [32.164.145.219]) by mail.hardakers.net (Postfix) with ESMTPSA id 2D15398099 for ; Wed, 16 Dec 2009 05:39:53 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20091216105240.GA78492@elstar.local> Date: Wed, 16 Dec 2009 05:39:48 -0800 In-Reply-To: <20091216105240.GA78492@elstar.local> (Juergen Schoenwaelder's message of "Wed, 16 Dec 2009 11:52:40 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsissue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 16 Dec 2009 13:40:16 -0000 >>>>> On Wed, 16 Dec 2009 11:52:40 +0100, Juergen Schoenwaelder said: JS> at the last IETF meeting, we did run out of time on issue #12. Here JS> is the content of Wes' slide: Thanks for the nicely done summary of the issue Jurgen. I'd like to note that if WG members want to comment on it, please do so within the next 2 weeks as I intend to publish a new draft soon to address David's comments. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed Dec 16 08:14:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEE73A6A08 for ; Wed, 16 Dec 2009 08:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 PICpbG7K4xly for ; Wed, 16 Dec 2009 08:14:49 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id B8F283A69E5 for ; Wed, 16 Dec 2009 08:14:46 -0800 (PST) Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA10.westchester.pa.mail.comcast.net with comcast id HpwW1d0091YDfWL5AsEZml; Wed, 16 Dec 2009 16:14:33 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA20.westchester.pa.mail.comcast.net with comcast id HsF51d004284sdk3gsF5JB; Wed, 16 Dec 2009 16:15:05 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20091216105240.GA78492@elstar.local> Date: Wed, 16 Dec 2009 11:14:31 -0500 Message-ID: <062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091216105240.GA78492@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acp+Pej1hMkkJsHfSImn1bTaoPbgCAAKxMpA Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 16 Dec 2009 16:14:58 -0000 Hi, In SSHTM (and in TLSTM), it is possible to attempt to set up entries in advance, creating the tunnels for expected communication. This was deliberate and had consensus of the WG for SSHTM work. I think Eliot was the person who first championed this approach. I think the idea was to support one channel that could support both request/response traffic and notification traffic. I am not sure whether that is still something that can be suppoorted, given the way SSHTM has been written, and given the assumptions about implied-authentication of the sender for notifications. To be consistent with this design decision, the point is needed: > - Can create TLSTM-MIB entries in advance of TARGET-MIB entries > being created but the second point would potentially cause a problem, I think. > - When TARGET-MIB entries are deleted, corresponding TLSTM-MIB > entries are deleted It may not be a problem, if the only TLSTM-MIB entries that are associated with TARGET-MIB are for notifications. You might want to be able to set up a channel in advance to receive notifications. If these will be fate shared, then the text should be very clear to operators that they MUST fill in the TARGET-MIB first before they do the TLSTM-MIB. The correllary to the point above is that the TLSTM-MIB entries should not be instantiated if the corresponding TARGET-MIB entries don't exist. What happens if the TARGET-MIB entry becomes inactive? Does the corresponding TLSTM-MIB entry become inactive? I personally don't care whether pre-creation is supported. I just wanted to explain some of the thinking behind the original decision, whiuch could be impacted by the fate-sharing decision. I will point out that I don't think SSHTM has this fate-sharing restriction, and would tend to favor consistency across models because of the impact to operators of having different approaches to configuration rules in different models. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, December 16, 2009 5:53 AM > To: isms@ietf.org > Subject: [Isms] issue #12: fate sharing > > Hi, > > at the last IETF meeting, we did run out of time on issue #12. Here > is the content of Wes' slide: > > -- > > #12: Fate Sharing > > Currently: > > - Can create TLSTM-MIB entries in advance of TARGET-MIB entries > being created > - When TARGET-MIB entries are deleted, corresponding TLSTM-MIB > entries are deleted > > Juergen finds this inconsistent. > - Second bullet decided in previous WG > > Proposal: leave as is > > -- > > A more detailed explanation: The tlstmParamsEntry, which is > conceptually a (D)TLS specific extension of the SNMP-TARGET-MIB's > snmpTargetParamsTable, currently has has the following text in the > description of tlstmParamsRowStatus: > > If this row is deleted it has no effect on the corresponding > row in the targetParamsTable. > > If the corresponding row in the targetParamsTable is deleted > then this row must be automatically removed. > > I (speaking as technical contributor) find this second sentence > somewhat surprising for essentially two reasons: > > - First, we specify here something that at the end affects the > implementation of targetParamsTable, which may or may not be our > business (but I guess is unavoidable for behaviours like this). > > - Second, while we allow to provision entries in tlstmParamsEntry for > later use (once targetParamsTable entries are created), we forbid to > reuse those provisioned entries once a targetParamsTable using it > gets removed - which can be considered somewhat inconsistent. > > As a chair, I do not have a strong opinion about this and by default > we will continue with the text currently in the document. If WG > members support a change of the text (i.e. removal of the second > quoted sentence), then please speak up now. Silence will be read as > agreement to the current text. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Thu Dec 17 14:38:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCBF3A68C1 for ; Thu, 17 Dec 2009 14:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, 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 QfXBSTDK52XZ for ; Thu, 17 Dec 2009 14:38:00 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id AA85D3A6814 for ; Thu, 17 Dec 2009 14:37:59 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id JCBH1d0031HzFnQ51NctZL; Thu, 17 Dec 2009 22:36:53 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA14.westchester.pa.mail.comcast.net with comcast id JNdl1d00H284sdk3aNdlnM; Thu, 17 Dec 2009 22:37:46 +0000 From: "David Harrington" To: Date: Thu, 17 Dec 2009 17:37:44 -0500 Message-ID: <079301ca7f69$8d004820$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acp/aYyXJQD9gjdbSD69yAWPGIFDVw== Subject: [Isms] revew of snmp/dtls, part II X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 17 Dec 2009 22:38:01 -0000 Hi, Picking up at 5.3 paragraph 1 references 5.3 "This MAY be done automatically" - you explicitly exampt Report and Response messages. rfc5590 deliberately did not sayt these OK, these not, but used "applications that initiate, such as" because SNMPv3 is designed to allow new applications to be developed in the future. I am conmcerned to see the selection of cyphersuites discussed in the Elements of Procedure. This is something that I think should be out of scope for an ISMS document. We are supposed to be using the existing underlying secure transport, without the TM having any knowldege of the details of the security. Which cyphersuites get used should be configured for the TLS layer, and the TM EOP should be blissfully unaware of this TLS-layer configuration. If the TM needs to be pre-configured with a list of the acceptable certificates and ciphersuites, then this TM misses the point of ISMS. I think trying to support multiple security levels is a mistake. If you don't want security, don't use a secure transport. Duh! We have multiple security level support in USM. I am unaware that anybody actually uses multiple securitylevels in the real world, except for very specific things like auto-discovery. You don't need that supported in every TM. We don't support it in SSHTM, and we don't need it here. Let's not add complexity for the sake of adding complexity. Nobody NEEDS this. Implementations can choose to supplement the standard with as much complxiety as their customers demand, but we don't need that complexity turned into a MUST-implement requirement of the standard. The standard should be simple enough to encourage implementers to implement a standard baseline to achieve interoperability. Stop adding unnecessary complexity. - " tlstmSessionOpenErrors is incremented, an error indication is returned, and processing stops. If the session failed to open because the presented server certificate was unknown or invalid then the tlstmSessionUnknownServerCertificate or tlstmSessionInvalidServerCertificates MUST be incremented and a tlstmServerCertificateUnknown or tlstmServerInvalidCertificate notification SHOULD be sent as appropriate. Reasons for server certificate invalidation includes, but is not limited to, cryptographic validation failures and an unexpected presented certificate identity." "includes but is not limoted to"? So different implementations are allowed to choose which conditions they want to count in their counter? So how do you compare these across implementations? Where is the interoperability? How can an operator use this information effectively if the implementation can choose what gets counted? A standard should be CLEAR and UNAMBIGUOUS. Again, I think you are getting way too detailed in the knowledge of the TLS implementation. step a) requires preconfiguration. Did I miss something? Is this no longer the ISMS WG, which was trying to minimize or eliminate preconfiguration for SNMP-specific credentials and parameters, and just use what was already available from the lower layer secure transport? Complexity, complexity, complexity. " b) The (D)TLS client side of the connection MUST verify that authenticated identity of the (D)TLS server's certificate is the certificate." I'm not sure I understand what this says. "is the certificate"? what certificate? The one we're checking? s/ determine the if the presented identity matches the/???/ " 4) The (D)TLS-specific session identifier is passed to the TLS Transport Model and associated with the tmStateReference cache entry to indicate that the session has been established successfully and to point to a specific (D)TLS session for future use." does this mean "set the sessionID in the tmStateReference cache to the session identifier passed to tlstm from TLS? " Servers that wish to support multiple principals at a particular port" Does this really have to be part of TLSTM? We are defining a standard baseline for interoperability. Why we do we even need to know if the implementers choose to support some additional complexity in the TLS layer? In SSHTM, we have a sessionscloses counter; is ti deliberate that we don't bother to increment one for closed tls sessions? In SSHTM, closing a session only requires the sessionID from the tmStateReference; In TLSTM, you pass in a whole tmStateReference. Is this really necessary? dbh David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From j.schoenwaelder@jacobs-university.de Fri Dec 18 01:38:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCA53A68BE for ; Fri, 18 Dec 2009 01:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG75oLqe-dFs for ; Fri, 18 Dec 2009 01:38:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 320783A689A for ; Fri, 18 Dec 2009 01:38:26 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1B9AC005E; Fri, 18 Dec 2009 10:38:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rMTnrE0T+Sqw; Fri, 18 Dec 2009 10:38:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A74F8C0053; Fri, 18 Dec 2009 10:38:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 52F36F81A55; Fri, 18 Dec 2009 10:38:06 +0100 (CET) Date: Fri, 18 Dec 2009 10:38:06 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20091218093806.GA68656@elstar.local> Mail-Followup-To: David Harrington , "isms@ietf.org" References: <079301ca7f69$8d004820$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <079301ca7f69$8d004820$6601a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] revew of snmp/dtls, part II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 09:38:27 -0000 On Thu, Dec 17, 2009 at 11:37:44PM +0100, David Harrington wrote: > - " tlstmSessionOpenErrors is incremented, an error indication > is > returned, and processing stops. If the session failed to open > because the presented server certificate was unknown or invalid > then the tlstmSessionUnknownServerCertificate or > tlstmSessionInvalidServerCertificates MUST be incremented and a > tlstmServerCertificateUnknown or tlstmServerInvalidCertificate > notification SHOULD be sent as appropriate. Reasons for server > certificate invalidation includes, but is not limited to, > cryptographic validation failures and an unexpected presented > certificate identity." > "includes but is not limoted to"? So different implementations are > allowed to choose which conditions they want to count in their > counter? So how do you compare these across implementations? Where is > the interoperability? How can an operator use this information > effectively if the implementation can choose what gets counted? A > standard should be CLEAR and UNAMBIGUOUS. I don't find the text ambiguous. It says that counters MUST be incremented when a presented server certificate is unknown or invalid. The text then provides some example reasons why a server certificate can be considered unknown or invalid. This is advice to implementors. Are you suggesting to remove helpful implementation hints? /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 Fri Dec 18 09:36:30 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988A928C0E1 for ; Fri, 18 Dec 2009 09:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li-fJdnuv9M3 for ; Fri, 18 Dec 2009 09:36:30 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BCDC53A6774 for ; Fri, 18 Dec 2009 09:36:29 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A612198099; Fri, 18 Dec 2009 09:36:14 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <079301ca7f69$8d004820$6601a8c0@china.huawei.com> Date: Fri, 18 Dec 2009 09:36:14 -0800 In-Reply-To: <079301ca7f69$8d004820$6601a8c0@china.huawei.com> (David Harrington's message of "Thu, 17 Dec 2009 17:37:44 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Ismsrevew of snmp/dtls, part II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 17:36:30 -0000 >>>>> On Thu, 17 Dec 2009 17:37:44 -0500, "David Harrington" said: DH> Picking up at 5.3 David, Thanks for the notes; I'll be examining them in detail in the coming week-ish. -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Fri Dec 18 10:17:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7754C3A68E7 for ; Fri, 18 Dec 2009 10:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6xT5tZp7bRs for ; Fri, 18 Dec 2009 10:17:14 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id E7C053A691A for ; Fri, 18 Dec 2009 10:17:12 -0800 (PST) X-Trace: 313691233/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.90/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.90 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAHJVK0s+vGRa/2dsb2JhbACCexYUhTmIc8Q/CoQkBIFk X-IronPort-AV: E=Sophos;i="4.47,419,1257120000"; d="scan'208";a="313691233" X-IP-Direction: IN Received: from 1cust90.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.90]) by smtp.pipex.tiscali.co.uk with SMTP; 18 Dec 2009 18:16:56 +0000 Message-ID: <000901ca8005$ffe88220$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Fri, 18 Dec 2009 18:16:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 18:17:15 -0000 Wes I find this a bit light still on client side processing of certs. The I-D rightly says that the use of certs by TLS is optional for both client and server. What it does not say is that many, if not most, uses of TLS require server certs and not client certs - some stacks would even appear to fail when client certs are involved. So the environment into which this is going, in terms of TLS, is that server certs are a commonplace, client certs are not. As I see, it is the client cert that here is the basis for the derivation of the securityName and so is REQUIRED. How do you ensure that a client Cert is even sent? - limit the ciphersuites to those where a client cert is REQUIRED? - require the server library to allow the request of a client cert and insist that one is requested? - ...? And what if no client cert is requested? Perhaps the client should terminate the TLS session if the initial handshake does not ask for client cert; assuming it can tell. Most likely, this will be an implementation bug on the part of the server, failing to tell the TLS library that that is what it wants, but it could be malicious. And it would be useful to have a MIB object to count this type of failure (as distinct from 'I did not like the server cert'). I say 'initial' because a common pattern when client certs are required is to establish a TLS session with only a server cert and then to re-negotiate using the secure channel and this time asking for a client cert. This has been going on for many years, and it has just been noticed that it opens up a hole for a MITM attack - see the TLS list for more details (if you have few weeks to spare reading all the details:-( Since client certs are a MUST, I think that we should exclude this approach and require client certs in all negotiations (even if a fix for the loophole is imminent). Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: Sent: Wednesday, December 09, 2009 12:27 AM Subject: [Isms] Updated TLSTM document posted > > I've updated the TLSTM document to address all the outstanding WG issues > and comments received to date (roughly 130 comment items were received, > though some were duplicates). > > The current version (-02) can be found here: > > http://tools.ietf.org/id/draft-ietf-isms-dtls-tm-02.txt > > (It's currently still redirecting to -01, but I'm sure that will be > fixed once the publication finishes propagating) > > Diffs since last time can be found here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-dtls-tm-02.txt > > I'll be sending out responses to each person that submitted comments > shortly. Thanks to everyone who did send in comments as they were all > very helpful. > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From jhutz@cmu.edu Fri Dec 18 10:39:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D403A68B4 for ; Fri, 18 Dec 2009 10:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koCQdcNT4XTc for ; Fri, 18 Dec 2009 10:39:14 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 542EC3A688E for ; Fri, 18 Dec 2009 10:39:14 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nBIIcw1h024436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 13:38:58 -0500 (EST) Date: Fri, 18 Dec 2009 13:38:58 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Message-ID: <5CE8FED51DE57671E687ED13@minbar.fac.cs.cmu.edu> In-Reply-To: <3283_1261089469_nBHMbmol030623_079301ca7f69$8d004820$6601a8c0@china.huawei.com> References: <3283_1261089469_nBHMbmol030623_079301ca7f69$8d004820$6601a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [Isms] revew of snmp/dtls, part II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 18:39:15 -0000 --On Thursday, December 17, 2009 05:37:44 PM -0500 David Harrington wrote: > Which cyphersuites get used should be > configured for the TLS layer, and the TM EOP should be blissfully > unaware of this TLS-layer configuration. Agree. > I think trying to support multiple security levels is a mistake. Agree. > "includes but is not limoted to"? So different implementations are > allowed to choose which conditions they want to count in their > counter? So how do you compare these across implementations? Where is > the interoperability? Not at this layer. > Again, I think you are getting way too detailed in the knowledge of > the TLS implementation. On the contrary, the correct thing here is to simply specify counters and notifications to be used when an invalid certificate is encountered, and to leave the question of what constitutes an invalid certificate below the TLS abstraction, as much as possible. It turns out there are some details which we must and do specify above that layer, such as name mapping, but everything else should be left to (D)TLS, as we do with SSH. BTW, this reminds me -- we should define an EKU keyPurposeId for SNMP. -- Jeff From adonati@motorola.com Mon Dec 21 06:47:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033493A695B for ; Mon, 21 Dec 2009 06:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 zXF3xY9lCoQ6 for ; Mon, 21 Dec 2009 06:47:18 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 0B3263A6A15 for ; Mon, 21 Dec 2009 06:47:18 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1261406809!8470128!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 6125 invoked from network); 21 Dec 2009 14:46:50 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-5.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Dec 2009 14:46:50 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id nBLEknbc001794 for ; Mon, 21 Dec 2009 07:46:49 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id nBLEknp5025459 for ; Mon, 21 Dec 2009 08:46:49 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id nBLEkmHY025456 for ; Mon, 21 Dec 2009 08:46:48 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 09:46:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: wg last call on the (d)tls transport model Thread-Index: Acp4ZARbeKsP2q5RSOewL+E/hfEd+QJ4XByQ References: <20091029111229.GA20307@elstar.local> From: "Donati Andrew-MGIA0477" To: "Wes Hardaker" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 14:47:19 -0000 Wes, Your efforts in evaluating and acting on these comments are greatly appreciated. One more thing that recently came to mind is possibly adding a control specifically for tlstm notifications, which can be much like the existing snmpEnableAuthenTraps object. Andy Donati -----Original Message----- From: Wes Hardaker [mailto:wjhns1@hardakers.net]=20 Sent: Tuesday, December 08, 2009 7:10 PM To: Donati Andrew-MGIA0477 Cc: Juergen Schoenwaelder; isms@ietf.org Subject: Re: wg last call on the (d)tls transport model >>>>> On Sun, 1 Nov 2009 09:57:49 -0500, "Donati Andrew-MGIA0477" said: DA> I read the (d)tls transport model document and here is the full=20 DA> summary of my comments: (The first 3 items were posted to the list DA> previously) Thanks for the comments and suggestions. 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 * DONE tlstmServerAuthFailure notification.=20 Will it be helpful for network administrators to know the current count of how many times the presented server certificate is invalid in each tlstmServerAuthFailure notification? If so, it may be useful to have tlstmSessionInvalidServerCertificates as an additional binding, especially if this object is the trigger. + WH: After WG discussion I did add these requested objects. They've also been restructured a touch since the last time you read them to make them more clear (due to other comments). * DONE Standard authentication failure notification.=20 There may have been some previous discussions about possibly using the standard authenticationFailure trap for tlstm (client) authentication failures. Will this be used or mentioned in the document? + WH: I added a entry in the EoP to discuss when this should be sent during the establishing a session rules. =20 * DONE tlstmServerCertNotFound Will it be feasible to have a scalar object that serves as a counter for this event?=20 If implemented, it can be added to this notification. + WH: The two notifications, as discussed above, were cleaned up and a counter was added. Please see if the new text meets your needs. =20 * DONE Section 6.4 Configuration Tables There is double verb, (is are), in the 2nd sentence. + WH: fixed, thanks! =20 * DONE Section 6.4.1 Notifications This section mentions a notification (tlstmServerAuthFailure) that alerts management stations when the server's presented certificate does not meet the expected value but does not appear to have a statement that directly refers to the tlstmServerCertNotFound notification. + WH: Good point; I changed the text to this: =20 The TLSTM-MIB defines notifications to alert management stations when a (D)TLS connection fails because a server's presented certificate did not meet an expected value (tlstmServerCertNotFound) or because cryptographic validation failed (tlstmServerAuthFailure). -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Dec 21 07:59:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261EF3A6A27 for ; Mon, 21 Dec 2009 07:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRHhIpo-xGhN for ; Mon, 21 Dec 2009 07:59:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2DE083A6A0F for ; Mon, 21 Dec 2009 07:59:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06EC4C0028; Mon, 21 Dec 2009 16:58:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qQbc8xGy0xh8; Mon, 21 Dec 2009 16:58:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D359CC001C; Mon, 21 Dec 2009 16:58:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59A8AF96873; Mon, 21 Dec 2009 16:58:41 +0100 (CET) Date: Mon, 21 Dec 2009 16:58:41 +0100 From: Juergen Schoenwaelder To: Donati Andrew-MGIA0477 Message-ID: <20091221155839.GD15104@elstar.local> Mail-Followup-To: Donati Andrew-MGIA0477 , Wes Hardaker , "isms@ietf.org" References: <20091029111229.GA20307@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:59:05 -0000 On Mon, Dec 21, 2009 at 03:46:26PM +0100, Donati Andrew-MGIA0477 wrote: > Your efforts in evaluating and acting on these comments are greatly > appreciated. One more thing that recently came to mind is possibly > adding a control specifically for tlstm notifications, which can be much > like the existing snmpEnableAuthenTraps object. I am wondering whether this is generally the right approach given the fact that we have an access control model that can enable / disable notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Dec 21 08:23:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CA93A6A33 for ; Mon, 21 Dec 2009 08:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIJSvlMYZ6yr for ; Mon, 21 Dec 2009 08:23:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CA3353A68E6 for ; Mon, 21 Dec 2009 08:23:05 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0AC3C001C; Mon, 21 Dec 2009 17:22:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id INbXM0VZalXS; Mon, 21 Dec 2009 17:22:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A44AC0009; Mon, 21 Dec 2009 17:22:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E3375F96EDD; Mon, 21 Dec 2009 17:22:44 +0100 (CET) Date: Mon, 21 Dec 2009 17:22:44 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20091221162244.GG15104@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <000901ca8005$ffe88220$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901ca8005$ffe88220$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:23:07 -0000 On Fri, Dec 18, 2009 at 06:16:53PM +0100, tom.petch wrote: > Wes > > I find this a bit light still on client side processing of certs. > > The I-D rightly says that the use of certs by TLS is optional for > both client and server. What it does not say is that many, if not > most, uses of TLS require server certs and not client certs - some > stacks would even appear to fail when client certs are involved. > > So the environment into which this is going, in terms of TLS, > is that server certs are a commonplace, client certs are not. > > As I see, it is the client cert that here is the basis for the > derivation of the securityName and so is REQUIRED. How > do you ensure that a client Cert is even sent? > > - limit the ciphersuites to those where a client cert is REQUIRED? > > - require the server library to allow the request of a client cert and insist > that one is requested? > > - ...? > > And what if no client cert is requested? Perhaps the client > should terminate the TLS session if the initial handshake does > not ask for client cert; assuming it can tell. Most likely, > this will be an implementation bug on the part of the server, failing > to tell the TLS library that that is what it wants, but it could be > malicious. And it would be useful to have a MIB object to > count this type of failure (as distinct from 'I did not like the > server cert'). > > I say 'initial' because a common pattern when client certs are > required is to establish a TLS session with only a server cert > and then to re-negotiate using the secure channel and this > time asking for a client cert. This has been going on for many > years, and it has just been noticed that it opens up a hole for > a MITM attack - see the TLS list for more details (if you have > few weeks to spare reading all the details:-( > > Since client certs are a MUST, I think that we should > exclude this approach and require client certs in all > negotiations (even if a fix for the loophole is imminent). Can you make a concrete proposal what should be added/deleted in the existing ID to address your concern? But keep in mind that we do not want to mess around with (D)TLS internals. Also not that there is text like this: a) The (D)TLS server side of the connection identifies the authenticated identity from the (D)TLS client's principal certificate using configuration information from the tlstmCertToTSNTable mapping table. The resulting derived tmSecurityName is recorded in the tmStateReference cache as tmSecurityName. The details of the lookup process are fully described in the DESCRIPTION clause of the tlstmCertToTSNTable MIB object. If any verification fails in any way (for example because of failures in cryptographic verification or because of the lack of an appropriate row in the tlstmCertToTSNTable) then the session establishment MUST fail, the tlstmSessionInvalidClientCertificates object is incremented and processing stops. The text clearly says that a failure to verify the client's cert causes processing to stop. It is not clear to me why this is not sufficient - hence the request for a concrete change proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From adonati@motorola.com Mon Dec 21 08:33:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA30B3A67D9 for ; Mon, 21 Dec 2009 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5S0h-bfGPgi for ; Mon, 21 Dec 2009 08:33:43 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6B6FC28C0D7 for ; Mon, 21 Dec 2009 08:33:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1261413206!43878871!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8688 invoked from network); 21 Dec 2009 16:33:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Dec 2009 16:33:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id nBLGXQlB007578 for ; Mon, 21 Dec 2009 09:33:26 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id nBLGXP73000545 for ; Mon, 21 Dec 2009 10:33:25 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id nBLGXPOB000538 for ; Mon, 21 Dec 2009 10:33:25 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 11:33:03 -0500 Message-ID: In-Reply-To: <20091221155839.GD15104@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: wg last call on the (d)tls transport model Thread-Index: AcqCVon2QvdGJ+M4SmWp1TN70f+98QAA+wkQ References: <20091029111229.GA20307@elstar.local> <20091221155839.GD15104@elstar.local> From: "Donati Andrew-MGIA0477" To: "Juergen Schoenwaelder" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:33:44 -0000 Thanks. Since vacm access can already take care of this, we should be all set the way it is. - Andy Donati =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, December 21, 2009 10:59 AM To: Donati Andrew-MGIA0477 Cc: Wes Hardaker; isms@ietf.org Subject: Re: wg last call on the (d)tls transport model On Mon, Dec 21, 2009 at 03:46:26PM +0100, Donati Andrew-MGIA0477 wrote: =20 > Your efforts in evaluating and acting on these comments are greatly=20 > appreciated. One more thing that recently came to mind is possibly=20 > adding a control specifically for tlstm notifications, which can be=20 > much like the existing snmpEnableAuthenTraps object. I am wondering whether this is generally the right approach given the fact that we have an access control model that can enable / disable notifications. /js --=20 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 Dec 21 09:00:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B053A6A44 for ; Mon, 21 Dec 2009 09:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U5yVH7z+jNg6 for ; Mon, 21 Dec 2009 09:00:01 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 5A34F3A6A0B for ; Mon, 21 Dec 2009 09:00:01 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BD80E980D2; Mon, 21 Dec 2009 08:59:44 -0800 (PST) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: <20091029111229.GA20307@elstar.local> <20091221155839.GD15104@elstar.local> Date: Mon, 21 Dec 2009 08:59:44 -0800 In-Reply-To: (Donati Andrew-MGIA's message of "Mon, 21 Dec 2009 11:33:03 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 17:00:02 -0000 >>>>> On Mon, 21 Dec 2009 11:33:03 -0500, "Donati Andrew-MGIA0477" said: DA> Thanks. Since vacm access can already take care of this, we should DA> be all set the way it is. Thanks. (And thanks Juergen, because I was going to say the exact same thing but you already had!) -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Dec 22 16:41:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E8D3A6909 for ; Tue, 22 Dec 2009 16:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFoVwPil-krl for ; Tue, 22 Dec 2009 16:41:53 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D90B83A68C6 for ; Tue, 22 Dec 2009 16:41:48 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 0A4B99808B; Tue, 22 Dec 2009 16:41:08 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> Date: Tue, 22 Dec 2009 16:41:07 -0800 In-Reply-To: <000901ca8005$ffe88220$0601a8c0@allison> (tom petch's message of "Fri, 18 Dec 2009 18:16:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM 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, 23 Dec 2009 00:41:54 -0000 >>>>> On Fri, 18 Dec 2009 18:16:53 +0100, "tom.petch" said: tp> I find this a bit light still on client side processing of certs. I've tried to careful walk the line of too much vs too little (in fact, I've recently removed some DTLS specific handling and have moved a lot of text to an appendix because WG members thought there was too much detail). In short, it's not our job to specify how to process certificates as that's already documented in other documents like 5280. tp> The I-D rightly says that the use of certs by TLS is optional for tp> both client and server. True, but it also says that this document is only specifying X.509 based authentication of clients and servers. It doesn't preclude other forms of TLS usage, but is only concentrating on the X.509 usage. tp> What it does not say is that many, if not most, uses of TLS require tp> server certs and not client certs - some stacks would even appear to tp> fail when client certs are involved. Most web uses do, yes. I have a number of personal client-side certificates that disagree with your statement that they're not commonly used. Their usage has definitely been increasing in the past decade, though not as much over port 80 which is where many people believe all TLS takes place. tp> As I see, it is the client cert that here is the basis for the tp> derivation of the securityName and so is REQUIRED. How tp> do you ensure that a client Cert is even sent? You'll get an error if you follow the Elements of Procedure without a client offering a certificate. Specifically: If any verification fails in any way (for example because of failures in cryptographic verification or because of the lack of an appropriate row in the tlstmCertToTSNTable) then the session establishment MUST fail, the tlstmSessionInvalidClientCertificates object is incremented and processing stops. tp> And what if no client cert is requested? Perhaps the client tp> should terminate the TLS session if the initial handshake does tp> not ask for client cert; assuming it can tell. Most likely, tp> this will be an implementation bug on the part of the server, failing tp> to tell the TLS library that that is what it wants, but it could be tp> malicious. And it would be useful to have a MIB object to tp> count this type of failure (as distinct from 'I did not like the tp> server cert'). We could create counters to identify every particular type of error that may result from TLS, but the number of counters would be huge and be very specific to TLS processing. The WG has specifically avoided management of TLS specific internals and it is hoped that future TLS and X.509 specific MIB objects may be developed in other working groups. You're right that problems like you've listed will result in failed connections. It is impossible for this document to enumerate all the possible connection failure cases without duplicating most of the TLS and 5280 documents in the process. tp> I say 'initial' because a common pattern when client certs are tp> required is to establish a TLS session with only a server cert tp> and then to re-negotiate using the secure channel and this tp> time asking for a client cert. That's common for applications where a client certificate isn't required, yes. For us we always require a client cert. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Wed Dec 23 14:15:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D1D2A3A6942; Wed, 23 Dec 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091223221501.D1D2A3A6942@core3.amsl.com> Date: Wed, 23 Dec 2009 14:15:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-03.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-03.txt Pages : 64 Date : 2009-12-23 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/SCTP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-23140528.I-D@ietf.org> --NextPart-- From cfinss@dial.pipex.com Thu Dec 24 03:30:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399C53A694E for ; Thu, 24 Dec 2009 03:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiixE10gUU4i for ; Thu, 24 Dec 2009 03:30:43 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 94F803A6887 for ; Thu, 24 Dec 2009 03:30:42 -0800 (PST) X-Trace: 225833357/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.234/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.234 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAMPfMks+vGTq/2dsb2JhbACCXo49kzGiSSQJa4wuAgiCJQ4NgWkEgWWLdQ X-IronPort-AV: E=Sophos;i="4.47,448,1257120000"; d="scan'208";a="225833357" X-IP-Direction: IN Received: from 1cust234.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.234]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 11:30:20 +0000 Message-ID: <007301ca8484$2cfe6720$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> Date: Thu, 24 Dec 2009 11:03:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 11:30:44 -0000 Juergen The text you quote is fine; I am concerned about an earlier problem, getting a certificate to validate in the first place, about which more should be said in Appendix B, such as: "The (D)TLS client initiates the handshake protocol with a ClientHello message but the server can request a handshake, initial or as part of a re-negotiation, with a HelloRequest" and "Most applications running over TLS authenticate the server with a certificate and do not authenticate the client. When the client is authenticated, then it is often as part of a re-negotiation, that is a secure channel is established with an initial handshake with server authentication only and then a re-negotiation authenticates the client. The TLS client cannot send an unsolicited certificate; it can only send one when requested to by the TLS server, and then only of the type that the server requests. The derivation of the SNMP securityName depends on the client certificate and so SNMP applications acting as a TLS server must ensure that the handshake requests a client certificate suitable for authentication. The client can send application data after an initial handshake and prior to re-negotiation and so the client certificate must be requested as part of the initial handshake and not left to re-negotiation." A reference for this would be RFC5246. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Wes Hardaker" ; Sent: Monday, December 21, 2009 5:22 PM Subject: Re: [Isms] Updated TLSTM document > On Fri, Dec 18, 2009 at 06:16:53PM +0100, tom.petch wrote: > > Wes > > > > I find this a bit light still on client side processing of certs. > > > > The I-D rightly says that the use of certs by TLS is optional for > > both client and server. What it does not say is that many, if not > > most, uses of TLS require server certs and not client certs - some > > stacks would even appear to fail when client certs are involved. > > > > So the environment into which this is going, in terms of TLS, > > is that server certs are a commonplace, client certs are not. > > > > As I see, it is the client cert that here is the basis for the > > derivation of the securityName and so is REQUIRED. How > > do you ensure that a client Cert is even sent? > > > > - limit the ciphersuites to those where a client cert is REQUIRED? > > > > - require the server library to allow the request of a client cert and insist > > that one is requested? > > > > - ...? > > > > And what if no client cert is requested? Perhaps the client > > should terminate the TLS session if the initial handshake does > > not ask for client cert; assuming it can tell. Most likely, > > this will be an implementation bug on the part of the server, failing > > to tell the TLS library that that is what it wants, but it could be > > malicious. And it would be useful to have a MIB object to > > count this type of failure (as distinct from 'I did not like the > > server cert'). > > > > I say 'initial' because a common pattern when client certs are > > required is to establish a TLS session with only a server cert > > and then to re-negotiate using the secure channel and this > > time asking for a client cert. This has been going on for many > > years, and it has just been noticed that it opens up a hole for > > a MITM attack - see the TLS list for more details (if you have > > few weeks to spare reading all the details:-( > > > > Since client certs are a MUST, I think that we should > > exclude this approach and require client certs in all > > negotiations (even if a fix for the loophole is imminent). > > Can you make a concrete proposal what should be added/deleted in the > existing ID to address your concern? But keep in mind that we do not > want to mess around with (D)TLS internals. Also not that there is > text like this: > > a) The (D)TLS server side of the connection identifies the > authenticated identity from the (D)TLS client's principal > certificate using configuration information from the > tlstmCertToTSNTable mapping table. The resulting derived > tmSecurityName is recorded in the tmStateReference cache as > tmSecurityName. The details of the lookup process are fully > described in the DESCRIPTION clause of the > tlstmCertToTSNTable MIB object. If any verification fails in > any way (for example because of failures in cryptographic > verification or because of the lack of an appropriate row in > the tlstmCertToTSNTable) then the session establishment MUST > fail, the tlstmSessionInvalidClientCertificates object is > incremented and processing stops. > > The text clearly says that a failure to verify the client's cert > causes processing to stop. It is not clear to me why this is not > sufficient - hence the request for a concrete change proposal. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From cfinss@dial.pipex.com Thu Dec 24 03:30:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C113A6887 for ; Thu, 24 Dec 2009 03:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 cWPcc-puILuN for ; Thu, 24 Dec 2009 03:30:43 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 61DAA3A6911 for ; Thu, 24 Dec 2009 03:30:43 -0800 (PST) X-Trace: 225833384/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.234/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.234 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAMPfMks+vGTq/2dsb2JhbACCXo49w0AKgiWCBASBZQ X-IronPort-AV: E=Sophos;i="4.47,448,1257120000"; d="scan'208";a="225833384" X-IP-Direction: IN Received: from 1cust234.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.234]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 11:30:24 +0000 Message-ID: <007401ca8484$2e2c86e0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <000901ca8005$ffe88220$0601a8c0@allison> Date: Thu, 24 Dec 2009 11:29:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 11:30:44 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Wednesday, December 23, 2009 1:41 AM > >>>>> On Fri, 18 Dec 2009 18:16:53 +0100, "tom.petch" said: > Most web uses do, yes. I have a number of personal client-side > certificates that disagree with your statement that they're not commonly > used. Their usage has definitely been increasing in the past decade, > though not as much over port 80 which is where many people believe all > TLS takes place. To quote the author of RFC5246, "it's common (well, common in the small number of cases where client certs are used at all) for the server to let the client connect and request a resource and then if the resource is protected renegotiate asking for a certificate" or this quote just in from the TLS list > Although it's technically possible to implement client identity > protection securely with the existing protocol, it is so significantly > underspecified that it makes it unlikely that even those clients > which care about this, implement it in a secure fashion today. Ouch! Ask most people with a TLS background (as opposed to operations) and I expect you will find the view that - client authentication is rare - when the client is authenticated, it is as part of re-negotiation so that is the environment I see us going into; hence the need to say more. Tom Petch > -- > Wes Hardaker > Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 23 13:43:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236BE3A677D for ; Wed, 23 Dec 2009 13:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfGlAqEv3TWy for ; Wed, 23 Dec 2009 13:43:11 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 46D953A659C for ; Wed, 23 Dec 2009 13:43:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id AFD04980A4; Wed, 23 Dec 2009 13:42:49 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <020b01ca793f$1044b800$6601a8c0@china.huawei.com> Date: Wed, 23 Dec 2009 13:42:48 -0800 In-Reply-To: <020b01ca793f$1044b800$6601a8c0@china.huawei.com> (David Harrington's message of "Wed, 9 Dec 2009 21:18:29 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 14:41:59 -0000 DH> I reviewed draft-ietf-isms-dtls-tm-02.txt and have comments. Hi David, Thanks for the comments and suggestions. 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 WH: Note: I reformatted much of the comments to ensure they were more easily readable. Some that were more severely white space damaged I didn't reformat due to time constraints. * DONE Section 1 + DONE s/defines supports/supports/ + DONE paragraph 4 repeats the last sentence of paragrah 1. I recommend eliminating paragraph 4. + DONE section 1 says The Transport Model in this document is referred to as the Transport Layer Security Transport Model (TLSTM). But the diagram shows DTLS TM + WH: Good catch; figure changed. + DONE TSM is used in the diagram before being mentioned in the text. + WH: Added a sentence and a reference to the paragraph above the diagram. + DONE Diagram s/Notification Responder/Notification Receiver/ s/NOTIFICATION ORIGINATOR applications/NOTIFICATION ORIGINATOR application/ * DONE Section 1.1 + DONE Some changes have been made to the wording and/or capitalizations in the conventions section, compared to RFC5592. Some of those wordings were done at the request of the rfc editor. I recommend not making changes between the SSH-TM and TLS-TM documents unless there is a valid technical reason to do so. Consistency in the conventions is a good thing. Many of the conventions relate to SNMP in general, and some relate to the specifics of this transport model. I recommend the tlstm-specific conventions be positioned after the general conventions. I would move the paragraph starting "Large portions" after the discussions of agent/manager and principal. This would be consistent with the arrangement in the SSH-TM document. Because you use the (D)TLS term in the client/server discussion, the paragraph starting "Large portions" should precede the client/server discussion. + WH: Done as you suggested. I actually think the text originally come from a pre-RFC version of the SSH document. * WONTDO Section 2.1 first paragraph is a bit hard to parse. It could use wordsmithing. + WH: The first paragraph is a sentence long and merely says "To properly support the SNMP over TLS Transport Model, the (D)TLS implementation requires the following:". If you had a problem with a paragraph I doubt it was this one. * DONE Section 2 mentions authentication, data message integrity, and privacy. Section 2.1 discusses mutual authentication and encryption. Section 3.1 discusses a broader range of threats addressed by the model. I think it would be good to put the discussion of what threats TLSTM addresses, and how it addresses them, in one place, and couples that with the MUST support features from section 2.1 (which is part of how it addresses them). + WH: I've moved the MUST/SHOULD sentences into section 3 per your suggestion. * DONE The "primary goal paragraph in section 2 says a goal is source authentication, but section 1 explicitly says Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. There is a mismatch between how many in the security community define "source authentication" and the authentication done in a transport model. That's why SSHTM and TSM do not use the term "source authentication". + WH: changed to "peer identity authentication" * WONTDO section 2 doesn't actuallly describe TLS or DTLS at all. I think it should provide a quick architectural overview for SNMP readers (you know, TLS for Dummies ;-). + WH: The WG decided that such a architectural overview would be placed into an appendix, which is where it was moved to. * DONE Section 3 + DONE In paragraph 2, unencrypted/encrypted was changed to unprotected/protected. RFC5592 used unencrypted because any unencryption (decryption) is expected to be done before the message is passed to the MPM. This is important for the elements of procedure to work, and it is important to understand how the transport model fits into the architecture - the purpose of this section. I don't know what unprotected means in this context. Remember we are NOT trying to be consistent with other security terminology; we are supposed to remain consistent with other SNMP terminology (as described under conventions). We had a serious debate about whether to be consistent with SNMP or with a Security Glossary that was being published. Consensus was to remain consistent with other SNMP documents. We don't use "protected" and "unprotected" in other SNMP documents. + WH: changed to refer specifically to encryption and authentication. I find the current paragraph in 5592 misleading because SSH does much more than just encryption. I understand your issue with the word "protecting" even though I think it's ok to use. I've changed the text, however, to be more explicit about what the TLSTM is expecting from the TLS layer. + WONTDO I don't know why you added the "authenticated and intergity-checked" text here, because that has nothing to do with how the transport model fits into the architecture. + WH: It definitely fits into the architecture since the TLSTM is outsourcing it's authentication and integrity protection to the (D)TLS transport. TLSTM is explicitly expecting the TLS layer to have accomplished not just encryption (as the SSHTM says) but also verification that the message hasn't been modified. If verification wasn't done then we'd have a real problem with using TLS. SSH should have, IMHO, also described this aspect of it's architecture in its corresponding paragraph. We can put that on the 'bis todo list ;-) + DONE The RFC Editor questioned the inconsistency of capitalization for terms like Dispatcher and the applications between RFC5592 and other SNMP document, so we aligned them (probably imperfectly). You obviously prefer the opposite of the way our other ISMS documents have been handled. + WH: Actually, I don't care that much. It's likely my fingers cared, however. I've changed them to match your expectations. + DONE In the section about establishing channels/sessions, RFC5592 says multiple message sMAY be passed in the same channel. I think the same is accurate for (D)TLS. But you expanded this to add a SHOULD here. I would be very careful about this. We had significant debate about requests/responses having to go through the same channel/session. This SHOULD that you added could be misinterpreted in that context. I think the wording in RFC5592 fit the consensus, and your changes might conflict with that consensus. + WH: I've changed that SHOULD to a MAY. + ANSWERED I would be really careful about all these minor unnecessary editorial changes to text that had WG consensus. Some of the original text was written as it is for very specific reasons. + WH: the two models are different in different areas. If you're referring to the above, then I agree it can stay the same. In other cases, this isn't the case. I'm, at this point, only changing things in the document people have issues with. Since you had an issue with the above, I've changed it. * WONTDO Section 3.1.1 was written to describe how SSH addressed the threat. IIRC, the WG decided it was not necessary to describe the threat, since that was already done in RFC3411. Did the WG change its mind on this point? + WH: During one WG meeting this was discussed I believe (I'd have to go back though the audio to double check) and was agreed that the text should be shortened (which I did) but not removed as it was helpful. The text, as is, is more clear to the reader IMHO. You don't suggest changing it so you must be fine with it too. + DONE The application names are incorrect in the masquerade bullet. I think think it is incorrect to say that TLSTM authenticates the applications. TLSTM authenticates the TLS server and TLS client. + WH: changed to: "The TLSTM provides for verification of the identity of the (D)TLS server through the use of the (D)TLS protocol and the X.509 certificates." + DONE The text does not describe the connection between X.509 certificates and the Access Control models that prevent masquerade. + WH: I've never liked that paragraph either. so I've deleted it. + DONE I would be careful using the word Privacy in the Disclosure paragraph. Privacy in SNMP means encryption; it has a very different meaning in the security community, usually related to a person's control of data pertaining to them. I would just use the term encryption: The TLS and DTLS protocols provide support for encryption tp prevent unauthorized disclosure of data. or to be consistent with RFC5592: 4. Disclosure - (D)TLS provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines. + WH: Changed to your suggested RFC5592 similar text + DONE Denial of Service: Implementations are not required to perform the stateless cookie exchange for every DTLS handshake, but in environments where an overload on server side resources is detectable it is RECOMMENDED that the cookie exchange is utilized. /detectable/detectable by the implementation/ /utilized/utilized by the implementation/ This is purely an implementation decision, not a deployment decision, correct? + WH: Um, no... It could certainly be turned on and off with configuration and policy knobs. That being said, I don't think your suggested text is bad either so I've changed it to that. If nothing else, it suggests to do the right thing in the default configuration state of the transport implementation. * DONE Section 3.1.2 + WONTDO /Message Protection/Message Authentication/ + WH: The section discusses more than just authentication; it discusses encryption too. + DONE Quoting: "The TLS Transport Model determines from (D)TLS the identity of the authenticated principal, and the type and address associated with an incoming message. The TLS Transport Model provides this information to (D)TLS for an outgoing message." not really; the identity provided to (D)TLS for Requests is not yet authenticated. The identity provided to (D)TLS for Notifications is authorized, but not yet authenticated, except implicitly. + WH: Fair enough; I've changed the second sentence to "The TLS Transport Model provides the identity and destination type and address to (D)TLS for outgoing messages." If you think this is still incorrect, please suggest text. + ANSWERED Quoting the document: "If a suitable interface between the TLS Transport Model and the (D)TLS Handshake Protocol is implemented to allow the selection of security level dependent algorithms (for example a security level to cipher_suites mapping table) then different security levels may be utilized by the application." Will this be interoperable with engines that do not support selection of security dependent algorithms? + WH: yes, because they still have to meet the other criteria which means that if it's a fixed selection their security level must still be appropriate (ie, no NULL for auth/encr) + DONE /trust of particular algorithms and implementations should offer/ trust of particular algorithms. Implementations should offer/ (the current wording made it look like "algorithms and implementations" rather than the start of a new point. + ANSWERED Quoting: "time. Implementers are encouraged to plan for changes in operator trust of particular algorithms and implementations should offer configuration settings for mapping algorithms to SNMPv3 security levels." The SNMP community has historically deliberately avoided any attempts to classify algorithms or crypto suites by strength. If different engines use different mappings, then the assumptions of the sender may not match those of the receiver, and security vulnerabilities could result. I am not sure that would be true of a TLS environment, but we have traditionally steered clear of this approach in SNMP standards. + WH: you'll note that we're not standardizing things in this document. We're merely saying to plan for algorithmic perceived-strength changes. The only thing we state in the document is you can't use NULL algorithms. + DONE s/tlsSnmpSessionID/tlstmSessionID/ + DONE DTLS sessions, when used over UDP, are uniquely identified within the The UDP portion of the paragraph doesn't talk about the need for a unique address/port pairing; this is only mentioned when TCP/SCTP are said to NOT need it. I think the UDP section should talk about this requirement, or the TCP/SCTP should not discuss it. I am not certain it needs to be discussed here. + WH: You're very right. In fact, I couldn't find the original text that required the uniqueness between ports. Turned out it was in a section that was removed and it was the place the MUST previously existed. I've taken the older text from the deleted section and ensured it's in the new (and the sentence referencing SCTP and TLS/TCP was removed since it was somewhat redundant and out of place). + WONTDO Quoting: "The tlsSnmpSessionID MAY be the same as the (D)TLS internal SessionID but caution must be exercised since the (D)TLS internal SessionID may change over the life of the connection as seen by the TLSTM (for example during renegotiation). The tlsSnmpSessionID identifier MUST NOT change during the entire duration of the connection from the TLSTM's perspective." This paragraph seems to encourage the match between tlstmSessionID and the TLS session ID, which we know has potential problems. Wouldn't it be better to say implementers SHOULD NOT do this because ... + WH: It says "MAY", which I don't think is an encouragement. It's an implementation hint that you need to be careful when doing so. But if they want to work out the problems, they can do so and then match them (which may help them with other implementation related binding issues). + DONE Quoting: "are translated by the TLS Transport Model into security parameters for the TLS Transport Model and security model (i.e., securityLevel," RFC5592 says translated by the Transport Model into security parameters independent of the Transport and Security Models. The Transport This was very deliberate because securityLevel, securityName, and transport address are suposed to be independent of the models to maintain modularity. + WH: I've changed: 1) s/securityLevel/tmSecurityLevel/ 2) s/i.e./e.g./ + Both TMs (TLS and SSH) have to do translation. This document merely spells out the current likely needed values. You're right that it shouldn't be explicit though and they should be referenced as examples to keep the modularity safe for future change. + WONTDO Quoting provided by the dispatcher in the sendMessage() Abstract Service Interface (ASI) and input from the tmStateReference cache. The The ASI includes the tmStateReference, so this is redundant. s/Interface (ASI) and input from the tmStateReference cache./Interface (ASI)./ + WH: I believe this text helps the reader understand that extra important parameters are contained within the object. + DONE Quoting: (D)TLS sessions may be initiated by (D)TLS clients on behalf of command generators, notification originators or proxy forwarders. The applications that can do this should not be constrained by a list like this. New applications could be developed. I notice RFC5592 uses an even shorter list - whoops! s/originators or proxy forwarders/originators, proxy forwarders, and possibly other applications/ + WH: I made the change as "or other applications". + DONE Quoting: notification originators and proxy forwarders are usually unmanned automated processes. The targets to whom notifications should be sent is typically determined and configured by a network administrator. You added proxy forwarders to unmanned processes, but then only talk about configuring notifications. Admins also need to configure the proxy relationships. + WH: added "and proxied requests" + DONE Quoting: object and an appropriate snmpTLSAddress value. The snmpTargetParamsMPModel column of the snmpTargetParamsTable should be set to a value of 3 to indicate the SNMPv3 message processing model. Is that a SHOULD be? IIRC, Operators can send SNMPv1 messages over USM and SSHTM. The RFC3411 architecture calls for these to be modular, so an SNMPv3 message, for example, might be sent over this transport. Requiring this to be a 3 violates RFC3411 modularity. Operators should be able to send any message version over this transport; the document should discuss the implications of doing so. + WH: Added "When used with the SNMPv3 message processing model, + WH: And obviously, the answer to your leading "SHOULD" is no... it shouldn't be SHOULD. * DONE Section 4.1 Should this section say that support of X.509 certs is REQUIRED for interoperability purposes? + WH: Added: " TLSTM implementations are REQUIRED to support X.509 certificates." * DONE Section 4.1.1 + DONE Quoting: Authentication using (D)TLS will require that SNMP entities are provisioned with certificates, which are signed by trusted certificate authorities. Furthermore, SNMP entities will most s/certificate authorities./certificate authorities (possibly itself). + WH: (possibly the certificate itself) + DONE Quoting: Trusted public keys from either CA certificates and/or self-signed certificates, must be installed through a trusted out of band mechanism into the server and its authenticity MUST be verified before access is granted. s/through a trusted out of band mechanism/, e.g., through a trusted out of band mechanism/ s/must be installed/MUST be installed/ + WH: changed must to MUST but didn't add the e.g.. Out of band is the only choice as we don't provide an TLSTM in-band mechanism (and that would be a challenge ;-). + DONE Quoting: authenticated tmSecurityName of the principal is derived up using the "derived up"? + WH: s/up// + ANSWERED Quoting: entity can use for certificate verification. SNMP entities SHOULD also be provisioned with a X.509 certificate revocation mechanism we don't that to be a MUST? + WH: no we don't, though feel free to argue that we should do otherwise. I can see cases where it may not be possible for certain devices to support revocation lists. + WONTDO Quoting: potential tlstmCertToTSNTable mapping exists before performing s/potential// you want it there already, right? potential means the mappng can be added in the future. How will the engine know what potentially might be configured in the future? + WH: Actually, no. It's possible that you could find a row but it's resulting configuration within the row won't work and thus it won't be a "true" match in the end. This sentence is there to say that if you have no matches at all, as an implementation hint, you may want to not accept the connection at all without diving further into processing the message. IE, a quick drop. + WONTDO Quoting: Implementations MAY choose to discard any connections for which no potential tlstmCertToTSNTable mapping exists before performing certificate verification to avoid expending computational resources associated with certificate verification. This is an implementation optimization. We probably should not be discussing it unless it impacts interoperability. If ti impacts interoperability, then we should probably be stating a SHOULD or a MUST here. + WH: It's an implementation hint. As has been pointed out by other vendor's comments, they have been found useful and they're not detrimental. + DONE Quoting: The typical enterprise configuration will map a "subjectAltName" component of the tbsCertificate to the TLSTM specific tmSecurityName. How do you know what a typical configuration will look like? If this is a recommendation, then use SHOULD, not "typical" + WH: Fair point on the wording. I changed the sentence to be: 'Enterprise configurations are encouraged to map a "subjectAltName" component of the X.509 certificate to the TLSTM specific tmSecurityName.' I don't think that SHOULD is acceptable here either as we'd be mandating deployment not protocol standardization. + DONE tbsCertificate is not mentioned yet in the document. I recommend you mention the cert in earlier discussions of X.509, and then point the reader to Appendix B for more information. + WH: Changed to X.509 certificate + WONTDO You talk about mapping to a securityName, but I think you miss some very important rules about tmSecurityName: The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in the Elements of Procedure. The tmSecurityName MUST be constant for all traffic passing through a TLSTM session. Messages MUST NOT be sent through an existing TLS session that was established using a different tmSecurityName. The mapping discussion happens in a section called "Provisioning for the certificate" - but the mapping is not about provisioning, is it? + WH: I don't believe we're missing anything about mapping to tmSecurityNames. It is discussed in multiple places in the document like the EOP and the MIB as well (not just in the provision section). If you feel that it should be discussed somewhere it is not, please specify the exact spot. * DONE Section 4.2 + ANSWERED Quoting: within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP messages from being sent that exceeds the maximum DTLS message size. What are the acceptable exceptions that justify a SHOULD here, rather than a MUST? What will likely happen if the SNMP engine sends messages of excessive size? + WH: I expect that there are stacks out there that will not permit accurate calculations of DTLS message sizes from inside an application. Given that, it's a SHOULD. If it's too large then it'd be an stack error that the implementation would have to deal with. What the stack does and whether or not the application is notified is beyond the scope. Warning about the problem, however, isn't. + ANSWERED Quoting: Transport Model. This document specifies the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. why do we need three different domains? + WH: Because otherwise there would be no way to configure the application to send it via one of the three different protocol variations (unless we put a delimiter in the address field, but I don't think that's a wise choice). + DONE Quoting: destTransportAddress. This parameter may also be used by the transport subsystem to route the message to the appropriate Transport Model. This document specifies the snmpTLSDomain, the Isn't that exactly why we have three domains? Becaise the domain is used by the transport subsystem to decide which transport model to use? So should there be ONE domain the subsystem needs to know about, since all three combinations go to the same transport model? Does the transport model have nay way to determine which combionation to use, or does it have to rely on the domain to determine that? + WH: I've deleted the "This parameter..." sentence as I agree it doesn't make much sense. + DONE Quoting: tmStateReference: A handle/reference to tmSecurityData to be used by the security model. I believe this is incorrect. This is a reference to the tmState cache, not the security cache. + WH: you're right (I checked 5590 to be sure) * DONE Section 4.4.1 Actually, tlstm does have specific responsibilities. It creates the tmSecurityName via the mapping tables, and creates the tmSessionID. This is the place where those discussions really belong. s/first prior/prior/ + WH: I've updated the section to match what is in 5592 better. Please let me know if you find anything problematic with the near word-to-word copy from 5592. * DONE Section 5.1.1 + DONE Quoting: DTLS is significantly different in terms of session handling than ^ over UDP + ANSWERED Quoting: 2) The TLS Transport Model queries the LCD using the transport parameters (source and destination addresses and ports) to determine if a session already exists and its tlsSnmpSessionID. So there can be only one DTLS session that exists between two endpoints? + WH: where endpoints is srcaddr/srcport/dstaddr/dstport, yes. As is described as a MUST in multiple places. There cannot be two with different security principals or different securityLevels? + WH: where endpoints is srcaddr/srcport/dstaddr/dstport, yes. As is described as a MUST in multiple places. I think that contradicts something I read earlier about securityLevels and mappings to crypto suites. + WH: I don't believe so. Let me know if you find a conflict. Which table in the LCD does this query? Is the table only for DTLS/UDP sessions? + WH: It's an implementation dependent cache of data. It doesn't need to be referenced by external modules so is not defined concretely in the document. + DONE s/through what session/through which session/ + ANSWERED Quoting: If a matching entry in the LCD does not exist then the message is passed to DTLS for processing without a corresponding tlsSnmpSessionID. The incoming packet may result in a new session being established if the receiving entity is acting as a DTLS server. If DTLS returns success then stop processing of this message. If DTLS returns an error then and the the tlstmSessionNoAvailableSessions counter and stop processing the message. If I read this correctly, then whether DTLS returns success or returns an error, we stop processing the message at this point. What is DTLS doing with this packet we pass it? Does it return something to us other than an error code? I have difficulty following the purpose and logic in this paragraph. + WH: The point behind the paragraph is less clear after I removed the longer multi-paragraph version of it that explained in greater detail what DTLS needed to do internally. Functionally, DTLS still needs to process messages even if we can't determine why they've arrived. Either way: yes, processing will stop from the transport's point of view regardless of whether the packet triggers an error or is successfully processed (ie, a TLS Hello message will result in a success and a garbage packet will result in an error; in both cases, there is nothing for SNMP to act upon).. + DONE The last sentence needs to be rewritten. I am not sure what it meant to say. WH: rewritten to "If DTLS returns an error then increment the tlstmSessionNoAvailableSessions counter and stop processing the message." + DONE "rogue" is used withiout being defined. Is this a malicious message? Can you proivde a reference so I can understand what a rogue message is? Is this an SNMP message? I don't recognize the term from other SNMP documents. + WH: changed to "An entry may not exist, however, if a message not intended the SNMP entity was routed to it by mistake." + ANSWERED I didn't review the DTLS spec. Is it accurate that DTLS receives a packet, passes it to the application for demultiplexing, which passes it back to DTLS to create a session(?), then DTLS passes it back to the application, to record the sessionID, and then the application passes it back to DTLS for decryption, which then passses the decrypted packet to the application? Boy, so much for layering. + WH: It's implementation specific. I know for a fact that there are two different ways this is handled in the wild (currently; we're boiling down to the second one I hope): +-------------------+ v | +-----+ +-----+ +-------------+ +------+ | Net | --> | UDP | --> | Application | --> | DTLS | +-----+ +-----+ +-------------+ +------+ Or: +-----+ +-----+ +------+ +-------------+ | Net | --> | UDP | --> | DTLS | --> | Application | +-----+ +-----+ +------+ +-------------+ IE, your description doesn't match the first that you were trying to match against. The application may receive a raw UDP packet which needs processing by DTLS. Note that DTLS doesn't contain a session identifier within it, which is why we're trying to define one for the first case where DTLS won't be able to cache keys and other information based on addr/port combinations. You *don't* want DTLS trying every key it has to figure out which is the right one to use when decrypting a packet. Either way, TLS doesn't have a pretty application architecture like SNMP does. It merely describes the protocol bits. They seem to prefer short, concise documents unlike the SNMP WGs. * DONE Section 5.1.2 singular? would single work here - just one at a time? or is the usage of singular that means outstanding or unusual - does singular have a special meaning in the DTLS world? If so, then the definition should be discussed. + WH: I'm not sure the sentence reads as well with "single", but I'm not a great linguist so I'll assume your wording is better and I've changed it ;-) * DONE Section 5.2 + DONE you don't check that the tmStateReference refers to a cache containing the required values. This is something the WG decided needed to be done. + WH: added + DONE you don't extract the transportDomain from tmStateReference, but you will need that to know whuch security mechansism and which underlying transport to use if you have to establish a new session. + WH: tmTransportDomain added + DONE I notice that the snmpSshtmSessionNoSessions and tlstmSessionNoAvailableSessions counters have different name contructions, but count the same types of errors. Can we contruct the names in a similar fashion to make it easier for operators? + WH: MIB objects changed to match the SSH object structures + DONE Quoting: 3) If tmSameSecurity is false and tmSessionID refers to a session that is no longer available then an implementation SHOULD open a new session using the openSession() ASI (described in greater detail in step 4b). An implementation MAY choose to return an error to the calling module and stop processing of the message. Shouldn't we have standardization in this handling? Why do we need to allow implementers to return an error rather than trying to open a new session? Which error counter gets returned if the implementation makes this choice? Would this choice be better inside the openSession() processing? + WH: I believe it's impossible to guarantee that a new session can be opened. So, yes, they SHOULD try if they can on behalf of the client but either way the client may have to deal with errors. Note that the SSH document actually fails to catch this condition entirely: the EOP could select a session which can't be used (ie, if the SSH library has lost or dropped the session but the application hasn't yet been made aware of it). Once selected the SSHTM assumes the session is valid and never does error checking on whether the message could actually be sent over it. I've made the snmpTlstmSessionNoSessions be returned if the error-route is selected. + ANSWERED what does an undefined tmSessionID look like? + WH: that's implementation dependent as the format of the sessionID is implementation dependent. + DONE Quoting: 4) If tmSessionID is undefined, then use tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel to see if there is a corresponding entry in the LCD suitable to send the message over. Does this decision consider DTLS vs TLS, and UDP vs TCP vs SCTP? Domain isn't mentioned. + WH: I've added tmTransportDomain + ANSWERED Quoting: Section 5.3). Implementations MAY wish to offer message buffering to prevent redundant openSession() calls for the same cache entry. I am not sure what type of message buffering you refer to here. How will you get redundant openSession() calls? + WH: in a threaded application, for example, or even a socket based application it is entirely possible for a management application to issue multiple command generator messages to be sent to the same destination before the TLS processing of a session has completed. Buffering these for the same session would be wise. + DONE In 5592, if openSession fails, the tmtateReference being created is also discarded. Should it be discarded here? + WH: discard note added. * DONE Section 5.3. Establishing a Session + DONE Quoting: The TLS Transport Model provides the following primitive to establish a new (D)TLS session (previously discussed in Section 5.3): I don't think this was previously discussed in section 5.3, since we just entered section 5.3. + WH: good point. huh. + DONE "This MAY be done automatically" - you explicitly exampt Report and Response messages. rfc5590 deliberately did not sayt these OK, these not, but used "applications that initiate, such as" because SNMPv3 is designed to allow new applications to be developed in the future. + WH: changed to "This MAY be done automatically for an SNMP application that initiates a transaction, such as a command generator, a notification originator, or a proxy forwarder." which matches 5592 better. + WONTDO I am conmcerned to see the selection of cyphersuites discussed in the Elements of Procedure. This is something that I think should be out of scope for an ISMS document. We are supposed to be using the existing underlying secure transport, without the TM having any knowldege of the details of the security. Which cyphersuites get used should be configured for the TLS layer, and the TM EOP should be blissfully unaware of this TLS-layer configuration. If the TM needs to be pre-configured with a list of the acceptable certificates and ciphersuites, then this TM misses the point of ISMS. + WH: We don't talk about select of ciphersuites other than mentioning that it has to happen and mentioning where in the process it happens. We make no statements about good vs bad, priority ordering, policy selection knobs, etc. All we say is you have to do it at this point in the process and that the selection comes from implementation-specific configuration because *we're not* doing it. + WONTDO I think trying to support multiple security levels is a mistake. If you don't want security, don't use a secure transport. Duh! We have multiple security level support in USM. I am unaware that anybody actually uses multiple securitylevels in the real world, except for very specific things like auto-discovery. You don't need that supported in every TM. We don't support it in SSHTM, and we don't need it here. Let's not add complexity for the sake of adding complexity. Nobody NEEDS this. Implementations can choose to supplement the standard with as much complxiety as their customers demand, but we don't need that complexity turned into a MUST-implement requirement of the standard. The standard should be simple enough to encourage implementers to implement a standard baseline to achieve interoperability. Stop adding unnecessary complexity. + WH: I'm more than sure real world users are not using encryption in USM because they don't need it and don't want the hit. I many users of my SNMP stack that don't want encryption turned on all the time. I know this is also true for IPsec and likely for TLS (though I'm less familiar with other TLS protocols and their deployed usage). The positives far outweigh the minor complexity added. + WONTDO Quoting: - "tlstmSessionOpenErrors is incremented, an error indication is returned, and processing stops. If the session failed to open because the presented server certificate was unknown or invalid then the tlstmSessionUnknownServerCertificate or tlstmSessionInvalidServerCertificates MUST be incremented and a tlstmServerCertificateUnknown or tlstmServerInvalidCertificate notification SHOULD be sent as appropriate. Reasons for server certificate invalidation includes, but is not limited to, cryptographic validation failures and an unexpected presented certificate identity." "includes but is not limoted to"? So different implementations are allowed to choose which conditions they want to count in their counter? So how do you compare these across implementations? Where is the interoperability? How can an operator use this information effectively if the implementation can choose what gets counted? A standard should be CLEAR and UNAMBIGUOUS. Again, I think you are getting way too detailed in the knowledge of the TLS implementation. + WH: As stated previously, we can't enumerate every possible case why a TLS stack may not be able to open a session. That doesn't make the counter not valuable. We label the common cases but it's well beyond our scope to do error accounting of the (D)TLS protocols (which may even change). I think we strike a good balance of being on the line between too much and too little. We don't say how TLS works internally, but we acknowledge that it uses cryptography and can generate errors associated with it. + ANSWERED step a) requires preconfiguration. Did I miss something? Is this no longer the ISMS WG, which was trying to minimize or eliminate preconfiguration for SNMP-specific credentials and parameters, and just use what was already available from the lower layer secure transport? Complexity, complexity, complexity. + WH: You didn't miss anything. SSH requires pre-configuration too. + DONE Quoting: "b) The (D)TLS client side of the connection MUST verify that authenticated identity of the (D)TLS server's certificate is the certificate." I'm not sure I understand what this says. "is the certificate"? what certificate? The one we're checking? + WH: Thanks for catching the editing mistake. It should have been the "expected certificate" (in the same way that SSH has a known_hosts file to ensure the SSH server's presented certificate is the expected one). I've added "presented" as well as "expected" to make the sentence clearer. + WONTDO s/determine the if the presented identity matches the/???/ + WH: ???s aren't a good replacement in that sentence; It makes sense to me as is and you don't describe how you're confused so it's hard to fix your issue with it. + DONE Quoting: "4) The (D)TLS-specific session identifier is passed to the TLS Transport Model and associated with the tmStateReference cache entry to indicate that the session has been established successfully and to point to a specific (D)TLS session for future use." does this mean "set the sessionID in the tmStateReference cache to the session identifier passed to tlstm from TLS? + WH: Yes and good point. I've stated this more clearly directly now: "The (D)TLS-specific session identifier is set in the sessionID of the tmStateReference passed to the TLS Transport Model to indicate that the session has been established successfully and to point to a specific (D)TLS session for future use." + ANSWERED Quoting: "Servers that wish to support multiple principals at a particular port" Does this really have to be part of TLSTM? We are defining a standard baseline for interoperability. Why we do we even need to know if the implementers choose to support some additional complexity in the TLS layer? + WH: It's important that we define the way two implementations should interact. Some people believe (myself included) that receiving notifications sent to multiple recipients at a notification receiver is an important problem to solve, and this paragraph specifies how it SHOULD be done. + DONE In SSHTM, we have a sessionscloses counter; is ti deliberate that we don't bother to increment one for closed tls sessions? + WH: I've added an incrementation of the snmpTlstmSessionCloses counter. Return question: What was the rational for incrementing the counter even in a failure case (ie, no session exists)? Seems kinda odd, though I duplicated it to remain consistent. + DONE In SSHTM, closing a session only requires the sessionID from the tmStateReference; In TLSTM, you pass in a whole tmStateReference. Is this really necessary? + WH: I've changed it so that only a tmSessionID is passed. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Dec 24 06:44:59 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED8528B797; Thu, 24 Dec 2009 06:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vd2dYFXHQ9S; Thu, 24 Dec 2009 06:44:59 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B9DF33A6851; Thu, 24 Dec 2009 06:44:58 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 27133980A5; Thu, 24 Dec 2009 06:44:41 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 24 Dec 2009 06:44:40 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: postmaster@ietf.org Subject: [Isms] mailing list issues/warning/test X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 24 Dec 2009 14:44:59 -0000 Yesterday I mailed a reply to David H to the list but I got a bounce message from isms@core3.amsl.com saying that I was sending it from an unsubscribed address. I sent it from the same address I've always used (this one) and one which is subscribed. (The same one that I replied to Tom with two days ago). I'm not sure what's been changing with the IETF list server, but just a word of caution: look out for this problem and make sure your messages get through. The archive can be checked at: http://www.ietf.org/mail-archive/web/isms/current/maillist.html -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Dec 24 06:49:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D803A69DA for ; Thu, 24 Dec 2009 06:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 JxvM2gq+O-vd for ; Thu, 24 Dec 2009 06:49:37 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 36B903A65A5 for ; Thu, 24 Dec 2009 06:49:37 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 95292980AD; Thu, 24 Dec 2009 06:49:19 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <007401ca8484$2e2c86e0$0601a8c0@allison> Date: Thu, 24 Dec 2009 06:49:19 -0800 In-Reply-To: <007401ca8484$2e2c86e0$0601a8c0@allison> (tom petch's message of "Thu, 24 Dec 2009 11:29:25 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM 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: Thu, 24 Dec 2009 14:49:38 -0000 >>>>> On Thu, 24 Dec 2009 11:29:25 +0100, "tom.petch" said: tp> - when the client is authenticated, it is as part of re-negotiation tp> so that is the environment I see us going into; hence the need to say tp> more. During the last IETF meeting it was decided that we shouldn't say anything in particular about the existing TLS renegotiation problems as they're out of scope. Mentioning it seems like an obvious thing to, but in the end: the problem is known and is being handled by the base protocol working group. It's not our job to document the potential flaws in the other protocol. Nor is it our job to document every possibly insecure method of implementing the base protocol. If we went down that road there are actually a number of things we might have to list. Consider the SSHTM document. Why didn't we say in it that SSH version 1 is an insecure version of the protocol and shouldn't be used? It's fundamentally the same problem, but much older. Should we document every potential TLS issue people may run into? I don't think that's our job. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Dec 24 06:56:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5483A69F4 for ; Thu, 24 Dec 2009 06:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+ocRMc1N6q5 for ; Thu, 24 Dec 2009 06:56:50 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BFC833A690F for ; Thu, 24 Dec 2009 06:56:49 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 33710980DB; Thu, 24 Dec 2009 06:56:32 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> <007301ca8484$2cfe6720$0601a8c0@allison> Date: Thu, 24 Dec 2009 06:56:31 -0800 In-Reply-To: <007301ca8484$2cfe6720$0601a8c0@allison> (tom petch's message of "Thu, 24 Dec 2009 11:03:30 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM 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: Thu, 24 Dec 2009 14:56:50 -0000 >>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" said: tp> The text you quote is fine; I am concerned about an earlier problem, tp> getting a certificate to validate in the first place, about which tp> more should be said in Appendix B, such as: Would the following statement, added to the a) bullet in 5.3 meet your needs? "The (D)TLS server MUST request and expect a certificate from the client and MUST NOT accept messages over the (D)TLS session until the client has sent one." tp> "The (D)TLS client initiates the handshake protocol with a ClientHello tp> message but the server can request a handshake, initial or as part tp> of a re-negotiation, with a HelloRequest" It's been decided that we can't go into that much detail about the TLS protocol. IE, listing the "HelloRequest" message type is too much (and in fact, I just removed references to other message types from the document at the request of the WG). We should be stating things more generically than that. I agree we need to state absolutely that the client must present a certificate and the server must expect one, which I tried to craft into the above sentence. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Thu Dec 24 07:01:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1A53A6A03 for ; Thu, 24 Dec 2009 07:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTkOyQ+IF-Aq for ; Thu, 24 Dec 2009 07:01:23 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 9C1BA3A6855 for ; Thu, 24 Dec 2009 07:01:23 -0800 (PST) Received: from OMTA23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA07.westchester.pa.mail.comcast.net with comcast id M2c01d00E1c6gX857317Pk; Thu, 24 Dec 2009 15:01:07 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA23.westchester.pa.mail.comcast.net with comcast id M3Ae1d002284sdk3j3AeYS; Thu, 24 Dec 2009 15:10:38 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <000901ca8005$ffe88220$0601a8c0@allison><007401ca8484$2e2c86e0$0601a8c0@allison> Date: Thu, 24 Dec 2009 10:01:05 -0500 Message-ID: <0bbc01ca84a9$eafa6ba0$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqEqEiMLidZ9p4RQZC/dIKZzEO6RQAAZ5rQ Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM 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: Thu, 24 Dec 2009 15:01:24 -0000 +1 dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Thursday, December 24, 2009 9:49 AM > To: tom.petch > Cc: isms@ietf.org > Subject: Re: [Isms] Updated TLSTM document > > >>>>> On Thu, 24 Dec 2009 11:29:25 +0100, "tom.petch" > said: > > tp> - when the client is authenticated, it is as part of > re-negotiation > tp> so that is the environment I see us going into; hence the > need to say > tp> more. > > During the last IETF meeting it was decided that we shouldn't say > anything in particular about the existing TLS renegotiation > problems as > they're out of scope. Mentioning it seems like an obvious > thing to, but > in the end: the problem is known and is being handled by the base > protocol working group. It's not our job to document the potential > flaws in the other protocol. Nor is it our job to document every > possibly insecure method of implementing the base protocol. > If we went > down that road there are actually a number of things we might have to > list. > > Consider the SSHTM document. Why didn't we say in it that > SSH version 1 > is an insecure version of the protocol and shouldn't be used? It's > fundamentally the same problem, but much older. Should we document > every potential TLS issue people may run into? I don't think > that's our > job. > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From cfinss@dial.pipex.com Thu Dec 24 12:36:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081933A6900 for ; Thu, 24 Dec 2009 12:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.497, 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 gAzKQAfpSKi7 for ; Thu, 24 Dec 2009 12:36:06 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D97E03A68B6 for ; Thu, 24 Dec 2009 12:36:05 -0800 (PST) X-Trace: 314953911/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAIlfM0s+vGRy/2dsb2JhbACCXiqFMIhmw3UKhCkEgWU X-IronPort-AV: E=Sophos;i="4.47,451,1257120000"; d="scan'208";a="314953911" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 20:35:45 +0000 Message-ID: <012101ca84d0$5da15a80$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <000901ca8005$ffe88220$0601a8c0@allison><007401ca8484$2e2c86e0$0601a8c0@allison> Date: Thu, 24 Dec 2009 20:00:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 20:36:07 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Thursday, December 24, 2009 3:49 PM > >>>>> On Thu, 24 Dec 2009 11:29:25 +0100, "tom.petch" said: > > tp> - when the client is authenticated, it is as part of re-negotiation > tp> so that is the environment I see us going into; hence the need to say > tp> more. > > During the last IETF meeting it was decided that we shouldn't say > anything in particular about the existing TLS renegotiation problems as > they're out of scope. Mentioning it seems like an obvious thing to, but > in the end: the problem is known and is being handled by the base > protocol working group. It's not our job to document the potential > flaws in the other protocol. Nor is it our job to document every > possibly insecure method of implementing the base protocol. If we went > down that road there are actually a number of things we might have to > list. > > Consider the SSHTM document. Why didn't we say in it that SSH version 1 > is an insecure version of the protocol and shouldn't be used? It's > fundamentally the same problem, but much older. Should we document > every potential TLS issue people may run into? I don't think that's our > job. I think that you misconstrue my point. When client certificates are used, the commonest way of using them is re-negotiation (based on posts to the TLS list and other places). This is current technology, accepted and used (I would not put SSH v1 in that category). SNMP TLS servers must request client certificates and must not re-negotiate to do so, not because a loophole that will in all probability be fixed before this I-D hits the streets, but because this technique will have the TLS client sending SNMP messages before the client certificate has arrived - there is nothing to stop it. So rather than having the first n SNMP messages fail because there is no client certificate from which to generate a securityName, ban this technique for this application. We must not ban renegotiation because it is needed; TLS recommends that security parameters are renegotiated every 24 hours, and SNMP sessions will last longer than that. Tom Petch > Wes Hardaker > Cobham Analytic Solutions From cfinss@dial.pipex.com Thu Dec 24 12:36:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CAD3A68B6; Thu, 24 Dec 2009 12:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, 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 5M128sOFeq45; Thu, 24 Dec 2009 12:36:07 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 792413A68AA; Thu, 24 Dec 2009 12:36:06 -0800 (PST) X-Trace: 314953914/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAIlfM0s+vGRy/2dsb2JhbACCXiqFMIhmw3UKhCkEgWU X-IronPort-AV: E=Sophos;i="4.47,451,1257120000"; d="scan'208";a="314953914" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 20:35:47 +0000 Message-ID: <012201ca84d0$5e93f7e0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Thu, 24 Dec 2009 20:31:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: postmaster@ietf.org Subject: Re: [Isms] mailing list issues/warning/test X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 20:36:08 -0000 Wes Try using IPv4, that protocol that's almost as obsolete as SSHv1:-) Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: Cc: Sent: Thursday, December 24, 2009 3:44 PM Subject: [Isms] mailing list issues/warning/test > > Yesterday I mailed a reply to David H to the list but I got a bounce > message from isms@core3.amsl.com saying that I was sending it from an > unsubscribed address. I sent it from the same address I've always used > (this one) and one which is subscribed. (The same one that I replied to > Tom with two days ago). I'm not sure what's been changing with the IETF > list server, but just a word of caution: look out for this problem and > make sure your messages get through. The archive can be checked at: > > http://www.ietf.org/mail-archive/web/isms/current/maillist.html > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Thu Dec 24 12:36:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E4F3A69DE for ; Thu, 24 Dec 2009 12:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 G8ll8gD5lG9U for ; Thu, 24 Dec 2009 12:36:08 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 41E2E3A68AA for ; Thu, 24 Dec 2009 12:36:08 -0800 (PST) X-Trace: 314953916/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAIlfM0s+vGRy/2dsb2JhbACCXiqFMIhmw3UKhCkEgWU X-IronPort-AV: E=Sophos;i="4.47,451,1257120000"; d="scan'208";a="314953916" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 20:35:49 +0000 Message-ID: <012301ca84d0$5f5d6260$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <000901ca8005$ffe88220$0601a8c0@allison><20091221162244.GG15104@elstar.local><007301ca8484$2cfe6720$0601a8c0@allison> Date: Thu, 24 Dec 2009 20:31:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 20:36:09 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Thursday, December 24, 2009 3:56 PM > >>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" said: > > tp> The text you quote is fine; I am concerned about an earlier problem, > tp> getting a certificate to validate in the first place, about which > tp> more should be said in Appendix B, such as: > > Would the following statement, added to the a) bullet in 5.3 meet your > needs? > > "The (D)TLS server MUST request and expect a certificate from the client > and MUST NOT accept messages over the (D)TLS session until the client > has sent one." Yes, that addresses my main concern; perhaps it would be better to say 'until the server has received one' but I leave that up to you. > tp> "The (D)TLS client initiates the handshake protocol with a ClientHello > tp> message but the server can request a handshake, initial or as part > tp> of a re-negotiation, with a HelloRequest" > > It's been decided that we can't go into that much detail about the TLS > protocol. IE, listing the "HelloRequest" message type is too much (and > in fact, I just removed references to other message types from the > document at the request of the WG). We should be stating things more > generically than that. I agree we need to state absolutely that the > client must present a certificate and the server must expect one, which > I tried to craft into the above sentence. I find the existing sentence "Only the (D)TLS client can initiate the handshake protocol. " --- well, not right - no need to mention TLS messages but I think we should hint at the server's ability to kick things off. Perhaps "The (D)TLS client initiates the handshake protocol while the (D)TLS server can ask the client to do so." Tom Petch > Wes Hardaker > Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Sun Dec 27 05:51:22 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF043A6832 for ; Sun, 27 Dec 2009 05:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTN7cObFz32N for ; Sun, 27 Dec 2009 05:51:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DEC833A6805 for ; Sun, 27 Dec 2009 05:51:21 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F40DEC001B; Sun, 27 Dec 2009 14:51:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OueXyjm5PcKY; Sun, 27 Dec 2009 14:51:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7124C0004; Sun, 27 Dec 2009 14:51:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5CE65FA2D03; Sun, 27 Dec 2009 14:50:57 +0100 (CET) Date: Sun, 27 Dec 2009 14:50:57 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091227135057.GB7209@elstar.local> Mail-Followup-To: Wes Hardaker , "tom.petch" , "isms@ietf.org" References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> <007301ca8484$2cfe6720$0601a8c0@allison> 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 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: Sun, 27 Dec 2009 13:51:23 -0000 On Thu, Dec 24, 2009 at 03:56:31PM +0100, Wes Hardaker wrote: > >>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" said: > > tp> The text you quote is fine; I am concerned about an earlier problem, > tp> getting a certificate to validate in the first place, about which > tp> more should be said in Appendix B, such as: > > Would the following statement, added to the a) bullet in 5.3 meet your > needs? > > "The (D)TLS server MUST request and expect a certificate from the client > and MUST NOT accept messages over the (D)TLS session until the client > has sent one." To be more precise, s/messages/SNMP messages/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Dec 27 05:57:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421E93A687E for ; Sun, 27 Dec 2009 05:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWhcCNIg7sgK for ; Sun, 27 Dec 2009 05:57:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4D00A3A6805 for ; Sun, 27 Dec 2009 05:57:18 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAA66C0006; Sun, 27 Dec 2009 14:56:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yr9HJN8HEPPP; Sun, 27 Dec 2009 14:56:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC301C0004; Sun, 27 Dec 2009 14:56:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 68927FA2E0E; Sun, 27 Dec 2009 14:56:55 +0100 (CET) Date: Sun, 27 Dec 2009 14:56:55 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20091227135655.GA7255@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <000901ca8005$ffe88220$0601a8c0@allison> <007401ca8484$2e2c86e0$0601a8c0@allison> <012101ca84d0$5da15a80$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012101ca84d0$5da15a80$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Updated TLSTM 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: Sun, 27 Dec 2009 13:57:19 -0000 On Thu, Dec 24, 2009 at 08:00:47PM +0100, tom.petch wrote: > When client certificates are used, the commonest way of using them is > re-negotiation (based on posts to the TLS list and other places). This > is current technology, accepted and used (I would not put SSH v1 > in that category). > > SNMP TLS servers must request client certificates and must not > re-negotiate to do so, not because a loophole that will in all > probability be fixed before this I-D hits the streets, but because > this technique will have the TLS client sending SNMP messages > before the client certificate has arrived - there is nothing to stop it. > So rather than having the first n SNMP messages fail because there > is no client certificate from which to generate a securityName, > ban this technique for this application. > > We must not ban renegotiation because it is needed; TLS recommends > that security parameters are renegotiated every 24 hours, and SNMP > sessions will last longer than that. Speaking as a technical contributor, I think the proposed addition to 5.3 makes it clear that SNMP messages arriving before the mutual authentication is complete are not processed. I do not think we need to go into the (D)TLS specifics how to achieve mutual authentication or how to minimize the risk of getting SNMP messages before mutual authentication is complete. /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 Dec 28 07:29:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6413A686D for ; Mon, 28 Dec 2009 07:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pql8xb3Rujru for ; Mon, 28 Dec 2009 07:29:15 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A12A53A687E for ; Mon, 28 Dec 2009 07:29:15 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 71CB798091; Mon, 28 Dec 2009 07:28:55 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> <007301ca8484$2cfe6720$0601a8c0@allison> <20091227135057.GB7209@elstar.local> Date: Mon, 28 Dec 2009 07:28:54 -0800 In-Reply-To: <20091227135057.GB7209@elstar.local> (Juergen Schoenwaelder's message of "Sun, 27 Dec 2009 14:50:57 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 15:29:16 -0000 >>>>> On Sun, 27 Dec 2009 14:50:57 +0100, Juergen Schoenwaelder said: JS> To be more precise, s/messages/SNMP messages/ Will do. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Dec 28 07:30:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B2C3A6968 for ; Mon, 28 Dec 2009 07:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgO12484xaHp for ; Mon, 28 Dec 2009 07:30:33 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id E292D3A68BB for ; Mon, 28 Dec 2009 07:30:32 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A490C98091; Mon, 28 Dec 2009 07:30:13 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> <007301ca8484$2cfe6720$0601a8c0@allison> <20091227135057.GB7209@elstar.local> Date: Mon, 28 Dec 2009 07:30:13 -0800 In-Reply-To: <20091227135057.GB7209@elstar.local> (Juergen Schoenwaelder's message of "Sun, 27 Dec 2009 14:50:57 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 15:30:34 -0000 >>>>> On Sun, 27 Dec 2009 14:50:57 +0100, Juergen Schoenwaelder said: JS> On Thu, Dec 24, 2009 at 03:56:31PM +0100, Wes Hardaker wrote: >> >>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" said: >> tp> The text you quote is fine; I am concerned about an earlier problem, tp> getting a certificate to validate in the first place, about which tp> more should be said in Appendix B, such as: >> >> Would the following statement, added to the a) bullet in 5.3 meet your >> needs? >> >> "The (D)TLS server MUST request and expect a certificate from the client >> and MUST NOT accept messages over the (D)TLS session until the client >> has sent one." JS> To be more precise, s/messages/SNMP messages/ This is the final sentence that I added: The (D)TLS server MUST request and expect a certificate from the client and MUST NOT accept SNMP messages over the (D)TLS session until the client has sent one and it has been authenticated. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Mon Dec 28 07:46:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226783A68BB for ; Mon, 28 Dec 2009 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 0seIrUwepEN7 for ; Mon, 28 Dec 2009 07:46:09 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 07E873A687B for ; Mon, 28 Dec 2009 07:46:08 -0800 (PST) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Nf4E1d0041swQuc5AflrSH; Mon, 28 Dec 2009 15:45:51 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA15.westchester.pa.mail.comcast.net with comcast id NfnK1d008284sdk3bfnKQm; Mon, 28 Dec 2009 15:47:20 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <000901ca8005$ffe88220$0601a8c0@allison><20091221162244.GG15104@elstar.local><007301ca8484$2cfe6720$0601a8c0@allison><20091227135057.GB7209@elstar.local> Date: Mon, 28 Dec 2009 10:45:49 -0500 Message-ID: <0c6001ca87d4$d458b400$6601a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqH0qjlBYTTB61gQ2m1UeBW7REDPQAAhA/g Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 15:46:10 -0000 "sent one" is ambiguous. Does it have to send a certificate or an SNMP message? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Monday, December 28, 2009 10:30 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] Updated TLSTM document > > >>>>> On Sun, 27 Dec 2009 14:50:57 +0100, Juergen > Schoenwaelder said: > > JS> On Thu, Dec 24, 2009 at 03:56:31PM +0100, Wes Hardaker wrote: > >> >>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" > said: > >> > tp> The text you quote is fine; I am concerned about an > earlier problem, > tp> getting a certificate to validate in the first place, about which > tp> more should be said in Appendix B, such as: > >> > >> Would the following statement, added to the a) bullet in > 5.3 meet your > >> needs? > >> > >> "The (D)TLS server MUST request and expect a certificate > from the client > >> and MUST NOT accept messages over the (D)TLS session until > the client > >> has sent one." > > JS> To be more precise, s/messages/SNMP messages/ > > This is the final sentence that I added: > > The (D)TLS server MUST request and expect a certificate from the > client and MUST NOT accept SNMP messages over the (D)TLS session until > the client has sent one and it has been authenticated. > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Mon Dec 28 07:47:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5354D3A687B for ; Mon, 28 Dec 2009 07:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0JaG9w+tnR9 for ; Mon, 28 Dec 2009 07:47:15 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 68DA13A682A for ; Mon, 28 Dec 2009 07:47:15 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 16C88980AF; Mon, 28 Dec 2009 07:46:56 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <20091221162244.GG15104@elstar.local> <007301ca8484$2cfe6720$0601a8c0@allison> <20091227135057.GB7209@elstar.local> <0c6001ca87d4$d458b400$6601a8c0@china.huawei.com> Date: Mon, 28 Dec 2009 07:46:55 -0800 In-Reply-To: <0c6001ca87d4$d458b400$6601a8c0@china.huawei.com> (David Harrington's message of "Mon, 28 Dec 2009 10:45:49 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 15:47:16 -0000 >>>>> On Mon, 28 Dec 2009 10:45:49 -0500, "David Harrington" said: DH> "sent one" is ambiguous. DH> Does it have to send a certificate or an SNMP message? Ok, then: The (D)TLS server MUST request and expect a certificate from the client and MUST NOT accept SNMP messages over the (D)TLS session until the client has sent a certificate and it has been authenticated. -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Wed Dec 30 07:23:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3766B3A68AB for ; Wed, 30 Dec 2009 07:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AULPyWXi0esG for ; Wed, 30 Dec 2009 07:23:23 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 36EDA3A6844 for ; Wed, 30 Dec 2009 07:23:23 -0800 (PST) X-Trace: 226536658/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.91/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.91 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAKv+Oks+vGRb/2dsb2JhbABAghsXhUSIQcZYCoQnBIFo X-IronPort-AV: E=Sophos;i="4.47,475,1257120000"; d="scan'208";a="226536658" X-IP-Direction: IN Received: from 1cust91.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.91]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Dec 2009 15:23:00 +0000 Message-ID: <000401ca895b$a54a0000$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Joseph Salowey \(jsalowey\)" References: Date: Wed, 30 Dec 2009 11:43:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:23:24 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Wednesday, December 09, 2009 1:25 AM > On Sun, 6 Dec 2009 23:18:53 -0800, "Joseph Salowey (jsalowey)" said: > > JS> I've had a chance to take a look at draft-ietf-isms-dtls-tm-01. In > JS> general I think the document is clear and well done. I have a few > JS> comments below, I haven't gotten all the way through the MIB definition > JS> or the appendices yet. > * DONE Section 5.3 last paragraph > > TLS does define a Server Name Indication extension for identifying the > server you connect to > ([http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt]). Right now > the only type of name defined is host name, which may not be very useful > for this case. New name types could be developed if it would solve a > real problem. > > + I did add a reference to 4366 (Pasi mentioned it as well). > + I found it interesting to note that 5246 is marked as > obsoleting 4366 even though not everything in 4366 is in > 5246 (and in fact 5246 *references* 4366). I suspect a bug > in the RFC status DB. I think it wrong to reference 4366. The definition of extensions is now in RFC5246 while the details of extensions per se - eg SNI - is the updated 4366-bis that Joe refers to so that is the reference we should use. Also, I think that s8.2 is now contradicting this section so 8.2 needs updating with a reference to use of SNI to fix this problem. As Joe says, HostName seems inappropriate while SNI is an excellent fit for our problem. (The trouble with TLS and its documents is that they are frequently written as if HTTP was the only application protocol in the world:-). I think we should ask for a new case in 4366-bis to cover user/principal names. And, while I am at it, I think the reference to RFC4347 is wrong; should be draft-ietf-tls-rfc4347-bis to go with RFC5246. Tom Petch > Wes Hardaker > Cobham Analytic Solutions From cfinss@dial.pipex.com Wed Dec 30 07:23:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF413A6844 for ; Wed, 30 Dec 2009 07:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIpZ+TMNG0zs for ; Wed, 30 Dec 2009 07:23:24 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id C9D853A6893 for ; Wed, 30 Dec 2009 07:23:23 -0800 (PST) X-Trace: 226536672/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.91/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.91 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAKv+Oks+vGRb/2dsb2JhbACCWxeFRIhBxlgKhCcE X-IronPort-AV: E=Sophos;i="4.47,475,1257120000"; d="scan'208";a="226536672" X-IP-Direction: IN Received: from 1cust91.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.91]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Dec 2009 15:23:02 +0000 Message-ID: <000501ca895b$a6ed9de0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: <000901ca8005$ffe88220$0601a8c0@allison> Date: Wed, 30 Dec 2009 15:08:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:23:24 -0000 s1.1 "Either SNMP entity may act as client or as server." This seems to tell me that a CG or NO can be TLS client or TLS server, but 3.3 used to say "(D)TLS sessions may be initiated by (D)TLS clients on behalf of command generators, notification originators, proxy forwarders " which suggests that CG and NO are TLS clients. Please clarify. Tom Petch From cfinss@dial.pipex.com Wed Dec 30 07:23:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0A73A68EA for ; Wed, 30 Dec 2009 07:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 TH2wVAFCGRpI for ; Wed, 30 Dec 2009 07:23:24 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1643A67A2 for ; Wed, 30 Dec 2009 07:23:24 -0800 (PST) X-Trace: 226536679/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.91/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.91 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAKv+Oks+vGRb/2dsb2JhbACCWxeFRIhBxlgKgiOCBAQ X-IronPort-AV: E=Sophos;i="4.47,475,1257120000"; d="scan'208";a="226536679" X-IP-Direction: IN Received: from 1cust91.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.91]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Dec 2009 15:23:03 +0000 Message-ID: <000601ca895b$a784adc0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: <000901ca8005$ffe88220$0601a8c0@allison> Date: Wed, 30 Dec 2009 15:12:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Updated TLSTM document 5.3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:23:25 -0000 5.3 3)b (I think) dbh commented on "determine the if the presented identity matches" to which WH replied "It makes sense to me as is and you don't describe how you're confused so it's hard to fix your issue with it." Yes it makes sense to me, but I would find it more grammatical if it read "determine if the presented identity matches" Tom Petch From cfinss@dial.pipex.com Wed Dec 30 07:23:26 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADB63A6992 for ; Wed, 30 Dec 2009 07:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 4HOoSthotQmP for ; Wed, 30 Dec 2009 07:23:25 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 56A943A68D3 for ; Wed, 30 Dec 2009 07:23:25 -0800 (PST) X-Trace: 226536685/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.91/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.91 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAKv+Oks+vGRb/2dsb2JhbACCWxeFRIhBxlgKhCcE X-IronPort-AV: E=Sophos;i="4.47,475,1257120000"; d="scan'208";a="226536685" X-IP-Direction: IN Received: from 1cust91.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.91]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Dec 2009 15:23:04 +0000 Message-ID: <000701ca895b$a81bbda0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: <000901ca8005$ffe88220$0601a8c0@allison> Date: Wed, 30 Dec 2009 15:15:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Updated TLSTM document 5.3 4 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:23:26 -0000 "4) The (D)TLS-specific session identifier is set in the sessionID of the tmStateReference passed to the TLS Transport Model to indicate that the session has been established successfully and to point to a specific (D)TLS session for future use." sessionID does not exist here (does in TLS:-) And I think that "The (D)TLS-specific session identifier" is tlstmSessionID in which case, please say it explicitly ie "The (D)TLS-specific session identifier, tlstmSessionID, is set .... Tom Petch From ietfdbh@comcast.net Wed Dec 30 07:27:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F003A67F4 for ; Wed, 30 Dec 2009 07:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9wKTGd6rFmk for ; Wed, 30 Dec 2009 07:27:41 -0800 (PST) Received: from QMTA13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 4BE223A67A2 for ; Wed, 30 Dec 2009 07:27:41 -0800 (PST) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA13.westchester.pa.mail.comcast.net with comcast id PSPL1d00D1ei1Bg5DTTNQn; Wed, 30 Dec 2009 15:27:22 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA24.westchester.pa.mail.comcast.net with comcast id PTUk1d00J284sdk3kTUkxW; Wed, 30 Dec 2009 15:28:45 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" , References: <000901ca8005$ffe88220$0601a8c0@allison> <000501ca895b$a6ed9de0$0601a8c0@allison> Date: Wed, 30 Dec 2009 10:27:20 -0500 Message-ID: <004101ca8964$9471eeb0$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: AcqJY/82NJHsZBSiQtKmJGSy+g1RcAAACb4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <000501ca895b$a6ed9de0$0601a8c0@allison> Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:27:42 -0000 Hi, What it should say is "(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP appplications that initiate communications, such as command generators, notification originators, proxy forwarders." RFC3411 architecture allows for new applications to be defined, so the old wording was too restrictive, and, as you point out, the current wording is not restrictive enough. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Wednesday, December 30, 2009 9:08 AM > To: Wes Hardaker; isms@ietf.org > Subject: Re: [Isms] Updated TLSTM document 1.1 > > s1.1 > "Either SNMP entity may act as client or as server." > > This seems to tell me that a CG or NO can be TLS client or > TLS server, but 3.3 > used to say > "(D)TLS sessions may be initiated by (D)TLS clients on behalf of > command generators, notification originators, proxy forwarders " > > which suggests that CG and NO are TLS clients. > > Please clarify. > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Wed Dec 30 07:32:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8B03A68C8 for ; Wed, 30 Dec 2009 07:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_05=-1.11, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JL+0ZmJYJbi for ; Wed, 30 Dec 2009 07:32:24 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 268D03A695A for ; Wed, 30 Dec 2009 07:32:23 -0800 (PST) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA09.westchester.pa.mail.comcast.net with comcast id PSAp1d0051wpRvQ59TY4NJ; Wed, 30 Dec 2009 15:32:04 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA18.westchester.pa.mail.comcast.net with comcast id PTYy1d008284sdk3eTZ7TZ; Wed, 30 Dec 2009 15:33:07 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" , "'Joseph Salowey \(jsalowey\)'" References: <000401ca895b$a54a0000$0601a8c0@allison> Date: Wed, 30 Dec 2009 10:31:53 -0500 Message-ID: <004201ca8965$3c6a1d90$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: AcqJY/82kuanKn88Q3KZv28GC4D06gAANltQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <000401ca895b$a54a0000$0601a8c0@allison> Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:32:25 -0000 Personally, I recommend against having a reference to the bis document. We are in WGLC and don't want publication held up because of a reference to bis. I suggest the wording allow for the changes that are being incorporated into bis, preferably without referencing bis or the discussing any of the details from bis. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Wednesday, December 30, 2009 5:44 AM > To: Wes Hardaker; Joseph Salowey (jsalowey) > Cc: isms@ietf.org > Subject: Re: [Isms] SNI was IsmsReview of > draft-ietf-isms-dtls-tm-01.txt > > ----- Original Message ----- > From: "Wes Hardaker" > Sent: Wednesday, December 09, 2009 1:25 AM > > > On Sun, 6 Dec 2009 23:18:53 -0800, "Joseph Salowey (jsalowey)" > said: > > > > JS> I've had a chance to take a look at > draft-ietf-isms-dtls-tm-01. In > > JS> general I think the document is clear and well done. I > have a few > > JS> comments below, I haven't gotten all the way through > the MIB definition > > JS> or the appendices yet. > > > > > * DONE Section 5.3 last paragraph > > > > TLS does define a Server Name Indication extension for > identifying the > > server you connect to > > > ([http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt]). > Right now > > the only type of name defined is host name, which may not > be very useful > > for this case. New name types could be developed if it > would solve a > > real problem. > > > > + I did add a reference to 4366 (Pasi mentioned it as well). > > + I found it interesting to note that 5246 is marked as > > obsoleting 4366 even though not everything in 4366 is in > > 5246 (and in fact 5246 *references* 4366). I suspect a bug > > in the RFC status DB. > > I think it wrong to reference 4366. The definition of > extensions is now in > RFC5246 while the details of extensions per se - eg SNI - is > the updated > 4366-bis that Joe refers to so that is the reference we should use. > > Also, I think that s8.2 is now contradicting this section so 8.2 needs > updating with a reference to use of SNI to fix this problem. > > As Joe says, HostName seems inappropriate while SNI is an excellent > fit for our problem. (The trouble with TLS and its documents is that > they are frequently written as if HTTP was the only > application protocol > in the world:-). I think we should ask for a new case in > 4366-bis to cover > user/principal names. > > And, while I am at it, I think the reference to RFC4347 is > wrong; should be > draft-ietf-tls-rfc4347-bis > to go with RFC5246. > > Tom Petch > > > Wes Hardaker > > Cobham Analytic Solutions > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Wed Dec 30 08:08:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD563A693E for ; Wed, 30 Dec 2009 08:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUklxtqH7rpl for ; Wed, 30 Dec 2009 08:08:16 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 7ECBB3A6909 for ; Wed, 30 Dec 2009 08:08:16 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 1F40C98062; Wed, 30 Dec 2009 08:07:48 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <000401ca895b$a54a0000$0601a8c0@allison> <004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 08:07:45 -0800 In-Reply-To: <004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 30 Dec 2009 10:31:53 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:08:36 -0000 >>>>> On Wed, 30 Dec 2009 10:31:53 -0500, "David Harrington" said: DH> Personally, I recommend against having a reference to the bis DH> document. We are in WGLC and don't want publication held up because of DH> a reference to bis. I agree; I was trying not to specify which versions of the TLS based protocols we are requiring because I don't think there are any features of the newer ones that we need. There is no reason that future versions of TLS and DTLS couldn't be used as well assuming they didn't introduce a technical conflict with our document, which is unlikely. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:15:23 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314B13A68EA for ; Wed, 30 Dec 2009 08:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW+g6k198SXp for ; Wed, 30 Dec 2009 08:15:22 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 429213A6891 for ; Wed, 30 Dec 2009 08:15:22 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 904E998071; Wed, 30 Dec 2009 08:14:59 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000401ca895b$a54a0000$0601a8c0@allison> Date: Wed, 30 Dec 2009 08:14:55 -0800 In-Reply-To: <000401ca895b$a54a0000$0601a8c0@allison> (tom petch's message of "Wed, 30 Dec 2009 11:43:58 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:15:23 -0000 >>>>> On Wed, 30 Dec 2009 11:43:58 +0100, "tom.petch" said: tp> Also, I think that s8.2 is now contradicting this section so 8.2 needs tp> updating with a reference to use of SNI to fix this problem. You're right about that; I've now updated 8.2 so it should match the text from 5.3 and they should now be consistent (with SNI being strongly recommended). Thanks for pointing that out. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:17:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F803A6A3B for ; Wed, 30 Dec 2009 08:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HowgLJLSF+b3 for ; Wed, 30 Dec 2009 08:17:43 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D250E3A6961 for ; Wed, 30 Dec 2009 08:17:42 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id A7BAD98073; Wed, 30 Dec 2009 08:17:21 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <000501ca895b$a6ed9de0$0601a8c0@allison> <004101ca8964$9471eeb0$0600a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 08:17:17 -0800 In-Reply-To: <004101ca8964$9471eeb0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 30 Dec 2009 10:27:20 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:17:45 -0000 >>>>> On Wed, 30 Dec 2009 10:27:20 -0500, "David Harrington" said: DH> What it should say is DH> "(D)TLS sessions may be initiated by (D)TLS clients on behalf of DH> SNMP appplications that initiate communications, such as command DH> generators, notification originators, proxy forwarders." Good text; thanks! Changed! -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:20:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9626A3A6A44 for ; Wed, 30 Dec 2009 08:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK3ap3ZDbuAC for ; Wed, 30 Dec 2009 08:20:17 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 0CAAC3A6A3C for ; Wed, 30 Dec 2009 08:20:14 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 3B29198074; Wed, 30 Dec 2009 08:19:47 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <000701ca895b$a81bbda0$0601a8c0@allison> Date: Wed, 30 Dec 2009 08:19:43 -0800 In-Reply-To: <000701ca895b$a81bbda0$0601a8c0@allison> (tom petch's message of "Wed, 30 Dec 2009 15:15:16 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document 5.3 4 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:20:20 -0000 >>>>> On Wed, 30 Dec 2009 15:15:16 +0100, "tom.petch" said: tp> And I think that tp> "The (D)TLS-specific session identifier" tp> is tlstmSessionID tp> in which case, please say it explicitly ie tp> "The (D)TLS-specific session identifier, tlstmSessionID, is set .... Actually, it should say the "TLSTM-specific session identifier", which I've changed it to and also added your suggested reference to tlstmSessionID. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:21:06 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CE13A6A36 for ; Wed, 30 Dec 2009 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl8Ku9B542hl for ; Wed, 30 Dec 2009 08:21:04 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id AFFB03A6A3C for ; Wed, 30 Dec 2009 08:21:01 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id A22689805E; Wed, 30 Dec 2009 08:20:39 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <000901ca8005$ffe88220$0601a8c0@allison> <000601ca895b$a784adc0$0601a8c0@allison> Date: Wed, 30 Dec 2009 08:20:34 -0800 In-Reply-To: <000601ca895b$a784adc0$0601a8c0@allison> (tom petch's message of "Wed, 30 Dec 2009 15:12:14 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Updated TLSTM document 5.3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:21:06 -0000 >>>>> On Wed, 30 Dec 2009 15:12:14 +0100, "tom.petch" said: tp> Yes it makes sense to me, but I would find it more grammatical if tp> it read tp> "determine if the presented identity matches" Yes, David and I actually already resolved that particular issue over private email. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:27:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC643A6A40 for ; Wed, 30 Dec 2009 08:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeqqaCU+azql for ; Wed, 30 Dec 2009 08:27:01 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A1B443A6A3E for ; Wed, 30 Dec 2009 08:27:01 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 10BCB98082; Wed, 30 Dec 2009 08:26:37 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20091216105240.GA78492@elstar.local> <062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 08:26:33 -0800 In-Reply-To: <062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> (David Harrington's message of "Wed, 16 Dec 2009 11:14:31 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 30 Dec 2009 16:27:02 -0000 >>>>> On Wed, 16 Dec 2009 11:14:31 -0500, "David Harrington" said: DH> In SSHTM (and in TLSTM), it is possible to attempt to set up entries DH> in advance, creating the tunnels for expected communication. This was DH> deliberate and had consensus of the WG for SSHTM work. I think Eliot DH> was the person who first championed this approach. Eliot wanted to design something to allow for a "callhome" approach. The goal was to let something like a Command Responder call home to a Command Generator and wait for incoming traffic. IE, the CR became the SSH client and the CG the SSH server. Nothing that has been done has necessarily prohibited that approach from happening, but internally all the SNMP stacks don't act that way at all. I'm not saying they couldn't though. DH> To be consistent with this design decision, the point is needed: >> - Can create TLSTM-MIB entries in advance of TARGET-MIB entries >> being created You're implying there that creating the TLSTM-MIB entry opens the connection; it does not. The TARGET-MIB is still the source of the configuration for who to talk with. Any support for call-home type approaches would need to still use the TARGET-MIB as the source of data to make the connection with and is beyond the scope of this work. We don't, however, add anything that prevents this future work from happening (and in fact, by adding the configuration objects we have we're helping support it). Based on the rest of your text, I think you were misunderstanding the discussion surrounding pre-creation and fate-sharing. The discussion was only talking about the fate sharing between the MIB tables and had nothing to do with advanced connection establishment (which, as I said, is out of scope as it should be done in a generic fashion in 'some other MIB module'). -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Dec 30 08:36:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5F93A6A35 for ; Wed, 30 Dec 2009 08:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTr+Bg39fr9K for ; Wed, 30 Dec 2009 08:36:43 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 42FB63A6844 for ; Wed, 30 Dec 2009 08:36:43 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 4119E98082; Wed, 30 Dec 2009 08:36:18 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <000401ca895b$a54a0000$0601a8c0@allison> <004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 08:36:14 -0800 In-Reply-To: (Wes Hardaker's message of "Wed, 30 Dec 2009 08:07:45 -0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:36:44 -0000 >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker said: DH> Personally, I recommend against having a reference to the bis DH> document. We are in WGLC and don't want publication held up because of DH> a reference to bis. WH> I agree; I was trying not to specify which versions of the TLS based WH> protocols we are requiring because I don't think there are any features WH> of the newer ones that we need. There is no reason that future versions WH> of TLS and DTLS couldn't be used as well assuming they didn't introduce WH> a technical conflict with our document, which is unlikely. Whoops. Having re-read everything I realized I was confused about which of the two issues David was talking about. I responded about the DTLS reference but the discussion was surrounding the fact that RFC4366 is the only RFC that documents the server name extension until a new one gets published. Because of that, we'd either have to keep referencing the older one (which doesn't cause any technical problems that I'm aware of) or reference the ID and hope it completes soon. Pasi may have a better idea about how the other document is progressing, but unless it's almost identically timed I don't think it buys us much to reference the ID. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Wed Dec 30 08:45:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DBAC03A6A5C; Wed, 30 Dec 2009 08:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091230164501.DBAC03A6A5C@core3.amsl.com> Date: Wed, 30 Dec 2009 08:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-04.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-04.txt Pages : 64 Date : 2009-12-30 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/SCTP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-30083923.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Wed Dec 30 09:11:47 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6BB3A6A5C for ; Wed, 30 Dec 2009 09:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHCJdmLkTYCi for ; Wed, 30 Dec 2009 09:11:44 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 36A9F3A65A6 for ; Wed, 30 Dec 2009 09:11:44 -0800 (PST) Received: from localhost (unknown [32.152.24.228]) by mail.hardakers.net (Postfix) with ESMTPSA id 39FBA98061 for ; Wed, 30 Dec 2009 09:11:21 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 30 Dec 2009 09:11:17 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 17:11:47 -0000 I'm in the process right now of publishing a -04 copy of the TLSTM draft and it contains all my outstanding edits from the comments received since last call. Note that although last call has long ago finished we've received a number of comments after that cut-off, in part because of Juergen's request for more reviews. Thanks to everyone who has submitted comments about the draft as they've been very helpful. I've already responded to each person with the actions taken based on the comments. I'll leave it up to the working group chairs to decide if there are any outstanding consensus calls that need to be made that I've missed. The only outstanding issues that I think are still being discussed on the list are: 1) The reference to 4366 for the server-name extension. Consensus currently seems that we should leave the reference and not reference the unpublished ID yet that updates that section from 4366. But there aren't many opinions yet. 2) The issue of MIB fate-sharing is still being discussed as well about whether or not the rows in the target add-on tlstmParamsTable should be deleted when a row in the original target table has been deleted. There are two independent in functionality but related in global-picture that we're discussing. I. row creation ordering a) The tlstmParamsTable entry may be created in advance of the row in the snmpTargetParamsTable. [being done now in the MIB DESCRIPTIONs] b) The snmpTargetParamsTable entry must pre-exist before the row in the tlstmParamsTable can be created. The downside of this is that with the snmpTargetParamsTable row in existence before the tlstmParamsTable then the row won't be functional when one of the TLSTM domains are in use until the other row is created. Or worse, per 5.3 step 1) the connection can still be attempted with a different certificate than was expected if another was identified through other configuration (eg, a global device certificate). c) The tlstmParamsTable entry must pre-exist before the row in the snmpTargetParamsTable can be created. This would be adding requirements to the existing TARGET-MIB implementations when the new MIB is supported, which is generally frowned upon. II. row deletion ordering a) The row in tlstmParamsTable is automatically deleted when the corresponding row in the snmpTargetParamsTable is deleted. [being done now in the MIB DESCRIPTIONs] b) The rows in the two tables are independent with respect to deletion. Either can be deleted first (and without both in place, the connection can't be completed). c) One table could require the deletion of a row from the other table. I don't think anyone is vying for this option though. The working group seems somewhat split on this subject but I don't think we have an accurate account of who wants what at this point. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed Dec 30 10:36:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3EE3A6824 for ; Wed, 30 Dec 2009 10:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 LhfR90D8dqFq for ; Wed, 30 Dec 2009 10:36:27 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id A0CC13A659A for ; Wed, 30 Dec 2009 10:36:26 -0800 (PST) Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA07.westchester.pa.mail.comcast.net with comcast id PQVB1d0031YDfWL57Wc7RY; Wed, 30 Dec 2009 18:36:07 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA20.westchester.pa.mail.comcast.net with comcast id PWd91d005284sdk3gWd9cQ; Wed, 30 Dec 2009 18:37:09 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <20091216105240.GA78492@elstar.local><062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 13:36:06 -0500 Message-ID: <006701ca897e$f2d6abc0$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: AcqJbN/vhuGEKI0ISJu6UtrDp5vLQAAC2ksw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Cc: isms@ietf.org Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 30 Dec 2009 18:36:28 -0000 Hi, I assume the information in the tlstmParamsTable and the tlstmAddrTable must be manually configured by an administrator. We usually expect such information to be persistent across reboots. I didn't see text in the MIB that said this. Now back to paragraph 1 of my response. If this is admin-configured, we probably do not want to automatically delete the configuration information and force the admin to re-enter the info. Is this a potential scenario? An admin decides to delete and re-enter a target-mib entry, possibly because he entered the info incorrectly in the first place. But he did enter the corresponding info in tlstmParamsTable correctly. If he deletes the incorrect target-mib info, will the tlstmParams data be automatically discarded, forcing the operator to re-enter the information? tlstmParamsRowStatus says "Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'." There are columns in the TARGET-MIB that could be interpreted as being "corresponding" columns. I think the text here needs to be more explicit about what the corresponding columns are. If columns in this table fate-share with columns in TARGET-MIB when columns there are deleted, then the required corresponding columns for creation should probably include the corresponding target-mib columns. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, December 30, 2009 11:27 AM > To: David Harrington > Cc: 'Juergen Schoenwaelder'; isms@ietf.org > Subject: Re: issue #12: fate sharing > > >>>>> On Wed, 16 Dec 2009 11:14:31 -0500, "David Harrington" > said: > > DH> In SSHTM (and in TLSTM), it is possible to attempt to set > up entries > DH> in advance, creating the tunnels for expected > communication. This was > DH> deliberate and had consensus of the WG for SSHTM work. I > think Eliot > DH> was the person who first championed this approach. > > Eliot wanted to design something to allow for a "callhome" approach. > The goal was to let something like a Command Responder call home to a > Command Generator and wait for incoming traffic. IE, the CR > became the > SSH client and the CG the SSH server. Nothing that has been done has > necessarily prohibited that approach from happening, but > internally all > the SNMP stacks don't act that way at all. I'm not saying > they couldn't > though. > > DH> To be consistent with this design decision, the point is needed: > >> - Can create TLSTM-MIB entries in advance of TARGET-MIB entries > >> being created > > You're implying there that creating the TLSTM-MIB entry opens the > connection; it does not. The TARGET-MIB is still the source of the > configuration for who to talk with. Any support for call-home type > approaches would need to still use the TARGET-MIB as the > source of data > to make the connection with and is beyond the scope of this work. We > don't, however, add anything that prevents this future work from > happening (and in fact, by adding the configuration objects we have > we're helping support it). > > Based on the rest of your text, I think you were misunderstanding the > discussion surrounding pre-creation and fate-sharing. The discussion > was only talking about the fate sharing between the MIB tables and had > nothing to do with advanced connection establishment (which, > as I said, > is out of scope as it should be done in a generic fashion in > 'some other > MIB module'). > -- > Wes Hardaker > Cobham Analytic Solutions > From randy_presuhn@mindspring.com Wed Dec 30 11:08:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52563A68E1 for ; Wed, 30 Dec 2009 11:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3u1ou4vqzCP for ; Wed, 30 Dec 2009 11:08:08 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DF1CF3A67E4 for ; Wed, 30 Dec 2009 11:08:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OdhEloXrg/XHctQFwnEvR/yPkFPoDWyhm4T0MA11rrx2CUCYSALe2vuU5zs7xcyf; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.52.63] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NQ3tb-0003Kn-RO for isms@ietf.org; Wed, 30 Dec 2009 14:07:48 -0500 Message-ID: <000601ca8983$bc4f11a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091216105240.GA78492@elstar.local><062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> <006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 11:10:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40e02484d8426a3295b8bd480557299fff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.52.63 Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 30 Dec 2009 19:08:09 -0000 Hi - > From: "David Harrington" > To: "'Wes Hardaker'" > Cc: > Sent: Wednesday, December 30, 2009 10:36 AM > Subject: Re: [Isms] issue #12: fate sharing ... > tlstmParamsRowStatus says "Until instances of all corresponding > columns are appropriately configured, the value of the corresponding > instance of the tlstmParamsRowStatus column is 'notReady'." > There are columns in the TARGET-MIB that could be interpreted as being > "corresponding" columns. I think the text here needs to be more > explicit about what the corresponding columns are. I would hope that what is intended is "this row of this table". ... > If columns in this table fate-share with columns in TARGET-MIB when > columns there are deleted, then the required corresponding columns for > creation should probably include the corresponding target-mib columns. ... Fate-sharing between tables is, in my opinion, something that should in general be carefully avoided. It produces too many potential surprises, and can even provide a back-door around access control. (should deleting something to which one has access rights cause the deletion of something to which one potentially has no access rights?) Fate-sharing between tables also unnecessarily complicates implementation, since it makes fairly strong assumptions about those tables being implemented in such a way that the module resposible for implementing the one will have access to the data structures of the other, potentially violating the design modularity. Randy From cfinss@dial.pipex.com Wed Dec 30 11:13:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E69E3A68F7 for ; Wed, 30 Dec 2009 11:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHauNE0a8NSi for ; Wed, 30 Dec 2009 11:13:47 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id A81503A68E1 for ; Wed, 30 Dec 2009 11:13:45 -0800 (PST) X-Trace: 226563905/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.226/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.226 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFAKE0O0s+vGTi/2dsb2JhbACCW4VbiEfGOgqEJwQ X-IronPort-AV: E=Sophos;i="4.47,476,1257120000"; d="scan'208";a="226563905" X-IP-Direction: IN Received: from 1cust226.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.226]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Dec 2009 19:13:23 +0000 Message-ID: <004001ca897b$d4999c60$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" , References: <000901ca8005$ffe88220$0601a8c0@allison> <000501ca895b$a6ed9de0$0601a8c0@allison> <004101ca8964$9471eeb0$0600a8c0@china.huawei.com> Date: Wed, 30 Dec 2009 19:12:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 19:13:56 -0000 ----- Original Message ----- From: "David Harrington" Sent: Wednesday, December 30, 2009 4:27 PM Subject: RE: [Isms] Updated TLSTM document 1.1 > What it should say is > "(D)TLS sessions may be initiated by (D)TLS clients on behalf of > SNMP appplications that initiate communications, such as command > generators, notification originators, proxy forwarders." > > RFC3411 architecture allows for new applications to be defined, so the > old wording was too restrictive, and, as you point out, the current > wording is not restrictive enough. > Good What about 1.1, "Either SNMP entity may act as client or as server." in isolation, at the start, still looks misleading to me. Or are you suggesting that this text appears in 1.1 and in 3.3 ? Tom Petch > dbh > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of tom.petch > > Sent: Wednesday, December 30, 2009 9:08 AM > > To: Wes Hardaker; isms@ietf.org > > Subject: Re: [Isms] Updated TLSTM document 1.1 > > > > s1.1 > > "Either SNMP entity may act as client or as server." > > > > This seems to tell me that a CG or NO can be TLS client or > > TLS server, but 3.3 > > used to say > > "(D)TLS sessions may be initiated by (D)TLS clients on behalf of > > command generators, notification originators, proxy forwarders " > > > > which suggests that CG and NO are TLS clients. > > > > Please clarify. > > > > Tom Petch > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > > From ietfdbh@comcast.net Wed Dec 30 11:44:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DAA3A68E4 for ; Wed, 30 Dec 2009 11:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 WG3Db+-pkl1W for ; Wed, 30 Dec 2009 11:44:20 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 954C53A6831 for ; Wed, 30 Dec 2009 11:44:20 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA09.westchester.pa.mail.comcast.net with comcast id PQl31d0010Fqzac59Xk1cA; Wed, 30 Dec 2009 19:44:01 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA08.westchester.pa.mail.comcast.net with comcast id PXk01d009284sdk3UXk0Mw; Wed, 30 Dec 2009 19:44:01 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" , References: <000901ca8005$ffe88220$0601a8c0@allison> <000501ca895b$a6ed9de0$0601a8c0@allison> <004101ca8964$9471eeb0$0600a8c0@china.huawei.com> <004001ca897b$d4999c60$0601a8c0@allison> Date: Wed, 30 Dec 2009 14:43:59 -0500 Message-ID: <006a01ca8988$6efd44d0$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: AcqJhCrJ3SNzXGBBSJOGkCJB9xP4tQABASiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <004001ca897b$d4999c60$0601a8c0@allison> Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 19:44:21 -0000 > What about 1.1, > > "Either SNMP entity may act as client or as server." > in isolation, at the start, still looks misleading to me. > > Or are you suggesting that this text appears in 1.1 and in > 3.3 ? How about "An SNMP entity may act as client or server or both, depending on the SNMP applications supported." dbh From ietfdbh@comcast.net Wed Dec 30 11:48:04 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEED3A67B6 for ; Wed, 30 Dec 2009 11:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 Ka33-ifrOOD0 for ; Wed, 30 Dec 2009 11:48:04 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id D9F9C3A67CF for ; Wed, 30 Dec 2009 11:48:03 -0800 (PST) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA09.westchester.pa.mail.comcast.net with comcast id PWxl1d0061wpRvQ59XnlJ1; Wed, 30 Dec 2009 19:47:45 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA18.westchester.pa.mail.comcast.net with comcast id PXoo1d009284sdk3eXoogV; Wed, 30 Dec 2009 19:48:49 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20091216105240.GA78492@elstar.local><062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com><006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> <000601ca8983$bc4f11a0$6801a8c0@oemcomputer> Date: Wed, 30 Dec 2009 14:47:43 -0500 Message-ID: <006b01ca8988$f43d5c20$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: AcqJg2McECZQFWTkTdKQ/dkyu/rj4QABRx+Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <000601ca8983$bc4f11a0$6801a8c0@oemcomputer> Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 30 Dec 2009 19:48:05 -0000 I also prefer to avoid fate-sharing. If fate-sharing is supported, then I think the fate sharing for creation and deletion should match. Since the tables in question contain security certificate hashes, are there any security considerations related to having orphaned entries? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, December 30, 2009 2:10 PM > To: isms@ietf.org > Subject: Re: [Isms] issue #12: fate sharing > > Hi - > > > From: "David Harrington" > > To: "'Wes Hardaker'" > > Cc: > > Sent: Wednesday, December 30, 2009 10:36 AM > > Subject: Re: [Isms] issue #12: fate sharing > ... > > tlstmParamsRowStatus says "Until instances of all corresponding > > columns are appropriately configured, the value of the corresponding > > instance of the tlstmParamsRowStatus column is 'notReady'." > > There are columns in the TARGET-MIB that could be > interpreted as being > > "corresponding" columns. I think the text here needs to be more > > explicit about what the corresponding columns are. > > I would hope that what is intended is "this row of this table". > ... > > If columns in this table fate-share with columns in TARGET-MIB when > > columns there are deleted, then the required corresponding > columns for > > creation should probably include the corresponding > target-mib columns. > ... > > Fate-sharing between tables is, in my opinion, something that should > in general be carefully avoided. It produces too many > potential surprises, > and can even provide a back-door around access control. > (should deleting > something to which one has access rights cause the deletion > of something > to which one potentially has no access rights?) > > Fate-sharing between tables also unnecessarily complicates > implementation, > since it makes fairly strong assumptions about those tables > being implemented > in such a way that the module resposible for implementing the > one will have > access to the data structures of the other, potentially > violating the design modularity. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From adonati@motorola.com Wed Dec 30 16:01:49 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E5A3A680A for ; Wed, 30 Dec 2009 16:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HXCivGtVq-c for ; Wed, 30 Dec 2009 16:01:48 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 1CC823A67C0 for ; Wed, 30 Dec 2009 16:01:48 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1262217684!14311206!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 28567 invoked from network); 31 Dec 2009 00:01:25 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-11.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 00:01:25 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id nBV01OeZ002455 for ; Wed, 30 Dec 2009 17:01:24 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id nBV01Opg018685 for ; Wed, 30 Dec 2009 18:01:24 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id nBV01OWv018678 for ; Wed, 30 Dec 2009 18:01:24 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Dec 2009 19:01:01 -0500 Message-ID: In-Reply-To: <006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] issue #12: fate sharing Thread-Index: AcqJbN/vhuGEKI0ISJu6UtrDp5vLQAAC2kswAAxE2UA= References: <20091216105240.GA78492@elstar.local><062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> <006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> From: "Donati Andrew-MGIA0477" To: "David Harrington" , "Wes Hardaker" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 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, 31 Dec 2009 00:01:49 -0000 =20 Since persistence is handled by the value of StorageType in each row, we can run into an issue where corresponding rows in each table do not share=20 the same StorageType value. For example, one can be volatile and the other non-volatile.=20 Andy Donati > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, December 30, 2009 1:36 PM > To: 'Wes Hardaker' > Cc: isms@ietf.org > Subject: Re: [Isms] issue #12: fate sharing > Hi, > I assume the information in the tlstmParamsTable and the tlstmAddrTable must be > manually configured by an administrator. We usually expect such information > to be persistent across reboots. I didn't see text in the MIB that said this. > Now back to paragraph 1 of my response. If this is admin-configured, > we probably do not want to automatically delete the configuration > information and force the admin to re-enter the info.=20 > Is this a potential scenario? An admin decides to > delete and re-enter a target-mib entry, possibly because he entered the info > incorrectly in the first place. But he did enter the corresponding info > in tlstmParamsTable correctly. If he deletes the incorrect target-mib info, > will the tlstmParams data be automatically discarded, forcing the operator > to re-enter the information? > tlstmParamsRowStatus says "Until instances of all corresponding=20 > columns are appropriately configured, the value of the corresponding > instance of the tlstmParamsRowStatus column is 'notReady'." > There are columns in the TARGET-MIB that could be > interpreted as being "corresponding" columns. I think the text > here needs to be more explicit about what the corresponding columns are. > If columns in this table fate-share with columns in TARGET-MIB when columns > there are deleted, then the required corresponding columns for creation > should probably include the corresponding target-mib columns. > dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, December 30, 2009 11:27 AM > To: David Harrington > Cc: 'Juergen Schoenwaelder'; isms@ietf.org > Subject: Re: issue #12: fate sharing >=20 > >>>>> On Wed, 16 Dec 2009 11:14:31 -0500, "David Harrington"=20 > said: >=20 > DH> In SSHTM (and in TLSTM), it is possible to attempt to set > up entries > DH> in advance, creating the tunnels for expected > communication. This was > DH> deliberate and had consensus of the WG for SSHTM work. I > think Eliot > DH> was the person who first championed this approach.=20 >=20 > Eliot wanted to design something to allow for a "callhome" approach. > The goal was to let something like a Command Responder call home to a > Command Generator and wait for incoming traffic. IE, the CR became=20 > the SSH client and the CG the SSH server. Nothing that has been done has > necessarily prohibited that approach from happening, but internally=20 > all the SNMP stacks don't act that way at all. I'm not saying they=20 > couldn't though. >=20 > DH> To be consistent with this design decision, the point is needed: > >> - Can create TLSTM-MIB entries in advance of TARGET-MIB entries=20 > >> being created >=20 > You're implying there that creating the TLSTM-MIB entry opens the=20 > connection; it does not. The TARGET-MIB is still the source of the=20 > configuration for who to talk with. Any support for call-home type=20 > approaches would need to still use the TARGET-MIB as the source of=20 > data to make the connection with and is beyond the scope of this work. We > don't, however, add anything that prevents this future work from=20 > happening (and in fact, by adding the configuration objects we have=20 > we're helping support it). >=20 > Based on the rest of your text, I think you were misunderstanding the > discussion surrounding pre-creation and fate-sharing. The discussion > was only talking about the fate sharing between the MIB tables and had > nothing to do with advanced connection establishment (which, as I=20 > said, is out of scope as it should be done in a generic fashion in=20 > 'some other MIB module'). > -- > Wes Hardaker > Cobham Analytic Solutions >=20 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Wed Dec 30 21:14:06 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495B03A68F4 for ; Wed, 30 Dec 2009 21:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=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 aEKdzzPXAusS for ; Wed, 30 Dec 2009 21:14:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DD7023A685D for ; Wed, 30 Dec 2009 21:14:04 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E5AEC000A; Thu, 31 Dec 2009 06:13:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Rvo4vSrWQEeQ; Thu, 31 Dec 2009 06:13:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C396FC0003; Thu, 31 Dec 2009 06:13:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A1A25FA85AD; Thu, 31 Dec 2009 06:13:39 +0100 (CET) Date: Thu, 31 Dec 2009 06:13:39 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091231051339.GA26661@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 05:14:06 -0000 On Wed, Dec 30, 2009 at 06:11:17PM +0100, Wes Hardaker wrote: > The only outstanding issues that I think are still being discussed on > the list are: > > 1) The reference to 4366 for the server-name extension. Consensus > currently seems that we should leave the reference and not reference > the unpublished ID yet that updates that section from 4366. But > there aren't many opinions yet. Unless there is a very strong technical reason, we should avoid having a reference to 4366bis. If someone believes there is such a very strong technical reason, please speak up now. > 2) The issue of MIB fate-sharing is still being discussed as well about > whether or not the rows in the target add-on tlstmParamsTable should > be deleted when a row in the original target table has been deleted. > > There are two independent in functionality but related in > global-picture that we're discussing. > > I. row creation ordering > > a) The tlstmParamsTable entry may be created in advance of the row > in the snmpTargetParamsTable. > [being done now in the MIB DESCRIPTIONs] > > b) The snmpTargetParamsTable entry must pre-exist before the row > in the tlstmParamsTable can be created. The downside of this > is that with the snmpTargetParamsTable row in existence before > the tlstmParamsTable then the row won't be functional when one > of the TLSTM domains are in use until the other row is created. > Or worse, per 5.3 step 1) the connection can still be attempted > with a different certificate than was expected if another was > identified through other configuration (eg, a global device > certificate). > > c) The tlstmParamsTable entry must pre-exist before the row in the > snmpTargetParamsTable can be created. This would be adding > requirements to the existing TARGET-MIB implementations when > the new MIB is supported, which is generally frowned upon. I do not think there was a request to change what we have for row creation ordering, namely I.a). > II. row deletion ordering > > a) The row in tlstmParamsTable is automatically deleted when the > corresponding row in the snmpTargetParamsTable is deleted. > [being done now in the MIB DESCRIPTIONs] > > b) The rows in the two tables are independent with respect to > deletion. Either can be deleted first (and without both in > place, the connection can't be completed). > > c) One table could require the deletion of a row from the other > table. I don't think anyone is vying for this option though. > > The working group seems somewhat split on this subject but I don't > think we have an accurate account of who wants what at this point. I heard David Harrington, Randy Presuhn, Andrew Donati and myself (as technical contributor) speaking in favour of II.b) and all three provided different arguments for choosing II.b): - David mentioned consistent user experience and consistency across SNMP configuration tables in general. - Randy mentioned the implementation aspects of fate shared tables and side effects potentially circumventing access controls rules. - Andrew mentioned issues with StorageTypes that prevent fate sharing from happening. Unless someone speaks up now with a technical argument in favour of keeping II.a) and in particular explains how to address the issue Andrew Donati brought up, I assume we will go with II.b. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Dec 30 21:21:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707CE3A699D for ; Wed, 30 Dec 2009 21:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SujXXxlUK3pU for ; Wed, 30 Dec 2009 21:21:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63D513A6991 for ; Wed, 30 Dec 2009 21:21:57 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E001C000A; Thu, 31 Dec 2009 06:21:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4NnnbUve5GE8; Thu, 31 Dec 2009 06:21:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AEA7C0003; Thu, 31 Dec 2009 06:21:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2FE6DFA85EC; Thu, 31 Dec 2009 06:21:33 +0100 (CET) Date: Thu, 31 Dec 2009 06:21:33 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091231052133.GB26661@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 05:21:58 -0000 On Wed, Dec 30, 2009 at 06:11:17PM +0100, Wes Hardaker wrote: > I'll leave it up to the working group chairs to decide if there are any > outstanding consensus calls that need to be made that I've missed. According to my record, the following people provided WG last call reviews: - Andrew Donati - Pasi Eronen - Juergen Schoenwaelder - Hamid Mukhtar - Alan Luchuk - Joe Salowey - David Harrington - Tom Petch I like to ask these WG members to check that the changes in the -04 document address their concerns. Silence will be read as the changes are fine. Please check until Wed January 6th the latest. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Thu Dec 31 01:35:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820D03A68FE for ; Thu, 31 Dec 2009 01:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 5vTjopX-7E1C for ; Thu, 31 Dec 2009 01:35:18 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 0799F3A685B for ; Thu, 31 Dec 2009 01:35:17 -0800 (PST) X-Trace: 315683470/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.135/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAIr/O0s+vGmH/2dsb2JhbACCWi2FK4hLt1oIizgKgiMOBgiBaASNVw X-IronPort-AV: E=Sophos;i="4.47,481,1257120000"; d="scan'208";a="315683470" X-IP-Direction: IN Received: from 1cust135.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.135]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 09:34:55 +0000 Message-ID: <001901ca89f4$2eaa03c0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Thu, 31 Dec 2009 09:30:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] TLSTM -04 draft being published: some more edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:35:19 -0000 Some editorial suggestions, of grammar, semantics and clarity. 3.1.1 2 "The TLSTM provides for verification of the identity of the (D)TLS server through the use of the (D)TLS protocol and the X.509 certificates. " Suggest "The TLSTM verifies the identity of the (D)TLS server through the use of the (D)TLS protocol and X.509 certificates. " 3.1.1 5 "However, datagram-based security protocols are .... because it" /it/they/ 3.1.2 " and the type and address associated " suggest "and the transport type and address associated " type on its own left me floundering 3.1.3 "Each unique combination of these parameters MUST have a locally-chosen unique tlstmSessionID associated for active sessions. " The last clause seems barely grammatical; suggest removing 'associated for active sessions' If you want to limit this to active sessions, suggest 'for each active session' "TLS and DTLS over SCTP sessions," tells me this is TLS over SCTP; suggest "TLS over TCP and DTLS over SCTP sessions," "The tlstmSessionID identifier MUST NOT change during the entire duration of the connection " since it is a sessionID suggest session not connection. 3.2 "(e.g..," an extra period to go with ... 4.4.1 ... a missing period 5.1.1 5 /(D)TLS/DTLS/ 5.2 5 4b (eh???? but that is what it says:-( /tmStateReferenc/tmStateReference/ 5.3 3b "The (D)TLS client side of the connection MUST verify that authenticated identity of the (D)TLS server's presented certificate is the expected certificate" ie 'the authenticated identity is the certificate' ok grammatically, but for me, not semantically; identities and certificates come from different universes 5.3 4 this is the one and only appearance of sessionID; well known in the TLS protocol but not what I think you mean:-) Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: Sent: Wednesday, December 30, 2009 6:11 PM Subject: [Isms] TLSTM -04 draft being published: wraps up all outstandingedits > > I'm in the process right now of publishing a -04 copy of the TLSTM draft > and it contains all my outstanding edits from the comments received > since last call. Note that although last call has long ago finished > we've received a number of comments after that cut-off, in part because > of Juergen's request for more reviews. Thanks to everyone who has > submitted comments about the draft as they've been very helpful. I've > already responded to each person with the actions taken based on the > comments. > > I'll leave it up to the working group chairs to decide if there are any > outstanding consensus calls that need to be made that I've missed. > > The only outstanding issues that I think are still being discussed on > the list are: > > 1) The reference to 4366 for the server-name extension. Consensus > currently seems that we should leave the reference and not reference > the unpublished ID yet that updates that section from 4366. But > there aren't many opinions yet. > > 2) The issue of MIB fate-sharing is still being discussed as well about > whether or not the rows in the target add-on tlstmParamsTable should > be deleted when a row in the original target table has been deleted. > > There are two independent in functionality but related in > global-picture that we're discussing. > > I. row creation ordering > > a) The tlstmParamsTable entry may be created in advance of the row > in the snmpTargetParamsTable. > [being done now in the MIB DESCRIPTIONs] > > b) The snmpTargetParamsTable entry must pre-exist before the row > in the tlstmParamsTable can be created. The downside of this > is that with the snmpTargetParamsTable row in existence before > the tlstmParamsTable then the row won't be functional when one > of the TLSTM domains are in use until the other row is created. > Or worse, per 5.3 step 1) the connection can still be attempted > with a different certificate than was expected if another was > identified through other configuration (eg, a global device > certificate). > > c) The tlstmParamsTable entry must pre-exist before the row in the > snmpTargetParamsTable can be created. This would be adding > requirements to the existing TARGET-MIB implementations when > the new MIB is supported, which is generally frowned upon. > > II. row deletion ordering > > a) The row in tlstmParamsTable is automatically deleted when the > corresponding row in the snmpTargetParamsTable is deleted. > [being done now in the MIB DESCRIPTIONs] > > b) The rows in the two tables are independent with respect to > deletion. Either can be deleted first (and without both in > place, the connection can't be completed). > > > c) One table could require the deletion of a row from the other > table. I don't think anyone is vying for this option though. > > The working group seems somewhat split on this subject but I don't > think we have an accurate account of who wants what at this point. > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Thu Dec 31 01:35:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79323A685B for ; Thu, 31 Dec 2009 01:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_20=-0.74, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+bVKVfWjJx9 for ; Thu, 31 Dec 2009 01:35:19 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D99013A68E4 for ; Thu, 31 Dec 2009 01:35:18 -0800 (PST) X-Trace: 315683471/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.135/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAIr/O0s+vGmH/2dsb2JhbACCWi2FK4hLwxoKhCcE X-IronPort-AV: E=Sophos;i="4.47,481,1257120000"; d="scan'208";a="315683471" X-IP-Direction: IN Received: from 1cust135.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.135]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 09:34:57 +0000 Message-ID: <001a01ca89f4$30015660$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <000401ca895b$a54a0000$0601a8c0@allison><004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> Date: Thu, 31 Dec 2009 09:32:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:35:20 -0000 ----- Original Message ----- From: "Wes Hardaker" Sent: Wednesday, December 30, 2009 5:36 PM Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker said: > > DH> Personally, I recommend against having a reference to the bis > DH> document. We are in WGLC and don't want publication held up because of > DH> a reference to bis. > > WH> I agree; I was trying not to specify which versions of the TLS based > WH> protocols we are requiring because I don't think there are any features > WH> of the newer ones that we need. There is no reason that future versions > WH> of TLS and DTLS couldn't be used as well assuming they didn't introduce > WH> a technical conflict with our document, which is unlikely. > > Whoops. Having re-read everything I realized I was confused about which > of the two issues David was talking about. I responded about the DTLS > reference but the discussion was surrounding the fact that RFC4366 is > the only RFC that documents the server name extension until a new one > gets published. Because of that, we'd either have to keep referencing > the older one (which doesn't cause any technical problems that I'm aware > of) or reference the ID and hope it completes soon. Pasi may have a > better idea about how the other document is progressing, but unless it's > almost identically timed I don't think it buys us much to reference the ID. Um My point was rather that RFC4366 is obsoleted by RFC5246 because the description of the extension technique has been removed from the TLS extension document and made part of the base document, ie extensions are base TLS as of TLS 1.2 (a key feature of current TLS list discussions). 4366-bis will only contain details of specific extensions. SNI does appear in both RFC4366 and 4366-bis so from that point of view, either will do, so it is a choice of being allowed to depend on an obsoleted document versus having to wait for an I-D to progress - I think the latter far preferable, the former a short term expedient. The latter gives us the chance to request another case for SNI, the current hostname insisting on a fully qualified DNS name which isn't really right for a securityName. My personal view is that, currently, the TLS WG is rather preoccupied with fixing the hole in renegotiation and I expect it will be some months before 4366bis gets the attention it deserves. Tom Petch > Wes Hardaker > Cobham Analytic Solutions From cfinss@dial.pipex.com Thu Dec 31 01:43:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4053A699A for ; Thu, 31 Dec 2009 01:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_21=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 3BFNCShrRK3A for ; Thu, 31 Dec 2009 01:43:04 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id E3F5F3A6996 for ; Thu, 31 Dec 2009 01:43:03 -0800 (PST) X-Trace: 226613821/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.135/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFALcAPEs+vGmH/2dsb2JhbACCWi2FK4hLt0wHAQiLMAIIgjcHAYFoBA X-IronPort-AV: E=Sophos;i="4.47,481,1257120000"; d="scan'208";a="226613821" X-IP-Direction: IN Received: from 1cust135.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.135]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 09:42:41 +0000 Message-ID: <002701ca89f5$44721340$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "Wes Hardaker" References: <20091231051339.GA26661@elstar.local> Date: Thu, 31 Dec 2009 09:42:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:43:05 -0000 on 4366 Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wes Hardaker" Cc: Sent: Thursday, December 31, 2009 6:13 AM Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits > On Wed, Dec 30, 2009 at 06:11:17PM +0100, Wes Hardaker wrote: > > > The only outstanding issues that I think are still being discussed on > > the list are: > > > > 1) The reference to 4366 for the server-name extension. Consensus > > currently seems that we should leave the reference and not reference > > the unpublished ID yet that updates that section from 4366. But > > there aren't many opinions yet. > > Unless there is a very strong technical reason, we should avoid having > a reference to 4366bis. If someone believes there is such a very > strong technical reason, please speak up now. 4366 requires the HostName to be a fully qualified DNS name so if we follow that RFC, we would require our securityNames-to-be to be fully qualified DNS names. I think that wrong. We should either ask the TLS WG to add another case more suitable for our needs, ie in 4366bis or else we do it ourselves, put in another case as an update to the registry of cases - the rules for update allow us to do that. Tom Petch > > 2) The issue of MIB fate-sharing is still being discussed as well about > > whether or not the rows in the target add-on tlstmParamsTable should > > be deleted when a row in the original target table has been deleted. > > > > There are two independent in functionality but related in > > global-picture that we're discussing. > > > > I. row creation ordering > > > > a) The tlstmParamsTable entry may be created in advance of the row > > in the snmpTargetParamsTable. > > [being done now in the MIB DESCRIPTIONs] > > > > b) The snmpTargetParamsTable entry must pre-exist before the row > > in the tlstmParamsTable can be created. The downside of this > > is that with the snmpTargetParamsTable row in existence before > > the tlstmParamsTable then the row won't be functional when one > > of the TLSTM domains are in use until the other row is created. > > Or worse, per 5.3 step 1) the connection can still be attempted > > with a different certificate than was expected if another was > > identified through other configuration (eg, a global device > > certificate). > > > > c) The tlstmParamsTable entry must pre-exist before the row in the > > snmpTargetParamsTable can be created. This would be adding > > requirements to the existing TARGET-MIB implementations when > > the new MIB is supported, which is generally frowned upon. > > I do not think there was a request to change what we have for row > creation ordering, namely I.a). > > > II. row deletion ordering > > > > a) The row in tlstmParamsTable is automatically deleted when the > > corresponding row in the snmpTargetParamsTable is deleted. > > [being done now in the MIB DESCRIPTIONs] > > > > b) The rows in the two tables are independent with respect to > > deletion. Either can be deleted first (and without both in > > place, the connection can't be completed). > > > > c) One table could require the deletion of a row from the other > > table. I don't think anyone is vying for this option though. > > > > The working group seems somewhat split on this subject but I don't > > think we have an accurate account of who wants what at this point. > > I heard David Harrington, Randy Presuhn, Andrew Donati and myself (as > technical contributor) speaking in favour of II.b) and all three > provided different arguments for choosing II.b): > > - David mentioned consistent user experience and consistency across > SNMP configuration tables in general. > > - Randy mentioned the implementation aspects of fate shared tables and > side effects potentially circumventing access controls rules. > > - Andrew mentioned issues with StorageTypes that prevent fate sharing > from happening. > > Unless someone speaks up now with a technical argument in favour of > keeping II.a) and in particular explains how to address the issue > Andrew Donati brought up, I assume we will go with II.b. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Thu Dec 31 04:46:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330233A6801 for ; Thu, 31 Dec 2009 04:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk0BJ0jc1qTx for ; Thu, 31 Dec 2009 04:46:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1841B3A677C for ; Thu, 31 Dec 2009 04:46:32 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D95CEC0003; Thu, 31 Dec 2009 13:46:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id w29Oz7pxG4wm; Thu, 31 Dec 2009 13:46:10 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7440FC0002; Thu, 31 Dec 2009 13:46:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 05C39FA8EFE; Thu, 31 Dec 2009 13:46:06 +0100 (CET) Date: Thu, 31 Dec 2009 13:46:06 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20091231124606.GA27340@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <000401ca895b$a54a0000$0601a8c0@allison> <004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> <001a01ca89f4$30015660$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01ca89f4$30015660$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 12:46:34 -0000 On Thu, Dec 31, 2009 at 09:32:05AM +0100, tom.petch wrote: > > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker > said: > > > > DH> Personally, I recommend against having a reference to the bis > > DH> document. We are in WGLC and don't want publication held up because of > > DH> a reference to bis. > > > > WH> I agree; I was trying not to specify which versions of the TLS based > > WH> protocols we are requiring because I don't think there are any features > > WH> of the newer ones that we need. There is no reason that future versions > > WH> of TLS and DTLS couldn't be used as well assuming they didn't introduce > > WH> a technical conflict with our document, which is unlikely. > > > > Whoops. Having re-read everything I realized I was confused about which > > of the two issues David was talking about. I responded about the DTLS > > reference but the discussion was surrounding the fact that RFC4366 is > > the only RFC that documents the server name extension until a new one > > gets published. Because of that, we'd either have to keep referencing > > the older one (which doesn't cause any technical problems that I'm aware > > of) or reference the ID and hope it completes soon. Pasi may have a > > better idea about how the other document is progressing, but unless it's > > almost identically timed I don't think it buys us much to reference the ID. > > Um > > My point was rather that RFC4366 is obsoleted by RFC5246 because the > description of the extension technique has been removed from the TLS > extension document and made part of the base document, ie extensions > are base TLS as of TLS 1.2 (a key feature of current TLS list discussions). > > 4366-bis will only contain details of specific extensions. > > SNI does appear in both RFC4366 and 4366-bis so from that > point of view, either will do, so it is a choice of being allowed to depend > on an obsoleted document versus having to wait for an I-D to > progress - I think the latter far preferable, the former a short > term expedient. The latter gives us the chance to request > another case for SNI, the current hostname insisting on a fully > qualified DNS name which isn't really right for a securityName. > > My personal view is that, currently, the TLS WG is rather > preoccupied with fixing the hole in renegotiation and I expect > it will be some months before 4366bis gets the attention it deserves. If we can avoid to get delayed by months, we should try to do so. Lets keep in mind that Propose Standard is just the beginning of the life of a document on the standards track. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Dec 31 04:51:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EE13A6A7A for ; Thu, 31 Dec 2009 04:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVOTxc1m66yS for ; Thu, 31 Dec 2009 04:51:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 65A0D3A677C for ; Thu, 31 Dec 2009 04:51:30 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01365C0003; Thu, 31 Dec 2009 13:51:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zSCyJkQfIp0V; Thu, 31 Dec 2009 13:51:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 169E9C0002; Thu, 31 Dec 2009 13:51:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7560FA8F5A; Thu, 31 Dec 2009 13:51:05 +0100 (CET) Date: Thu, 31 Dec 2009 13:51:05 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20091231125105.GB27340@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , "isms@ietf.org" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002701ca89f5$44721340$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 12:51:31 -0000 On Thu, Dec 31, 2009 at 09:42:57AM +0100, tom.petch wrote: > 4366 requires the HostName to be a fully qualified DNS name > so if we follow that RFC, we would require our securityNames-to-be > to be fully qualified DNS names. I think that wrong. Why? > We should either ask the TLS WG to add another case more > suitable for our needs, ie in 4366bis or else we do it ourselves, > put in another case as an update to the registry of cases - the rules > for update allow us to do that. If there is a strong case that can be well argued, I would prefer to channel this through the TLS WG if it needs to be dealt with at all. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Dec 31 05:02:28 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31B43A6817 for ; Thu, 31 Dec 2009 05:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RAd6BgH6GNI for ; Thu, 31 Dec 2009 05:02:27 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 994943A6822 for ; Thu, 31 Dec 2009 05:02:27 -0800 (PST) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PoPt1d0021swQuc5Bp28x3; Thu, 31 Dec 2009 13:02:08 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA15.westchester.pa.mail.comcast.net with comcast id Pp3j1d00V284sdk3bp3lEL; Thu, 31 Dec 2009 13:03:46 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" References: <000401ca895b$a54a0000$0601a8c0@allison><004201ca8965$3c6a1d90$0600a8c0@china.huawei.com> <001a01ca89f4$30015660$0601a8c0@allison> Date: Thu, 31 Dec 2009 08:02:04 -0500 Message-ID: <00d301ca8a19$74ad7260$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqJ/IdoqpBi1S+WR9qdA3aUwSEyiAAHIFhg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <001a01ca89f4$30015660$0601a8c0@allison> Cc: isms@ietf.org Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 13:02:28 -0000 My experience tells me that getting a document through the IESG approval process can take a year, more likely 6 months. If the bis status changes we can always change the reference later. But I don't get the sense that the bis will beat our document through the system, so I would prefer to point to the stable document unless, as Juergen points out, there is a real technical distinction. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Thursday, December 31, 2009 3:32 AM > To: Wes Hardaker > Cc: David Harrington; 'Joseph Salowey (jsalowey)'; > isms@ietf.org; Pasi Eronen > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > ----- Original Message ----- > From: "Wes Hardaker" > Sent: Wednesday, December 30, 2009 5:36 PM > Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt > > > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker > > said: > > > > DH> Personally, I recommend against having a reference to the bis > > DH> document. We are in WGLC and don't want publication > held up because of > > DH> a reference to bis. > > > > WH> I agree; I was trying not to specify which versions of > the TLS based > > WH> protocols we are requiring because I don't think there > are any features > > WH> of the newer ones that we need. There is no reason > that future versions > > WH> of TLS and DTLS couldn't be used as well assuming they > didn't introduce > > WH> a technical conflict with our document, which is unlikely. > > > > Whoops. Having re-read everything I realized I was > confused about which > > of the two issues David was talking about. I responded > about the DTLS > > reference but the discussion was surrounding the fact that > RFC4366 is > > the only RFC that documents the server name extension until > a new one > > gets published. Because of that, we'd either have to keep > referencing > > the older one (which doesn't cause any technical problems > that I'm aware > > of) or reference the ID and hope it completes soon. Pasi may have a > > better idea about how the other document is progressing, > but unless it's > > almost identically timed I don't think it buys us much to > reference the ID. > > Um > > My point was rather that RFC4366 is obsoleted by RFC5246 because the > description of the extension technique has been removed from the TLS > extension document and made part of the base document, ie extensions > are base TLS as of TLS 1.2 (a key feature of current TLS list > discussions). > > 4366-bis will only contain details of specific extensions. > > SNI does appear in both RFC4366 and 4366-bis so from that > point of view, either will do, so it is a choice of being > allowed to depend > on an obsoleted document versus having to wait for an I-D to > progress - I think the latter far preferable, the former a short > term expedient. The latter gives us the chance to request > another case for SNI, the current hostname insisting on a fully > qualified DNS name which isn't really right for a securityName. > > My personal view is that, currently, the TLS WG is rather > preoccupied with fixing the hole in renegotiation and I expect > it will be some months before 4366bis gets the attention it deserves. > > Tom Petch > > > Wes Hardaker > > Cobham Analytic Solutions > > From cfinss@dial.pipex.com Thu Dec 31 05:42:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C492A3A6834 for ; Thu, 31 Dec 2009 05:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, 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 y9Aoxd+3a0D2 for ; Thu, 31 Dec 2009 05:42:35 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 4FDD63A67FD for ; Thu, 31 Dec 2009 05:42:35 -0800 (PST) X-Trace: 280924535/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.62/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.62 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAPY4PEs+vGk+/2dsb2JhbACCWxiFQIhLwxgKhCcE X-IronPort-AV: E=Sophos;i="4.47,482,1257120000"; d="scan'208";a="280924535" X-IP-Direction: IN Received: from 1cust62.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.62]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 13:42:12 +0000 Message-ID: <000401ca8a16$ba7abd00$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" References: <20091216105240.GA78492@elstar.local><062501ca7e6a$da17b3a0$6601a8c0@china.huawei.com> <006701ca897e$f2d6abc0$0600a8c0@china.huawei.com> Date: Thu, 31 Dec 2009 12:14:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] issue #12: fate sharing X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 13:42:36 -0000 David On the question of setting up in advance, that is something I have always wanted and seen almost as necessary for Notifications. I would have liked the Notification Receiver to be able to to this, since it is that engine that is keenest to make it happen and is likely to be the one with the greatest amount of infrastructure around it (automation, human operators ...). And it solves the DTLS heartbeat (lack of) problem. I intend to go through tlstm and see if it is possible. On fate sharing per se, sounds like a dreadful idea, full of scope for disasters caused by boxes doing things that humans would never expect them to do. There has got to be either an obvious (to a human) link between a and b for a change to a to ripple automatically into b or else b has got to be so obscure that a human will never consider it. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Wes Hardaker'" Cc: Sent: Wednesday, December 30, 2009 7:36 PM Subject: Re: [Isms] issue #12: fate sharing > Hi, > > I assume the information in the tlstmParamsTable and the > tlstmAddrTable must be manually configured by an administrator. We > usually expect such information to be persistent across reboots. I > didn't see text in the MIB that said this. > > Now back to paragraph 1 of my response. If this is admin-configured, > we probably do not want to automatically delete the configuration > information and force the admin to re-enter the info. > > Is this a potential scenario? An admin decides to delete and re-enter > a target-mib entry, possibly because he entered the info incorrectly > in the first place. But he did enter the corresponding info in > tlstmParamsTable correctly. If he deletes the incorrect target-mib > info, will the tlstmParams data be automatically discarded, forcing > the operator to re-enter the information? > > tlstmParamsRowStatus says "Until instances of all corresponding > columns are appropriately configured, the value of the corresponding > instance of the tlstmParamsRowStatus column is 'notReady'." > There are columns in the TARGET-MIB that could be interpreted as being > "corresponding" columns. I think the text here needs to be more > explicit about what the corresponding columns are. > > If columns in this table fate-share with columns in TARGET-MIB when > columns there are deleted, then the required corresponding columns for > creation should probably include the corresponding target-mib columns. > > dbh > > > > > -----Original Message----- > > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > > Sent: Wednesday, December 30, 2009 11:27 AM > > To: David Harrington > > Cc: 'Juergen Schoenwaelder'; isms@ietf.org > > Subject: Re: issue #12: fate sharing > > > > >>>>> On Wed, 16 Dec 2009 11:14:31 -0500, "David Harrington" > > said: > > > > DH> In SSHTM (and in TLSTM), it is possible to attempt to set > > up entries > > DH> in advance, creating the tunnels for expected > > communication. This was > > DH> deliberate and had consensus of the WG for SSHTM work. I > > think Eliot > > DH> was the person who first championed this approach. > > > > Eliot wanted to design something to allow for a "callhome" approach. > > The goal was to let something like a Command Responder call home to > a > > Command Generator and wait for incoming traffic. IE, the CR > > became the > > SSH client and the CG the SSH server. Nothing that has been done > has > > necessarily prohibited that approach from happening, but > > internally all > > the SNMP stacks don't act that way at all. I'm not saying > > they couldn't > > though. > > > > DH> To be consistent with this design decision, the point is needed: > > >> - Can create TLSTM-MIB entries in advance of TARGET-MIB entries > > >> being created > > > > You're implying there that creating the TLSTM-MIB entry opens the > > connection; it does not. The TARGET-MIB is still the source of the > > configuration for who to talk with. Any support for call-home type > > approaches would need to still use the TARGET-MIB as the > > source of data > > to make the connection with and is beyond the scope of this work. > We > > don't, however, add anything that prevents this future work from > > happening (and in fact, by adding the configuration objects we have > > we're helping support it). > > > > Based on the rest of your text, I think you were misunderstanding > the > > discussion surrounding pre-creation and fate-sharing. The > discussion > > was only talking about the fate sharing between the MIB tables and > had > > nothing to do with advanced connection establishment (which, > > as I said, > > is out of scope as it should be done in a generic fashion in > > 'some other > > MIB module'). > > -- > > Wes Hardaker > > Cobham Analytic Solutions > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Thu Dec 31 05:42:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EDE3A67FD for ; Thu, 31 Dec 2009 05:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 rs++9LDJ8uc5 for ; Thu, 31 Dec 2009 05:42:36 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 845F93A6833 for ; Thu, 31 Dec 2009 05:42:36 -0800 (PST) X-Trace: 280924537/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.62/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.62 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAPY4PEs+vGk+/2dsb2JhbACCWxiFQIhLwxgKhCcE X-IronPort-AV: E=Sophos;i="4.47,482,1257120000"; d="scan'208";a="280924537" X-IP-Direction: IN Received: from 1cust62.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.62]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 13:42:15 +0000 Message-ID: <000501ca8a16$bc691f80$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" , References: <000901ca8005$ffe88220$0601a8c0@allison> <000501ca895b$a6ed9de0$0601a8c0@allison> <004101ca8964$9471eeb0$0600a8c0@china.huawei.com> <004001ca897b$d4999c60$0601a8c0@allison> <006a01ca8988$6efd44d0$0600a8c0@china.huawei.com> Date: Thu, 31 Dec 2009 12:18:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Updated TLSTM document 1.1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 13:42:37 -0000 ----- Original Message ----- From: "David Harrington" Sent: Wednesday, December 30, 2009 8:43 PM > > What about 1.1, > > > > "Either SNMP entity may act as client or as server." > > in isolation, at the start, still looks misleading to me. > > > > Or are you suggesting that this text appears in 1.1 and in > > 3.3 ? > > How about > "An SNMP entity may act as client or server or both, depending on the > SNMP applications supported." Looks good, Tom Petch > dbh > From cfinss@dial.pipex.com Thu Dec 31 10:15:01 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747EA3A6A59 for ; Thu, 31 Dec 2009 10:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_20=-0.74, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbz9nUlpBVfF for ; Thu, 31 Dec 2009 10:15:00 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 52F2E3A6A01 for ; Thu, 31 Dec 2009 10:15:00 -0800 (PST) X-Trace: 226708931/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.33/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.33 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAD94PEs+vGQh/2dsb2JhbACCWoVYiEu3fgmLGAIIgj6BaQQ X-IronPort-AV: E=Sophos;i="4.47,483,1257120000"; d="scan'208";a="226708931" X-IP-Direction: IN Received: from 1cust33.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.33]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 18:13:37 +0000 Message-ID: <02a601ca8a3c$a4fb8ba0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20091231051339.GA26661@elstar.local> <002701ca89f5$44721340$0601a8c0@allison> <20091231125105.GB27340@elstar.local> Date: Thu, 31 Dec 2009 16:13:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 18:15:01 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" j.schoenwaelder@jacobs-university.de Sent: Thursday, December 31, 2009 1:51 PM > On Thu, Dec 31, 2009 at 09:42:57AM +0100, tom.petch wrote: > > > 4366 requires the HostName to be a fully qualified DNS name > > so if we follow that RFC, we would require our securityNames-to-be > > to be fully qualified DNS names. I think that wrong. > > Why? You seem to be suggesting that your principal names are fully qualified DNS names. I know of none such so forcing the SNI to be a fully qualified DNS name, which is my reading of RFC4366, means yet another mapping table to be configured by the admin, mapping fully qualified DNS names into what admins actually assign to users. I see a need for another case allowing snmpAdminString format. Tom Petch > > We should either ask the TLS WG to add another case more > > suitable for our needs, ie in 4366bis or else we do it ourselves, > > put in another case as an update to the registry of cases - the rules > > for update allow us to do that. > > If there is a strong case that can be well argued, I would prefer to > channel this through the TLS WG if it needs to be dealt with at all. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103