From isms-bounces@lists.ietf.org Sat Oct 01 03:09:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELbVK-0001GS-VH; Sat, 01 Oct 2005 03:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELbVI-0001GA-3H for isms@megatron.ietf.org; Sat, 01 Oct 2005 03:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00729 for ; Sat, 1 Oct 2005 03:09:49 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELbdI-0004DY-3p for isms@ietf.org; Sat, 01 Oct 2005 03:18:09 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9179eBT014603; Sat, 1 Oct 2005 00:09:40 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9179XeB032740; Sat, 1 Oct 2005 00:09:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9179X3F032735; Sat, 1 Oct 2005 00:09:33 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 1 Oct 2005 00:09:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: Re: [Isms] authoritative In-Reply-To: <200510010102.VAA01974@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, We (dbh and I) have gone over this multiple times, and it seems like we still disagree whether or not "authoritative engines" is a SNMPv3 concept or a USM concept. I believe it is purely a USM concept and has no requirement to be in other security models. Also, I believe that USM could have been designed so that either SNMP engine could have been the authorattive engine. Also, USM as specified does not require that certain engines have an engineID assigned to them. I believe that only engines that have a "persistent" transport address need an engineID. I also believe that SNMPv3 talks about, but leaves out the development and definition of an important "role", which I have called "observer" over the years. Thus, I believe, putting aside proxies, there are the following SNMP interactions and roles: SNMP MGT APP------GET/SET/BULK------>SNMP AGENT <--------RESPONSE------- In the above SNMP messages, the contextEngineID is that of the SNMP agent. SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT -------RESPONSE-----> In the above SNMP messages, the contextEngineID is that of the SNMP agent. SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER -------RESPONSE------> In the above SNMP messages, the contextEngineID is that not that of the SNMP observer, but that of the SNMP agents in the system that is being observered (monitored). In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR need to have a persistent transport address. On Fri, 30 Sep 2005, David B Harrington wrote: > Hi, > > In SNMPv3, we have the concept of authoritative. We need to discuss > what that means for the SSH security model. > > I am especially interested in hearing from those who helped develop > SNMPv3 and the notion of authoritative engines in the first place, and > those who fought for the manager being authoritative for Informs (of > whom I am one). > > Obviously everybody is welcome to get in involved, but I'm really > trying to understand whether the historical requirement is stll valid, > and if you don't know what that historical requirement was, you > probably cannot answer the question very well. > > Once we establish the requirement, we can determine whether SSH meets > the requirement, in both normal mode and the proposed callback mode. > > David Harrington > dbharrington@comcast.net Enjoy, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 01 13:26:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELl7c-00010V-TG; Sat, 01 Oct 2005 13:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELl7b-00010Q-Fp for isms@megatron.ietf.org; Sat, 01 Oct 2005 13:26:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11175 for ; Sat, 1 Oct 2005 13:25:59 -0400 (EDT) Message-Id: <200510011725.NAA11175@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELlFg-0003LC-78 for isms@ietf.org; Sat, 01 Oct 2005 13:34:26 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20051001172551012004ff18e>; Sat, 1 Oct 2005 17:25:51 +0000 From: "David B Harrington" To: "'David T. Perkins'" , "'David B Harrington'" Subject: RE: [Isms] authoritative Date: Sat, 1 Oct 2005 13:25:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXGV1uHTi7vn6AoQu6+8x625yrc3gAS/RFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I think maybe the concept should have been limited to USM, and would like to eliminate it from the SSH security model if possible, but I need to gain WG consensus to do this, and before we make such a decision, we need to understand why the concept exists at all. That's why I'm starting this discussion about the requirement of having an authoritative engine. Please note that the authoritative engine is related to the securityEngineID, never the contextEngineID, even though both securityEngineID and contextEngineID are related to snmpEngineID. This discussion is explicitly NOT about whether we need an snmpEngineID or contextEngineID; that's a different discussion. The RFCs as written show the "authoritative" securityEngineID to be an RFC3411 requirement (i.e. independent of the message version). The "authoritative" securityEngineID is described in the RFC3411 architecture's ASIs. However, it is only found in generateRequestMsg(), processIncomingMsg(), and generateResponseMsg() - all of which exist in the message-processing-to-security-model interface. Its USAGE shows it to be an SNMPv3 requirement. RFC3412 has two parts - sections 1 through 6 are about the message processing **subsystem**; section 7 is about the **version 3 message processing model**. securityEngineID is set in section 7.1 (Outgoing message EOP) paragraph 8a, in the generateResponseMsg() ASI to the local snmpEngineID, paragraph 9a for the generateRequestMsg() ASI to the local snmpEngineID or to the target snmpEngineID, depending on the message Class. For outgoing messages, the USM security model sets the securityEngineID in section 3.1 paragraph 1a to the local snmpEngineID (if it is a response or a report), or the value specified in the generateRequestMsg() ASI is used to perform lookup in the USM tables. Subsequently, securityEngineID is passed in the msgAuthoritativeEngineID field of the securityParameters. (The format and contents of securityParameters are security-model-dependent. In the SSHSM, we may not need msgAuthoritativeEngineID.) Note that USM also uses a zero-length msgAuthoritativeEngineID to cause discovery of a remote engine's snmpEngineID. For incoming messages, the USM security model caches the securityEngineID from msgAuthoritativeEngineID in section 3.2, paragraph 2) and returns it to the message processing model in an OUT parameter of the processIncomingMsg() ASI. securityEngineID is subsequently USED in RFC3412 section 7.2 (Prepare Data Elements from an Incoming SNMP Message - part of the SNMPv3 message processing elements of procedure) paragraph 13a , where it is verified for a confirmed message to be equal to the local snmpEngineID. If it is not equal, then the cache is cleared, the message is discarded, and a FAILURE is returned. I don't see the securityEngineID being used elsewhere in the RFC341x specs. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins > Sent: Saturday, October 01, 2005 3:10 AM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] authoritative > > HI, > > We (dbh and I) have gone over this multiple times, and > it seems like we still disagree whether or not > "authoritative engines" is a SNMPv3 concept or > a USM concept. I believe it is purely a USM concept > and has no requirement to be in other security models. > Also, I believe that USM could have been designed > so that either SNMP engine could have been the > authorattive engine. Also, USM as specified does > not require that certain engines have an engineID > assigned to them. I believe that only engines that > have a "persistent" transport address need an > engineID. I also believe that SNMPv3 talks about, > but leaves out the development and definition of > an important "role", which I have called "observer" > over the years. > > Thus, I believe, putting aside proxies, there are > the following SNMP interactions and roles: > > SNMP MGT APP------GET/SET/BULK------>SNMP AGENT > <--------RESPONSE------- > > In the above SNMP messages, the contextEngineID is that > of the SNMP agent. > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT > -------RESPONSE-----> > In the above SNMP messages, the contextEngineID is that > of the SNMP agent. > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER > -------RESPONSE------> > > In the above SNMP messages, the contextEngineID is that > not that of the SNMP observer, but that of the SNMP agents > in the system that is being observered (monitored). > > In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR > need to have a persistent transport address. > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > Hi, > > > > In SNMPv3, we have the concept of authoritative. We need to discuss > > what that means for the SSH security model. > > > > I am especially interested in hearing from those who helped develop > > SNMPv3 and the notion of authoritative engines in the first > place, and > > those who fought for the manager being authoritative for Informs (of > > whom I am one). > > > > Obviously everybody is welcome to get in involved, but I'm really > > trying to understand whether the historical requirement is > stll valid, > > and if you don't know what that historical requirement was, you > > probably cannot answer the question very well. > > > > Once we establish the requirement, we can determine whether > SSH meets > > the requirement, in both normal mode and the proposed callback mode. > > > > David Harrington > > dbharrington@comcast.net > > Enjoy, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 01 14:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELlpl-000658-TQ; Sat, 01 Oct 2005 14:11:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELlpl-000653-BY for isms@megatron.ietf.org; Sat, 01 Oct 2005 14:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12640 for ; Sat, 1 Oct 2005 14:11:37 -0400 (EDT) Message-Id: <200510011811.OAA12640@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELlxs-0004Ll-5o for isms@ietf.org; Sat, 01 Oct 2005 14:20:04 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005100118112901300fktvme>; Sat, 1 Oct 2005 18:11:29 +0000 From: "David B Harrington" To: Date: Sat, 1 Oct 2005 14:11:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXGV1uHTi7vn6AoQu6+8x625yrc3gAVdX9A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] contextEngineID X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, David and I have discussed this before, many times, since "authoritative engines" was a contentious issue in the SNMPv2 wars. Hopefully, we can keep the WG discourse civil this time. I have changed the subject line of this thread to contextEngineID. While both securityEngineID and contextEngineID refer to an engine's snmpEngineID, and while they frequently refer to the same engine, securityEngineID and contextEngineID serve different purposes, and do not always refer to the same engine. An "authoritative engine" is always related to the securityEngineID being passed in the RFC3411/RFC3412/RFC3414 ASIs. The authoritative engine is not about contextEngineIDs. Comments inline. > We (dbh and I) have gone over this multiple times, and > it seems like we still disagree whether or not > "authoritative engines" is a SNMPv3 concept or > a USM concept. I believe it is purely a USM concept > and has no requirement to be in other security models. See my other mail under the topic "authoritative" > Also, I believe that USM could have been designed > so that either SNMP engine could have been the > authorattive engine. Others disagreed with this. > Also, USM as specified does > not require that certain engines have an engineID > assigned to them. I concur that USM does not require this. But SNMPv3 requires a contextEngineID in the scopedPDU. > I believe that only engines that > have a "persistent" transport address need an > engineID. One purpose of the snmpEngineID is to identify a datastore gathered from an engine, independent of the address. If the engine changes its address, presumably via DHCP, or has multiple addresses, on a router for example, then an NMS can correlate the datastores gathered from multiple addresses as being from the same engine. This can be important for maintaining historical trending data, or eliminating redundant icons in an NMS GUI. In addition, the engineID identifies the datastore that was the source of information, regardless of the transport address of the last hop. This is important when a scopedPDU is passed through a proxy or a trap-forwarder or a NAT, to be able to identify the engine that sourced the data. > I also believe that SNMPv3 talks about, > but leaves out the development and definition of > an important "role", which I have called "observer" > over the years. > > Thus, I believe, putting aside proxies, there are > the following SNMP interactions and roles: > > SNMP MGT APP------GET/SET/BULK------>SNMP AGENT > <--------RESPONSE------- > > In the above SNMP messages, the contextEngineID is that > of the SNMP agent. > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT > -------RESPONSE-----> > In the above SNMP messages, the contextEngineID is that > of the SNMP agent. Yes, the contextEngineID identifies the source of the data. But the point of the "authoritative" discussion is authoritative engines, and the authoritative engine is NOT always the same as the contextEngineID, even when putting aside proxy. And when used in a proxy situation, an application that is part of STD62, the "authoritative" engine is NEVER the contextEngineID. > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER > -------RESPONSE------> > > In the above SNMP messages, the contextEngineID is that > not that of the SNMP observer, but that of the SNMP agents > in the system that is being observered (monitored). > > In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR > need to have a persistent transport address. Your argument is about who needs a persistent transport address. That is not the purpose of the "authoritative" thread, nor do I see it being impotant as an aspect of the comntextEngineID discussion. I consider the following comment to be out of scope for this WG: I'm not sure I agree with your contention that the SNMP agent necessarily needs a persistent transport address. An NMS that monitors the network for new transport adddresses being added to the network and monitors fo rnon-reachability of known addresses (both common features of NMS platforms), could correlate any new addresses to the datastore associated with their snmpEngineID, and eliminate non-reachable addresses from association with existing datastores, thus adapting to non-persistent transport addresses. This would be more difficult for notification generators since they do not typically perform a network monitoring function like NMS platforms do. David Harrington dbharrington@comcast.net > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > Hi, > > > > In SNMPv3, we have the concept of authoritative. We need to discuss > > what that means for the SSH security model. > > > > I am especially interested in hearing from those who helped develop > > SNMPv3 and the notion of authoritative engines in the first > place, and > > those who fought for the manager being authoritative for Informs (of > > whom I am one). > > > > Obviously everybody is welcome to get in involved, but I'm really > > trying to understand whether the historical requirement is > stll valid, > > and if you don't know what that historical requirement was, you > > probably cannot answer the question very well. > > > > Once we establish the requirement, we can determine whether > SSH meets > > the requirement, in both normal mode and the proposed callback mode. > > > > David Harrington > > dbharrington@comcast.net > > Enjoy, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 01 14:17:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELlvh-0001D2-KX; Sat, 01 Oct 2005 14:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELlvf-0001Cu-9v for isms@megatron.ietf.org; Sat, 01 Oct 2005 14:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12820 for ; Sat, 1 Oct 2005 14:17:43 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELm3l-0004Td-LT for isms@ietf.org; Sat, 01 Oct 2005 14:26:10 -0400 Received: from pc6 (1Cust138.tnt102.lnd4.gbr.da.uu.net [213.116.52.138]) by blaster.systems.pipex.net (Postfix) with SMTP id 9ACEEE00009D; Sat, 1 Oct 2005 19:17:32 +0100 (BST) Message-ID: <035601c5c6ab$ef033800$0601a8c0@pc6> From: "Tom Petch" To: "David T. Perkins" , "David B Harrington" References: Subject: Re: [Isms] authoritative Date: Sat, 1 Oct 2005 12:05:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David T. Perkins" To: "David B Harrington" Cc: Sent: Saturday, October 01, 2005 9:09 AM Subject: Re: [Isms] authoritative > We (dbh and I) have gone over this multiple times, and > it seems like we still disagree whether or not > "authoritative engines" is a SNMPv3 concept or > a USM concept. I believe it is purely a USM concept > and has no requirement to be in other security models. Agree absolutely, it is an unnecessary complication; scrap it! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 01 15:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmag-00044g-9T; Sat, 01 Oct 2005 15:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmae-00044b-5l for isms@megatron.ietf.org; Sat, 01 Oct 2005 15:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13943 for ; Sat, 1 Oct 2005 15:00:03 -0400 (EDT) Message-Id: <200510011900.PAA13943@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELmii-0005Na-O4 for isms@ietf.org; Sat, 01 Oct 2005 15:08:32 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20051001185951012004df80e>; Sat, 1 Oct 2005 18:59:51 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'David T. Perkins'" Subject: RE: [Isms] authoritative Date: Sat, 1 Oct 2005 14:59:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <035601c5c6ab$ef033800$0601a8c0@pc6> Thread-Index: AcXGtGdVR3fl8ODWTnm9NCpbrm9YdAABYJtg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, Can you rephrase this into "Here are the requirements that led to its being part of STD62" and "Here's why those requirements do not apply to SNMPv3 with SSHSM"? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Saturday, October 01, 2005 6:05 AM > To: David T. Perkins; David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] authoritative > > > Tom Petch > ----- Original Message ----- > From: "David T. Perkins" > To: "David B Harrington" > Cc: > Sent: Saturday, October 01, 2005 9:09 AM > Subject: Re: [Isms] authoritative > > > > We (dbh and I) have gone over this multiple times, and > > it seems like we still disagree whether or not > > "authoritative engines" is a SNMPv3 concept or > > a USM concept. I believe it is purely a USM concept > > and has no requirement to be in other security models. > > Agree absolutely, it is an unnecessary complication; scrap it! > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 06:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNuI-0004EE-88; Mon, 03 Oct 2005 06:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNuC-0004Dy-3U for isms@megatron.ietf.org; Mon, 03 Oct 2005 06:50:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19919 for ; Mon, 3 Oct 2005 06:50:45 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMO2c-00033I-GY for isms@ietf.org; Mon, 03 Oct 2005 06:59:32 -0400 Received: from pc6 (1Cust147.tnt3.lnd4.gbr.da.uu.net [62.188.132.147]) by galaxy.systems.pipex.net (Postfix) with SMTP id 52160E0001CB; Mon, 3 Oct 2005 11:50:22 +0100 (BST) Message-ID: <001401c5c7ff$c9397120$0601a8c0@pc6> From: "Tom Petch" To: , "'David T. Perkins'" References: <20051001185952.A79B7E00008B@dragons.systems.pipex.net> Subject: Re: [Isms] authoritative Date: Mon, 3 Oct 2005 11:46:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I work from the principle that if it is not needed, don't do it:-) Authoritative engine id does not appear in the body of VACM [RFC3415] and only appears as a gloss for securityEngineID in ARCH [RFC3411] and MPP [RFC3412] so in that sense, the term seems to add nothing and can be dispensed with. In MPP, when generatng a message, securityEngineID is taken from snmpEngineID for Response and Internal Class PDU and from the target entity's snmpEngineID for Confimed and Notification Class, which in turn is determined in an implementation dependent manner . The only time I see it used is in MPP, on receipt of a Confirmed Class PDU, when the securityEngineID must match the snmpEngineID else the message is discarded. So it appears to provide an additonal check that the message really got to the intended engine. All of which I am sure you know already. In the case of SSH, I expect the secure, authenticated tunnel to provide the assurance that the message has been delivered to the intended engine. To preserve the ASI, the ssh security model could take it from snmpEngineID thereby ensuring the MPP check succeeds. More complicatedly, it could be passed transparently in the security parameters. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; "'David T. Perkins'" Cc: Sent: Saturday, October 01, 2005 8:59 PM Subject: RE: [Isms] authoritative > Hi Tom, > > Can you rephrase this into > "Here are the requirements that led to its being part of STD62" and > "Here's why those requirements do not apply to SNMPv3 with SSHSM"? > > David Harrington > dbharrington@comcast.net > > > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Saturday, October 01, 2005 6:05 AM > > To: David T. Perkins; David B Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] authoritative > > > > > > Tom Petch > > ----- Original Message ----- > > From: "David T. Perkins" > > To: "David B Harrington" > > Cc: > > Sent: Saturday, October 01, 2005 9:09 AM > > Subject: Re: [Isms] authoritative > > > > > > > We (dbh and I) have gone over this multiple times, and > > > it seems like we still disagree whether or not > > > "authoritative engines" is a SNMPv3 concept or > > > a USM concept. I believe it is purely a USM concept > > > and has no requirement to be in other security models. > > > > Agree absolutely, it is an unnecessary complication; scrap it! > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 08:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPOx-0006Ud-Uf; Mon, 03 Oct 2005 08:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPOw-0006SJ-CV for isms@megatron.ietf.org; Mon, 03 Oct 2005 08:26:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24901 for ; Mon, 3 Oct 2005 08:26:37 -0400 (EDT) Message-Id: <200510031226.IAA24901@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMPXP-0005aU-Qu for isms@ietf.org; Mon, 03 Oct 2005 08:35:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005100312262801400pplh7e>; Mon, 3 Oct 2005 12:26:28 +0000 From: "David B Harrington" To: "'Tom Petch'" , , "'David T. Perkins'" Subject: RE: [Isms] authoritative Date: Mon, 3 Oct 2005 08:26:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <001401c5c7ff$c9397120$0601a8c0@pc6> Thread-Index: AcXICG1cIfkAcGozRvaRoBhpxgm29QAC9z3Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, You analysis and my analysis are very similar, and we've reached similar conclusions about how to preserve the ASIs when using SSH. Unfortunately, many standards are defined capturing the solution, but not the thinking that led to the solution. So it is unclear what requirements were being met by having an authoritative engine, and it's been a long time since those discussions, and my recall of the requirements is fuzzy. To the rest of the WG, what are the reasons we need to maintain the concept of authoritative? Does the authoritative securityEngineID need to be passed in the message when using SSH or other external security substrate? Two proponents of the authoritative engine were Steve Waldbusser and Jeff Case. I have asked them to join in this discussion, in the hopes they can recall the requirements in more detail than I. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Monday, October 03, 2005 5:46 AM > To: dbharrington@comcast.net; 'David T. Perkins' > Cc: isms@ietf.org > Subject: Re: [Isms] authoritative > > I work from the principle that if it is not needed, don't do it:-) > > Authoritative engine id does not appear in the body of VACM > [RFC3415] and only > appears as a gloss for securityEngineID in ARCH [RFC3411] and > MPP [RFC3412] so > in that sense, the term seems to add nothing and can be > dispensed with. > > In MPP, when generatng a message, securityEngineID is taken > from snmpEngineID > for Response and Internal Class PDU and from the target > entity's snmpEngineID > for Confimed and Notification Class, which in turn is determined in an > implementation dependent manner . > > The only time I see it used is in MPP, on receipt of a > Confirmed Class PDU, when > the securityEngineID must match the snmpEngineID else the > message is discarded. > So it appears to provide an additonal check that the message > really got to the > intended engine. > > All of which I am sure you know already. > > In the case of SSH, I expect the secure, authenticated tunnel > to provide the > assurance that the message has been delivered to the intended > engine. To > preserve the ASI, the ssh security model could take it from > snmpEngineID thereby > ensuring the MPP check succeeds. More complicatedly, it > could be passed > transparently in the security parameters. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: "'Tom Petch'" ; "'David T. Perkins'" > > Cc: > Sent: Saturday, October 01, 2005 8:59 PM > Subject: RE: [Isms] authoritative > > > > Hi Tom, > > > > Can you rephrase this into > > "Here are the requirements that led to its being part of STD62" and > > "Here's why those requirements do not apply to SNMPv3 with SSHSM"? > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Saturday, October 01, 2005 6:05 AM > > > To: David T. Perkins; David B Harrington > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] authoritative > > > > > > > > > Tom Petch > > > ----- Original Message ----- > > > From: "David T. Perkins" > > > To: "David B Harrington" > > > Cc: > > > Sent: Saturday, October 01, 2005 9:09 AM > > > Subject: Re: [Isms] authoritative > > > > > > > > > > We (dbh and I) have gone over this multiple times, and > > > > it seems like we still disagree whether or not > > > > "authoritative engines" is a SNMPv3 concept or > > > > a USM concept. I believe it is purely a USM concept > > > > and has no requirement to be in other security models. > > > > > > Agree absolutely, it is an unnecessary complication; scrap it! > > > > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 13:11:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTqw-0002GZ-7Q; Mon, 03 Oct 2005 13:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTqv-0002GR-4t for isms@megatron.ietf.org; Mon, 03 Oct 2005 13:11:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18936 for ; Mon, 3 Oct 2005 13:11:46 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTzP-0006GT-Rw for isms@ietf.org; Mon, 03 Oct 2005 13:20:37 -0400 Received: from pc6 (1Cust43.tnt14.lnd4.gbr.da.uu.net [62.188.143.43]) by galaxy.systems.pipex.net (Postfix) with SMTP id 1C226E0001F0; Mon, 3 Oct 2005 18:11:24 +0100 (BST) Message-ID: <020001c5c835$03b14be0$0601a8c0@pc6> From: "Tom Petch" To: , References: <200510011811.OAA12640@ietf.org> Subject: Re: [Isms] contextEngineID Date: Mon, 3 Oct 2005 18:10:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.3 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org contextEngineID I saw as a given for isms, since it appears part of the ScopedPDU [RFC3412] and we are not meant to change the PDU. I also saw it as a reasonable part of the context, that is contextName would not be globally unique but contextEngineID.contextName would be. There is then the challenge of determining the snmpEngineID of the target entity in an implementation dependent manner [RFC3412], soluble but tedious, no different for USM, SSH, etc etc. The one thing that gives me pause is the ASI in RFC3412 which an application uses to register itself for processing pdu, where it provides pduType, naturally, and contextEngineID - eh? can this be anything other than the snmpEngineID? can there be more than one in an SNMP entity as the adjacent text suggests? That ASI I have never understood. Whatever, I still see contextEngineID (unlike securityEngineID) as something that stays unchanged in isms. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Saturday, October 01, 2005 8:11 PM Subject: [Isms] contextEngineID > Hi, > > David and I have discussed this before, many times, since > "authoritative engines" was a contentious issue in the SNMPv2 wars. > Hopefully, we can keep the WG discourse civil this time. > > I have changed the subject line of this thread to contextEngineID. > > While both securityEngineID and contextEngineID refer to an engine's > snmpEngineID, and while they frequently refer to the same engine, > securityEngineID and contextEngineID serve different purposes, and do > not always refer to the same engine. An "authoritative engine" is > always related to the securityEngineID being passed in the > RFC3411/RFC3412/RFC3414 ASIs. The authoritative engine is not about > contextEngineIDs. > > Comments inline. > > > We (dbh and I) have gone over this multiple times, and > > it seems like we still disagree whether or not > > "authoritative engines" is a SNMPv3 concept or > > a USM concept. I believe it is purely a USM concept > > and has no requirement to be in other security models. > > See my other mail under the topic "authoritative" > > > Also, I believe that USM could have been designed > > so that either SNMP engine could have been the > > authorattive engine. > > Others disagreed with this. > > > Also, USM as specified does > > not require that certain engines have an engineID > > assigned to them. > > I concur that USM does not require this. But SNMPv3 requires a > contextEngineID in the scopedPDU. > > > I believe that only engines that > > have a "persistent" transport address need an > > engineID. > > One purpose of the snmpEngineID is to identify a datastore gathered > from an engine, independent of the address. If the engine changes its > address, presumably via DHCP, or has multiple addresses, on a router > for example, then an NMS can correlate the datastores gathered from > multiple addresses as being from the same engine. This can be > important for maintaining historical trending data, or eliminating > redundant icons in an NMS GUI. > > In addition, the engineID identifies the datastore that was the source > of information, regardless of the transport address of the last hop. > This is important when a scopedPDU is passed through a proxy or a > trap-forwarder or a NAT, to be able to identify the engine that > sourced the data. > > > I also believe that SNMPv3 talks about, > > but leaves out the development and definition of > > an important "role", which I have called "observer" > > over the years. > > > > Thus, I believe, putting aside proxies, there are > > the following SNMP interactions and roles: > > > > SNMP MGT APP------GET/SET/BULK------>SNMP AGENT > > <--------RESPONSE------- > > > > In the above SNMP messages, the contextEngineID is that > > of the SNMP agent. > > > > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT > > -------RESPONSE-----> > > In the above SNMP messages, the contextEngineID is that > > of the SNMP agent. > > Yes, the contextEngineID identifies the source of the data. > > But the point of the "authoritative" discussion is authoritative > engines, and the authoritative engine is NOT always the same as the > contextEngineID, even when putting aside proxy. > > And when used in a proxy situation, an application that is part of > STD62, the "authoritative" engine is NEVER the contextEngineID. > > > > > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER > > -------RESPONSE------> > > > > In the above SNMP messages, the contextEngineID is that > > not that of the SNMP observer, but that of the SNMP agents > > in the system that is being observered (monitored). > > > > In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR > > need to have a persistent transport address. > > Your argument is about who needs a persistent transport address. That > is not the purpose of the "authoritative" thread, nor do I see it > being impotant as an aspect of the comntextEngineID discussion. > > I consider the following comment to be out of scope for this WG: > > I'm not sure I agree with your contention that the SNMP agent > necessarily needs a persistent transport address. An NMS that monitors > the network for new transport adddresses being added to the network > and monitors fo rnon-reachability of known addresses (both common > features of NMS platforms), could correlate any new addresses to the > datastore associated with their snmpEngineID, and eliminate > non-reachable addresses from association with existing datastores, > thus adapting to non-persistent transport addresses. > > This would be more difficult for notification generators since they do > not typically perform a network monitoring function like NMS platforms > do. > > David Harrington > dbharrington@comcast.net > > > > > > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > > Hi, > > > > > > In SNMPv3, we have the concept of authoritative. We need to > discuss > > > what that means for the SSH security model. > > > > > > I am especially interested in hearing from those who helped > develop > > > SNMPv3 and the notion of authoritative engines in the first > > place, and > > > those who fought for the manager being authoritative for Informs > (of > > > whom I am one). > > > > > > Obviously everybody is welcome to get in involved, but I'm really > > > trying to understand whether the historical requirement is > > stll valid, > > > and if you don't know what that historical requirement was, you > > > probably cannot answer the question very well. > > > > > > Once we establish the requirement, we can determine whether > > SSH meets > > > the requirement, in both normal mode and the proposed callback > mode. > > > > > > David Harrington > > > dbharrington@comcast.net > > > > Enjoy, > > /david t. perkins > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 14:36:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVBG-0008FG-2M; Mon, 03 Oct 2005 14:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVBF-0008FB-DZ for isms@megatron.ietf.org; Mon, 03 Oct 2005 14:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23902 for ; Mon, 3 Oct 2005 14:36:52 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVJl-0000O7-BR for isms@ietf.org; Mon, 03 Oct 2005 14:45:42 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DF6C8E0049; Mon, 3 Oct 2005 14:36:50 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Mon, 03 Oct 2005 14:36:50 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Isms] ISMS at IETF 64 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm surprised that I have not seen a scheduling request for ISMS. Today is the WG scheduling deadline. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 15:34:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMW5K-0000Ev-39; Mon, 03 Oct 2005 15:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMW5I-0000Em-Do for isms@megatron.ietf.org; Mon, 03 Oct 2005 15:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27252 for ; Mon, 3 Oct 2005 15:34:46 -0400 (EDT) Message-Id: <200510031934.PAA27252@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMWDp-0001gu-5g for isms@ietf.org; Mon, 03 Oct 2005 15:43:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005100319343801300fke22e>; Mon, 3 Oct 2005 19:34:38 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] contextEngineID Date: Mon, 3 Oct 2005 15:34:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <020001c5c835$03b14be0$0601a8c0@pc6> Thread-Index: AcXIPX3bum5KXJUMSlSXgJRRth4DBQADfagg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, I agree that contextEngineID is still needed, even if we can eliminate securityEngineID and/or the authoritative concept. There are ways to accomplish similar things that contextEngineID permits, such as overloading the contextName, but changes to the PDU are outside the scope of this WG. As I recall, there were a number of cases where multiple engineID/PDU registrations could occur. 1) In SNMPv1, there were cases where a community string could be fashioned as "public@deviceB" or "deviceB:public" and so forth, and the SNMP engine would send the message to deviceB, typically using the "public" community extracted from the compound-style community name. If device B has an assigned engineID (even if only the engine with the PDU registration knows it, and deviceB doesn't actually support an snmpEngineID, existing systems could use that mechanism to proxy messages. Of course, we also designed a proxy-forwarder that could be used, but that would not be backwards compatible with the "public@deviceB" approach. 2) The forwarding protocol may or may not be SNMP; the STD62 "proxy forwarder" is only one type of possible proxy mechanism, one that can translate between SNMP versions. One could proxy using a "command responder" application that actually queries a device using non-SNMP management protocols and reports the result using SNMP. (I think this is similar to the "observer" role that Dave Perkins mentioned.) 3) an engine could be composed of multiple processor units (applications) - one could have a contextEngineID that refers to the processing to be done by an SNMPv1 "command responder" and a different one for an SNMPv3 "command responder" (and possibly another for an SNMPv4 command responder, etc.). These are edge cases, but the SNMPv3 WG thought it important to offer the flexibility for these and other cases. Discovery of the contextEngineID can be difficult, especially in the case of proxy. USM discovers securityEngineIDs using Reports, or through implementation-defined mechanisms. If we don't need securityEngineID for SSHSM, we might be able to have a discovery mechanism that simply GETs the snmpEngineID from the SNMP-FRAMEWORK-MIB, and is provided in another way for those engines that don't support the SNMP-FRAMEWORK-MIB. Stay tuned. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Monday, October 03, 2005 12:10 PM > To: ietfdbh@comcast.net; isms@ietf.org > Subject: Re: [Isms] contextEngineID > > contextEngineID I saw as a given for isms, since it appears > part of the > ScopedPDU [RFC3412] and we are not meant to change the PDU. > > I also saw it as a reasonable part of the context, that is > contextName would not > be globally unique but contextEngineID.contextName would be. > There is then the > challenge of determining the snmpEngineID of the target entity in an > implementation > dependent manner [RFC3412], soluble but tedious, no different > for USM, SSH, etc > etc. > > The one thing that gives me pause is the ASI in RFC3412 which > an application > uses to register itself for processing pdu, where it provides pduType, > naturally, and > contextEngineID - eh? can this be anything other than the > snmpEngineID? can > there be more than one in an SNMP entity as the adjacent text > suggests? That > ASI I have never understood. > > Whatever, I still see contextEngineID (unlike > securityEngineID) as something > that stays unchanged in isms. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Saturday, October 01, 2005 8:11 PM > Subject: [Isms] contextEngineID > > > > Hi, > > > > David and I have discussed this before, many times, since > > "authoritative engines" was a contentious issue in the SNMPv2 wars. > > Hopefully, we can keep the WG discourse civil this time. > > > > I have changed the subject line of this thread to contextEngineID. > > > > While both securityEngineID and contextEngineID refer to an engine's > > snmpEngineID, and while they frequently refer to the same engine, > > securityEngineID and contextEngineID serve different > purposes, and do > > not always refer to the same engine. An "authoritative engine" is > > always related to the securityEngineID being passed in the > > RFC3411/RFC3412/RFC3414 ASIs. The authoritative engine is not about > > contextEngineIDs. > > > > Comments inline. > > > > > We (dbh and I) have gone over this multiple times, and > > > it seems like we still disagree whether or not > > > "authoritative engines" is a SNMPv3 concept or > > > a USM concept. I believe it is purely a USM concept > > > and has no requirement to be in other security models. > > > > See my other mail under the topic "authoritative" > > > > > Also, I believe that USM could have been designed > > > so that either SNMP engine could have been the > > > authorattive engine. > > > > Others disagreed with this. > > > > > Also, USM as specified does > > > not require that certain engines have an engineID > > > assigned to them. > > > > I concur that USM does not require this. But SNMPv3 requires a > > contextEngineID in the scopedPDU. > > > > > I believe that only engines that > > > have a "persistent" transport address need an > > > engineID. > > > > One purpose of the snmpEngineID is to identify a datastore gathered > > from an engine, independent of the address. If the engine > changes its > > address, presumably via DHCP, or has multiple addresses, on a router > > for example, then an NMS can correlate the datastores gathered from > > multiple addresses as being from the same engine. This can be > > important for maintaining historical trending data, or eliminating > > redundant icons in an NMS GUI. > > > > In addition, the engineID identifies the datastore that was > the source > > of information, regardless of the transport address of the last hop. > > This is important when a scopedPDU is passed through a proxy or a > > trap-forwarder or a NAT, to be able to identify the engine that > > sourced the data. > > > > > I also believe that SNMPv3 talks about, > > > but leaves out the development and definition of > > > an important "role", which I have called "observer" > > > over the years. > > > > > > Thus, I believe, putting aside proxies, there are > > > the following SNMP interactions and roles: > > > > > > SNMP MGT APP------GET/SET/BULK------>SNMP AGENT > > > <--------RESPONSE------- > > > > > > In the above SNMP messages, the contextEngineID is that > > > of the SNMP agent. > > > > > > > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT > > > -------RESPONSE-----> > > > In the above SNMP messages, the contextEngineID is that > > > of the SNMP agent. > > > > Yes, the contextEngineID identifies the source of the data. > > > > But the point of the "authoritative" discussion is authoritative > > engines, and the authoritative engine is NOT always the same as the > > contextEngineID, even when putting aside proxy. > > > > And when used in a proxy situation, an application that is part of > > STD62, the "authoritative" engine is NEVER the contextEngineID. > > > > > > > > > > > SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER > > > -------RESPONSE------> > > > > > > In the above SNMP messages, the contextEngineID is that > > > not that of the SNMP observer, but that of the SNMP agents > > > in the system that is being observered (monitored). > > > > > > In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR > > > need to have a persistent transport address. > > > > Your argument is about who needs a persistent transport > address. That > > is not the purpose of the "authoritative" thread, nor do I see it > > being impotant as an aspect of the comntextEngineID discussion. > > > > I consider the following comment to be out of scope for this WG: > > > > I'm not sure I agree with your contention that the SNMP agent > > necessarily needs a persistent transport address. An NMS > that monitors > > the network for new transport adddresses being added to the network > > and monitors fo rnon-reachability of known addresses (both common > > features of NMS platforms), could correlate any new addresses to the > > datastore associated with their snmpEngineID, and eliminate > > non-reachable addresses from association with existing datastores, > > thus adapting to non-persistent transport addresses. > > > > This would be more difficult for notification generators > since they do > > not typically perform a network monitoring function like > NMS platforms > > do. > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > > > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > > > Hi, > > > > > > > > In SNMPv3, we have the concept of authoritative. We need to > > discuss > > > > what that means for the SSH security model. > > > > > > > > I am especially interested in hearing from those who helped > > develop > > > > SNMPv3 and the notion of authoritative engines in the first > > > place, and > > > > those who fought for the manager being authoritative for Informs > > (of > > > > whom I am one). > > > > > > > > Obviously everybody is welcome to get in involved, but > I'm really > > > > trying to understand whether the historical requirement is > > > stll valid, > > > > and if you don't know what that historical requirement was, you > > > > probably cannot answer the question very well. > > > > > > > > Once we establish the requirement, we can determine whether > > > SSH meets > > > > the requirement, in both normal mode and the proposed callback > > mode. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > Enjoy, > > > /david t. perkins > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 18:52:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZA9-0007I0-K5; Mon, 03 Oct 2005 18:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZA8-0007Hv-6e for isms@megatron.ietf.org; Mon, 03 Oct 2005 18:52:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24962 for ; Mon, 3 Oct 2005 18:51:57 -0400 (EDT) Message-Id: <200510032251.SAA24962@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMZIg-0004Ma-4y for isms@ietf.org; Mon, 03 Oct 2005 19:00:51 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005100322514801300fms8de>; Mon, 3 Oct 2005 22:51:48 +0000 From: "David B Harrington" To: "'Sam Hartman'" Date: Mon, 3 Oct 2005 18:51:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXIbQafV0FUMdbwS/yF89yivsSnGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] IETF64 meeting X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, Did Juergen get a meeting request to you today in time? Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 19:05:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZNc-0007f5-IK; Mon, 03 Oct 2005 19:05:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZNa-0007eB-Qy for isms@megatron.ietf.org; Mon, 03 Oct 2005 19:05:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27285 for ; Mon, 3 Oct 2005 19:05:51 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMZW9-0005KH-L8 for isms@ietf.org; Mon, 03 Oct 2005 19:14:46 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2005 16:05:45 -0700 X-IronPort-AV: i="3.97,170,1125903600"; d="scan'208"; a="663216144:sNHT37629976" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j93N5RKK011824; Mon, 3 Oct 2005 16:05:38 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 16:05:40 -0700 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] authoritative Date: Mon, 3 Oct 2005 16:05:39 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3AE2F09@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] authoritative Thread-Index: AcXICG1cIfkAcGozRvaRoBhpxgm29QAC9z3QABXSP2A= From: "Kaushik Narayan \(kaushik\)" To: , "Tom Petch" , , "David T. Perkins" X-OriginalArrivalTime: 03 Oct 2005 23:05:40.0798 (UTC) FILETIME=[F982BDE0:01C5C86E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I agree that the notion of authoritative engines have a significant influence on USM but much lesser bearing on the general SNMP architecture. Fundamentally it is tied to synchronization of the clock (engineTime and engineBoots need to be synchronized from the authoritative engine). There isn't a need to synchronize clocks at the SNMP layer with a transport mapped security model. Also the notion of authoritative is not completely consistent with a reliable transport, since with notification-type, the authoritative engine depends on the Class of the message, i.e. agent is authoritative for SNMP Traps and the Reciever is authoritative for Informs. You might have the same information being transferred between two SNMP engines via different messages and have different engines being treated as authoritative. Also it creates a tricky issue with any TMSM since for UnConfirmed Notification-Type messages (Traps), the security model will have no idea of which endpoint to send the trap (the SNMP engine ID passed down would identify itself) =20 I recommend that we deprecate the notion of authoritative engines for all transport mapped security models not just SSHSM. Regards, kaushik!=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Monday, October 03, 2005 5:26 AM To: 'Tom Petch'; dbharrington@comcast.net; 'David T. Perkins' Cc: isms@ietf.org Subject: RE: [Isms] authoritative Hi Tom, You analysis and my analysis are very similar, and we've reached similar conclusions about how to preserve the ASIs when using SSH. Unfortunately, many standards are defined capturing the solution, but not the thinking that led to the solution. So it is unclear what requirements were being met by having an authoritative engine, and it's been a long time since those discussions, and my recall of the requirements is fuzzy. To the rest of the WG, what are the reasons we need to maintain the concept of authoritative? Does the authoritative securityEngineID need to be passed in the message when using SSH or other external security substrate? Two proponents of the authoritative engine were Steve Waldbusser and Jeff Case. I have asked them to join in this discussion, in the hopes they can recall the requirements in more detail than I. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Monday, October 03, 2005 5:46 AM > To: dbharrington@comcast.net; 'David T. Perkins' > Cc: isms@ietf.org > Subject: Re: [Isms] authoritative >=20 > I work from the principle that if it is not needed, don't do it:-) >=20 > Authoritative engine id does not appear in the body of VACM [RFC3415]=20 > and only appears as a gloss for securityEngineID in ARCH [RFC3411] and > MPP [RFC3412] so in that sense, the term seems to add nothing and can=20 > be dispensed with. >=20 > In MPP, when generatng a message, securityEngineID is taken from=20 > snmpEngineID for Response and Internal Class PDU and from the target=20 > entity's snmpEngineID for Confimed and Notification Class, which in=20 > turn is determined in an > implementation dependent manner . >=20 > The only time I see it used is in MPP, on receipt of a Confirmed Class > PDU, when the securityEngineID must match the snmpEngineID else the=20 > message is discarded. > So it appears to provide an additonal check that the message really=20 > got to the intended engine. >=20 > All of which I am sure you know already. >=20 > In the case of SSH, I expect the secure, authenticated tunnel to=20 > provide the assurance that the message has been delivered to the=20 > intended engine. To preserve the ASI, the ssh security model could=20 > take it from snmpEngineID thereby ensuring the MPP check succeeds. =20 > More complicatedly, it could be passed transparently in the security=20 > parameters. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "David B Harrington" > To: "'Tom Petch'" ; "'David T. Perkins'" > > Cc: > Sent: Saturday, October 01, 2005 8:59 PM > Subject: RE: [Isms] authoritative >=20 >=20 > > Hi Tom, > > > > Can you rephrase this into > > "Here are the requirements that led to its being part of STD62" and > > "Here's why those requirements do not apply to SNMPv3 with SSHSM"? > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Saturday, October 01, 2005 6:05 AM > > > To: David T. Perkins; David B Harrington > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] authoritative > > > > > > > > > Tom Petch > > > ----- Original Message ----- > > > From: "David T. Perkins" > > > To: "David B Harrington" > > > Cc: > > > Sent: Saturday, October 01, 2005 9:09 AM > > > Subject: Re: [Isms] authoritative > > > > > > > > > > We (dbh and I) have gone over this multiple times, and it seems=20 > > > > like we still disagree whether or not "authoritative engines" is > > > > a SNMPv3 concept or a USM concept. I believe it is purely a USM=20 > > > > concept and has no requirement to be in other security models. > > > > > > Agree absolutely, it is an unnecessary complication; scrap it! > > > > > > > >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 20:29:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMag3-0003uk-PU; Mon, 03 Oct 2005 20:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMag1-0003uP-BX for isms@megatron.ietf.org; Mon, 03 Oct 2005 20:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00508 for ; Mon, 3 Oct 2005 20:29:00 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMaoa-00076d-6c for isms@ietf.org; Mon, 03 Oct 2005 20:37:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C619CE0049; Mon, 3 Oct 2005 20:28:18 -0400 (EDT) To: References: <200510032251.j93MpkqM022051@pacific-carrier-annex.mit.edu> From: Sam Hartman Date: Mon, 03 Oct 2005 20:28:18 -0400 In-Reply-To: <200510032251.j93MpkqM022051@pacific-carrier-annex.mit.edu> (David B. Harrington's message of "Mon, 3 Oct 2005 18:51:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: isms@ietf.org Subject: [Isms] Re: IETF64 meeting 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi Sam, Did Juergen get a meeting request to you today in David> time? No. I preemptively told Marsha that she should expect a late one though. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 20:30:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMahG-0004I8-Gs; Mon, 03 Oct 2005 20:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMahE-0004I0-5z for isms@megatron.ietf.org; Mon, 03 Oct 2005 20:30:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00561 for ; Mon, 3 Oct 2005 20:30:14 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMapn-00078P-4z for isms@ietf.org; Mon, 03 Oct 2005 20:39:08 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E1B41E0049; Mon, 3 Oct 2005 20:30:11 -0400 (EDT) To: References: <200510032251.j93MpkqM022051@pacific-carrier-annex.mit.edu> From: Sam Hartman Date: Mon, 03 Oct 2005 20:30:11 -0400 In-Reply-To: <200510032251.j93MpkqM022051@pacific-carrier-annex.mit.edu> (David B. Harrington's message of "Mon, 3 Oct 2005 18:51:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: isms@ietf.org Subject: [Isms] Re: IETF64 meeting 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org O, apparently the chairs did send in a scheduling request but I didn't see it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 03 23:39:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdeQ-0003RQ-0v; Mon, 03 Oct 2005 23:39:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdeP-0003RK-FG for isms@megatron.ietf.org; Mon, 03 Oct 2005 23:39:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09832 for ; Mon, 3 Oct 2005 23:39:30 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMdmz-0003PV-EB for isms@ietf.org; Mon, 03 Oct 2005 23:48:26 -0400 Received: from h-64-105-136-135.snvacaid.dynamic.covad.net ([64.105.136.135] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EMdeB-0006zC-00 for isms@ietf.org; Mon, 03 Oct 2005 23:39:19 -0400 Message-ID: <009301c5c895$a3eb0d20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510031226.IAA24901@ietf.org> Subject: Re: [Isms] authoritative Date: Mon, 3 Oct 2005 20:42:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: "'Tom Petch'" ; ; "'David T. Perkins'" > Cc: > Sent: Monday, October 03, 2005 5:26 AM > Subject: RE: [Isms] authoritative ... > To the rest of the WG, what are the reasons we need to maintain the > concept of authoritative? Does the authoritative securityEngineID need > to be passed in the message when using SSH or other external security > substrate? ... My recollection is that the only thing that the authoritative EngineID is needed for is to figure out whose boots/clock information to use in the anti-reply logic of USM. Conceptually, it goes back to the field snmpPartyIdentity described in RFC 1352, though the details of the timeliness algorithms are different. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 00:00:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdyc-0007q1-E9; Tue, 04 Oct 2005 00:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdya-0007pw-TX for isms@megatron.ietf.org; Tue, 04 Oct 2005 00:00:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10672 for ; Tue, 4 Oct 2005 00:00:22 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMe7B-0003yA-Hi for isms@ietf.org; Tue, 04 Oct 2005 00:09:18 -0400 Received: from h-64-105-136-135.snvacaid.dynamic.covad.net ([64.105.136.135] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EMdyX-0003hE-00 for isms@ietf.org; Tue, 04 Oct 2005 00:00:21 -0400 Message-ID: <00a201c5c898$971ef5e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510031226.IAA24901@ietf.org> <009301c5c895$a3eb0d20$7f1afea9@oemcomputer> Subject: Re: [Isms] authoritative Date: Mon, 3 Oct 2005 21:02:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" > To: > Sent: Monday, October 03, 2005 8:42 PM > Subject: Re: [Isms] authoritative ... > My recollection is that the only thing that the authoritative EngineID is > needed for is to figure out whose boots/clock information to use in > the anti-reply logic of USM. Conceptually, it goes back to the field > snmpPartyIdentity described in RFC 1352, though the details of the > timeliness algorithms are different. Oh, it is also used with the user name to allow the recipient to know which keys to use to authenticate and decrypt! But, to the point of David Harrington's question, does it need to be repeated on the wire in every message for every possible security model? I'd say no, since that information would be associated with the connection, assuming (1) there is a one user per connection limitation, and (2) we don't trip ourselves up by confusing the user name for an Inform with the the user name for a Trap. (2) may be OK as an operational simplification, but we need to be sure we're doing it consciously. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 01:40:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfWz-0002lS-Kw; Tue, 04 Oct 2005 01:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfWv-0002iX-Ek for isms@megatron.ietf.org; Tue, 04 Oct 2005 01:39:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14483 for ; Tue, 4 Oct 2005 01:39:55 -0400 (EDT) Received: from iae7c.i.pppool.de ([85.73.174.124] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMffT-00066r-JJ for isms@ietf.org; Tue, 04 Oct 2005 01:48:48 -0400 Received: by boskop.local (Postfix, from userid 501) id 24B83449C82; Tue, 4 Oct 2005 07:39:27 +0200 (CEST) Date: Tue, 4 Oct 2005 07:39:27 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] authoritative Message-ID: <20051004053927.GA1260@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <200510031226.IAA24901@ietf.org> <009301c5c895$a3eb0d20$7f1afea9@oemcomputer> <00a201c5c898$971ef5e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a201c5c898$971ef5e0$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Oct 03, 2005 at 09:02:57PM -0700, Randy Presuhn wrote: > [...] (2) we don't trip ourselves up by confusing the user name for > an Inform with the the user name for a Trap. (2) may be OK as an > operational simplification, but we need to be sure we're doing it > consciously. Randy, can you please elaborate on this? What do you think is the difference between a user name for a trap and an inform? It sounds like you believe there is a feature to have these different... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 01:56:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfme-0006Vw-DE; Tue, 04 Oct 2005 01:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfmc-0006Vo-Q0 for isms@megatron.ietf.org; Tue, 04 Oct 2005 01:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15049 for ; Tue, 4 Oct 2005 01:56:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMfvD-0006Rc-JM for isms@ietf.org; Tue, 04 Oct 2005 02:05:05 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2005 22:55:54 -0700 X-IronPort-AV: i="3.97,171,1125903600"; d="scan'208"; a="347981390:sNHT29705860" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j945tqKC028490; Mon, 3 Oct 2005 22:55:52 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4161.cisco.com [10.61.80.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9467Bs8009903; Mon, 3 Oct 2005 23:07:14 -0700 Message-ID: <43421965.9060907@cisco.com> Date: Tue, 04 Oct 2005 07:55:49 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4 (Macintosh/20050908) MIME-Version: 1.0 To: Randy Presuhn , isms@ietf.org Subject: Re: [Isms] authoritative References: <200510031226.IAA24901@ietf.org> <009301c5c895$a3eb0d20$7f1afea9@oemcomputer> <00a201c5c898$971ef5e0$7f1afea9@oemcomputer> <20051004053927.GA1260@boskop.local> In-Reply-To: <20051004053927.GA1260@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=309; t=1128406034; x=1128838234; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20authoritative| From:Eliot=20Lear=20| Date:Tue,=2004=20Oct=202005=2007=3A55=3A49=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=P3ZbuLBJ/kmYJC/NnPjUsbhVCrN5w9kKDBQ4oFoAtR2H/HlF9Jn++DXgaToHRLKT9Gayc773 EafNnflzRRZ/F8bsrVaLuTGqIEodSvjbAKKDbDorCllhZ6VMAE2scfEL2uTyCNA24ydKyOK+SjN cXmeI977/lYSNBqQ2QGdDXpU= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder wrote: > can you please elaborate on this? What do you think is the difference > between a user name for a trap and an inform? It sounds like you > believe there is a feature to have these different... While I didn't think that's where Randy was going I do wonder what the operational difference between trap and inform would be in the case of SSHSM. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 08:41:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMm7L-0008AE-Ez; Tue, 04 Oct 2005 08:41:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMm7K-00089d-17 for isms@megatron.ietf.org; Tue, 04 Oct 2005 08:41:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15433 for ; Tue, 4 Oct 2005 08:41:56 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmFz-0007lO-E9 for isms@ietf.org; Tue, 04 Oct 2005 08:50:56 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2D307E0049; Tue, 4 Oct 2005 08:41:52 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] IETF64 meeting References: <200510032251.SAA24962@ietf.org> From: Sam Hartman Date: Tue, 04 Oct 2005 08:41:52 -0400 In-Reply-To: <200510032251.SAA24962@ietf.org> (David B. Harrington's message of "Mon, 3 Oct 2005 18:51:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi Sam, Did Juergen get a meeting request to you today in David> time? It turns out he sent in a meeting request last week and I missed it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 13:01:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqA8-0003Wt-BM; Tue, 04 Oct 2005 13:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqA6-0003Vk-2R for isms@megatron.ietf.org; Tue, 04 Oct 2005 13:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10208 for ; Tue, 4 Oct 2005 13:01:02 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMqIn-0001Hm-II for isms@ietf.org; Tue, 04 Oct 2005 13:10:06 -0400 Received: from h-68-166-189-106.snvacaid.dynamic.covad.net ([68.166.189.106] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EMq9v-0004lV-00 for isms@ietf.org; Tue, 04 Oct 2005 13:00:56 -0400 Message-ID: <001001c5c905$9e5ad6e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510031226.IAA24901@ietf.org> <009301c5c895$a3eb0d20$7f1afea9@oemcomputer> <00a201c5c898$971ef5e0$7f1afea9@oemcomputer> <20051004053927.GA1260@boskop.local> Subject: Re: [Isms] authoritative Date: Tue, 4 Oct 2005 10:04:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, October 03, 2005 10:39 PM > Subject: Re: [Isms] authoritative > > On Mon, Oct 03, 2005 at 09:02:57PM -0700, Randy Presuhn wrote: > > > [...] (2) we don't trip ourselves up by confusing the user name for > > an Inform with the the user name for a Trap. (2) may be OK as an > > operational simplification, but we need to be sure we're doing it > > consciously. > > Randy, > > can you please elaborate on this? What do you think is the difference > between a user name for a trap and an inform? It sounds like you > believe there is a feature to have these different... ... I'd say it's more an artifact of USM rather than a "feature", but it will affect operational policies. In USM, the USM user name's "scope" is limited to a particular engine, thus the indexing structure of the USM user table. Nothing in USM requires or assumes that user "joe" on system A has any relationship whatsoever to user "joe" on system B. With USM, even if the security policy has been rationalized so that the same model-independent security name is used for all systems in an administrative domain (let's not worry about federation) there is still good reason to use different USM user names for informs and traps. That reason is key localization. For traps, the sender is authoritative, meaning it is the sender's localized keys that are used for authentication and privacy. Compromise of the sending SNMP engine does not allow an attacker to impersonate any other SNMP engine, and enables attacks only on the compromised device. For Informs, the recipient is authoritative. Compromise of the sending SNMP engine allows an attacker to generate authenticated Get, Get-Next, and Set requests that will look like they came from the Inform's intended destination. For this reason, the USM user names used for Informs should NOT be ones that map to model-independent security names that belong to VACM groups with vacmAccessReadViewName or vacmAccessWriteViewName that permit access to anything sensitive, on *ANY* system in the administrative domain. (I'd set them both to ""). You can see why I'd call it an "artifact" rather than a feature. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 13:14:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqMn-0007Oy-2W; Tue, 04 Oct 2005 13:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqMl-0007Ot-J3 for isms@megatron.ietf.org; Tue, 04 Oct 2005 13:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10734 for ; Tue, 4 Oct 2005 13:14:07 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMqVT-0001aG-OT for isms@ietf.org; Tue, 04 Oct 2005 13:23:12 -0400 Received: from h-68-166-189-106.snvacaid.dynamic.covad.net ([68.166.189.106] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EMqMj-00011k-00 for isms@ietf.org; Tue, 04 Oct 2005 13:14:09 -0400 Message-ID: <004101c5c907$7bce5140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510031226.IAA24901@ietf.org><009301c5c895$a3eb0d20$7f1afea9@oemcomputer><00a201c5c898$971ef5e0$7f1afea9@oemcomputer><20051004053927.GA1260@boskop.local> <001001c5c905$9e5ad6e0$7f1afea9@oemcomputer> Subject: Re: [Isms] authoritative Date: Tue, 4 Oct 2005 10:17:22 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - Ooops, I got it wrong. It's been too long. :-) Corrections below. Randy > From: "Randy Presuhn" > To: > Sent: Tuesday, October 04, 2005 10:04 AM > Subject: Re: [Isms] authoritative > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Monday, October 03, 2005 10:39 PM > > Subject: Re: [Isms] authoritative > > > > On Mon, Oct 03, 2005 at 09:02:57PM -0700, Randy Presuhn wrote: > > > > > [...] (2) we don't trip ourselves up by confusing the user name for > > > an Inform with the the user name for a Trap. (2) may be OK as an > > > operational simplification, but we need to be sure we're doing it > > > consciously. > > > > Randy, > > > > can you please elaborate on this? What do you think is the difference > > between a user name for a trap and an inform? It sounds like you > > believe there is a feature to have these different... > ... > > I'd say it's more an artifact of USM rather than a "feature", but it will > affect operational policies. > > > In USM, the USM user name's "scope" is limited to > a particular engine, thus the indexing structure of the USM user table. > Nothing in USM requires or assumes that user "joe" on system A has > any relationship whatsoever to user "joe" on system B. > > With USM, even if the security policy has been rationalized so that the > same model-independent security name is used for all systems in > an administrative domain (let's not worry about federation) there is > still good reason to use different USM user names for informs and > traps. That reason is key localization. so far, so good. > For traps, the sender is authoritative, meaning it is the sender's > localized keys that are used for authentication and privacy. Compromise > of the sending SNMP engine does not allow an attacker to impersonate any > other SNMP engine, and enables attacks only on the compromised device. > > For Informs, the recipient is authoritative. Compromise of the sending > SNMP engine allows an attacker to generate authenticated Get, Get-Next, > and Set requests that will look like they came from the Inform's intended > destination. s/intended destination/sender/ Add: It also allows Informs to be sent as though they were coming from any other system. > For this reason, the USM user names used for Informs > should NOT be ones that map to model-independent security names > that belong to VACM groups with vacmAccessReadViewName or > vacmAccessWriteViewName that permit access to anything sensitive, > on *ANY* system in the administrative domain. (I'd set them both to ""). > > > You can see why I'd call it an "artifact" rather than a feature. > > Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 04 14:26:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrUy-0007SW-J1; Tue, 04 Oct 2005 14:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrUx-0007S2-OG for isms@megatron.ietf.org; Tue, 04 Oct 2005 14:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15673 for ; Tue, 4 Oct 2005 14:26:42 -0400 (EDT) Message-Id: <200510041826.OAA15673@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMrdf-00042m-6I for isms@ietf.org; Tue, 04 Oct 2005 14:35:45 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20051004182632011009fpile>; Tue, 4 Oct 2005 18:26:32 +0000 From: "David B Harrington" To: "'Juergen Quittek'" Date: Tue, 4 Oct 2005 14:26:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXJESHRZOiTqAfOQ3eIo7oXAFMKGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] drafts X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen Q, Should we publish the existing TMSM and SSHSM drafts as ISMS WG drafts? If so, you'll need to approve these -00- drafts. The TMSM draft hasn't changed significantly, so that's ready to submit. I expect to have an updated SSHSM by the deadline for -00- drafts. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 05 16:12:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFcy-0001LS-6D; Wed, 05 Oct 2005 16:12:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENF4v-0001Mz-LC for isms@megatron.ietf.org; Wed, 05 Oct 2005 15:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13263 for ; Wed, 5 Oct 2005 15:37:23 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENFDr-0005lL-Ba for isms@ietf.org; Wed, 05 Oct 2005 15:46:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 49628E0049; Wed, 5 Oct 2005 15:37:22 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Wed, 05 Oct 2005 15:37:22 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Isms] chair search 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. I was not nearly as diligent as I should have been on working to find a ISMS chair. There were several higher priority items and I believe that at this point one chair is sufficient. Also, I believe nothing stops you from moving forward under the new charter. I'm now talking to some people. Then I will talk to Juergen and select a chair. Then the chair and new charter will be announced. I definitely hope to have this concluded by Vancouver. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 05 23:10:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENM9o-0004hL-Jk; Wed, 05 Oct 2005 23:10:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENM9n-0004hG-DR for isms@megatron.ietf.org; Wed, 05 Oct 2005 23:10:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18545 for ; Wed, 5 Oct 2005 23:10:52 -0400 (EDT) Received: from c-67-180-254-221.hsd1.ca.comcast.net ([67.180.254.221] helo=fullsail.no-ip.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENMIm-0008IF-AZ for isms@ietf.org; Wed, 05 Oct 2005 23:20:13 -0400 Received: from [127.0.0.1] (speed.nextbeacon.com [192.168.1.21]) by fullsail.no-ip.info (8.12.8/8.12.8) with ESMTP id j961VqUT023215 for ; Wed, 5 Oct 2005 18:31:55 -0700 Message-ID: <43449635.5050007@nextbeacon.com> Date: Wed, 05 Oct 2005 20:12:53 -0700 From: Steve Waldbusser User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org Subject: Re: [Isms] authoritative References: <200510011725.NAA11175@ietf.org> In-Reply-To: <200510011725.NAA11175@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David H. and Bert asked me to give some background on this because I represented one end of a long debate on this issue about 10 years ago. My point back then was that it is very important for responders to be authoritative (as opposed to initiators being authoritative) In this type of communication, one end is deemed authoritative and typically has keys stored in long-term storage. The other end either gets the key from a human or has a "cached" copy of the key (I say "cached" because in the event the authoritative end says the key is wrong, it is simply discarded at which point the usual fallback is to prompt the user for the correct key). We are very accustomed to the situation where the responder is authoritative and I guess we don't give it much thought. A transaction initiated by a user asks the user for the key and sends it. If the responder says the key is wrong, the user is prompted for a new one. If the transaction is initiated by unattended software, the key must be cached. But imagine the case if the initiator was authoritative. Then the responder must be the end with the human and/or the cached key. When a request arrives at the responder, a human can't react quickly enough to a prompt to type the key within the retransmit period so this doesn't work (and there may not be a human or the right human sitting at the responder anyway). So basically we are forced to cache the key. That's not so bad until we ask which keys are we going to cache? Unfortunately, one answer is *all of them*. If there are 1000 potential initiators each with 10 users, then I have to cache all 10,000 keys because only the initiators will know if they ever have any intention of sending me a transaction and I need to be prepared in case they do. An alternative is to treat it as a provisioning task: when I configure a system to initiate transactions, I must load the key into all systems that I plan to communicate with which is a burden best avoided. Plus it seems that having all of those keys floating around might not be in the best interests of security. To summarize, making the initiator authoritative means either: - a massive configuration of all possible initiators in all possible responders; or, - an additional, expensive provisioning step for setting up a new initiator (or even if I'm just adding a new communications target for an existing initiator). Most apps (email, fileshare, web, ssh) follow the "responder is authoritative" model. I can't think of any exceptions. I haven't been following your discussion so I might be wrong about the implications, but it seems to me that the implication is that the notion of authoritative is really a snmpv3 notion and not just a USM notion. Steve _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 06 11:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENY0p-0001ii-Gp; Thu, 06 Oct 2005 11:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENY0o-0001id-2c for isms@megatron.ietf.org; Thu, 06 Oct 2005 11:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11378 for ; Thu, 6 Oct 2005 11:50:23 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENY9t-0005aX-1i for isms@ietf.org; Thu, 06 Oct 2005 11:59:51 -0400 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 IAA27498; Thu, 6 Oct 2005 08:50:06 -0700 (PDT) Received: from XCH-NWBH-11.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 j96Fo6o13509; Thu, 6 Oct 2005 10:50:06 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Oct 2005 08:50:06 -0700 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] authoritative Date: Thu, 6 Oct 2005 08:50:05 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBC9CB@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] authoritative Thread-Index: AcXKI67CPDC3IiiCS9ehIZbKUC4sJAAaOXvA From: "Fleischman, Eric" To: "Steve Waldbusser" , X-OriginalArrivalTime: 06 Oct 2005 15:50:06.0101 (UTC) FILETIME=[9F41B450:01C5CA8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Steve, Your points resonate with me in environments using shared secret keys. However, other environments also exist such as: 1) Authoratative server acting as intermediary (e.g., Kerberos, RADIUS) 2) Keys issues from an authorative source (e.g., PKI) In these latter two environments, neither the initiator nor the responder is authorative but, rather, they use the agency of another entity that is both authorative and trusted. In my own mind, ISMS is trying to evolve from the original shared secret key model to a model in which a trusted server or a trusted issuing agency is authoratative. Given this transition, I have trouble understanding how this historic argument is still an issue for ISMS. Do you believe that it is and, if so, what are your thoughts on this matter? --Eric -----Original Message----- From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com]=20 Sent: Wednesday, October 05, 2005 8:13 PM To: isms@ietf.org Subject: Re: [Isms] authoritative David H. and Bert asked me to give some background on this because I=20 represented one end of a long debate on this issue about 10 years ago. My point back then was that it is very important for responders to be=20 authoritative (as opposed to initiators being authoritative) In this type of communication, one end is deemed authoritative and=20 typically has keys stored in long-term storage. The other end either=20 gets the key from a human or has a "cached" copy of the key (I say=20 "cached" because in the event the authoritative end says the key is=20 wrong, it is simply discarded at which point the usual fallback is to=20 prompt the user for the correct key). We are very accustomed to the situation where the responder is=20 authoritative and I guess we don't give it much thought. A transaction=20 initiated by a user asks the user for the key and sends it. If the=20 responder says the key is wrong, the user is prompted for a new one. If=20 the transaction is initiated by unattended software, the key must be cached. But imagine the case if the initiator was authoritative. Then the=20 responder must be the end with the human and/or the cached key. When a=20 request arrives at the responder, a human can't react quickly enough to=20 a prompt to type the key within the retransmit period so this doesn't=20 work (and there may not be a human or the right human sitting at the=20 responder anyway). So basically we are forced to cache the key. That's=20 not so bad until we ask which keys are we going to cache? Unfortunately, one answer is *all of them*. If there are 1000 potential initiators each with 10 users, then I have to cache all 10,000 keys because only the=20 initiators will know if they ever have any intention of sending me a=20 transaction and I need to be prepared in case they do. An alternative is to treat it as a provisioning task: when I configure a system to=20 initiate transactions, I must load the key into all systems that I plan=20 to communicate with which is a burden best avoided. Plus it seems that=20 having all of those keys floating around might not be in the best=20 interests of security. To summarize, making the initiator authoritative means either: - a massive configuration of all possible initiators in all possible=20 responders; or, - an additional, expensive provisioning step for setting up a new=20 initiator (or even if I'm just adding a new communications target for an existing initiator). Most apps (email, fileshare, web, ssh) follow the "responder is=20 authoritative" model. I can't think of any exceptions. I haven't been following your discussion so I might be wrong about the=20 implications, but it seems to me that the implication is that the notion of authoritative is really a snmpv3 notion and not just a USM notion. Steve _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 06 20:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENfuT-0002VN-IE; Thu, 06 Oct 2005 20:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENfuS-0002VI-KT for isms@megatron.ietf.org; Thu, 06 Oct 2005 20:16:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28810 for ; Thu, 6 Oct 2005 20:16:22 -0400 (EDT) Received: from c-67-180-254-221.hsd1.ca.comcast.net ([67.180.254.221] helo=fullsail.no-ip.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENg3d-0008Va-OY for isms@ietf.org; Thu, 06 Oct 2005 20:25:54 -0400 Received: from [127.0.0.1] (speed.nextbeacon.com [192.168.1.21]) by fullsail.no-ip.info (8.12.8/8.12.8) with ESMTP id j96MmMG5004114; Thu, 6 Oct 2005 15:48:23 -0700 Message-ID: <4345BED1.6070507@nextbeacon.com> Date: Thu, 06 Oct 2005 17:18:25 -0700 From: Steve Waldbusser User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [Isms] authoritative References: <474EEBD229DF754FB83D256004D02108BBC9CB@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108BBC9CB@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On 10/6/2005 8:50 AM, Fleischman, Eric wrote: >Steve, > >Your points resonate with me in environments using shared secret keys. >However, other environments also exist such as: >1) Authoratative server acting as intermediary (e.g., Kerberos, RADIUS) >2) Keys issues from an authorative source (e.g., PKI) > > Yes, you're right. >In these latter two environments, neither the initiator nor the >responder is authorative but, rather, they use the agency of another >entity that is both authorative and trusted. In my own mind, ISMS is >trying to evolve from the original shared secret key model to a model in >which a trusted server or a trusted issuing agency is authoratative. >Given this transition, I have trouble understanding how this historic >argument is still an issue for ISMS. Do you believe that it is and, if >so, what are your thoughts on this matter? > > The conclusion I draw from your message is that I was wrong to suggest that it is an snmpv3 issue (i.e. transport level) . Instead, it would be more correct to say that the issue applies to all shared secret key models like USM. Or maybe rather than saying "the responder should be authoritative", we should say "the initiator shouldn't be authoritative" and note that even in your Kerberos, Radius, PKI examples *somebody* is always authoritative. Does that mean it's an snmpv3 issue again? Forgive me as I'm not up to speed on the issues here and I could see myself changing my mind a few more times before I'm done. But what worries me the most is that this sounds less and less like the issue I was first asked to comment on which I thought was roughly "we're trying to define SNMP over SSH and for notifications it has been asserted that it would be better if we made the initiator authoritative." If that's the question, then my opinion is it would be a bad thing. Steve >--Eric > >-----Original Message----- >From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com] >Sent: Wednesday, October 05, 2005 8:13 PM >To: isms@ietf.org >Subject: Re: [Isms] authoritative > > > >David H. and Bert asked me to give some background on this because I >represented one end of a long debate on this issue about 10 years ago. > >My point back then was that it is very important for responders to be >authoritative (as opposed to initiators being authoritative) > >In this type of communication, one end is deemed authoritative and >typically has keys stored in long-term storage. The other end either >gets the key from a human or has a "cached" copy of the key (I say >"cached" because in the event the authoritative end says the key is >wrong, it is simply discarded at which point the usual fallback is to >prompt the user for the correct key). > >We are very accustomed to the situation where the responder is >authoritative and I guess we don't give it much thought. A transaction >initiated by a user asks the user for the key and sends it. If the >responder says the key is wrong, the user is prompted for a new one. If >the transaction is initiated by unattended software, the key must be >cached. > >But imagine the case if the initiator was authoritative. Then the >responder must be the end with the human and/or the cached key. When a >request arrives at the responder, a human can't react quickly enough to >a prompt to type the key within the retransmit period so this doesn't >work (and there may not be a human or the right human sitting at the >responder anyway). So basically we are forced to cache the key. That's >not so bad until we ask which keys are we going to cache? Unfortunately, > >one answer is *all of them*. If there are 1000 potential initiators each > >with 10 users, then I have to cache all 10,000 keys because only the >initiators will know if they ever have any intention of sending me a >transaction and I need to be prepared in case they do. An alternative is > >to treat it as a provisioning task: when I configure a system to >initiate transactions, I must load the key into all systems that I plan >to communicate with which is a burden best avoided. Plus it seems that >having all of those keys floating around might not be in the best >interests of security. > >To summarize, making the initiator authoritative means either: >- a massive configuration of all possible initiators in all possible >responders; or, >- an additional, expensive provisioning step for setting up a new >initiator (or even if I'm just adding a new communications target for an > >existing initiator). > >Most apps (email, fileshare, web, ssh) follow the "responder is >authoritative" model. I can't think of any exceptions. > >I haven't been following your discussion so I might be wrong about the >implications, but it seems to me that the implication is that the notion > >of authoritative is really a snmpv3 notion and not just a USM notion. > > >Steve > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 07 14:18:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwnI-0002jj-Ez; Fri, 07 Oct 2005 14:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwnG-0002jb-Km for isms@megatron.ietf.org; Fri, 07 Oct 2005 14:18:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03898 for ; Fri, 7 Oct 2005 14:18:04 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwwa-00025t-Gu for isms@ietf.org; Fri, 07 Oct 2005 14:27:45 -0400 Received: from pc6 (1Cust119.tnt21.lnd4.gbr.da.uu.net [62.188.150.119]) by blaster.systems.pipex.net (Postfix) with SMTP id 280FBE000079; Fri, 7 Oct 2005 19:17:41 +0100 (BST) Message-ID: <018e01c5cb62$ed1902c0$0601a8c0@pc6> From: "Tom Petch" To: "Steve Waldbusser" , References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> Subject: Re: [Isms] authoritative Date: Fri, 7 Oct 2005 19:16:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm puzzled, on a number of counts, primarily on what authoritative means. Reading the SNMPv3 RFC, excluding USM, I find the term used as a gloss for securityEngine ID and that only appears on the ASI of the security model and is only used, in MPP, on receipt of a Confirmed Class PDU, when the securityEngineID must match the snmpEngineID else the message is discarded ie it appears to provide an additional check that the message really got to the intended engine. Within USM, it is described as protecting against message replay, delay and redirection which I see as a problem for USM that SSH takes care of by setting up a secure tunnel. This makes me see it as a USM, rather than an SNMPv3, concept. Another puzzle is your reference to ssh following the "responder is authoritative" model. ssh always authenticates the server (with client authentication as optional); does not this make the initiator authoritative? Tom Petch ----- Original Message ----- From: "Steve Waldbusser" To: Sent: Thursday, October 06, 2005 5:12 AM Subject: Re: [Isms] authoritative > > David H. and Bert asked me to give some background on this because I > represented one end of a long debate on this issue about 10 years ago. > > My point back then was that it is very important for responders to be > authoritative (as opposed to initiators being authoritative) > > In this type of communication, one end is deemed authoritative and > typically has keys stored in long-term storage. The other end either > gets the key from a human or has a "cached" copy of the key (I say > "cached" because in the event the authoritative end says the key is > wrong, it is simply discarded at which point the usual fallback is to > prompt the user for the correct key). > > We are very accustomed to the situation where the responder is > authoritative and I guess we don't give it much thought. A transaction > initiated by a user asks the user for the key and sends it. If the > responder says the key is wrong, the user is prompted for a new one. If > the transaction is initiated by unattended software, the key must be cached. > > But imagine the case if the initiator was authoritative. Then the > responder must be the end with the human and/or the cached key. When a > request arrives at the responder, a human can't react quickly enough to > a prompt to type the key within the retransmit period so this doesn't > work (and there may not be a human or the right human sitting at the > responder anyway). So basically we are forced to cache the key. That's > not so bad until we ask which keys are we going to cache? Unfortunately, > one answer is *all of them*. If there are 1000 potential initiators each > with 10 users, then I have to cache all 10,000 keys because only the > initiators will know if they ever have any intention of sending me a > transaction and I need to be prepared in case they do. An alternative is > to treat it as a provisioning task: when I configure a system to > initiate transactions, I must load the key into all systems that I plan > to communicate with which is a burden best avoided. Plus it seems that > having all of those keys floating around might not be in the best > interests of security. > > To summarize, making the initiator authoritative means either: > - a massive configuration of all possible initiators in all possible > responders; or, > - an additional, expensive provisioning step for setting up a new > initiator (or even if I'm just adding a new communications target for an > existing initiator). > > Most apps (email, fileshare, web, ssh) follow the "responder is > authoritative" model. I can't think of any exceptions. > > I haven't been following your discussion so I might be wrong about the > implications, but it seems to me that the implication is that the notion > of authoritative is really a snmpv3 notion and not just a USM notion. > > > Steve > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 07 15:02:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxUJ-0007QN-55; Fri, 07 Oct 2005 15:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxUH-0007QI-SP for isms@megatron.ietf.org; Fri, 07 Oct 2005 15:02:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06331 for ; Fri, 7 Oct 2005 15:02:31 -0400 (EDT) Received: from i8412.i.pppool.de ([85.73.132.18] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENxdc-0003uY-5q for isms@ietf.org; Fri, 07 Oct 2005 15:12:13 -0400 Received: by boskop.local (Postfix, from userid 501) id 6C7EC4BB558; Fri, 7 Oct 2005 21:01:59 +0200 (CEST) Date: Fri, 7 Oct 2005 21:01:59 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] authoritative Message-ID: <20051007190159.GA907@boskop.local> Mail-Followup-To: Tom Petch , Steve Waldbusser , isms@ietf.org References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> <018e01c5cb62$ed1902c0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018e01c5cb62$ed1902c0$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Oct 07, 2005 at 07:16:19PM +0200, Tom Petch wrote: > I'm puzzled, on a number of counts, primarily on what authoritative means. I agree. For me, the context in which you use the work authoritative is import to understand where we are. In a layered system, one can talk about: a) Who is authoritative wrt. the information transported by a protocol. Lets call this "information authoritative". b) Who is authoritative wrt. the keys used in a security protocol. Lets call this "key authoritative". c) Who is authoritative wrt. the clocks used in a security protocol Lets call this "clock authoritative". d) Who is authoritative wrt. to access control decisions. Lets call this "access control authoritative". In the contact of SNMP, I think the notification originator is "information authoritative" for Notification Class PDUs while the command responder is "information authoritative" for Read Class PDUs. One could argue that the command generator is "information authoritative" for Write Class PDUs. Furthermore, it seems rather clear that USM defines clear roles for the messages containing the various PDU types regarding who is "clock authoritative". Obviously, this concept is USM specific since the clock synchronization mechanism is USM specific. A bit less clear is probably the notion of "key authoritativeness". In a classic symmetric key protocol, one could argue that both peers share the same authoritativeness. USM, however, uses localized keys and one therefore might argue that the authoritativeness is not shared equally. Still, I consider the question of who is "key authoritative" a security model specific issue. Regarding access control, it is rather clean in SNMP that the command responder and the notification originater are "access control authoritative". Perhaps this helps to organize the discussion. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 09 05:43:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOXiJ-00088v-CU; Sun, 09 Oct 2005 05:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOXiI-00088q-FV for isms@megatron.ietf.org; Sun, 09 Oct 2005 05:43:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05581 for ; Sun, 9 Oct 2005 05:43:24 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOXrw-0006D0-Ge for isms@ietf.org; Sun, 09 Oct 2005 05:53:26 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-004-231.hsi.kabelbw.de [85.216.4.231]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 037961BAC4D; Sun, 9 Oct 2005 11:43:07 +0200 (CEST) Date: Sun, 09 Oct 2005 11:43:06 +0200 From: Juergen Quittek To: David Nelson Message-ID: <2C724C97828B104E2AE66C91@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Bernard Aboba Subject: [Isms] READEXT and ISMS sessions in Vancouver 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, It would be nice if someone could present the request from ISMS to RADEXT on specifying RADIUS attributes for TMSMs at the Vancouver session. Can you reserve a time slot for this in the RADEXT agenda? It would also be of big help if you could participate in the ISMS session. Unfortunately, I found that the draft schedule for Vancouver has the RADEXT and ISMS sessions scheduled in parallel. Would you support a request for re-scheduling one of the sessions? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 09 06:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOYeK-0001rz-4o; Sun, 09 Oct 2005 06:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOYeI-0001rr-LM for isms@megatron.ietf.org; Sun, 09 Oct 2005 06:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07944 for ; Sun, 9 Oct 2005 06:43:20 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOYny-0007aP-6o for isms@ietf.org; Sun, 09 Oct 2005 06:53:23 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j99AeZGO014271 for ; Sun, 9 Oct 2005 06:40:35 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j99AeXGO014221 for ; Sun, 9 Oct 2005 06:40:34 -0400 (EDT) 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] READEXT and ISMS sessions in Vancouver Date: Sun, 9 Oct 2005 12:43:17 +0200 Message-ID: Thread-Topic: [Isms] READEXT and ISMS sessions in Vancouver Thread-Index: AcXMth4tESUeJWrbTNGz9ffGb3rkvgAB/v5A From: "Romascanu, Dan \(Dan\)" To: "Juergen Quittek" , "David Nelson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, Bernard Aboba 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I also would like to see the scheduling conflict between ISMS and RADEXT avoided.=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Sunday, October 09, 2005 11:43 AM > To: David Nelson > Cc: isms@ietf.org; Bernard Aboba > Subject: [Isms] READEXT and ISMS sessions in Vancouver >=20 > David, >=20 > It would be nice if someone could present the request from=20 > ISMS to RADEXT on specifying RADIUS attributes for TMSMs at=20 > the Vancouver session. Can you reserve a time slot for this=20 > in the RADEXT agenda? >=20 > It would also be of big help if you could participate in the=20 > ISMS session. >=20 > Unfortunately, I found that the draft schedule for Vancouver=20 > has the RADEXT and ISMS sessions scheduled in parallel. =20 > Would you support a request for re-scheduling one of the sessions? >=20 > Thanks, >=20 > Juergen > --=20 > Juergen Quittek quittek@netlab.nec.de Tel: +49=20 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49=20 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany =20 > http://www.netlab.nec.de >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 09 07:56:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZmj-0005aV-IP; Sun, 09 Oct 2005 07:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZmh-0005Xl-ND for isms@megatron.ietf.org; Sun, 09 Oct 2005 07:56:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12209 for ; Sun, 9 Oct 2005 07:56:06 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOZwN-0001Ox-Qw for isms@ietf.org; Sun, 09 Oct 2005 08:06:09 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id HAA25475 for ; Sun, 9 Oct 2005 07:59:15 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma025458; Sun, 9 Oct 05 07:59:06 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Sun, 09 Oct 2005 07:55:48 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Sun, 09 Oct 2005 07:55:48 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 9 Oct 2005 07:55:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Oct 2005 07:51:24 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901292CD2@MAANDMBX2.ets.enterasys.com> Thread-Topic: READEXT and ISMS sessions in Vancouver Thread-Index: AcXMtd/hMgkkSnVjRf+fXp4qlOVgwAAEeZva From: "Nelson, David" To: "Juergen Quittek" X-OriginalArrivalTime: 09 Oct 2005 11:55:48.0539 (UTC) FILETIME=[638938B0:01C5CCC8] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, Bernard Aboba Subject: [Isms] RE: READEXT and ISMS sessions in Vancouver 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Quittek writes... > It would be nice if someone could present the request from ISMS to > RADEXT on specifying RADIUS attributes for TMSMs at the Vancouver > session. Can you reserve a time slot for this in the RADEXT agenda? =20 Yes. > It would also be of big help if you could participate in the ISMS = session. > > Unfortunately, I found that the draft schedule for Vancouver has the > RADEXT and ISMS sessions scheduled in parallel. Would you support a > request for re-scheduling one of the sessions? Sure, but the draft Agenda I saw has RADEXT and ISMS in separate time = slots: =20 TUESDAY, November 8, 2005 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP rui Remote UI BOF INT ipv6 IP Version 6 WG INT monami6 Mobile Nodes and Multiple Interfaces in IPv6 BOF OPS radext Radius Extensions WG RTG mpls MultiProtocol Label Switching WG SEC sasl Simple Authentication and Security Layer WG TSV nfsv4 Network File System Version 4 WG TSV xcon Centralized Conferencing WG 1130-1300 Break 1300-1500 Afternoon Session I APP imapext Internet Message Access Protocol Extension WG INT 16ng IPv6 over IEEE 802.6(e) Network BOF RTG forces Forwarding and Control Element Separation WG RTG idr Inter-Domain Routing WG SEC isms Integrated Security Model for SNMP WG SEC pkix Public-Key Infrastructure (X.509) WG TSV rserpool Reliable Server Pooling WG TSV sip Session Initiation Protocol WG =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 09 20:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOli6-00080u-Vz; Sun, 09 Oct 2005 20:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOli5-00080p-B9 for isms@megatron.ietf.org; Sun, 09 Oct 2005 20:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21339 for ; Sun, 9 Oct 2005 20:40:07 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOlrr-0003Gv-TO for isms@ietf.org; Sun, 09 Oct 2005 20:50:17 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-004-231.hsi.kabelbw.de [85.216.4.231]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 447131BAC4D; Mon, 10 Oct 2005 02:39:51 +0200 (CEST) Date: Mon, 10 Oct 2005 02:39:51 +0200 From: Juergen Quittek To: "Nelson, David" Message-ID: <4A9066D8FD675423C0141691@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Bernard Aboba Subject: [Isms] RE: READEXT and ISMS sessions in Vancouver 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Are there any volunteers for presenting the issue at the READEXT session? --On 09.10.2005 7:51 Uhr -0400 Nelson, David wrote: > Juergen Quittek writes... > >> It would be nice if someone could present the request from ISMS to >> RADEXT on specifying RADIUS attributes for TMSMs at the Vancouver >> session. Can you reserve a time slot for this in the RADEXT agenda? > > Yes. > >> It would also be of big help if you could participate in the ISMS session. >> >> Unfortunately, I found that the draft schedule for Vancouver has the >> RADEXT and ISMS sessions scheduled in parallel. Would you support a >> request for re-scheduling one of the sessions? > > Sure, but the draft Agenda I saw has RADEXT and ISMS in separate time slots: Sorry, I looked it up at the wrong place. Yes, in the schedule distributed on Friday there is no conflict. Thanks, Juergen > TUESDAY, November 8, 2005 > 0800-1800 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Session I > APP rui Remote UI BOF > INT ipv6 IP Version 6 WG > INT monami6 Mobile Nodes and Multiple Interfaces in IPv6 BOF > OPS radext Radius Extensions WG > RTG mpls MultiProtocol Label Switching WG > SEC sasl Simple Authentication and Security Layer WG > TSV nfsv4 Network File System Version 4 WG > TSV xcon Centralized Conferencing WG > > 1130-1300 Break > 1300-1500 Afternoon Session I > APP imapext Internet Message Access Protocol Extension WG > INT 16ng IPv6 over IEEE 802.6(e) Network BOF > RTG forces Forwarding and Control Element Separation WG > RTG idr Inter-Domain Routing WG > SEC isms Integrated Security Model for SNMP WG > SEC pkix Public-Key Infrastructure (X.509) WG > TSV rserpool Reliable Server Pooling WG > TSV sip Session Initiation Protocol WG > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 10 14:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2hs-0005yY-6Q; Mon, 10 Oct 2005 14:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2hq-0005ww-0q for isms@megatron.ietf.org; Mon, 10 Oct 2005 14:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12288 for ; Mon, 10 Oct 2005 14:49:00 -0400 (EDT) Received: from c-67-180-254-221.hsd1.ca.comcast.net ([67.180.254.221] helo=fullsail.no-ip.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2rl-0004qn-HD for isms@ietf.org; Mon, 10 Oct 2005 14:59:19 -0400 Received: from [127.0.0.1] (speed.nextbeacon.com [192.168.1.21]) by fullsail.no-ip.info (8.12.8/8.12.8) with ESMTP id j9AHKVer004822; Mon, 10 Oct 2005 10:20:34 -0700 Message-ID: <434AB800.4090300@nextbeacon.com> Date: Mon, 10 Oct 2005 11:50:40 -0700 From: Steve Waldbusser User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] authoritative References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> <018e01c5cb62$ed1902c0$0601a8c0@pc6> <20051007190159.GA907@boskop.local> In-Reply-To: <20051007190159.GA907@boskop.local> X-Spam-Score: 2.6 (++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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: , Content-Type: multipart/mixed; boundary="===============0221214220==" Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0221214220== Content-Type: multipart/alternative; boundary="------------030308000605000509080701" This is a multi-part message in MIME format. --------------030308000605000509080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, Yes, it helps a lot. I've been speaking about "key authoritative". Steve On 10/7/2005 12:01 PM, Juergen Schoenwaelder wrote: >On Fri, Oct 07, 2005 at 07:16:19PM +0200, Tom Petch wrote: > > > >>I'm puzzled, on a number of counts, primarily on what authoritative means. >> >> > >I agree. For me, the context in which you use the work authoritative >is import to understand where we are. In a layered system, one can >talk about: > >a) Who is authoritative wrt. the information transported by a > protocol. Lets call this "information authoritative". > >b) Who is authoritative wrt. the keys used in a security protocol. > Lets call this "key authoritative". > >c) Who is authoritative wrt. the clocks used in a security protocol > Lets call this "clock authoritative". > >d) Who is authoritative wrt. to access control decisions. > Lets call this "access control authoritative". > >In the contact of SNMP, I think the notification originator is >"information authoritative" for Notification Class PDUs while the >command responder is "information authoritative" for Read Class >PDUs. One could argue that the command generator is "information >authoritative" for Write Class PDUs. > >Furthermore, it seems rather clear that USM defines clear roles for >the messages containing the various PDU types regarding who is "clock >authoritative". Obviously, this concept is USM specific since the >clock synchronization mechanism is USM specific. > >A bit less clear is probably the notion of "key authoritativeness". >In a classic symmetric key protocol, one could argue that both peers >share the same authoritativeness. USM, however, uses localized keys >and one therefore might argue that the authoritativeness is not shared >equally. Still, I consider the question of who is "key authoritative" >a security model specific issue. > >Regarding access control, it is rather clean in SNMP that the command >responder and the notification originater are "access control >authoritative". > >Perhaps this helps to organize the discussion. > >/js > > > --------------030308000605000509080701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Juergen,

  Yes, it helps a lot. I've been speaking about "key authoritative".

Steve


On 10/7/2005 12:01 PM, Juergen Schoenwaelder wrote: 
On Fri, Oct 07, 2005 at 07:16:19PM +0200, Tom Petch wrote:

  
I'm puzzled, on a number of counts, primarily on what authoritative means.
    

I agree. For me, the context in which you use the work authoritative
is import to understand where we are. In a layered system, one can
talk about:

a) Who is authoritative wrt. the information transported by a
   protocol. Lets call this "information authoritative".

b) Who is authoritative wrt. the keys used in a security protocol.
   Lets call this "key authoritative".

c) Who is authoritative wrt. the clocks used in a security protocol
   Lets call this "clock authoritative".

d) Who is authoritative wrt. to access control decisions. 
   Lets call this "access control authoritative".

In the contact of SNMP, I think the notification originator is
"information authoritative" for Notification Class PDUs while the
command responder is "information authoritative" for Read Class
PDUs. One could argue that the command generator is "information
authoritative" for Write Class PDUs.

Furthermore, it seems rather clear that USM defines clear roles for
the messages containing the various PDU types regarding who is "clock
authoritative". Obviously, this concept is USM specific since the
clock synchronization mechanism is USM specific.

A bit less clear is probably the notion of "key authoritativeness".
In a classic symmetric key protocol, one could argue that both peers
share the same authoritativeness. USM, however, uses localized keys
and one therefore might argue that the authoritativeness is not shared
equally. Still, I consider the question of who is "key authoritative"
a security model specific issue.

Regarding access control, it is rather clean in SNMP that the command
responder and the notification originater are "access control
authoritative".

Perhaps this helps to organize the discussion.

/js

--------------030308000605000509080701-- --===============0221214220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0221214220==-- From isms-bounces@lists.ietf.org Mon Oct 10 15:32:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3No-0000xk-Vg; Mon, 10 Oct 2005 15:32:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3Nn-0000xc-C8 for isms@megatron.ietf.org; Mon, 10 Oct 2005 15:32:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16025 for ; Mon, 10 Oct 2005 15:32:21 -0400 (EDT) Received: from c-67-180-254-221.hsd1.ca.comcast.net ([67.180.254.221] helo=fullsail.no-ip.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP3Xl-00069h-2r for isms@ietf.org; Mon, 10 Oct 2005 15:42:41 -0400 Received: from [127.0.0.1] (speed.nextbeacon.com [192.168.1.21]) by fullsail.no-ip.info (8.12.8/8.12.8) with ESMTP id j9AI4Eer004972; Mon, 10 Oct 2005 11:04:15 -0700 Message-ID: <434AC1C1.7080300@nextbeacon.com> Date: Mon, 10 Oct 2005 12:32:17 -0700 From: Steve Waldbusser User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Isms] authoritative References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> <018e01c5cb62$ed1902c0$0601a8c0@pc6> In-Reply-To: <018e01c5cb62$ed1902c0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >Another puzzle is your reference to ssh following the "responder is >authoritative" model. ssh always authenticates the server (with client >authentication as optional); does not this make the initiator authoritative? > If a ssh connection setup fails because the server couldn't be authenticated, it doesn't throw away its keys and try again with a new pair. This is true of both the server authentication portion as well as the optional client authentication (as well as the typical "plain" password). By "key authoritative", I mean that in the event of an authentication failure, the end that is key authoritative keeps its keys while the other end is forced to adapt by getting better keys, choosing not to communicate, getting the info from elsewhere, etc. And the end that is key authoritative better have those keys stored locally or a pretty quick means of getting them on demand. Steve _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 12 04:19:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbjf-00036y-H6; Wed, 12 Oct 2005 04:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbjd-00036k-4U; Wed, 12 Oct 2005 04:13:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04583; Wed, 12 Oct 2005 04:13:10 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPbts-0001xP-2R; Wed, 12 Oct 2005 04:23:50 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2005 01:13:01 -0700 X-IronPort-AV: i="3.97,205,1125903600"; d="scan'208"; a="665368836:sNHT25667928" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9C8Cwub016879; Wed, 12 Oct 2005 01:12:59 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp148.cisco.com [10.61.64.148]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9C8Nop3016722; Wed, 12 Oct 2005 01:23:50 -0700 Message-ID: <434CC589.2020608@cisco.com> Date: Wed, 12 Oct 2005 10:12:57 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "ops- nm"@ops.ietf.org, isms@ietf.org, call-home@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1932; t=1129105431; x=1129537631; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:last=20call=20for=20a=20Call=20Home=20BoF| From:Eliot=20Lear=20| Date:Wed,=2012=20Oct=202005=2010=3A12=3A57=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HMPtSMIPPWVMgx4ahNPbMftO4YsS9yKsA+ZDiZlJdx6RwtaI9Wj9b0d5wYdqMod6ePUVuPSZ fEFQeNuTzrCdYdnjaWs/kB8vmIchiBtdSut4JDaWphIT26DiRmcq2TrBoKslZ24lK5uGrizhU9d 1PBWHqy4yWKP9xtBUbsBCR9E= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.4 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] last call for a Call Home BoF 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org After all of the mail last month, Bert is considering allowing a BoF on the topic of Call Home. I initially posted a note to the call-home mailing list announcing the possibility of a BoF. Response to that note was - well - underwhelming. If you are interested in seeing one, could you please reply to this email, CCing the call-home mailing list. Here is a draft agenda. It is subject to your input. If we do not see much input, I'm going to drop the request to Bert. Eliot Title: callhome Period of time: 1 hour Area: ops-nm Expected # attendees: 40-60 (small room) Don't conflict with: ISMS, ops-area, netconf (if there is one) Short Description: Discussion of Architectural Issues Concerning protocols that could benefit from reversing of roles Long Description: Certain protocols, and in particular management protocols where devices on either end of connection take client server roles may be able to take advantage of "Call Home" functionality, when traditional roles are reversed, and a server connect to a client. Examples of existing protocols that make use of call home include SMTP [ETRN] and COPS. At this BoF we will look at extending such functionality into other protocols, as well as any architectural issues this raises. This work stems from efforts in ISMS to extend SNMP to run over SSH, as well as work as work that has gone on in NETCONF. We will begin with a discussion of draft-lear-callhome-description-0[1,2].txt, which contains a description of call home, what problems it can solve, and what some of the architectural issues are. During the BoF we may identify additional such issues as well as protocols other than management protocols that could benefit from this work. An additional potential question should be whether a generic standard or process should be used to implement call home, such as rules for SSH. There are three possible outcomes: a working group to add "call home" functionality to existing protocols such as SNMP/SSH and NETCONF/SSH, use of existing working groups for this purpose, or nothing. Chair: Eliot Lear (or tbd) Agenda: Agenda bashing - 1 minute Presentation of draft-lear-callhome-description-00.txt 19 minutes Application to SNMP and open areas - 10 minutes Discussion including architectural issues - 20 minutes Moving Forward Options - 10 minutes _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 12 13:58:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkrY-0004Id-To; Wed, 12 Oct 2005 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkrX-0004IY-N6 for isms@megatron.ietf.org; Wed, 12 Oct 2005 13:57:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08056 for ; Wed, 12 Oct 2005 13:57:55 -0400 (EDT) Message-Id: <200510121757.NAA08056@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPl1q-00028Z-N0 for isms@ietf.org; Wed, 12 Oct 2005 14:08:42 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101217574601300jrsube>; Wed, 12 Oct 2005 17:57:46 +0000 From: "David B Harrington" To: Date: Wed, 12 Oct 2005 13:57:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXOF2hESl6N7OemSIWU3zd++VjKPQBPuzNw X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] FW: Open issues from SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I sent this out yesterday, but I haven't seen it on the list and it's not in the archive. -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Tuesday, October 11, 2005 8:54 AM To: 'isms@ietf.org' Subject: Open issues from SSHSM Hi, I have converted a number of [todo] markers to [discuss] markers in the latest revisions of SSHSM, because we need to reach consensus on some issues. I expect to publish another revision before the deadline. I numbered the markers in the text for easy correlation to the issue discussions. *** When discussing these issues, please use the provided # in the subject line, and please limit the message to one topic at a time. *** Here is the current list of issues from the SSHSM document where we need to reach consensus. #1: is it important to support anonymous user access to SNMP? #2: a) is server authentication a requirement that SNMP will require of the client? b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? #3: we need some text contributed to discuss the implications of sessions on SNMP. #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic) #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? #7: is there still a need for an "authoritative SNMP engine"? #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent? #9: Can an existing R/R session be reused for notifications? #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero-length OCTET STRING, or should it be an ASN.1 NULL? #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? B) There were discussions about whether it was acceptable for a transport-mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided? #13: will SSHSM be impacted by keychanges to the SSH local datastore? #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages? #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? #16: The SSH server doesn't necessarily authorize the name carried in the SSH_MSG_USERAUTH_REQUEST message, but may return a different name or list of names that are authorized to be used given the authentication of the provided username. A) What should be the source of the SSHSM mechanism-specific username for mapping to securityname? B) passing a securityname might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS,etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide securityname when establishing a session, so the authentication machanisms can use it as a hint? #17: I believe somebody suggested we require mutual authentication. I'm not sure I understand the edits. #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each, and determine whether we can collapse this into one section. a) Using Passwords to Authenticate SNMP Principals B) Using Public keys to Authenticate SNMP Principals C) Using Host-based Authentication of SNMP Principals D) Using RADIUS to Authenticate SNMP Principals #19: RADIUS is just an instance of the password authentication protocol. The details of RADIUS are within the SSH layer. I don't think it is a good idea to expose this outside of SSH. #20: How do we get the mapping from model-specific identity to a model independent securityName?. #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means #24: How should we enable auto-discovery? #25: Where is the best place to call establishSession()? See the "Sending an Outgoing Message to the Network" section for more details on this issue. #26: According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). #27: The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Do we need to discuss these issues? Where? in the security considerations? #28: For notification tables, how do we predefine the dynamic session identifiers? #29: do we need to support reports? For what purpose? #30: If we actually do not extract anything from securityParameters, do we need to check whether this field parses correctly? #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? #32: For an incoming message, is using a default securityName mapping the right thing to do? #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 10:35:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4B8-0000V2-Hw; Thu, 13 Oct 2005 10:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4B7-0000Ux-Iy for isms@megatron.ietf.org; Thu, 13 Oct 2005 10:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21437 for ; Thu, 13 Oct 2005 10:35:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4Ld-0005UG-7z for isms@ietf.org; Thu, 13 Oct 2005 10:46:22 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 13 Oct 2005 07:35:19 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9DEZGJh012470; Thu, 13 Oct 2005 07:35:17 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp419.cisco.com [10.61.65.163]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9DEk28o029391; Thu, 13 Oct 2005 07:46:03 -0700 Message-ID: <434E70A1.4090408@cisco.com> Date: Thu, 13 Oct 2005 16:35:13 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: dbharrington@comcast.net Subject: Re: [Isms] FW: Open issues from SSHSM References: <200510121757.NAA08056@ietf.org> In-Reply-To: <200510121757.NAA08056@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=8106; t=1129214764; x=1129646964; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20FW=3A=20Open=20issues=20from=20SSHSM| From:Eliot=20Lear=20| Date:Thu,=2013=20Oct=202005=2016=3A35=3A13=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=p5m2bPG8/pjcfAkqsSWN8uXNVrt3QgfixtDWbD5xi/9DFjKoS+48VGLDb022WON6LRqXdD8x iD2blpGAJrexGs5gzeJNnGeWb8cHtVJkAU+ffv2cn+IePeTRw6VdggqUTUPr+7w4ZRG157q2uUq O9qhZbOQygTnn2Ah4jJnbcJk= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave, Here are my answers to some of your questions. YMMV. > #1: is it important to support anonymous user access to SNMP? Are you referring to unauthenticated or anonymous? > > #2: a) is server authentication a requirement that SNMP will require > of the client? I'm not sure what you mean here, but if you mean that the client should verify the server identity as part of SSH session initiation, absolutely. Consider Wes' simple implementation. The SNMP subsystem doesn't even get invoked until long after this happens. > b) how can we verify that server authentication was performed, > or do we take simply trust the SSH client layer to perform such > authentication? You trust the underlying layer to do its job. > c) for the common case of DH signed by public keys, how does > the client learn the host's public key in advance, and verify that the > correct key is being used? I don't see how this happens other than out of band, but perhaps I don't understand the available public ASIs well enough. > > #3: we need some text contributed to discuss the implications of > sessions on SNMP. Happy to help. Let's grab some time at IETF after the WG, tho, so it follows from discussion of these points. > > #4: Should the SSHSM document include a discussion of the operational > expectations of this model for use in troubleshooting a broken > network, or can this be covered in the TMSM document? (Either way, we > could use some contributed text on the topic) > > #5: Should the SSHSM document include a discussion of ways SNMP could > be extended to better support management/monitoring needs when a > network is running just fine, or can this be covered in the TMSM > document, or in an applicability document? > > #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? Potentially. See below. > > #7: is there still a need for an "authoritative SNMP engine"? It is not clear to me why you would need this given that SSH is responsible for security. > > #8: Do we need a mapping between the SSH key (or other SSH engine > identifier) and SNMP engineID? What happens if an agent "spoofs" > another engineID, and an NMS perfoms a SET of sensitive parameters to > the agent? In other words, the IP address to engine id mapping is broken or there is some man in the middle attack. The spoofing agent is not likely to get this far via SSHSM because the underlying layer will have blown up due to failure to match the DH key. If the attacker had access to the manager via other means, then perhaps the mapping could be considered broken. But what would those other means be? Perhaps a broken USM key with DES56? In this case, perhaps there is a potential negative interaction between USM and SSHSM? > > #9: Can an existing R/R session be reused for notifications? For obvious reasons I think this is a great idea (and visa versa - an existing notification session should be used for R/R). Once a connection is established so long as authorization requirements are met the connection should be reused. This will limit if not completely prevent the problem I described regarding traversing a firewall for one use but not being able to get back for the other. > > #10: a) which securityparameters must be supported for the SSHSM > model? > b) Which services provided in USM are needed in TMSM/SSHSM? > C) How does the Message Processing model provide this information to > the security model via generateRequestMsg() and processIncomingMsg() > primitives? > > #11: If we eliminate all msgSecurityParameters, should the > msgSecurityParameters field in the SNMPv3 message simply be a > zero-length OCTET STRING, or should it be an ASN.1 NULL? > > #12: a) how does SSHSM determine whether SSH can provide the security > services requested in msgFlags? > B) There were discussions about whether it was acceptable for a > transport-mapping-model to provide stronger security than requested. > Does this need to be discussed in the SSHSM document, or should we > discuss this in the TMSM document? > c) when sending a message into an environment where encryption > is not legal, how do we ensure that encryption is not provided? > > #13: will SSHSM be impacted by keychanges to the SSH local datastore? I presume you mean "How will SSHSM...". Of course the next session started should make use of the key change as appropriate. There's always the question of what to do with an existing session. > > > #14: MUST the SSHSM model provide mutual authentication of the client > and server, and MUST it authenticate, integrity-check, and encrypt the > messages? It should be capable of doing so. Your question is should it be capable of not doing so? There is always v2c, you know... > > #15: What data needs to be stored in the tmStateReference, and how > does SSHSM get the information from SSH, for the various > authentication and transport options? > > #16: The SSH server doesn't necessarily authorize the name carried in > the SSH_MSG_USERAUTH_REQUEST message, but may return a different name > or list of names that are authorized to be used given the > authentication of the provided username. > A) What should be the source of the SSHSM mechanism-specific username > for mapping to securityname? > B) passing a securityname might be useful for passing as a hint to > RADIUS or other authorization mechanism to indicate which identity we > want to use when doing access control, and RADIUS,etc. can tell us > whether the username being authenticated is allowed to be mapped to > that authorization/accounting identity. Should we provide securityname > when establishing a session, so the authentication machanisms can use > it as a hint? > > #17: I believe somebody suggested we require mutual authentication. > I'm not sure I understand the edits. You should get that by default with SSH, and would have to work hard to not get it. > > #18: I currently have multiple sections, one for each known auth > mechanism. We need to discuss the parameters that need to be cached > for each, and determine whether we can collapse this into one section. > a) Using Passwords to Authenticate SNMP Principals > B) Using Public keys to Authenticate SNMP Principals > C) Using Host-based Authentication of SNMP Principals > D) Using RADIUS to Authenticate SNMP Principals > > #19: RADIUS is just an instance of the password authentication > protocol. The details of RADIUS are within the SSH layer. I don't > think it is a good idea to expose this outside of SSH. I agree. We would like to be able to support other forms of password verification. Perhaps the real test is whether Kerberos authentication works. > > #20: How do we get the mapping from model-specific identity to a model > independent securityName?. How about a table in a MIB? Seriously, it would help should we choose to do call home later. > > #21: we need to determine what data should be persistent and stored in > the LCD for notification purposes. > > #22: Joe: There are a significant number of > security problems associated with mapping to a transport address which > may need to be discussed in the security considerations section. > > #23: We need to discuss the circumstances under which a session should > be closed, and how an SNMP engine should determine if, and respond if > the SSH session is closed by other means Ok, I have two answers to this. Take your pick. Answer one: - the device that initiated the connection should initiate the close. It presumably knew why it initiated the connection and will know when it is done. - let it be a matter of configurable policy. In some environments a long lived connection may be advisable while in other environments a short lived one so. > > #24: How should we enable auto-discovery? > > #25: Where is the best place to call establishSession()? See the > "Sending an Outgoing Message to the Network" section for more details > on this issue. You need some separation of establishSession() from individual requests. For one, if a connection has failed you want to retry no more than some period+e lest you DDOS the other end. > > #26: According to RFC 3411, section 4.1.1, the application provides > the > transportDomain and transportAddress to the PDU dispatcher via the > sendPDU() primitive. If we permit multiple sessions per > transportAddress, then we would need to define how session identifiers > get passed from the application to the PDU dispatcher (and then to the > MP model). > > #27: The SNMP over TCP Transport Mapping document [RFC3430] says that > TCP connections can be recreated dynamically or kept for future use > and actually leaves all that to the transport mapping. Do we need to > discuss these issues? Where? in the security considerations? Somewhere along the way it has to be made clear who can (re)use a connection. RFC 3430 didn't have this problem because individual PDUs were authenticated and authorized. Perhaps this is some of the session wording you request above? > > #28: For notification tables, how do we predefine the dynamic session > identifiers? > > #29: do we need to support reports? For what purpose? > > #30: If we actually do not extract anything from securityParameters, > do we need to check whether this field parses correctly? > > #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once > for the session? Do we need to take into consideration the SSH window > size? > > #32: For an incoming message, is using a default securityName mapping > the right thing to do? If by this you mean that ssh username = securityName by default, seems like a reasonable plan. But see above. > #33: does the mib need to be writable, so sessions can be > preconfigured, such as for callhome, or would it be populated at > creation time by the underlying instrumentation, and not writable by > SNMP? Can't say just yet until we answer some of the above questions in more detail. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 13:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ76y-0006It-8D; Thu, 13 Oct 2005 13:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPlfL-0001Um-6G; Wed, 12 Oct 2005 14:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10599; Wed, 12 Oct 2005 14:49:24 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPlpf-0003Ws-Tl; Wed, 12 Oct 2005 15:00:10 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2005 11:49:17 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="13052015:sNHT22792716" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9CImXFM028776; Wed, 12 Oct 2005 14:49:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:49:12 -0400 Received: from [161.44.65.232] ([161.44.65.232]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:49:11 -0400 Message-ID: <434D5AA7.40702@cisco.com> Date: Wed, 12 Oct 2005 14:49:11 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear References: <434CC589.2020608@cisco.com> In-Reply-To: <434CC589.2020608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2005 18:49:11.0817 (UTC) FILETIME=[A2AE5790:01C5CF5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Oct 2005 13:43:23 -0400 Cc: "ops- nm"@ops.ietf.org, call-home@ietf.org, isms@ietf.org Subject: [Isms] Re: [Call-home] last call for a Call Home BoF 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm interested in this BoF, and think this is an important topic. Josh Littlefield Eliot Lear wrote: > After all of the mail last month, Bert is considering allowing a BoF on > the topic of Call Home. I initially posted a note to the call-home > mailing list announcing the possibility of a BoF. Response to that note > was - well - underwhelming. If you are interested in seeing one, could > you please reply to this email, CCing the call-home mailing list. Here > is a draft agenda. It is subject to your input. > > If we do not see much input, I'm going to drop the request to Bert. > > Eliot > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 13:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ76y-0006JI-FP; Thu, 13 Oct 2005 13:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5ZO-0000tw-Fj for isms@megatron.ietf.org; Thu, 13 Oct 2005 12:04:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25862 for ; Thu, 13 Oct 2005 12:04:34 -0400 (EDT) Received: from mail.networksolutionsemail.com ([205.178.146.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ5jv-0007pj-AJ for isms@ietf.org; Thu, 13 Oct 2005 12:15:32 -0400 Received: (qmail 30685 invoked by uid 78); 13 Oct 2005 16:00:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail.networksolutionsemail.com with SMTP; 13 Oct 2005 16:00:50 -0000 Message-ID: <434E8474.7080409@andybierman.com> Date: Thu, 13 Oct 2005 08:59:48 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear References: <434CC589.2020608@cisco.com> In-Reply-To: <434CC589.2020608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Oct 2005 13:43:22 -0400 Cc: call-home@ietf.org, ops-nm@ops.ietf.org, isms@ietf.org Subject: [Isms] Re: last call for a Call Home BoF 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot Lear wrote: > After all of the mail last month, Bert is considering allowing a BoF > on the topic of Call Home. I initially posted a note to the call-home > mailing list announcing the possibility of a BoF. Response to that > note was - well - underwhelming. If you are interested in seeing one, > could you please reply to this email, CCing the call-home mailing > list. Here is a draft agenda. It is subject to your input. > > If we do not see much input, I'm going to drop the request to Bert. IMO there is a disconnect between the BoF charter text below and the email discussions I (mostly) followed in the last month. I am in favor of sharply defined work that will achieve integration between NETCONF and ISMS through foresight and planning. I'm not so keen about the open-ended charter text below. [IMO, this feature is simply defined as "the NETCONF peer acting in the agent role initiates the session establishment". There may be additional ISMS requirements, but I don't know.] I suspected (back at the first NETCONF interim in Sunnyvale) that our decision to provide this "reverse connect" feature for BEEP only would come back to bite us -- then even more when we picked SSH as the mandatory transport. I think this functionality is important enough to be available via the mandatory transport. (IMO the work can be done as an extension to the 1.0 specification set.) Beyond the firewall/NAT issues, I think there are some important use cases for this feature, especially when notification generator applications are introduced in NETCONF. Issues such as mobility, scale, and auto-configuration may make applications a lot easier to design if the agent connects to the manager. > > Eliot Andy > > Title: callhome > Period of time: 1 hour > Area: ops-nm > Expected # attendees: 40-60 (small room) > Don't conflict with: ISMS, ops-area, netconf (if there is one) > > > Short Description: Discussion of Architectural Issues Concerning > protocols that could benefit from reversing > of roles > > Long Description: > > Certain protocols, and in particular management protocols where > devices on either end of connection take client server roles may > be able to take advantage of "Call Home" functionality, when > traditional roles are reversed, and a server connect to a client. > Examples of existing protocols that make use of call home include > SMTP [ETRN] and COPS. At this BoF we will look at extending such > functionality into other protocols, as well as any architectural > issues this raises. > > This work stems from efforts in ISMS to extend SNMP to run over SSH, > as well as work as work that has gone on in NETCONF. > > We will begin with a discussion of > draft-lear-callhome-description-0[1,2].txt, which contains a > description of call home, what problems it can solve, and what some of > the architectural issues are. During the BoF we may identify > additional such issues as well as protocols other than management > protocols that could benefit from this work. An additional potential > question should be whether a generic standard or process should be > used to implement call home, such as rules for SSH. > > There are three possible outcomes: a working group to add "call home" > functionality to existing protocols such as SNMP/SSH and NETCONF/SSH, > use of existing working groups for this purpose, or nothing. > > Chair: Eliot Lear (or tbd) > Agenda: > > Agenda bashing - 1 minute > Presentation of draft-lear-callhome-description-00.txt 19 minutes > Application to SNMP and open areas - 10 minutes > Discussion including architectural issues - 20 minutes > Moving Forward Options - 10 minutes > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 14:00:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7NR-0003j4-PP; Thu, 13 Oct 2005 14:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7NQ-0003ie-8n for isms@megatron.ietf.org; Thu, 13 Oct 2005 14:00:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02514 for ; Thu, 13 Oct 2005 14:00:19 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7Xy-0002c4-H9 for isms@ietf.org; Thu, 13 Oct 2005 14:11:19 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2005 11:00:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9DHxHvF025554; Thu, 13 Oct 2005 11:00:12 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 11:00:10 -0700 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] FW: Open issues from SSHSM Date: Thu, 13 Oct 2005 11:00:09 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B995EF@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] FW: Open issues from SSHSM Thread-Index: AcXOF2hESl6N7OemSIWU3zd++VjKPQBPuzNwADJeUjA= From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 13 Oct 2005 18:00:10.0122 (UTC) FILETIME=[F3B50EA0:01C5D01F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Please find reply inline (used tag ) Regards, kaushik! I have converted a number of [todo] markers to [discuss] markers in the latest revisions of SSHSM, because we need to reach consensus on some issues. I expect to publish another revision before the deadline. I numbered the markers in the text for easy correlation to the issue discussions. *** When discussing these issues, please use the provided # in the subject line, and please limit the message to one topic at a time. *** Here is the current list of issues from the SSHSM document where we need to reach consensus.=20 #1: is it important to support anonymous user access to SNMP? Is this support for backwards compatability with noAuthNoPriv. If we do deprecate the authoritative engine notion within SNMPv3, we should be able to get away from engine discovery for SSHSM which is the most prevelant use of noAuthNoPriv. I recommend that we do not support anonymous user access unless absolutely required. #2: a) is server authentication a requirement that SNMP will require of the client?=20 I think this is an artifact of a TMSM, I don't think we really have an option.=20 b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? We have to trust the SSH layer. Any TMSM not just SSHSM will need to trust the transport layer to perform server authentication and key negotiation. c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? I had mentioned this in my previous note, SSHSM does create the need to manually provision public keys on clients until we have X.509 support (or GSSAPI is being used). SSH client implementations in interactive mode will verify the key by echoing it to the user and saving the key once the user accepts. We cannot do that with SSHSM and we either require manual provisioning of server public keys or accept blindly the first time, which make it suscepitble to mitm. #3: we need some text contributed to discuss the implications of sessions on SNMP. What specifically are you looking at. I can certainly contribute text that talk about how existing USM based management systems will be impacted once we move a session based model. #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic) #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? I think #3, #4 & #5 could make a section that talks about impact of introducing session based security to SNMP, I think this should be in broader spec (may be applicatability document). #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? None that I can think especially with USM since SSHSM (or TMSM) will be a separate security model with independent credentials. #7: is there still a need for an "authoritative SNMP engine"?=20 Based on previous discussion on thread, we might consider dropping this. #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent?=20 I think we should think about using/mapping the identity of the SNMP engine to the SNMP engine ID, this will be particularly useful when you have multiple SNMP engines on the same host (single SSH server). The engine ID would be used for server identity, client like a NMS sending out a SET will be represented by a client identity and need to authenticate via client credentials such as passwords, user public keys etc. #9: Can an existing R/R session be reused for notifications? I certainly hope we consider the possibility since SSH does allow multiple channels to be created within a session. We do need to consider the following issue. In the case of a R/R channel, the client is a NMS user that authenticates to the SSH server on the agent, the server authenticates via it's public key. The agent (SNMP engine) will authorize the requests based on that user. In case of notifications, we will need the agent (notification originator) to authenticate the NMS host identity via it's public key and provide client identity (configured username)and credentials to authenticate itself to the NMS (Notification reciever). The principals that are authenticated in either direction are not symmetric and we might need to consider whether they can be mapped to allow a channel for NMS to agent to be reused for agent to NMS. #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero-length OCTET STRING, or should it be an ASN.1 NULL? #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? B) There were discussions about whether it was acceptable for a transport-mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided?=20 I think this is a TMSM issue, we need to talk about how to ensure that the underlying transport is providing the level of security requested by the SNMP engine.=20 #13: will SSHSM be impacted by keychanges to the SSH local datastore? #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages?=20 Not sure about this question, since mutual authentication is part of the SSH specification (server authentication part of the SSH transport and client authentication part of the SSH authentication. #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? #16: The SSH server doesn't necessarily authorize the name carried in the SSH_MSG_USERAUTH_REQUEST message, but may return a different name or list of names that are authorized to be used given the authentication of the provided username.=20 A) What should be the source of the SSHSM mechanism-specific username for mapping to securityname? I think the mapping (if any) of the username authenticated by SSH to a SNMP securityName MUST be within the SNMP subsystem. It is not anything we need SSH or the authentication systems to deal with.=20 B) passing a securityname might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS,etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide securityname when establishing a session, so the authentication machanisms can use it as a hint? This will constitute SNMP specific behavior within RADIUS and other authentication/authorization systems. #17: I believe somebody suggested we require mutual authentication. I'm not sure I understand the edits.=20 #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each, and determine whether we can collapse this into one section. a) Using Passwords to Authenticate SNMP Principals B) Using Public keys to Authenticate SNMP Principals C) Using Host-based Authentication of SNMP Principals D) Using RADIUS to Authenticate SNMP Principals #19: RADIUS is just an instance of the password authentication protocol. The details of RADIUS are within the SSH layer. I don't think it is a good idea to expose this outside of SSH. #20: How do we get the mapping from model-specific identity to a model independent securityName?.=20 Isn't this a variant of #16.=20 #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. Shouldn't we be able to use the same notification data in LCD from USM. This would primarily be the configured user and credentials for the notification originator #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means #24: How should we enable auto-discovery? #25: Where is the best place to call establishSession()? See the "Sending an Outgoing Message to the Network" section for more details on this issue. #26: According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model).=20 #27: The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Do we need to discuss these issues? Where? in the security considerations? #28: For notification tables, how do we predefine the dynamic session identifiers?=20 #29: do we need to support reports? For what purpose? #30: If we actually do not extract anything from securityParameters, do we need to check whether this field parses correctly? #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? #32: For an incoming message, is using a default securityName mapping the right thing to do? Isn't this a variant of #16.=20 #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 16:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9un-0001If-1R; Thu, 13 Oct 2005 16:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9um-0001Ia-C7 for isms@megatron.ietf.org; Thu, 13 Oct 2005 16:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16211 for ; Thu, 13 Oct 2005 16:42:56 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQA5L-0000Rv-CL for isms@ietf.org; Thu, 13 Oct 2005 16:53:56 -0400 Received: from pc6 (1Cust48.tnt101.lnd4.gbr.da.uu.net [213.116.50.48]) by blaster.systems.pipex.net (Postfix) with SMTP id 2C6CCE0001F7; Thu, 13 Oct 2005 21:42:28 +0100 (BST) Message-ID: <067901c5d02e$2276a100$0601a8c0@pc6> From: "Tom Petch" To: References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> <018e01c5cb62$ed1902c0$0601a8c0@pc6> <20051007190159.GA907@boskop.local> Subject: Re: [Isms] authoritative Date: Thu, 13 Oct 2005 17:48:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen I think I just found another, in the Entity MIB, namely, "The authoritative contextEngineID that can be used to send an SNMP message concerning information held by this logical entity, to the address specified by the associated 'entLogicalTAddress/entLogicalTDomain' pair. Not sure how widespread a usage this is but it is not what I had in mind, which, from your typology, is key authoritative. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Petch" Cc: "Steve Waldbusser" ; Sent: Friday, October 07, 2005 9:01 PM Subject: Re: [Isms] authoritative > On Fri, Oct 07, 2005 at 07:16:19PM +0200, Tom Petch wrote: > > > I'm puzzled, on a number of counts, primarily on what authoritative means. > > I agree. For me, the context in which you use the work authoritative > is import to understand where we are. In a layered system, one can > talk about: > > a) Who is authoritative wrt. the information transported by a > protocol. Lets call this "information authoritative". > > b) Who is authoritative wrt. the keys used in a security protocol. > Lets call this "key authoritative". > > c) Who is authoritative wrt. the clocks used in a security protocol > Lets call this "clock authoritative". > > d) Who is authoritative wrt. to access control decisions. > Lets call this "access control authoritative". > > In the contact of SNMP, I think the notification originator is > "information authoritative" for Notification Class PDUs while the > command responder is "information authoritative" for Read Class > PDUs. One could argue that the command generator is "information > authoritative" for Write Class PDUs. > > Furthermore, it seems rather clear that USM defines clear roles for > the messages containing the various PDU types regarding who is "clock > authoritative". Obviously, this concept is USM specific since the > clock synchronization mechanism is USM specific. > > A bit less clear is probably the notion of "key authoritativeness". > In a classic symmetric key protocol, one could argue that both peers > share the same authoritativeness. USM, however, uses localized keys > and one therefore might argue that the authoritativeness is not shared > equally. Still, I consider the question of who is "key authoritative" > a security model specific issue. > > Regarding access control, it is rather clean in SNMP that the command > responder and the notification originater are "access control > authoritative". > > Perhaps this helps to organize the discussion. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:23:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAYK-0005SQ-Rp; Thu, 13 Oct 2005 17:23:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAYI-0005Rx-Ti for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:23:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18692 for ; Thu, 13 Oct 2005 17:23:47 -0400 (EDT) Message-Id: <200510132123.RAA18692@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAis-0001eR-IB for isms@ietf.org; Thu, 13 Oct 2005 17:34:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200510132123390140093sfne>; Thu, 13 Oct 2005 21:23:39 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:23:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQPFw6VtbELyJ8TlOQriZrOKtcmg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #1: is it important to support anonymous user access to SNMP? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange that is authenticated and even private when the session initiator or responder is anonymous." This is a new feature provided by SBSM. Can we establish consensus that a) this is needed or b) this is not needed? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:24:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAZ3-0005VT-4F; Thu, 13 Oct 2005 17:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAZ0-0005VI-Po for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:24:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18727 for ; Thu, 13 Oct 2005 17:24:31 -0400 (EDT) Received: from ia794.i.pppool.de ([85.73.167.148] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAja-0001fR-Dh for isms@ietf.org; Thu, 13 Oct 2005 17:35:31 -0400 Received: by boskop.local (Postfix, from userid 501) id C31D14C45AB; Thu, 13 Oct 2005 23:24:10 +0200 (CEST) Date: Thu, 13 Oct 2005 23:24:10 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] authoritative Message-ID: <20051013212410.GA3427@boskop.local> Mail-Followup-To: Tom Petch , Steve Waldbusser , isms@ietf.org References: <200510011725.NAA11175@ietf.org> <43449635.5050007@nextbeacon.com> <018e01c5cb62$ed1902c0$0601a8c0@pc6> <20051007190159.GA907@boskop.local> <067901c5d02e$2276a100$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <067901c5d02e$2276a100$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Thu, Oct 13, 2005 at 05:48:13PM +0200, Tom Petch wrote: > I think I just found another, in the Entity MIB, namely, > > "The authoritative contextEngineID that can be used to send > an SNMP message concerning information held by this logical > entity, to the address specified by the associated > 'entLogicalTAddress/entLogicalTDomain' pair. > > Not sure how widespread a usage this is but it is not what I had in > mind, which, from your typology, is key authoritative. This object belongs to the category "information authoritative" as it is used to identify the context on an "agent" (called a logical entity in the ENTITY-MIB terminology) which is authoritative regarding some information on the "agent". /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAij-0000Qj-1v; Thu, 13 Oct 2005 17:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAih-0000Qe-1l for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19200 for ; Thu, 13 Oct 2005 17:34:29 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAtA-0001tx-KN for isms@ietf.org; Thu, 13 Oct 2005 17:45:30 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9DLYOZC021533 for ; Thu, 13 Oct 2005 17:34:24 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 13 Oct 2005 17:34:25 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 13 Oct 2005 17:34:25 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Oct 2005 17:33:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #1: is it important to support anonymous user access to SNMP? Date: Thu, 13 Oct 2005 17:33:27 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EA@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #1: is it important to support anonymous user access to SNMP? Thread-Index: AcXQPFw6VtbELyJ8TlOQriZrOKtcmgAARFeQ From: "Nelson, David" To: X-OriginalArrivalTime: 13 Oct 2005 21:33:28.0321 (UTC) FILETIME=[C0073F10:01C5D03D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:21.2499 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave Harrington writes... > From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > that is authenticated and even private when the session initiator or > responder is anonymous." >=20 > This is a new feature provided by SBSM. Can we establish consensus > that a) this is needed or b) this is not needed? I may be particularly obtuse on this point, but I fail to see how a truly anonymous entity can ever be authenticated. Private, yes. But authenticated? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:44:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAsC-0003Fz-HA; Thu, 13 Oct 2005 17:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAsB-0003Fr-An for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19618 for ; Thu, 13 Oct 2005 17:44:19 -0400 (EDT) Message-Id: <200510132144.RAA19618@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB2l-00028A-5b for isms@ietf.org; Thu, 13 Oct 2005 17:55:20 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101321441001300js2eee>; Thu, 13 Oct 2005 21:44:10 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:44:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQPzrH1AAxQprySPqC3zIieLdTZA== X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Open issues for SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I find the members of this WG not very good at taking direction. ;-) I'm trying to understand what would work better than the method I used: *** When discussing these issues, please use the provided # in the subject line, and please limit the message to one topic at a time. *** Would five stars be more effective? ;-) Seriously, I made that request for a reason - I want to track the issues. It is much easier if a particular topic is discussed using a consistent subject line. When all the responses are put into the one message, it becomes very difficult to follow a thread regarding a particular topic. Juergen S and I are discussing how we might be able to automate thread tracking of the issues (of course, the archives already provide that if people use the right subject lines). So let me try again, ***** Please, use the provided # in the subject line, and please limit the message to one topic at a time. ***** (Darn, now I won't be able to tell if it was the five stars that worked) Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:46:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAuK-0003Z1-0U; Thu, 13 Oct 2005 17:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAuI-0003Yp-CT for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:46:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19711 for ; Thu, 13 Oct 2005 17:46:30 -0400 (EDT) Message-Id: <200510132146.RAA19711@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB4s-0002Aq-8d for isms@ietf.org; Thu, 13 Oct 2005 17:57:31 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200510132146210140093snce>; Thu, 13 Oct 2005 21:46:21 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:46:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP4i43PTPse8URdmOLogjswlQGw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #2: is server authentication a requirement that SNMP will require X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #2: a) is server authentication a requirement that SNMP will require of the client? b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:47:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAuz-0003aX-7O; Thu, 13 Oct 2005 17:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAuy-0003aS-03 for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:47:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19727 for ; Thu, 13 Oct 2005 17:47:12 -0400 (EDT) Message-Id: <200510132147.RAA19727@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB5X-0002BU-UC for isms@ietf.org; Thu, 13 Oct 2005 17:58:13 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101321470401400l8sb2e>; Thu, 13 Oct 2005 21:47:05 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:46:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP6NL4w9mnbhtTmyxuexnslWbmQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #3: we need some text contributed to discuss the implications of sessions on SNMP. X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:48:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAvt-0003ha-Fc; Thu, 13 Oct 2005 17:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAvr-0003hV-Fn for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19747 for ; Thu, 13 Oct 2005 17:48:07 -0400 (EDT) Message-Id: <200510132148.RAA19747@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB6R-0002C4-FM for isms@ietf.org; Thu, 13 Oct 2005 17:59:08 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321480001500b87vve>; Thu, 13 Oct 2005 21:48:00 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:47:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP8QHX3/LNeRFQa2TbnC/m8y6zA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #4: Should SSHSM discuss operational expectation? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic) David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:49:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAx7-0003se-PB; Thu, 13 Oct 2005 17:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAx5-0003sZ-Gc for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19779 for ; Thu, 13 Oct 2005 17:49:23 -0400 (EDT) Message-Id: <200510132149.RAA19779@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB7f-0002DU-Eg for isms@ietf.org; Thu, 13 Oct 2005 18:00:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101321491601400910g6e>; Thu, 13 Oct 2005 21:49:16 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:49:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP/EgV4O0bhY7QDidbWW9ktYnfw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #5: Should discuss management/monitoring needs in non-broken networks? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:49:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAxT-0003u6-0S; Thu, 13 Oct 2005 17:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAxR-0003u1-Px for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:49:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19807 for ; Thu, 13 Oct 2005 17:49:45 -0400 (EDT) Message-Id: <200510132149.RAA19807@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB81-0002Du-Q7 for isms@ietf.org; Thu, 13 Oct 2005 18:00:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101321493901400926oge>; Thu, 13 Oct 2005 21:49:39 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:49:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP/7INe8ZPM9ORqi+7bfUQnHgIg== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:50:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAxm-00042p-79; Thu, 13 Oct 2005 17:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAxk-00041h-Vr for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19823 for ; Thu, 13 Oct 2005 17:50:05 -0400 (EDT) Message-Id: <200510132150.RAA19823@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB8K-0002EW-U6 for isms@ietf.org; Thu, 13 Oct 2005 18:01:06 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321495801500b5q8ge>; Thu, 13 Oct 2005 21:49:58 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:49:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQApnWBTzE0RaSzeOV9+cOwIC8A== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #7: is there still a need for an "authoritative SNMP engine"? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:51:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAya-0005FT-8u; Thu, 13 Oct 2005 17:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAyY-00059M-E6 for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:50:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19867 for ; Thu, 13 Oct 2005 17:50:54 -0400 (EDT) Message-Id: <200510132150.RAA19867@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB98-0002Fq-E3 for isms@ietf.org; Thu, 13 Oct 2005 18:01:55 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101321504601300joqvee>; Thu, 13 Oct 2005 21:50:46 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:50:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQCcWe5m8R8aCT3iYNBmJBi8SqA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #8: Do we need a mapping between the SSH key and SNMP engineID? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:52:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAzz-0005Zd-JF; Thu, 13 Oct 2005 17:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAzy-0005ZY-Sy for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19967 for ; Thu, 13 Oct 2005 17:52:22 -0400 (EDT) Message-Id: <200510132152.RAA19967@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBAY-0002It-RH for isms@ietf.org; Thu, 13 Oct 2005 18:03:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101321513301400993hhe>; Thu, 13 Oct 2005 21:51:33 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:51:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQELmXTQ9nG2BSqaP5HT+e22cqg== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #9: Can an existing R/R session be reused for notifications? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:52:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB0D-0005aD-Pa; Thu, 13 Oct 2005 17:52:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB0C-0005a8-BN for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:52:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19970 for ; Thu, 13 Oct 2005 17:52:36 -0400 (EDT) Message-Id: <200510132152.RAA19970@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBAl-0002J6-7z for isms@ietf.org; Thu, 13 Oct 2005 18:03:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101321522601400l7f5ee>; Thu, 13 Oct 2005 21:52:26 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:52:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQGMzJKrvP0DUQaeSWh3YH8QXSg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #10: a) which securityparameters must be supported for SSHSM? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:53:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB15-0005dd-30; Thu, 13 Oct 2005 17:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB13-0005dY-PI for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:53:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20006 for ; Thu, 13 Oct 2005 17:53:29 -0400 (EDT) Message-Id: <200510132153.RAA20006@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBBd-0002K3-QV for isms@ietf.org; Thu, 13 Oct 2005 18:04:31 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321532301500b7t9le>; Thu, 13 Oct 2005 21:53:23 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:53:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQIT6J7Xf2todQdK9kNk9c1jE/A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #11: zero-length OCTET STRING, or ASN.1 NULL for msgSecurityParameters? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero-length OCTET STRING, or should it be an ASN.1 NULL? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:54:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB1y-0005kb-8b; Thu, 13 Oct 2005 17:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB1x-0005kW-1v for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20067 for ; Thu, 13 Oct 2005 17:54:25 -0400 (EDT) Message-Id: <200510132154.RAA20067@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBCY-0002M0-1v for isms@ietf.org; Thu, 13 Oct 2005 18:05:26 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101321541901400l880qe>; Thu, 13 Oct 2005 21:54:19 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:54:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQKWnRzz6CvaoRVe1uIjUMwReAw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #12: msgflags X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? B) There were discussions about whether it was acceptable for a transport-mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:54:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2K-0005m4-Eu; Thu, 13 Oct 2005 17:54:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2J-0005lz-Cu for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:54:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20090 for ; Thu, 13 Oct 2005 17:54:47 -0400 (EDT) Message-Id: <200510132154.RAA20090@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBCt-0002Md-8s for isms@ietf.org; Thu, 13 Oct 2005 18:05:48 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321544001500b4neoe>; Thu, 13 Oct 2005 21:54:40 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:54:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQLHQRrYV4lNMQkmPrI5Rit7BbA== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #13: will SSHSM be impacted by keychanges to the SSH local datastore? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:55:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2v-0005ui-2A; Thu, 13 Oct 2005 17:55:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2t-0005to-JD for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:55:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20129 for ; Thu, 13 Oct 2005 17:55:23 -0400 (EDT) Message-Id: <200510132155.RAA20129@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBDU-0002NY-Kc for isms@ietf.org; Thu, 13 Oct 2005 18:06:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200510132155170140095g4he>; Thu, 13 Oct 2005 21:55:18 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:55:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQMggVY10vjK8SQeV4UKOg+0ZTw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #14: MUST the SSHSM model provide mutual authentication, etc.? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:56:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB4E-00069n-FZ; Thu, 13 Oct 2005 17:56:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB4D-00069a-79 for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:56:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20185 for ; Thu, 13 Oct 2005 17:56:45 -0400 (EDT) Message-Id: <200510132156.RAA20185@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBEo-0002Pg-9o for isms@ietf.org; Thu, 13 Oct 2005 18:07:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101321563801400933ese>; Thu, 13 Oct 2005 21:56:39 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:56:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQPmB+lgfXkrpRLan4Oblex1xHA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #15: how does SSHSM get the information from SSH for tmStateReference? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:57:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB4p-0006Fa-M6; Thu, 13 Oct 2005 17:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB4n-0006FI-Sc for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:57:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20243 for ; Thu, 13 Oct 2005 17:57:21 -0400 (EDT) Message-Id: <200510132157.RAA20243@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBFN-0002Rl-SC for isms@ietf.org; Thu, 13 Oct 2005 18:08:23 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101321571501400l4tu9e>; Thu, 13 Oct 2005 21:57:15 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:57:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQQ7yF5wyQuOGRcqMMlyr4LWAZw== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #16: What should be the source of the SSHSM mechanism-specific username? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB5k-0006MX-00; Thu, 13 Oct 2005 17:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB5i-0006MS-KX for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20283 for ; Thu, 13 Oct 2005 17:58:18 -0400 (EDT) Message-Id: <200510132158.RAA20283@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBGI-0002TC-M0 for isms@ietf.org; Thu, 13 Oct 2005 18:09:19 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321581101500bcjire>; Thu, 13 Oct 2005 21:58:11 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:58:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQTEdwnYLfqgJQMS7uelRXtUHyg== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #17: Do we agree on what "mutual authentication" means? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB6b-0006ff-6j; Thu, 13 Oct 2005 17:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB6Z-0006fJ-Sd for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:59:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20344 for ; Thu, 13 Oct 2005 17:59:11 -0400 (EDT) Message-Id: <200510132159.RAA20344@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBH9-0002V3-QH for isms@ietf.org; Thu, 13 Oct 2005 18:10:13 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101321590401300jmt01e>; Thu, 13 Oct 2005 21:59:04 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:58:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQVB4B/Ny9ljXRrmQEpzlej3vpw== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #18: what parameters need to be cached for each auth mechanism? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 17:59:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB7A-0006tm-Sx; Thu, 13 Oct 2005 17:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB79-0006sn-A6 for isms@megatron.ietf.org; Thu, 13 Oct 2005 17:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20390 for ; Thu, 13 Oct 2005 17:59:47 -0400 (EDT) Message-Id: <200510132159.RAA20390@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBHi-0002WB-Tv for isms@ietf.org; Thu, 13 Oct 2005 18:10:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101321594001500bbicce>; Thu, 13 Oct 2005 21:59:40 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 17:59:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQ== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #19: should RADIUS be exposed outside of SSH? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:01:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB8I-0008V8-M7; Thu, 13 Oct 2005 18:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB8G-0008Ug-NO for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20479 for ; Thu, 13 Oct 2005 18:00:56 -0400 (EDT) Message-Id: <200510132200.SAA20479@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBIq-0002ZB-Om for isms@ietf.org; Thu, 13 Oct 2005 18:11:58 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322004801500b4g48e>; Thu, 13 Oct 2005 22:00:48 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:00:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQY0OOdK2YeGmTMSB1Erg9H8Pwg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #20 the source of the mapping of username to securityName X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #20: How do we get the mapping from model-specific identity to a model independent securityName?. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:01:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB99-0000Gu-T7; Thu, 13 Oct 2005 18:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB98-0000Fv-IE for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:01:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20527 for ; Thu, 13 Oct 2005 18:01:50 -0400 (EDT) Message-Id: <200510132201.SAA20527@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBJj-0002aU-Kl for isms@ietf.org; Thu, 13 Oct 2005 18:12:51 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101322014201400ld1rfe>; Thu, 13 Oct 2005 22:01:42 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:01:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQa2ZIIboze6TSB2l2QFQOBFULQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #21: persistent configuration for notifications X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:02:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB9t-0000e1-OJ; Thu, 13 Oct 2005 18:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB9r-0000ds-VL for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20547 for ; Thu, 13 Oct 2005 18:02:35 -0400 (EDT) Message-Id: <200510132202.SAA20547@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBKS-0002b6-34 for isms@ietf.org; Thu, 13 Oct 2005 18:13:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101322022901300jq7rje>; Thu, 13 Oct 2005 22:02:29 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:02:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQcpsA/wcBOCgTeCKfYH/WAsliQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #22: security problems of mapping to a transport address X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBAJ-0000l2-V9; Thu, 13 Oct 2005 18:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBAJ-0000kx-4W for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:03:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20567 for ; Thu, 13 Oct 2005 18:03:03 -0400 (EDT) Message-Id: <200510132203.SAA20567@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBKu-0002bU-62 for isms@ietf.org; Thu, 13 Oct 2005 18:14:04 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101322025701300jnom0e>; Thu, 13 Oct 2005 22:02:57 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:02:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQdsm7UcWqc+MTyCQCoSAlGUYlQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #23: closing sessions X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBAc-0000sx-4O; Thu, 13 Oct 2005 18:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBAb-0000ss-EH for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:03:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20585 for ; Thu, 13 Oct 2005 18:03:21 -0400 (EDT) Message-Id: <200510132203.SAA20585@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBLC-0002cH-Em for isms@ietf.org; Thu, 13 Oct 2005 18:14:22 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200510132203130140092gsve>; Thu, 13 Oct 2005 22:03:13 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:03:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQeSPLWA+z8VrR+uIhUQ9BH4wkA== X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #24: How should we enable auto-discovery? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:04:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBBP-0000xo-0q; Thu, 13 Oct 2005 18:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBBN-0000xj-F6 for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:04:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20645 for ; Thu, 13 Oct 2005 18:04:09 -0400 (EDT) Message-Id: <200510132204.SAA20645@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBLy-0002eN-Gh for isms@ietf.org; Thu, 13 Oct 2005 18:15:10 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322040301500b94ice>; Thu, 13 Oct 2005 22:04:03 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:03:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQgHp92KxOQeDSMWZF1YYvyhD2g== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #25: when to call establishSession() X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #25: Where is the best place to call establishSession()? See the "Sending an Outgoing Message to the Network" section for more details on this issue. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:05:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBCG-00012B-Ov; Thu, 13 Oct 2005 18:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBCG-000125-6y for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:05:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20703 for ; Thu, 13 Oct 2005 18:05:04 -0400 (EDT) Message-Id: <200510132205.SAA20703@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBMq-0002g3-9T for isms@ietf.org; Thu, 13 Oct 2005 18:16:05 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101322045701400971jhe>; Thu, 13 Oct 2005 22:04:57 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:04:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQiD1RwUQKMqPTB6GMiPEnmum/w== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #26: multiple sessions per transportAddress X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #26: According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:06:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBD6-000162-EI; Thu, 13 Oct 2005 18:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBD5-000158-5S for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20750 for ; Thu, 13 Oct 2005 18:05:55 -0400 (EDT) Message-Id: <200510132205.SAA20750@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBNb-0002hc-62 for isms@ietf.org; Thu, 13 Oct 2005 18:16:56 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322054401500b4u40e>; Thu, 13 Oct 2005 22:05:44 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:05:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQj2+RiZXt/kYRmO11MGyLzwReg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #27: dynamic recreation of connections X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #27: The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Do we need to discuss these issues? Where? in the security considerations? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:06:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBDe-00018i-5Z; Thu, 13 Oct 2005 18:06:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBDd-00018d-0e for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20778 for ; Thu, 13 Oct 2005 18:06:29 -0400 (EDT) Message-Id: <200510132206.SAA20778@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBOD-0002ie-2s for isms@ietf.org; Thu, 13 Oct 2005 18:17:30 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322062101500b8p2ne>; Thu, 13 Oct 2005 22:06:22 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:06:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQlTKGPjBlGbbR5a/fuRjccOITQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #28: dynamic sessions and notification configuration X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #28: For notification tables, how do we predefine the dynamic session identifiers? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:07:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBES-0001Cx-3s; Thu, 13 Oct 2005 18:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBER-0001Cl-1b for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:07:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20842 for ; Thu, 13 Oct 2005 18:07:18 -0400 (EDT) Message-Id: <200510132207.SAA20842@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBP1-0002kT-3Z for isms@ietf.org; Thu, 13 Oct 2005 18:18:20 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101322071101400l3dkne>; Thu, 13 Oct 2005 22:07:12 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:07:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQnMone882fDPR121r7RkfiA7cw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #29: do we need reports? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #29: do we need to support reports? For what purpose? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:08:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBFU-0001Rx-MD; Thu, 13 Oct 2005 18:08:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBFT-0001QV-Dg for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:08:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20931 for ; Thu, 13 Oct 2005 18:08:23 -0400 (EDT) Message-Id: <200510132208.SAA20931@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBQ3-0002my-JB for isms@ietf.org; Thu, 13 Oct 2005 18:19:24 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101322081601400l7du5e>; Thu, 13 Oct 2005 22:08:16 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:08:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQplhvD4NM6a0RYuy21hXwCw4tA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #30: do we need to check whether securityParameters parses correctly? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #30: If we actually do not extract anything from securityParameters, do we need to check whether this field parses correctly? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:09:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBGB-0001xr-1a; Thu, 13 Oct 2005 18:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBG9-0001v7-Ra for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21050 for ; Thu, 13 Oct 2005 18:09:05 -0400 (EDT) Message-Id: <200510132209.SAA21050@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBQk-0002ot-SV for isms@ietf.org; Thu, 13 Oct 2005 18:20:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005101322085901300jpdg4e>; Thu, 13 Oct 2005 22:09:00 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:08:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQrL3vD6D9EVrSHe99RZ6u38/iQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #31: Is maxSizeResponseScopedPDU relevant? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:10:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBHD-0002eW-2K; Thu, 13 Oct 2005 18:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBHB-0002bz-B7 for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21149 for ; Thu, 13 Oct 2005 18:10:09 -0400 (EDT) Message-Id: <200510132210.SAA21149@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBRl-0002s1-GG for isms@ietf.org; Thu, 13 Oct 2005 18:21:10 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322100201500bbeo1e>; Thu, 13 Oct 2005 22:10:02 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:09:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQtfX5kRv6D5fRzOccacm3NQ+RQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #32: is the securityName=username default OK? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #32: For an incoming message, is using a default securityName mapping the right thing to do? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:10:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBHZ-0002rG-IF; Thu, 13 Oct 2005 18:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBHY-0002qz-HQ for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21186 for ; Thu, 13 Oct 2005 18:10:32 -0400 (EDT) Message-Id: <200510132210.SAA21186@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBS8-0002sj-Ah for isms@ietf.org; Thu, 13 Oct 2005 18:21:33 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <200510132210240140091k2le>; Thu, 13 Oct 2005 22:10:24 +0000 From: "David B Harrington" To: Date: Thu, 13 Oct 2005 18:10:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQuVi4XLNqjIIR1am+KZS/LskyA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] #33: does the mib need to be writable? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBPQ-0005Ao-JI; Thu, 13 Oct 2005 18:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBPP-00058z-2a for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21656 for ; Thu, 13 Oct 2005 18:18:38 -0400 (EDT) Message-Id: <200510132218.SAA21656@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBZz-00036S-5R for isms@ietf.org; Thu, 13 Oct 2005 18:29:40 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322183201500b4uale>; Thu, 13 Oct 2005 22:18:32 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #20 the source of the mapping of username to securityName Date: Thu, 13 Oct 2005 18:18:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQY0OOdK2YeGmTMSB1Erg9H8PwgAAiOvQ In-Reply-To: <200510132200.SAA20479@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org To be clear about this point, it is about the ***mapping*** of the SSH-authenticated identity to securityName. If we require admins to preconfigure a MIB module with the mappings, we seem to have the same problem USM has. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:21:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBRe-00067i-Bw; Thu, 13 Oct 2005 18:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBRc-000639-7L for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:21:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21779 for ; Thu, 13 Oct 2005 18:20:56 -0400 (EDT) Message-Id: <200510132220.SAA21779@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBcD-0003BF-BP for isms@ietf.org; Thu, 13 Oct 2005 18:31:57 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <20051013222046014008vsboe>; Thu, 13 Oct 2005 22:20:48 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #16: What should be the source of the SSHSMmechanism-specific username? Date: Thu, 13 Oct 2005 18:20:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQQQ7yF5wyQuOGRcqMMlyr4LWAZwAAv1rw In-Reply-To: <200510132157.RAA20243@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org To be clear about point#16, this is about how to get the username (or other SSH authenticated identity from the SSH layer). Is this implementation-specific? If so, is the standard sufficently unambiguous to be secure and to permit interoperability? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 13 18:24:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBUW-0006t9-LO; Thu, 13 Oct 2005 18:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBUU-0006t4-LT for isms@megatron.ietf.org; Thu, 13 Oct 2005 18:23:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21940 for ; Thu, 13 Oct 2005 18:23:54 -0400 (EDT) Message-Id: <200510132223.SAA21940@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBf4-0003H3-VT for isms@ietf.org; Thu, 13 Oct 2005 18:34:56 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101322234701500baog2e>; Thu, 13 Oct 2005 22:23:47 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #3: we need some text contributed to discuss theimplications of sessions on SNMP. Date: Thu, 13 Oct 2005 18:23:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP6NL4w9mnbhtTmyxuexnslWbmQABMviw In-Reply-To: <200510132147.RAA19727@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org SNMP was originally designed with certain assumptions in mind. Some assumptions may no longer be valid if we use sessions. Which assumptions are no longer valid, and what new assumptions can be made in a session-based approach? Specifically requesting text discussing this. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 02:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJ2Z-0001Md-S9; Fri, 14 Oct 2005 02:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJ2Y-0001MV-CF for isms@megatron.ietf.org; Fri, 14 Oct 2005 02:27:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20340 for ; Fri, 14 Oct 2005 02:27:33 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJDD-0000r0-Hm for isms@ietf.org; Fri, 14 Oct 2005 02:38:39 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9E6RIBT014047; Thu, 13 Oct 2005 23:27:18 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9E6RBfU017786; Thu, 13 Oct 2005 23:27:11 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9E6RB2u017780; Thu, 13 Oct 2005 23:27:11 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 13 Oct 2005 23:27:11 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] #1: is it important to support anonymous user access to SNMP? In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EA@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, What anonymous user means is the following... 1) the identity of a command generator (an SNMP management app) is not verified (and is unknown) 2) the identity of the command responder (an SNMP agent) is authenticated 3) the integrity (and timeliness) of the SNMP messages is verified Optionally, the messages are encrypted. This capability allows "authentic management information" to be obtained from an anonymous identity. There are many real-world examples of this usage pattern. I believe that it is more important to be able to have encrypted and integrity checked messages instead of just integrity checked messages. This capability allows authentic message exchange with a "new identity" without any configuration of the SNMP agent's configuration. This is a VERY GOOD THING. In the other direction, what anonymous user means is the following... 1) the identity of a notification receiver is not verified 2) the identity of a notification generator (an agent) is authenticated 3) the integrity (and timeliness) of SNMP messages is verified. Optionally, the messages are encrypted. This capability allows "authentic management information" to be sent via a notification to an anonymous identity. I believe that this could be quite problematic to implement, and I can't think of any the real-world cases for this. Also, a new receiver requires an update of configuration of the SNMP agent to specify a transport address. On Thu, 13 Oct 2005, Nelson, David wrote: > Dave Harrington writes... > > > From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > > that is authenticated and even private when the session initiator or > > responder is anonymous." > > > > This is a new feature provided by SBSM. Can we establish consensus > > that a) this is needed or b) this is not needed? > > I may be particularly obtuse on this point, but I fail to see how a > truly anonymous entity can ever be authenticated. Private, yes. But > authenticated? > > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 06:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMxK-0004Np-CR; Fri, 14 Oct 2005 06:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMxJ-0004Ne-Hx; Fri, 14 Oct 2005 06:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01082; Fri, 14 Oct 2005 06:38:24 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQN80-0007Jt-Ma; Fri, 14 Oct 2005 06:49:33 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9EAcAkQ021266; Fri, 14 Oct 2005 05:38:11 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 12:38:09 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508490441@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andy Bierman , Eliot Lear Date: Fri, 14 Oct 2005 12:38:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: call-home@ietf.org, ops-nm@ops.ietf.org, isms@ietf.org Subject: [Isms] RE: [Call-home] Re: last call for a Call Home BoF 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Here is my AD-view on this: First the NM aspects: - The topic came up strong in the last ISMS f2f meeting in Paris. - I (as AD, but also as an individual contributor) worry/worried that we might make something (like call-home) a MUST for ISMS while it was not a MUST in NETCONF. I think we should be conistsent in our NM protocols and try to make sure that the same (security) infrastructure can be used for ISMS and NetConf (and others). - I also worry/worried about what impact it may have on SNMPv3 (hence the discussion on authoritative (engine, information etc). I am happy to see that that is being well discussed on ISMS list Then the IETF-wide aspects - I worry/worried that we might be doing a point-solution in the NM space, while it seems to me that the CH fiunctionality is an IETF wide issue. - So I at least want to get a much better understanding of what the IETF-wide or Architectural aspects/possibilities are. - Even if we decide to do a point-solution, then I still want to try and make sure that we do so based on a well-informed set of discussions including those from other areas. So that is what the BOF (in my view) needs to address. The result is (as yet) unknown. It may turn out that there are (reasonably) simple solutions at the IETF-wide level. If so, then we (NM folk) may want to help define/specify a generic solution that we can then also use in NM protocols. If we need to go down the road of a point-solution, then I would hope that we at least take into consideration all the things we learn during the BOF. Makes sense? Bert > -----Original Message----- > From: call-home-bounces@ietf.org [mailto:call-home-bounces@ietf.org]On > Behalf Of Andy Bierman > Sent: Thursday, October 13, 2005 18:00 > To: Eliot Lear > Cc: call-home@ietf.org; ops-nm@ops.ietf.org; isms@ietf.org > Subject: [Call-home] Re: last call for a Call Home BoF > > > Eliot Lear wrote: > > > After all of the mail last month, Bert is considering > allowing a BoF > > on the topic of Call Home. I initially posted a note to > the call-home > > mailing list announcing the possibility of a BoF. Response to that > > note was - well - underwhelming. If you are interested in > seeing one, > > could you please reply to this email, CCing the call-home mailing > > list. Here is a draft agenda. It is subject to your input. > > > > If we do not see much input, I'm going to drop the request to Bert. > > > IMO there is a disconnect between the BoF charter text below and the > email discussions I (mostly) followed in the last month. > I am in favor of sharply defined work that will achieve integration > between NETCONF and ISMS through foresight and planning. I'm > not so keen about the open-ended charter text below. > > [IMO, this feature is simply defined as "the NETCONF peer > acting in the agent role initiates the session establishment". > There may be additional ISMS requirements, but I don't know.] > > I suspected (back at the first NETCONF interim in Sunnyvale) > that our decision to provide this "reverse connect" feature > for BEEP only would come back to bite us -- then even more > when we picked SSH as the mandatory transport. I think this > functionality is important enough to be available via the > mandatory transport. (IMO the work can be done as an extension > to the 1.0 specification set.) > > Beyond the firewall/NAT issues, I think there are some > important use cases for this feature, especially when > notification generator applications are introduced in NETCONF. > Issues such as mobility, scale, and auto-configuration may > make applications a lot easier to design if the agent > connects to the manager. > > > > > > Eliot > > > Andy > > > > > Title: callhome > > Period of time: 1 hour > > Area: ops-nm > > Expected # attendees: 40-60 (small room) > > Don't conflict with: ISMS, ops-area, netconf (if there is one) > > > > > > Short Description: Discussion of Architectural Issues Concerning > > protocols that could benefit from reversing > > of roles > > > > Long Description: > > > > Certain protocols, and in particular management protocols where > > devices on either end of connection take client server roles may > > be able to take advantage of "Call Home" functionality, when > > traditional roles are reversed, and a server connect to a client. > > Examples of existing protocols that make use of call home include > > SMTP [ETRN] and COPS. At this BoF we will look at extending such > > functionality into other protocols, as well as any architectural > > issues this raises. > > > > This work stems from efforts in ISMS to extend SNMP to run over SSH, > > as well as work as work that has gone on in NETCONF. > > > > We will begin with a discussion of > > draft-lear-callhome-description-0[1,2].txt, which contains a > > description of call home, what problems it can solve, and > what some of > > the architectural issues are. During the BoF we may identify > > additional such issues as well as protocols other than management > > protocols that could benefit from this work. An additional > potential > > question should be whether a generic standard or process should be > > used to implement call home, such as rules for SSH. > > > > There are three possible outcomes: a working group to add > "call home" > > functionality to existing protocols such as SNMP/SSH and > NETCONF/SSH, > > use of existing working groups for this purpose, or nothing. > > > > Chair: Eliot Lear (or tbd) > > Agenda: > > > > Agenda bashing - 1 minute > > Presentation of draft-lear-callhome-description-00.txt 19 minutes > > Application to SNMP and open areas - 10 minutes > > Discussion including architectural issues - 20 minutes > > Moving Forward Options - 10 minutes > > > > > > > > > _______________________________________________ > Call-home mailing list > Call-home@ietf.org > https://www1.ietf.org/mailman/listinfo/call-home > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 07:56:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOAq-0003Wa-RT; Fri, 14 Oct 2005 07:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOAo-0003WQ-Vc for isms@megatron.ietf.org; Fri, 14 Oct 2005 07:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04729 for ; Fri, 14 Oct 2005 07:56:26 -0400 (EDT) Message-Id: <200510141156.HAA04729@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQOLW-0000wC-CT for isms@ietf.org; Fri, 14 Oct 2005 08:07:35 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005101411562001400lu2cee>; Fri, 14 Oct 2005 11:56:20 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #2: is server authentication a requirement that SNMP willrequire Date: Fri, 14 Oct 2005 07:56:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQP4i43PTPse8URdmOLogjswlQGwABW41w In-Reply-To: <200510132146.RAA19711@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > #2: a) is server authentication a requirement that SNMP will require > of the client? I think we should NOT permit NOT doing server authentication. It is my understanding (which might be mistaken) that not authenticating the server is generally frowned upon by SSH, but is not "MUST NOT" > b) how can we verify that server authentication was performed, > or do we take simply trust the SSH client layer to perform such > authentication? I think we must trust the lower layer to do its job. We have no means for verification. > c) for the common case of DH signed by public keys, how does > the client learn the host's public key in advance, and verify that the > correct key is being used? NETCONF, or CLI scripting, or other operator-chosen mechanism will need to pre-configure the SSH server with this information. I think this is consistent with current SSH usage. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 10:27:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQX2-000377-TC; Fri, 14 Oct 2005 10:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQX1-00036u-QO for isms@megatron.ietf.org; Fri, 14 Oct 2005 10:27:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13733 for ; Fri, 14 Oct 2005 10:27:29 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQhk-00058d-3z for isms@ietf.org; Fri, 14 Oct 2005 10:38:41 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9EERLBT019907; Fri, 14 Oct 2005 07:27:21 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9EERE5k024093; Fri, 14 Oct 2005 07:27:14 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9EEREvC024090; Fri, 14 Oct 2005 07:27:14 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 14 Oct 2005 07:27:14 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] #1: is it important to support anonymous user access to SNMP? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I noticed a small, yet important typo. Also, an example.... On Thu, 13 Oct 2005, David T. Perkins wrote: > HI, > > What anonymous user means is the following... > 1) the identity of a command generator (an SNMP management app) > is not verified (and is unknown) > 2) the identity of the command responder (an SNMP agent) > is authenticated > 3) the integrity (and timeliness) of the SNMP messages is > verified > Optionally, the messages are encrypted. > > This capability allows "authentic management information" to > be obtained from an anonymous identity. There are many ^^^^ should be "by" > real-world examples of this usage pattern. I believe that > it is more important to be able to have encrypted and > integrity checked messages instead of just integrity checked > messages. This "anonymous user" allows authentic message > exchange with a "new identity" without any configuration > of the SNMP agent's configuration. This is a VERY > GOOD THING. A very common use case is making network status available to anyone. "Anonymous user" means that the info is authentic. > > In the other direction, what anonymous user means is the following... > 1) the identity of a notification receiver is not verified > 2) the identity of a notification generator (an agent) > is authenticated > 3) the integrity (and timeliness) of SNMP messages is > verified. > Optionally, the messages are encrypted. > > This capability allows "authentic management information" > to be sent via a notification to an anonymous identity. > I believe that this could be quite problematic to implement, > and I can't think of any the real-world cases for this. > Also, a new receiver requires an update of configuration > of the SNMP agent to specify a transport address. > > On Thu, 13 Oct 2005, Nelson, David wrote: > > > Dave Harrington writes... > > > > > From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > > > that is authenticated and even private when the session initiator or > > > responder is anonymous." > > > > > > This is a new feature provided by SBSM. Can we establish consensus > > > that a) this is needed or b) this is not needed? > > > > I may be particularly obtuse on this point, but I fail to see how a > > truly anonymous entity can ever be authenticated. Private, yes. But > > authenticated? > > > > > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 11:57:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRvl-0004pL-Eh; Fri, 14 Oct 2005 11:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRvk-0004pF-Ob for isms@megatron.ietf.org; Fri, 14 Oct 2005 11:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25778 for ; Fri, 14 Oct 2005 11:57:08 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQS6T-0001mk-US for isms@ietf.org; Fri, 14 Oct 2005 12:08:19 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 08:57:02 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666232852:sNHT33078304" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EFuuJj027951; Fri, 14 Oct 2005 08:57:00 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 08:56:59 -0700 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] #1: is it important to support anonymous user access to SNMP? Date: Fri, 14 Oct 2005 08:56:59 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B9996E@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user access to SNMP? Thread-Index: AcXQPFw6VtbELyJ8TlOQriZrOKtcmgAm217Q From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 14 Oct 2005 15:56:59.0783 (UTC) FILETIME=[E9229170:01C5D0D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I don't see a potential application for anonymous with SNMP, I think it is not needed. =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:24 PM To: isms@ietf.org Subject: [Isms] #1: is it important to support anonymous user access to SNMP? >From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange that is authenticated and even private when the session initiator or responder is anonymous." This is a new feature provided by SBSM. Can we establish consensus that a) this is needed or b) this is not needed? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 12:00:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRym-00067m-2q; Fri, 14 Oct 2005 12:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRyd-00062q-1d for isms@megatron.ietf.org; Fri, 14 Oct 2005 12:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25979 for ; Fri, 14 Oct 2005 12:00:06 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQS9L-0001sd-Fj for isms@ietf.org; Fri, 14 Oct 2005 12:11:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2005 08:59:47 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="352168452:sNHT2338951458" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EFxHK9029533; Fri, 14 Oct 2005 08:59:45 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 08:59:44 -0700 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] #2: is server authentication a requirement that SNMP willrequire Date: Fri, 14 Oct 2005 08:59:44 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #2: is server authentication a requirement that SNMP willrequire Thread-Index: AcXQP4i43PTPse8URdmOLogjswlQGwAmH5Ew From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 14 Oct 2005 15:59:44.0938 (UTC) FILETIME=[4B9338A0:01C5D0D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:46 PM To: isms@ietf.org Subject: [Isms] #2: is server authentication a requirement that SNMP willrequire #2: a) is server authentication a requirement that SNMP will require of the client?=20 I think this is an artifact of any TMSM, I don't think we really have an option. We will have to support it. b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? We have to trust the SSH layer. Any TMSM not just SSHSM will need to trust the transport layer to perform server authentication and key negotiation. c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? I had mentioned this in a previous note, SSHSM does create the need to manually provision public keys on clients until we have X.509 support (or GSSAPI is being used). SSH client implementations in interactive mode will verify the key by echoing it to the user and saving the key once the user accepts. We cannot do that with SSHSM and we either require manual provisioning of server public keys or accept blindly the first time, which make it suscepitble to mitm. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 12:02:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQS19-0006pg-Am; Fri, 14 Oct 2005 12:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQS17-0006pQ-PP for isms@megatron.ietf.org; Fri, 14 Oct 2005 12:02:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26172 for ; Fri, 14 Oct 2005 12:02:41 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSBr-0001y8-8g for isms@ietf.org; Fri, 14 Oct 2005 12:13:52 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 09:02:34 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666234688:sNHT897570974" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EG1nKL001496; Fri, 14 Oct 2005 09:02:31 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:02:29 -0700 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] #5: Should discuss management/monitoring needs in non-brokennetworks? Date: Fri, 14 Oct 2005 09:02:28 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99978@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #5: Should discuss management/monitoring needs in non-brokennetworks? Thread-Index: AcXQP/EgV4O0bhY7QDidbWW9ktYnfwAmJA+A From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 14 Oct 2005 16:02:29.0182 (UTC) FILETIME=[AD78DDE0:01C5D0D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think #4 & #5 could make a section that talks about impact and recommendations of using session based security to SNMP, I think this should be in broader spec (may be applicatability document). =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:49 PM To: isms@ietf.org Subject: [Isms] #5: Should discuss management/monitoring needs in non-brokennetworks? #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 12:20:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSFJ-0008QC-Rj; Fri, 14 Oct 2005 12:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSFH-0008Oj-2u for isms@megatron.ietf.org; Fri, 14 Oct 2005 12:17:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27508 for ; Fri, 14 Oct 2005 12:17:18 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSQ0-0002YJ-GH for isms@ietf.org; Fri, 14 Oct 2005 12:28:29 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 09:17:13 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666242574:sNHT445356754" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGGNKL010999; Fri, 14 Oct 2005 09:17:10 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:17:07 -0700 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] #9: Can an existing R/R session be reused for notifications? Date: Fri, 14 Oct 2005 09:17:07 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99989@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #9: Can an existing R/R session be reused for notifications? Thread-Index: AcXQQELmXTQ9nG2BSqaP5HT+e22cqgAmkFWw From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 14 Oct 2005 16:17:07.0578 (UTC) FILETIME=[B90975A0:01C5D0DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I certainly hope we consider the possibility since SSH does allow multiple channels to be created within a session. We do need to consider the issue that the principals that are authenticated in either direction are not symmetric and we might need to figure out they can be mapped to allow a channel for NMS to agent to be reused for agent to NMS. i.e In the case of a R/R channel, the client is a NMS user that authenticates to the SSH server on the agent, the server authenticates via it's public key. The agent (SNMP engine) will authorize the requests based on that user. In case of notifications, we will need the agent (notification originator) to authenticate the NMS host identity via it's public key and provide client identity (configured username)and credentials to authenticate itself to the NMS (Notification reciever). =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:51 PM To: isms@ietf.org Subject: [Isms] #9: Can an existing R/R session be reused for notifications? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 12:20:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQS8T-00037y-SN; Fri, 14 Oct 2005 12:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQS8S-00037e-JB for isms@megatron.ietf.org; Fri, 14 Oct 2005 12:10:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26952 for ; Fri, 14 Oct 2005 12:10:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSJC-0002Ij-2T for isms@ietf.org; Fri, 14 Oct 2005 12:21:27 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 09:10:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9EG9r8q014093; Fri, 14 Oct 2005 09:10:03 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:10:08 -0700 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] #8: Do we need a mapping between the SSH key and SNMPengineID? Date: Fri, 14 Oct 2005 09:10:07 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99980@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Thread-Index: AcXQQCcWe5m8R8aCT3iYNBmJBi8SqAAmMFtA From: "Kaushik Narayan \(kaushik\)" To: , X-OriginalArrivalTime: 14 Oct 2005 16:10:08.0005 (UTC) FILETIME=[BEF3B350:01C5D0D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 I think we should consider using/mapping the identity of the SNMP engine to the SNMP engine ID, this will be particularly useful when you have multiple SNMP engines on the same host (single SSH server). I am not quite sure about the spoofing issue since that should be taken care by server (agent) authentication by the SSH transport protocol. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:51 PM To: isms@ietf.org Subject: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent?=20 David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 13:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTCo-0005k2-8w; Fri, 14 Oct 2005 13:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTCm-0005go-9T for isms@megatron.ietf.org; Fri, 14 Oct 2005 13:18:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01410 for ; Fri, 14 Oct 2005 13:18:46 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTNQ-0004Op-Ap for isms@ietf.org; Fri, 14 Oct 2005 13:29:58 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9EHISZC010155 for ; Fri, 14 Oct 2005 13:18:34 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 14 Oct 2005 13:18:16 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Fri, 14 Oct 2005 13:18:13 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 13:17:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 13:17:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EF@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQAoL8vA From: "Nelson, David" To: X-OriginalArrivalTime: 14 Oct 2005 17:17:41.0355 (UTC) FILETIME=[2EEFD3B0:01C5D0E3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.6627 P:95.9108 R:95.9108 S:40.3606 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Subject: [Isms] #19: should RADIUS be exposed outside of SSH? Yes and no. The details of RADIUS authentication need not be exposed outside of SSH, except for making the authenticated identity (e.g. User-Name) available. The details of RADIUS authorization, which may be mapped onto, or otherwise impact, SNMP access control mechanisms need to be exposed to SNMP. One point that hasn't had much [any] discussion is that AAA services such as RADIUS and Diameter are designed to provision a specific service, such as packet forwarding or telnet terminal services. I believe that AAA should provision SNMP management access as a specific service, and therefore a RADIUS authorization for SNMP access should not be capable of being used for packet forwarding services (or visa versa). This is another level of authorization that would need to be exposed beyond SSH. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 13:48:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTfK-0000sd-0P; Fri, 14 Oct 2005 13:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTfI-0000sY-Nw for isms@megatron.ietf.org; Fri, 14 Oct 2005 13:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02640 for ; Fri, 14 Oct 2005 13:48:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTq3-00054O-5v for isms@ietf.org; Fri, 14 Oct 2005 13:59:28 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 10:48:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EHlWv7015125; Fri, 14 Oct 2005 10:48:08 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:48:07 -0700 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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 10:48:06 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99A35@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQAoL8vAAAEwAOA= From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 14 Oct 2005 17:48:07.0865 (UTC) FILETIME=[6F9F2290:01C5D0E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Please find my reply inline.=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David Sent: Friday, October 14, 2005 10:18 AM To: isms@ietf.org Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? > Subject: [Isms] #19: should RADIUS be exposed outside of SSH? Yes and no. The details of RADIUS authentication need not be exposed outside of SSH, except for making the authenticated identity (e.g. User-Name) available. The details of RADIUS authorization, which may be mapped onto, or otherwise impact, SNMP access control mechanisms need to be exposed to SNMP. This is not a RADIUS specific requirement, there needs to be a way to map the user identity authenticated by SSH to the SNMPv3 securityName. One point that hasn't had much [any] discussion is that AAA services such as RADIUS and Diameter are designed to provision a specific service, such as packet forwarding or telnet terminal services. I believe that AAA should provision SNMP management access as a specific service, and therefore a RADIUS authorization for SNMP access should not be capable of being used for packet forwarding services (or visa versa). This is another level of authorization that would need to be exposed beyond SSH. This is an important discussion but it isn't this specific to AAA handling of management (CLI, NetConf, SNMP) authorization. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 15:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUzb-0002NM-2v; Fri, 14 Oct 2005 15:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUzZ-0002NF-Is for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:13:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05646 for ; Fri, 14 Oct 2005 15:13:16 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVAK-0006pW-NF for isms@ietf.org; Fri, 14 Oct 2005 15:24:30 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA29876 for ; Fri, 14 Oct 2005 15:16:35 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029486; Fri, 14 Oct 05 15:15:02 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 14 Oct 2005 15:11:39 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 14 Oct 2005 15:11:37 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 15:10:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 15:10:38 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F0@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQAoL8vAAAEwAOAAAtFGAA== From: "Nelson, David" To: X-OriginalArrivalTime: 14 Oct 2005 19:10:39.0586 (UTC) FILETIME=[F713CC20:01C5D0F2] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:84.0661 M:98.6627 P:95.9108 R:95.9108 S:48.0129 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... =20 > This is not a RADIUS specific requirement, there needs to be a way to > map the user identity authenticated by SSH to the SNMPv3 securityName. Good point. I had assumed that the question was using RADIUS as a specific instance of generalized AAA service "exposure" requirements. > This is an important discussion but it isn't this specific to AAA > handling of management (CLI, NetConf, SNMP) authorization. Yes, in a way. However, there is no RFC that I'm aware of that describes RADIUS provisioning of management other than CLI (Service-Types of Administrative and NAS-Prompt). While not an issue for SSHSM itself, it is an issue for a RADIUS document that supports SSHSM, and probably an issue for SSH implementations used to support SSHSM. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 15:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVUT-0002oh-3h; Fri, 14 Oct 2005 15:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVUR-0002ly-UG for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06945 for ; Fri, 14 Oct 2005 15:45:08 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVfB-0007ZH-Rc for isms@ietf.org; Fri, 14 Oct 2005 15:56:23 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVUN-0005Or-00 for isms@ietf.org; Fri, 14 Oct 2005 15:45:11 -0400 Message-ID: <001a01c5d0f8$453b2ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132149.RAA19807@ietf.org> Subject: Re: [Isms] #6: Are there are any wrinkles to coexistence withSNMPv1/v2c/USM? Date: Fri, 14 Oct 2005 12:48:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:49 PM > Subject: [Isms] #6: Are there are any wrinkles to coexistence withSNMPv1/v2c/USM? ... Someone should think through how proxy would work, or whether it would be simpler to just say "don't do that". Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 15:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVVs-0003yb-7a; Fri, 14 Oct 2005 15:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVVq-0003yQ-GR for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07016 for ; Fri, 14 Oct 2005 15:46:36 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVga-0007bl-PX for isms@ietf.org; Fri, 14 Oct 2005 15:57:51 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVVm-0005ge-00 for isms@ietf.org; Fri, 14 Oct 2005 15:46:39 -0400 Message-ID: <001f01c5d0f8$79dfbce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132150.RAA19823@ietf.org> Subject: Re: [Isms] #7: is there still a need for an "authoritative SNMPengine"? Date: Fri, 14 Oct 2005 12:50:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:49 PM > Subject: [Isms] #7: is there still a need for an "authoritative SNMPengine"? ... This should probably be re-phrased in terms of Juergen's catergorization. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 15:52:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVbA-0005oH-Ua; Fri, 14 Oct 2005 15:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVbA-0005oA-21 for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:52:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07211 for ; Fri, 14 Oct 2005 15:52:05 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVlw-0007qy-5s for isms@ietf.org; Fri, 14 Oct 2005 16:03:20 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVb7-0007AJ-00 for isms@ietf.org; Fri, 14 Oct 2005 15:52:09 -0400 Message-ID: <003201c5d0f9$3ed35ac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132153.RAA20006@ietf.org> Subject: Re: [Isms] #11: zero-length OCTET STRING, or ASN.1 NULL for msgSecurityParameters? Date: Fri, 14 Oct 2005 12:55:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:53 PM > Subject: [Isms] #11: zero-length OCTET STRING,or ASN.1 NULL for msgSecurityParameters? > > #11: If we eliminate all msgSecurityParameters, should the > msgSecurityParameters field in the SNMPv3 message simply be a > zero-length OCTET STRING, or should it be an ASN.1 NULL? ... Unless folks want to re-open RFC 3412, it will have to be a zero-length OCTET STRING, since that's the only thing permitted by the ASN.1 there. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 15:56:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVfn-00073m-00; Fri, 14 Oct 2005 15:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVfl-00071e-LU for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:56:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07852 for ; Fri, 14 Oct 2005 15:56:51 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVqV-000872-9g for isms@ietf.org; Fri, 14 Oct 2005 16:08:06 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVfe-0000la-00 for isms@ietf.org; Fri, 14 Oct 2005 15:56:50 -0400 Message-ID: <003701c5d0f9$e625d3c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132154.RAA20067@ietf.org> Subject: Re: [Isms] #12: msgflags Date: Fri, 14 Oct 2005 13:00:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:54 PM > Subject: [Isms] #12: msgflags > > #12: a) how does SSHSM determine whether SSH can provide the security > services requested in msgFlags? I think it simply MUST. The "how" is an implementation matter, and we have no business specifying the mechanism. ... > c) when sending a message into an environment where encryption > is not legal, how do we ensure that encryption is not provided? ... This is the same as (12 a), and if one accepts it as a requirement, (I wouldn't) (12 b) is moot. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVij-0007kX-9y; Fri, 14 Oct 2005 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVih-0007kO-On for isms@megatron.ietf.org; Fri, 14 Oct 2005 15:59:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08289 for ; Fri, 14 Oct 2005 15:59:53 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVtT-0008Hy-8V for isms@ietf.org; Fri, 14 Oct 2005 16:11:08 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVid-0001eX-00; Fri, 14 Oct 2005 15:59:55 -0400 Message-ID: <003c01c5d0fa$54cdc4e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , References: <200510132154.RAA20090@ietf.org> Subject: Re: [Isms] #13: will SSHSM be impacted by keychanges to the SSH localdatastore? Date: Fri, 14 Oct 2005 13:03:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:54 PM > Subject: [Isms] #13: will SSHSM be impacted by keychanges to the SSH localdatastore? ... Just as USM has weasel words about when key changes (don't) take effect, we'll need to say something about what key changes do for new sessions and don't do for existing sessions, with extra headscratching for changes that take place during session establishment. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:01:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVkT-0000ai-6a; Fri, 14 Oct 2005 16:01:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVkR-0000ZI-H9 for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:01:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08978 for ; Fri, 14 Oct 2005 16:01:41 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVvC-000070-2o for isms@ietf.org; Fri, 14 Oct 2005 16:12:55 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVkO-0002BJ-00 for isms@ietf.org; Fri, 14 Oct 2005 16:01:44 -0400 Message-ID: <004101c5d0fa$9565b800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132155.RAA20129@ietf.org> Subject: Re: [Isms] #14: MUST the SSHSM model provide mutual authentication, etc.? Date: Fri, 14 Oct 2005 13:05:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:55 PM > Subject: [Isms] #14: MUST the SSHSM model provide mutual authentication,etc.? > > #14: MUST the SSHSM model provide mutual authentication of the client > and server, and MUST it authenticate, integrity-check, and encrypt the > messages? ... It would seem rather pointless if support for these capabilities was not mandatory. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:03:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVmQ-0001F4-QP; Fri, 14 Oct 2005 16:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVmQ-0001En-1B for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09674 for ; Fri, 14 Oct 2005 16:03:44 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVxC-0000Mb-Ky for isms@ietf.org; Fri, 14 Oct 2005 16:14:58 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQVmO-0002oH-00 for isms@ietf.org; Fri, 14 Oct 2005 16:03:48 -0400 Message-ID: <004601c5d0fa$dfad38c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132156.RAA20185@ietf.org> Subject: Re: [Isms] #15: how does SSHSM get the information from SSH fortmStateReference? Date: Fri, 14 Oct 2005 13:07:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 2:56 PM > Subject: [Isms] #15: how does SSHSM get the information from SSH fortmStateReference? > > #15: What data needs to be stored in the tmStateReference, and how > does SSHSM get the information from SSH, for the various > authentication and transport options? ... For the second half of this two-part question, I'd say it's an implementation decision, and we have no business specifying how it is to be done. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:25:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQW7g-0008NS-Bv; Fri, 14 Oct 2005 16:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQW7e-0008MM-AR for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19699 for ; Fri, 14 Oct 2005 16:25:40 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWIN-000467-Mb for isms@ietf.org; Fri, 14 Oct 2005 16:36:54 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 13:25:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9EKP89S008831; Fri, 14 Oct 2005 13:25:36 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 13:25:35 -0700 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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 13:25:34 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99B1E@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQAoL8vAAAEwAOAAAtFGAAACv9mA From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 14 Oct 2005 20:25:35.0730 (UTC) FILETIME=[6EFCED20:01C5D0FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > This is an important discussion but it isn't this specific to AAA=20 > handling of management (CLI, NetConf, SNMP) authorization. Yes, in a way. However, there is no RFC that I'm aware of that describes RADIUS provisioning of management other than CLI (Service-Types of Administrative and NAS-Prompt). While not an issue for SSHSM itself, it is an issue for a RADIUS document that supports SSHSM, and probably an issue for SSH implementations used to support SSHSM. Would this part of a RADIUS document for SSHSM or a general document that talks about RADIUS extensions for network management. I personally prefer a more generic approach here although there might be some SNMP specific attributes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:33:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWFN-0002KX-IW; Fri, 14 Oct 2005 16:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWFM-0002KS-IF for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22659 for ; Fri, 14 Oct 2005 16:33:38 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWQ8-0005GM-Ak for isms@ietf.org; Fri, 14 Oct 2005 16:44:53 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWFB-0004g0-00 for isms@ietf.org; Fri, 14 Oct 2005 16:33:33 -0400 Message-ID: <008f01c5d0ff$077875a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132220.SAA21779@ietf.org> Subject: Re: [Isms] #16: What should be the source of theSSHSMmechanism-specific username? Date: Fri, 14 Oct 2005 13:37:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:20 PM > Subject: RE: [Isms] #16: What should be the source of theSSHSMmechanism-specific username? > > To be clear about point#16, this is about how to get the username (or > other SSH authenticated identity from the SSH layer). > > Is this implementation-specific? If so, is the standard sufficently > unambiguous to be secure and to permit interoperability? ... This is definitely implementation specific. No comment on the second question. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:36:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWHi-0003US-2P; Fri, 14 Oct 2005 16:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWHg-0003UC-Tc for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:36:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22896 for ; Fri, 14 Oct 2005 16:36:02 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWS8-0005LO-Mw for isms@ietf.org; Fri, 14 Oct 2005 16:47:18 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9EKZhZC022302 for ; Fri, 14 Oct 2005 16:35:44 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 14 Oct 2005 16:35:44 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Fri, 14 Oct 2005 16:35:44 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 16:33:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 16:33:50 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F2@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXQQWVbZzANsOoSTcO4IuCcyPM3DQAoL8vAAAEwAOAAAtFGAAACv9mAAAAcuJA= From: "Nelson, David" To: X-OriginalArrivalTime: 14 Oct 2005 20:33:50.0902 (UTC) FILETIME=[96222D60:01C5D0FE] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:99.8514 P:95.9108 R:95.9108 S: 6.3364 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... > Would this part of a RADIUS document for SSHSM or a general document > that talks about RADIUS extensions for network management. I personally > prefer a more generic approach here although there might be some SNMP > specific attributes. Most likely in a RADIUS extensions for network management document, which could contain some specific attributes for SNMP. Coincidentally, there is such an I-D, authored by Greg Weber and myself. I have mentioned this document before. Once the ISMS requirements are clear, we will likely make the appropriate revisions to this draft. http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-02.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWMq-00011F-KV; Fri, 14 Oct 2005 16:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWMo-000114-LH for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23429 for ; Fri, 14 Oct 2005 16:41:20 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWXb-0005ae-8N for isms@ietf.org; Fri, 14 Oct 2005 16:52:35 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWMm-00004T-00 for isms@ietf.org; Fri, 14 Oct 2005 16:41:24 -0400 Message-ID: <00a201c5d100$202aacc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EF@MAANDMBX2.ets.enterasys.com> Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 13:44:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Nelson, David" > To: > Sent: Friday, October 14, 2005 10:17 AM > Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? ... > One point that hasn't had much [any] discussion is that AAA services > such as RADIUS and Diameter are designed to provision a specific > service, such as packet forwarding or telnet terminal services. I > believe that AAA should provision SNMP management access as a specific > service, and therefore a RADIUS authorization for SNMP access should not > be capable of being used for packet forwarding services (or visa versa). > This is another level of authorization that would need to be exposed > beyond SSH. I agree that it makes sense to treat SNMP management access as a separate service. I wonder whether there would be any value to subdividing that service into, for example, notification, monitoring, and control services. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:45:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWQp-0002l2-N8; Fri, 14 Oct 2005 16:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWQo-0002jz-ET for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23708 for ; Fri, 14 Oct 2005 16:45:28 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWbZ-0005iO-97 for isms@ietf.org; Fri, 14 Oct 2005 16:56:43 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWQk-0001Ey-00 for isms@ietf.org; Fri, 14 Oct 2005 16:45:31 -0400 Message-ID: <00ab01c5d100$b3425080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132218.SAA21656@ietf.org> Subject: Re: [Isms] #20 the source of the mapping of username to securityName Date: Fri, 14 Oct 2005 13:48:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:18 PM > Subject: RE: [Isms] #20 the source of the mapping of username to securityName > > To be clear about this point, it is about the ***mapping*** of the > SSH-authenticated identity to securityName. > > If we require admins to preconfigure a MIB module with the mappings, > we seem to have the same problem USM has. ... Agreed. This has the same gestalt as getting the information one would otherwise find in the vacmSecurityToGroupTable. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:49:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWUK-00030u-9V; Fri, 14 Oct 2005 16:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWUI-00030j-AX for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:49:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23860 for ; Fri, 14 Oct 2005 16:49:04 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWf2-0005nC-AW for isms@ietf.org; Fri, 14 Oct 2005 17:00:16 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWUD-0002HE-00 for isms@ietf.org; Fri, 14 Oct 2005 16:49:05 -0400 Message-ID: <00b201c5d101$3354dfe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132201.SAA20527@ietf.org> Subject: Re: [Isms] #21: persistent configuration for notifications Date: Fri, 14 Oct 2005 13:52:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:01 PM > Subject: [Isms] #21: persistent configuration for notifications > > #21: we need to determine what data should be persistent and stored in > the LCD for notification purposes. ... And how this information is tied to that in the tables from RFC 3413. Perhaps another way to look at it is this: what information do we need to deliver (or accept) a notification that isn't provided by RFC 3413? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 16:54:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWZU-0005IJ-Er; Fri, 14 Oct 2005 16:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWZS-0005IB-Cv for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24088 for ; Fri, 14 Oct 2005 16:54:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWkE-0005vm-Fz for isms@ietf.org; Fri, 14 Oct 2005 17:05:39 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2005 13:54:20 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="352301617:sNHT23678404" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EKs6uj011721; Fri, 14 Oct 2005 13:54:18 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 13:54:17 -0700 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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 13:54:16 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99B62@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXRAAUPc+D4DApuSWOiroAZU9q5kAAAJNUw From: "Kaushik Narayan \(kaushik\)" To: "Randy Presuhn" , X-OriginalArrivalTime: 14 Oct 2005 20:54:17.0637 (UTC) FILETIME=[71531550:01C5D101] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I agree that it makes sense to treat SNMP management access as a separate service. I wonder whether there would be any value to subdividing that service into, for example, notification, monitoring, and control services. The RADIUS service would typically serve as a namespace for authorization information. We also need to careful about proliferation of services since they would make administration of authorization more difficult on a RADIUS server. I am really not sure about the need for separate services for notification, monitoring etc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWky-0008JR-Lb; Fri, 14 Oct 2005 17:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWkx-0008JG-Jt for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24888 for ; Fri, 14 Oct 2005 17:06:19 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWvk-0006KP-S0 for isms@ietf.org; Fri, 14 Oct 2005 17:17:33 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWkr-00071W-00 for isms@ietf.org; Fri, 14 Oct 2005 17:06:17 -0400 Message-ID: <00e201c5d103$9a413940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132207.SAA20842@ietf.org> Subject: Re: [Isms] #29: do we need reports? Date: Fri, 14 Oct 2005 14:09:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:07 PM > Subject: [Isms] #29: do we need reports? > > #29: do we need to support reports? For what purpose? ... Yes. For example, RFC 3413 section 3.2 requires: - If the isAccessAllowed ASI returns a noSuchContext error, processing of the management operation is halted, no result PDU is generated, the snmpUnknownContexts counter is incremented, and control is passed to step (6) below for generation of a report message. and - If the context named by the contextName parameter is unavailable, processing of the management operation is halted, no result PDU is generated, the snmpUnavailableContexts counter is incremented, and control is passed to step (6) below for generation of a report message. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:09:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWoE-0000ip-To; Fri, 14 Oct 2005 17:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWoE-0000ik-35 for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:09:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25255 for ; Fri, 14 Oct 2005 17:09:41 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWyy-0006TP-Da for isms@ietf.org; Fri, 14 Oct 2005 17:20:52 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWoA-0000H0-00 for isms@ietf.org; Fri, 14 Oct 2005 17:09:42 -0400 Message-ID: <00e701c5d104$143c55e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132208.SAA20931@ietf.org> Subject: Re: [Isms] #30: do we need to check whether securityParameters parsescorrectly? Date: Fri, 14 Oct 2005 14:13:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:08 PM > Subject: [Isms] #30: do we need to check whether securityParameters parsescorrectly? > > #30: If we actually do not extract anything from securityParameters, > do we need to check whether this field parses correctly? ... Yes, within whatever constraints are extablished by the security model. If the security model says it needs to be a zero-length OCTET STRING, then implementations need to enforce that. If we give it more content / structure, then those too need to be enforced. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWtB-0005G0-2j; Fri, 14 Oct 2005 17:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWtA-0005Fv-4W for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25553 for ; Fri, 14 Oct 2005 17:14:47 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQX3w-0006be-EH for isms@ietf.org; Fri, 14 Oct 2005 17:26:01 -0400 Received: from h-68-166-188-241.snvacaid.dynamic.covad.net ([68.166.188.241] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EQWt7-0001TX-00 for isms@ietf.org; Fri, 14 Oct 2005 17:14:49 -0400 Message-ID: <00ec01c5d104$cb681ec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200510132209.SAA21050@ietf.org> Subject: Re: [Isms] #31: Is maxSizeResponseScopedPDU relevant? Date: Fri, 14 Oct 2005 14:18:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Thursday, October 13, 2005 3:08 PM > Subject: [Isms] #31: Is maxSizeResponseScopedPDU relevant? > > #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once > for the session? Do we need to take into consideration the SSH window > size? ... maxSizeResponseScopedPDU is relevant; getting rid of it would mean messing with RFC 3413, something I'm sure we'd rather not do. For simplicity, let's leave it where it is, and leave it to implementations to decide whether they want to advertise the same value throughout the lifetime of a session. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:21:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWzh-0007lg-Hb; Fri, 14 Oct 2005 17:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWzg-0007lZ-7Q for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25866 for ; Fri, 14 Oct 2005 17:21:32 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXAS-0006kx-IO for isms@ietf.org; Fri, 14 Oct 2005 17:32:45 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 14:21:25 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666328074:sNHT886302978" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9ELLNJh002326; Fri, 14 Oct 2005 14:21:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 14:26:46 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69061127AE@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXRAAUPc+D4DApuSWOiroAZU9q5kAAAJNUwAAER/tA= From: "Salowey, Joe" To: "Narayan, Kaushik" , "Randy Presuhn" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Something to also consider when looking at management extensions for RADIUS is that the exact type of management may not be know at authentication time. For example if the same SSH service is used for SNMP, CLI and NETCONF you probably won't know what the SSH client wants until it invokes the appropriate subsystem. The same is true for more fine grained services.=20 > -----Original Message----- > From: Narayan, Kaushik=20 > Sent: Friday, October 14, 2005 1:54 PM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? >=20 >=20 > I agree that it makes sense to treat SNMP management access=20 > as a separate service. I wonder whether there would be any=20 > value to subdividing that service into, for example,=20 > notification, monitoring, and control services. >=20 >=20 > >=20 > The RADIUS service would typically serve as a namespace for=20 > authorization information. We also need to careful about=20 > proliferation of services since they would make=20 > administration of authorization more difficult on a RADIUS=20 > server. I am really not sure about the need for separate=20 > services for notification, monitoring etc. >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:41:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXJ4-0007GX-9Z; Fri, 14 Oct 2005 17:41:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXJ2-0007Fq-Rc for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:41:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28342 for ; Fri, 14 Oct 2005 17:41:32 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXTp-0007na-3j for isms@ietf.org; Fri, 14 Oct 2005 17:52:46 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA13131 for ; Fri, 14 Oct 2005 17:44:54 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma013116; Fri, 14 Oct 05 17:43:54 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 14 Oct 2005 17:40:32 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 14 Oct 2005 17:40:32 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 17:40:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 17:40:00 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F3@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXRAAUPc+D4DApuSWOiroAZU9q5kAAAJNUwAAER/tAAAHWWoA== From: "Nelson, David" To: X-OriginalArrivalTime: 14 Oct 2005 21:40:01.0305 (UTC) FILETIME=[D4AD9890:01C5D107] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:40.2281 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Salowey, Joe writes... > Something to also consider when looking at management extensions for > RADIUS is that the exact type of management may not be know at > authentication time. Yes. > For example if the same SSH service is used for > SNMP, CLI and NETCONF you probably won't know what the SSH client wants > until it invokes the appropriate subsystem. The same is true for more > fine grained services. There are three ways that AAA systems that provision specific services typically deal with this issue: 1. the user identity presented for authentication is unique to the specific service, 2. the AAA client identity is unique to the specific service, or 3. the AAA client provides hints to the AAA server in the authentication request as to what service is being requested. The third approach is most common. In the case of an SSH connection where the application protocol is not known at authentication time, this presents a problem. Either the AAA system provides authentication without authorization, or some other method needs to be found. It seems like this in an AAA/SSH issue, and requires some further investigation. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 17:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXZu-0007Ct-3m; Fri, 14 Oct 2005 17:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXZs-00077m-Hk for isms@megatron.ietf.org; Fri, 14 Oct 2005 17:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29321 for ; Fri, 14 Oct 2005 17:58:56 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXke-0008Hf-54 for isms@ietf.org; Fri, 14 Oct 2005 18:10:10 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2005 14:58:49 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="220318919:sNHT34360400" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9ELwGVQ010604; Fri, 14 Oct 2005 14:58:47 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 14:58:45 -0700 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] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 14:58:44 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99BD1@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #19: should RADIUS be exposed outside of SSH? Thread-Index: AcXRAAUPc+D4DApuSWOiroAZU9q5kAAAJNUwAAER/tAAAHWWoAAAhU5w From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 14 Oct 2005 21:58:45.0140 (UTC) FILETIME=[72893540:01C5D10A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org There are two options The AAA server sends down all the management authorization information specific to that particular user. We can have the service names that are qualified, i.e. mgmt-snmp, mgmt-netconf and a SSH authentication request can send a mgmt* which would result in all management authorization information to be returned. The appropriate management protocol can then use this information based on what requests arrive on authenticated SSH channel. The other option is to allow for authorization when requests are sent on top of the SSH channel, this will however require change to protocols such as RADIUS, Diameter to support explicit authorization from the NAS to the AAA server. =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David Sent: Friday, October 14, 2005 2:40 PM To: isms@ietf.org Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? Salowey, Joe writes... > Something to also consider when looking at management extensions for=20 > RADIUS is that the exact type of management may not be know at=20 > authentication time. Yes. > For example if the same SSH service is used for SNMP, CLI and NETCONF > you probably won't know what the SSH client wants > until it invokes the appropriate subsystem. The same is true for more > fine grained services. There are three ways that AAA systems that provision specific services typically deal with this issue: 1. the user identity presented for authentication is unique to the specific service, 2. the AAA client identity is unique to the specific service, or 3. the AAA client provides hints to the AAA server in the authentication request as to what service is being requested. The third approach is most common. In the case of an SSH connection where the application protocol is not known at authentication time, this presents a problem. Either the AAA system provides authentication without authorization, or some other method needs to be found. It seems like this in an AAA/SSH issue, and requires some further investigation. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 19:02:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQYZA-0003mZ-I7; Fri, 14 Oct 2005 19:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWKJ-0007Iw-Vn for isms@megatron.ietf.org; Fri, 14 Oct 2005 16:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23231 for ; Fri, 14 Oct 2005 16:38:45 -0400 (EDT) Received: from mail.networksolutionsemail.com ([205.178.146.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQWV4-0005Uh-Gw for isms@ietf.org; Fri, 14 Oct 2005 16:50:01 -0400 Received: (qmail 5460 invoked by uid 78); 14 Oct 2005 20:38:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail.networksolutionsemail.com with SMTP; 14 Oct 2005 20:38:22 -0000 Message-ID: <4350173B.3070408@andybierman.com> Date: Fri, 14 Oct 2005 13:38:19 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" References: <7D5D48D2CAA3D84C813F5B154F43B15508490441@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508490441@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Oct 2005 19:02:20 -0400 Cc: call-home@ietf.org, ops-nm@ops.ietf.org, isms@ietf.org Subject: [Isms] Re: [Call-home] Re: last call for a Call Home BoF 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wijnen, Bert (Bert) wrote: >Here is my AD-view on this: > >First the NM aspects: >- The topic came up strong in the last ISMS f2f meeting in Paris. >- I (as AD, but also as an individual contributor) worry/worried that > we might make something (like call-home) a MUST for ISMS while it > was not a MUST in NETCONF. I think we should be conistsent in our > NM protocols and try to make sure that the same (security) > infrastructure can be used for ISMS and NetConf (and others). >- I also worry/worried about what impact it may have on SNMPv3 (hence > the discussion on authoritative (engine, information etc). I am > happy to see that that is being well discussed on ISMS list > >Then the IETF-wide aspects >- I worry/worried that we might be doing a point-solution in the NM > space, while it seems to me that the CH fiunctionality is an IETF > wide issue. >- So I at least want to get a much better understanding of what the > IETF-wide or Architectural aspects/possibilities are. >- Even if we decide to do a point-solution, then I still want to try > and make sure that we do so based on a well-informed set of > discussions including those from other areas. > >So that is what the BOF (in my view) needs to address. >The result is (as yet) unknown. It may turn out that there are >(reasonably) simple solutions at the IETF-wide level. If so, then we >(NM folk) may want to help define/specify a generic solution that >we can then also use in NM protocols. >If we need to go down the road of a point-solution, then I would hope >that we at least take into consideration all the things we learn during >the BOF. > >Makes sense? > > makes sense to me to do both. Consider the high-level architectural issues for the generalized problem space, but don't deadlock over a long requirements definition phase. Use the NETCONF/ISMS problem-space to create a specific/point solution that meets the architectural needs, get it deployed, learn from the experience, and move on. Andy >Bert > > > >>-----Original Message----- >>From: call-home-bounces@ietf.org [mailto:call-home-bounces@ietf.org]On >>Behalf Of Andy Bierman >>Sent: Thursday, October 13, 2005 18:00 >>To: Eliot Lear >>Cc: call-home@ietf.org; ops-nm@ops.ietf.org; isms@ietf.org >>Subject: [Call-home] Re: last call for a Call Home BoF >> >> >>Eliot Lear wrote: >> >> >> >>>After all of the mail last month, Bert is considering >>> >>> >>allowing a BoF >> >> >>>on the topic of Call Home. I initially posted a note to >>> >>> >>the call-home >> >> >>>mailing list announcing the possibility of a BoF. Response to that >>>note was - well - underwhelming. If you are interested in >>> >>> >>seeing one, >> >> >>>could you please reply to this email, CCing the call-home mailing >>>list. Here is a draft agenda. It is subject to your input. >>> >>>If we do not see much input, I'm going to drop the request to Bert. >>> >>> >>IMO there is a disconnect between the BoF charter text below and the >>email discussions I (mostly) followed in the last month. >>I am in favor of sharply defined work that will achieve integration >>between NETCONF and ISMS through foresight and planning. I'm >>not so keen about the open-ended charter text below. >> >>[IMO, this feature is simply defined as "the NETCONF peer >>acting in the agent role initiates the session establishment". >>There may be additional ISMS requirements, but I don't know.] >> >>I suspected (back at the first NETCONF interim in Sunnyvale) >>that our decision to provide this "reverse connect" feature >>for BEEP only would come back to bite us -- then even more >>when we picked SSH as the mandatory transport. I think this >>functionality is important enough to be available via the >>mandatory transport. (IMO the work can be done as an extension >>to the 1.0 specification set.) >> >>Beyond the firewall/NAT issues, I think there are some >>important use cases for this feature, especially when >>notification generator applications are introduced in NETCONF. >>Issues such as mobility, scale, and auto-configuration may >>make applications a lot easier to design if the agent >>connects to the manager. >> >> >> >> >>>Eliot >>> >>> >>Andy >> >> >> >>>Title: callhome >>>Period of time: 1 hour >>>Area: ops-nm >>>Expected # attendees: 40-60 (small room) >>>Don't conflict with: ISMS, ops-area, netconf (if there is one) >>> >>> >>>Short Description: Discussion of Architectural Issues Concerning >>> protocols that could benefit from reversing >>> of roles >>> >>>Long Description: >>> >>>Certain protocols, and in particular management protocols where >>>devices on either end of connection take client server roles may >>>be able to take advantage of "Call Home" functionality, when >>>traditional roles are reversed, and a server connect to a client. >>>Examples of existing protocols that make use of call home include >>>SMTP [ETRN] and COPS. At this BoF we will look at extending such >>>functionality into other protocols, as well as any architectural >>>issues this raises. >>> >>>This work stems from efforts in ISMS to extend SNMP to run over SSH, >>>as well as work as work that has gone on in NETCONF. >>> >>>We will begin with a discussion of >>>draft-lear-callhome-description-0[1,2].txt, which contains a >>>description of call home, what problems it can solve, and >>> >>> >>what some of >> >> >>>the architectural issues are. During the BoF we may identify >>>additional such issues as well as protocols other than management >>>protocols that could benefit from this work. An additional >>> >>> >>potential >> >> >>>question should be whether a generic standard or process should be >>>used to implement call home, such as rules for SSH. >>> >>>There are three possible outcomes: a working group to add >>> >>> >>"call home" >> >> >>>functionality to existing protocols such as SNMP/SSH and >>> >>> >>NETCONF/SSH, >> >> >>>use of existing working groups for this purpose, or nothing. >>> >>>Chair: Eliot Lear (or tbd) >>>Agenda: >>> >>>Agenda bashing - 1 minute >>>Presentation of draft-lear-callhome-description-00.txt 19 minutes >>>Application to SNMP and open areas - 10 minutes >>>Discussion including architectural issues - 20 minutes >>>Moving Forward Options - 10 minutes >>> >>> >>> >>> >>> >>_______________________________________________ >>Call-home mailing list >>Call-home@ietf.org >>https://www1.ietf.org/mailman/listinfo/call-home >> >> >> > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 14 20:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQaIF-0001bR-OI; Fri, 14 Oct 2005 20:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQaID-0001b4-Q5 for isms@megatron.ietf.org; Fri, 14 Oct 2005 20:52:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07571 for ; Fri, 14 Oct 2005 20:52:51 -0400 (EDT) Message-Id: <200510150052.UAA07571@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQaT1-0003wM-Fq for isms@ietf.org; Fri, 14 Oct 2005 21:04:08 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005101500524301400l7toie>; Sat, 15 Oct 2005 00:52:44 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? Date: Fri, 14 Oct 2005 20:52:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXRACMoyX2f0XlLRXiyA9QRoKh1mQAB8Edg In-Reply-To: <00a201c5d100$202aacc0$7f1afea9@oemcomputer> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I envision the RADIUS management authorization as providing a "named policy" that refers to an access control policy defined on the managed device, e.g. in VACM. This would be similar to the FilterID attribute used for network access policies. So I would expect the service would be SNMP, and then SNMP deals with how to apply the details of the named policy; the policy name could be a VACM groupname, for example, defined and named by the operator to match their corporate policies. For compatibility with other mgmt interfaces, such as netconf, RADIUS would authorize a named policy, and netconf would apply the netconf access control associated with the named policy. So the servce would be netconf, but the named policy might be notifications, or monitoring, or control services, or something more specific like helpdesk, and defined and named by the operator to match their corporate policies. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Friday, October 14, 2005 4:45 PM > To: isms@ietf.org > Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH? > > Hi - > > > From: "Nelson, David" > > To: > > Sent: Friday, October 14, 2005 10:17 AM > > Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? > ... > > One point that hasn't had much [any] discussion is that AAA services > > such as RADIUS and Diameter are designed to provision a specific > > service, such as packet forwarding or telnet terminal services. I > > believe that AAA should provision SNMP management access as > a specific > > service, and therefore a RADIUS authorization for SNMP > access should not > > be capable of being used for packet forwarding services (or > visa versa). > > This is another level of authorization that would need to be exposed > > beyond SSH. > > I agree that it makes sense to treat SNMP management access as a > separate service. I wonder whether there would be any value > to subdividing > that service into, for example, notification, monitoring, and > control services. > > Randy > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 10:16:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER9Jm-0000pI-Au; Sun, 16 Oct 2005 10:16:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER9Jj-0000pA-3L for isms@megatron.ietf.org; Sun, 16 Oct 2005 10:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03734 for ; Sun, 16 Oct 2005 10:16:44 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER9Uq-0003tJ-VF for isms@ietf.org; Sun, 16 Oct 2005 10:28:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2005 07:16:40 -0700 X-IronPort-AV: i="3.97,219,1125903600"; d="scan'208"; a="220607889:sNHT24739168" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9GEGcUw028877; Sun, 16 Oct 2005 07:16:38 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp23.cisco.com [10.61.64.23]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9GERDYq022429; Sun, 16 Oct 2005 07:27:14 -0700 Message-ID: <435260C4.7040304@cisco.com> Date: Sun, 16 Oct 2005 16:16:36 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH? References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EF@MAANDMBX2.ets.enterasys.com> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325EF@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=721; t=1129472834; x=1129905034; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20#19=3A=20should=20RADIUS=20be=20exposed=20outside=20of= 20SSH?| From:Eliot=20Lear=20| Date:Sun,=2016=20Oct=202005=2016=3A16=3A36=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ToP09gO6Ox5BZ33zrJZ1ujghbsosq2IGSm+/+kgzhF9Dblzg2ncRA3vJmEpJ89lIyLKkuDpQ wtzBd4Rbp5hTBazqDKa1I1wVmBLK18WWV5QJI/rOKFDLLtxUAZAug9Mze50X8nOxeDl5hmFnFli U1DAdr7LXG+CVf+E1NYfGtd4= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Nelson, David wrote: >> Subject: [Isms] #19: should RADIUS be exposed outside of SSH? > One point that hasn't had much [any] discussion is that AAA services > such as RADIUS and Diameter are designed to provision a specific > service, such as packet forwarding or telnet terminal services. I > believe that AAA should provision SNMP management access as a specific > service, and therefore a RADIUS authorization for SNMP access should not > be capable of being used for packet forwarding services (or visa versa). > This is another level of authorization that would need to be exposed > beyond SSH. We should be very careful how we do this. We do not want to tie SSHSM to radius or diameter. In order to even determine this prior to authentication (the specific SNMP subsystem request is made *after* authentication) it seems to me that a separate port is required. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 13:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBy3-00065h-Hz; Sun, 16 Oct 2005 13:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBxw-00065H-O1 for isms@megatron.ietf.org; Sun, 16 Oct 2005 13:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10904 for ; Sun, 16 Oct 2005 13:06:26 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERC93-00082R-Id for isms@ietf.org; Sun, 16 Oct 2005 13:18:04 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9GH6C0e014224 for ; Sun, 16 Oct 2005 10:06:12 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <4ZTC0NZB>; Sun, 16 Oct 2005 10:07:19 -0700 Message-ID: From: "McDonald, Ira" To: isms@ietf.org Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH? Date: Sun, 16 Oct 2005 10:07:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, A separate port would be a very good idea for SNMP over SSH. Using the same port for SSH supporting different management application protocols just reduces the granularity of admin policy (and therefore reduces the likelihood of widespread deployment). Frankly, I cannot imagine any utility for authentication of either initiator or responder in an SNMP over SSH session if ISMS doesn't address authorization (i.e., access control). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Eliot Lear > Sent: Sunday, October 16, 2005 10:17 AM > To: Nelson, David > Cc: isms@ietf.org > Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH? > > > Nelson, David wrote: > >> Subject: [Isms] #19: should RADIUS be exposed outside of SSH? > > One point that hasn't had much [any] discussion is that AAA services > > such as RADIUS and Diameter are designed to provision a specific > > service, such as packet forwarding or telnet terminal services. I > > believe that AAA should provision SNMP management access as > a specific > > service, and therefore a RADIUS authorization for SNMP > access should not > > be capable of being used for packet forwarding services (or > visa versa). > > This is another level of authorization that would need to be exposed > > beyond SSH. > > We should be very careful how we do this. We do not want to > tie SSHSM > to radius or diameter. In order to even determine this prior to > authentication (the specific SNMP subsystem request is made *after* > authentication) it seems to me that a separate port is required. > > Eliot > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 20:41:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJ3w-00075H-0Y; Sun, 16 Oct 2005 20:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJ3t-0006zK-Oe for isms@megatron.ietf.org; Sun, 16 Oct 2005 20:41:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05337 for ; Sun, 16 Oct 2005 20:41:03 -0400 (EDT) Received: from stratton-four-seventeen.mit.edu ([18.187.6.162] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERJF7-0002oU-2j for isms@ietf.org; Sun, 16 Oct 2005 20:52:46 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 81D98E0038; Sun, 16 Oct 2005 20:41:03 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] #2: is server authentication a requirement that SNMP will require References: <200510132146.RAA19711@ietf.org> From: Sam Hartman Date: Sun, 16 Oct 2005 20:41:03 -0400 In-Reply-To: <200510132146.RAA19711@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 17:46:14 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> #2: a) is server authentication a requirement that SNMP David> will require of the client? I suspect this will be a requirement. As an AD I would need to see a strong argument why any security protocol didn't provide server authentication before I would even consider it. You may have modes where no server authentication is provided (although probably not with ssh as a transport) but you need to have support for the protocol feature and you need to have a mandatory to implement mode. However if you are seeing something I don't see that would make it optional feel free to try and convince me. David> b) how can we verify that David> server authentication was performed, or do we take simply David> trust the SSH client layer to perform such authentication? I think you mandate it at the protocol level but leave it up to the implementation to properly implement the spec. David> c) for the common case of DH signed by public keys, how David> does the client learn the host's public key in advance, and David> verify that the correct key is being used? Why are you different than any other ssh application? If you are not, use the same mechanisms (asking the user, scanning possible targets, distributed known_hosts files) other ssh applications use. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 20:59:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJLV-0003Fa-Hp; Sun, 16 Oct 2005 20:59:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJLR-0003FS-03 for isms@megatron.ietf.org; Sun, 16 Oct 2005 20:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05806 for ; Sun, 16 Oct 2005 20:59:10 -0400 (EDT) Received: from stratton-four-seventeen.mit.edu ([18.187.6.162] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERJWe-00036Z-G1 for isms@ietf.org; Sun, 16 Oct 2005 21:10:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 05AD8E0038; Sun, 16 Oct 2005 20:59:10 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] #8: Do we need a mapping between the SSH key and SNMP engineID? References: <200510132150.RAA19867@ietf.org> From: Sam Hartman Date: Sun, 16 Oct 2005 20:59:10 -0400 In-Reply-To: <200510132150.RAA19867@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 17:50:40 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> #8: Do we need a mapping between the SSH key (or other SSH David> engine identifier) and SNMP engineID? What happens if an David> agent "spoofs" another engineID, and an NMS perfoms a SET David> of sensitive parameters to the agent? I cannot answer this question because I don't have enough understanding of SNMP. I can answer a related question. You must authenticate each party back to some name the user provided. On the server: you will get a username out of ssh's user authentication step. You need to make an access control decision and assign access rights based on that username. (I'd argue that as a general rule, that username is the only thing that in practice should matter in terms of assigning those access rights. The particular credentials presented and the particular authentication type used should not in general matter. ) On the client, it is more tricky. You need to securely map information provided by the user into an ssh service to contact and a username to present to that service. Then, you need to make an access control decision and determine if the credentials presented by that service are acceptable. If so, you need to decide as an access control matter what PDUs are acceptable to send to the server. The above is not SNMP specific. The above is true of any ssh application. One of the primary challenges of this working group is transalting that requirement into SNMP, possibly changing the architecture in the process. This will become more complicated because of notifications. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 21:01:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJO3-0003qB-29; Sun, 16 Oct 2005 21:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJO1-0003oc-FQ for isms@megatron.ietf.org; Sun, 16 Oct 2005 21:01:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05903 for ; Sun, 16 Oct 2005 21:01:51 -0400 (EDT) Received: from stratton-four-seventeen.mit.edu ([18.187.6.162] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERJZF-00039Z-1o for isms@ietf.org; Sun, 16 Oct 2005 21:13:34 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 703B1E0038; Sun, 16 Oct 2005 21:01:50 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] #14: MUST the SSHSM model provide mutual authentication, etc.? References: <200510132155.RAA20129@ietf.org> From: Sam Hartman Date: Sun, 16 Oct 2005 21:01:50 -0400 In-Reply-To: <200510132155.RAA20129@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 17:55:10 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> #14: MUST the SSHSM model provide mutual authentication of David> the client and server, and MUST it authenticate, David> integrity-check, and encrypt the messages? I think these are matters for the lower layer (ssh). I think it is reasonable for you to assume the lower layer is providing mutual authentication, sufficient integrity protection and sufficient confidentiality. My other two comments were mostly me talking as an AD. This is mostly me talking as an individual. However if your solution to this question adds significant complexity, I'll need justification for the solution in order to take the document to the IESG. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 16 22:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERL5P-0007kF-G2; Sun, 16 Oct 2005 22:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERL5O-0007k9-U1 for isms@megatron.ietf.org; Sun, 16 Oct 2005 22:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10060 for ; Sun, 16 Oct 2005 22:50:43 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERLGc-0005Qj-1y for isms@ietf.org; Sun, 16 Oct 2005 23:02:28 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr005.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 j9H2obQv023814 for ; Mon, 17 Oct 2005 02:50:37 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 j9H2oUA3032746 for ; Mon, 17 Oct 2005 02:50:37 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101619503622702 for ; Sun, 16 Oct 2005 19:50:36 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 19:50:37 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 19:50:36 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 22:50:35 -0400 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] #8: Do we need a mapping between the SSH key and SNMPengineID? Date: Sun, 16 Oct 2005 22:49:43 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290201514D@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? thread-index: AcXStjSbU/3U9QVaS3WlrK68dLBlCQADurTg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 17 Oct 2005 02:50:35.0770 (UTC) FILETIME=[8C82CDA0:01C5D2C5] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David> #8: Do we need a mapping between the SSH key (or other SSH David> engine identifier) and SNMP engineID? What happens if an David> agent "spoofs" another engineID, and an NMS perfoms a SET David> of sensitive parameters to the agent? > I cannot answer this question because I don't have enough > understanding of SNMP. I can answer a related question. > > You must authenticate each party back to some name the user provided. IMHO there must be a mapping between ISMS-usable SSH keys and related SNMP engine IDs. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 02:21:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERONf-0001xd-HI; Mon, 17 Oct 2005 02:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERONe-0001xV-IE for isms@megatron.ietf.org; Mon, 17 Oct 2005 02:21:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19349 for ; Mon, 17 Oct 2005 02:21:48 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EROYs-0001vc-Cy for isms@ietf.org; Mon, 17 Oct 2005 02:33:33 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9H6LcBT025729; Sun, 16 Oct 2005 23:21:38 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9H6LVX0012417; Sun, 16 Oct 2005 23:21:31 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9H6LU1x012412; Sun, 16 Oct 2005 23:21:31 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 16 Oct 2005 23:21:30 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Blumenthal, Uri" Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? In-Reply-To: <3DEC199BD7489643817ECA151F7C59290201514D@pysmsx401.amr.corp.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I don't follow. Would you fill in the details. Part of the reason that I don't follow is that I see no relationship between the SSH identifies and their keys and SNMP engineIDs. In USM, an identity is the pair (engineID (which is called the security engineID) and user name). SSH has no notion of SNMP engineIDs. On Sun, 16 Oct 2005, Blumenthal, Uri wrote: > David> #8: Do we need a mapping between the SSH key (or other SSH > David> engine identifier) and SNMP engineID? What happens if an > David> agent "spoofs" another engineID, and an NMS perfoms a SET > David> of sensitive parameters to the agent? > > > I cannot answer this question because I don't have enough > > understanding of SNMP. I can answer a related question. > > > > You must authenticate each party back to some name the user provided. > > IMHO there must be a mapping between ISMS-usable SSH keys and related > SNMP engine IDs. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 05:27:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRGz-00031x-Qx; Mon, 17 Oct 2005 05:27:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRGy-00031o-Qz for isms@megatron.ietf.org; Mon, 17 Oct 2005 05:27:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29013 for ; Mon, 17 Oct 2005 05:27:05 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRSB-0007NR-OG for isms@ietf.org; Mon, 17 Oct 2005 05:38:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOH00D3EZZNC1@szxga02-in.huawei.com> for isms@ietf.org; Mon, 17 Oct 2005 17:35:47 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOH00D4EZYFGZ@szxga02-in.huawei.com> for isms@ietf.org; Mon, 17 Oct 2005 17:35:47 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOI00HOO04XC4@szxml01-in.huawei.com>; Mon, 17 Oct 2005 17:38:57 +0800 (CST) Date: Mon, 17 Oct 2005 17:28:02 +0800 From: Miao Fuyou Subject: RE: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? In-reply-to: <618694EF0B657246A4D55A97E38274C3B99980@xmb-sjc-22d.amer.cisco.com> To: "'Kaushik Narayan (kaushik)'" , dbharrington@comcast.net, isms@ietf.org Message-id: <002b01c5d2fd$12765170$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7BIT Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org SSH transport is different from TCP tranport for SNMP. SSHSM starts a SNMP agent as subsystem of SSH server contrasting to TCP as forked child process, it means each subsytem is independent to each other. Will they share same snmpEngineID, just like in UDP or TCP transporting? In other word, do all subsystems started by a SSH server are same SNMP entity? If not, I believe snmpEngineID must be allocated dynamicaly enough. In such case mapping SSH key and snmpEngineID is difficult. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan (kaushik) Sent: Saturday, October 15, 2005 12:10 AM To: dbharrington@comcast.net; isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? I think we should consider using/mapping the identity of the SNMP engine to the SNMP engine ID, this will be particularly useful when you have multiple SNMP engines on the same host (single SSH server). I am not quite sure about the spoofing issue since that should be taken care by server (agent) authentication by the SSH transport protocol. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, October 13, 2005 2:51 PM To: isms@ietf.org Subject: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 09:02:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUdH-0001B2-C8; Mon, 17 Oct 2005 09:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUdF-0001As-UU for isms@megatron.ietf.org; Mon, 17 Oct 2005 09:02:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10915 for ; Mon, 17 Oct 2005 09:02:19 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERUoY-0005JC-LU for isms@ietf.org; Mon, 17 Oct 2005 09:14:09 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 43B654BD9A; Mon, 17 Oct 2005 15:02:05 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07246-06; Mon, 17 Oct 2005 15:02:04 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 292BD4BD9E; Mon, 17 Oct 2005 15:02:03 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 2369D4CE975; Mon, 17 Oct 2005 14:28:17 +0200 (CEST) Date: Mon, 17 Oct 2005 14:28:17 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] #31: Is maxSizeResponseScopedPDU relevant? Message-ID: <20051017122817.GA23920@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <200510132209.SAA21050@ietf.org> <00ec01c5d104$cb681ec0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ec01c5d104$cb681ec0$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Oct 14, 2005 at 02:18:06PM -0700, Randy Presuhn wrote: > Hi - > > > From: "David B Harrington" > > To: > > Sent: Thursday, October 13, 2005 3:08 PM > > Subject: [Isms] #31: Is maxSizeResponseScopedPDU relevant? > > > > #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once > > for the session? Do we need to take into consideration the SSH window > > size? > ... > > maxSizeResponseScopedPDU is relevant; getting rid of it would mean > messing with RFC 3413, something I'm sure we'd rather not do. For > simplicity, let's leave it where it is, and leave it to implementations to > decide whether they want to advertise the same value throughout the > lifetime of a session. I agree. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 11:11:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWe4-0008Qg-KE; Mon, 17 Oct 2005 11:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWe2-0008QY-CO for isms@megatron.ietf.org; Mon, 17 Oct 2005 11:11:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18269 for ; Mon, 17 Oct 2005 11:11:14 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWpM-0000mD-12 for isms@ietf.org; Mon, 17 Oct 2005 11:23:06 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id AC4CF4BD2F; Mon, 17 Oct 2005 17:11:09 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20892-07; Mon, 17 Oct 2005 17:11:08 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 25AD04BDE4; Mon, 17 Oct 2005 17:11:06 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 7B1534CE897; Mon, 17 Oct 2005 13:29:20 +0200 (CEST) Date: Mon, 17 Oct 2005 13:29:19 +0200 From: Juergen Schoenwaelder To: "Kaushik Narayan (kaushik)" Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire Message-ID: <20051017112919.GA23850@boskop.local> Mail-Followup-To: "Kaushik Narayan (kaushik)" , dbharrington@comcast.net, isms@ietf.org References: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Oct 14, 2005 at 08:59:44AM -0700, Kaushik Narayan (kaushik) wrote: > c) for the common case of DH signed by public keys, how does the > client learn the host's public key in advance, and verify that the > correct key is being used? > > I had mentioned this in a previous note, SSHSM does create the need to > manually provision public keys on clients until we have X.509 support > (or GSSAPI is being used). SSH client implementations in interactive > mode will verify the key by echoing it to the user and saving the key > once the user accepts. We cannot do that with SSHSM and we either > require manual provisioning of server public keys or accept blindly the > first time, which make it suscepitble to mitm. Management applications at the very end also have a human being involved. I don't see a reason why a management application can't do the same as my ssh client does when you hit a box you have not talked to before. Initiate a dialog with a human decision maker, open a ticket in a trouble ticket system or whatever the app writer seeks appropriate to get an OK to accept the key. This is all implementation detail for me. The spec should just say somewhere (perhaps in the security considerations section) that public host keys must be verified to prevent mitm attacks and that applications should cache host keys and warn about any changes. It is likely that all this text has already been written and we can just refer to the appropriate section(s) in the ssh documents. I think we should not even try to standardize a way to automatically verify host keys. If there is a need for such a feature, I think the ssh WG should work a general solution since this problem is not ISMS specific. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 11:23:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWph-0002e0-7C; Mon, 17 Oct 2005 11:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWpf-0002dv-FB for isms@megatron.ietf.org; Mon, 17 Oct 2005 11:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19118 for ; Mon, 17 Oct 2005 11:23:15 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERX11-0001CB-AL for isms@ietf.org; Mon, 17 Oct 2005 11:35:07 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr001.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 j9HFN882021742; Mon, 17 Oct 2005 15:23:08 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 j9HFN6RC014051; Mon, 17 Oct 2005 15:23:06 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101708230603747 ; Mon, 17 Oct 2005 08:23:06 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 08:23:06 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 08:22:56 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 11:22:55 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Date: Mon, 17 Oct 2005 11:22:00 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592902015490@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Thread-Index: AcXS4xUlbAu8GFODTRehNFz2ArfQBgASqRQw From: "Blumenthal, Uri" To: "David T. Perkins" X-OriginalArrivalTime: 17 Oct 2005 15:22:55.0415 (UTC) FILETIME=[A5D60470:01C5D32E] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org SSH purpose (besides establishing a secure pipe) is to authenticate the user to the host (various mechanisms available) and to prove host's identity to the user (by host's PK). Since there may be more than one SNMP engine on one host, and they (conceivably) may have different "access rights" etc, ability to differentiate between them makes sense. This implies that different engines should have different public keys. Otherwise from security point of view only one SNMP engine will be allowed on one SSH host. An alternative: all the security will depend on "SSH layer" - something responsible for all the SSH communications of this host, and multiplexing traffic between various services that use SSH for protection. -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 Sent: Monday, October 17, 2005 2:22 AM To: Blumenthal, Uri Cc: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? HI, I don't follow. Would you fill in the details. Part of the reason that I don't follow is that I see no relationship between the SSH identifies and their keys and SNMP engineIDs. In USM, an identity is the pair (engineID (which is called the security engineID) and user name). SSH has no notion of SNMP engineIDs. On Sun, 16 Oct 2005, Blumenthal, Uri wrote: > David> #8: Do we need a mapping between the SSH key (or other SSH > David> engine identifier) and SNMP engineID? What happens if an > David> agent "spoofs" another engineID, and an NMS perfoms a SET > David> of sensitive parameters to the agent? >=20 > > I cannot answer this question because I don't have enough > > understanding of SNMP. I can answer a related question. > > > > You must authenticate each party back to some name the user provided. >=20 > IMHO there must be a mapping between ISMS-usable SSH keys and related > SNMP engine IDs. >=20 Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 11:41:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERX7G-0006Bk-N0; Mon, 17 Oct 2005 11:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERX7E-0006BW-MJ for isms@megatron.ietf.org; Mon, 17 Oct 2005 11:41:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19905 for ; Mon, 17 Oct 2005 11:41:25 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXIZ-0001dk-TQ for isms@ietf.org; Mon, 17 Oct 2005 11:53:17 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 17 Oct 2005 08:41:22 -0700 X-IronPort-AV: i="3.97,222,1125903600"; d="scan'208"; a="666696803:sNHT26280796" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HFfKub006269; Mon, 17 Oct 2005 08:41:20 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp244.cisco.com [10.61.64.244]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9HFppkC028788; Mon, 17 Oct 2005 08:51:52 -0700 Message-ID: <4353C61D.2050701@cisco.com> Date: Mon, 17 Oct 2005 17:41:17 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Kaushik Narayan (kaushik)" , dbharrington@comcast.net, isms@ietf.org Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire References: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> <20051017112919.GA23850@boskop.local> In-Reply-To: <20051017112919.GA23850@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1029; t=1129564313; x=1129996513; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20#2=3A=20is=20server=20authentication=20a=20requirement= 20that=20SNMP=09willrequire| From:Eliot=20Lear=20| Date:Mon,=2017=20Oct=202005=2017=3A41=3A17=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ftFxvjjsDKWXUFuMqp1PH71qUlxTYY4x8xX/eiBf5MgLyAKVn+VwprtT/rp9HXUKpaV6Y+H3 9kI+UusIj3tz76gSFKbbcCsw4BaVNi977lLNSFwy3LSR+CcV6GeQX1glwklBVWLznvnI2JHugqB QPBwyRU7XNRHw1o8ts9Ns7ro= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I largely agree with what Juergen says but I'd suggest that we should anticipate X.509 certs being available in SSH. Imagining this being the case, how does that change the situation wrt host keys? Eliot Juergen Schoenwaelder wrote: > Management applications at the very end also have a human being > involved. I don't see a reason why a management application can't do > the same as my ssh client does when you hit a box you have not talked > to before. Initiate a dialog with a human decision maker, open a > ticket in a trouble ticket system or whatever the app writer seeks > appropriate to get an OK to accept the key. This is all implementation > detail for me. > > The spec should just say somewhere (perhaps in the security > considerations section) that public host keys must be verified to > prevent mitm attacks and that applications should cache host keys and > warn about any changes. It is likely that all this text has already > been written and we can just refer to the appropriate section(s) in > the ssh documents. > > I think we should not even try to standardize a way to automatically > verify host keys. If there is a need for such a feature, I think the > ssh WG should work a general solution since this problem is not ISMS > specific. > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 13:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYTc-0002YF-Hp; Mon, 17 Oct 2005 13:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYTY-0002Y5-Sy for isms@megatron.ietf.org; Mon, 17 Oct 2005 13:08:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25005 for ; Mon, 17 Oct 2005 13:08:30 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYes-0004Kk-M8 for isms@ietf.org; Mon, 17 Oct 2005 13:20:24 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HH8Na28805; Mon, 17 Oct 2005 13:08:24 -0400 (EDT) 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] #2: is server authentication a requirement thatSNMP willrequire Date: Mon, 17 Oct 2005 13:08:23 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030BA2CD@zcarhxm2.corp.nortel.com> Thread-Topic: [Isms] #2: is server authentication a requirement thatSNMP willrequire Thread-Index: AcXTMVS1Gj9lIqHfQ32hVPvcDh5crAAC7kSA From: "Martin Soukup" To: "Eliot Lear" , "Kaushik Narayan \(kaushik\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I agree with Juergen and believe that the same case is true for X.509 (i.e. public keys must be trusted and the specification of caching/verifying keys is outside of scope for ISMS). Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Eliot Lear > Sent: October 17, 2005 11:41 AM > To: Kaushik Narayan (kaushik); dbharrington@comcast.net; isms@ietf.org > Subject: Re: [Isms] #2: is server authentication a requirement thatSNMP > willrequire >=20 > I largely agree with what Juergen says but I'd suggest that we should > anticipate X.509 certs being available in SSH. Imagining this being the > case, how does that change the situation wrt host keys? >=20 > Eliot >=20 >=20 > Juergen Schoenwaelder wrote: > > Management applications at the very end also have a human being > > involved. I don't see a reason why a management application can't do > > the same as my ssh client does when you hit a box you have not talked > > to before. Initiate a dialog with a human decision maker, open a > > ticket in a trouble ticket system or whatever the app writer seeks > > appropriate to get an OK to accept the key. This is all implementation > > detail for me. > > > > The spec should just say somewhere (perhaps in the security > > considerations section) that public host keys must be verified to > > prevent mitm attacks and that applications should cache host keys and > > warn about any changes. It is likely that all this text has already > > been written and we can just refer to the appropriate section(s) in > > the ssh documents. > > > > I think we should not even try to standardize a way to automatically > > verify host keys. If there is a need for such a feature, I think the > > ssh WG should work a general solution since this problem is not ISMS > > specific. > > > > /js > > >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 13:11:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYWO-0003Re-PU; Mon, 17 Oct 2005 13:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYWK-0003Jz-HJ for isms@megatron.ietf.org; Mon, 17 Oct 2005 13:11:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25191 for ; Mon, 17 Oct 2005 13:11:24 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYhf-0004Pr-Bq for isms@ietf.org; Mon, 17 Oct 2005 13:23:17 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9HH8h403060; Mon, 17 Oct 2005 13:08:43 -0400 (EDT) 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] #8: Do we need a mapping between the SSH key andSNMPengineID? Date: Mon, 17 Oct 2005 13:11:17 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030BA2CE@zcarhxm2.corp.nortel.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? Thread-Index: AcXS4xUlbAu8GFODTRehNFz2ArfQBgASqRQwAAPsCmA= From: "Martin Soukup" To: "Blumenthal, Uri" , "David T. Perkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I prefer that each engine has unique access control and thus a unique key since differing access control requires different identities which in turn requires multiple authentications/keys. Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Blumenthal, Uri > Sent: October 17, 2005 11:22 AM > To: David T. Perkins > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? >=20 > SSH purpose (besides establishing a secure pipe) is to authenticate the > user to the host (various mechanisms available) and to prove host's > identity to the user (by host's PK). >=20 > Since there may be more than one SNMP engine on one host, and they > (conceivably) may have different "access rights" etc, ability to > differentiate between them makes sense. >=20 > This implies that different engines should have different public keys. > Otherwise from security point of view only one SNMP engine will be > allowed on one SSH host. >=20 > An alternative: all the security will depend on "SSH layer" - something > responsible for all the SSH communications of this host, and > multiplexing traffic between various services that use SSH for > protection. >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, October 17, 2005 2:22 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? >=20 > HI, >=20 > I don't follow. Would you fill in the details. Part of the reason > that I don't follow is that I see no relationship between > the SSH identifies and their keys and SNMP engineIDs. > In USM, an identity is the pair (engineID (which is called > the security engineID) and user name). SSH has no notion > of SNMP engineIDs. >=20 > On Sun, 16 Oct 2005, Blumenthal, Uri wrote: >=20 > > David> #8: Do we need a mapping between the SSH key (or other SSH > > David> engine identifier) and SNMP engineID? What happens if an > > David> agent "spoofs" another engineID, and an NMS perfoms a SET > > David> of sensitive parameters to the agent? > > > > > I cannot answer this question because I don't have enough > > > understanding of SNMP. I can answer a related question. > > > > > > You must authenticate each party back to some name the user > provided. > > > > IMHO there must be a mapping between ISMS-usable SSH keys and related > > SNMP engine IDs. > > >=20 > Regards, > /david t. perkins >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 13:24:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYj7-000760-8d; Mon, 17 Oct 2005 13:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYj3-00075s-AZ for isms@megatron.ietf.org; Mon, 17 Oct 2005 13:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25857 for ; Mon, 17 Oct 2005 13:24:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYuP-0004kz-Dq for isms@ietf.org; Mon, 17 Oct 2005 13:36:26 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 10:24:29 -0700 X-IronPort-AV: i="3.97,222,1125903600"; d="scan'208"; a="353155922:sNHT1044058280" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HHNxuv007446; Mon, 17 Oct 2005 10:24:26 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 10:24:25 -0700 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] #2: is server authentication a requirement that SNMP willrequire Date: Mon, 17 Oct 2005 10:24:23 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99E77@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #2: is server authentication a requirement that SNMP willrequire Thread-Index: AcXTLQoBFNkuu0FnQK+wCnbQhZvN9gAESYnA From: "Kaushik Narayan \(kaushik\)" To: X-OriginalArrivalTime: 17 Oct 2005 17:24:25.0041 (UTC) FILETIME=[9ECAAC10:01C5D33F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Please find my reply inline. Management applications at the very end also have a human being involved. I don't see a reason why a management application can't do the same as my ssh client does when you hit a box you have not talked to before. Initiate a dialog with a human decision maker, open a ticket in a trouble ticket system or whatever the app writer seeks appropriate to get an OK to accept the key. This is all implementation detail for me. Although management applications have a human involved, the communication with the device might not happen in real time. Almost all changes to the network (configuration) and all collection (inventory, fault, performance) of data from the network happens at a time that is least disruptive to the network. Also there are cases wherein devices need to be pre-provisioned where the operator might not be in the loop when the sign-of-life shows up from the device. This does raise the requirement for the public keys being available to the NMS before communication to the device happens, this will have to be done manually for a start and X.509 certs support in SSH will reduce this administrative burden. Again these may well be seen outside the realm of SSHSM but I think we need to make sure that operators are aware of the administrative chores required to deploy SSHSM since deployment was a key barrier to entry for USM and a main reason why ISMS was created. Regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 14:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERa7k-0003Uz-O1; Mon, 17 Oct 2005 14:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERa7j-0003Tp-6Z for isms@megatron.ietf.org; Mon, 17 Oct 2005 14:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00888 for ; Mon, 17 Oct 2005 14:54:08 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERaJ7-00079u-13 for isms@ietf.org; Mon, 17 Oct 2005 15:06:01 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 11:54:05 -0700 X-IronPort-AV: i="3.97,222,1125903600"; d="scan'208"; a="353205052:sNHT46092076" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9HIrUK9014712; Mon, 17 Oct 2005 11:54:01 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 11:54:00 -0700 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] #8: Do we need a mapping between the SSH key andSNMPengineID? Date: Mon, 17 Oct 2005 11:53:59 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99F34@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? Thread-Index: AcXS4xUlbAu8GFODTRehNFz2ArfQBgASqRQwAASp3/A= From: "Kaushik Narayan \(kaushik\)" To: "Blumenthal, Uri" , "David T. Perkins" X-OriginalArrivalTime: 17 Oct 2005 18:54:00.0025 (UTC) FILETIME=[22882490:01C5D34C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think this is a very fundamental issue with the usage model of the underlying transport within Transport Mapped Security Model. The fact that the underlying transport channel would be created prior to any SNMP communication and will be between two hosts makes it difficult in case we have multiple SSH instances with different credentials for each SNMP engine, how does the client identify which SSH instance to authenticate to. The ability to authorize the user access to the SNMP engines can still be achieved via VACM =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri Sent: Monday, October 17, 2005 8:22 AM To: David T. Perkins Cc: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? SSH purpose (besides establishing a secure pipe) is to authenticate the user to the host (various mechanisms available) and to prove host's identity to the user (by host's PK). Since there may be more than one SNMP engine on one host, and they (conceivably) may have different "access rights" etc, ability to differentiate between them makes sense. This implies that different engines should have different public keys. Otherwise from security point of view only one SNMP engine will be allowed on one SSH host. An alternative: all the security will depend on "SSH layer" - something responsible for all the SSH communications of this host, and multiplexing traffic between various services that use SSH for protection. -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Monday, October 17, 2005 2:22 AM To: Blumenthal, Uri Cc: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? HI, I don't follow. Would you fill in the details. Part of the reason that I don't follow is that I see no relationship between the SSH identifies and their keys and SNMP engineIDs. In USM, an identity is the pair (engineID (which is called the security engineID) and user name). SSH has no notion of SNMP engineIDs. On Sun, 16 Oct 2005, Blumenthal, Uri wrote: > David> #8: Do we need a mapping between the SSH key (or other SSH > David> engine identifier) and SNMP engineID? What happens if an > David> agent "spoofs" another engineID, and an NMS perfoms a SET > David> of sensitive parameters to the agent? >=20 > > I cannot answer this question because I don't have enough=20 > > understanding of SNMP. I can answer a related question. > > > > You must authenticate each party back to some name the user provided. >=20 > IMHO there must be a mapping between ISMS-usable SSH keys and related=20 > SNMP engine IDs. >=20 Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 15:16:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERaSw-0008Cg-US; Mon, 17 Oct 2005 15:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERaSv-0008CS-7b for isms@megatron.ietf.org; Mon, 17 Oct 2005 15:16:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01970 for ; Mon, 17 Oct 2005 15:16:02 -0400 (EDT) Message-Id: <200510171916.PAA01970@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERaeI-0007fR-8L for isms@ietf.org; Mon, 17 Oct 2005 15:27:55 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <2005101719155701400l7ohie>; Mon, 17 Oct 2005 19:15:58 +0000 From: "David B Harrington" To: "'Kaushik Narayan \(kaushik\)'" , "'Blumenthal, Uri'" , "'David T. Perkins'" Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Date: Mon, 17 Oct 2005 15:15:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <618694EF0B657246A4D55A97E38274C3B99F34@xmb-sjc-22d.amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXS4xUlbAu8GFODTRehNFz2ArfQBgASqRQwAASp3/AAA4vC8A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, > The ability to authorize the user access to the SNMP engines can > still be achieved via VACM If you're saying what I'm reading, I disagree. VACM configuration is contained within an SNMP engine, so it cannot authorize user access to different SNMP engines. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik > Narayan (kaushik) > Sent: Monday, October 17, 2005 2:54 PM > To: Blumenthal, Uri; David T. Perkins > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > keyandSNMPengineID? > > > I think this is a very fundamental issue with the usage model of the > underlying transport within Transport Mapped Security Model. The fact > that the underlying transport channel would be created prior > to any SNMP > communication and will be between two hosts makes it difficult in case > we have multiple SSH instances with different credentials for > each SNMP > engine, how does the client identify which SSH instance to > authenticate > to. The ability to authorize the user access to the SNMP engines can > still be achieved via VACM > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Blumenthal, Uri > Sent: Monday, October 17, 2005 8:22 AM > To: David T. Perkins > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? > > SSH purpose (besides establishing a secure pipe) is to > authenticate the > user to the host (various mechanisms available) and to prove host's > identity to the user (by host's PK). > > Since there may be more than one SNMP engine on one host, and they > (conceivably) may have different "access rights" etc, ability to > differentiate between them makes sense. > > This implies that different engines should have different public keys. > Otherwise from security point of view only one SNMP engine will be > allowed on one SSH host. > > An alternative: all the security will depend on "SSH layer" - > something > responsible for all the SSH communications of this host, and > multiplexing traffic between various services that use SSH for > protection. > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, October 17, 2005 2:22 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? > > HI, > > I don't follow. Would you fill in the details. Part of the > reason that I > don't follow is that I see no relationship between the SSH identifies > and their keys and SNMP engineIDs. > In USM, an identity is the pair (engineID (which is called > the security > engineID) and user name). SSH has no notion of SNMP engineIDs. > > On Sun, 16 Oct 2005, Blumenthal, Uri wrote: > > > David> #8: Do we need a mapping between the SSH key (or > other SSH > > David> engine identifier) and SNMP engineID? What happens if an > > David> agent "spoofs" another engineID, and an NMS perfoms a SET > > David> of sensitive parameters to the agent? > > > > > I cannot answer this question because I don't have enough > > > understanding of SNMP. I can answer a related question. > > > > > > You must authenticate each party back to some name the user > provided. > > > > IMHO there must be a mapping between ISMS-usable SSH keys > and related > > SNMP engine IDs. > > > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 15:37:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERanE-0004Ie-6g; Mon, 17 Oct 2005 15:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERanC-0004IQ-Fc for isms@megatron.ietf.org; Mon, 17 Oct 2005 15:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02874 for ; Mon, 17 Oct 2005 15:36:59 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERayZ-0008Ad-Is for isms@ietf.org; Mon, 17 Oct 2005 15:48:53 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9HJauBT011206; Mon, 17 Oct 2005 12:36:56 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9HJanvH026008; Mon, 17 Oct 2005 12:36:49 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9HJamhU026001; Mon, 17 Oct 2005 12:36:49 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 17 Oct 2005 12:36:48 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Blumenthal, Uri" Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? In-Reply-To: <3DEC199BD7489643817ECA151F7C592902015490@pysmsx401.amr.corp.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Let's take a step and look at this with a view that includes support for proxies, and compare with USM. Reviewing: 1) management info (from RFC 3411, section 3.3) is identified by items: a) an engineID (which needs to be unique only within a a management domain). In SNMPv3 requests, this is the value of field contextEngineID b) context value, which in SNMPv3 requests is the value of field contextName. c) object type (an OID value), which is the prefix of each variable (a variable is an OID value) (see RFC 3416, section 2.1) d) object index (an OID fragment), which is the suffix of each variable 2) the value of field contextEngineID determines if a request is to be processed "locally" by the SNMP entity that recieved it or forwarded to another SNMP entity for processing. (from RFC 3413, section 1.5) 3) In SSH, a server is identified by a transport address (SSH experts jump in if I've used the incorrect terminology) and is authenticated via use of a public key pair (RSA or DSA). (from draft-ietf-secsh-transport-24.txt and draft-ietf-secsh-architecture-22.txt) 4) In SSH, a client is identified by a "user name" (from draft-ietf-secsh-userauth-27.txt, section 5) and is authenticated via a mechanism identified by a "method name". The typical ones are "publickey" and "password" (see draft-ietf-secsh-assignednumbers-12.txt, section 4.8) 5) There is presently, no standard "interchange" format that is used by "SNMP management apps" to map between "SNMP agent's" transport address and an SNMP engineID. 6) In SNMPv3/USM, identities are specified by the pair engineID and user name. (RFC 3414, section 1.5.2) In SNMPv3/USM message exchange, the field msgSecurityParameters in SNMPv3 messages is encoded with the format as specified by UsmSecurityParameters (RFC 3414, section 2.4) USM specifies which SNMP engineID is to be used in message exchange between the two SNMP entities with the two different engineIDs. What it appears that you are proposing is to make the public key (or maybe just the "finger print" of the public key) from an SSH server's key pair, an identity. (FYI, a finger print is a MD5 hash of the public key, and is 16 octets long) This seems incorrect/problematic due to: 1) the key pair used to verify an SSH server can be changed without changing the identity of the server 2) there is no infrastructure for starting from a public key (or finger print) and mapping to a transport address. Note that I agree with you that just like SNMPv3/USM, that in SNMPv3/ISMS when there are multiple SNMP entities running on a system that each must use a unique transport address. And the SNMP engineID that each is using should be different. Also note that I pointed out several times in the past that when an SNMP entity is running certain "SNMP applications" (such as a command generator (that is an SNMP management application)) that the value of the engineID is NOT made known via SNMP operations, and thus NEVER needs to be created! This works out well in use of SSH when the SSH client is a command generator and the SSH server is a command responder. If one gets strict and believes that a command generator must have an engineID, then please remember in an SSH world, the client side is identified by a user name and method specific credentials which may not be a public key. Hope this helps. On Mon, 17 Oct 2005, Blumenthal, Uri wrote: > SSH purpose (besides establishing a secure pipe) is to authenticate the > user to the host (various mechanisms available) and to prove host's > identity to the user (by host's PK). > > Since there may be more than one SNMP engine on one host, and they > (conceivably) may have different "access rights" etc, ability to > differentiate between them makes sense. > > This implies that different engines should have different public keys. > Otherwise from security point of view only one SNMP engine will be > allowed on one SSH host. > > An alternative: all the security will depend on "SSH layer" - something > responsible for all the SSH communications of this host, and > multiplexing traffic between various services that use SSH for > protection. > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, October 17, 2005 2:22 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? > > HI, > > I don't follow. Would you fill in the details. Part of the reason > that I don't follow is that I see no relationship between > the SSH identifies and their keys and SNMP engineIDs. > In USM, an identity is the pair (engineID (which is called > the security engineID) and user name). SSH has no notion > of SNMP engineIDs. > > On Sun, 16 Oct 2005, Blumenthal, Uri wrote: > > > David> #8: Do we need a mapping between the SSH key (or other SSH > > David> engine identifier) and SNMP engineID? What happens if an > > David> agent "spoofs" another engineID, and an NMS perfoms a SET > > David> of sensitive parameters to the agent? > > > > > I cannot answer this question because I don't have enough > > > understanding of SNMP. I can answer a related question. > > > > > > You must authenticate each party back to some name the user > provided. > > > > IMHO there must be a mapping between ISMS-usable SSH keys and related > > SNMP engine IDs. > > > > Regards, > /david t. perkins Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 17:12:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcHO-0007fo-Cj; Mon, 17 Oct 2005 17:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcHM-0007ee-MV for isms@megatron.ietf.org; Mon, 17 Oct 2005 17:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06094 for ; Mon, 17 Oct 2005 17:12:13 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERcSk-0003uP-Hp for isms@ietf.org; Mon, 17 Oct 2005 17:24:08 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2005 14:12:10 -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.12.10/8.12.6) with ESMTP id j9HLBLKL023281; Mon, 17 Oct 2005 14:12:07 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 14:12:06 -0700 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] #8: Do we need a mapping between the SSH keyandSNMPengineID? Date: Mon, 17 Oct 2005 14:12:04 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3B99FFB@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Thread-Index: AcXS4xUlbAu8GFODTRehNFz2ArfQBgASqRQwAASp3/AAA4vC8AACwZ8g From: "Kaushik Narayan \(kaushik\)" To: , "Blumenthal, Uri" , "David T. Perkins" X-OriginalArrivalTime: 17 Oct 2005 21:12:06.0379 (UTC) FILETIME=[6D956BB0:01C5D35F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I was only trying to suggest that VACM will provide ability to authorize users to management information served by the various SNMP engines, I agree that my previous statement was not clear about that. Regards, kaushik! -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, October 17, 2005 12:16 PM To: Kaushik Narayan (kaushik); 'Blumenthal, Uri'; 'David T. Perkins' Cc: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Hi, > The ability to authorize the user access to the SNMP engines can still > be achieved via VACM If you're saying what I'm reading, I disagree. VACM configuration is contained within an SNMP engine, so it cannot authorize user access to different SNMP engines. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan=20 > (kaushik) > Sent: Monday, October 17, 2005 2:54 PM > To: Blumenthal, Uri; David T. Perkins > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH=20 > keyandSNMPengineID? >=20 >=20 > I think this is a very fundamental issue with the usage model of the=20 > underlying transport within Transport Mapped Security Model. The fact > that the underlying transport channel would be created prior to any=20 > SNMP communication and will be between two hosts makes it difficult in case > we have multiple SSH instances with different credentials for each=20 > SNMP engine, how does the client identify which SSH instance to=20 > authenticate to. The ability to authorize the user access to the SNMP=20 > engines can still be achieved via VACM > =20 >=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Blumenthal, Uri > Sent: Monday, October 17, 2005 8:22 AM > To: David T. Perkins > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? >=20 > SSH purpose (besides establishing a secure pipe) is to=20 > authenticate the > user to the host (various mechanisms available) and to prove host's > identity to the user (by host's PK). >=20 > Since there may be more than one SNMP engine on one host, and they > (conceivably) may have different "access rights" etc, ability to > differentiate between them makes sense. >=20 > This implies that different engines should have different public keys. > Otherwise from security point of view only one SNMP engine will be > allowed on one SSH host. >=20 > An alternative: all the security will depend on "SSH layer" -=20 > something > responsible for all the SSH communications of this host, and > multiplexing traffic between various services that use SSH for > protection. >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, October 17, 2005 2:22 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? >=20 > HI, >=20 > I don't follow. Would you fill in the details. Part of the=20 > reason that I > don't follow is that I see no relationship between the SSH identifies > and their keys and SNMP engineIDs. > In USM, an identity is the pair (engineID (which is called=20 > the security > engineID) and user name). SSH has no notion of SNMP engineIDs. >=20 > On Sun, 16 Oct 2005, Blumenthal, Uri wrote: >=20 > > David> #8: Do we need a mapping between the SSH key (or=20 > other SSH > > David> engine identifier) and SNMP engineID? What happens if an > > David> agent "spoofs" another engineID, and an NMS perfoms a SET > > David> of sensitive parameters to the agent? > >=20 > > > I cannot answer this question because I don't have enough=20 > > > understanding of SNMP. I can answer a related question. > > > > > > You must authenticate each party back to some name the user > provided. > >=20 > > IMHO there must be a mapping between ISMS-usable SSH keys=20 > and related=20 > > SNMP engine IDs. > >=20 >=20 > Regards, > /david t. perkins >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 17:39:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcht-0001VG-Ac; Mon, 17 Oct 2005 17:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERchs-0001V1-MC for isms@megatron.ietf.org; Mon, 17 Oct 2005 17:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08418 for ; Mon, 17 Oct 2005 17:39:36 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERctH-0004ty-IW for isms@ietf.org; Mon, 17 Oct 2005 17:51:32 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr001.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 j9HLdYld028092; Mon, 17 Oct 2005 21:39:34 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 j9HLdIRO020924; Mon, 17 Oct 2005 21:39:34 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101714393405015 ; Mon, 17 Oct 2005 14:39:34 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 14:39:34 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 14:39:34 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 17:39:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Date: Mon, 17 Oct 2005 17:38:34 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290204C8DB@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Thread-Index: AcXTUjbWXSmp/tBEQ1iUjEp/2DGh3QAC55Xw From: "Blumenthal, Uri" To: "David T. Perkins" X-OriginalArrivalTime: 17 Oct 2005 21:39:32.0444 (UTC) FILETIME=[42B701C0:01C5D363] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org First, it is a good practice for any discernable entity to have unique cryptographic material (keys). Second, if SNMP manager is OK with ascertaining only the host to where it directs its commands - then no need for separate keys. If however the manager wants to make sure that he talks with a certain *agent* - must have separate keys. > Reviewing:................... > 3) In SSH, a server is identified by a transport address > (SSH experts jump in if I've used the incorrect terminology) > and is authenticated via use of a public key pair (RSA or DSA). > (from draft-ietf-secsh-transport-24.txt and > draft-ietf-secsh-architecture-22.txt) Because SSH protocol and implementation offers access to a *host*, not to any one particular application running on that host. It may or may not be OK for SNMP.=20 > 5) There is presently, no standard "interchange" format that is > used by "SNMP management apps" to map between "SNMP > agent's" transport address and an SNMP engineID. =20 Of course, especially since this mapping is not a bijection (more than one agent on one host or IP address). > 6) In SNMPv3/USM, identities are specified by the > pair engineID and user name. (RFC 3414, section 1.5.2) > In SNMPv3/USM message exchange, the field > msgSecurityParameters in SNMPv3 messages is > encoded with the format as specified by=20 > UsmSecurityParameters (RFC 3414, section 2.4) > USM specifies which SNMP engineID is to be > used in message exchange between the two > SNMP entities with the two different engineIDs.=20 In USM, SNMP engines don't have their own credentials and thus only user identity truly matters. Engine ID is used in USM cryptography mostly for key localization. Agent authentication is implicit (if the key localized to a given agent works - then it must be the correct agent). SSH protocol requires defined credentials on both ends: user has his credentials, and the host has its key. > What it appears that you are proposing is to make the > public key (or maybe just the "finger print" of the > public key) from an SSH server's key pair, an identity. No. I am suggesting that if there's a need to differentiate between one SNMP-SSH agent and other SSH "entities" on a target host - it implies the need for SNMP-SSH agent to have its own public key pair, as if it was a separate "host". And whatever the identity of SNMP "agent" is - it would have to be bound to the public key used to ascertain its identity. Nowhere did I imply (nor said) that the key itself (or its fingerprint) should be used as/for identity (nor do I really care). > (FYI, a finger print is a MD5 hash of the public key, and > is 16 octets long) Wow! Thanks for letting me know. :-) > This seems incorrect/problematic due to: > 1) the key pair used to verify an SSH server can be > changed without changing the identity of the server > 2) there is no infrastructure for starting from > a public key (or finger print) and mapping > to a transport address. What seems problematic to me is that people hope to use existing SSH installations (one key pair per host), without providing extra keys and mechanisms to deal with them.=20 > Note that I agree with you that just like SNMPv3/USM, > that in SNMPv3/ISMS when there are multiple SNMP entities > running on a system that each must use a unique transport > address. And the SNMP engineID that each is using > should be different. Difference of engine ID necessarily implies difference in keying material it uses. > Also note that I pointed out several times in the > past that when an SNMP entity is running certain > "SNMP applications" (such as a command generator (that is > an SNMP management application)) that the value of the > engineID is NOT made known via SNMP operations, and thus > NEVER needs to be created! > This works out well in use of SSH when the SSH client > is a command generator and the SSH server is a command > responder.=20 Yes, but my concern is SNMP application(s) like command RESPONDER. > If one gets strict and believes that a command > generator must have an engineID, then please remember > in an SSH world, the client side is identified > by a user name and method specific credentials > which may not be a public key. Command generator probably does need an engine ID - but let's confine ourselves to the server case for now. How do you plan to authenticate an ISMS SNMP agent? > Hope this helps. Sorry - not much. On Mon, 17 Oct 2005, Blumenthal, Uri wrote: > SSH purpose (besides establishing a secure pipe) is to authenticate the > user to the host (various mechanisms available) and to prove host's > identity to the user (by host's PK). >=20 > Since there may be more than one SNMP engine on one host, and they > (conceivably) may have different "access rights" etc, ability to > differentiate between them makes sense. >=20 > This implies that different engines should have different public keys. > Otherwise from security point of view only one SNMP engine will be > allowed on one SSH host. >=20 > An alternative: all the security will depend on "SSH layer" - something > responsible for all the SSH communications of this host, and > multiplexing traffic between various services that use SSH for > protection. >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 > Sent: Monday, October 17, 2005 2:22 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? >=20 > HI, >=20 > I don't follow. Would you fill in the details. Part of the reason > that I don't follow is that I see no relationship between > the SSH identifies and their keys and SNMP engineIDs. > In USM, an identity is the pair (engineID (which is called > the security engineID) and user name). SSH has no notion > of SNMP engineIDs. >=20 > On Sun, 16 Oct 2005, Blumenthal, Uri wrote: >=20 > > David> #8: Do we need a mapping between the SSH key (or other SSH > > David> engine identifier) and SNMP engineID? What happens if an > > David> agent "spoofs" another engineID, and an NMS perfoms a SET > > David> of sensitive parameters to the agent? > >=20 > > > I cannot answer this question because I don't have enough > > > understanding of SNMP. I can answer a related question. > > > > > > You must authenticate each party back to some name the user > provided. > >=20 > > IMHO there must be a mapping between ISMS-usable SSH keys and related > > SNMP engine IDs. > >=20 >=20 > Regards, > /david t. perkins Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 17:41:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERck3-0002bK-0O; Mon, 17 Oct 2005 17:41:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERck1-0002bF-Hw for isms@megatron.ietf.org; Mon, 17 Oct 2005 17:41:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08578 for ; Mon, 17 Oct 2005 17:41:49 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERcvP-0004y1-FO for isms@ietf.org; Mon, 17 Oct 2005 17:53:45 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9HLfTpN014445; Mon, 17 Oct 2005 14:41:29 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <4ZTDADHF>; Mon, 17 Oct 2005 14:42:39 -0700 Message-ID: From: "McDonald, Ira" To: "'Kaushik Narayan (kaushik)'" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] #2: is server authentication a requirement that SNMP w illrequire Date: Mon, 17 Oct 2005 14:42:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Rather than passing around X.509 certificates (which are large), many mobile protocols are passing around the _hashes_ of X.509 certificates (sometimes just for the second through nth session between the same two endpoints - makes session restart faster). Does SSH have session restart similar to TLS? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Kaushik Narayan (kaushik) > Sent: Monday, October 17, 2005 1:24 PM > To: j.schoenwaelder@iu-bremen.de > Cc: dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] #2: is server authentication a > requirement that SNMP > willrequire > > > Hi Juergen, > > Please find my reply inline. > > > > Management applications at the very end also have a human being > involved. I don't see a reason why a management application > can't do the > same as my ssh client does when you hit a box you have not talked to > before. Initiate a dialog with a human decision maker, open a > ticket in > a trouble ticket system or whatever the app writer seeks > appropriate to > get an OK to accept the key. This is all implementation detail for me. > > > > > Although management applications have a human involved, the > communication with the device might not happen in real time. > Almost all > changes to the network (configuration) and all collection (inventory, > fault, performance) of data from the network happens at a time that is > least disruptive to the network. Also there are cases wherein devices > need to be pre-provisioned where the operator might not be in the loop > when the sign-of-life shows up from the device. > > This does raise the requirement for the public keys being available to > the NMS before communication to the device happens, this will > have to be > done manually for a start and X.509 certs support in SSH will reduce > this administrative burden. Again these may well be seen outside the > realm of SSHSM but I think we need to make sure that > operators are aware > of the administrative chores required to deploy SSHSM since deployment > was a key barrier to entry for USM and a main reason why ISMS was > created. > > Regards, > kaushik! > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 17:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcoe-0005La-PL; Mon, 17 Oct 2005 17:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcoZ-0005L7-5P for isms@megatron.ietf.org; Mon, 17 Oct 2005 17:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08853 for ; Mon, 17 Oct 2005 17:46:31 -0400 (EDT) Message-Id: <200510172146.RAA08853@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERczy-00055k-8B for isms@ietf.org; Mon, 17 Oct 2005 17:58:26 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <2005101721462301400khicke>; Mon, 17 Oct 2005 21:46:24 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? Date: Mon, 17 Oct 2005 17:46:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXTZDL7sCrbB4e6SV+tokG7OBZ8Lw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I would like to remind people that there is a distinction between the use of contextEngineID and the use of securityEngineID. As Juergen pointed out, there is the "information authoritative" engine and the "key authoritative" engine (plus "clock authoritative" and "access control authoritative"). The distinctions can be important to this question. SSH key in this question really means "authenticated SSH server identity". So this question really has three interpretations: Do we need a mapping between the SSH server identity and securityEngineID? Do we need a mapping between the SSH server identity and contextEngineID? Do we need a mapping between the SSH server identity and snmpEngineID? Regarding securityEngineID: USM doesn't explicitly authenticate the engineID, but it does authenticate the securityEngineID implicitly via the clock check (weakly) and the localized keys. So there is the question of whether there should be a mapping between the authentication of the SSH server and the associated SNMP engine, to replace the implicit authentication provided by localized keys. However, to send the message containing the spoofed engineID, the engine will need to establish a tunnel using SSH authentication, so I personally believe that such a spoofing attack is not a concern. Regarding contextEngineID authentication: USM, the current instantiation of SNMPv3 security, does not authenticate the contextEngineID passed in a message. In fact, USM really doesn't process the PDU portion of a message except to encrypt/decrypt it. But when processing is to be done locally, the contextEngineID equals the snmpEngineID managed object, and when the local engine will be information-authoritative (i.e. in a response message), the elements of procedure include checking whether the securityEngineID matches the local snmpEngineID during message processing. This check strikes me as an implicit binding between the securityEngineID and the "information-authoritative" engine (the local contextEngineID). This raises the question of whether there should be a binding between the authenticated SSH server identity and the information-authoritative engine (assuming the SSH server is always on the information-authoritative side). Regarding contextEngineID multiple registrations: RFC3412 allows multiple contextEngineIDs to be registered with the dispatcher. From RFC3412: "Note: Implementations may provide a means of requesting registration for simultaneous multiple contextEngineID values, e.g., all contextEngineID values, ...". This apparently would enable a single SSH server to provide security for multiple contextEngines. The SNMP dispatcher would handle the multiplexing of contextEngines (note this only applies to contextEngines, not securityEngines). [Note that RFC3411 seems to disagree with RFC3412 on whether a single SNMP entity can have multiple engineIDs - "Since there is a one-to- one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain." ] [Note that in a previous message I said one VACM instantiation could not apply to multiple engines; I was obviously incorrect in that assertion.] [Note that using multiple contextEngineIDs might be problematic, when checking whether securityEngineID matches snmpEngineID, since snmpEngineID should match the contextEngineID when processing is local.] But multiple registrations is only one way engine multiplexing can be accomplished. A single SSH server could support multiple engines (securityEngineIDs or contextEngineIDs) by having them use different ports. In this case, SSH would effectively be handling the multiplexing of engines. Looked at from the other direction, SNMP currently has no mechanism for multiplexing SSH servers, and has no parameter in the ASIs to allow an application to select which server to use (or which host key, etc.) for an outgoing message. If there was a binding between the securityEngineID and the SSH server (or the host key), established in advance or when the session was established, then when an application specified the securityEngineID, it would be apparent (to the SSHSM) which SSH server (or host key) to use. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 18:12:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdDN-0006YV-OD; Mon, 17 Oct 2005 18:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdDM-0006Rd-6R for isms@megatron.ietf.org; Mon, 17 Oct 2005 18:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10112 for ; Mon, 17 Oct 2005 18:12:08 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdOk-0005h0-SY for isms@ietf.org; Mon, 17 Oct 2005 18:24:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 04848E0038; Mon, 17 Oct 2005 18:12:15 -0400 (EDT) To: "McDonald, Ira" References: From: Sam Hartman Date: Mon, 17 Oct 2005 18:12:15 -0400 In-Reply-To: (Ira McDonald's message of "Mon, 17 Oct 2005 14:42:38 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: isms@ietf.org, dbharrington@comcast.net Subject: [Isms] ssh session restart 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "McDonald," == McDonald, Ira writes: McDonald,> Does SSH have session restart similar to TLS? No. ssh session setup always includes a DH exchange and a signing for the currently defined key exchange types. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 18:18:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdJ6-00005w-J1; Mon, 17 Oct 2005 18:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdJ4-00005r-Vl for isms@megatron.ietf.org; Mon, 17 Oct 2005 18:18:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10393 for ; Mon, 17 Oct 2005 18:18:03 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdUU-0005qH-Od for isms@ietf.org; Mon, 17 Oct 2005 18:29:58 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A1C8FE0038; Mon, 17 Oct 2005 18:18:09 -0400 (EDT) To: "Blumenthal, Uri" Subject: Re: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? References: <3DEC199BD7489643817ECA151F7C592902015490@pysmsx401.amr.corp.intel.com> From: Sam Hartman Date: Mon, 17 Oct 2005 18:18:09 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C592902015490@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Mon, 17 Oct 2005 11:22:00 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Blumenthal," == Blumenthal, Uri writes: Blumenthal,> This implies that different engines should have Blumenthal,> different public keys. Otherwise from security point Blumenthal,> of view only one SNMP engine will be allowed on one Blumenthal,> SSH host. I don't follow because as you point out: Blumenthal,> An alternative: all the security will depend on "SSH Blumenthal,> layer" - something responsible for all the SSH Blumenthal,> communications of this host, and multiplexing traffic Blumenthal,> between various services that use SSH for protection. right. In this model, you need a name to address PDUs to the snmp engines, but the security binding is handled at the ssh layer. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 17 18:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdK3-0000GQ-Bq; Mon, 17 Oct 2005 18:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdK1-0000GE-PW for isms@megatron.ietf.org; Mon, 17 Oct 2005 18:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10440 for ; Mon, 17 Oct 2005 18:19:01 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdVR-0005ry-E8 for isms@ietf.org; Mon, 17 Oct 2005 18:30:57 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6DE1FE0038; Mon, 17 Oct 2005 18:19:14 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire References: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> <20051017112919.GA23850@boskop.local> <4353C61D.2050701@cisco.com> From: Sam Hartman Date: Mon, 17 Oct 2005 18:19:14 -0400 In-Reply-To: <4353C61D.2050701@cisco.com> (Eliot Lear's message of "Mon, 17 Oct 2005 17:41:17 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> I largely agree with what Juergen says but I'd suggest that Eliot> we should anticipate X.509 certs being available in SSH. Eliot> Imagining this being the case, how does that change the Eliot> situation wrt host keys? I'd advise against assuming there will be a big push for ssh x.509 certs. It probably will be standardized; some people will probably implement it. However one of the major attractive features of ssh is that it does not use x.509. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 00:02:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERigP-0003i6-Qq; Tue, 18 Oct 2005 00:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERigN-0003hw-W0 for isms@megatron.ietf.org; Tue, 18 Oct 2005 00:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00253 for ; Tue, 18 Oct 2005 00:02:27 -0400 (EDT) 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.43) id 1ERirp-00078W-MZ for isms@ietf.org; Tue, 18 Oct 2005 00:14:26 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 5087111D6F6; Mon, 17 Oct 2005 21:02:20 -0700 (PDT) From: Wes Hardaker To: dbharrington@comcast.net Subject: Re: [Isms] #1: is it important to support anonymous user access to SNMP? Organization: Sparta References: <200510132123.RAA18692@ietf.org> Date: Mon, 17 Oct 2005 21:02:19 -0700 In-Reply-To: <200510132123.RAA18692@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 17:23:31 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 13 Oct 2005 17:23:31 -0400, "David B Harrington" said: >> From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange David> that is authenticated and even private when the session initiator or David> responder is anonymous." David> This is a new feature provided by SBSM. Can we establish consensus David> that a) this is needed or b) this is not needed? I think it would be nice to have but is not "needed". -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 00:05:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERijE-0004Od-9g; Tue, 18 Oct 2005 00:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERijD-0004OY-KL for isms@megatron.ietf.org; Tue, 18 Oct 2005 00:05:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00398 for ; Tue, 18 Oct 2005 00:05:23 -0400 (EDT) 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.43) id 1ERiug-0007Cf-CK for isms@ietf.org; Tue, 18 Oct 2005 00:17:22 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id BA08311D6F6; Mon, 17 Oct 2005 21:05:27 -0700 (PDT) From: Wes Hardaker To: dbharrington@comcast.net Subject: Re: [Isms] #33: does the mib need to be writable? Organization: Sparta References: <200510132210.SAA21186@ietf.org> Date: Mon, 17 Oct 2005 21:05:27 -0700 In-Reply-To: <200510132210.SAA21186@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 18:10:18 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 13 Oct 2005 18:10:18 -0400, "David B Harrington" said: David> #33: does the mib need to be writable, so sessions can be David> preconfigured, such as for callhome, or would it be populated David> at creation time by the underlying instrumentation, and not David> writable by SNMP? >From a SNMP strictness point of view, I'd suspect what you really mean there is can rows be added and should the rows be read-create. I suspect you will want things to be writable, even if creation isn't allowed, to add support for tearing down of a session regardless of whether or not the insertion was automatic or manual. That being said, I don't mind a creatable set of rows if it provides some benefit. But I don't think implementations need a MUST for support... I'd like the conformance statement to indicate that row-creation isn't required. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 00:18:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERirm-00074T-9d; Tue, 18 Oct 2005 00:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERirj-00074K-46 for isms@megatron.ietf.org; Tue, 18 Oct 2005 00:14:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00950 for ; Tue, 18 Oct 2005 00:14:11 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERj3B-0007TA-UM for isms@ietf.org; Tue, 18 Oct 2005 00:26:10 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2005 21:14:09 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9I4E7Jh019678; Mon, 17 Oct 2005 21:14:07 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp85.cisco.com [10.61.64.85]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9I4OYRv002526; Mon, 17 Oct 2005 21:24:36 -0700 Message-ID: <4354768A.3020808@cisco.com> Date: Tue, 18 Oct 2005 06:14:02 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire References: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> <20051017112919.GA23850@boskop.local> <4353C61D.2050701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=619; t=1129609477; x=1130041677; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20#2=3A=20is=20server=20authentication=20a=20requirement= 20that=20SNMP=09willrequire| From:Eliot=20Lear=20| Date:Tue,=2018=20Oct=202005=2006=3A14=3A02=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=IxF56b16MoSQBWrCtUoQSi4yoYFdhBtyx15Q0Xj1l8BcZvUN4VM7Wi9aumHJPYJqaqUHJSe0 u2Norytzn/ySV4Hh7HobDn0TPE5OqBHmyYkF54giIvTd1MxaolR4oRrvh2bYtHoneicykr8nnlv Rhz0/esnRATFS6T1Xt57mFRs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman wrote: > I'd advise against assuming there will be a big push for ssh x.509 > certs. It probably will be standardized; some people will probably > implement it. However one of the major attractive features of ssh is > that it does not use x.509. Sam, what you see as attractive is also a scaling limitation. It's easy for us to ship a core set of PCA certs in a device. Think about this way. My aunt goes to her local supermarket to buy a new set top box that she wants to use with her service provider, who will give her a username and a password. You want her to be sure that her device authenticates the configuration server. How is she supposed to verify that the host key is the right one? This is why it's important for X.509 certs to be done. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 08:26:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqYI-0005oj-QR; Tue, 18 Oct 2005 08:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqYG-0005ob-HY for isms@megatron.ietf.org; Tue, 18 Oct 2005 08:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26379 for ; Tue, 18 Oct 2005 08:26:35 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqjm-0003YJ-AB for isms@ietf.org; Tue, 18 Oct 2005 08:38:39 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 531504BF4C; Tue, 18 Oct 2005 14:26:32 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19160-04; Tue, 18 Oct 2005 14:26:31 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9B35C4C00E; Tue, 18 Oct 2005 14:26:29 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id CF2A24D293F; Tue, 18 Oct 2005 14:26:29 +0200 (CEST) Date: Tue, 18 Oct 2005 14:26:29 +0200 From: Juergen Schoenwaelder To: "Kaushik Narayan (kaushik)" Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire Message-ID: <20051018122629.GA17066@boskop.local> Mail-Followup-To: "Kaushik Narayan (kaushik)" , dbharrington@comcast.net, isms@ietf.org References: <618694EF0B657246A4D55A97E38274C3B99E77@xmb-sjc-22d.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C3B99E77@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Oct 17, 2005 at 10:24:23AM -0700, Kaushik Narayan (kaushik) wrote: > Although management applications have a human involved, the > communication with the device might not happen in real time. Almost all > changes to the network (configuration) and all collection (inventory, > fault, performance) of data from the network happens at a time that is > least disruptive to the network. Also there are cases wherein devices > need to be pre-provisioned where the operator might not be in the loop > when the sign-of-life shows up from the device. > > This does raise the requirement for the public keys being available to > the NMS before communication to the device happens, this will have to be > done manually for a start and X.509 certs support in SSH will reduce > this administrative burden. Again these may well be seen outside the > realm of SSHSM but I think we need to make sure that operators are aware > of the administrative chores required to deploy SSHSM since deployment > was a key barrier to entry for USM and a main reason why ISMS was > created. My primary goal is to enable secure SNMP in with zero additional costs in environments where operators already use ssh as a means to securely transport device configurations. I am happy with any concrete proposal which makes ISMS work in a broader context as long as it does not make reaching my primary goal stated above more difficult. So please write up what you think needs to be changed in the IDs to support X.509 certs and then lets look at the cost/benefit ratio. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 10:06:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERs7C-0007vm-Ti; Tue, 18 Oct 2005 10:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERs79-0007vS-RO for isms@megatron.ietf.org; Tue, 18 Oct 2005 10:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02309 for ; Tue, 18 Oct 2005 10:06:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsIg-0006Nk-S6 for isms@ietf.org; Tue, 18 Oct 2005 10:18:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 29766E0038; Tue, 18 Oct 2005 10:06:44 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] #2: is server authentication a requirement that SNMP willrequire References: <618694EF0B657246A4D55A97E38274C3B99972@xmb-sjc-22d.amer.cisco.com> <20051017112919.GA23850@boskop.local> <4353C61D.2050701@cisco.com> <4354768A.3020808@cisco.com> From: Sam Hartman Date: Tue, 18 Oct 2005 10:06:44 -0400 In-Reply-To: <4354768A.3020808@cisco.com> (Eliot Lear's message of "Tue, 18 Oct 2005 06:14:02 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam Hartman wrote: Eliot> Sam, what you see as attractive is also a scaling Eliot> limitation. I don't see it as attractive. Our community of users--the people who use our protocols--see it as attractive. I find it really annoying. I mostly avoided ssh until the gssapi support became stable basically for the reasons you describe. Eliot> It's easy for us to ship a core set of PCA Eliot> certs in a device. Think about this way. My aunt goes to Eliot> her local supermarket to buy a new set top box that she Eliot> wants to use with her service provider, who will give her a Eliot> username and a password. You want her to be sure that her Eliot> device authenticates the configuration server. How is she Eliot> supposed to verify that the host key is the right one? First, leap of faith (trust the first hostkey you get) probably would be sufficient for this situation. Second, I do understand the value of PKI. I understand that in some environments it will be used. ISMS needs to support that. But the charter goal of ISMS is to work with authentication people use today. Today, people do not use X.509 with ssh. No matter how much you, I or anyone else wants them to, it simply is not what people currently do. So, while ISMS should support it, and while you can (and should when appropriate) sell products that rely on it, it cannot be our primary focus. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 12:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuhN-00048H-Ds; Tue, 18 Oct 2005 12:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuhK-00045E-Qp for isms@megatron.ietf.org; Tue, 18 Oct 2005 12:52:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14074 for ; Tue, 18 Oct 2005 12:52:14 -0400 (EDT) Message-Id: <200510181652.MAA14074@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERuss-0003GM-WC for isms@ietf.org; Tue, 18 Oct 2005 13:04:20 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc13) with SMTP id <2005101816520701500igmf5e>; Tue, 18 Oct 2005 16:52:07 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #8: Do we need a mapping between the SSH key andSNMPengineID? Date: Tue, 18 Oct 2005 12:52:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <002b01c5d2fd$12765170$2d646e0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXS/O0EZR9/ozSERnqbpYSJisZTMQA+gPdw X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Maio, snmpEngineID should not be dynamically generated; that would defeat the whole purpose of having an engineID - to uniquely and unambiguously identify an engine within an administrative domain. An engine may have multiple addresses, and its addresses may change over time. But the snmpEngineID provides a consistent managed object to identify the virtual database of which it is part. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Monday, October 17, 2005 5:28 AM > To: 'Kaushik Narayan (kaushik)'; dbharrington@comcast.net; > isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > key andSNMPengineID? > > > SSH transport is different from TCP tranport for SNMP. SSHSM > starts a SNMP > agent as subsystem of SSH server contrasting to TCP as forked > child process, > it means each subsytem is independent to each other. Will > they share same > snmpEngineID, just like in UDP or TCP transporting? In other > word, do all > subsystems started by a SSH server are same SNMP entity? > > If not, I believe snmpEngineID must be allocated dynamicaly > enough. In such > case mapping SSH key and snmpEngineID is difficult. > > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Kaushik Narayan (kaushik) > Sent: Saturday, October 15, 2005 12:10 AM > To: dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? > > > > > > I think we should consider using/mapping the identity of the > SNMP engine to > the SNMP engine ID, this will be particularly useful when you > have multiple > SNMP engines on the same host (single SSH server). I am not > quite sure about > the spoofing issue since that should be taken care by server (agent) > authentication by the SSH transport protocol. > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David B Harrington > Sent: Thursday, October 13, 2005 2:51 PM > To: isms@ietf.org > Subject: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? > > #8: Do we need a mapping between the SSH key (or other SSH engine > identifier) and SNMP engineID? What happens if an agent > "spoofs" another > engineID, and an NMS perfoms a SET of sensitive parameters to > the agent? > > > > > > David Harrington > dbharrington@comcast.net > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 12:53:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuiQ-0004Hk-8G; Tue, 18 Oct 2005 12:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuiN-0004HW-C1 for isms@megatron.ietf.org; Tue, 18 Oct 2005 12:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14109 for ; Tue, 18 Oct 2005 12:53:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERutw-0003I9-Qj for isms@ietf.org; Tue, 18 Oct 2005 13:05:25 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2005 09:53:18 -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.12.10/8.12.6) with ESMTP id j9IGqnK7024328; Tue, 18 Oct 2005 09:53:15 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 09:53:14 -0700 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] #2: is server authentication a requirement that SNMPwillrequire Date: Tue, 18 Oct 2005 09:53:14 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3BEC3F7@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #2: is server authentication a requirement that SNMPwillrequire Thread-Index: AcXT7ThFzTW8po/UTk6bdCS/PTohVwAEf4HQ From: "Kaushik Narayan \(kaushik\)" To: "Sam Hartman" , "Eliot Lear" X-OriginalArrivalTime: 18 Oct 2005 16:53:14.0848 (UTC) FILETIME=[6E7B9E00:01C5D404] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, Please find my reply inline. =20 First, leap of faith (trust the first hostkey you get) probably would be sufficient for this situation. Second, I do understand the value of PKI. I understand that in some environments it will be used. ISMS needs to support that. But the charter goal of ISMS is to work with authentication people use today. Today, people do not use X.509 with ssh. No matter how much you, I or anyone else wants them to, it simply is not what people currently do. So, while ISMS should support it, and while you can (and should when appropriate) sell products that rely on it, it cannot be our primary focus. Today the predominant management protocol beyond SNMP (and Syslog) is a human interface (CLI) where the use of SSH with host keys will work just fine since the operator is in the loop. The use of CLI as a programmatic interface within our NMS systems requires manual provisioning of the device host keys and this is a significant overhead when managing thousands of devices, additionally pre-provisioning is major use case within network management systems where the device host keys are not known in advance.=20 Also, even if X.509 is not in use for SSH, other management protocols that use TLS such as Syslog and NetConf (over BEEP, SOAP) will move devices in that direction. Regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 15:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTe-00070E-VW; Tue, 18 Oct 2005 15:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTI-0006qk-Bv; Tue, 18 Oct 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24388; Tue, 18 Oct 2005 15:49:56 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxer-0000An-Ib; Tue, 18 Oct 2005 16:02:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTF-0001ZC-Of; Tue, 18 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-00.txt 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --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 Mapping Security Model (TMSM) for the Simple Network Management Protocol Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-00.txt Pages : 37 Date : 2005-10-18 This document describes a Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document identifies and discusses some key aspects that need to be considered for any transport-mapping-based security model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-18110404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-18110404.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue Oct 18 15:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTy-00073X-0S; Tue, 18 Oct 2005 15:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTI-0006rA-TI; Tue, 18 Oct 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24402; Tue, 18 Oct 2005 15:49:57 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxer-0000Am-Gt; Tue, 18 Oct 2005 16:02:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTF-0001Z8-Nm; Tue, 18 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-00.txt 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --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 : Secure Shell Security Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-00.txt Pages : 57 Date : 2005-10-18 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-18110041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-18110041.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue Oct 18 16:31:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy7T-0004c7-Fw; Tue, 18 Oct 2005 16:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy7R-0004bm-VA for isms@megatron.ietf.org; Tue, 18 Oct 2005 16:31:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09363 for ; Tue, 18 Oct 2005 16:31:25 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyIy-0005pg-Gs for isms@ietf.org; Tue, 18 Oct 2005 16:43:31 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 36C72E0038; Tue, 18 Oct 2005 16:31:32 -0400 (EDT) To: "Kaushik Narayan (kaushik)" Subject: Re: [Isms] #2: is server authentication a requirement that SNMPwillrequire References: <618694EF0B657246A4D55A97E38274C3BEC3F7@xmb-sjc-22d.amer.cisco.com> From: Sam Hartman Date: Tue, 18 Oct 2005 16:31:32 -0400 In-Reply-To: <618694EF0B657246A4D55A97E38274C3BEC3F7@xmb-sjc-22d.amer.cisco.com> (Kaushik Narayan's message of "Tue, 18 Oct 2005 09:53:14 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Kaushik" == Kaushik Narayan (kaushik) writes: Kaushik> Today the predominant management protocol beyond SNMP Kaushik> (and Syslog) is a human interface (CLI) where the use of Kaushik> SSH with host keys will work just fine since the operator Kaushik> is in the loop. The use of CLI as a programmatic Kaushik> interface within our NMS systems requires manual Kaushik> provisioning of the device host keys and this is a Kaushik> significant overhead when managing thousands of devices, Kaushik> additionally pre-provisioning is major use case within Kaushik> network management systems where the device host keys are Kaushik> not known in advance. Again, the goal of ISMS is to provide SNMP with support for *today's* authentication solutions. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 18 22:56:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES47V-0002bR-0a; Tue, 18 Oct 2005 22:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES47T-0002bM-6P for isms@megatron.ietf.org; Tue, 18 Oct 2005 22:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15243 for ; Tue, 18 Oct 2005 22:55:51 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES4J6-0003vn-Vs for isms@ietf.org; Tue, 18 Oct 2005 23:08:02 -0400 Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8082A1BAC4D for ; Wed, 19 Oct 2005 04:55:48 +0200 (CEST) Date: Wed, 19 Oct 2005 04:55:48 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] meeting in Vancouver 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, The ISMS WG will meet in Vancouver on Tuesday, November 8, 1300-1500 h. We have two working group documents and a long list of open issues which will be on the agenda. If you have suggestions for further agenda topics, please send me an email. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 00:22:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5TE-0005lA-5n; Wed, 19 Oct 2005 00:22:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5TC-0005l2-WE for isms@megatron.ietf.org; Wed, 19 Oct 2005 00:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18741 for ; Wed, 19 Oct 2005 00:22:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES5eo-0005rV-Hi for isms@ietf.org; Wed, 19 Oct 2005 00:34:31 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2005 21:22:18 -0700 X-IronPort-AV: i="3.97,229,1125903600"; d="scan'208"; a="221455085:sNHT24982000" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9J4MFJh009639; Tue, 18 Oct 2005 21:22:15 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp83.cisco.com [10.61.64.83]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9J4WeY1012808; Tue, 18 Oct 2005 21:32:41 -0700 Message-ID: <4355C9F5.3050000@cisco.com> Date: Wed, 19 Oct 2005 06:22:13 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Isms] #2: is server authentication a requirement that SNMPwillrequire References: <618694EF0B657246A4D55A97E38274C3BEC3F7@xmb-sjc-22d.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=274; t=1129696362; x=1130128562; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20#2=3A=20is=20server=20authentication=20a=20requirement= 20that=20SNMPwillrequire| From:Eliot=20Lear=20| Date:Wed,=2019=20Oct=202005=2006=3A22=3A13=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=rypg14CYcQbLUC4RSFeigAuybcUVXwuz6WH3WV2p3xnmWp1XfZ69bCC6+BQ6lx6Ylar4wjzC OTF2d4/IiUKig5YfA7HV1Sl9krXHGTVHVFGizz1l3zrnO5TUz13oq8rPsGKbVbZr++YZGH86rxs nD6A/Ow7JF30Cnchme2MOCIA= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, > Again, the goal of ISMS is to provide SNMP with support for *today's* > authentication solutions. It is not so far from the realm of possibility that X.509 will be here. I hope you will agree that if the SSHSM/SNMP subsystem treats SSH as a black box with appropriate gazzintas and gazzoutas this shouldn't be a problem. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 03:09:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES85B-0000gj-57; Wed, 19 Oct 2005 03:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES859-0000ge-VH for isms@megatron.ietf.org; Wed, 19 Oct 2005 03:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26077 for ; Wed, 19 Oct 2005 03:09:42 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES8Gp-0001Kb-Qz for isms@ietf.org; Wed, 19 Oct 2005 03:21:57 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 76AE7E0039; Wed, 19 Oct 2005 03:09:45 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] #2: is server authentication a requirement that SNMPwillrequire References: <618694EF0B657246A4D55A97E38274C3BEC3F7@xmb-sjc-22d.amer.cisco.com> <4355C9F5.3050000@cisco.com> From: Sam Hartman Date: Wed, 19 Oct 2005 03:09:45 -0400 In-Reply-To: <4355C9F5.3050000@cisco.com> (Eliot Lear's message of "Wed, 19 Oct 2005 06:22:13 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, >> Again, the goal of ISMS is to provide SNMP with support for >> *today's* authentication solutions. Eliot> It is not so far from the realm of possibility that X.509 Eliot> will be here. I hope you will agree that if the SSHSM/SNMP Eliot> subsystem treats SSH as a black box with appropriate Eliot> gazzintas and gazzoutas this shouldn't be a problem. Completely. You might even want to do things like standardize X.509 SubjectAltNames for SNMP engine IDs (or you might not); define a netconf data model fragment for configuring appropriate trust anchors and certificate validation policies; etc. What I think would be inappropriate is depending on X.509 in the core ssh SM documents. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 04:20:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES964-0002fQ-92; Wed, 19 Oct 2005 04:14:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES960-0002fI-W1 for isms@megatron.ietf.org; Wed, 19 Oct 2005 04:14:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28955 for ; Wed, 19 Oct 2005 04:14:41 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9Hg-00038D-9k for isms@ietf.org; Wed, 19 Oct 2005 04:26:54 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL00LADLTFX0@szxga01-in.huawei.com> for isms@ietf.org; Wed, 19 Oct 2005 16:20:04 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL000PBLTEQC@szxga01-in.huawei.com> for isms@ietf.org; Wed, 19 Oct 2005 16:20:03 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOL000DOLW31P@szxml02-in.huawei.com>; Wed, 19 Oct 2005 16:21:39 +0800 (CST) Date: Wed, 19 Oct 2005 16:14:00 +0800 From: Miao Fuyou Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? In-reply-to: <200510181652.MAA14074@ietf.org> To: dbharrington@comcast.net Message-id: <001901c5d485$0fb890e0$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7BIT 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, David, -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Wednesday, October 19, 2005 12:52 AM To: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Hi Maio, snmpEngineID should not be dynamically generated; that would defeat the whole purpose of having an engineID - to uniquely and unambiguously identify an engine within an administrative domain. An engine may have multiple addresses, and its addresses may change over time. But the snmpEngineID provides a consistent managed object to identify the virtual database of which it is part. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Monday, October 17, 2005 5:28 AM > To: 'Kaushik Narayan (kaushik)'; dbharrington@comcast.net; > isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > key andSNMPengineID? > > > SSH transport is different from TCP tranport for SNMP. SSHSM > starts a SNMP > agent as subsystem of SSH server contrasting to TCP as forked > child process, > it means each subsytem is independent to each other. Will > they share same > snmpEngineID, just like in UDP or TCP transporting? In other > word, do all > subsystems started by a SSH server are same SNMP entity? > > If not, I believe snmpEngineID must be allocated dynamicaly > enough. In such > case mapping SSH key and snmpEngineID is difficult. > > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Kaushik Narayan (kaushik) > Sent: Saturday, October 15, 2005 12:10 AM > To: dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? > > > > > > I think we should consider using/mapping the identity of the > SNMP engine to > the SNMP engine ID, this will be particularly useful when you > have multiple > SNMP engines on the same host (single SSH server). I am not > quite sure about > the spoofing issue since that should be taken care by server (agent) > authentication by the SSH transport protocol. > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David B Harrington > Sent: Thursday, October 13, 2005 2:51 PM > To: isms@ietf.org > Subject: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? > > #8: Do we need a mapping between the SSH key (or other SSH engine > identifier) and SNMP engineID? What happens if an agent > "spoofs" another > engineID, and an NMS perfoms a SET of sensitive parameters to > the agent? > > > > > > David Harrington > dbharrington@comcast.net > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 04:24:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9FM-0006PI-JP; Wed, 19 Oct 2005 04:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9FK-0006NL-UC for isms@megatron.ietf.org; Wed, 19 Oct 2005 04:24:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29389 for ; Wed, 19 Oct 2005 04:24:18 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9R1-0003O1-HN for isms@ietf.org; Wed, 19 Oct 2005 04:36:32 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3EDABE0038; Wed, 19 Oct 2005 04:24:21 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Wed, 19 Oct 2005 04:24:21 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Isms] Please welcome Juergen Schoenwaelder as the second ISMS chair 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. I'm quite pleased to announce that Juergen Schoenwaelder has agreed to replace Ken Hornstein as an ISMS co-chair. He will join Juergen Quittek who will continue as an ISMS chair. I'd like to thank Ken for the effort he was able to put in and hope that some day he will again have time to chair an ietf working group. I'd like to thank Juergen Schoenwaelder for joining us at this critical time as we move from choosing a solution into the work of protocol design. Juergen has significant experience in the management area and has a long history in the IETF. I look forward to working with both chairs. I will also be conducting a search in the ssh community for a security advisor. I think that should be much quicker than the search for chairs. I'd like to think all the people who suggested names of potential chairs, all those who volunteered and all the people I was talking to throughout this process. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 05:12:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESA07-0000wE-4W; Wed, 19 Oct 2005 05:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESA05-0000w6-KE for isms@megatron.ietf.org; Wed, 19 Oct 2005 05:12:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01419 for ; Wed, 19 Oct 2005 05:12:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESABn-0004Wh-IW for isms@ietf.org; Wed, 19 Oct 2005 05:24:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D84D5E0038; Wed, 19 Oct 2005 05:12:44 -0400 (EDT) To: "Blumenthal, Uri" Subject: Re: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? References: <3DEC199BD7489643817ECA151F7C59290204C8DB@pysmsx401.amr.corp.intel.com> From: Sam Hartman Date: Wed, 19 Oct 2005 05:12:44 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290204C8DB@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Mon, 17 Oct 2005 17:38:34 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Blumenthal," == Blumenthal, Uri writes: Blumenthal,> First, it is a good practice for any discernable Blumenthal,> entity to have unique cryptographic material (keys). Blumenthal,> Second, if SNMP manager is OK with ascertaining only Blumenthal,> the host to where it directs its commands - then no Blumenthal,> need for separate keys. Or if the manager is willing to trust the host to direct the command appropriately. If however the manager wants Blumenthal,> to make sure that he talks with a certain *agent* - Blumenthal,> must have separate keys. If the manager is not willing to trust the host to direct communication to a requested agent, then each agent needs keys. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 05:23:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAAv-0005YA-Jv; Wed, 19 Oct 2005 05:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAAt-0005Vz-Hr for isms@megatron.ietf.org; Wed, 19 Oct 2005 05:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01981 for ; Wed, 19 Oct 2005 05:23:47 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESAMa-0004rW-Jc for isms@ietf.org; Wed, 19 Oct 2005 05:36:02 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 23C40E0038; Wed, 19 Oct 2005 05:23:53 -0400 (EDT) To: "David T. Perkins" Subject: Re: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID? References: From: Sam Hartman Date: Wed, 19 Oct 2005 05:23:53 -0400 In-Reply-To: (David T. Perkins's message of "Mon, 17 Oct 2005 12:36:48 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David T Perkins writes: David> 3) In SSH, a server is identified by a transport address David> (SSH experts jump in if I've used the incorrect David> terminology) I'm not sure that the ssh protocol documents specify how servers are named. I think this may be a local matter. It sounds from the architecture document like servers are typically named by hostname, but many implementations also name servers by IP address. I'd appreciate a more specific citation to a claim that servers are identified by transport address. David> and is authenticated via use of a public key David> pair (RSA or DSA). (from draft-ietf-secsh-transport-24.txt David> and draft-ietf-secsh-architecture-22.txt) And is often authenticated by a public key. There is already another standards track mechanism for authenticating servers: draft-ietf-secsh-gssapi-keyex, which like the core ssh documents is waiting in the rfc-editor queue. Other mechanisms are possible. >From this I conclude that anything in SSHSM that depends on the particular way servers are authenticated will limit the applicability of SSHSM. It may be appropriate (and possibly even necessary) to define ways of managing certain information based on particular authentication methods. It is desirable to avoid depending on particular authentication methods and is probably desirable to be conservative in accepting authentication method information that may not be available from some authentication methods into architectural elements in SSHSM or TMSM. David> 4) In SSH, a client is identified by a "user name" (from David> draft-ietf-secsh-userauth-27.txt, section 5) and is David> authenticated via a mechanism identified by a "method David> name". The typical ones are "publickey" and "password" (see David> draft-ietf-secsh-assignednumbers-12.txt, section 4.8) A client is authenticated by zero or more methods. Method are in fact named. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 05:33:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAJu-00016V-GC; Wed, 19 Oct 2005 05:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAJt-00015u-4Q for isms@megatron.ietf.org; Wed, 19 Oct 2005 05:33:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02513 for ; Wed, 19 Oct 2005 05:33:04 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESAVb-00057l-1M for isms@ietf.org; Wed, 19 Oct 2005 05:45:19 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL00I2XPE3WO@szxga03-in.huawei.com> for isms@ietf.org; Wed, 19 Oct 2005 17:37:15 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL00400P6ZMF@szxga03-in.huawei.com> for isms@ietf.org; Wed, 19 Oct 2005 17:37:15 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOL00CPJPFCSW@szxml01-in.huawei.com>; Wed, 19 Oct 2005 17:38:01 +0800 (CST) Date: Wed, 19 Oct 2005 17:27:01 +0800 From: Miao Fuyou Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? In-reply-to: <200510181652.MAA14074@ietf.org> To: dbharrington@comcast.net, isms@ietf.org Message-id: <000001c5d48f$42e6a1f0$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7BIT Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, David, Thanks for your clarification! It is important for me to understand how SNMP works with SSH. RFC3411 says that snmpEngineID is used to uniquely identify an engine/entity, but I can't find sentence addressing snmpEngineID must be kept CONSISTENT even in case of address changes, I think it should be there. Miao -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Wednesday, October 19, 2005 12:52 AM To: isms@ietf.org Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Hi Maio, snmpEngineID should not be dynamically generated; that would defeat the whole purpose of having an engineID - to uniquely and unambiguously identify an engine within an administrative domain. An engine may have multiple addresses, and its addresses may change over time. But the snmpEngineID provides a consistent managed object to identify the virtual database of which it is part. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Monday, October 17, 2005 5:28 AM > To: 'Kaushik Narayan (kaushik)'; dbharrington@comcast.net; > isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > key andSNMPengineID? > > > SSH transport is different from TCP tranport for SNMP. SSHSM > starts a SNMP > agent as subsystem of SSH server contrasting to TCP as forked > child process, > it means each subsytem is independent to each other. Will > they share same > snmpEngineID, just like in UDP or TCP transporting? In other > word, do all > subsystems started by a SSH server are same SNMP entity? > > If not, I believe snmpEngineID must be allocated dynamicaly > enough. In such > case mapping SSH key and snmpEngineID is difficult. > > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Kaushik Narayan (kaushik) > Sent: Saturday, October 15, 2005 12:10 AM > To: dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > andSNMPengineID? > > > > > > I think we should consider using/mapping the identity of the > SNMP engine to > the SNMP engine ID, this will be particularly useful when you > have multiple > SNMP engines on the same host (single SSH server). I am not > quite sure about > the spoofing issue since that should be taken care by server (agent) > authentication by the SSH transport protocol. > > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David B Harrington > Sent: Thursday, October 13, 2005 2:51 PM > To: isms@ietf.org > Subject: [Isms] #8: Do we need a mapping between the SSH key and > SNMPengineID? > > #8: Do we need a mapping between the SSH key (or other SSH engine > identifier) and SNMP engineID? What happens if an agent > "spoofs" another > engineID, and an NMS perfoms a SET of sensitive parameters to > the agent? > > > > > > David Harrington > dbharrington@comcast.net > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 11:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG9d-0002Gz-DH; Wed, 19 Oct 2005 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG9c-0002Gr-33 for isms@megatron.ietf.org; Wed, 19 Oct 2005 11:47:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23989 for ; Wed, 19 Oct 2005 11:46:51 -0400 (EDT) Message-Id: <200510191546.LAA23989@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESGLM-0007Fz-JQ for isms@ietf.org; Wed, 19 Oct 2005 11:59:09 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <2005101915464901100a9sm3e>; Wed, 19 Oct 2005 15:46:49 +0000 From: "David B Harrington" To: "'Miao Fuyou'" , Subject: RE: [Isms] #8: Do we need a mapping between the SSH keyandSNMPengineID? Date: Wed, 19 Oct 2005 11:46:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXUkB3IopPvNEFVRq+AK5KbQpj8cgALr1Hg In-Reply-To: <000001c5d48f$42e6a1f0$2d646e0a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Maio, Let me assure you, you are not the first to make this mistake. ;-) The definition of snmpEngineID in RFC3411 says it should be constant: snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. This information SHOULD be stored in non-volatile storage so that it remains constant across re-initializations of the SNMP engine. " ::= { snmpEngine 1 } The definition of the SnmpEngineID Textual convention says it is not for addressing, only identification. I agree it could be clearer that a change of address does not mean the snmpEngineID should be regenerated. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Wednesday, October 19, 2005 5:27 AM > To: dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > keyandSNMPengineID? > > Hi, David, > > Thanks for your clarification! It is important for me to > understand how SNMP > works with SSH. RFC3411 says that snmpEngineID is used to > uniquely identify > an engine/entity, but I can't find sentence addressing > snmpEngineID must be > kept CONSISTENT even in case of address changes, I think it > should be there. > > > Miao > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > Behalf Of David B Harrington > Sent: Wednesday, October 19, 2005 12:52 AM > To: isms@ietf.org > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > keyandSNMPengineID? > > > Hi Maio, > > snmpEngineID should not be dynamically generated; that would > defeat the > whole purpose of having an engineID - to uniquely and > unambiguously identify > an engine within an administrative domain. > > An engine may have multiple addresses, and its addresses may > change over > time. But the snmpEngineID provides a consistent managed > object to identify > the virtual database of which it is part. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, October 17, 2005 5:28 AM > > To: 'Kaushik Narayan (kaushik)'; dbharrington@comcast.net; > > isms@ietf.org > > Subject: RE: [Isms] #8: Do we need a mapping between the SSH > > key andSNMPengineID? > > > > > > SSH transport is different from TCP tranport for SNMP. SSHSM > > starts a SNMP > > agent as subsystem of SSH server contrasting to TCP as forked > > child process, > > it means each subsytem is independent to each other. Will > > they share same > > snmpEngineID, just like in UDP or TCP transporting? In other > > word, do all > > subsystems started by a SSH server are same SNMP entity? > > > > If not, I believe snmpEngineID must be allocated dynamicaly > > enough. In such > > case mapping SSH key and snmpEngineID is difficult. > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On > > Behalf Of Kaushik Narayan (kaushik) > > Sent: Saturday, October 15, 2005 12:10 AM > > To: dbharrington@comcast.net; isms@ietf.org > > Subject: RE: [Isms] #8: Do we need a mapping between the SSH key > > andSNMPengineID? > > > > > > > > > > > > I think we should consider using/mapping the identity of the > > SNMP engine to > > the SNMP engine ID, this will be particularly useful when you > > have multiple > > SNMP engines on the same host (single SSH server). I am not > > quite sure about > > the spoofing issue since that should be taken care by server (agent) > > authentication by the SSH transport protocol. > > > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] > > On Behalf Of David B Harrington > > Sent: Thursday, October 13, 2005 2:51 PM > > To: isms@ietf.org > > Subject: [Isms] #8: Do we need a mapping between the SSH key and > > SNMPengineID? > > > > #8: Do we need a mapping between the SSH key (or other SSH engine > > identifier) and SNMP engineID? What happens if an agent > > "spoofs" another > > engineID, and an NMS perfoms a SET of sensitive parameters to > > the agent? > > > > > > > > > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 19 21:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOpP-00049V-Nf; Wed, 19 Oct 2005 21:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOpO-000491-5u for isms@megatron.ietf.org; Wed, 19 Oct 2005 21:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00436 for ; Wed, 19 Oct 2005 21:02:32 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESP1D-0002Ce-AJ for isms@ietf.org; Wed, 19 Oct 2005 21:14:56 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOM002ZWWJ24L@szxga01-in.huawei.com> for isms@ietf.org; Thu, 20 Oct 2005 09:09:02 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOM00MOEWJ26E@szxga01-in.huawei.com> for isms@ietf.org; Thu, 20 Oct 2005 09:09:02 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOM00AD4WRASN@szxml01-in.huawei.com>; Thu, 20 Oct 2005 09:13:59 +0800 (CST) Date: Thu, 20 Oct 2005 09:03:00 +0800 From: Miao Fuyou Subject: RE: [Isms] #24: How should we enable auto-discovery? In-reply-to: <200510132203.SAA20585@ietf.org> To: dbharrington@comcast.net, isms@ietf.org Message-id: <000001c5d512$04614ba0$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org One new draft is just released. It is my observation to SSH discovery. The URL is. http://www.ietf.org/internet-drafts/draft-miao-isms-sshsm-discovery-00.txt Abstract This document discusses several possible mechanisms of SNMP engine discovery when SSH is deployed as transport mapping for SNMP. The document proposes a discovery mechanism using UDP transport and User Based Security Model(USM) with a feature of SSH host key distribution. The mechanism tries to reduce discovery cost and in the same time improve SSH host key distribution efficiency. The draft is in "discussion" nature. Maybe there is text that is implementation-related, but the author believes it was not specific to a certain implementation. David gave some valuable comments, but I am sorry I had not enough time to incorporate all the comments into the draft because of cut-off date. One issue, dynamic snmpEngineID, had be made clear on mailing list. Miao -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Friday, October 14, 2005 6:03 AM To: isms@ietf.org Subject: [Isms] #24: How should we enable auto-discovery? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 20 22:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmdm-0008No-7x; Thu, 20 Oct 2005 22:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmdk-0008MX-8s for isms@megatron.ietf.org; Thu, 20 Oct 2005 22:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18131 for ; Thu, 20 Oct 2005 22:28:05 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESmpm-0004Gc-J3 for isms@ietf.org; Thu, 20 Oct 2005 22:40:44 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO00DZDV1PNO@szxga01-in.huawei.com> for isms@ietf.org; Fri, 21 Oct 2005 10:32:13 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO009NQV1P9S@szxga01-in.huawei.com> for isms@ietf.org; Fri, 21 Oct 2005 10:32:13 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOO00CUIV4C7T@szxml02-in.huawei.com>; Fri, 21 Oct 2005 10:33:49 +0800 (CST) Date: Fri, 21 Oct 2005 10:26:10 +0800 From: Miao Fuyou Subject: RE: [Isms] #1: is it important to support anonymous user access to SNMP? In-reply-to: <200510132123.RAA18692@ietf.org> To: dbharrington@comcast.net, isms@ietf.org Message-id: <03c501c5d5e6$ccfca170$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org It may be a practical feature for some scenarios. In the same time I believe supporting anonymity is heavily dependent to access control policies, and it may not be orthogonal to access control model. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Friday, October 14, 2005 5:24 AM To: isms@ietf.org Subject: [Isms] #1: is it important to support anonymous user access to SNMP? >From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange that is authenticated and even private when the session initiator or responder is anonymous." This is a new feature provided by SBSM. Can we establish consensus that a) this is needed or b) this is not needed? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 20 22:34:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmjy-00047d-8x; Thu, 20 Oct 2005 22:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmjw-00046Z-Ji for isms@megatron.ietf.org; Thu, 20 Oct 2005 22:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18427 for ; Thu, 20 Oct 2005 22:34:29 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESmvz-0004T1-80 for isms@ietf.org; Thu, 20 Oct 2005 22:47:08 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2005 19:34:30 -0700 X-IronPort-AV: i="3.97,238,1125903600"; d="scan'208"; a="668084384:sNHT25360732" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9L2YP96003749; Thu, 20 Oct 2005 19:34:28 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 19:34:27 -0700 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] #1: is it important to support anonymous user access toSNMP? Date: Thu, 20 Oct 2005 19:34:26 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625E24CE6@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user access toSNMP? Thread-Index: AcXV5zfkO8207eWDQte5mXmtL3r82QAAFQrw From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 21 Oct 2005 02:34:27.0674 (UTC) FILETIME=[F52213A0:01C5D5E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Miao Fuyou <> supposedly scribbled: > It may be a practical feature for some scenarios. In the same time I > believe supporting anonymity is heavily dependent to access control > policies, and it may not be orthogonal to access control model. =20 >=20 ... >> From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > that is authenticated and even private when the session initiator or > responder is anonymous."=20 >=20 > This is a new feature provided by SBSM. Can we establish consensus > that a) this is needed or b) this is not needed?=20 Let me get something straight here: we are talking about _management_, = right? I find it really hard to imagine an instance in which we = wouldn't care who was managing a device, or the manager wouldn't care = what device is being managed... >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 20 23:52:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnww-00079X-DT; Thu, 20 Oct 2005 23:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnwu-00076Y-CX for isms@megatron.ietf.org; Thu, 20 Oct 2005 23:52:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21527 for ; Thu, 20 Oct 2005 23:51:57 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESo8x-0006sr-Kx for isms@ietf.org; Fri, 21 Oct 2005 00:04:37 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO00L66Z2OVJ@szxga01-in.huawei.com> for isms@ietf.org; Fri, 21 Oct 2005 11:59:12 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO0015YZ2OIM@szxga01-in.huawei.com> for isms@ietf.org; Fri, 21 Oct 2005 11:59:12 +0800 (CST) Received: from m19684 ([10.110.100.45]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOO00EOEZ5BG2@szxml02-in.huawei.com>; Fri, 21 Oct 2005 12:00:47 +0800 (CST) Date: Fri, 21 Oct 2005 11:53:08 +0800 From: Miao Fuyou Subject: RE: [Isms] #1: is it important to support anonymous user access toSNMP? In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB2625E24CE6@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , isms@ietf.org Message-id: <03c601c5d5f2$f38133e0$2d646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT Cc: dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I don't think anonymous user access implies to managing an anonymous device. The identities of the managed deviced may(must? anyway "none" public key algorithm is not defined in SSh draft) be verified, in other word, SSH server authentication may/must be enabled even in case of anonymous user access. -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Friday, October 21, 2005 10:34 AM To: isms@ietf.org Cc: Miao Fuyou; dbharrington@comcast.net Subject: RE: [Isms] #1: is it important to support anonymous user access toSNMP? Miao Fuyou <> supposedly scribbled: > It may be a practical feature for some scenarios. In the same time I > believe supporting anonymity is heavily dependent to access control > policies, and it may not be orthogonal to access control model. > ... >> From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > that is authenticated and even private when the session initiator or > responder is anonymous." > > This is a new feature provided by SBSM. Can we establish consensus > that a) this is needed or b) this is not needed? Let me get something straight here: we are talking about _management_, right? I find it really hard to imagine an instance in which we wouldn't care who was managing a device, or the manager wouldn't care what device is being managed... > > David Harrington > dbharrington@comcast.net > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 02:05:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESq1m-0000OO-Vw; Fri, 21 Oct 2005 02:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESq1l-0000NO-E9 for isms@megatron.ietf.org; Fri, 21 Oct 2005 02:05:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29133 for ; Fri, 21 Oct 2005 02:05:07 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESqDo-0002Qr-Op for isms@ietf.org; Fri, 21 Oct 2005 02:17:47 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9L64xBT012244; Thu, 20 Oct 2005 23:04:59 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9L64jLV008300; Thu, 20 Oct 2005 23:04:51 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9L64dkQ008275; Thu, 20 Oct 2005 23:04:40 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 20 Oct 2005 23:04:39 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Glen Zorn (gwz)" Subject: RE: [Isms] #1: is it important to support anonymous user access toSNMP? In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625E24CE6@xmb-sjc-215.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Maybe you didn't see my previous post on this.... Everywhere today you see examples of "anonymous clients" retrieving info via an authenticated server via a channel with integrity and possibly encryption. Let me provide you an example with SNMP.... Consider a public facility (maybe a library) that has free network access. Consider management applications that could be used to determine the availability of some resource (such as a printer). In this situation, it would be impractical to give each user a unique identity so that they could use SNMP to determine the status of the printers. If the identities of the printers were not authenticated (or the communication not integrity checked) then someone could fake that a printer was unavailable so that they could have exclusive access. There are GAZILLION of similar examples! On Thu, 20 Oct 2005, Glen Zorn (gwz) wrote: > Miao Fuyou <> supposedly scribbled: > > > It may be a practical feature for some scenarios. In the same time I > > believe supporting anonymity is heavily dependent to access control > > policies, and it may not be orthogonal to access control model. > > > > ... > > >> From draft-hardaker-snmp-session-sm-03.txt: "SNMP message exchange > > that is authenticated and even private when the session initiator or > > responder is anonymous." > > > > This is a new feature provided by SBSM. Can we establish consensus > > that a) this is needed or b) this is not needed? > > Let me get something straight here: we are talking about _management_, right? I find it really hard to imagine an instance in which we wouldn't care who was managing a device, or the manager wouldn't care what device is being managed... > > > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 08:47:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwJI-0007Sp-NW; Fri, 21 Oct 2005 08:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwJF-0007Sg-Vi for isms@megatron.ietf.org; Fri, 21 Oct 2005 08:47:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19389 for ; Fri, 21 Oct 2005 08:47:35 -0400 (EDT) Message-Id: <200510211247.IAA19389@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwVO-0007yX-3R for isms@ietf.org; Fri, 21 Oct 2005 09:00:19 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005102112473501400seiome>; Fri, 21 Oct 2005 12:47:35 +0000 From: "David B Harrington" To: Subject: RE: [Isms] #1: is it important to support anonymous user access toSNMP? Date: Fri, 21 Oct 2005 08:47:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUw In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, > Consider a public facility (maybe a library) that has free > network access. Consider management applications that could > be used to determine the availability of some resource > (such as a printer). In this situation, it would be > impractical to give each user a unique identity so > that they could use SNMP to determine the status > of the printers. If the identities of the printers > were not authenticated (or the communication not > integrity checked) then someone could fake that > a printer was unavailable so that they could > have exclusive access. The much simpler approach is to give the printer-monitoring application installed on the public computers its own credentials - the application is mapped to a securityName, and the application is allowed to see specific portions of the SNMP data. Human users have anonymous access to the application, which has access to the SNMP data and would presumably interpret the data and display the interpretation in a form suitable for human consumption. The users do not need anonymous access to SNMP, and the application doesn't need to be anonymous either. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 09:09:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESweC-0001c8-H4; Fri, 21 Oct 2005 09:09:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESweB-0001c0-R1 for isms@megatron.ietf.org; Fri, 21 Oct 2005 09:09:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20563 for ; Fri, 21 Oct 2005 09:09:12 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwqI-0000GQ-Le for isms@ietf.org; Fri, 21 Oct 2005 09:21:57 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr006.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 j9LD95oR011267 for ; Fri, 21 Oct 2005 13:09:05 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 j9LD94S7030287 for ; Fri, 21 Oct 2005 13:09:05 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102106090528445 for ; Fri, 21 Oct 2005 06:09:05 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 06:09:05 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 06:09:04 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 09:09:03 -0400 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] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 09:08:03 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020B0F5C@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 21 Oct 2005 13:09:03.0776 (UTC) FILETIME=[9C422A00:01C5D640] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >> Consider a public facility (maybe a library) that has free >> network access. Consider management applications that could >> be used to determine the availability of some resource >> (such as a printer). In this situation, it would be >> impractical to give each user a unique identity so >> that they could use SNMP to determine the status >> of the printers. If the identities of the printers >> were not authenticated (or the communication not >> integrity checked) then someone could fake that >> a printer was unavailable so that they could >> have exclusive access. > >The much simpler approach is to give the printer-monitoring >application installed on the public computers its own credentials - >the application is mapped to a securityName, and the application is >allowed to see specific portions of the SNMP data.=20 I agree with Dave Perkins here. "Semi-anonymous" access (where the server is authenticated to an anonymous client) has its merits, and is useful for SNMP; for monitoring and not management. >Human users have anonymous access to the application, which has access >to the SNMP data and would presumably interpret the data and display >the interpretation in a form suitable for human consumption. IMHO this is possible but impractical, at least much less practical than what Dave P. outlined. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 09:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwxe-00033P-2R; Fri, 21 Oct 2005 09:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwxb-00032s-FN for isms@megatron.ietf.org; Fri, 21 Oct 2005 09:29:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21415 for ; Fri, 21 Oct 2005 09:29:16 -0400 (EDT) Message-Id: <200510211329.JAA21415@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESx9j-0000sW-NK for isms@ietf.org; Fri, 21 Oct 2005 09:42:01 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <20051021132904013003gal3e>; Fri, 21 Oct 2005 13:29:04 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 09:28:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgA== In-Reply-To: <3DEC199BD7489643817ECA151F7C5929020B0F5C@pysmsx401.amr.corp.intel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This approach is already being used by NMS systems today. I don't see why it would be impractical. > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Friday, October 21, 2005 9:08 AM > To: isms@ietf.org > Subject: RE: [Isms] #1: is it important to support anonymous > user accesstoSNMP? > > >> Consider a public facility (maybe a library) that has free > >> network access. Consider management applications that could > >> be used to determine the availability of some resource > >> (such as a printer). In this situation, it would be > >> impractical to give each user a unique identity so > >> that they could use SNMP to determine the status > >> of the printers. If the identities of the printers > >> were not authenticated (or the communication not > >> integrity checked) then someone could fake that > >> a printer was unavailable so that they could > >> have exclusive access. > > > >The much simpler approach is to give the printer-monitoring > >application installed on the public computers its own credentials - > >the application is mapped to a securityName, and the application is > >allowed to see specific portions of the SNMP data. > > I agree with Dave Perkins here. "Semi-anonymous" access (where the > server is authenticated to an anonymous client) has its merits, and is > useful for SNMP; for monitoring and not management. > > >Human users have anonymous access to the application, which > has access > >to the SNMP data and would presumably interpret the data and display > >the interpretation in a form suitable for human consumption. > > IMHO this is possible but impractical, at least much less > practical than > what Dave P. outlined. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 10:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxlL-0004MK-PK; Fri, 21 Oct 2005 10:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxlK-0004MF-9G for isms@megatron.ietf.org; Fri, 21 Oct 2005 10:20:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24234 for ; Fri, 21 Oct 2005 10:20:39 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxxP-0002lR-H8 for isms@ietf.org; Fri, 21 Oct 2005 10:33:24 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 34D824BF4D; Fri, 21 Oct 2005 16:20:22 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01087-08; Fri, 21 Oct 2005 16:20:21 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5AE3B4BF55; Fri, 21 Oct 2005 16:20:20 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 970D34D4DA4; Fri, 21 Oct 2005 16:20:22 +0200 (CEST) Date: Fri, 21 Oct 2005 16:20:22 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] #1: is it important to support anonymous user accesstoSNMP? Message-ID: <20051021142022.GA5028@boskop.local> Mail-Followup-To: David B Harrington , "'Blumenthal, Uri'" , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C5929020B0F5C@pysmsx401.amr.corp.intel.com> <200510211329.JAA21415@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510211329.JAA21415@ietf.org> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Oct 21, 2005 at 09:28:59AM -0400, David B Harrington wrote: > This approach is already being used by NMS systems today. I don't see > why it would be impractical. In all fairness, NMS systems also rely on community "public" for a great deal of their discovery. So even big commercial NMS systems sometimes like to talk to boxes who are not aware of the NMS identity. Note that I am not necessarily saying ISMS has to support authenticated anonymous access - perhaps community "public" is good enough, even though it is not authenticated. In fact, does authenticated anonymous access not boil down to "I configure a well-known (typically read-only) user identity with a secret that everybody knows about"? If yes, then I don't think ISMS has to do something special. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 11:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyah-0002wp-RL; Fri, 21 Oct 2005 11:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyaf-0002wT-Tp for isms@megatron.ietf.org; Fri, 21 Oct 2005 11:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01875 for ; Fri, 21 Oct 2005 11:13:42 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESymj-0006Mv-Mv for isms@ietf.org; Fri, 21 Oct 2005 11:26:28 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9LFDeZC021438 for ; Fri, 21 Oct 2005 11:13:40 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 21 Oct 2005 11:13:41 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 21 Oct 2005 11:13:41 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Oct 2005 11:13:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 11:13:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103260F@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWSzw80j/e0fOUTaqDDCsTJ9d1TQABPnmQ From: "Nelson, David" To: X-OriginalArrivalTime: 21 Oct 2005 15:13:08.0758 (UTC) FILETIME=[F1D04360:01C5D651] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:20.4119 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Whether or not "it" is a useful feature in ISMS, I pedantically oppose use of the term "authenticated anonymous access" to describe "it". As explained in this thread, "it" is access by means of a security association in which one party is authenticated and the other party is anonymous. I still claim that it is meaningless to say that an anonymous entity has been authenticated, and that's what "authenticated anonymous access" says if you parse it using standard syntax rules for the English language. In the "one party authenticated, one party anonymous" scenario, the two parties still need to have some form of shared credential for any authentication to occur. One example of this is when the anonymous party has a local trust anchor (e.g. an X.509 certificate chain) that allows it to authenticate the non-anonymous party. This certainly works with modern web browsers. The need for non-enrolled, non-authenticated entities to obtain access, for monitoring purposes, may make sense in some scenarios. But do the non-authenticated entities need to be anonymous? I use the word anonymous in its traditional security protocol meaning, i.e. the identity of the entity is not disclosed and cannot be determined. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 12:07:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzQ5-0005kY-VD; Fri, 21 Oct 2005 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzQ5-0005kT-Ay for isms@megatron.ietf.org; Fri, 21 Oct 2005 12:07:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15583 for ; Fri, 21 Oct 2005 12:06:49 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzcF-0003nd-1j for isms@ietf.org; Fri, 21 Oct 2005 12:19:36 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr006.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 j9LG6poR007752 for ; Fri, 21 Oct 2005 16:06:51 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.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 j9LG6jdi026400 for ; Fri, 21 Oct 2005 16:06:51 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102109065021301 for ; Fri, 21 Oct 2005 09:06:50 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 09:06:50 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 09:06:50 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 12:06:49 -0400 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] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 12:05:48 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020B1245@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWSphMi3oQcWJDSBGXE04dswT22AADkiUw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 21 Oct 2005 16:06:49.0438 (UTC) FILETIME=[717D07E0:01C5D659] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > Note that I am not necessarily saying ISMS has to support > authenticated anonymous access - perhaps community "public" is good > enough, even though it is not authenticated. The question was whether this is a useful feature. My answer is yes. Whether it's a necessary one, or how much development efforts it justifies - I abstain from answering. > In fact, does authenticated anonymous access not boil down to "I > configure a well-known (typically read-only) user identity with a > secret that everybody knows about"? If yes, then I don't think ISMS > has to do something special. No, because in models such as USM - knowledge of that secret cryptographically allows to impersonate *either* end of the conversation. In ISMS it may or may not be different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 12:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESznn-000235-Fa; Fri, 21 Oct 2005 12:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESznl-0001r7-C9 for isms@megatron.ietf.org; Fri, 21 Oct 2005 12:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17241 for ; Fri, 21 Oct 2005 12:31:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzzv-0004mi-Ep for isms@ietf.org; Fri, 21 Oct 2005 12:44:04 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 09:31:19 -0700 X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="222499203:sNHT28480280" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9LGVGUw013205; Fri, 21 Oct 2005 09:31:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 09:36:44 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69061B14E7@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAg From: "Salowey, Joe" To: , "Blumenthal, Uri" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Since it seems like we are talking about unauthenticated access I see this as more of an operational issue than something that would require much, if any, protocol specification. If unauthenticated access is really required then operational conventions can be developed to support this within the current authentication framework of SSH. =20 David B Harrington wrote: > This approach is already being used by NMS systems today. I > don't see why it would be impractical. >=20 >=20 >=20 >> -----Original Message----- >> From: isms-bounces@lists.ietf.org >> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri >> Sent: Friday, October 21, 2005 9:08 AM >> To: isms@ietf.org >> Subject: RE: [Isms] #1: is it important to support anonymous user >> accesstoSNMP?=20 >>=20 >>>> Consider a public facility (maybe a library) that has free network >>>> access. Consider management applications that could be used to >>>> determine the availability of some resource (such as a printer). In >>>> this situation, it would be impractical to give each user a unique >>>> identity so that they could use SNMP to determine the status of the >>>> printers. If the identities of the printers were not authenticated >>>> (or the communication not integrity checked) then someone could >>>> fake that a printer was unavailable so that they could have >>>> exclusive access. >>>=20 >>> The much simpler approach is to give the printer-monitoring >>> application installed on the public computers its own credentials - >>> the application is mapped to a securityName, and the application is >>> allowed to see specific portions of the SNMP data. >>=20 >> I agree with Dave Perkins here. "Semi-anonymous" access (where the >> server is authenticated to an anonymous client) has its merits, and >> is useful for SNMP; for monitoring and not management. >>=20 >>> Human users have anonymous access to the application, which has >>> access to the SNMP data and would presumably interpret the data and >>> display the interpretation in a form suitable for human consumption. >>=20 >> IMHO this is possible but impractical, at least much less practical >> than what Dave P. outlined.=20 >>=20 >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >>=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 13:44:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0wt-0003GP-Ak; Fri, 21 Oct 2005 13:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0wr-0003GF-Sq for isms@megatron.ietf.org; Fri, 21 Oct 2005 13:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21100 for ; Fri, 21 Oct 2005 13:44:47 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET192-0007UP-BB for isms@ietf.org; Fri, 21 Oct 2005 13:57:33 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr001.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 j9LHiiPc025372; Fri, 21 Oct 2005 17:44:44 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.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 j9LHiTds024628; Fri, 21 Oct 2005 17:44:44 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102110444406559 ; Fri, 21 Oct 2005 10:44:44 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 10:44:44 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 10:44:43 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 13:44:42 -0400 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] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 13:43:41 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020B1378@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAAHyOZA= From: "Blumenthal, Uri" To: "Salowey, Joe" , , X-OriginalArrivalTime: 21 Oct 2005 17:44:42.0488 (UTC) FILETIME=[1E195780:01C5D667] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Since it seems like we are talking about unauthenticated access Not quite. There are two end-points, and it is possible to authenticate only one of them. Apparently it can be useful to be able to enforce authentication of only one end. > ....I see > this as more of an operational issue than something that would require > much, if any, protocol specification.=20 Probably - I don't know. > If unauthenticated access is > really required then operational conventions can be developed to support > this within the current authentication framework of SSH. =20 For SSH it would mean - SSH server doesn't authenticate the user (or a "well-known" credential is used, such as "public"), but the SSH client authenticates SSH server. David B Harrington wrote: > This approach is already being used by NMS systems today. I > don't see why it would be impractical. >=20 >=20 >=20 >> -----Original Message----- >> From: isms-bounces@lists.ietf.org >> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri >> Sent: Friday, October 21, 2005 9:08 AM >> To: isms@ietf.org >> Subject: RE: [Isms] #1: is it important to support anonymous user >> accesstoSNMP?=20 >>=20 >>>> Consider a public facility (maybe a library) that has free network >>>> access. Consider management applications that could be used to >>>> determine the availability of some resource (such as a printer). In >>>> this situation, it would be impractical to give each user a unique >>>> identity so that they could use SNMP to determine the status of the >>>> printers. If the identities of the printers were not authenticated >>>> (or the communication not integrity checked) then someone could >>>> fake that a printer was unavailable so that they could have >>>> exclusive access. >>>=20 >>> The much simpler approach is to give the printer-monitoring >>> application installed on the public computers its own credentials - >>> the application is mapped to a securityName, and the application is >>> allowed to see specific portions of the SNMP data. >>=20 >> I agree with Dave Perkins here. "Semi-anonymous" access (where the >> server is authenticated to an anonymous client) has its merits, and >> is useful for SNMP; for monitoring and not management. >>=20 >>> Human users have anonymous access to the application, which has >>> access to the SNMP data and would presumably interpret the data and >>> display the interpretation in a form suitable for human consumption. >>=20 >> IMHO this is possible but impractical, at least much less practical >> than what Dave P. outlined.=20 >>=20 >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >>=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 18:14:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET59F-00035p-Bc; Fri, 21 Oct 2005 18:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET59D-00035i-TL for isms@megatron.ietf.org; Fri, 21 Oct 2005 18:13:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21431 for ; Fri, 21 Oct 2005 18:13:47 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET5LQ-0008PX-L5 for isms@ietf.org; Fri, 21 Oct 2005 18:26:37 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2005 15:13:49 -0700 X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="355243944:sNHT25142532" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9LMD39g009350; Fri, 21 Oct 2005 15:13:47 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:13:46 -0700 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 15:13:45 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625E24F31@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWSzw80j/e0fOUTaqDDCsTJ9d1TQABPnmQAA6BM7A= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , X-OriginalArrivalTime: 21 Oct 2005 22:13:46.0149 (UTC) FILETIME=[B4788550:01C5D68C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Nelson, David <> supposedly scribbled: > Whether or not "it" is a useful feature in ISMS, I pedantically > oppose use of the term "authenticated anonymous access" to describe > "it". As explained in this thread, "it" is access by means of a > security association in which one party is authenticated and the > other party is anonymous. I still claim that it is meaningless to > say that an anonymous entity has been authenticated, and that's what > "authenticated anonymous access" says if you parse it using standard > syntax rules for the English language.=20 I agree. =20 >=20 > In the "one party authenticated, one party anonymous" scenario, the > two parties still need to have some form of shared credential for any > authentication to occur. One example of this is when the anonymous > party has a local trust anchor (e.g. an X.509 certificate chain) that > allows it to authenticate the non-anonymous party. This certainly > works with modern web browsers. =20 Yes, & that's not completely unreasonable. =20 >=20 > The need for non-enrolled, non-authenticated entities to obtain > access, for monitoring purposes, may make sense in some scenarios.=20 It might, indeed, but I would be strongly opposed to using the word = "secure" in referencing those applications... > But do the non-authenticated entities need to be anonymous? I use > the word anonymous in its traditional security protocol meaning, i.e. > the identity of the entity is not disclosed and cannot be determined. I think it's actually more like "don't care" than truly anonymous.=20 =20 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 21 20:53:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET7dI-0003xx-WC; Fri, 21 Oct 2005 20:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET7dG-0003rs-Do for isms@megatron.ietf.org; Fri, 21 Oct 2005 20:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07758 for ; Fri, 21 Oct 2005 20:52:59 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET7pU-0008Li-IM for isms@ietf.org; Fri, 21 Oct 2005 21:05:49 -0400 Received: from h-68-165-4-175.snvacaid.dynamic.covad.net ([68.165.4.175] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ET7dD-0004kh-00 for isms@ietf.org; Fri, 21 Oct 2005 20:53:07 -0400 Message-ID: <002e01c5d6a3$7867a980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625E24F31@xmb-sjc-215.amer.cisco.com> Subject: Re: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Fri, 21 Oct 2005 17:56:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - Perhaps we can distill the what the use cases are asking for: - that the user of the command generator application does not need to be known to to the administration. (the security administrator may, of course, choose to prohibit such access) This isn't necessarily true anonymity, and I'm sure it would help if someone could suggest a term from the security community that means what we intend. - the request will be encrypted, if the user wants privacy. Other "anonymous" users will have no advantage in attempting to decrypt such a request. - the command responder will have reasonable confidence that the request has not been modified en route, even by another "anonymous" users. - the "anonymous" user making such a request can be referred to in a VACM policy - if the request was encrypted, the response will also be encrypted, so that only the intended recipient (and possibly the sender) will be able to decrypt it. In particular, other "anonymous" users will NOT have any advantage in attempting to decrypt the response. - the user of the command generator application will be able to be reasonably confident that the response came from the intended command responder, and was not modified in transit. (The reason for wanting integrity on the request is due to the way getNext and getBulk work in SNMP. With a simple get request, the response would make it clear whether the request had been mangled in any significant way. With getNext and getBulk, one can massively change the request, and the response would give no clue that this had happen, even though the information returned could indeed be different.) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 07:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0q3-0006zt-V0; Mon, 24 Oct 2005 07:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0q1-0006yu-Dq for isms@megatron.ietf.org; Mon, 24 Oct 2005 07:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04220 for ; Mon, 24 Oct 2005 07:49:47 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU12k-0000Cp-Ja for isms@ietf.org; Mon, 24 Oct 2005 08:03:11 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 92B29E0038; Mon, 24 Oct 2005 07:50:03 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] #32: is the securityName=username default OK? References: <200510132210.SAA21149@ietf.org> From: Sam Hartman Date: Mon, 24 Oct 2005 07:50:03 -0400 In-Reply-To: <200510132210.SAA21149@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 18:09:56 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> #32: For an incoming message, is using a default David> securityName mapping the right thing to do? Can you explain this in more detail? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 07:57:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0wx-0000nh-7H; Mon, 24 Oct 2005 07:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0wu-0000nN-Go for isms@megatron.ietf.org; Mon, 24 Oct 2005 07:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04468 for ; Mon, 24 Oct 2005 07:56:55 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU19f-0000Pp-7q for isms@ietf.org; Mon, 24 Oct 2005 08:10:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7A26FE0038; Mon, 24 Oct 2005 07:57:11 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH? References: <200510132159.RAA20390@ietf.org> From: Sam Hartman Date: Mon, 24 Oct 2005 07:57:11 -0400 In-Reply-To: <200510132159.RAA20390@ietf.org> (David B. Harrington's message of "Thu, 13 Oct 2005 17:59:34 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org It is important that ssh work fine without any use of radius. It may be desirable to expose radius interactions outside ssh for management, monitoring and configuration. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 07:59:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0zf-00015I-02; Mon, 24 Oct 2005 07:59:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0zd-000158-II for isms@megatron.ietf.org; Mon, 24 Oct 2005 07:59:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04557 for ; Mon, 24 Oct 2005 07:59:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU1CI-0000Ug-9S for isms@ietf.org; Mon, 24 Oct 2005 08:13:05 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8913EE0038; Mon, 24 Oct 2005 07:59:55 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Mon, 24 Oct 2005 07:59:55 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Isms] New charter and chair announcement from secretariat 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Within five minutes of my note to this working group announcing the new chair, I sent a request to the secretariat to announce the new charter formally and to update the web page. They've been a bit busy and have not gotten to that request. I just wanted to let everyone know that was in process and as far as I can tell no balls have been dropped. The time before the meeting is very busy for the secretariat. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 10:35:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3QJ-0004N1-3N; Mon, 24 Oct 2005 10:35:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3QH-0004Mb-1l for isms@megatron.ietf.org; Mon, 24 Oct 2005 10:35:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12923 for ; Mon, 24 Oct 2005 10:35:22 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU3d1-0005o6-Tp for isms@ietf.org; Mon, 24 Oct 2005 10:48:49 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <2005102414352301100rrpcbe>; Mon, 24 Oct 2005 14:35:23 +0000 From: "David B Harrington" To: Date: Mon, 24 Oct 2005 10:35:17 -0400 Message-ID: <001401c5d8a8$28e70020$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFidEw X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Issue #s and their context X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, The issues I presented are all related to discussion needed to complete specific sections of draft-ietf-isms-secshell-00.txt. To understand the context of issue #32, search for "[discuss] #32" in the document; to understand the context of other issues, substitute the chosen issue # in your search pattern. I think that may answer many questions. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Monday, October 24, 2005 7:50 AM > To: dbharrington@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] #32: is the securityName=username default OK? > > >>>>> "David" == David B Harrington writes: > > David> #32: For an incoming message, is using a default > David> securityName mapping the right thing to do? > > Can you explain this in more detail? > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 10:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3nQ-00046p-80; Mon, 24 Oct 2005 10:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3nN-00046N-G7 for isms@megatron.ietf.org; Mon, 24 Oct 2005 10:59:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14097 for ; Mon, 24 Oct 2005 10:59:14 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU408-0006ZB-Db for isms@ietf.org; Mon, 24 Oct 2005 11:12:41 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <20051024145901013003kkfpe>; Mon, 24 Oct 2005 14:59:07 +0000 From: "David B Harrington" To: "'Sam Hartman'" , Subject: RE: [Isms] #32: is the securityName=username default OK? Date: Mon, 24 Oct 2005 10:58:52 -0400 Message-ID: <001501c5d8ab$75ec12e0$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBA X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, This issue is related to the "Elements of Procedure" in draft-ietf-isms-secshell-00.txt section 5.7, step 10). Following the elements of procedure of USM as closely as reasonable, the text says the mapping from the SSH authentication-method-specific tmSecurityName to a model-independent securityName should be contained in the Local Configuration Datastore (LCD): "10) Information about the value of tmSecurityName is extracted from the Local Configuration Datastore (LCD) to provide conversion from the SSH authentication-method-specific tmSecurityName to a model- independent securityName." However, we are attempting to eliminate the need for lots of preconfiguration, so we may want to define a default mechanism for algorithmically determining the mapping to securityName. Therefore section 10) has some default logic (I've added some clarifications in [] markers): "If no information is available for the username in the LCD, then the securityName is set to the username associated with the session. Note that USM at this point would return an unknownSecurityName error to the caller, because [USM] didn't automatically assign a securityname from the model-specific parameters. The message should never reach us if it didn't pass [client] authentication [during session establishment], so tmSecurityname should always be present [in the session information]. " So, if the mapping between a mechanism-specific "username" and a corresponding securityname is not explicitly specified in the Local Configuration Datastore, then is setting securityName to the username (tmSecurityname) associated with the session the right thing to do? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Monday, October 24, 2005 7:50 AM > To: dbharrington@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] #32: is the securityName=username default OK? > > >>>>> "David" == David B Harrington writes: > > David> #32: For an incoming message, is using a default > David> securityName mapping the right thing to do? > > Can you explain this in more detail? > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 11:14:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU41m-0000YN-AM; Mon, 24 Oct 2005 11:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU41l-0000Xe-5j for isms@megatron.ietf.org; Mon, 24 Oct 2005 11:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14849 for ; Mon, 24 Oct 2005 11:14:06 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4EU-00073J-Ii for isms@ietf.org; Mon, 24 Oct 2005 11:27:33 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4FCFBE0038; Mon, 24 Oct 2005 11:14:24 -0400 (EDT) To: Subject: Re: [Isms] #32: is the securityName=username default OK? References: <001501c5d8ab$75ec12e0$0400a8c0@DJYXPY41> From: Sam Hartman Date: Mon, 24 Oct 2005 11:14:23 -0400 In-Reply-To: <001501c5d8ab$75ec12e0$0400a8c0@DJYXPY41> (David B. Harrington's message of "Mon, 24 Oct 2005 10:58:52 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dbharrington@comcast.net, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> So, if the mapping between a mechanism-specific "username" David> and a corresponding securityname is not explicitly David> specified in the Local Configuration Datastore, then is David> setting securityName to the username (tmSecurityname) David> associated with the session the right thing to do? On the ssh server, probably yes. On the ssh client, probably not. My answers to #8 expand on the issues involved here. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 11:34:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4LL-0006L4-Ke; Mon, 24 Oct 2005 11:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4LK-0006Kz-F6 for isms@megatron.ietf.org; Mon, 24 Oct 2005 11:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15796 for ; Mon, 24 Oct 2005 11:34:21 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4Xo-0007ew-Pe for isms@ietf.org; Mon, 24 Oct 2005 11:47:47 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9OFXqZC029215 for ; Mon, 24 Oct 2005 11:33:55 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 24 Oct 2005 11:33:41 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 24 Oct 2005 11:33:39 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Oct 2005 11:33:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Mon, 24 Oct 2005 11:30:46 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F381@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlA= From: "Nelson, David" To: X-OriginalArrivalTime: 24 Oct 2005 15:33:38.0868 (UTC) FILETIME=[4E416740:01C5D8B0] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:49.3701 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David B Harrington writes... > So, if the mapping between a mechanism-specific "username" and a > corresponding securityname is not explicitly specified in the Local > Configuration Datastore, then is setting securityName to the username > (tmSecurityname) associated with the session the right thing to do? While nothing would preclude having USM-style local configuration information dealing with the creation of securityName, I think the straightforward thing to do is eliminate any local configuration dependency and *always* use the tmSecurityName as the securityName.=20 This effectively deprecates the concept of a model independent securityName. While that was probably a nice concept in theory, and practical as long as local configuration was intrinsically part of the authentication mechanism, I think it makes little sense when used with existing authentication (or AAA) infrastructures. Remember, the whole premise is to leverage existing, centralized identity management, so having to configure an identity transform on each managed entity makes no sense to me. We don't want to have to configure the identities on each managed entity, so why should we have to configure an identity transform? IMHO, the proposed default behavior is the only required behavior. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 15:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Lt-0003QI-3v; Mon, 24 Oct 2005 15:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Kz-000391-7Q for isms@megatron.ietf.org; Mon, 24 Oct 2005 15:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28628 for ; Mon, 24 Oct 2005 15:50:14 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8Xj-0007e2-Hs for isms@ietf.org; Mon, 24 Oct 2005 16:03:44 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA27299; Mon, 24 Oct 2005 12:50:09 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9OJo9J14035; Mon, 24 Oct 2005 12:50:09 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 12:49:48 -0700 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] #1: is it important to support anonymous user accesstoSNMP? Date: Mon, 24 Oct 2005 12:49:47 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBCA17@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAJ3K2ZA= From: "Fleischman, Eric" To: "Salowey, Joe" , , "Blumenthal, Uri" , X-OriginalArrivalTime: 24 Oct 2005 19:49:48.0323 (UTC) FILETIME=[172A1F30:01C5D8D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This discussion appears to me to have been coupling authentication with authorization. If we permit the authentication of an "anonymous" entity, then the question of whether or not that entity is authorized to do anything useful is a policy issue. I propose that we support a wide variety of authentication alternatives and that those alternatives are then mapped to various authorization results via locally defined policies. Given this, one can bind SSH with the authentication identity (which is what I interpret your email message as implying) but the authorization that entity experiences is a function of the locally-defined policies. -----Original Message----- From: Salowey, Joe [mailto:jsalowey@cisco.com]=20 Sent: Friday, October 21, 2005 9:37 AM To: ietfdbh@comcast.net; Blumenthal, Uri; isms@ietf.org Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Since it seems like we are talking about unauthenticated access I see this as more of an operational issue than something that would require much, if any, protocol specification. If unauthenticated access is really required then operational conventions can be developed to support this within the current authentication framework of SSH. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 17:30:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU9tP-0000nl-UI; Mon, 24 Oct 2005 17:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU9tN-0000nb-L1 for isms@megatron.ietf.org; Mon, 24 Oct 2005 17:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21577 for ; Mon, 24 Oct 2005 17:29:50 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUA6C-0000KU-2U for isms@ietf.org; Mon, 24 Oct 2005 17:43:21 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <2005102421295401100rt2jme>; Mon, 24 Oct 2005 21:29:54 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Salowey, Joe'" , "'Blumenthal, Uri'" , Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Mon, 24 Oct 2005 17:29:49 -0400 Message-ID: <00fc01c5d8e2$10a38e90$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474EEBD229DF754FB83D256004D02108BBCA17@XCH-NW-6V1.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAJ3K2ZAAAsE8kA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Comments inline. > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > I propose that we support a wide > variety of authentication alternatives and that those alternatives are > then mapped to various authorization results via locally defined > policies. In SNMPv3, we have an authentication subsystem and an access control subsystem. It will always be that an entity that is authenticated (or not, using noAuthNpPriv) will then be mapped to authorization policies using securityName. Personally, rather than seeing support for a wide variety of authentication alternatives, I'd like to see us support the widely-deployed SSH authentication mechanisms that serve SNMP needs. I am willing to accept that we should support any authentication mechanism REQUIRED or RECOMMENDED for use with the SecSH standard. Is anonymous SSH authentication supported by the secsh standards? The question is really, does SSHSM need to support an authentication mechanism so anonymous entities can have access to raw SNMP data? I can see use-cases for anonymous access to a system, such as for FTP downloads of publicly accessible information, but I have difficulty seeing use-cases for anonymous SNMP access to a system, and I am concerned that adding this feature that has never existed in SNMP (although "public" is pretty close to anonymous) will increase the complexity of SSHSM with no real benefit to justify the added complexity. I personally believe it is NOT important to support anonymous SNMP access to SNMP data, and it is not important that SSHSM support this. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 17:55:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUAHz-0001QA-J0; Mon, 24 Oct 2005 17:55:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU9sb-0000ab-22; Mon, 24 Oct 2005 17:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21533; Mon, 24 Oct 2005 17:29:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUA5Q-0000Ji-Mn; Mon, 24 Oct 2005 17:42:32 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EU9sZ-0006QV-RW; Mon, 24 Oct 2005 17:29:15 -0400 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Mon, 24 Oct 2005 17:29:15 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Mon, 24 Oct 2005 17:55:30 -0400 Cc: isms@ietf.org Subject: [Isms] WG Action: RECHARTER: Integrated Security Model for SNMP (isms) 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org The Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Integrated Security Model for SNMP (isms) ========================================== Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Juergen Quittek Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals and Milestones: Done Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution Done Decision about which architecture the WG will focus its efforts on Oct 05 Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models Oct 05 Initial version of a document specifying the SSH security model for SNMP Feb 06 Initial version of an applicability statement that sets up reasonable mandatory to implement methods Feb 06 Submit TMSM document to IESG Jun 06 Submit SSH TMSM to IESG Jun 06 Submit RADIUS mapping model for SNMP to IESG Aug 06 Submit applicability statement to IESG Dec 06 Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 18:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUAbw-00005c-27; Mon, 24 Oct 2005 18:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUAbu-0008TC-Ek for isms@megatron.ietf.org; Mon, 24 Oct 2005 18:16:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25025 for ; Mon, 24 Oct 2005 18:15:53 -0400 (EDT) Received: from stratton-one-o-six.mit.edu ([18.187.5.106] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUAoh-00022f-Hc for isms@ietf.org; Mon, 24 Oct 2005 18:29:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 245A5E0038; Mon, 24 Oct 2005 18:15:57 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] #1: is it important to support anonymous user accesstoSNMP? References: <00fc01c5d8e2$10a38e90$0400a8c0@DJYXPY41> From: Sam Hartman Date: Mon, 24 Oct 2005 18:15:57 -0400 In-Reply-To: <00fc01c5d8e2$10a38e90$0400a8c0@DJYXPY41> (David B. Harrington's message of "Mon, 24 Oct 2005 17:29:49 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Personally, rather than seeing support for a wide variety David> of authentication alternatives, I'd like to see us support David> the widely-deployed SSH authentication mechanisms that David> serve SNMP needs. I am willing to accept that we should David> support any authentication mechanism REQUIRED or David> RECOMMENDED for use with the SecSH standard. I think as a matter of architectural sanity you need to support any authentication mechanism that works with the ssh protocol regardless of whether it is recommended for use. David> Is anonymous SSH authentication supported by the secsh David> standards? Sure. Two ways. The easiest is that the server simply returns success when you start user authentication instead of giving you methods to choose from. I've also seen servers that offer keyboard-interactive and when you select it simply return success. The second is that you have some well known credential. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 18:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB4b-00038k-49; Mon, 24 Oct 2005 18:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB4Z-00037E-S0 for isms@megatron.ietf.org; Mon, 24 Oct 2005 18:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26376 for ; Mon, 24 Oct 2005 18:45:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBHO-0002jn-Va for isms@ietf.org; Mon, 24 Oct 2005 18:59:00 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2005 15:45:33 -0700 X-IronPort-AV: i="3.97,246,1125903600"; d="scan'208"; a="356121670:sNHT23404220" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9OMjS96023372; Mon, 24 Oct 2005 15:45:30 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 15:45:20 -0700 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Mon, 24 Oct 2005 15:45:19 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625EB7744@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAJ3K2ZAABhRo8A== From: "Glen Zorn \(gwz\)" To: "Fleischman, Eric" , "Joseph Salowey \(jsalowey\)" , , "Blumenthal, Uri" , X-OriginalArrivalTime: 24 Oct 2005 22:45:20.0410 (UTC) FILETIME=[9CC70FA0:01C5D8EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Fleischman, Eric <> supposedly scribbled: > This discussion appears to me to have been coupling authentication > with authorization. If we permit the authentication of an "anonymous" > entity, then the question of whether or not that entity is authorized > to do anything useful is a policy issue.=20 The term "authentication" doesn't seem to apply to anonymous entities. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 24 19:08:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUBQT-0002ko-Oc; Mon, 24 Oct 2005 19:08:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUBQQ-0002kH-Cs for isms@megatron.ietf.org; Mon, 24 Oct 2005 19:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00976 for ; Mon, 24 Oct 2005 19:08:04 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBdD-0004X6-Uf for isms@ietf.org; Mon, 24 Oct 2005 19:21:34 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005102423080301400sd4tke>; Mon, 24 Oct 2005 23:08:03 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] #32: is the securityName=username default OK? Date: Mon, 24 Oct 2005 19:07:58 -0400 Message-ID: <011701c5d8ef$c6967660$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F381@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAABy1FIA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Comments inline. > > While nothing would preclude having USM-style local configuration > information dealing with the creation of securityName, I think the > straightforward thing to do is eliminate any local configuration > dependency and *always* use the tmSecurityName as the securityName. Remember that ISMS supplements USM. USM requires a local configuration dependency, therefore we cannot eliminate it. > This effectively deprecates the concept of a model independent > securityName. While that was probably a nice concept in theory, and > practical as long as local configuration was intrinsically part of the > authentication mechanism, I think it makes little sense when used with > existing authentication (or AAA) infrastructures. Remember, the whole > premise is to leverage existing, centralized identity management, so > having to configure an identity transform on each managed entity makes > no sense to me. We don't want to have to configure the identities on > each managed entity, so why should we have to configure an identity > transform? One reason why we have securityName is so that a system logging facility that logs changes to the SNMP system can use a human-readable name in the log - the securityName. We have no guarantee that the tmSecurityName is human-readable. The more obvious reason for securityname is to allow multiple authentication mechanisms to map to a common securityname for a user (or a group of users, or whatever) for use by the access control system. I do not believe all organizations will always have only one mechanism for authenticating all people and other entities (such as applications), regardless of the device from which they are authenticating, the firmware version of the device from which they are authenticating, or the location from which they are authenticating. Having a mechanism to bind multiple mechanism-specific identities to ojne SNMp identity seems a good thing. David Harrington dbharrington@comcast.net > > IMHO, the proposed default behavior is the only required behavior. > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 03:29:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJFh-0005gF-V6; Tue, 25 Oct 2005 03:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJFf-0005fl-I6 for isms@megatron.ietf.org; Tue, 25 Oct 2005 03:29:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27016 for ; Tue, 25 Oct 2005 03:29:28 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUJSY-0000zq-U4 for isms@ietf.org; Tue, 25 Oct 2005 03:43:04 -0400 Received: from h-64-105-137-163.snvacaid.dynamic.covad.net ([64.105.137.163] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EUJFU-0002Tz-00 for isms@ietf.org; Tue, 25 Oct 2005 03:29:32 -0400 Message-ID: <000e01c5d936$5e3c5200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <474EEBD229DF754FB83D256004D02108BBCA17@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 00:33:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Fleischman, Eric" > To: "Salowey, Joe" ; ; "Blumenthal, Uri" ; > Sent: Monday, October 24, 2005 12:49 PM > Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? > > This discussion appears to me to have been coupling authentication with > authorization. If we permit the authentication of an "anonymous" entity, > then the question of whether or not that entity is authorized to do > anything useful is a policy issue. I propose that we support a wide > variety of authentication alternatives and that those alternatives are > then mapped to various authorization results via locally defined > policies. Given this, one can bind SSH with the authentication identity > (which is what I interpret your email message as implying) but the > authorization that entity experiences is a function of the > locally-defined policies. ... To make it really concrete, if we assume the security adminstrator is reasonably sane, the permissions granted to "anonymous" would probably be identical to those given to "public". The difference (with respect to using "public" with USM or SNMPv1 or SNMPv2) is that the user could have reasonable assurance that the data being retrieved was not tampered with or spoofed, and, optionally, was protected from evesdroppers. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 10:24:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPjC-0003cY-2g; Tue, 25 Oct 2005 10:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPjA-0003YO-Cs for isms@megatron.ietf.org; Tue, 25 Oct 2005 10:24:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20170 for ; Tue, 25 Oct 2005 10:24:21 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPw2-0004Fk-H2 for isms@ietf.org; Tue, 25 Oct 2005 10:38:01 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PEOQZC010851 for ; Tue, 25 Oct 2005 10:24:27 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 10:23:52 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 10:23:51 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 10:23:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 10:19:57 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F38A@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAABy1FIAAoXOgg From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 14:23:51.0735 (UTC) FILETIME=[B8F15C70:01C5D96F] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:98.0684 P:95.9108 R:95.9108 S:22.7654 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David B Harrington writes... > Remember that ISMS supplements USM. I think of ISMS as an alternative to USM. > USM requires a local configuration > dependency, therefore we cannot eliminate it. Well, even ISMS will require some local configuration. It will also be dependent on local configuration of the SSH server. That being said, the *type* of local configuration that makes USM difficult to deploy is per-user information. The most basic concept of AAA systems is to store all per-user information on centralized servers. I think that requiring ISMS to have per-user (or per-meta-user) configuration stored on each managed entity defeats the purpose. Requiring the local configuration of authentication mechanisms, shared secrets and AAA server addresses is, of course, to be expected. > One reason why we have securityName is so that a system logging > facility that logs changes to the SNMP system can use a human-readable > name in the log - the securityName. We have no guarantee that the > tmSecurityName is human-readable. AAA systems almost always authenticate humans. Even when they don't, the protocols have been designed for authentication of humans. That pretty much guarantees that the basic identity nomenclature (the username) will be human readable, because it has to be human writeable (e.g. entered by a human at a keyboard). I believe you can assume and require that tmSecurityName be human readable without any loss of generality, even when the credentials are in a more complex form, such as digital certificates. > The more obvious reason for securityname is to allow multiple > authentication mechanisms to map to a common securityname for a user > (or a group of users, or whatever) for use by the access control > system. Grouping multiple users into policy groups is the domain of the AAA server, not the AAA client, and therefore not ISMS. > I do not believe all organizations will always have only one mechanism > for authenticating all people and other entities (such as > applications), regardless of the device from which they are > authenticating, the firmware version of the device from which they are > authenticating, or the location from which they are authenticating. > Having a mechanism to bind multiple mechanism-specific identities to > one SNMP identity seems a good thing. It is true that organizations sometime use multiple legacy authentication mechanisms. When it is technically feasible, organizations will most often back-end each of these disparate mechanisms with the same user identity repository, i.e. implement a form of single-sign-on. For ISMS to succeed, it must not only accommodate multiple authentication mechanisms (those supported or supportable by SSH), it must remove any dependencies on per-user configuration on each managed entity. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 11:22:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQd0-0007r5-Mh; Tue, 25 Oct 2005 11:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQcy-0007qA-Kk for isms@megatron.ietf.org; Tue, 25 Oct 2005 11:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29167 for ; Tue, 25 Oct 2005 11:22:01 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQpw-0007un-7m for isms@ietf.org; Tue, 25 Oct 2005 11:35:41 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 08:22:04 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356451501:sNHT52095556" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9PFLU9W000818; Tue, 25 Oct 2005 08:22:02 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 08:21:58 -0700 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] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 08:21:57 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3C4215D@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXY6JYnbd3ZOZBIRbKM9heJX7bGewAjmkmg From: "Kaushik Narayan \(kaushik\)" To: "Sam Hartman" , X-OriginalArrivalTime: 25 Oct 2005 15:21:58.0769 (UTC) FILETIME=[D7608610:01C5D977] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I really don't see any serious SNMP use cases that might require anonymous user support. I completely agree with David here, we should use capabilities from SSH based on what's needed for SNMP. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman Sent: Monday, October 24, 2005 3:16 PM To: ietfdbh@comcast.net Cc: isms@ietf.org Subject: Re: [Isms] #1: is it important to support anonymous user accesstoSNMP? >>>>> "David" =3D=3D David B Harrington writes: David> Personally, rather than seeing support for a wide variety David> of authentication alternatives, I'd like to see us support David> the widely-deployed SSH authentication mechanisms that David> serve SNMP needs. I am willing to accept that we should David> support any authentication mechanism REQUIRED or David> RECOMMENDED for use with the SecSH standard. I think as a matter of architectural sanity you need to support any authentication mechanism that works with the ssh protocol regardless of whether it is recommended for use. David> Is anonymous SSH authentication supported by the secsh David> standards? Sure. Two ways. The easiest is that the server simply returns success when you start user authentication instead of giving you methods to choose from. I've also seen servers that offer keyboard-interactive and when you select it simply return success. The second is that you have some well known credential. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 11:53:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR6y-0003OZ-KX; Tue, 25 Oct 2005 11:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR6w-0003KM-DN for isms@megatron.ietf.org; Tue, 25 Oct 2005 11:53:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01250 for ; Tue, 25 Oct 2005 11:52:59 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURJr-0000QD-HI for isms@ietf.org; Tue, 25 Oct 2005 12:06:36 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2005 08:53:01 -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.12.10/8.12.6) with ESMTP id j9PFqSK9018280; Tue, 25 Oct 2005 08:52:58 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 08:52:57 -0700 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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 08:52:56 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3C42187@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMA== From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 25 Oct 2005 15:52:57.0830 (UTC) FILETIME=[2B76B860:01C5D97C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I think some authentication systems and even some domains such as DOCSIS might require mapping of the authenticated "name" to a securityName. It might be better to handle this within ISMS configuration (which would probably be implementation dependent) and not security model independent configuration since the mapping might be specific to particular authentication systems. regards, kaushik! =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David Sent: Monday, October 24, 2005 8:31 AM To: isms@ietf.org Subject: RE: [Isms] #32: is the securityName=3Dusername default OK? David B Harrington writes... > So, if the mapping between a mechanism-specific "username" and a=20 > corresponding securityname is not explicitly specified in the Local=20 > Configuration Datastore, then is setting securityName to the username > (tmSecurityname) associated with the session the right thing to do? While nothing would preclude having USM-style local configuration information dealing with the creation of securityName, I think the straightforward thing to do is eliminate any local configuration dependency and *always* use the tmSecurityName as the securityName.=20 This effectively deprecates the concept of a model independent securityName. While that was probably a nice concept in theory, and practical as long as local configuration was intrinsically part of the authentication mechanism, I think it makes little sense when used with existing authentication (or AAA) infrastructures. Remember, the whole premise is to leverage existing, centralized identity management, so having to configure an identity transform on each managed entity makes no sense to me. We don't want to have to configure the identities on each managed entity, so why should we have to configure an identity transform? IMHO, the proposed default behavior is the only required behavior. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 12:02:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURG0-0005no-Qm; Tue, 25 Oct 2005 12:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURFv-0005ne-Oc for isms@megatron.ietf.org; Tue, 25 Oct 2005 12:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01668 for ; Tue, 25 Oct 2005 12:02:16 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURSX-0000dq-OY for isms@ietf.org; Tue, 25 Oct 2005 12:15:57 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PG1xZC027846 for ; Tue, 25 Oct 2005 12:02:00 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 12:02:00 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 12:01:59 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 12:01:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 12:01:48 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F390@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5g From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 16:01:48.0384 (UTC) FILETIME=[67B2D600:01C5D97D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.6627 P:95.9108 R:95.9108 S:83.4377 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... > I think some authentication systems and even some domains such as DOCSIS > might require mapping of the authenticated "name" to a securityName. I suppose there might be such a requirement, but could you give us a concrete example? > It might be better to handle this within ISMS configuration (which would > probably be implementation dependent) and not security model independent > configuration since the mapping might be specific to particular > authentication systems. This seems like a potential pit-fall to me. I can see all sorts of interoperability problems arising out of localized, implementation specific mappings of identity. It may work very well in specific deployment environments, where the rules are universally understood. However, I can see difficulties in obtaining correct results from multi-vendor interoperability testing. If the tmSecurityName is a function of local per-user (or per-meta-user) configuration information, then how is ISMS fundamentally different from USM? ISMS is supposed to be more than USM over SSH. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 13:22:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSVG-0006oY-Rk; Tue, 25 Oct 2005 13:22:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSVB-0006oE-Dw for isms@megatron.ietf.org; Tue, 25 Oct 2005 13:22:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07007 for ; Tue, 25 Oct 2005 13:22:07 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSi8-0003IK-QD for isms@ietf.org; Tue, 25 Oct 2005 13:35:47 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) 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 j9PHM8Sc028949 for ; Tue, 25 Oct 2005 17:22:08 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.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 j9PHM7H0028372 for ; Tue, 25 Oct 2005 17:22:08 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102510220822303 for ; Tue, 25 Oct 2005 10:22:08 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 10:22:08 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 10:22:08 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 13:22:07 -0400 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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 13:21:03 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020EE958@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 25 Oct 2005 17:22:07.0022 (UTC) FILETIME=[9FD4A4E0:01C5D988] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >> I think some authentication systems and even some domains >> such as DOCSIS might require mapping of the authenticated >> "name" to a securityName. > > I suppose there might be such a requirement, > but could you give us a concrete example? Easily. SNMPv2p (that was implemented and did see some limited deployment) identified entities by ASN.1-encoded OIDs.=20 > If the tmSecurityName is a function of local per-user (or per-meta-user) > configuration information, then how is ISMS fundamentally different from > USM?=20 First, who said that successful design must be "fundamentally different"? Second - most SSH installations have some local info both about the SSH config, AND about the users that can login via SSH. Often this info is shared with operating system user list - password file(s), but so what - the point is that local systems more often than not store relevant per-user information locally. The major complaints about USM that I'm aware of are: (a) USM requires SEPARATE infrastructure IN ADDITION to what's already deployed, and (b) USM lacks short-lived session keys and decent key update mechanism. > ISMS is supposed to be more than USM over SSH. :-) Is it? :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 13:47:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUStE-00072r-Np; Tue, 25 Oct 2005 13:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUStC-00071g-SH for isms@megatron.ietf.org; Tue, 25 Oct 2005 13:47:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08430 for ; Tue, 25 Oct 2005 13:46:56 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUT6A-000422-25 for isms@ietf.org; Tue, 25 Oct 2005 14:00:37 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 10:46:39 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356516026:sNHT2183026228" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9PHjnvF010883; Tue, 25 Oct 2005 10:46:37 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 10:46:36 -0700 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 10:46:33 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625EB79FF@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXZNfuPe6zVItgzSsuvA1m0KVdMrgAVaqsg From: "Glen Zorn \(gwz\)" To: "Randy Presuhn" X-OriginalArrivalTime: 25 Oct 2005 17:46:36.0118 (UTC) FILETIME=[0B7AE760:01C5D98C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Randy Presuhn <> supposedly scribbled: ... > To make it really concrete, if we assume the security adminstrator is > reasonably sane, the permissions granted to "anonymous" would > probably be identical to those given to "public". The difference > (with respect to using "public" with USM or SNMPv1 or SNMPv2) is that > the user could have reasonable assurance that the data being > retrieved was not tampered with or spoofed, and, optionally, was > protected from evesdroppers.=20 OK, so this argues not for some kind of ill-defined "anonymous user = authentication", but for actual authentication of the communicating = devices. One size does _not_ fit all... =20 >=20 > Randy Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 13:49:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSvk-0007sg-M1; Tue, 25 Oct 2005 13:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSvj-0007sb-1y for isms@megatron.ietf.org; Tue, 25 Oct 2005 13:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08668 for ; Tue, 25 Oct 2005 13:49:32 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUT8c-00049X-2d for isms@ietf.org; Tue, 25 Oct 2005 14:03:13 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PHnaZC027498 for ; Tue, 25 Oct 2005 13:49:36 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 13:49:36 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 13:49:36 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 13:49:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 13:49:23 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F393@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYA== From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 17:49:23.0704 (UTC) FILETIME=[6F5E7F80:01C5D98C] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:78.9889 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Uri Blumenthal writes... =20 > Easily. SNMPv2p (that was implemented and did see some limited > deployment) identified entities by ASN.1-encoded OIDs. Fine, but the ISMS charter is to develop an additional security method for SNMPv3. > First, who said that successful design must be "fundamentally > different"? I, for one, would certainly make that statement. If there isn't a significant difference, why expend the efforts of an IETF WG? > Second - most SSH installations have some local info both about the SSH > config, AND about the users that can login via SSH. Often this info is > shared with operating system user list - password file(s), but so what - > the point is that local systems more often than not store relevant > per-user information locally. Sigh. Having chosen SSH as the security transport, let's not lose sight of the fact that the original problem was to integrate SNMPv3 security with existing authentication infrastructures. That has to include AAA systems, as well as KDC systems. SSH implementations that rely on local password files are indistinguishable, IMHO, from USM in terms of being tied to locally configured user information, and therefore not scaleable. If we are considering a class of managed entities that includes native support for distributed authentication systems (e.g. NIS or Active Directory), then I see your point. My understanding is that the class of managed entities we are primarily considering is embedded systems that do not have such native support, and are reliant on protocols such as RADIUS, Diameter, TACACS, Kerberos, etc. for centralized AAA. > > ISMS is supposed to be more than USM over SSH. :-) >=20 > Is it? :-) Yes, I think so. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 13:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUT0S-0008DA-AK; Tue, 25 Oct 2005 13:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUT0R-0008D2-Cg for isms@megatron.ietf.org; Tue, 25 Oct 2005 13:54:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08892 for ; Tue, 25 Oct 2005 13:54:25 -0400 (EDT) Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTDQ-0004G3-LO for isms@ietf.org; Tue, 25 Oct 2005 14:08:05 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <20051025175415013003eln8e>; Tue, 25 Oct 2005 17:54:15 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 13:54:08 -0400 Message-ID: <004501c5d98d$1b5e53f0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAAOxXVA= In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F390@MAANDMBX2.ets.enterasys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I think this discussion is going off into ratholes. Allowing for static configuration does not REQUIRE static copnfiguration, nor preclude dynamic configuration; Allowing for dynamic configuration does not preclude static configuration where desired. A AAA system could provide a mapping that is stored in the LCD as part of the session configuration. In this case, the securityname is not necessarily the same as the username used for authentication. For example, RADIUS permits sending an accounting identity to be sent as part of the ACCESS-ACCEPT message, if I recall correctly. This could be stored in the LCD and thus be "picked up" as the value for securityName rather than defaulting to the "username" field from the ACCESS-REQUEST message (which is the current source for the tm-cached identity). If desired, an SNMP MIB could be designed, comparable to the USM-MIB, that permitted static assignemnts of usernames to securityNames. If desired, an LCD, possibly but not necessarily in MIB format, could be populated using CLI scripts or other non-SNMP configuration. The elements of procedure first look in the LCD, and if there is no assignment then securityname defaults to the mechanism-specific username: if ((securityname = LCD::lookup(username)) is FALSE) { then securityName = username; } David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, October 25, 2005 12:02 PM > To: isms@ietf.org > Subject: RE: [Isms] #32: is the securityName=username default OK? > > Kaushik Narayan writes... > > > I think some authentication systems and even some domains such as > DOCSIS > > might require mapping of the authenticated "name" to a securityName. > > I suppose there might be such a requirement, but could you give us a > concrete example? > > > It might be better to handle this within ISMS configuration (which > would > > probably be implementation dependent) and not security model > independent > > configuration since the mapping might be specific to particular > > authentication systems. > > This seems like a potential pit-fall to me. I can see all sorts of > interoperability problems arising out of localized, implementation > specific mappings of identity. It may work very well in specific > deployment environments, where the rules are universally understood. > However, I can see difficulties in obtaining correct results from > multi-vendor interoperability testing. > > If the tmSecurityName is a function of local per-user (or > per-meta-user) > configuration information, then how is ISMS fundamentally > different from > USM? ISMS is supposed to be more than USM over SSH. :-) > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 14:02:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUT8T-000306-Ii; Tue, 25 Oct 2005 14:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUT8R-0002xh-F6 for isms@megatron.ietf.org; Tue, 25 Oct 2005 14:02:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09542 for ; Tue, 25 Oct 2005 14:02:41 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTLR-0004Zg-PG for isms@ietf.org; Tue, 25 Oct 2005 14:16:22 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EUT8Q-0000cf-Nu for isms@ietf.org; Tue, 25 Oct 2005 14:02:54 -0400 Content-Type: text/plain Mime-Version: 1.0 To: isms@ietf.org From: iesg-secretary@ietf.org Message-Id: Date: Tue, 25 Oct 2005 14:02:54 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Isms] WG Action: RECHARTER: Integrated Security Model for SNMP (isms) 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org The Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Integrated Security Model for SNMP (isms) ========================================== Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Juergen Quittek Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: isms at ietf.org To Subscribe: isms-request at ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals and Milestones: Done Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution Done Decision about which architecture the WG will focus its efforts on Oct 05 Initial version of a general transport mapping security models (TMSMs)document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models Oct 05 Initial version of a document specifying the SSH security model for SNMP Feb 06 Initial version of an applicability statement that sets up reasonable mandatory to implement methods Feb 06 Submit TMSM document to IESG Jun 06 Submit SSH TMSM to IESG Jun 06 Submit RADIUS mapping model for SNMP to IESG Aug 06 Submit applicability statement to IESG Dec 06 Initial version of a document specifying the RADIUS authentication andauthorization mapping model for SNMP _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 14:12:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTHs-0000q6-JZ; Tue, 25 Oct 2005 14:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTHr-0000pu-19 for isms@megatron.ietf.org; Tue, 25 Oct 2005 14:12:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09945 for ; Tue, 25 Oct 2005 14:12:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTUX-0004o2-5n for isms@ietf.org; Tue, 25 Oct 2005 14:26:05 -0400 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by mx2.foretec.com with esmtp (Exim 4.24) id 1EUTHQ-0003lY-6I for isms@ietf.org; Tue, 25 Oct 2005 14:12:12 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PIBUZC029715 for ; Tue, 25 Oct 2005 14:11:30 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 14:11:31 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 14:11:31 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 14:10:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 14:10:23 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F394@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAAOxXVAAAJsOAA== From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 18:10:24.0009 (UTC) FILETIME=[5E91C790:01C5D98F] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:29.3724 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David B Harrington writes... > I think this discussion is going off into ratholes. What may be a rathole of inconsequential detail for one may be a fundamental requirement for another. YMMV. > Allowing for > static configuration does not REQUIRE static copnfiguration, nor > preclude dynamic configuration; Allowing for dynamic configuration > does not preclude static configuration where desired. Granted. I see no harm is allowing the option for local, static authentication information. OTOH, my opinion is that, if local, static authentication information is *all* you need, then USM meets your requirements today. > A AAA system could provide a mapping that is stored in the LCD as part > of the session configuration. In this case, the securityname is not > necessarily the same as the username used for authentication. For > example, RADIUS permits sending an accounting identity to be sent as > part of the ACCESS-ACCEPT message, if I recall correctly. This could > be stored in the LCD and thus be "picked up" as the value for > securityName rather than defaulting to the "username" field from the > ACCESS-REQUEST message (which is the current source for the tm-cached > identity). It could, but why is this a requirement for ISMS? I may be dense, but I still fail to see the value added by this additional complexity. > If desired, an SNMP MIB could be designed, comparable to the USM-MIB, > that permitted static assignemnts of usernames to securityNames. Yes, and that would make ISMS significantly different from USM in what way? =20 > If desired, an LCD, possibly but not necessarily in MIB format, could > be populated using CLI scripts or other non-SNMP configuration. Ditto. I don't object to a "compatibility" mode for ISMS in which it effectively behaves as USM, but if that is all we see as needed, then I suggest we don't bother and close the WG. I firmly believe that in order to be successful, and solve the customer problems that USM does not solve, that ISMS MUST have a mandatory to implement mode of operation in which it is fully independent of any locally configured per-user (or per-meta-user) authentication information. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 14:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTa6-00009P-5t; Tue, 25 Oct 2005 14:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTa4-00009D-Ko for isms@megatron.ietf.org; Tue, 25 Oct 2005 14:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11113 for ; Tue, 25 Oct 2005 14:31:14 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTn4-0005P3-0A for isms@ietf.org; Tue, 25 Oct 2005 14:44:55 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr001.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 j9PIVIIC022299 for ; Tue, 25 Oct 2005 18:31:18 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 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 j9PIVEGS030384 for ; Tue, 25 Oct 2005 18:31:18 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102511311701756 for ; Tue, 25 Oct 2005 11:31:17 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:31:17 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:31:17 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 14:31:16 -0400 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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 14:30:12 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020EEADD@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYAABIR0w From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 25 Oct 2005 18:31:16.0412 (UTC) FILETIME=[490F4FC0:01C5D992] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > > Easily. SNMPv2p (that was implemented and did see some limited > > deployment) identified entities by ASN.1-encoded OIDs. > > Fine, but the ISMS charter is to develop an additional security > method for SNMPv3. And SNMPv3 was designed to deal with more than one [different] security model without breaking the rest of the architecture. That includes security models that, like SNMPv2p, do NOT identify their entities by human-readable strings. You wanted an example of such security model - you were provided an example (which, as I said, was implemented and deployed - though not widely). > > First, who said that successful design must be "fundamentally > > different"? > > I, for one, would certainly make that statement. If there isn't a > significant difference, why expend the efforts of an IETF WG? It has to differ in the important areas of dissatisfaction with USM. There's no need for "fundamental difference" to address those (and IMHO ISMS isn't so "fundamentally different", so far at least).=20 IETF WG efforts normally are [supposed to be] expended to create a technically acceptable deployable protocol that takes care of something that other protocols don't (or don't do as well). "Being fundamentally different" is a silly useless goal to begin with. As a home exercise - consider what in TLSv1 is "fundamentally different" from SSLv3, and in TLSv1.1 - from TLSv1.0. > > Second - most SSH installations have some local info both about the > > SSH config, AND about the users that can login via SSH. Often this > > info is shared with operating system user list - password file(s), > > but so what - the point is that local systems more often than not > > store relevant per-user information locally. > > Sigh. Having chosen SSH as the security transport, let's not lose sight > of the fact that the original problem was to integrate SNMPv3 security > with existing authentication infrastructures.=20 Which for some are local password files. > That has to include AAA systems, as well as KDC systems. But not PKI? :-) > SSH implementations that rely on local password files are > indistinguishable, IMHO, from USM in terms of being > tied to locally configured user information, and therefore > not scaleable. People apparently aren't bothered by "scalability" - they simply don't want YET ANOTHER infrastructure to manage. If today they're happy with local password files (or domain logins) - that's what they want SNMP to use for security. Of course Kerberos users want Kerberos, and AAA users - want AAA. > If we are considering a class of managed entities that includes native > support for distributed authentication systems (e.g. NIS or Active > Directory), then I see your point. My understanding is that the class > of managed entities we are primarily considering is embedded systems > that do not have such native support, and are reliant on protocols such > as RADIUS, Diameter, TACACS, Kerberos, etc. for centralized AAA. No, even embedded systems aren't necessarily AAA- etc. reliant. Some are, some aren't... Welcome to diversity. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 14:34:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTd1-0001EU-Kb; Tue, 25 Oct 2005 14:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTd0-0001DW-GJ for isms@megatron.ietf.org; Tue, 25 Oct 2005 14:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11258 for ; Tue, 25 Oct 2005 14:34:16 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTq0-0005VB-OL for isms@ietf.org; Tue, 25 Oct 2005 14:47:57 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 11:34:20 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356542649:sNHT24857072" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PIXcKB007184; Tue, 25 Oct 2005 11:34:18 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:34:15 -0700 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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 11:34:14 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3C422B0@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAAUG6hA= From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 25 Oct 2005 18:34:15.0522 (UTC) FILETIME=[B3D15420:01C5D992] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Please find my reply inline.=20 I suppose there might be such a requirement, but could you give us a concrete example? Sure, If we support X.509 certificates we would need to map attributes (such as CN) from the client certificate to a username. > It might be better to handle this within ISMS configuration (which would > probably be implementation dependent) and not security model independent > configuration since the mapping might be specific to particular=20 > authentication systems. This seems like a potential pit-fall to me. I can see all sorts of interoperability problems arising out of localized, implementation specific mappings of identity. It may work very well in specific deployment environments, where the rules are universally understood. However, I can see difficulties in obtaining correct results from multi-vendor interoperability testing. If the tmSecurityName is a function of local per-user (or per-meta-user) configuration information, then how is ISMS fundamentally different from USM? ISMS is supposed to be more than USM over SSH. :-) I think ISMS supports a variety of authentication systems, for a majority of these authentication systems there isn't any local per-user configuration but I want to make sure that we don't preclude that possibility. Regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 15:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUU2Z-0002qf-VQ; Tue, 25 Oct 2005 15:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUU2Y-0002qU-Mm for isms@megatron.ietf.org; Tue, 25 Oct 2005 15:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12696 for ; Tue, 25 Oct 2005 15:00:40 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUFC-0006E0-Ar for isms@ietf.org; Tue, 25 Oct 2005 15:14:21 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PJ0QZC003714 for ; Tue, 25 Oct 2005 15:00:26 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 15:00:27 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 15:00:24 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 14:59:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 14:59:34 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F395@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYAABIR0wAAFS4oA= From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 18:59:34.0547 (UTC) FILETIME=[3D3A2630:01C5D996] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:93.2377 M:99.2571 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Uri Blumenthal writes... > You wanted an example of such security model - you were provided an > example (which, as I said, was implemented and deployed - though not > widely). OK, fair enough. > > Sigh. Having chosen SSH as the security transport, let's not=20 > > lose sight of the fact that the original problem was to=20 > > integrate SNMPv3 security with existing authentication=20 > > infrastructures. >=20 > Which for some are local password files. I guess a local password file is a *form* of infrastructure. IMHO, a degenerate case. > > That has to include AAA systems, as well as KDC systems. >=20 > But not PKI? :-) Many AAA systems will back-end to PKI and use X.509 certificates as credentials. > People apparently aren't bothered by "scalability" - they simply don't > want YET ANOTHER infrastructure to manage. OK. I'll agree that describes a segment of the user population. Although I certainly hope that somebody cares about scalability! :-) > If today they're happy with local password files (or domain=20 > logins) - that's what they want SNMP to use for security. Of=20 > course Kerberos users want Kerberos, and AAA users want AAA. Yes. As long as the Kerberos users and AAA users aren't saddled with the requirement to implement and configure localized user authentication information in the managed entity, I suppose that's all fine. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 15:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUEd-0000vd-DH; Tue, 25 Oct 2005 15:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUEb-0000vS-Ko for isms@megatron.ietf.org; Tue, 25 Oct 2005 15:13:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13358 for ; Tue, 25 Oct 2005 15:13:06 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUURb-0006b3-6l for isms@ietf.org; Tue, 25 Oct 2005 15:26:48 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr005.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 j9PJD2GV004320; Tue, 25 Oct 2005 19:13:02 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 j9PJCpGS007191; Tue, 25 Oct 2005 19:13:02 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102512130211413 ; Tue, 25 Oct 2005 12:13:02 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 12:13:02 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 12:13:02 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 15:12:15 -0400 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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 15:11:09 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929020EEB85@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYAABIR0wAAFS4oAAAKv/sA== From: "Blumenthal, Uri" To: "Nelson, David" , X-OriginalArrivalTime: 25 Oct 2005 19:12:15.0543 (UTC) FILETIME=[02D0EC70:01C5D998] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > I guess a local password file is a *form* of infrastructure. > IMHO, a degenerate case. It's what many people use...=20 >> People apparently aren't bothered by "scalability" - they simply don't >> want YET ANOTHER infrastructure to manage. > > OK. I'll agree that describes a segment of the user population. > Although I certainly hope that somebody cares about scalability! :-) The birth-reason of ISMS was - people already invested in SOME infrastructure, and don't want to spend an extra dime on ANOTHER one. So whatever scalability issues they had - they ALREADY ADDRESSED them in whatever infrastructure that they chose. > Yes. As long as the Kerberos users and AAA users aren't saddled with > the requirement to implement and configure localized user authentication > information in the managed entity, I suppose that's all fine. It would be nice if ISMS can accomplish that. I don't know if it's possible - but will be happy if it is. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 15:23:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUO9-0004YW-V8; Tue, 25 Oct 2005 15:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUO8-0004XX-Pz for isms@megatron.ietf.org; Tue, 25 Oct 2005 15:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14068 for ; Tue, 25 Oct 2005 15:22:58 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUao-0006wC-Ki for isms@ietf.org; Tue, 25 Oct 2005 15:36:40 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PJMmZC005750 for ; Tue, 25 Oct 2005 15:22:48 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 15:22:49 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 15:22:49 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 15:22:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 15:22:33 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F396@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYAABIR0wAAFS4oAAAKv/sAAAT75g From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 19:22:34.0454 (UTC) FILETIME=[73B73F60:01C5D999] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:98.6627 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Uri Blumenthal writes... > The birth-reason of ISMS was - people already invested in SOME > infrastructure, and don't want to spend an extra dime on ANOTHER one. So > whatever scalability issues they had - they ALREADY ADDRESSED them in > whatever infrastructure that they chose. There are a range of scalability properties in the already adopted infrastructures. Local password files have relatively low scalability, while Kerberos, RADIUS, Diameter, TACACS and general PKI infrastructures have relatively high scalability. As long as the requirements of ISMS don't force the reduction of scalability to the lowest common denominator for all mechanisms, I will be well satisfied. > > Yes. As long as the Kerberos users and AAA users aren't saddled with > > the requirement to implement and configure localized user > > authentication information in the managed entity, I suppose that's=20 > > all fine. >=20 > It would be nice if ISMS can accomplish that. I don't know if it's > possible - but will be happy if it is. I agree, however, I think that it is possible, and that it's more of a MUST than a SHOULD.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 15:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUZo-0008Si-NO; Tue, 25 Oct 2005 15:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUZn-0008Sd-TA for isms@megatron.ietf.org; Tue, 25 Oct 2005 15:35:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14693 for ; Tue, 25 Oct 2005 15:35:01 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUmn-0007HQ-U0 for isms@ietf.org; Tue, 25 Oct 2005 15:48:43 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA03053; Tue, 25 Oct 2005 12:35:03 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9PJZ3J16968; Tue, 25 Oct 2005 12:35:03 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 12:35:00 -0700 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] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 12:35:00 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBCA1A@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAJ3K2ZAABhRo8AArjleQ From: "Fleischman, Eric" To: "Glen Zorn \(gwz\)" , "Joseph Salowey \(jsalowey\)" , , "Blumenthal, Uri" , X-OriginalArrivalTime: 25 Oct 2005 19:35:00.0733 (UTC) FILETIME=[308862D0:01C5D99B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Glen, Since I've scribbled once, I may as well scribble again to respectfully disagree with your posting: If one defines authentication to be "proving that an entity is who it claims to be", then authenticating an anonymous entity is simply proving that the entity has no specific identity to that system.=20 It is a separate issue as to whether anonymous authentication is needed or not within ISMS. I originally thought that it anonymity was not desirable in network management (i.e., the perspective I surmise that you hold), but David Perkin's subsequent arguments convinced me that there is a potential need to support anonymous entities. It also is a separate issue as to how authorization should relate to authentication. --Eric -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Fleischman, Eric <> supposedly scribbled: > This discussion appears to me to have been coupling authentication=20 > with authorization. If we permit the authentication of an "anonymous"=20 > entity, then the question of whether or not that entity is authorized=20 > to do anything useful is a policy issue. The term "authentication" doesn't seem to apply to anonymous entities. Hope this helps, ~gwz W _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 15:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUqt-0007ZS-Vi; Tue, 25 Oct 2005 15:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUp8-00071W-NR for isms@megatron.ietf.org; Tue, 25 Oct 2005 15:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15794 for ; Tue, 25 Oct 2005 15:50:52 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUV1o-0007v0-V7 for isms@ietf.org; Tue, 25 Oct 2005 16:04:34 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9PJoeZC007841 for ; Tue, 25 Oct 2005 15:50:41 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 25 Oct 2005 15:50:40 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 25 Oct 2005 15:50:40 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 15:50:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 15:50:15 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F397@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXWBVsCxh+NlerIRPa3Zej0MqvAZQAN0kUwAADb+PAAAM9YgAAGQnAgAJ3K2ZAABhRo8AArjleQAACIprA= From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2005 19:50:16.0438 (UTC) FILETIME=[5255E160:01C5D99D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:92.2363 M:98.0742 P:95.9108 R:95.9108 S:40.2992 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eric Fleischman writes... > If one defines authentication to be "proving that an entity is who it > claims to be", then authenticating an anonymous entity is simply proving > that the entity has no specific identity to that system. Well, this *is* a rathole, but I'll go one more round. :-) I support Glen Zorn's assertion. You are attempting to prove a negative. As an example, please *prove* to me that you and I have never met and that you would not recognize me on the street. Assume that I've provided you no credentials, and that my e-mail username may very well be a pseudonym. I respectfully suggest that the term "anonymous access" or the term "non-authenticated access" would accurately describe the feature under discussion. I agree that the term "authenticated anonymous access" is an oxymoron. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 16:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVdx-0005JH-Hu; Tue, 25 Oct 2005 16:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVdv-0005Ip-WA for isms@megatron.ietf.org; Tue, 25 Oct 2005 16:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06088 for ; Tue, 25 Oct 2005 16:43:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVqu-00078d-Q2 for isms@ietf.org; Tue, 25 Oct 2005 16:57:01 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 13:42:59 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356604642:sNHT904248258" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9PKgtud008024; Tue, 25 Oct 2005 13:42:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 13:48:26 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906265726@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAAOxXVAAAJsOAAABDOtQ From: "Salowey, Joe" To: "Nelson, David" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Mapping does not always require per-user local configuration. In the case where you are mapping a mechanism specific name to an application usable name the configuration is often a set of rules that apply to all (or a subset) of entities authenticated by a particular method. For example for an X.509 PKC you may have a rule that selects the appropriate field from the cert (such as DN) and applies some processing on that field (removal of ASN.1, selection of a name element). It is possible for the rules for one application to differ from another. =20 In some cases an entity wants to assert a name that it wants to use to reduce ambiguity in mapping to an application usable name or to be used instead of an authenticated mechanism specific name. This could be accomplished in SSHSM though the SNMP securityName field. This could also be done in SSH for some authentication mechanisms where an asserted name is allowed in addition to the authenticated name (I think the SSH specs are a bit vague on this). The verifier needs to validate that the asserted name is a valid alias for the authenticated name. Depending on the mapping function this could involve the use of information from a third party and/or local configuration.=20 I think mapping will need to happen and that mapping functions may vary from deployment to deployment. It seems useful for an entity to be able to assert a name it wants to use. Mapping can happen within the SSH implementation without direct involvement of SSHSM. If the securityName field in the SNMP message then SSHSM would need to be involved in the mapping. Doing the mapping in SSHSM adds complexity and probably should be at most optional (the complexity might be less if we had a decent name mapping API). =20 It is also possible that additional mapping may be desired for authorization mechanism specific attributes such as groups, roles etc. While these are also interesting, I think they are currently out of scope.=20 Joe > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com]=20 > Sent: Tuesday, October 25, 2005 11:10 AM > To: isms@ietf.org > Subject: RE: [Isms] #32: is the securityName=3Dusername default OK? >=20 > David B Harrington writes... >=20 > > I think this discussion is going off into ratholes. >=20 > What may be a rathole of inconsequential detail for one may=20 > be a fundamental requirement for another. YMMV. >=20 > > Allowing for > > static configuration does not REQUIRE static copnfiguration, nor=20 > > preclude dynamic configuration; Allowing for dynamic configuration=20 > > does not preclude static configuration where desired. >=20 > Granted. I see no harm is allowing the option for local,=20 > static authentication information. OTOH, my opinion is that,=20 > if local, static authentication information is *all* you=20 > need, then USM meets your requirements today. >=20 > > A AAA system could provide a mapping that is stored in the=20 > LCD as part=20 > > of the session configuration. In this case, the securityname is not=20 > > necessarily the same as the username used for authentication. For=20 > > example, RADIUS permits sending an accounting identity to=20 > be sent as=20 > > part of the ACCESS-ACCEPT message, if I recall correctly.=20 > This could=20 > > be stored in the LCD and thus be "picked up" as the value for=20 > > securityName rather than defaulting to the "username" field=20 > from the=20 > > ACCESS-REQUEST message (which is the current source for the=20 > tm-cached=20 > > identity). >=20 > It could, but why is this a requirement for ISMS? I may be=20 > dense, but I still fail to see the value added by this=20 > additional complexity. >=20 > > If desired, an SNMP MIB could be designed, comparable to=20 > the USM-MIB,=20 > > that permitted static assignemnts of usernames to securityNames. >=20 > Yes, and that would make ISMS significantly different from=20 > USM in what way? > =20 > > If desired, an LCD, possibly but not necessarily in MIB=20 > format, could=20 > > be populated using CLI scripts or other non-SNMP configuration. >=20 > Ditto. >=20 > I don't object to a "compatibility" mode for ISMS in which it=20 > effectively behaves as USM, but if that is all we see as=20 > needed, then I suggest we don't bother and close the WG. I=20 > firmly believe that in order to be successful, and solve the=20 > customer problems that USM does not solve, that ISMS MUST=20 > have a mandatory to implement mode of operation in which it=20 > is fully independent of any locally configured per-user (or=20 > per-meta-user) authentication information. >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 18:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWwc-0005eH-4L; Tue, 25 Oct 2005 18:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWwa-0005aj-MC for isms@megatron.ietf.org; Tue, 25 Oct 2005 18:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18090 for ; Tue, 25 Oct 2005 18:06:41 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUX9b-0003tj-O9 for isms@ietf.org; Tue, 25 Oct 2005 18:20:25 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9PM6HBv021830; Tue, 25 Oct 2005 15:06:18 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Oct 2005 15:07:41 -0700 Message-ID: From: "McDonald, Ira" To: "'Fleischman, Eric'" , "Glen Zorn (gwz)" , "Joseph Salowey (jsalowey)" , ietfdbh@comcast.net, "Blumenthal, Uri" , isms@ietf.org Subject: RE: [Isms] #1: is it important to support anonymous user accessto SNMP? Date: Tue, 25 Oct 2005 15:07:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, The example given for the utility of 'anonymous authentication' (which term is not merely an oxymoron, but actual gibberish) was printer discovery via SNMP in an enterprise network. Speaking from ten years in the printing industry, I'd like to point out that printer vendors intensely dislike the use of SNMP as a printer discovery mechanism, because it invariably angers the network support staff of large enterprise networks. So print clients and printer monitors written by printer vendors have for some years shipped with the SNMP printer discovery feature DISABLED and typically warn the end user in two levels of 'are you sure?' dialog boxes before attempting it. This is NOT a realistic or suitable scenario to justify support of this 'anonymous authentication' feature in ISMS. Cheers, - Ira (co-editor of Printer MIB v2) Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Fleischman, Eric > Sent: Tuesday, October 25, 2005 3:35 PM > To: Glen Zorn (gwz); Joseph Salowey (jsalowey); ietfdbh@comcast.net; > Blumenthal, Uri; isms@ietf.org > Subject: RE: [Isms] #1: is it important to support anonymous user > accesstoSNMP? > > > Glen, > > Since I've scribbled once, I may as well scribble again to > respectfully > disagree with your posting: > If one defines authentication to be "proving that an entity is who it > claims to be", then authenticating an anonymous entity is > simply proving > that the entity has no specific identity to that system. > > It is a separate issue as to whether anonymous authentication > is needed > or not within ISMS. I originally thought that it anonymity was not > desirable in network management (i.e., the perspective I surmise that > you hold), but David Perkin's subsequent arguments convinced me that > there is a potential need to support anonymous entities. It also is a > separate issue as to how authorization should relate to > authentication. > > --Eric > > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > > Fleischman, Eric <> supposedly scribbled: > > > This discussion appears to me to have been coupling authentication > > with authorization. If we permit the authentication of an > "anonymous" > > entity, then the question of whether or not that entity is > authorized > > to do anything useful is a policy issue. > > The term "authentication" doesn't seem to apply to anonymous entities. > > Hope this helps, > > ~gwz > > W > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 18:32:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXLc-0005CT-V2; Tue, 25 Oct 2005 18:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXLc-0005CO-4q for isms@megatron.ietf.org; Tue, 25 Oct 2005 18:32:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19680 for ; Tue, 25 Oct 2005 18:32:32 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXYb-0004gQ-JL for isms@ietf.org; Tue, 25 Oct 2005 18:46:17 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA24096; Tue, 25 Oct 2005 17:32:20 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9PMWJJ01865; Tue, 25 Oct 2005 15:32:19 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 15:32:19 -0700 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] #1: is it important to support anonymous user accesstoSNMP? Date: Tue, 25 Oct 2005 15:32:18 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBCA1D@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXZsFfDJwy4kd+fRXOZZlm3MevdogAAD7ig From: "Fleischman, Eric" To: "McDonald, Ira" , "Glen Zorn \(gwz\)" , "Joseph Salowey \(jsalowey\)" , , "Blumenthal, Uri" , , "David T. Perkins" X-OriginalArrivalTime: 25 Oct 2005 22:32:19.0437 (UTC) FILETIME=[F5B1C9D0:01C5D9B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ira, Thank you for this insightful posting. Perhaps I was too easily swayed, but the thoughts within David Perkin's postings that I resonated with are the following points (i.e., not the printing example that you cited): 1) David Perkins argument about the need for ""anonymous clients" retrieving info via an authenticated server via a channel with integrity and possibly encryption" 2) Joe Touch's ideas about the need for a "minimalist" security options (i.e., something between none and plenty) such as http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/dra ft-touch-anonsec-00.txt 3) My own Fear, Uncertainty, and Doubt (FUD) as I remembered how often I have failed to think of important use cases in the past and a desire therefore to avoid being painted into a corner in the future by my own lack of foresight. Do any of these points resonate with you? --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 18:36:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXPI-0006SX-MY; Tue, 25 Oct 2005 18:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXPH-0006SS-6a for isms@megatron.ietf.org; Tue, 25 Oct 2005 18:36:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19863 for ; Tue, 25 Oct 2005 18:36:19 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXcG-0004mn-T1 for isms@ietf.org; Tue, 25 Oct 2005 18:50:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 837E6E0038; Tue, 25 Oct 2005 18:36:30 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] #32: is the securityName=username default OK? References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F38A@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Tue, 25 Oct 2005 18:36:30 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F38A@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Tue, 25 Oct 2005 10:19:57 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> AAA systems almost always authenticate humans. Even when Nelson,> they don't, the protocols have been designed for Nelson,> authentication of humans. That pretty much guarantees Nelson,> that the basic identity nomenclature (the username) will Nelson,> be human readable, because it has to be human writeable Nelson,> (e.g. entered by a human at a keyboard). I believe you Nelson,> can assume and require that tmSecurityName be human Nelson,> readable without any loss of generality, even when the Nelson,> credentials are in a more complex form, such as digital Nelson,> certificates. I believe that assuming Tmsecurityname is human readable is in general false. There are too many complicated problems having to do with choosing the right name and various things people want to put in a name. I believe that you can assume the ssh username is human readable and agree with david that you do not want per-user configuration. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 22:40:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbDf-00018E-0N; Tue, 25 Oct 2005 22:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbDd-000183-Fu for isms@megatron.ietf.org; Tue, 25 Oct 2005 22:40:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15291 for ; Tue, 25 Oct 2005 22:40:33 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUbQg-0007NL-MP for isms@ietf.org; Tue, 25 Oct 2005 22:54:19 -0400 Received: from h-68-166-38-185.snvacaid.dynamic.covad.net ([68.166.38.185] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EUbDU-0005XX-00 for isms@ietf.org; Tue, 25 Oct 2005 22:40:40 -0400 Message-ID: <008b01c5d9d7$31f40980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F38A@MAANDMBX2.ets.enterasys.com> Subject: Re: [Isms] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 19:44:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Sam Hartman" > To: "Nelson, David" > Cc: > Sent: Tuesday, October 25, 2005 3:36 PM > Subject: Re: [Isms] #32: is the securityName=username default OK? ... > I believe that assuming Tmsecurityname is human readable is in general > false. There are too many complicated problems having to do with > choosing the right name and various things people want to put in a > name. > > I believe that you can assume the ssh username is human readable and > agree with david that you do not want per-user configuration. ... By the time one gets to VACM, it will have to have been somehow trasformed into an SnmpAdminString (that's the syntax of vacmSecurityName, UTF-8) which means there's a fairly strong assumption that it's going to be seen by humans. The textual convention is written to cope with non-displayable stuff, but the advice on its use in RFC 3411 seems pretty clear. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Oct 25 22:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbG2-00026b-Tq; Tue, 25 Oct 2005 22:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbG1-00024o-B3 for isms@megatron.ietf.org; Tue, 25 Oct 2005 22:43:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15477 for ; Tue, 25 Oct 2005 22:43:01 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUbT5-0007TU-SS for isms@ietf.org; Tue, 25 Oct 2005 22:56:48 -0400 Received: from h-68-166-38-185.snvacaid.dynamic.covad.net ([68.166.38.185] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EUbFz-00068G-00 for isms@ietf.org; Tue, 25 Oct 2005 22:43:15 -0400 Message-ID: <008e01c5d9d7$8ef760a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <7210B31550AC934A8637D6619739CE6906265726@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: [Isms] #32: is the securityName=username default OK? Date: Tue, 25 Oct 2005 19:46:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Salowey, Joe" > To: "Nelson, David" ; > Sent: Tuesday, October 25, 2005 1:48 PM > Subject: RE: [Isms] #32: is the securityName=username default OK? ... > I think mapping will need to happen and that mapping functions may vary > from deployment to deployment. It seems useful for an entity to be able > to assert a name it wants to use. Mapping can happen within the SSH > implementation without direct involvement of SSHSM. If the securityName > field in the SNMP message then SSHSM would need to be involved in the > mapping. Doing the mapping in SSHSM adds complexity and probably should > be at most optional (the complexity might be less if we had a decent > name mapping API). ... Do you envision that these mappings would be configured via a MIB, or would some other mechanism ensure that the various implementations in a deployment were using the right mappings? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 26 00:52:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUdHW-0000sN-03; Wed, 26 Oct 2005 00:52:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUdHU-0000s6-58 for isms@megatron.ietf.org; Wed, 26 Oct 2005 00:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21977 for ; Wed, 26 Oct 2005 00:52:40 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUdUY-0002PA-8W for isms@ietf.org; Wed, 26 Oct 2005 01:06:28 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc13) with SMTP id <2005102604524301500bampie>; Wed, 26 Oct 2005 04:52:44 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] #32: is the securityName=username default OK? Date: Wed, 26 Oct 2005 00:52:37 -0400 Message-ID: <021001c5d9e9$175b1660$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXYkT8T5cFQXYHGTcy6SSxUPgCMvgAFutBAAAGnAlAAMmSmMAAA/K5gAALKJnAAAM3ZYAABIR0wAAFS4oAAFOpq4A== In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F395@MAANDMBX2.ets.enterasys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Yes. As long as the Kerberos users and AAA users aren't saddled with > the requirement to implement and configure localized user > authentication > information in the managed entity, I suppose that's all fine. Nobody has proposed that localized user mapping to securityName is a requirement to support Kerberos and AAA security models. It is just an option to allow administrators to run their networks as they see fit, rather than as the designers of Kerberos or AAA solutions think they should. And it is a requirmeent that SNMP still be able to work when Kerberos and AAA servers cannot be reached, so allowing for local authentication is important. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 26 19:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUuUB-0007yw-RI; Wed, 26 Oct 2005 19:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUuU9-0007y7-Mx for isms@megatron.ietf.org; Wed, 26 Oct 2005 19:15:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13081 for ; Wed, 26 Oct 2005 19:14:53 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuhN-0003tb-Ss for isms@ietf.org; Wed, 26 Oct 2005 19:28:51 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2005 16:14:58 -0700 X-IronPort-AV: i="3.97,255,1125903600"; d="scan'208"; a="357219854:sNHT24879408" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QNEuJh029190; Wed, 26 Oct 2005 16:14:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] #32: is the securityName=username default OK? Date: Wed, 26 Oct 2005 16:20:27 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906265B29@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] #32: is the securityName=username default OK? Thread-Index: AcXZ1/IiEAbzMBfoSSWreiaDpWdVLgAqfNiA From: "Salowey, Joe" To: "Randy Presuhn" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Tuesday, October 25, 2005 7:47 PM > To: isms@ietf.org > Subject: Re: [Isms] #32: is the securityName=3Dusername default OK? >=20 > Hi - >=20 > > From: "Salowey, Joe" > > To: "Nelson, David" ; > > Sent: Tuesday, October 25, 2005 1:48 PM > > Subject: RE: [Isms] #32: is the securityName=3Dusername default OK? > ... > > I think mapping will need to happen and that mapping functions may=20 > > vary from deployment to deployment. It seems useful for an=20 > entity to=20 > > be able to assert a name it wants to use. Mapping can=20 > happen within=20 > > the SSH implementation without direct involvement of SSHSM. If the=20 > > securityName field in the SNMP message then SSHSM would need to be=20 > > involved in the mapping. Doing the mapping in SSHSM adds=20 > complexity=20 > > and probably should be at most optional (the complexity=20 > might be less if we had a decent > > name mapping API). =20 > ... >=20 > Do you envision that these mappings would be configured via a=20 > MIB, or would some other mechanism ensure that the various=20 > implementations in a deployment were using the right mappings? >=20 [Joe] Often I would expect there would be some reasonable default behavior that would fit many cases. If an override is necessary then these configurations could be part of a MIB. The question is it a part of an SSH MIB or an SSHSM MIB. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Oct 26 23:16:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyFu-0006tB-CY; Wed, 26 Oct 2005 23:16:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyFr-0006t2-4z for isms@megatron.ietf.org; Wed, 26 Oct 2005 23:16:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18588 for ; Wed, 26 Oct 2005 23:16:23 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUyT7-0004pk-J0 for isms@ietf.org; Wed, 26 Oct 2005 23:30:22 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9R3GTBT004314; Wed, 26 Oct 2005 20:16:29 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9R3GMRg001217; Wed, 26 Oct 2005 20:16:22 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9R3GLmi001204; Wed, 26 Oct 2005 20:16:22 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 26 Oct 2005 20:16:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Glen Zorn (gwz)" Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625EB7744@xmb-sjc-215.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Glen - what terminology would you want all to use when discussing: client identity is not authenticated server identity is authenticated session data is integrity checked Regards, /david t. perkins On Mon, 24 Oct 2005, Glen Zorn (gwz) wrote: > Fleischman, Eric <> supposedly scribbled: > > > This discussion appears to me to have been coupling authentication > > with authorization. If we permit the authentication of an "anonymous" > > entity, then the question of whether or not that entity is authorized > > to do anything useful is a policy issue. > > The term "authentication" doesn't seem to apply to anonymous entities. > > Hope this helps, > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 27 12:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAhc-0006WT-JL; Thu, 27 Oct 2005 12:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAhb-0006WL-Id for isms@megatron.ietf.org; Thu, 27 Oct 2005 12:34:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13091 for ; Thu, 27 Oct 2005 12:33:51 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAuz-0002eB-9G for isms@ietf.org; Thu, 27 Oct 2005 12:47:58 -0400 Received: from [192.168.0.24] (dhcp.pacifictokyo.jp [219.101.140.1]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 44A471BAC4D for ; Thu, 27 Oct 2005 18:33:53 +0200 (CEST) Date: Thu, 27 Oct 2005 18:33:55 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] draft agenda for Vancouver meeting 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Below please find the draft agenda for our meeting in Vancouver. If you have any comments, please contact Juergen Schoenwaelder or myself. Thanks, Juergen Q. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Integrated Security Model for SNMP WG (isms) Tuesday November 8 at 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =B4 CHAIRS: Juergen Schoenwaelder Juergen Quittek AGENDA: 1) Administrivia, Agenda bashing ( 5 min) 2) Report from the RADEXT meeting (10 min) 3) Discussion of SSH model open issues (50 min) - draft-ietf-isms-secshell-00.txt 4) Discussion of TMSM open issues (50 min) - draft-ietf-isms-tmsm-00.txt 5) Wrap up ( 5 min) - review of action points INTERNET DRAFTS: - Secure Shell Security Model for SNMP - Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol RELATED DRAFTS: - RADIUS NAS-Management Authorization - SNMP Agent Discovery under SSH Transport _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Oct 27 13:12:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBId-0008NT-TO; Thu, 27 Oct 2005 13:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBIb-0008Kh-2v for isms@megatron.ietf.org; Thu, 27 Oct 2005 13:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16208 for ; Thu, 27 Oct 2005 13:12:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBVz-0004D4-A0 for isms@ietf.org; Thu, 27 Oct 2005 13:26:12 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2005 10:12:11 -0700 X-IronPort-AV: i="3.97,259,1125903600"; d="scan'208"; a="357556496:sNHT24695692" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9RHBPKF026349; Thu, 27 Oct 2005 10:12:08 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 10:12:07 -0700 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Date: Thu, 27 Oct 2005 10:12:06 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625EB817E@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXapNHCsA5mAp6+TRCaUophMAnOqQAc9IUg From: "Glen Zorn \(gwz\)" To: "David T. Perkins" X-OriginalArrivalTime: 27 Oct 2005 17:12:07.0991 (UTC) FILETIME=[8F9B4470:01C5DB19] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David T. Perkins supposedly scribbled: > HI, >=20 > Glen - what terminology would you want all to use when discussing: > client identity is not authenticated > server identity is authenticated > session data is integrity checked How about "server-side authentication"? That seems to sum it up to me. = What is done w/the session data stream (integrity protection, = encryption, etc.) seems to be a different question insofar as data = protection isn't entailed by authentication. >=20 > Regards, > /david t. perkins ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 28 09:04:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTuB-0002QM-0T; Fri, 28 Oct 2005 09:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTu9-0002Ky-NH for isms@megatron.ietf.org; Fri, 28 Oct 2005 09:04:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13135 for ; Fri, 28 Oct 2005 09:04:04 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVU7i-0004pS-Dj for isms@ietf.org; Fri, 28 Oct 2005 09:18:23 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8AD6AE0048; Fri, 28 Oct 2005 09:04:13 -0400 (EDT) To: Juergen Quittek Subject: Re: [Isms] draft agenda for Vancouver meeting References: From: Sam Hartman Date: Fri, 28 Oct 2005 09:04:13 -0400 In-Reply-To: (Juergen Quittek's message of "Thu, 27 Oct 2005 18:33:55 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi. Are there any of the issues on ssh where it might be useful to have a short presentations? For example we've seen a lot of confusion around what identities ssh uses here and the asymmetry between client and server. Do people now understand ssh well enough or would it be worth taking meeting time to discuss this? --Sam as an individual _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 28 16:27:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVapN-0002Ss-BR; Fri, 28 Oct 2005 16:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVapM-0002Sn-6k for isms@megatron.ietf.org; Fri, 28 Oct 2005 16:27:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16153 for ; Fri, 28 Oct 2005 16:27:33 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVb2y-0003co-KG for isms@ietf.org; Fri, 28 Oct 2005 16:41:57 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <200510282027410110030bkae>; Fri, 28 Oct 2005 20:27:41 +0000 From: "David B Harrington" To: "'Nelson, David'" , Date: Fri, 28 Oct 2005 16:27:37 -0400 Message-ID: <009f01c5dbfe$09d2c030$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60A= In-reply-to: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3AF@MAANDMBX2.ets.enterasys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Radext attributes X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Dave, Would SSHSM need to provide the hints that it wants RADIUS to authorize the "SNMPv3 over SSH" service? Would SSH do the RADIUS authentication before establishing the "SNMP" subsystem? If so, should the SSHSM rules for establishing the SNMP subsystem include a request for SSH to get RADIUS authorization for the "SNMPv3/SSH service"? (I'm deliberately not addressing whether there should be different SSH subsystems for notifications and request/response, to keep my question simple). dbh > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, October 27, 2005 5:58 PM > To: dbharrington@comcast.net > Cc: j.schoenwaelder@iu-bremen.de; Juergen Quittek > Subject: RE: Radext presentation > > Dave, > > This looks good to me. > > The one element that isn't included, and hasn't had much discussion in > ISMS, is the notion of the RADIUS-provisioned service. This > is often by > means of the Service-Type attribute in RADIUS, but other attributes > sub-specify specific forms of service. When these "service" > attributes > appear in an Access-Accept message, it tells the managed entity what > form of service it is to provide. When these "service" attributes > appear in an Access-Request message, they provide a hint to the RADIUS > server as to what kind of access is being requested by the user. Most > RADIUS servers use these hint attributes to select among multiple > "access profiles" available for a single user identity, enabling the > server to return the correct set of provisioning attributes in the > Access-Accept. > > I think it is important that these "service" type of > attributes for ISMS > (i.e. SNMPv3 access over SSH) are also defined, such that the hinting > and provisioning behaviors of RADIUS server can explicitly take ISMS > into account. These types of attributes and attribute values are also > included in the Management Authorization draft. This doesn't have any > direct impact on ISMS, but it will enable ISMS to integrate smoothly > into existing RADIUS deployments. > > Regards, > > Dave > > David B. Nelson > Enterasys Networks, Inc. > 50 Minuteman Road > Andover, MA 01810-1008 > Phone: (978) 684-1330 > E-mail: dnelson@enterasys.com > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Thursday, October 27, 2005 5:41 PM > > To: Nelson, David > > Cc: j.schoenwaelder@iu-bremen.de; 'Juergen Quittek' > > Subject: Radext presentation > > > > Hi, > > > > This is the first pass of the presentation for RADEXT. > > Comments welcome. > > > > David Harrington > > dbharrington@comcast.net > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 28 16:50:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbAq-00004w-6h; Fri, 28 Oct 2005 16:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbAo-0008W5-5f for isms@megatron.ietf.org; Fri, 28 Oct 2005 16:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18456 for ; Fri, 28 Oct 2005 16:49:45 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbOQ-0004az-Fw for isms@ietf.org; Fri, 28 Oct 2005 17:04:07 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA22641 for ; Fri, 28 Oct 2005 16:53:24 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma022620; Fri, 28 Oct 05 16:52:35 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 28 Oct 2005 16:49:04 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 28 Oct 2005 16:49:04 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Oct 2005 16:46:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2005 16:46:55 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3B9@MAANDMBX2.ets.enterasys.com> Thread-Topic: Radext attributes Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60AAAImIIA== From: "Nelson, David" To: , X-OriginalArrivalTime: 28 Oct 2005 20:46:56.0211 (UTC) FILETIME=[BBFF5230:01C5DC00] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] RE: Radext attributes 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave Harrington writes... =20 > Would SSHSM need to provide the hints that it wants RADIUS to > authorize the "SNMPv3 over SSH" service? It is the RADIUS Client that provides the hints. The RADIUS Client decides what hints to include in the Access-Request message based on which "access service" is requesting authentication. SSH is often the layer that makes direct use of RADIUS. If SSH were to communicate to the RADIUS Client the additional information that the requested SSH session is to be used for SSHSM, then the RADIUS Client could use that information in its hints as well. > Would SSH do the RADIUS authentication before establishing the "SNMP" > subsystem? It may be that at the time of SSH session authentication via RADIUS that SSH doesn't know what service will be run over the session. Since SSH needs to eventually re-direct the session to the SSHSM "portal", it seems that SSH will have the information sooner or later. It may also depend on implementation. I have seen Telnet over SSH implementations where the CLI "login" prompt dialogue is completed before the CLI session calls RADIUS for authentication. In that implementation it is not SSH itself that calls on RADIUS, it is the CLI session (shell, whatever) that makes the RADIUS call (in place of a check of /etc/passwd, for example). So it seems that it is possible for either SSH or SSHSM to make the call to the RADIUS Client. While this may be an implementation decision, it would be helpful to understand the data flow in each scenario. Having a clearer understanding of the existing SSH-to-RADIUS implementations may be of benefit. > If so, should the SSHSM rules for establishing the SNMP > subsystem include a request for SSH to get RADIUS authorization for > the "SNMPv3/SSH service"? I believe it would be very helpful if SSH were to know at the time of it call to the RADIUS Client that the SSH session will be user to carry SSHSM traffic. In the alternative, SSHSM could directly call the RADIUS Client itself, after the SSH session has been established. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Oct 28 18:14:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcUA-0004e3-ND; Fri, 28 Oct 2005 18:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcU8-0004aP-Th for isms@megatron.ietf.org; Fri, 28 Oct 2005 18:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23041 for ; Fri, 28 Oct 2005 18:13:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVchm-0006yA-DM for isms@ietf.org; Fri, 28 Oct 2005 18:28:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 28 Oct 2005 15:13:55 -0700 X-IronPort-AV: i="3.97,263,1125903600"; d="scan'208"; a="358203305:sNHT24611224" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9SMDC7o006886; Fri, 28 Oct 2005 15:13:52 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 15:13:50 -0700 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] RE: Radext attributes Date: Fri, 28 Oct 2005 15:13:49 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3CA0DC0@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] RE: Radext attributes Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60AAAImIIAACl8FQ From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , , X-OriginalArrivalTime: 28 Oct 2005 22:13:50.0921 (UTC) FILETIME=[E034EB90:01C5DC0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, =20 > If so, should the SSHSM rules for establishing the SNMP subsystem=20 > include a request for SSH to get RADIUS authorization for the=20 > "SNMPv3/SSH service"? I believe it would be very helpful if SSH were to know at the time of it call to the RADIUS Client that the SSH session will be user to carry SSHSM traffic. In the alternative, SSHSM could directly call the RADIUS Client itself, after the SSH session has been established. I am not sure about the alternative since the user authentication (RADIUS Access_Request) needs to happen prior to the SSH session establishment.=20 I am not sure there are means to communicate a service name in SSH and the only option might be run the SSH server on a separate port for SSHSM. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 15:19:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwEI-0001bD-9M; Sat, 29 Oct 2005 15:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwEG-0001VF-Gl for isms@megatron.ietf.org; Sat, 29 Oct 2005 15:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18821 for ; Sat, 29 Oct 2005 15:18:41 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVwS4-0004HJ-Do for isms@ietf.org; Sat, 29 Oct 2005 15:33:17 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9TJIU3B013081; Sat, 29 Oct 2005 12:18:30 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Oct 2005 12:19:59 -0700 Message-ID: From: "McDonald, Ira" To: "'Fleischman, Eric'" , "McDonald, Ira" , "Glen Zorn (gwz)" , "Joseph Salowey (jsalowey)" , ietfdbh@comcast.net, "Blumenthal, Uri" , isms@ietf.org, "David T. Perkins" Subject: RE: [Isms] #1: is it important to support anonymous user accessto SNMP? Date: Sat, 29 Oct 2005 12:19:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, Thanks for the pointer to Joe Touch's ANONsec draft from May 2004. I read it all the way through with interest. And then I discovered the recently chartered IETF BTNS (Better Than Nothing Security) WG, (http://www.ietf.org/html.charters/btns-charter.html), which has published: "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 26-Sep-05, The two independent working drafts are: "An Unauthenticated, or Leap-of-Faith-Authorization Mode for Bump-In-The-Stack Implementations of IPsec Using Internet Key Exchange Protocols", Nicolas Williams, 2-May-05, "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, 8-Sep-05, The latter is the successor to Joe Touch's original ANONsec draft. But what Joe Touch and the BTNS folks have done is give a good rationale for adding support for unauthenticated IKE SAs (Security Associations) to IKEv2. That is, the whole point of Joe's argument is that this mechanism is ONLY useful at the NETWORK layer - to protect against off-path attacks on the transport protocols - such as the serious RST attack on TCP, which cannot be defended against within TCP for long-duration connections at high data rates (above 100 Mbps), because the valid receive window simply becomes too large. I'm unpersuaded that this is a good general mechanism at the application layer (e.g., SNMP), even though it is ubiquitous in web browsing (HTTPS). This is NOT an 'authenticated' mechanism. When used at the application layer, it cannot defend against active off-path or man-in-the-middle attacks. I doubt that the reason we want networks to deploy SNMPv3 is the protocol performance improvements over SNMPv1. I think the main reason is to get them to use acceptably strong security to avoid compromising the integrity of their networks. Anonymous use access to SNMP is available now with the SNMPv1 'public' community. And it's caused a lot of serious problems. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > Sent: Tuesday, October 25, 2005 6:32 PM > To: McDonald, Ira; Glen Zorn (gwz); Joseph Salowey (jsalowey); > ietfdbh@comcast.net; Blumenthal, Uri; isms@ietf.org; David T. Perkins > Subject: RE: [Isms] #1: is it important to support anonymous user > accesstoSNMP? > > > Ira, > > Thank you for this insightful posting. Perhaps I was too > easily swayed, > but the thoughts within David Perkin's postings that I resonated with > are the following points (i.e., not the printing example that you > cited): > 1) David Perkins argument about the need for ""anonymous clients" > retrieving info via an authenticated server via a channel > with integrity > and possibly encryption" > 2) Joe Touch's ideas about the need for a "minimalist" > security options > (i.e., something between none and plenty) such as > http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet- drafts/dra ft-touch-anonsec-00.txt 3) My own Fear, Uncertainty, and Doubt (FUD) as I remembered how often I have failed to think of important use cases in the past and a desire therefore to avoid being painted into a corner in the future by my own lack of foresight. Do any of these points resonate with you? --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 15:29:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwO4-0006fT-76; Sat, 29 Oct 2005 15:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwO0-0006fC-FB for isms@megatron.ietf.org; Sat, 29 Oct 2005 15:29:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19367 for ; Sat, 29 Oct 2005 15:28:46 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVwbq-0004b6-3l for isms@ietf.org; Sat, 29 Oct 2005 15:43:22 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9TJSgLX013399; Sat, 29 Oct 2005 12:28:42 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Oct 2005 12:30:11 -0700 Message-ID: From: "McDonald, Ira" To: "'Kaushik Narayan (kaushik)'" , "Nelson, David" , dbharrington@comcast.net, isms@ietf.org Date: Sat, 29 Oct 2005 12:30:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Isms] SNMP over SSH REQUIRES a separate port 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Kaushik Narayan (kaushik) > Sent: Friday, October 28, 2005 6:14 PM > To: Nelson, David; dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] RE: Radext attributes > > ...snip... > > I am not sure there are means to communicate a service name in SSH and > the only option might be run the SSH server on a separate port for > SSHSM. I note that the IETF Netconf over SSH current draft REQUIRES a separate port: "In order to allow NETCONF traffic to be easily identified and filtered by firewalls and other network devices, NETCONF servers MUST default to providing access to the "netconf" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port . Servers SHOULD be configurable to allow access to the netconf SSH subsystem over other ports." Based on current IETF best practice, I assume the same applies to SNMP over SSH. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 15:38:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwXN-0001bt-8V; Sat, 29 Oct 2005 15:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwXL-0001bl-Fz for isms@megatron.ietf.org; Sat, 29 Oct 2005 15:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19869 for ; Sat, 29 Oct 2005 15:38:25 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVwlA-0004rP-81 for isms@ietf.org; Sat, 29 Oct 2005 15:53:01 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <20051029193832013003vkuke>; Sat, 29 Oct 2005 19:38:32 +0000 From: "David B Harrington" To: "'McDonald, Ira'" , "'Kaushik Narayan \(kaushik\)'" , "'Nelson, David'" , , Subject: RE: [Isms] RE: Radext attributes Date: Sat, 29 Oct 2005 15:38:20 -0400 Message-ID: <00be01c5dcc0$567b4d40$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXcvxND3llz3woCTYyJHBFHzjuxSwAALOlA In-reply-to: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, So does SSHSM: " In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Security Model MUST default to providing access to the "SNMP" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port (TBD). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports." That wasn't the question, though. The question was how to communicate a service name from SSHSM to RADIUS via SSH. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > Sent: Saturday, October 29, 2005 3:30 PM > To: 'Kaushik Narayan (kaushik)'; Nelson, David; > dbharrington@comcast.net; isms@ietf.org > Subject: [Isms] SNMP over SSH REQUIRES a separate port > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Kaushik Narayan (kaushik) > > Sent: Friday, October 28, 2005 6:14 PM > > To: Nelson, David; dbharrington@comcast.net; isms@ietf.org > > Subject: RE: [Isms] RE: Radext attributes > > > > ...snip... > > > > I am not sure there are means to communicate a service name > in SSH and > > the only option might be run the SSH server on a separate port for > > SSHSM. > > I note that the IETF Netconf over SSH current draft REQUIRES > a separate > port: > > "In order to allow NETCONF traffic to be easily identified and > filtered by firewalls and other network devices, NETCONF > servers MUST > default to providing access to the "netconf" SSH > subsystem only when > the SSH session is established using the IANA-assigned TCP port > . Servers SHOULD be configurable to allow access to > the netconf > SSH subsystem over other ports." > > Based on current IETF best practice, I assume the same applies to SNMP > over SSH. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 18:35:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzI3-000490-6b; Sat, 29 Oct 2005 18:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzI0-00043s-Tb for isms@megatron.ietf.org; Sat, 29 Oct 2005 18:35:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28193 for ; Sat, 29 Oct 2005 18:34:43 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVzVl-0001Ct-Qc for isms@ietf.org; Sat, 29 Oct 2005 18:49:20 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9TMYXth019215; Sat, 29 Oct 2005 15:34:33 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Oct 2005 15:36:03 -0700 Message-ID: From: "McDonald, Ira" To: "'ietfdbh@comcast.net'" , "McDonald, Ira" , "'Kaushik Narayan (kaushik)'" , "'Nelson, David'" , dbharrington@comcast.net, isms@ietf.org Subject: RE: [Isms] RE: Radext attributes Date: Sat, 29 Oct 2005 15:36:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Well if the SNMP over SSH connection arrives over a dedicated port isn't it easy to 'shim' the SSH library with for the service SNMP? SSH doesn't run in the kernel, right? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Saturday, October 29, 2005 3:38 PM > To: 'McDonald, Ira'; 'Kaushik Narayan (kaushik)'; 'Nelson, David'; > dbharrington@comcast.net; isms@ietf.org > Subject: RE: [Isms] RE: Radext attributes > > > Hi, > > So does SSHSM: > > " In order to allow SNMP traffic to be easily identified and filtered > by firewalls and other network devices, servers associated with > SNMP > entities using the Secure Shell Security Model MUST default to > providing access to the "SNMP" SSH subsystem only when the SSH > session is established using the IANA-assigned TCP port (TBD). > Servers SHOULD be configurable to allow access to the SNMP SSH > subsystem over other ports." > > That wasn't the question, though. > > The question was how to communicate a service name from SSHSM to > RADIUS via SSH. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > Sent: Saturday, October 29, 2005 3:30 PM > > To: 'Kaushik Narayan (kaushik)'; Nelson, David; > > dbharrington@comcast.net; isms@ietf.org > > Subject: [Isms] SNMP over SSH REQUIRES a separate port > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org]On > > > Behalf Of Kaushik Narayan (kaushik) > > > Sent: Friday, October 28, 2005 6:14 PM > > > To: Nelson, David; dbharrington@comcast.net; isms@ietf.org > > > Subject: RE: [Isms] RE: Radext attributes > > > > > > ...snip... > > > > > > I am not sure there are means to communicate a service name > > in SSH and > > > the only option might be run the SSH server on a separate port for > > > SSHSM. > > > > I note that the IETF Netconf over SSH current draft REQUIRES > > a separate > > port: > > > > "In order to allow NETCONF traffic to be easily identified and > > filtered by firewalls and other network devices, NETCONF > > servers MUST > > default to providing access to the "netconf" SSH > > subsystem only when > > the SSH session is established using the IANA-assigned TCP port > > . Servers SHOULD be configurable to allow access to > > the netconf > > SSH subsystem over other ports." > > > > Based on current IETF best practice, I assume the same applies to > SNMP > > over SSH. > > > > Cheers, > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 19:13:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzsz-0007f5-RD; Sat, 29 Oct 2005 19:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzsx-0007er-61 for isms@megatron.ietf.org; Sat, 29 Oct 2005 19:13:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29953 for ; Sat, 29 Oct 2005 19:12:57 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW06o-00027f-HZ for isms@ietf.org; Sat, 29 Oct 2005 19:27:34 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2005 16:13:05 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="358478936:sNHT24560932" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9TND2Jh013978; Sat, 29 Oct 2005 16:13:03 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4179.cisco.com [10.61.80.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9TNMl9T009034; Sat, 29 Oct 2005 16:22:47 -0700 Message-ID: <436401FC.2000400@cisco.com> Date: Sun, 30 Oct 2005 01:13:00 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: ietfdbh@comcast.net Subject: Re: [Isms] RE: Radext attributes References: <00be01c5dcc0$567b4d40$0300a8c0@DJYXPY41> In-Reply-To: <00be01c5dcc0$567b4d40$0300a8c0@DJYXPY41> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=314; t=1130628169; x=1131060369; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Radext=20attributes| From:Eliot=20Lear=20| Date:Sun,=2030=20Oct=202005=2001=3A13=3A00=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Iyxso1jy6mSsfRZ0DJ4d7hVJ4WMLNONbnXJAyVK3xZPePivVkygPEwGxXWqE7L+OQl8KZzcZ jAoafFf/Kndrz3pNgdqMuw5Wc5ypFxfd1O2sRvd0MHKt5Yv4XCb2E9NBxBgZJIpFww+1BpEzbB/ 6pux2DlHmVX+PG/hat6pFYRk= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, dbharrington@comcast.net 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > The question was how to communicate a service name from SSHSM to > RADIUS via SSH. Dave, Because the authentication phase occurs prior to the invocation of the SSHSM subsystem there are only two ways to convey the other side's intent: 1. use of a separate port 2. use of a username that is only authorized for SSHSM We inevitably run into namespace concerns with 2, mind you. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Oct 29 22:59:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW3Pz-0006VN-L7; Sat, 29 Oct 2005 22:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW3Pv-0006VC-Qo for isms@megatron.ietf.org; Sat, 29 Oct 2005 22:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07774 for ; Sat, 29 Oct 2005 22:59:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW3dp-0006vA-Bc for isms@ietf.org; Sat, 29 Oct 2005 23:13:53 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2005 19:59:21 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="358498884:sNHT1765297038" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9U2xIbA013069; Sat, 29 Oct 2005 19:59:19 -0700 (PDT) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 19:59:18 -0700 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: RE: [Isms] RE: Radext attributes Date: Sat, 29 Oct 2005 19:59:17 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3CA0EFB@xmb-sjc-22d.amer.cisco.com> Thread-Topic: RE: [Isms] RE: Radext attributes Thread-Index: AcXcvxND3llz3woCTYyJHBFHzjuxSwAALOlAAA9OKKA= From: "Kaushik Narayan \(kaushik\)" To: , "McDonald, Ira" , "Nelson, David" , , X-OriginalArrivalTime: 30 Oct 2005 02:59:18.0581 (UTC) FILETIME=[EB802E50:01C5DCFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Since the SSH server for SSHSM will be running on a separate port, we could have the SSH server specify the RADIUS service-name since there is only service (snmp) in question. Regards, kaushik! =20 -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Saturday, October 29, 2005 12:38 PM To: 'McDonald, Ira'; Kaushik Narayan (kaushik); 'Nelson, David'; dbharrington@comcast.net; isms@ietf.org Subject: RE: [Isms] RE: Radext attributes Hi, So does SSHSM: " In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Security Model MUST default to providing access to the "SNMP" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port (TBD). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports."=20 That wasn't the question, though.=20 The question was how to communicate a service name from SSHSM to RADIUS via SSH. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > Sent: Saturday, October 29, 2005 3:30 PM > To: 'Kaushik Narayan (kaushik)'; Nelson, David;=20 > dbharrington@comcast.net; isms@ietf.org > Subject: [Isms] SNMP over SSH REQUIRES a separate port >=20 > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Kaushik Narayan (kaushik) > > Sent: Friday, October 28, 2005 6:14 PM > > To: Nelson, David; dbharrington@comcast.net; isms@ietf.org > > Subject: RE: [Isms] RE: Radext attributes > > > > ...snip...=20 > >=20 > > I am not sure there are means to communicate a service name > in SSH and > > the only option might be run the SSH server on a separate port for=20 > > SSHSM. >=20 > I note that the IETF Netconf over SSH current draft REQUIRES a=20 > separate > port: >=20 > "In order to allow NETCONF traffic to be easily identified and > filtered by firewalls and other network devices, NETCONF servers=20 > MUST > default to providing access to the "netconf" SSH subsystem only=20 > when > the SSH session is established using the IANA-assigned TCP port > . Servers SHOULD be configurable to allow access to the=20 > netconf > SSH subsystem over other ports." >=20 > Based on current IETF best practice, I assume the same applies to SNMP > over SSH. >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) Blue Roof Music / High=20 > North Inc PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 30 14:22:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIl7-0005Tz-Re; Sun, 30 Oct 2005 14:22:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIl5-0005Se-RU for isms@megatron.ietf.org; Sun, 30 Oct 2005 14:22:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07362 for ; Sun, 30 Oct 2005 14:22:02 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWFyI-0003hp-VK for isms@ietf.org; Sun, 30 Oct 2005 11:23:52 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9UG95TU022558 for ; Sun, 30 Oct 2005 08:09:05 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 30 Oct 2005 08:10:34 -0800 Message-ID: From: "McDonald, Ira" To: isms@ietf.org Date: Sun, 30 Oct 2005 08:10:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Isms] Latest draft of TLS w/ SRP 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Although this ISMS WG has now turned away from TLS to SSH (unwisely IMHO), to set the record straight, the work on TLS w/ SRP is very much alive and well. The latest draft is: Using SRP for TLS Authentication, October 6 2005 ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt Given that the IESG is very unlikely to approve SNMP over SSH without a mandatory IANA-registered port, arguments against using TLS for ISMS seem dubious to me. Whatever security protocol is used below the SNMP application layer, the SAs (security associations) at the lower layer (SSH, TLS, whatever) and the SNMP layer will have to be securely cryptographically bound or else the SSH SA MUST require strong mutual authentication or else active man-in-the-middle attacks will be trivially easy. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Oct 30 18:42:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMp4-0001L5-PO; Sun, 30 Oct 2005 18:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMp2-0001Kt-Pu for isms@megatron.ietf.org; Sun, 30 Oct 2005 18:42:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25813 for ; Sun, 30 Oct 2005 18:42:26 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWN35-0005uy-BP for isms@ietf.org; Sun, 30 Oct 2005 18:57:17 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <200510302342270130045itse>; Sun, 30 Oct 2005 23:42:33 +0000 From: "David B Harrington" To: "'McDonald, Ira'" , Subject: RE: [Isms] Latest draft of TLS w/ SRP Date: Sun, 30 Oct 2005 18:42:14 -0500 Message-ID: <00db01c5ddab$93c5b140$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXdiHblpVK31PRORtqtzaKbO5LmIQAIu40w In-reply-to: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Ira, Did I miss something? What arguments against using TLS? I thought we simply decided that SSH seemed to be more in demand by operators for network management purposes. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > Sent: Sunday, October 30, 2005 11:11 AM > To: isms@ietf.org > Subject: [Isms] Latest draft of TLS w/ SRP > > Hi, > > Although this ISMS WG has now turned away from TLS to SSH > (unwisely IMHO), to set the record straight, the work on TLS > w/ SRP is very much alive and well. The latest draft is: > > Using SRP for TLS Authentication, October 6 2005 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt > > Given that the IESG is very unlikely to approve SNMP over SSH > without a mandatory IANA-registered port, arguments against > using TLS for ISMS seem dubious to me. > > Whatever security protocol is used below the SNMP application > layer, the SAs (security associations) at the lower layer (SSH, > TLS, whatever) and the SNMP layer will have to be securely > cryptographically bound or else the SSH SA MUST require strong > mutual authentication or else active man-in-the-middle attacks > will be trivially easy. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 08:39:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZsm-00008w-N9; Mon, 31 Oct 2005 08:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZsl-00008f-0a for isms@megatron.ietf.org; Mon, 31 Oct 2005 08:39:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08460 for ; Mon, 31 Oct 2005 08:39:07 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWa6v-0003LO-N6 for isms@ietf.org; Mon, 31 Oct 2005 08:54:07 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D3BDF4BEF2; Mon, 31 Oct 2005 14:39:15 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22619-01; Mon, 31 Oct 2005 14:39:14 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 735B14BE0D; Mon, 31 Oct 2005 14:39:13 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 8154351A249; Mon, 31 Oct 2005 14:38:10 +0100 (CET) Date: Mon, 31 Oct 2005 14:38:10 +0100 From: Juergen Schoenwaelder To: Sam Hartman Subject: Re: [Isms] draft agenda for Vancouver meeting Message-ID: <20051031133810.GC1359@boskop.local> Mail-Followup-To: Sam Hartman , Juergen Quittek , 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.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Fri, Oct 28, 2005 at 09:04:13AM -0400, Sam Hartman wrote: > Hi. Are there any of the issues on ssh where it might be useful to > have a short presentations? > > For example we've seen a lot of confusion around what identities ssh > uses here and the asymmetry between client and server. > > Do people now understand ssh well enough or would it be worth taking > meeting time to discuss this? Personally, I prefer to work through the open issues we have and to receive spontaneous education by SSH experts whenever we identify a topic where we need training. It is difficult for me to say upfront where we will need such help. (I personally believe the asymmetry is now much better understood than a few weeks ago.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 10:12:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbKj-0003RE-ED; Mon, 31 Oct 2005 10:12:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbKi-0003QQ-2O for isms@megatron.ietf.org; Mon, 31 Oct 2005 10:12:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13414 for ; Mon, 31 Oct 2005 10:12:01 -0500 (EST) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbYr-00053e-90 for isms@ietf.org; Mon, 31 Oct 2005 10:27:02 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA28368 for ; Mon, 31 Oct 2005 10:15:50 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma028349; Mon, 31 Oct 05 10:15:27 -0500 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 31 Oct 2005 10:11:54 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 31 Oct 2005 10:11:54 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Oct 2005 10:11:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] RE: Radext attributes Date: Mon, 31 Oct 2005 10:11:33 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BB@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Radext attributes Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60AAAImIIAACl8FQAIkGNFA= From: "Nelson, David" To: X-OriginalArrivalTime: 31 Oct 2005 15:11:34.0524 (UTC) FILETIME=[61C6CBC0:01C5DE2D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:84.0661 M:98.9607 P:95.9108 R:95.9108 S:71.7381 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... =20 > I am not sure about the alternative since the user > authentication (RADIUS Access_Request) needs to happen prior to the SSH > session establishment. Why? I'm not suggesting that authentication SHOULD occur after SSH session establishment, I'm merely suggestion that I don't see that it MUST occur before. Could you please elaborate? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 10:38:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbkP-0000eu-Ps; Mon, 31 Oct 2005 10:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbkO-0000ep-5O for isms@megatron.ietf.org; Mon, 31 Oct 2005 10:38:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14651 for ; Mon, 31 Oct 2005 10:38:36 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbya-0007lh-4u for isms@ietf.org; Mon, 31 Oct 2005 10:53:37 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2005 07:38:46 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="670634272:sNHT23787872" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9VFch94016693; Mon, 31 Oct 2005 07:38:44 -0800 (PST) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4447.cisco.com [10.61.81.94]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9VFmLVA020241; Mon, 31 Oct 2005 07:48:23 -0800 Message-ID: <43663A80.1060700@cisco.com> Date: Mon, 31 Oct 2005 16:38:40 +0100 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Isms] RE: Radext attributes References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BB@MAANDMBX2.ets.enterasys.com> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BB@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=656; t=1130773703; x=1131205903; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20=20Radext=20attributes| From:Eliot=20Lear=20| Date:Mon,=2031=20Oct=202005=2016=3A38=3A40=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ZmuGYtHETvQQk2y/3SC3HH7dn2ABdKjG5AOYGEPbY3eKdiwn4RMuVoYW9j93E/7BVzvRV9V0 C5dW/8q59LomWepvPRgiQlHMcshpdrELK/qjs3pwl/UWXw/TEYQFj0RHrXTdQ0QVONT1blepI87 0fN9TY+WIAtWELso53r1K07k= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Nelson, David wrote: > Kaushik Narayan writes... > >> I am not sure about the alternative since the user >> authentication (RADIUS Access_Request) needs to happen prior to the > SSH >> session establishment. > > Why? I'm not suggesting that authentication SHOULD occur after SSH > session establishment, I'm merely suggestion that I don't see that it > MUST occur before. Could you please elaborate? I think you two are talking about two different "establishment"s. In Kaushik's case he's saying that the SSHSM subsystem has not been started and so it can provide no hints to radius *unless* a separate port is in use. (It is possible albeit arguably undesirable to accomplish the same task based on specific usernames, but I think we'd all agree that's just plain ugly). Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 10:57:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc25-0004y2-8a; Mon, 31 Oct 2005 10:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc22-0004xD-Ru for isms@megatron.ietf.org; Mon, 31 Oct 2005 10:57:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15671 for ; Mon, 31 Oct 2005 10:56:50 -0500 (EST) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcG8-0001e4-S1 for isms@ietf.org; Mon, 31 Oct 2005 11:11:52 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9VFv08c021235 for ; Mon, 31 Oct 2005 10:57:00 -0500 (EST) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 31 Oct 2005 10:57:00 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 31 Oct 2005 10:57:00 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Oct 2005 10:54:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] RE: Radext attributes Date: Mon, 31 Oct 2005 10:54:36 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BC@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Radext attributes Thread-Index: AcXeMTKm9Mf/98AdRSKcwov6V3/8aQAANoDw From: "Nelson, David" To: X-OriginalArrivalTime: 31 Oct 2005 15:54:37.0305 (UTC) FILETIME=[653BE690:01C5DE33] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0659 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot Lear writes... =20 > I think you two are talking about two different "establishment"s. Perhaps... > In Kaushik's case he's saying that the SSHSM subsystem has not=20 > been started and so it can provide no hints to radius *unless* a=20 > separate port is in use. My suggestion was that it is possible to defer RADIUS authentication until SSHSM starts, and let it do the RADIUS Client calls. I have seen implementations of Telnet over SSH where this approach has been taken. SSH supplies privacy and Telnet (CLI "login" session) provides authentication and authorization. I'm not suggesting that to be the preferred implementation, just observing that it is a possible implementation. > (It is possible albeit arguably undesirable to accomplish the same > task based on specific usernames, but I think we'd all agree that's just > plain ugly). Agreed. So, if I understand the flow correctly, a "generic" SSH session is opened between manager and agent (OK, for the purists, between the peers). After that has occurred, SSHSM then uses the SSH session to spawn an SSMSM session. Is that the model? What system component (e.g. listener) is the SSH session connected to at the agent, that receives the command to initiate an SSHSM session? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 11:18:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcMd-0003eD-2S; Mon, 31 Oct 2005 11:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcMb-0003c7-Hc for isms@megatron.ietf.org; Mon, 31 Oct 2005 11:18:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18096 for ; Mon, 31 Oct 2005 11:18:05 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcan-0004oY-I9 for isms@ietf.org; Mon, 31 Oct 2005 11:33:06 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2005 08:18:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9VGHnbS015811; Mon, 31 Oct 2005 08:18:12 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 08:18:11 -0800 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] RE: Radext attributes Date: Mon, 31 Oct 2005 08:18:10 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C3CA1019@xmb-sjc-22d.amer.cisco.com> Thread-Topic: [Isms] RE: Radext attributes Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60AAAImIIAACl8FQAIkGNFAAAiwmYA== From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , X-OriginalArrivalTime: 31 Oct 2005 16:18:11.0393 (UTC) FILETIME=[B0189B10:01C5DE36] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, You mentioned that "SSHSM could directly call the RADIUS Client itself, after the SSH session has been established" I wasn't sure of this assessment since SSHSM might not be involved during SSH session establishment and it might not be possible to have the SSHSM call the RADIUS client. I was suggesting that since we have a separate port for SSHSM, the SSH server can always call the RADIUS client with service=3Dsnmp. Regards, kaushik! -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David Sent: Monday, October 31, 2005 7:12 AM To: isms@ietf.org Subject: RE: [Isms] RE: Radext attributes Kaushik Narayan writes... =20 > I am not sure about the alternative since the user=20 > authentication (RADIUS Access_Request) needs to happen prior to the SSH > session establishment. Why? I'm not suggesting that authentication SHOULD occur after SSH session establishment, I'm merely suggestion that I don't see that it MUST occur before. Could you please elaborate? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 11:30:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcYc-0007YT-D1; Mon, 31 Oct 2005 11:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcYa-0007Xg-HI for isms@megatron.ietf.org; Mon, 31 Oct 2005 11:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18793 for ; Mon, 31 Oct 2005 11:30:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcmn-0005oG-0l for isms@ietf.org; Mon, 31 Oct 2005 11:45:30 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2005 08:30:38 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9VGUaJh027686; Mon, 31 Oct 2005 08:30:36 -0800 (PST) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4447.cisco.com [10.61.81.94]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9VGeDm2020734; Mon, 31 Oct 2005 08:40:15 -0800 Message-ID: <436646A9.9090804@cisco.com> Date: Mon, 31 Oct 2005 17:30:33 +0100 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Isms] RE: Radext attributes References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BC@MAANDMBX2.ets.enterasys.com> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BC@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=456; t=1130776816; x=1131209016; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20=20Radext=20attributes| From:Eliot=20Lear=20| Date:Mon,=2031=20Oct=202005=2017=3A30=3A33=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ewbRwYFtQeiuESeMjyuumw+3Sz2FQPGk5pCVNmJRMmasclxOWwF11j9rNf9hGWdJHauwC9Ob 9W+HOU7NvN7DZ8VId279liNMqgvxP0dYdZXk09GuB2QPnHgCUXE05LYwBA+fykxeTIG73gumyva WptVAXTlHgdB8C6wf8AOyzs0= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Nelson, David wrote: > So, if I understand the flow correctly, a "generic" SSH session is > opened between manager and agent (OK, for the purists, between the > peers). After that has occurred, SSHSM then uses the SSH session to > spawn an SSMSM session. Is that the model? What system component (e.g. > listener) is the SSH session connected to at the agent, that receives > the command to initiate an SSHSM session? If I understand SSH parlance correctly this would be part of the connection service, at the same point as "session" or "netconf". Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 11:34:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcbu-0008Qo-2W; Mon, 31 Oct 2005 11:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcbs-0008Pr-AX for isms@megatron.ietf.org; Mon, 31 Oct 2005 11:34:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19026 for ; Mon, 31 Oct 2005 11:33:52 -0500 (EST) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcpk-000699-Pf for isms@ietf.org; Mon, 31 Oct 2005 11:48:54 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j9VGXm8c022710 for ; Mon, 31 Oct 2005 11:33:48 -0500 (EST) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 31 Oct 2005 11:33:49 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 31 Oct 2005 11:33:49 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Oct 2005 11:32:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] RE: Radext attributes Date: Mon, 31 Oct 2005 11:32:51 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690141F3BD@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Radext attributes Thread-Index: AcXbPycua1xLCJI2RJC/rCVmZln8tAAAOawwAC8X60AAAImIIAACl8FQAIkGNFAAAiwmYAAAqfCw From: "Nelson, David" To: X-OriginalArrivalTime: 31 Oct 2005 16:32:53.0633 (UTC) FILETIME=[BDF3BF10:01C5DE38] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.2169 P:95.9108 R:95.9108 S:57.2403 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... =20 > I wasn't sure of this assessment since SSHSM might not be involved > during SSH session establishment ... Correct. It might not. > ... and it might not be possible to have > the SSHSM call the RADIUS client. I don't see why not? Both exist on the managed entity. This is simply a matter of the necessary API. =20 > I was suggesting that since we have a separate port for SSHSM, the SSH > server can always call the RADIUS client with service=3Dsnmp. Agreed. That may be a good thing to do, in any event. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 11:43:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWckp-0002RI-9F; Mon, 31 Oct 2005 11:43:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWckm-0002Qj-R0 for isms@megatron.ietf.org; Mon, 31 Oct 2005 11:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19485 for ; Mon, 31 Oct 2005 11:43:04 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcyx-0007G0-OK for isms@ietf.org; Mon, 31 Oct 2005 11:58:06 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9VGh2ex020753; Mon, 31 Oct 2005 08:43:02 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Oct 2005 08:44:35 -0800 Message-ID: From: "McDonald, Ira" To: "'ietfdbh@comcast.net'" , "McDonald, Ira" , isms@ietf.org Subject: RE: [Isms] Latest draft of TLS w/ SRP Date: Mon, 31 Oct 2005 08:44:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Well - certainly many routers and middleboxes support _some_ form of some protocol they call 'SSH'. But it's noteworthy that SSH2 (the current version) is still in the RFC Editor's queue. And that SSH1 and SSH2 (specifically the modules from SSH Communications Security Corp who hold the trademark on 'SSH' in many countries) do NOT interoperate. The quality of open source implementations of SSH is vastly inferior to the open source implementations of TLS, as has been noted on this mailing list. The fairly arbitrary choice of SSH over TLS forced the ISMS WG move to SNMP over TCP connections (with all the attendant vulnerabilities of TCP and of long-term connections). A TLS choice would have permitted the use of DTLS (also now in the RFC Editor's queue as Proposed Standard), which would have allowed ISMS to use UDP (the traditional SNMP transport). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Sunday, October 30, 2005 6:42 PM > To: 'McDonald, Ira'; isms@ietf.org > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > Hi Ira, > > Did I miss something? What arguments against using TLS? > > I thought we simply decided that SSH seemed to be more in demand by > operators for network management purposes. > > dbh > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > Sent: Sunday, October 30, 2005 11:11 AM > > To: isms@ietf.org > > Subject: [Isms] Latest draft of TLS w/ SRP > > > > Hi, > > > > Although this ISMS WG has now turned away from TLS to SSH > > (unwisely IMHO), to set the record straight, the work on TLS > > w/ SRP is very much alive and well. The latest draft is: > > > > Using SRP for TLS Authentication, October 6 2005 > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt > > > > Given that the IESG is very unlikely to approve SNMP over SSH > > without a mandatory IANA-registered port, arguments against > > using TLS for ISMS seem dubious to me. > > > > Whatever security protocol is used below the SNMP application > > layer, the SAs (security associations) at the lower layer (SSH, > > TLS, whatever) and the SNMP layer will have to be securely > > cryptographically bound or else the SSH SA MUST require strong > > mutual authentication or else active man-in-the-middle attacks > > will be trivially easy. > > > > Cheers, > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 12:46:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdjV-0001I5-9C; Mon, 31 Oct 2005 12:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdjS-0001Hp-Hy for isms@megatron.ietf.org; Mon, 31 Oct 2005 12:46:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23389 for ; Mon, 31 Oct 2005 12:45:42 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdxc-00041T-9i for isms@ietf.org; Mon, 31 Oct 2005 13:00:45 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA13553; Mon, 31 Oct 2005 09:45:45 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VHjjH23410; Mon, 31 Oct 2005 09:45:45 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 09:45:45 -0800 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] #1: is it important to support anonymous user accesstoSNMP? Date: Mon, 31 Oct 2005 09:45:44 -0800 Message-ID: <474EEBD229DF754FB83D256004D02108BBCA34@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] #1: is it important to support anonymous user accesstoSNMP? Thread-Index: AcXcvZDDN6fvPoRiTFGMl2fb7yv3VQBhIOTQ From: "Fleischman, Eric" To: "McDonald, Ira" , "Glen Zorn \(gwz\)" , "Joseph Salowey \(jsalowey\)" , , "Blumenthal, Uri" , , "David T. Perkins" X-OriginalArrivalTime: 31 Oct 2005 17:45:45.0161 (UTC) FILETIME=[EB95FB90:01C5DE42] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Ira, Thank you for considering these issues and evaluating them in regards to ISMS. I certainly concur with you that the primary goal of ISMS is to improve upon SNMPv3 security. I am also aware of the problems that have been occuring with the SNMP "public" community. Thus, unless somebody can identify an actual requirement for "anonymous users" within SNMP, you have convinced me that providing an anonymous authentication possibility (i.e., solely for FUD reasons) is not something we want to do in ISMS. --Eric -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com]=20 Sent: Saturday, October 29, 2005 12:20 PM To: Fleischman, Eric; McDonald, Ira; Glen Zorn (gwz); Joseph Salowey (jsalowey); ietfdbh@comcast.net; Blumenthal, Uri; isms@ietf.org; David T. Perkins Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP? Hi Eric, Thanks for the pointer to Joe Touch's ANONsec draft from May 2004. I read it all the way through with interest. And then I discovered=20 the recently chartered IETF BTNS (Better Than Nothing Security) WG,=20 (http://www.ietf.org/html.charters/btns-charter.html), which has published: "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 26-Sep-05, The two independent working drafts are: "An Unauthenticated, or Leap-of-Faith-Authorization Mode for Bump-In-The-Stack Implementations of IPsec Using Internet Key Exchange Protocols", Nicolas Williams, 2-May-05, "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, 8-Sep-05, The latter is the successor to Joe Touch's original ANONsec draft. But what Joe Touch and the BTNS folks have done is give a good rationale for adding support for unauthenticated IKE SAs (Security Associations) to=20 IKEv2. That is, the whole point of Joe's argument is that this mechanism is ONLY useful at the NETWORK layer - to protect against off-path attacks on the transport protocols - such as the serious RST attack on TCP, which cannot be defended against within TCP for long-duration connections at high data=20 rates (above 100 Mbps), because the valid receive window simply becomes=20 too large. I'm unpersuaded that this is a good general mechanism at the application layer (e.g., SNMP), even though it is ubiquitous in web browsing (HTTPS). This is NOT an 'authenticated' mechanism. When used at the application=20 layer, it cannot defend against active off-path or man-in-the-middle attacks. I doubt that the reason we want networks to deploy SNMPv3 is the protocol performance improvements over SNMPv1. I think the main reason is to get them to use acceptably strong security to avoid compromising the integrity of their networks. Anonymous use access to SNMP is available now with the SNMPv1 'public' community. And it's caused a lot of serious problems. Cheers, - Ira _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 15:32:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgK2-0008WT-EC; Mon, 31 Oct 2005 15:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgJy-0008Vp-FG for isms@megatron.ietf.org; Mon, 31 Oct 2005 15:31:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06064 for ; Mon, 31 Oct 2005 15:31:38 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgYD-0007mJ-Tr for isms@ietf.org; Mon, 31 Oct 2005 15:46:42 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2005 12:31:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9VKVgJl008855; Mon, 31 Oct 2005 12:31:47 -0800 (PST) Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 12:31:44 -0800 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] Latest draft of TLS w/ SRP Date: Mon, 31 Oct 2005 12:31:44 -0800 Message-ID: Thread-Topic: [Isms] Latest draft of TLS w/ SRP Thread-Index: AcXeOlPA2ANSPs0SRiWrqMw5gfkEGgAG9UHQ From: "Khanh Nguyen \(khanhvn\)" To: "McDonald, Ira" , , X-OriginalArrivalTime: 31 Oct 2005 20:31:44.0980 (UTC) FILETIME=[1C19C140:01C5DE5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think it's too late now to go back to the SSH vs TLS discussion. But if we do decide to reconsider, I definitely go with TLS+SRP. I believe SRP is the ideal authentication method for SNMP because the passwords can be used for not only client (manager) but also server (agent) authentication, so you don't need PKI, Kerberos, or other heavy-weight infrastructure for server auth. Unfortunately SRP has never been seriously considered here. I think the reason SSH is more in demand in the survey is because operators are more familiar with it, not because of its technical superiority. Khanh > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > Sent: Monday, October 31, 2005 8:45 AM > To: 'ietfdbh@comcast.net'; McDonald, Ira; isms@ietf.org > Subject: RE: [Isms] Latest draft of TLS w/ SRP >=20 > Hi, >=20 > Well - certainly many routers and middleboxes support _some_=20 > form of some protocol they call 'SSH'. But it's noteworthy=20 > that SSH2 (the current version) is still in the RFC Editor's=20 > queue. And that SSH1 and SSH2 (specifically the modules from=20 > SSH Communications Security Corp who hold the trademark on=20 > 'SSH' in many countries) do NOT interoperate. >=20 > The quality of open source implementations of SSH is vastly=20 > inferior to the open source implementations of TLS, as has=20 > been noted on this mailing list. >=20 > The fairly arbitrary choice of SSH over TLS forced the ISMS=20 > WG move to SNMP over TCP connections (with all the attendant=20 > vulnerabilities of TCP and of long-term connections). >=20 > A TLS choice would have permitted the use of DTLS (also now=20 > in the RFC Editor's queue as Proposed Standard), which would=20 > have allowed ISMS to use UDP (the traditional SNMP transport). >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) Blue Roof Music=20 > / High North Inc PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Sunday, October 30, 2005 6:42 PM > > To: 'McDonald, Ira'; isms@ietf.org > > Subject: RE: [Isms] Latest draft of TLS w/ SRP > >=20 > >=20 > > Hi Ira, > >=20 > > Did I miss something? What arguments against using TLS? > >=20 > > I thought we simply decided that SSH seemed to be more in demand by=20 > > operators for network management purposes. > >=20 > > dbh > >=20 > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > > Sent: Sunday, October 30, 2005 11:11 AM > > > To: isms@ietf.org > > > Subject: [Isms] Latest draft of TLS w/ SRP > > >=20 > > > Hi, > > >=20 > > > Although this ISMS WG has now turned away from TLS to SSH=20 > (unwisely=20 > > > IMHO), to set the record straight, the work on TLS w/ SRP is very=20 > > > much alive and well. The latest draft is: > > >=20 > > > Using SRP for TLS Authentication, October 6 2005 > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt > > >=20 > > > Given that the IESG is very unlikely to approve SNMP over SSH=20 > > > without a mandatory IANA-registered port, arguments against using=20 > > > TLS for ISMS seem dubious to me. > > >=20 > > > Whatever security protocol is used below the SNMP=20 > application layer,=20 > > > the SAs (security associations) at the lower layer (SSH, TLS,=20 > > > whatever) and the SNMP layer will have to be securely=20 > > > cryptographically bound or else the SSH SA MUST require strong=20 > > > mutual authentication or else active man-in-the-middle=20 > attacks will=20 > > > be trivially easy. > > >=20 > > > Cheers, > > > - Ira > > >=20 > > >=20 > > > Ira McDonald (Musician / Software Architect) Blue Roof=20 > Music / High=20 > > > North Inc PO Box 221 Grand Marais, MI 49839 > > > phone: +1-906-494-2434 > > > email: imcdonald@sharplabs.com > > >=20 > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 16:08:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgtQ-00025c-8v; Mon, 31 Oct 2005 16:08:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgtN-00025T-T2 for isms@megatron.ietf.org; Mon, 31 Oct 2005 16:08:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09997 for ; Mon, 31 Oct 2005 16:08:13 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWh7d-0004Dh-DF for isms@ietf.org; Mon, 31 Oct 2005 16:23:17 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005103121082201200drqahe>; Mon, 31 Oct 2005 21:08:22 +0000 From: "David B Harrington" To: "'Khanh Nguyen \(khanhvn\)'" , "'McDonald, Ira'" , Subject: RE: [Isms] Latest draft of TLS w/ SRP Date: Mon, 31 Oct 2005 16:08:11 -0500 Message-ID: <010301c5de5f$383edb30$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXeOlPA2ANSPs0SRiWrqMw5gfkEGgAG9UHQAAHqwhA= In-reply-to: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I agree. We chose to work on SSH because operators indicated a preference, not because there was a recognized technical superiority of one solution over the other. The existence of an SSH solution does not preclude a TLS solution. From the charter: "In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS." In addition to expressed operator preference, we have volunteers willing to edit the documents needed to describe an SSH solution. If Ira and others want a TLS+SRP solution, then feel free to start editing the documents needed to describe a TLS+SRP solution. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] > Sent: Monday, October 31, 2005 3:32 PM > To: McDonald, Ira; ietfdbh@comcast.net; isms@ietf.org > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > I think it's too late now to go back to the SSH vs TLS > discussion. But > if we do decide to reconsider, I definitely go with TLS+SRP. > > I believe SRP is the ideal authentication method for SNMP because the > passwords can be used for not only client (manager) but also server > (agent) authentication, so you don't need PKI, Kerberos, or other > heavy-weight infrastructure for server auth. Unfortunately SRP has > never been seriously considered here. > > I think the reason SSH is more in demand in the survey is because > operators are more familiar with it, not because of its technical > superiority. > > Khanh > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > Sent: Monday, October 31, 2005 8:45 AM > > To: 'ietfdbh@comcast.net'; McDonald, Ira; isms@ietf.org > > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > > Hi, > > > > Well - certainly many routers and middleboxes support _some_ > > form of some protocol they call 'SSH'. But it's noteworthy > > that SSH2 (the current version) is still in the RFC Editor's > > queue. And that SSH1 and SSH2 (specifically the modules from > > SSH Communications Security Corp who hold the trademark on > > 'SSH' in many countries) do NOT interoperate. > > > > The quality of open source implementations of SSH is vastly > > inferior to the open source implementations of TLS, as has > > been noted on this mailing list. > > > > The fairly arbitrary choice of SSH over TLS forced the ISMS > > WG move to SNMP over TCP connections (with all the attendant > > vulnerabilities of TCP and of long-term connections). > > > > A TLS choice would have permitted the use of DTLS (also now > > in the RFC Editor's queue as Proposed Standard), which would > > have allowed ISMS to use UDP (the traditional SNMP transport). > > > > Cheers, > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) Blue Roof Music > > / High North Inc PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Sunday, October 30, 2005 6:42 PM > > > To: 'McDonald, Ira'; isms@ietf.org > > > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > > > > > > > Hi Ira, > > > > > > Did I miss something? What arguments against using TLS? > > > > > > I thought we simply decided that SSH seemed to be more in > demand by > > > operators for network management purposes. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > > > Sent: Sunday, October 30, 2005 11:11 AM > > > > To: isms@ietf.org > > > > Subject: [Isms] Latest draft of TLS w/ SRP > > > > > > > > Hi, > > > > > > > > Although this ISMS WG has now turned away from TLS to SSH > > (unwisely > > > > IMHO), to set the record straight, the work on TLS w/ > SRP is very > > > > much alive and well. The latest draft is: > > > > > > > > Using SRP for TLS Authentication, October 6 2005 > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt > > > > > > > > Given that the IESG is very unlikely to approve SNMP over SSH > > > > without a mandatory IANA-registered port, arguments > against using > > > > TLS for ISMS seem dubious to me. > > > > > > > > Whatever security protocol is used below the SNMP > > application layer, > > > > the SAs (security associations) at the lower layer (SSH, TLS, > > > > whatever) and the SNMP layer will have to be securely > > > > cryptographically bound or else the SSH SA MUST require strong > > > > mutual authentication or else active man-in-the-middle > > attacks will > > > > be trivially easy. > > > > > > > > Cheers, > > > > - Ira > > > > > > > > > > > > Ira McDonald (Musician / Software Architect) Blue Roof > > Music / High > > > > North Inc PO Box 221 Grand Marais, MI 49839 > > > > phone: +1-906-494-2434 > > > > email: imcdonald@sharplabs.com > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Oct 31 16:23:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgw3-0002dr-8U; Mon, 31 Oct 2005 16:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgw1-0002dg-Cz for isms@megatron.ietf.org; Mon, 31 Oct 2005 16:11:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10166 for ; Mon, 31 Oct 2005 16:10:57 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhAH-0004lv-0m for isms@ietf.org; Mon, 31 Oct 2005 16:26:01 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j9VLApHf001414; Mon, 31 Oct 2005 13:10:51 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Oct 2005 13:12:24 -0800 Message-ID: From: "McDonald, Ira" To: "'Khanh Nguyen (khanhvn)'" , "McDonald, Ira" , ietfdbh@comcast.net, isms@ietf.org Subject: RE: [Isms] Latest draft of TLS w/ SRP Date: Mon, 31 Oct 2005 13:12:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Agreed - the decision to use SSH instead of TLS is probably not reversible in the ISMS WG. Also agreed - TLS+SRP is a very good solution for a lots application protocols (as you say), because it's lightweight and doesn't require deployment of expensive infrastructure. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Khanh Nguyen (khanhvn) [mailto:khanhvn@cisco.com] > Sent: Monday, October 31, 2005 3:32 PM > To: McDonald, Ira; ietfdbh@comcast.net; isms@ietf.org > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > I think it's too late now to go back to the SSH vs TLS > discussion. But > if we do decide to reconsider, I definitely go with TLS+SRP. > > I believe SRP is the ideal authentication method for SNMP because the > passwords can be used for not only client (manager) but also server > (agent) authentication, so you don't need PKI, Kerberos, or other > heavy-weight infrastructure for server auth. Unfortunately SRP has > never been seriously considered here. > > I think the reason SSH is more in demand in the survey is because > operators are more familiar with it, not because of its technical > superiority. > > Khanh > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > Sent: Monday, October 31, 2005 8:45 AM > > To: 'ietfdbh@comcast.net'; McDonald, Ira; isms@ietf.org > > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > > Hi, > > > > Well - certainly many routers and middleboxes support _some_ > > form of some protocol they call 'SSH'. But it's noteworthy > > that SSH2 (the current version) is still in the RFC Editor's > > queue. And that SSH1 and SSH2 (specifically the modules from > > SSH Communications Security Corp who hold the trademark on > > 'SSH' in many countries) do NOT interoperate. > > > > The quality of open source implementations of SSH is vastly > > inferior to the open source implementations of TLS, as has > > been noted on this mailing list. > > > > The fairly arbitrary choice of SSH over TLS forced the ISMS > > WG move to SNMP over TCP connections (with all the attendant > > vulnerabilities of TCP and of long-term connections). > > > > A TLS choice would have permitted the use of DTLS (also now > > in the RFC Editor's queue as Proposed Standard), which would > > have allowed ISMS to use UDP (the traditional SNMP transport). > > > > Cheers, > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) Blue Roof Music > > / High North Inc PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Sunday, October 30, 2005 6:42 PM > > > To: 'McDonald, Ira'; isms@ietf.org > > > Subject: RE: [Isms] Latest draft of TLS w/ SRP > > > > > > > > > Hi Ira, > > > > > > Did I miss something? What arguments against using TLS? > > > > > > I thought we simply decided that SSH seemed to be more in > demand by > > > operators for network management purposes. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > > > Sent: Sunday, October 30, 2005 11:11 AM > > > > To: isms@ietf.org > > > > Subject: [Isms] Latest draft of TLS w/ SRP > > > > > > > > Hi, > > > > > > > > Although this ISMS WG has now turned away from TLS to SSH > > (unwisely > > > > IMHO), to set the record straight, the work on TLS w/ > SRP is very > > > > much alive and well. The latest draft is: > > > > > > > > Using SRP for TLS Authentication, October 6 2005 > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt > > > > > > > > Given that the IESG is very unlikely to approve SNMP over SSH > > > > without a mandatory IANA-registered port, arguments > against using > > > > TLS for ISMS seem dubious to me. > > > > > > > > Whatever security protocol is used below the SNMP > > application layer, > > > > the SAs (security associations) at the lower layer (SSH, TLS, > > > > whatever) and the SNMP layer will have to be securely > > > > cryptographically bound or else the SSH SA MUST require strong > > > > mutual authentication or else active man-in-the-middle > > attacks will > > > > be trivially easy. > > > > > > > > Cheers, > > > > - Ira > > > > > > > > > > > > Ira McDonald (Musician / Software Architect) Blue Roof > > Music / High > > > > North Inc PO Box 221 Grand Marais, MI 49839 > > > > phone: +1-906-494-2434 > > > > email: imcdonald@sharplabs.com > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms