From root@core3.amsl.com Wed Sep 2 00:30:02 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 BF32F28C2EB; Wed, 2 Sep 2009 00:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090902073002.BF32F28C2EB@core3.amsl.com> Date: Wed, 2 Sep 2009 00:30:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-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 Sep 2009 07:30:03 -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 Transport Model for SNMP Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-00.txt Pages : 66 Date : 2009-09-01 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. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-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-dtls-tm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-02001633.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Wed Sep 9 08:01: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 C662A3A698E for ; Wed, 9 Sep 2009 08:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-2.245, BAYES_50=0.001, HELO_EQ_DE=0.35, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb5LLe0oCiKq for ; Wed, 9 Sep 2009 08:01:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDBAB3A6982 for ; Wed, 9 Sep 2009 08:01:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6387FC0006 for ; Wed, 9 Sep 2009 17:02:01 +0200 (CEST) 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 U9sWd409uVqc; Wed, 9 Sep 2009 17:02:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFC17C0003; Wed, 9 Sep 2009 17:02:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C5A01C99967; Wed, 9 Sep 2009 17:01:59 +0200 (CEST) Date: Wed, 9 Sep 2009 17:01:59 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090909150159.GA23817@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] NOMCOM 2009-2010 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, 09 Sep 2009 15:01:29 -0000 Hi, the NOMCOM Call for Nominations is still open and the NOMCOM likes to see more nominations. Please consider volunteering if you want to make a leadership contribution to the IETF. There details are here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06510.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Sep 10 13:21: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 7BB9B3A6B8C for ; Thu, 10 Sep 2009 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LXnCJ7d54y6b for ; Thu, 10 Sep 2009 13:21:13 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 96F823A6989 for ; Thu, 10 Sep 2009 13:21:13 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BEB7E981C0 for ; Thu, 10 Sep 2009 13:21:47 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 10 Sep 2009 13:21:47 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] First WG version of the TLSTM draft 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: Thu, 10 Sep 2009 20:21:14 -0000 I'm sure most of you saw the announcement, but just as a reminder: the first WG version of the draft was posted on Sept 1st. Comments appreciated. - The contained MIB now reflects the discussion during the WG meeting in Stockholm - A number of other edits - Not, however, the edits given to me by Dave Shield on paper; those are next on my todo list -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Sep 10 13:41: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 091963A6A74 for ; Thu, 10 Sep 2009 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44YDyra+BjbX for ; Thu, 10 Sep 2009 13:41:33 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 130B63A6AC5 for ; Thu, 10 Sep 2009 13:41:32 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 1BD1F981CC for ; Thu, 10 Sep 2009 13:42:06 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 10 Sep 2009 13:42:06 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] TLS Certificate Path Requirements X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 20:41:37 -0000 One question that was not fully flushed out at the last meeting was what path validation we should require implementations to support. In particular, we need to decide what a client and a server MUST/SHOULD/MAY support with respect to what type of path validation they need to support. They need to support either or both of: - path validation to a trust anchor (e.g. RFC5280 processing) - self-signed certificates Right now the wording in the document doesn't explicitly state what a implementation must support on either end. This is roughly what is spelled out, MIB-and-code-implementation-wise: On the client - via the tlstmAddrTable: a finger print of the exact certificate expected of the server - Words describing that a client may do path validation to a trust anchor, but we agreed at the WG meeting that configuration of active trust anchors was outside the scope. On the server, via the tlstmCertToSNTable: - recognizing a cell-signed incoming client certificate via a fingerprint - recognizing a fingerprint of a trust anchor that properly path-validates [RFC5280] the client's certificate. So the boiled down questions for this that can be answered in terms of MUST/SHOULD/MAY: 1) Should the client be required to support self-signed server certificates? 2) Should the client be required to support certificate path validation of server certificates. 3) Should the server be required to support self-signed client certificates? 4) Should the server be required to support certificate path validation of client certificates. And an interesting side question: 5) Should we specifically reference RFC5280 as THE path validation procedure to use. The text right now says things like "The client MUST always perform appropriate certificate path validation procedures (e.g. [RFC5280]) to ensure the certificate is cryptographically valid." where the wording is slightly generic and allows for any path validation procedure that the device can perform. The fuzziness is there to leave room for future validation documents to be used since as long as the validation occurs, I don't think we should specifically require 5280. But that's my personal opinion. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Sep 10 13:48: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 9940128C1C6 for ; Thu, 10 Sep 2009 13:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjXurn7lwAN4 for ; Thu, 10 Sep 2009 13:48:20 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 77B603A6A8D for ; Thu, 10 Sep 2009 13:48:20 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3C15B981D0 for ; Thu, 10 Sep 2009 13:48:55 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 10 Sep 2009 13:48:55 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 20:48:21 -0000 After doing research about what other fingerprinting / hash textual conventions were out there, I found none. Which surprised me. The end result was there was nothing to reuse, so we do need to define our own. The -00 version of the document defines 2 TCs for "fingerprints" (FingerprintType and FingerprintValue). These are worded generically so they can be reused elsewhere easily. The biggest question, as I was defining the TCs, was what type of data the FingerprintType should be. Originally in the personal versions of the draft, it was an integer. But it's highly likely that many other hashing algorithms will be defined in the future, especially with the NIST hashing algorithm "contest" going on right now. So we certainly need something with agility. In the end, I changed the FingerprintType to a OID instead. Note that in our MIBs at least, it's not being used as an index so we don't have issues with the length restrictions it would impose on MIB objects. I could easily see other MIBs wanting to put it in an INDEX though. Feedback on these resulting TCs is greatly appreciated. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Thu Sep 10 15:12:39 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 B36983A6AD5 for ; Thu, 10 Sep 2009 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 3gJO7GHZLhuD for ; Thu, 10 Sep 2009 15:12:39 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id EB05D3A6A91 for ; Thu, 10 Sep 2009 15:12:38 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8AMDAI0027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 18:13:10 -0400 (EDT) Date: Thu, 10 Sep 2009 18:13:09 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , isms@ietf.org Message-ID: <5C883C4024B072DF9B6AF893@minbar.fac.cs.cmu.edu> In-Reply-To: <14020_1252615753_n8AKnCIV020344_sdhbvamsp4.fsf@wjh.hardakers.net> References: <14020_1252615753_n8AKnCIV020344_sdhbvamsp4.fsf@wjh.hardakers.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 22:12:39 -0000 --On Thursday, September 10, 2009 01:48:55 PM -0700 Wes Hardaker wrote: > > After doing research about what other fingerprinting / hash textual > conventions were out there, I found none. Which surprised me. The end > result was there was nothing to reuse, so we do need to define our own. Then we should be going to PKIX or maybe even SAAG for advice. If we're going to define something we expect to be reused, we should make sure to get it right, or better, get it done right in a more appropriate forum. -- Jeff From jsalowey@cisco.com Thu Sep 10 15:22: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 25DFA28C222 for ; Thu, 10 Sep 2009 15:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 nWguKdWgtA6I for ; Thu, 10 Sep 2009 15:22:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1E3EE3A69D0 for ; Thu, 10 Sep 2009 15:22:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALYYqUqrR7MV/2dsb2JhbADGO4hGAZBFBYQY X-IronPort-AV: E=Sophos;i="4.44,366,1249257600"; d="scan'208";a="203587497" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2009 22:22:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8AMMc5c016507; Thu, 10 Sep 2009 15:22:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8AMMbdj026892; Thu, 10 Sep 2009 22:22:37 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 15:22:37 -0700 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, 10 Sep 2009 15:22:36 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] fingerprint TCs and hash types Thread-Index: AcoyWCuxxwCu+VOPT/GwjBcVtLsr/wABztrA References: From: "Joseph Salowey (jsalowey)" To: "Wes Hardaker" , X-OriginalArrivalTime: 10 Sep 2009 22:22:37.0835 (UTC) FILETIME=[33F65DB0:01CA3265] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2322; t=1252621358; x=1253485358; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Isms]=20fingerprint=20TCs=20and=20hash =20types |Sender:=20; bh=TbtzE66MGR5ym/nU5qRuFzvApIAK0wcOO4XWP+Crf+I=; b=BRKhHEc0hl6ngMxd5YvvREjg5mb3/F32VSywu1W6ArHD88l/ysBzQS0ICi xGya/LA0lXhSIC5++GbSiWesV8/PheYtN+z+rF2/gAGfNyXWwfPbF9wk3J69 8Z9vz4jYNm58ek9L8bYF9e9DQglJxH0elQ928kwAjzwnEuPXgAy/4=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 22:22:03 -0000 =20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Wes Hardaker > Sent: Thursday, September 10, 2009 1:49 PM > To: isms@ietf.org > Subject: [Isms] fingerprint TCs and hash types >=20 >=20 > After doing research about what other fingerprinting / hash=20 > textual conventions were out there, I found none. Which=20 > surprised me. The end result was there was nothing to reuse,=20 > so we do need to define our own. >=20 > The -00 version of the document defines 2 TCs for "fingerprints" > (FingerprintType and FingerprintValue). These are worded=20 > generically so they can be reused elsewhere easily. >=20 > > > The biggest question, as I was defining the TCs, was what=20 > type of data the FingerprintType should be. Originally in=20 > the personal versions of the draft, it was an integer. But=20 > it's highly likely that many other hashing algorithms will be=20 > defined in the future, especially with the NIST hashing=20 > algorithm "contest" going on right now. So we certainly need=20 > something with agility. In the end, I changed the=20 > FingerprintType to a OID instead. >=20 [Joe] I haven't had a chance to look at your document yet, but I guess it depends on what you want specified in FingerprintType. If you are just looking for hashes there probably are already OIDs for this defined for PKIX,PKCS,X509 etc. In addition for Syslog TLS, RFC 5425, the fingerprint support references the names for hash functions defined in IANA registry "Hash Function Textual Names" allocated in RFC4572. If you are looking for something that is specifying hash and encoding then I'm not sure there is anything formally defined. It would be nice if things lined up in some useful way with RFC 5425. =20 > Note that in our MIBs at least, it's not being used as an=20 > index so we don't have issues with the length restrictions it=20 > would impose on MIB objects. I could easily see other MIBs=20 > wanting to put it in an INDEX though. >=20 > Feedback on these resulting TCs is greatly appreciated. >=20 > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From j.schoenwaelder@jacobs-university.de Thu Sep 10 15:28: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 B1C8B3A67CC for ; Thu, 10 Sep 2009 15:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 WcGBeP-nY8Ms for ; Thu, 10 Sep 2009 15:28:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E30603A67C0 for ; Thu, 10 Sep 2009 15:28:49 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12FCBC0022; Fri, 11 Sep 2009 00:29:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lATyKiX7JR02; Fri, 11 Sep 2009 00:29:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27C84C0014; Fri, 11 Sep 2009 00:29:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C97F7C9C38E; Fri, 11 Sep 2009 00:29:21 +0200 (CEST) Date: Fri, 11 Sep 2009 00:29:21 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090910222921.GA26279@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] fingerprint TCs and hash types 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, 10 Sep 2009 22:28:52 -0000 On Thu, Sep 10, 2009 at 10:48:55PM +0200, Wes Hardaker wrote: > After doing research about what other fingerprinting / hash textual > conventions were out there, I found none. Which surprised me. The end > result was there was nothing to reuse, so we do need to define our own. > > The -00 version of the document defines 2 TCs for "fingerprints" > (FingerprintType and FingerprintValue). These are worded generically so > they can be reused elsewhere easily. I am wondering what the correct term is here: fingerprint versus (crptographic) hashvalue versus message digest. My understanding is that FingerprintValue contains simply the output generated by the hash function identified by FingerprintType, correct? > The biggest question, as I was defining the TCs, was what type of data > the FingerprintType should be. Originally in the personal versions of > the draft, it was an integer. But it's highly likely that many other > hashing algorithms will be defined in the future, especially with the > NIST hashing algorithm "contest" going on right now. So we certainly > need something with agility. In the end, I changed the FingerprintType > to a OID instead. > > Note that in our MIBs at least, it's not being used as an index so we > don't have issues with the length restrictions it would impose on MIB > objects. I could easily see other MIBs wanting to put it in an INDEX > though. In SNMP-USER-BASED-SM-MIB, we have object identifies for authentication and encryption protocols and the relevant columns of the tables use SNMPv2-SMI's AutonomousType. Can we do the same? Is FingerprintType as a separate TC really needed? /js PS: It would be nice if the hash algorithm OBJECT-IDENTITYs would have REFERENCE clauses. -- 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 Sep 10 15:32: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 85CDC3A6B33 for ; Thu, 10 Sep 2009 15:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=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 325w2fIIaV7c for ; Thu, 10 Sep 2009 15:32:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4827E3A6861 for ; Thu, 10 Sep 2009 15:32:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CF7AC0022; Fri, 11 Sep 2009 00:33:23 +0200 (CEST) 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 pQTWun5WwSpT; Fri, 11 Sep 2009 00:33:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22C77C0014; Fri, 11 Sep 2009 00:33:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E3DB9C9C3EA; Fri, 11 Sep 2009 00:33:20 +0200 (CEST) Date: Fri, 11 Sep 2009 00:33:20 +0200 From: Juergen Schoenwaelder To: "Joseph Salowey (jsalowey)" Message-ID: <20090910223320.GB26279@elstar.local> Mail-Followup-To: "Joseph Salowey (jsalowey)" , 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] fingerprint TCs and hash types 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, 10 Sep 2009 22:32:49 -0000 On Fri, Sep 11, 2009 at 12:22:36AM +0200, Joseph Salowey (jsalowey) wrote: > If you are just looking for hashes there probably are already OIDs > for this defined for PKIX,PKCS,X509 etc. In addition for Syslog > TLS, RFC 5425, the fingerprint support references the names for hash > functions defined in IANA registry "Hash Function Textual Names" > allocated in RFC4572. This IANA registry looks great - we can simply MIBify those OID definitions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Sep 10 16:05: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 6AADF3A69A5 for ; Thu, 10 Sep 2009 16:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WlYoAyMPuUgw for ; Thu, 10 Sep 2009 16:04:59 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 62D0A3A67BD for ; Thu, 10 Sep 2009 16:04:59 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id EAAFA98132; Thu, 10 Sep 2009 16:05:34 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090910222921.GA26279@elstar.local> Date: Thu, 10 Sep 2009 16:05:34 -0700 In-Reply-To: <20090910222921.GA26279@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Sep 2009 00:29:21 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 23:05:00 -0000 >>>>> On Fri, 11 Sep 2009 00:29:21 +0200, Juergen Schoenwaelder said: JS> I am wondering what the correct term is here: fingerprint versus JS> (crptographic) hashvalue versus message digest. I originally used hash in a lot of places, but in the end because 5280 and 5425 (eg) refer specifically to "fingerprints" I decided that terminology should be the correct choice and was in fairly wide use in our other documentation. JS> My understanding is that FingerprintValue contains simply the output JS> generated by the hash function identified by FingerprintType, JS> correct? Correct. JS> In SNMP-USER-BASED-SM-MIB, we have object identifies for JS> authentication and encryption protocols and the relevant columns of JS> the tables use SNMPv2-SMI's AutonomousType. Can we do the same? Is JS> FingerprintType as a separate TC really needed? That's a good point. I wrote the TCs in an effort to more formally standardize the description of the type, as opposed to being generic. Otherwise you end up reproducing a lot of DESCRIPTION text everywhere describing what the column is supposed to refer to. Kind of like how TransportDomain is also defining something "common". Why wasn't a AutonomousType used for that instead? IMHO, we're trying to define a commonality among multiple objects (the MIB in the TLSTM document uses each one 3 times, for example). The USM MIB really doesn't. It uses a auth and priv algorithm in just one column in just one table. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Sep 10 16:06: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 738783A6B3F for ; Thu, 10 Sep 2009 16:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 mEchJfijeajo for ; Thu, 10 Sep 2009 16:06:55 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 971EC3A6B33 for ; Thu, 10 Sep 2009 16:06:55 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 908A698118; Thu, 10 Sep 2009 16:07:28 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <14020_1252615753_n8AKnCIV020344_sdhbvamsp4.fsf@wjh.hardakers.net> <5C883C4024B072DF9B6AF893@minbar.fac.cs.cmu.edu> Date: Thu, 10 Sep 2009 16:07:28 -0700 In-Reply-To: <5C883C4024B072DF9B6AF893@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 10 Sep 2009 18:13:09 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 23:06:56 -0000 >>>>> On Thu, 10 Sep 2009 18:13:09 -0400, Jeffrey Hutzelman said: JH> Then we should be going to PKIX or maybe even SAAG for advice. If JH> we're going to define something we expect to be reused, we should make JH> sure to get it right, or better, get it done right in a more JH> appropriate forum. Splitting it out into another document and running it quickly through another WG is certainly an option. In the end, I'd expect those other working groups to ask "how are you planning on using it?". It needs to be a joint effort and I disagree that "here" isn't the right place to discuss the "how to use it" aspect (which is one of the reasons the question was asking about the right SNMP data type to use). -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Thu Sep 10 16:24: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 7715F3A6850 for ; Thu, 10 Sep 2009 16:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 F4x921Ikje5Q for ; Thu, 10 Sep 2009 16:24:36 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 6D2583A6783 for ; Thu, 10 Sep 2009 16:24:36 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8ANP8UP028159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 19:25:08 -0400 (EDT) Date: Thu, 10 Sep 2009 19:25:08 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <204D4E9455D66BECEF7F54C6@minbar.fac.cs.cmu.edu> In-Reply-To: References: <14020_1252615753_n8AKnCIV020344_sdhbvamsp4.fsf@wjh.hardakers.net> <5C883C4024B072DF9B6AF893@minbar.fac.cs.cmu.edu> 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] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 23:24:37 -0000 --On Thursday, September 10, 2009 04:07:28 PM -0700 Wes Hardaker wrote: >>>>>> On Thu, 10 Sep 2009 18:13:09 -0400, Jeffrey Hutzelman >>>>>> said: > > JH> Then we should be going to PKIX or maybe even SAAG for advice. If > JH> we're going to define something we expect to be reused, we should make > JH> sure to get it right, or better, get it done right in a more > JH> appropriate forum. > > Splitting it out into another document and running it quickly through > another WG is certainly an option. In the end, I'd expect those other > working groups to ask "how are you planning on using it?". It needs to > be a joint effort and > I disagree that "here" isn't the right place to > discuss the "how to use it" aspect (which is one of the reasons the > question was asking about the right SNMP data type to use). I don't think I said that, and I certainly didn't intend to. Here is almost certainly the only reasonable place to talk about SNMP use of fingerprints. But defining a standard fingerprint format, especially if it's going to be used outside of SNMP, needs a broader audience than we typically have here. -- Jeff From wjhns1@hardakers.net Thu Sep 10 16:26: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 05C4328C251 for ; Thu, 10 Sep 2009 16:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 44x6R+bKDcCF for ; Thu, 10 Sep 2009 16:26:55 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 0758028C225 for ; Thu, 10 Sep 2009 16:26:54 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 0413098138; Thu, 10 Sep 2009 16:27:29 -0700 (PDT) From: Wes Hardaker To: "Joseph Salowey \(jsalowey\)" Organization: Sparta References: Date: Thu, 10 Sep 2009 16:27:28 -0700 In-Reply-To: (Joseph Salowey's message of "Thu, 10 Sep 2009 15:22:36 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 23:26:56 -0000 >>>>> On Thu, 10 Sep 2009 15:22:36 -0700, "Joseph Salowey (jsalowey)" said: JS> If you are just looking for hashes there probably are already OIDs JS> for this defined for PKIX,PKCS,X509 etc. True, but we need to be able to point to a common list that's agreed upon for this particular usage. It wouldn't be hard to create an "a list of externally defined OIDs" though, you're right. Many of those other OIDs will fall outside of the standard SNMP OID tree which I could see confusing some poorly written software, but I'm not sure that we should worry about them. JS> If you are looking for something that is specifying hash and JS> encoding then I'm not sure there is anything formally defined. It JS> would be nice if things lined up in some useful way with RFC 5425. Actually, I think 4.2.2 of RFC 5425 does define a standardized string for encoding fingerprints and maybe it would be easiest to reduce our 2 object pair (type/value) to a single ascii string that exactly references that string format. For those that don't want to pull up 4.2.2 of 5425, I'll reproduce it below: 4.2.2. Certificate Fingerprints Both client and server implementations MUST make the certificate fingerprints for their certificate available through a management interface. The labels for the algorithms are taken from the textual names of the hash functions as defined in the IANA registry "Hash Function Textual Names" allocated in [RFC4572]. The mechanism to generate a fingerprint is to take the hash of the DER-encoded certificate using a cryptographically strong algorithm, and convert the result into colon-separated, hexadecimal bytes, each represented by 2 uppercase ASCII characters. When a fingerprint value is displayed or configured, the fingerprint is prepended with an ASCII label identifying the hash function followed by a colon. Implementations MUST support SHA-1 as the hash algorithm and use the ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the length of the corresponding fingerprint string is 65 characters. An example certificate fingerprint is: sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D During validation the hash is extracted from the fingerprint and compared against the hash calculated over the received certificate. If we go this route, it makes the most sense to copy the format but still allow it to be used generically (IE, not just for certificate fingerprints). -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Sep 10 21:51: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 7248A3A689E for ; Thu, 10 Sep 2009 21:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 eKwYNaNYyuvd for ; Thu, 10 Sep 2009 21:51:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 38F4D3A6783 for ; Thu, 10 Sep 2009 21:51:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15AF4C000F; Fri, 11 Sep 2009 06:51:40 +0200 (CEST) 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 6tltPsVRjowI; Fri, 11 Sep 2009 06:51:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CB07C0007; Fri, 11 Sep 2009 06:51:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6DB04C9C801; Fri, 11 Sep 2009 06:51:36 +0200 (CEST) Date: Fri, 11 Sep 2009 06:51:36 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090911045136.GA26629@elstar.local> Mail-Followup-To: Wes Hardaker , "Joseph Salowey (jsalowey)" , "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] fingerprint TCs and hash types 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, 11 Sep 2009 04:51:18 -0000 On Fri, Sep 11, 2009 at 01:27:28AM +0200, Wes Hardaker wrote: > Actually, I think 4.2.2 of RFC 5425 does define a standardized string > for encoding fingerprints and maybe it would be easiest to reduce our 2 > object pair (type/value) to a single ascii string that exactly > references that string format. > > For those that don't want to pull up 4.2.2 of 5425, I'll reproduce it > below: > > 4.2.2. Certificate Fingerprints > > Both client and server implementations MUST make the certificate > fingerprints for their certificate available through a management > interface. The labels for the algorithms are taken from the textual > names of the hash functions as defined in the IANA registry "Hash > Function Textual Names" allocated in [RFC4572]. > > The mechanism to generate a fingerprint is to take the hash of the > DER-encoded certificate using a cryptographically strong algorithm, > and convert the result into colon-separated, hexadecimal bytes, each > represented by 2 uppercase ASCII characters. When a fingerprint > value is displayed or configured, the fingerprint is prepended with > an ASCII label identifying the hash function followed by a colon. > Implementations MUST support SHA-1 as the hash algorithm and use the > ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a > SHA-1 hash is 20 bytes and the length of the corresponding > fingerprint string is 65 characters. An example certificate > fingerprint is: > > sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > During validation the hash is extracted from the fingerprint and > compared against the hash calculated over the received certificate. > > If we go this route, it makes the most sense to copy the format but > still allow it to be used generically (IE, not just for certificate > fingerprints). In general, I like this format. The downside of course is its length compared to an OCTET STRING representation: sha-1 20 65 sha-256 32 103 sha-512 64 199 The second column shows the length of the hash and the third column the length of the fingerprint (including the label). With sha-512, we are still well below the common 255 octet boundary but the overhead is significant and even the sha-1 fingerprint easily allows to ship an additional varbind while still saving space. Note the terminology apparently used in RFC 5425: the hash is the value generated by the hash function and the fingerprint is the stringified tagged representation of the hash value. This makes sense to me and we should try to align with it - so the question really becomes whether we represent hash values or fingerprints. /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 Sep 11 06:50:39 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 9EE163A6899 for ; Fri, 11 Sep 2009 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 k28559dZLSjs for ; Fri, 11 Sep 2009 06:50:38 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 1036C3A67D2 for ; Fri, 11 Sep 2009 06:50:38 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D2982981A5; Fri, 11 Sep 2009 06:51:14 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090911045136.GA26629@elstar.local> Date: Fri, 11 Sep 2009 06:51:14 -0700 In-Reply-To: <20090911045136.GA26629@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Sep 2009 06:51:36 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 13:50:39 -0000 >>>>> On Fri, 11 Sep 2009 06:51:36 +0200, Juergen Schoenwaelder said: JS> In general, I like this format. The downside of course is its length JS> compared to an OCTET STRING representation: JS> sha-1 20 65 JS> sha-256 32 103 JS> sha-512 64 199 Yep. I thought about it. But the upside of human readability and string management might outweigh it. Most management tools do deal with hex <-> binary conversion fairly well, but this is still probably easier in the end. Another win, though, is that the prefixes are already standardized and we don't need to do anything else. JS> The second column shows the length of the hash and the third column JS> the length of the fingerprint (including the label). With sha-512, we JS> are still well below the common 255 octet boundary but the overhead is JS> significant and even the sha-1 fingerprint easily allows to ship an JS> additional varbind while still saving space. If you're counting bytes in terms of bytes on the wire, you probably need to include the type encoding as well for the second column that holds the type which will be 2 OIDs in size length (adding in the length for the column OID and the value OID). However, the results will still be small compared to the ascii encoding. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Fri Sep 11 06:54: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 AFEAA3A6972 for ; Fri, 11 Sep 2009 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 OEk67sbqUtDj for ; Fri, 11 Sep 2009 06:54:28 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B29643A6899 for ; Fri, 11 Sep 2009 06:54:28 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BF700981A9; Fri, 11 Sep 2009 06:55:05 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <14020_1252615753_n8AKnCIV020344_sdhbvamsp4.fsf@wjh.hardakers.net> <5C883C4024B072DF9B6AF893@minbar.fac.cs.cmu.edu> <204D4E9455D66BECEF7F54C6@minbar.fac.cs.cmu.edu> Date: Fri, 11 Sep 2009 06:55:05 -0700 In-Reply-To: <204D4E9455D66BECEF7F54C6@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 10 Sep 2009 19:25:08 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 13:54:29 -0000 >>>>> On Thu, 10 Sep 2009 19:25:08 -0400, Jeffrey Hutzelman said: JH> Here is almost certainly the only reasonable place to talk about JH> SNMP use of But defining a standard fingerprint format, especially JH> if it's going to be used outside of SNMP, needs a broader audience JH> than we typically have here. I never tried to imply we were standardizing something that would be used outside of SNMP. The TC that was defined was only for SNMP use. And, I suppose, things that may derive from it some day (e.g. netconf). -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Fri Sep 11 09:22: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 5770F3A6952 for ; Fri, 11 Sep 2009 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtjTXvcDYUH7 for ; Fri, 11 Sep 2009 09:22:49 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 87EA83A6922 for ; Fri, 11 Sep 2009 09:22:49 -0700 (PDT) Received: from [173.124.133.143] (173-124-133-143.pools.spcsdns.net [173.124.133.143]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8BGNHCd010131 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Sep 2009 12:23:21 -0400 (EDT) From: "Jeffrey Hutzelman" Date: 11 Sep 2009 12:23:00 -0400 To: X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.18) Message-ID: <3335516604.8072868@smtp.srv.cs.cmu.edu> X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: isms@ietf.org Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 16:22:50 -0000 Oh; that's different. -----Original Message----- From: Wes Hardaker Date: Friday, Sep 11, 2009 9:55 am Subject: Re: fingerprint TCs and hash types To: Jeffrey Hutzelman CC: Wes Hardaker , isms@ietf.org >>>>> On Thu, 10 Sep 2009 19:25:08 -0400, Jeffrey Hutzelman said: > >JH> Here is almost certainly the only reasonable place to talk about JH> SNMP use of But defining a standard fingerprint format, especially JH> if it's going to be used outside of SNMP, needs a broader audience JH> than we typically have here. > >I never tried to imply we were standardizing something that would be used outside of SNMP. The TC that was defined was only for SNMP use. And, I suppose, things that may derive from it some day (e.g. netconf). >-- >Wes Hardaker >Cobham Analytic Solutions > > From j.schoenwaelder@jacobs-university.de Fri Sep 11 09:51: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 E5E5B3A6892 for ; Fri, 11 Sep 2009 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 xacQGMiCvh21 for ; Fri, 11 Sep 2009 09:51:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9EDD13A6813 for ; Fri, 11 Sep 2009 09:51:14 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA460C000F; Fri, 11 Sep 2009 18:51:51 +0200 (CEST) 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 LFz8W-qUMYgD; Fri, 11 Sep 2009 18:51:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BA4FC0007; Fri, 11 Sep 2009 18:51:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A7E2DC9D525; Fri, 11 Sep 2009 18:51:48 +0200 (CEST) Date: Fri, 11 Sep 2009 18:51:48 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090911165148.GD27905@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20090911045136.GA26629@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] fingerprint TCs and hash types 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, 11 Sep 2009 16:51:16 -0000 On Fri, Sep 11, 2009 at 03:51:14PM +0200, Wes Hardaker wrote: > >>>>> On Fri, 11 Sep 2009 06:51:36 +0200, Juergen Schoenwaelder said: > > JS> In general, I like this format. The downside of course is its length > JS> compared to an OCTET STRING representation: > > JS> sha-1 20 65 > JS> sha-256 32 103 > JS> sha-512 64 199 > > Yep. I thought about it. But the upside of human readability and > string management might outweigh it. Most management tools do deal with > hex <-> binary conversion fairly well, but this is still probably easier > in the end. > > Another win, though, is that the prefixes are already standardized and > we don't need to do anything else. There are networks (such as 802.15.4/6LoWPAN) where DTLS might be a perfect fit since its session nature reduces per message overhead and the message size constraints are significant here. > JS> The second column shows the length of the hash and the third column > JS> the length of the fingerprint (including the label). With sha-512, we > JS> are still well below the common 255 octet boundary but the overhead is > JS> significant and even the sha-1 fingerprint easily allows to ship an > JS> additional varbind while still saving space. > > If you're counting bytes in terms of bytes on the wire, you probably > need to include the type encoding as well for the second column that > holds the type which will be 2 OIDs in size length (adding in the length > for the column OID and the value OID). However, the results will still > be small compared to the ascii encoding. It does seem inconsistent to be on the one hand happy with an IANA register for fingerprint names while you want unlimited number space extensibility with OIDs. I vote for a small integer, if needed partition the integer number space like we do for say security models. Or simply ship a string such as "sha-1". (BTW, does the relevant RFC specify how to create non-standard names, e.g. an "x-" escape?) But in general, I think we do not necessarily need to provide more flexibility than the PKI specs provide. /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 Sep 11 11:04: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 77BA63A698C for ; Fri, 11 Sep 2009 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 omwX8H-G2Dzj for ; Fri, 11 Sep 2009 11:04:50 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 80C173A685C for ; Fri, 11 Sep 2009 11:04:50 -0700 (PDT) Received: from localhost (unknown [10.1.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 1759A9815A; Fri, 11 Sep 2009 11:05:28 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090911045136.GA26629@elstar.local> <20090911165148.GD27905@elstar.local> Date: Fri, 11 Sep 2009 11:05:27 -0700 In-Reply-To: <20090911165148.GD27905@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Sep 2009 18:51:48 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 18:04:51 -0000 >>>>> On Fri, 11 Sep 2009 18:51:48 +0200, Juergen Schoenwaelder said: >> Another win, though, is that the prefixes are already standardized and >> we don't need to do anything else. JS> There are networks (such as 802.15.4/6LoWPAN) where DTLS might be a JS> perfect fit since its session nature reduces per message overhead and JS> the message size constraints are significant here. True, but sort of off topic for the thread I think since it was about a MIB object's contents? I'm not saying it's not an interesting point (it is!), I'm just trying to make sure we don't have a disconnect in the conversation. JS> It does seem inconsistent to be on the one hand happy with an IANA JS> register for fingerprint names while you want unlimited number space JS> extensibility with OIDs. I vote for a small integer, if needed JS> partition the integer number space like we do for say security models. JS> Or simply ship a string such as "sha-1". (BTW, does the relevant RFC JS> specify how to create non-standard names, e.g. an "x-" escape?) But JS> in general, I think we do not necessarily need to provide more JS> flexibility than the PKI specs provide. I'm now a bit confused about where your technical opinion lies, since you've been professing the positive and negative attributes of all the possibilities. Would you prefer: 1) a single ascii encoding with type prefix that matches the other PKIX RFC(s) 2) an integer (possibly partitioned) and a binary encoded value 3) an OID and a binary encoded value I think all the points you've brought up are good ones. I'm not sure what side of the fence you ended up on. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Fri Sep 11 11:22: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 9A9EE3A6942 for ; Fri, 11 Sep 2009 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=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 0GlE4jz4YhT9 for ; Fri, 11 Sep 2009 11:22:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 49E613A68A7 for ; Fri, 11 Sep 2009 11:22:22 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E238CC000F; Fri, 11 Sep 2009 20:22:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 619d6YBHS4pH; Fri, 11 Sep 2009 20:22:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F0B9C0007; Fri, 11 Sep 2009 20:22:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06B23C9D716; Fri, 11 Sep 2009 20:22:56 +0200 (CEST) Date: Fri, 11 Sep 2009 20:22:56 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090911182256.GB28043@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20090911045136.GA26629@elstar.local> <20090911165148.GD27905@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] fingerprint TCs and hash types 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, 11 Sep 2009 18:22:23 -0000 On Fri, Sep 11, 2009 at 08:05:27PM +0200, Wes Hardaker wrote: > >>>>> On Fri, 11 Sep 2009 18:51:48 +0200, Juergen Schoenwaelder said: > > >> Another win, though, is that the prefixes are already standardized and > >> we don't need to do anything else. > > JS> There are networks (such as 802.15.4/6LoWPAN) where DTLS might be a > JS> perfect fit since its session nature reduces per message overhead and > JS> the message size constraints are significant here. > > True, but sort of off topic for the thread I think since it was about a > MIB object's contents? I'm not saying it's not an interesting point (it > is!), I'm just trying to make sure we don't have a disconnect in the > conversation. I thought the MIB objects are there to support SNMP over DTLS so I consider them relevant for a 6LoWPAN environment. (The message size in those environments is really small - 127 octets excluding frame header) and fragmentation is pretty bad and buffer sizes are limited as well. So from this perspective, it prefer a binary OCTET STRING for the hash value. > JS> It does seem inconsistent to be on the one hand happy with an IANA > JS> register for fingerprint names while you want unlimited number space > JS> extensibility with OIDs. I vote for a small integer, if needed > JS> partition the integer number space like we do for say security models. > JS> Or simply ship a string such as "sha-1". (BTW, does the relevant RFC > JS> specify how to create non-standard names, e.g. an "x-" escape?) But > JS> in general, I think we do not necessarily need to provide more > JS> flexibility than the PKI specs provide. > > I'm now a bit confused about where your technical opinion lies, since > you've been professing the positive and negative attributes of all the > possibilities. > > Would you prefer: > > 1) a single ascii encoding with type prefix that matches the other PKIX RFC(s) > 2) an integer (possibly partitioned) and a binary encoded value > 3) an OID and a binary encoded value > > I think all the points you've brought up are good ones. I'm not sure > what side of the fence you ended up on. I prefer a binary OCTET STRING encoding together with a 1x: DISPLAY-HINT. I have the feeling that an OID is overkill and I prefer a compact IANA maintained INTEGER TC. Depending on the IANA rules and if people seriously see a need for enterprise specific hash functions, I suggest to partition the INTEGER space following the Snmp*Model textual conventions. /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 Sep 11 11:42: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 7542428C1C7 for ; Fri, 11 Sep 2009 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_45=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 Of-YkInecDg9 for ; Fri, 11 Sep 2009 11:42:24 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 782D528C1B5 for ; Fri, 11 Sep 2009 11:42:24 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 37B8E98168; Fri, 11 Sep 2009 11:43:01 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090911045136.GA26629@elstar.local> <20090911165148.GD27905@elstar.local> <20090911182256.GB28043@elstar.local> Date: Fri, 11 Sep 2009 11:43:00 -0700 In-Reply-To: <20090911182256.GB28043@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Sep 2009 20:22:56 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] fingerprint TCs and hash types X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 18:42:25 -0000 >>>>> On Fri, 11 Sep 2009 20:22:56 +0200, Juergen Schoenwaelder said: JS> I thought the MIB objects are there to support SNMP over DTLS so I JS> consider them relevant for a 6LoWPAN environment. (The message size in JS> those environments is really small - 127 octets excluding frame JS> header) and fragmentation is pretty bad and buffer sizes are limited JS> as well. So from this perspective, it prefer a binary OCTET STRING for JS> the hash value. Ahh... I missed that point. You want to make sure our objects our manageable in that environment. Check. JS> I prefer a binary OCTET STRING encoding together with a 1x: JS> DISPLAY-HINT. I have the feeling that an OID is overkill and I prefer JS> a compact IANA maintained INTEGER TC. Depending on the IANA rules and JS> if people seriously see a need for enterprise specific hash functions, JS> I suggest to partition the INTEGER space following the Snmp*Model JS> textual conventions. I know of people that use enterprise specific hash functions, so I do think we need to make room for it one way or another. Thanks for solidifying your opinion; I understand it clearly now. -- Wes Hardaker Cobham Analytic Solutions From adonati@motorola.com Mon Sep 14 09:40: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 F1B833A67C1 for ; Mon, 14 Sep 2009 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 d33sGQGvCDUV for ; Mon, 14 Sep 2009 09:40:24 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 94FBE3A68CC for ; Mon, 14 Sep 2009 09:40:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-3.tower-55.messagelabs.com!1252946460!10554120!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32136 invoked from network); 14 Sep 2009 16:41:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2009 16:41:01 -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 n8EGf0E0010985 for ; Mon, 14 Sep 2009 09:41:00 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n8EGf0eH008882 for ; Mon, 14 Sep 2009 11:41:00 -0500 (CDT) 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 n8EGf0Sb008879 for ; Mon, 14 Sep 2009 11:41:00 -0500 (CDT) 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, 14 Sep 2009 12:40:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications thread-index: Acn06RB5KUBsk/30R6KYODVBYB02jRAcDZjg References: From: "Donati Andrew-MGIA0477" To: "Wes Hardaker" , X-CFilter-Loop: Reflected Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 16:40:26 -0000 Wes, Will it be feasible to define optional notifications for each the=20 events defined by the counters below ? tlstmSessionInvalidClientCertificates tlstmSessionInvalidServerCertificates=20 - Andy Donati Motorola HN&M -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Wes Hardaker Sent: Wednesday, June 24, 2009 12:30 PM To: isms@ietf.org Subject: [Isms] draft-hardaker-isms-dtls-tm-05 submitted I've just posted an updated version of my DTLS draft. I've left the name the same until it becomes a WG document after the charter is approved, at which point I'll drop the 'd' in the draft title so it's just '-tls'. The biggest change in this version of the draft is the incorporation of the straight TLS transport in addition to the DTLS transport previously described. Most of the text changes are very straight forward as the text was fairly generically pointed to TLS related features in the first place. In a few places, however, TLS or DTLS are specifically called out. http://www.ietf.org/internet-drafts/draft-hardaker-isms-dtls-tm-05.txt -- Wes Hardaker Cobham Analytic Solutions _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From wjhns1@hardakers.net Mon Sep 14 10:36:12 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 1F50328C142 for ; Mon, 14 Sep 2009 10:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK+8+J5i9fFY for ; Mon, 14 Sep 2009 10:36:11 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 25CE13A6A95 for ; Mon, 14 Sep 2009 10:36:11 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id AB43598146; Mon, 14 Sep 2009 10:36:55 -0700 (PDT) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: Date: Mon, 14 Sep 2009 10:36:55 -0700 In-Reply-To: (Donati Andrew-MGIA's message of "Mon, 14 Sep 2009 12:40:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 17:36:12 -0000 >>>>> On Mon, 14 Sep 2009 12:40:38 -0400, "Donati Andrew-MGIA0477" said: DA> Will it be feasible to define optional notifications for each the DA> events defined by the counters below ? DA> tlstmSessionInvalidClientCertificates DA> tlstmSessionInvalidServerCertificates I think it's a good idea to have notifications defined for those two cases. The likely triggering points would be: 1) tlstmSessionInvalidClientCertificates - command responder, notification responder or proxy application receives a client cert it can't cope with. 2) tlstmSessionInvalidServerCertificates - a command generator in a remote device (e.g., disman-event mib type functionality or ...) or proxy application receives a server cert it can't cope with. - in theory a local manager could trigger this condition too, but it doesn't make as much sense. There is no reason to say they can't send it though. The interesting question is that for #1, we actually already have such a notification in a more generic form: the authenticationFailure notification from the SNMPv2-MIB. The questions in my mind are: A) should we include a more specific one for DTLS B) should we specify in the documentation other likely (recommend) DTLS specific variables to add to the generic authenticationFailure notification when being sent? -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Sep 14 11:28:46 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 C2E3B28C170 for ; Mon, 14 Sep 2009 11:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 911vXZktzdB9 for ; Mon, 14 Sep 2009 11:28:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6E053A6908 for ; Mon, 14 Sep 2009 11:28:45 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B78EC000D; Mon, 14 Sep 2009 20:29:30 +0200 (CEST) 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 aO2sMmnicHal; Mon, 14 Sep 2009 20:29:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32544C0003; Mon, 14 Sep 2009 20:29:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CABA3CB392B; Mon, 14 Sep 2009 20:29:18 +0200 (CEST) Date: Mon, 14 Sep 2009 20:29:18 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090914182918.GA1332@elstar.local> Mail-Followup-To: Wes Hardaker , Donati Andrew-MGIA0477 , "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] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications 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, 14 Sep 2009 18:28:46 -0000 On Mon, Sep 14, 2009 at 07:36:55PM +0200, Wes Hardaker wrote: > >>>>> On Mon, 14 Sep 2009 12:40:38 -0400, "Donati Andrew-MGIA0477" said: > > DA> Will it be feasible to define optional notifications for each the > DA> events defined by the counters below ? > > DA> tlstmSessionInvalidClientCertificates > DA> tlstmSessionInvalidServerCertificates > > I think it's a good idea to have notifications defined for those two > cases. The likely triggering points would be: > > 1) tlstmSessionInvalidClientCertificates > > - command responder, notification responder or proxy application > receives a client cert it can't cope with. > > 2) tlstmSessionInvalidServerCertificates > > - a command generator in a remote device (e.g., disman-event mib type > functionality or ...) or proxy application receives a server cert > it can't cope with. > > - in theory a local manager could trigger this condition too, but it > doesn't make as much sense. There is no reason to say they can't > send it though. The question is to what extend the SNMP agent is really involved in all this or whether the DTLS transport takes care of the processing itself. In the SNMP over SSH case, we did decide to stay out of things that really concern the SSH layer. It seems with TLS/DTLS, we seem to go into much more details - perhaps this is even justified. I just notice that we seem to deal with these different secure transports differently. /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 Sep 14 12:01: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 E179A3A6A18 for ; Mon, 14 Sep 2009 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 psjI6ja1Ncwv for ; Mon, 14 Sep 2009 12:01:29 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B923D3A690F for ; Mon, 14 Sep 2009 12:01:15 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 93E3E98180; Mon, 14 Sep 2009 12:02:00 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090914182918.GA1332@elstar.local> Date: Mon, 14 Sep 2009 12:02:00 -0700 In-Reply-To: <20090914182918.GA1332@elstar.local> (Juergen Schoenwaelder's message of "Mon, 14 Sep 2009 20:29:18 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 19:01:30 -0000 >>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder said: JS> The question is to what extend the SNMP agent is really involved in JS> all this or whether the DTLS transport takes care of the processing JS> itself. In the SNMP over SSH case, we did decide to stay out of things JS> that really concern the SSH layer. It seems with TLS/DTLS, we seem to JS> go into much more details - perhaps this is even justified. I just JS> notice that we seem to deal with these different secure transports JS> differently. I'd argue that if it helps the operator it doesn't matter much. We're not violating layers because we want to help manage a transport just as we're not violating layers when we send a linkUp notification (which if you drew an architectural diagram, would be way outside the SNMPv3 blocks). In other words, do we want managers to be able to get notifications about failed (D)TLS connections? If yes, then we need to define the notifications and it's implementation specific as to how to detect the need to send them. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Mon Sep 14 12:08: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 D94BA3A6867 for ; Mon, 14 Sep 2009 12:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrYxvC2hJqwu for ; Mon, 14 Sep 2009 12:08:20 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 077723A67F1 for ; Mon, 14 Sep 2009 12:08:19 -0700 (PDT) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8EJ8ub9029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 15:08:58 -0400 (EDT) Date: Mon, 14 Sep 2009 15:08:56 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: In-Reply-To: <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 19:08:20 -0000 --On Monday, September 14, 2009 12:02:00 PM -0700 Wes Hardaker wrote: >>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder >>>>>> said: > > JS> The question is to what extend the SNMP agent is really involved in > JS> all this or whether the DTLS transport takes care of the processing > JS> itself. In the SNMP over SSH case, we did decide to stay out of things > JS> that really concern the SSH layer. It seems with TLS/DTLS, we seem to > JS> go into much more details - perhaps this is even justified. I just > JS> notice that we seem to deal with these different secure transports > JS> differently. > > I'd argue that if it helps the operator it doesn't matter much. We're > not violating layers because we want to help manage a transport just as > we're not violating layers when we send a linkUp notification (which if > you drew an architectural diagram, would be way outside the SNMPv3 > blocks). > > In other words, do we want managers to be able to get notifications > about failed (D)TLS connections? If yes, then we need to define the > notifications and it's implementation specific as to how to detect the > need to send them. Agree. We're not talking here about the SNMP agent breaking layers and looking at things it has no business knowing about. We're talking about the (D)TLS transport itself being manageable. -- Jeff From j.schoenwaelder@jacobs-university.de Mon Sep 14 13:13:41 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 A4F543A6984 for ; Mon, 14 Sep 2009 13:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 GSeX2rYfT24K for ; Mon, 14 Sep 2009 13:13:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4BA9728C190 for ; Mon, 14 Sep 2009 13:13:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AA19C000D; Mon, 14 Sep 2009 22:14:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SgNaiEl48WUO; Mon, 14 Sep 2009 22:14:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6E56C0003; Mon, 14 Sep 2009 22:14:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8FECCCB3CB9; Mon, 14 Sep 2009 22:14:19 +0200 (CEST) Date: Mon, 14 Sep 2009 22:14:19 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090914201419.GE1376@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , Wes Hardaker , "isms@ietf.org" References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> 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] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications 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, 14 Sep 2009 20:13:41 -0000 On Mon, Sep 14, 2009 at 09:08:56PM +0200, Jeffrey Hutzelman wrote: > --On Monday, September 14, 2009 12:02:00 PM -0700 Wes Hardaker > wrote: > > >>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder > >>>>>> said: > > > > JS> The question is to what extend the SNMP agent is really involved in > > JS> all this or whether the DTLS transport takes care of the processing > > JS> itself. In the SNMP over SSH case, we did decide to stay out of things > > JS> that really concern the SSH layer. It seems with TLS/DTLS, we seem to > > JS> go into much more details - perhaps this is even justified. I just > > JS> notice that we seem to deal with these different secure transports > > JS> differently. > > > > I'd argue that if it helps the operator it doesn't matter much. We're > > not violating layers because we want to help manage a transport just as > > we're not violating layers when we send a linkUp notification (which if > > you drew an architectural diagram, would be way outside the SNMPv3 > > blocks). > > > > In other words, do we want managers to be able to get notifications > > about failed (D)TLS connections? If yes, then we need to define the > > notifications and it's implementation specific as to how to detect the > > need to send them. > > Agree. We're not talking here about the SNMP agent breaking layers and > looking at things it has no business knowing about. We're talking about > the (D)TLS transport itself being manageable. But in the case of SSH, we decided to _not_ go into SSH details and leave that to future SSH management work. I just noticed that we seem to treat TLS/DTLS different. I am not saying this is good or bad (and I am speaking as a technical contributor). All I want to achieve is that we reflect the reasons if we do things differently for different transports. /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 Mon Sep 14 13: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 EA25A3A691C for ; Mon, 14 Sep 2009 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, 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 5hxX0ezHCmrm for ; Mon, 14 Sep 2009 13:27:42 -0700 (PDT) Received: from QMTA14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id B545D3A6867 for ; Mon, 14 Sep 2009 13:27:41 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA14.westchester.pa.mail.comcast.net with comcast id gbEA1c00E0mv7h05EkUThl; Mon, 14 Sep 2009 20:28:27 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id gkUT1c0060UQ6dC3XkUTVA; Mon, 14 Sep 2009 20:28:27 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Wes Hardaker'" References: <20090914182918.GA1332@elstar.local><27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> Date: Mon, 14 Sep 2009 16:28:26 -0400 Message-ID: <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aco1btwruoqSFGmtRHWo9w02YV5yCAAAJtbQ Cc: isms@ietf.org Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 20:27:43 -0000 Hi, It looks to me like we *would* be violating layers. If (D)TLS gets an invalid certificate, will it still pass the payload to SNMP? If (D)TLS gets an invalid certificate during the "service authorization" step, will it even start the SNMP service? In SSHTM, we document what we know after asking for a session to be opened or closed - i.e., it failed. We make the assumption we can tell whether the failure was a user-authentication failure or a server-authentication failure or a channel-open failure or a subsystem failure. We do not assume we know what authentication method was used when authentication failed; we have one error counter for userauth failure and another for serverauth failure, whether SSH used passwords or certificates or some other method to perform the authentication. I think the InvalidClientCertificate and InvalidServercertificate counters cross the line into (D)TLS specific processing. If you want insight into what is happening at the (D)TLS "layer", then you should write a (D)TLS MIB to capture that information. That does not belong in the transport model though, just as the specific SSH failures do not get documented in the SSHTM MIB. Think of it this way. If you write a generic (D)TLS MIB that recorded InvalidClientCertificates and InvalidServercertificates, would these only be incremented when SNMP was the protocol utilizing the (D)TLS service, or might they also be incremented when using, say, IPFIX or Netconf or HTTP? I think these are (D)TLS-specific errors, not SNMP-TM-specific errors. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Jeffrey Hutzelman > Sent: Monday, September 14, 2009 3:09 PM > To: Wes Hardaker > Cc: isms@ietf.org; jhutz@cmu.edu > Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted > - tlstmNotifications > > --On Monday, September 14, 2009 12:02:00 PM -0700 Wes Hardaker > wrote: > > >>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder > >>>>>> said: > > > > JS> The question is to what extend the SNMP agent is really > involved in > > JS> all this or whether the DTLS transport takes care of > the processing > > JS> itself. In the SNMP over SSH case, we did decide to > stay out of things > > JS> that really concern the SSH layer. It seems with > TLS/DTLS, we seem to > > JS> go into much more details - perhaps this is even > justified. I just > > JS> notice that we seem to deal with these different secure > transports > > JS> differently. > > > > I'd argue that if it helps the operator it doesn't matter > much. We're > > not violating layers because we want to help manage a > transport just as > > we're not violating layers when we send a linkUp > notification (which if > > you drew an architectural diagram, would be way outside the SNMPv3 > > blocks). > > > > In other words, do we want managers to be able to get notifications > > about failed (D)TLS connections? If yes, then we need to define the > > notifications and it's implementation specific as to how to > detect the > > need to send them. > > Agree. We're not talking here about the SNMP agent breaking > layers and > looking at things it has no business knowing about. We're > talking about > the (D)TLS transport itself being manageable. > > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Mon Sep 14 13:51: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 2DEE03A692A for ; Mon, 14 Sep 2009 13:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 fZqiPzaYA9m7 for ; Mon, 14 Sep 2009 13:51:57 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 33CA33A691C for ; Mon, 14 Sep 2009 13:51:57 -0700 (PDT) Received: from [10.0.0.3] (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 n8EKqVGS022500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 16:52:31 -0400 (EDT) Date: Mon, 14 Sep 2009 16:52:31 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" Message-ID: <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> In-Reply-To: <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 20:51:58 -0000 --On Monday, September 14, 2009 04:28:26 PM -0400 David Harrington wrote: > If you want insight into what is happening at the (D)TLS "layer", then > you should write a (D)TLS MIB to capture that information. That does > not belong in the transport model though, just as the specific SSH > failures do not get documented in the SSHTM MIB. > > Think of it this way. If you write a generic (D)TLS MIB that recorded > InvalidClientCertificates and InvalidServercertificates, would these > only be incremented when SNMP was the protocol utilizing the (D)TLS > service, or might they also be incremented when using, say, IPFIX or > Netconf or HTTP? I think these are (D)TLS-specific errors, not > SNMP-TM-specific errors. There really isn't such a thing as "_the_ (D)TLS service". A given host might have any number of services utilizing TLS or DTLS on different ports with different configuration. It's not multiplexed the way SSH might be, and you wouldn't want to combine management information for them. Ideally, there'd be some kind of "MIB fragment" describing (D)TLS which could be incorporated into MIB's for various services using those protocols, of which the SNMP DTLS TM is just one. From ietfdbh@comcast.net Mon Sep 14 13:55: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 A82463A692E for ; Mon, 14 Sep 2009 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 FQNADEkrcvWX for ; Mon, 14 Sep 2009 13:55:31 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id AEC4A3A68B3 for ; Mon, 14 Sep 2009 13:55:31 -0700 (PDT) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA08.westchester.pa.mail.comcast.net with comcast id gi101c00l1swQuc58kw4KR; Mon, 14 Sep 2009 20:56:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA15.westchester.pa.mail.comcast.net with comcast id gl1l1c0050UQ6dC3bl1lS5; Mon, 14 Sep 2009 21:01:45 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Wes Hardaker'" References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> Date: Mon, 14 Sep 2009 16:56:16 -0400 Message-ID: <033e01ca357d$cd57ade0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aco1fUnevmf8G7VXRaKmVknvZ2yrgQAAFD2g Cc: isms@ietf.org Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 20:55:32 -0000 If one were to implement the DTLS-TM using a DTLS toolkit, would the SNMP side of the API likely know why that the client certificate was invalid, or would that likely be internal to the toolkit? dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Monday, September 14, 2009 4:53 PM > To: David Harrington; 'Wes Hardaker' > Cc: isms@ietf.org; jhutz@cmu.edu > Subject: RE: [Isms] draft-hardaker-isms-dtls-tm-05 submitted > - tlstmNotifications > > --On Monday, September 14, 2009 04:28:26 PM -0400 David Harrington > wrote: > > > If you want insight into what is happening at the (D)TLS > "layer", then > > you should write a (D)TLS MIB to capture that information. That does > > not belong in the transport model though, just as the specific SSH > > failures do not get documented in the SSHTM MIB. > > > > Think of it this way. If you write a generic (D)TLS MIB > that recorded > > InvalidClientCertificates and InvalidServercertificates, would these > > only be incremented when SNMP was the protocol utilizing the (D)TLS > > service, or might they also be incremented when using, say, IPFIX or > > Netconf or HTTP? I think these are (D)TLS-specific errors, not > > SNMP-TM-specific errors. > > There really isn't such a thing as "_the_ (D)TLS service". A > given host > might have any number of services utilizing TLS or DTLS on > different ports > with different configuration. It's not multiplexed the way > SSH might be, > and you wouldn't want to combine management information for > them. Ideally, > there'd be some kind of "MIB fragment" describing (D)TLS > which could be > incorporated into MIB's for various services using those > protocols, of > which the SNMP DTLS TM is just one. > From wjhns1@hardakers.net Mon Sep 14 14:07: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 A177F3A6AB4 for ; Mon, 14 Sep 2009 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_31=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 mbMf2zBZQ4bC for ; Mon, 14 Sep 2009 14:07:16 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 9B31328C1AE for ; Mon, 14 Sep 2009 14:07:04 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 665BF9805C; Mon, 14 Sep 2009 14:07:49 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> <033e01ca357d$cd57ade0$0600a8c0@china.huawei.com> Date: Mon, 14 Sep 2009 14:07:49 -0700 In-Reply-To: <033e01ca357d$cd57ade0$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 14 Sep 2009 16:56:16 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 21:07:17 -0000 >>>>> On Mon, 14 Sep 2009 16:56:16 -0400, "David Harrington" said: DH> If one were to implement the DTLS-TM using a DTLS toolkit, would the DH> SNMP side of the API likely know why that the client certificate was DH> invalid, or would that likely be internal to the toolkit? 1) Yes. I've seen the openssl code and know that you can determine this exact situation. 2) IMHO, it doesn't matter. It's not up to us to specify how a service gets managed. As an example, many of the interface counters, for example, were put into "exporting data" code in the linux kernel because SNMP needed access to them. There are only two cases: A) A (D)TLS implementation can export the situation already today within the existing APIs (such as the case for OpenSSL, as mentioned above). B) A (D)TLS implementation can not export the data and as far as the client goes, it's a silent fail with a generic error. If this is the case, then one of three things must happen: i) the SSL implementation implements a mechanism through "some manner" so that the invalid-certificate notification can be sent by the application using the SSL API. Maybe through a new error code, or whatever. ii) the SSL implementation implements an internal "I got a problem" event and sends through some aspect to anyone listening. A listener (possibly the SNMP agent application) would listen for a problem and send a notification when it received that internal software event. iii) the SSL implementation won't export the details that a problem has occurred problem through any method. This leaves the SNMP agent implementation out of luck as it simply can't send the notification at all. If we think this is possible, wouldn't it make more sense to put the notification into an optional conformance group than to not put it in at all? And eventually, hopefully, all iii)s would eventually transition to either i) or ii). -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Sep 14 14:17:41 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 8B75B3A6AB4 for ; Mon, 14 Sep 2009 14:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 473BBYsRkQpJ for ; Mon, 14 Sep 2009 14:17:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 625773A690D for ; Mon, 14 Sep 2009 14:17:40 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ADADC0010; Mon, 14 Sep 2009 23:18:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZVsTVZM8fedw; Mon, 14 Sep 2009 23:18:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 640CDC000D; Mon, 14 Sep 2009 23:18:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 27015CB3F37; Mon, 14 Sep 2009 23:18:17 +0200 (CEST) Date: Mon, 14 Sep 2009 23:18:17 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090914211817.GD1493@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David Harrington , 'Wes Hardaker' , "isms@ietf.org" References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications 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, 14 Sep 2009 21:17:41 -0000 On Mon, Sep 14, 2009 at 10:52:31PM +0200, Jeffrey Hutzelman wrote: > There really isn't such a thing as "_the_ (D)TLS service". A given host > might have any number of services utilizing TLS or DTLS on different ports > with different configuration. It's not multiplexed the way SSH might be, > and you wouldn't want to combine management information for them. Ideally, > there'd be some kind of "MIB fragment" describing (D)TLS which could be > incorporated into MIB's for various services using those protocols, of > which the SNMP DTLS TM is just one. We implemented SNMP over SSH by linking in an SSH library; we do not go through an sshd and hence assuming SSH is "multiplexed" is not always correct. This is all implementation choice. I agree that an SSH MIB or [D]TLS MIB would have to provide proper indexing so that multiple concurrent SSH or D[TLS] instances can export data to the SNMP agent. /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 Mon Sep 14 14:20: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 293493A683D for ; Mon, 14 Sep 2009 14:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, J_CHICKENPOX_31=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 DNpGEApqG5C8 for ; Mon, 14 Sep 2009 14:20:58 -0700 (PDT) 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 146F93A6844 for ; Mon, 14 Sep 2009 14:20:57 -0700 (PDT) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gcqj1c0031swQuc57lMjS4; Mon, 14 Sep 2009 21:21:43 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA15.westchester.pa.mail.comcast.net with comcast id glTB1c00P0UQ6dC3blTB2X; Mon, 14 Sep 2009 21:27:12 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <20090914182918.GA1332@elstar.local><27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net><033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com><11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu><033e01ca357d$cd57ade0$0600a8c0@china.huawei.com> Date: Mon, 14 Sep 2009 17:21:42 -0400 Message-ID: <034001ca3581$5b4089d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aco1f2vZLQQxPppmRaiIc+BnDmvh3gAAHbIw Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 21:20:59 -0000 Hi, Following up on Juergen's and Jeff's comments, I think the document should explain why this TM does pay attention to authentication-mechanism-specific errors, as compared to, say, SSH - IIUC, because TLS does not multiplex services while SSH does. For interoperability purposes, it is important to know that some agents might send a notification and count these particular errors, while others do not, even though both would apparently be considered compliant. A separate compliance clause might be the right approach for this. A knob that indicates whether this support is available or not might be helpful to NMSes. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Monday, September 14, 2009 5:08 PM > To: David Harrington > Cc: 'Jeffrey Hutzelman'; 'Wes Hardaker'; isms@ietf.org > Subject: Re: draft-hardaker-isms-dtls-tm-05 submitted - > tlstmNotifications > > >>>>> On Mon, 14 Sep 2009 16:56:16 -0400, "David Harrington" > said: > > DH> If one were to implement the DTLS-TM using a DTLS > toolkit, would the > DH> SNMP side of the API likely know why that the client > certificate was > DH> invalid, or would that likely be internal to the toolkit? > > 1) Yes. I've seen the openssl code and know that you can > determine this > exact situation. > > 2) IMHO, it doesn't matter. It's not up to us to specify how > a service > gets managed. As an example, many of the interface counters, for > example, were put into "exporting data" code in the linux kernel > because SNMP needed access to them. > > There are only two cases: > > A) A (D)TLS implementation can export the situation already today > within the existing APIs (such as the case for OpenSSL, as > mentioned above). > > B) A (D)TLS implementation can not export the data and as > far as the > client goes, it's a silent fail with a generic error. > If this is > the case, then one of three things must happen: > > i) the SSL implementation implements a mechanism through "some > manner" so that the invalid-certificate notification can be > sent by the application using the SSL API. Maybe > through a new > error code, or whatever. > > ii) the SSL implementation implements an internal "I got > a problem" > event and sends through some aspect to anyone listening. A > listener (possibly the SNMP agent application) would > listen for > a problem and send a notification when it received that > internal software event. > > iii) the SSL implementation won't export the details that > a problem > has occurred problem through any method. This > leaves the SNMP > agent implementation out of luck as it simply can't send the > notification at all. If we think this is possible, > wouldn't it > make more sense to put the notification into an optional > conformance group than to not put it in at all? > > And eventually, hopefully, all iii)s would eventually > transition to either i) or ii). > > -- > Wes Hardaker > Cobham Analytic Solutions > From wjhns1@hardakers.net Mon Sep 14 15:14: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 B7FB53A6852 for ; Mon, 14 Sep 2009 15:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 mhyAFgU2ZBxe for ; Mon, 14 Sep 2009 15:14:21 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id CF7383A635F for ; Mon, 14 Sep 2009 15:14:20 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id EECDC980D4; Mon, 14 Sep 2009 15:15:04 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20090914182918.GA1332@elstar.local> <27070_1252954966_n8EJ2jKD029767_sd4or59wpj.fsf@wjh.hardakers.net> <033a01ca3579$ea2c30c0$0600a8c0@china.huawei.com> <11B6ECDDB8C495CF22FEC194@atlantis.pc.cs.cmu.edu> <033e01ca357d$cd57ade0$0600a8c0@china.huawei.com> <034001ca3581$5b4089d0$0600a8c0@china.huawei.com> Date: Mon, 14 Sep 2009 15:15:04 -0700 In-Reply-To: <034001ca3581$5b4089d0$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 14 Sep 2009 17:21:42 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Jeffrey Hutzelman' , isms@ietf.org Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Sep 2009 22:14:21 -0000 >>>>> On Mon, 14 Sep 2009 17:21:42 -0400, "David Harrington" said: DH> Following up on Juergen's and Jeff's comments, I think the document DH> should explain why this TM does pay attention to DH> authentication-mechanism-specific errors, as compared to, say, SSH - DH> IIUC, because TLS does not multiplex services while SSH does. I'm not sure it's necessary to document the differences, IMHO. Each document should define the objects that are necessary to manage them. I don't think a cross-comparison of "why" is necessary. DH> For interoperability purposes, it is important to know that some DH> agents might send a notification and count these particular errors, DH> while others do not, even though both would apparently be considered DH> compliant. I agree. I don't think imposing some of these should be MUSTs in terms of interoperability, so I agree. I think putting them in optional compliance modules alleviates this problem. DH> A knob that indicates whether this support is available or not might DH> be helpful to NMSes. Sadly, we have that knob now in SNMP (agent-capabilities); the problem is that the solution isn't one that anyone likes to use. I don't think it's within the scope of the WG to fix the compliance reporting features within SNMP itself. (I'd love to see that work get done generically somewhere; it's definitely a missing piece of the puzzle) -- Wes Hardaker Cobham Analytic Solutions From adonati@motorola.com Wed Sep 16 07: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 330EA3A67AE for ; Wed, 16 Sep 2009 07:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.792 X-Spam-Level: X-Spam-Status: No, score=-4.792 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 RUkjSAe-Ezvp for ; Wed, 16 Sep 2009 07:50:00 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 247913A63CB for ; Wed, 16 Sep 2009 07:50:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1253112641!95617341!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9084 invoked from network); 16 Sep 2009 14:50:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2009 14:50:41 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n8GEof2L011063 for ; Wed, 16 Sep 2009 07:50:41 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n8GEoeXk013203 for ; Wed, 16 Sep 2009 09:50:40 -0500 (CDT) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n8GEoe4j013200 for ; Wed, 16 Sep 2009 09:50:40 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA36DD.02819C46" Date: Wed, 16 Sep 2009 10:50:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmCertToSNTable thread-index: Aco23QJ0iL3kWPeGRN+6OnoZomMn/g== From: "Donati Andrew-MGIA0477" To: , "Wes Hardaker" X-CFilter-Loop: Reflected Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmCertToSNTable X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 14:50:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA36DD.02819C46 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Wes,=20 Here are a few small items. =20 > tlstmCertToSNTable The description clause for tlstmCertToSNSecurityName states; "The securityName that the session should use if the tlstmCertToSNMapType is set to specified(1), otherwise the value in this column should be ignored." Likewise, will it be a good idea to have the description within tlstmCertToSNSANType contain a similar statement even though it is already implied ? =20 >In tlstmCertToSNSANType description: OthenName sequence =20 > In Appendix A:=20 vacmGroupaName =3D "administrators" - Andy Donati Motorola HN&M =20 =20 ------_=_NextPart_001_01CA36DD.02819C46 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Wes,=20
Here are a few=20 small items.
 
> tlstmCertToSNTable
The description clause for=20 tlstmCertToSNSecurityName states; = “The=20 securityName that the session should use if the
tlstmCertToSNMapType is set to = specified(1),=20 otherwise the value in this = column should=20 be ignored.”  Likewise, will it be
a good idea to have the description within=20 tlstmCertToSNSANType contain a similar statement even though it is = already=20 implied ?
 
>In=20 tlstmCertToSNSANType description:
OthenName = sequence
 
> In=20 Appendix A: 
vacmGroupaName =3D=20 "administrators"

- Andy Donati
Motorola=20 HN&M

 
 
------_=_NextPart_001_01CA36DD.02819C46-- From wjhns1@hardakers.net Thu Sep 17 17:34: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 D70793A6B2A for ; Thu, 17 Sep 2009 17:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 POVkAjxT7qoy for ; Thu, 17 Sep 2009 17:34:26 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 116373A6A2A for ; Thu, 17 Sep 2009 17:34:25 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 0D114980F9; Thu, 17 Sep 2009 17:35:18 -0700 (PDT) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: Date: Thu, 17 Sep 2009 17:35:17 -0700 In-Reply-To: (Donati Andrew-MGIA's message of "Wed, 16 Sep 2009 10:50:19 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmCertToSNTable X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Sep 2009 00:34:26 -0000 >>>>> On Wed, 16 Sep 2009 10:50:19 -0400, "Donati Andrew-MGIA0477" said: DA> Here are a few small items. Donati, Thanks for the suggestions. I'll integrate them into the next version! -- Wes Hardaker Cobham Analytic Solutions