From mailman-bounces@ietf.org Wed Dec 1 05:54:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12033 for ; Wed, 1 Dec 2004 05:54:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZSCz-0005Ck-QY for isms-archive@ietf.org; Wed, 01 Dec 2004 05:59:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZRV5-0002LM-Hz for isms-archive@ietf.org; Wed, 01 Dec 2004 05:14:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:03:16 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for isms-archive@ietf.org: List Password // URL ---- -------- isms@lists.ietf.org riufwi https://www1.ietf.org/mailman/options/isms/isms-archive%40ietf.org From isms-bounces@ietf.org Thu Dec 2 17:43:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08964; Thu, 2 Dec 2004 17:43:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzlP-0001Iu-Ef; Thu, 02 Dec 2004 17:49:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZyxT-0001cu-KD; Thu, 02 Dec 2004 16:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZy3V-0001fN-3m for isms@megatron.ietf.org; Thu, 02 Dec 2004 16:00:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29136 for ; Thu, 2 Dec 2004 15:59:58 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZy94-00071M-N0 for isms@ietf.org; Thu, 02 Dec 2004 16:05:48 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB2KxHuE025521; Thu, 2 Dec 2004 20:59:17 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iB2KwiNm010658; Thu, 2 Dec 2004 20:59:15 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004120212591422092 ; Thu, 02 Dec 2004 12:59:14 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 12:59:14 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 12:59:14 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 15:59:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Evaluation process? Date: Thu, 2 Dec 2004 15:59:10 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929600273@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Evaluation process? Thread-Index: AcTWYgk6vSAFTfw4QJC8QLTMeuA9dAAGIcQgAI1kP0A= From: "Blumenthal, Uri" To: "Fleischman, Eric" , "Wes Hardaker" , "Robert Story" X-OriginalArrivalTime: 02 Dec 2004 20:59:13.0139 (UTC) FILETIME=[C6EC1C30:01C4D8B1] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable > If the ISMS results won't produce an (SNMPv3) USM-like variant (or adjunct) that > cleanly works with PKI, then my efforts in arguing for the formation of > this WG would have been wasted. Can you explain how exactly you envision PKI utilisation in SNMPv3?=20 > I know that not every entity is deploying corporate-wide PKI > infrastructures, but I strongly believe that a prime requirement for > ISMS is that the selected protocol MUST be able to integrate with the > major existing corporate key management systems. These infrastructures > include PKI, Kerberos, RADIUS, and possibly a few others. PKI is probably in the future for the corporate world, question's when... > I also believe that the protocol MUST resolve the existing security > problems with SNMPv3 USM which are: > 1) no provisions for two-factored authentication Not sure it's needed - probably the *other* direction is where two-factored auth may be required. > 2) SNMP symmetric keys may be assembled from passwords You don't want keys be assembled from passwords - so don't do that. It's not mandatory to derive keys that way. But for those who insist on having the convenience of that weaker method, it's there. And by the way, if you noticed - most of the world is still using plain password auth (thankfully, now within a TLS pipe). > 3) Key updates do not provide for Perfect Forward Security DH-based key updates do. > 4) Inherent Symmetric Key distribution problems You either need a trusted third party to tell the entities what their session key is going to be, or a trusted thir party to confirm their identities (i.e. DH key agreement signed by certified public keys), or pre-provision the keys. > 5) Lack of viable session keys Perhaps it comes from the lack of the session concept in SNMP protocol? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Dec 2 18:21:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13277; Thu, 2 Dec 2004 18:21:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca0MY-0002FG-9E; Thu, 02 Dec 2004 18:27:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZyyh-0001xB-1y; Thu, 02 Dec 2004 16:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZyQw-0003RO-Lc for isms@megatron.ietf.org; Thu, 02 Dec 2004 16:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00690 for ; Thu, 2 Dec 2004 16:24:12 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZyWW-0007Y8-RS for isms@ietf.org; Thu, 02 Dec 2004 16:30:02 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 3C30711D8D4; Thu, 2 Dec 2004 13:24:00 -0800 (PST) To: "Blumenthal, Uri" Subject: Re: [Isms] Evaluation process? References: <3DEC199BD7489643817ECA151F7C5929600273@pysmsx401.amr.corp.intel.com> From: Wes Hardaker Organization: Sparta Date: Thu, 02 Dec 2004 13:23:59 -0800 In-Reply-To: <3DEC199BD7489643817ECA151F7C5929600273@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Thu, 2 Dec 2004 15:59:10 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Can we not argue whether or not USM provides what people need? It has been fairly well shown that it doesn't. I'd rather argue on how we can fix the problem, which is what the WG is for, rather than arguing on the past. (note that I'm not saying that discussing using USM in some fashion to leverage a solution shouldn't be done. I personally think it'll solve the problem, but it should still be discussed). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Dec 2 21:34:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28960; Thu, 2 Dec 2004 21:34:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3N5-0006Yt-RZ; Thu, 02 Dec 2004 21:40:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0RT-0004YN-MP; Thu, 02 Dec 2004 18:32:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZz8F-0004a3-3u for isms@megatron.ietf.org; Thu, 02 Dec 2004 17:08:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04563 for ; Thu, 2 Dec 2004 17:08:56 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzDq-0000F2-La for isms@ietf.org; Thu, 02 Dec 2004 17:14:47 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA10088; Thu, 2 Dec 2004 14:08:16 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iB2M8Cx19163; Thu, 2 Dec 2004 16:08:12 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Dec 2004 14:08:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Evaluation process? Date: Thu, 2 Dec 2004 14:08:12 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA4F@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation process? Thread-Index: AcTWYgk6vSAFTfw4QJC8QLTMeuA9dAAGIcQgAI1kP0AAAWr/UA== From: "Fleischman, Eric" To: "Blumenthal, Uri" , "Wes Hardaker" , "Robert Story" X-OriginalArrivalTime: 02 Dec 2004 22:08:12.0879 (UTC) FILETIME=[6A664DF0:01C4D8BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Uri,=20 Thank you for your response. My answers are embedded within delimiters below. --Eric From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] to Eric Fleischman: > If the ISMS results won't produce an (SNMPv3) USM-like variant (or adjunct) that > cleanly works with PKI, then my efforts in arguing for the formation of > this WG would have been wasted. Can you explain how exactly you envision PKI utilisation in SNMPv3?=20 I would like to see PKI identity certs be used for network manager authentication to SNMPv3 agents. I'd also like to see the identity certs and server certs be used in a (code, document) signing manner to provide authentication and integrity protection of SNMP communications -- including the introduction of an authentication chaining concept. The latter would permit the SNMP agent, for example, to securely forward the signed communication to some other remote location (which may or may not be under its auspices) for the network manager's request to be processed without having the processing agent have to trust the security representations of the SNMP agent. In this way, there would be no requirement for the processing agent to trust the SNMP agent. > I know that not every entity is deploying corporate-wide PKI=20 > infrastructures, but I strongly believe that a prime requirement for=20 > ISMS is that the selected protocol MUST be able to integrate with the=20 > major existing corporate key management systems. These infrastructures > include PKI, Kerberos, RADIUS, and possibly a few others. PKI is probably in the future for the corporate world, question's when... Yeah, I've heard this skepticism many times before. However, our corporation spent many years to gradually make PKI become universally real within our environment. It's been effectively "rock and rolling" here for some time now. I am aware that not everybody is in a similar shape, but I do know of many similar efforts occurring within other American and European corporations, universities, and governments. PKI is in much better shape than your skepticism justifies. > I also believe that the protocol MUST resolve the existing security=20 > problems with SNMPv3 USM which are: > 1) no provisions for two-factored authentication Not sure it's needed - probably the *other* direction is where two-factored auth may be required. Feel free to conclude this if you want. However, please privately contact me if you aren't already aware of use cases where such a feature would be very valuable. =20 > 2) SNMP symmetric keys may be assembled from passwords You don't want keys be assembled from passwords - so don't do that. It's not mandatory to derive keys that way. But for those who insist on having the convenience of that weaker method, it's there. And by the way, if you noticed - most of the world is still using plain password auth (thankfully, now within a TLS pipe). Several/many existing SNMPv3 products today solely support password assembly options. > 3) Key updates do not provide for Perfect Forward Security DH-based key updates do. If your deployed SNMP implementations come from a single source, you may be OK. If it comes from many sources, then you probably are not. > 4) Inherent Symmetric Key distribution problems You either need a trusted third party to tell the entities what their session key is going to be, or a trusted thir party to confirm their identities (i.e. DH key agreement signed by certified public keys), or pre-provision the keys. Your "Trusted third parties" reference presumes an existing key management infrastructure or approach that you share together. Since SNMP's use of symmetric keys is unique within our environment, it is not cost-effective to develop such an infrastructure solely for SNMP. Rather, SNMP should conform to already existing key distribution systems that we have already created for more important applications. By using the word "important", I am not speaking against SNMP. Rather, I am attempting to reflect the fact that SNMP has a very poor business case because it doesn't help to bring in any revenue (i.e., it is a cost sink, not a business solution). > 5) Lack of viable session keys Perhaps it comes from the lack of the session concept in SNMP protocol? Yes, you are of course correct about SNMP's UDP orientation. However, several of the proposals on the ISMS table have suggested solutions to this problem without requiring TCP transports. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Dec 2 22:08:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02361; Thu, 2 Dec 2004 22:08:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3tx-0007ZG-Js; Thu, 02 Dec 2004 22:14:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0bG-0006oU-RG; Thu, 02 Dec 2004 18:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca03l-00044A-03 for isms@megatron.ietf.org; Thu, 02 Dec 2004 18:08:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11377 for ; Thu, 2 Dec 2004 18:08:22 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca09M-0001uX-Ub for isms@ietf.org; Thu, 02 Dec 2004 18:14:13 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB2N7quE010257; Thu, 2 Dec 2004 23:07:52 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iB2N7hNg009018; Thu, 2 Dec 2004 23:07:52 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004120214221302128 ; Thu, 02 Dec 2004 14:22:13 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 14:22:02 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 14:22:01 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Dec 2004 17:22:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Evaluation process? Date: Thu, 2 Dec 2004 17:21:59 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929600334@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Evaluation process? Thread-Index: AcTWYgk6vSAFTfw4QJC8QLTMeuA9dAAGIcQgAI1kP0AAAWr/UAABfEbg From: "Blumenthal, Uri" To: "Fleischman, Eric" X-OriginalArrivalTime: 02 Dec 2004 22:22:00.0183 (UTC) FILETIME=[5782E070:01C4D8BD] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Thank you for your response. My answers are embedded within delimiters below. :-) --Eric I would like to see PKI identity certs be used for network manager authentication to SNMPv3 agents. I'd also like to see the identity certs and server certs be used in a (code, document) signing manner to provide authentication and integrity protection of SNMP Communications.... [Uri] Obviously for auth - that's not exactly what I'm asking.=20 [Uri] Do you want per-message signatures to be PK-based? And [Uri] how do you see agent-to-manager auth in that environment? -- including the introduction of an authentication chaining concept. The latter would permit the SNMP agent, for example, to securely forward the signed communication to some other remote location (which may or may not be under its auspices) for the network manager's request to be processed without having the processing agent have to trust the security representations of the SNMP agent. In this way, there would be no requirement for the processing agent to trust the SNMP agent. [Uri] I sort of understand what you mean... I'm not sure it belongs [Uri] to SNMP, but perhaps I just didn't get enough of this idea. [Uri] We can discuss it later privately. PKI is probably in the future for the corporate world, question's when... Yeah, I've heard this skepticism many times before. However, our corporation spent many years to gradually make PKI become universally real within our environment. It's been effectively "rock and rolling" here for some time now. I am aware that not everybody is in a similar shape, but I do know of many similar efforts occurring within other American and European corporations, universities, and governments. PKI is in much better shape than your skepticism justifies. [Uri] It's not skepticism - just an observation. Now, if you're in [Uri] position to send me an unclassified presentation on PKI [Uri] deployment in your organization (off-line of course), [Uri] it would make my life easier. (At the last IETF, there [Uri] were several such ones: MIT, J&J and US DoD.) Feel free to conclude this if you want. However, please privately contact me if you aren't already aware of use cases where such a feature would be very valuable. =20 [Uri] Please consider this a request (re. two-factor auth both ways),and [Uri] feel free to respond privately. Several/many existing SNMPv3 products today solely support password assembly options. [Uri] Hmm... Nowhere does the standard say that one should do so. [Uri] And banging on the vendors should solve this, no? After all, [Uri] it's a lot easier for the code to just intake a key, than to [Uri] intake something, crank it several times and then store as a=20 [Uri] key... Your "Trusted third parties" reference presumes an existing key management infrastructure or approach that you share together. Since SNMP's use of symmetric keys is unique within our environment, it is not cost-effective to develop such an infrastructure solely for SNMP. Rather, SNMP should conform to already existing key distribution systems that we have already created for more important applications. By using the word "important", I am not speaking against SNMP. Rather, I am attempting to reflect the fact that SNMP has a very poor business case because it doesn't help to bring in any revenue (i.e., it is a cost sink, not a business solution). > 5) Lack of viable session keys Perhaps it comes from the lack of the session concept in SNMP protocol? Yes, you are of course correct about SNMP's UDP orientation. However, several of the proposals on the ISMS table have suggested solutions to this problem without requiring TCP transports. [Uri] Not quite. And it's not a TCP issue - it's the issue of having [Uri] to keep track of a "session" somewhere at both ends, rather=20 [Uri] than just "get a message, respond and forget". I'm not arguing [Uri] against it - just bringing to attention that it's an extra [Uri] effort that somebody or something will have to spend. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Dec 30 11:57:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27339; Thu, 30 Dec 2004 11:57:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck3nu-00055m-Bt; Thu, 30 Dec 2004 12:09:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck3as-0001s5-5l; Thu, 30 Dec 2004 11:56:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck3WC-0000OD-8e for isms@megatron.ietf.org; Thu, 30 Dec 2004 11:51:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26871 for ; Thu, 30 Dec 2004 11:51:17 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck3hY-0004tb-R1 for isms@ietf.org; Thu, 30 Dec 2004 12:03:05 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id EBE3511D822; Thu, 30 Dec 2004 08:51:04 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 30 Dec 2004 08:51:03 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Isms] Evaluation results? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I have to admit: I'm getting a bit nervous. We have a deadline of end-of-March to make a determination about which direction to go and an evaluation that is taking place but is consuming much of the remaining time. If we're supposed to prove to the ADs that set the deadline that the community at large has picked a direction, I think we need as much time as possible between the time that the results of the evaluation team has come to a conclusion and the time frame by which community support needs to be shown. At this point, we have very little time left and hence I'm getting nervous. Having only a few people select a solution with little input from the community and then expecting the community to swallow it immediately is a sure path to the closure of this working group. Do we have a new expected due date for the results of the team to be published since the last two deadlines have already passed? (Admittedly, the end-of-march deadline was set by Steve and Bert, but Steve has stepped-down and I'm not sure what Sam's opinions on the subject are. I'll leave that to him if he wants to expand on the subject, otherwise we'll need to assume the original restrictions are in place.) -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms