From isms-bounces@lists.ietf.org Sun Apr 01 15:56:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY69p-0003rl-Uf; Sun, 01 Apr 2007 15:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY69p-0003rg-5Z for isms@ietf.org; Sun, 01 Apr 2007 15:56:09 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY69n-0004PA-RG for isms@ietf.org; Sun, 01 Apr 2007 15:56:09 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 11ED76D9EC for ; Sun, 1 Apr 2007 21:56:07 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09632-04; Sun, 1 Apr 2007 21:56:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id BA7055AD17; Sun, 1 Apr 2007 21:56:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 47F8B20097F; Sun, 1 Apr 2007 21:56:02 +0200 (CEST) Date: Sun, 1 Apr 2007 21:56:02 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070401195602.GA921@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Isms] transport security model 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: , Errors-To: isms-bounces@lists.ietf.org Hi, draft-ietf-isms-transport-security-model-03.txt has been under WG last call, which formally ended March 25, 2007. We have seen only a few comments posted to the mailing list and this is not really good. So please, a) if you have read the document and you did not have any comments, drop us a note; b) if you like to review but you need more time, also let us know; c) if you planned to read this document but you forgot for some reason, please be reminded that we still are very much interested in getting more opinions and comments. It is really essential that we receive substantial reviews. Note that document is just 25 I-D pages and some of them are appendix. It should not take too long to read this document. /js -- Juergen Schoenwaelder Jacobs 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 Apr 05 13:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVij-0001T9-Ii; Thu, 05 Apr 2007 13:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVii-0001Sz-9q for isms@ietf.org; Thu, 05 Apr 2007 13:26:00 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZVig-00063U-VP for isms@ietf.org; Thu, 05 Apr 2007 13:26:00 -0400 Received: from pc6 (1Cust49.tnt2.lnd4.gbr.da.uu.net [62.188.131.49]) by ranger.systems.pipex.net (Postfix) with SMTP id 3F09FE00008A; Thu, 5 Apr 2007 18:25:44 +0100 (BST) Message-ID: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> From: "tom.petch" To: "Tammy Alper" , References: Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Thu, 5 Apr 2007 18:12:51 +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.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Tammy Alper [mailto:tammyi@marvell.com] > Sent: maandag 19 maart 2007 9:41 > To: isms@ietf.org > Subject: [Isms] Question regarding SNMPv3 engine-id discovery process > > Hello, > > I have a question regarding the SNMPv3 engine-id discovery process: > Suppose an SNMP engine wants to discover a remote engine-id value, > for the purpose of sending an Inform message to the remote engine. > I am missing something here (apart from time to read messages promptly:-( Why do you need the remote engine-id? An Inform sends information about itself so the contextEngineID is itself and the authoritativeEngineID is that of the sender, again itself. So if all you do is receive Informs, you need not have an EngineID (although there is probably a clause buried in STD62 somewhere that says you must) Tom Petch > After sending the discovery packet to the requested target and upon > receiving an incoming packet: > > Should the (UDP) port also be used (in addition to IP address) for > matching response to the request in this case? > > In other words - when a cache is used to store remote > engine-ids information, > > should the mapping be of the form: engine-id -> ip-address > or engine-id -> ip-address, UDP port > > In case the SNMP engine supports second option, if the remote > engine-id sends a response to the discovery packet from a port > different from the port on which it got the request, the SNMP > engine will ignore the response and the discovery process will > fail. Hence the importance of interoperability in this case. > > > > Thank you > > Tammy Alper > _______________________________________________ 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 Apr 05 15:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXvr-0000jq-OK; Thu, 05 Apr 2007 15:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXvq-0000jl-MP for isms@ietf.org; Thu, 05 Apr 2007 15:47:42 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXvp-00042S-0c for isms@ietf.org; Thu, 05 Apr 2007 15:47:42 -0400 X-TACSUNS: Virus Scanned Received: from rtp-cse-133.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l35Jleb21323; Thu, 5 Apr 2007 15:47:40 -0400 (EDT) Received: from localhost (chelliot@localhost) by rtp-cse-133.cisco.com (8.11.7p1+Sun/8.11.6) with ESMTP id l35JlZK19179; Thu, 5 Apr 2007 15:47:36 -0400 (EDT) Date: Thu, 5 Apr 2007 15:47:35 -0400 (EDT) From: Chris Elliott To: "tom.petch" Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process In-Reply-To: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> Message-ID: References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Tammy Alper , 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: , Errors-To: isms-bounces@lists.ietf.org Tom, In all SNMPv3 USM communications where a response is expected the authoritativeEngineID is the SNMP entity receiving the operation to which a response is expected. Therefore, the authoritativeEngineID for an Inform operation is that of the recipient. As traps don't require a response, the authoritativeEngineID is that of the sender. A trap receiver could get away without an engineID, but not an inform receiver. Chris. P.S. Tammy--I agree with Burt--cache the port. If you look at the SNMP-TARGET-MIB, you'll see that the typical transport domain for SNMP (snmpUDPDomain) requires a transport address that includes the IPv4 address and the UDP port number. On Thu, 5 Apr 2007, tom.petch wrote: >> -----Original Message----- >> From: Tammy Alper [mailto:tammyi@marvell.com] >> Sent: maandag 19 maart 2007 9:41 >> To: isms@ietf.org >> Subject: [Isms] Question regarding SNMPv3 engine-id discovery process >> >> Hello, >> >> I have a question regarding the SNMPv3 engine-id discovery process: >> Suppose an SNMP engine wants to discover a remote engine-id value, >> for the purpose of sending an Inform message to the remote engine. >> > > I am missing something here (apart from time to read messages promptly:-( > > Why do you need the remote engine-id? An Inform sends information about itself > so the contextEngineID is itself and the authoritativeEngineID is that of the > sender, again itself. So if all you do is receive Informs, you need not have an > EngineID (although there is probably a clause buried in STD62 somewhere that > says you must) > > Tom Petch > >> After sending the discovery packet to the requested target and upon >> receiving an incoming packet: >> >> Should the (UDP) port also be used (in addition to IP address) for >> matching response to the request in this case? >> >> In other words - when a cache is used to store remote >> engine-ids information, >> >> should the mapping be of the form: engine-id -> ip-address >> or engine-id -> ip-address, UDP port >> >> In case the SNMP engine supports second option, if the remote >> engine-id sends a response to the discovery packet from a port >> different from the port on which it got the request, the SNMP >> engine will ignore the response and the discovery process will >> fail. Hence the importance of interoperability in this case. >> >> >> >> Thank you >> >> Tammy Alper >> > _______________________________________________ > 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 > -- Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Apr 05 16:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYKc-00037I-8Q; Thu, 05 Apr 2007 16:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYKb-00036s-9p for isms@ietf.org; Thu, 05 Apr 2007 16:13:17 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZYKY-0000qM-Aj for isms@ietf.org; Thu, 05 Apr 2007 16:13:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bx7jQV7LxM3QHGthE3+1pGnKuSOKQC7he43VJx61+pZASyOyB1UXrIitMCHC+Dnx; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.169] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HZYKT-00028K-JN for isms@ietf.org; Thu, 05 Apr 2007 16:13:09 -0400 Message-ID: <001901c777bf$07f4efa0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Thu, 5 Apr 2007 13:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd77c97297942ac85e65fa25f078e9c5b03350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.169 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "tom.petch" > To: "Tammy Alper" ; > Sent: Thursday, April 05, 2007 9:12 AM > Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process ... > Why do you need the remote engine-id? > An Inform sends information about itself > so the contextEngineID is itself and the authoritativeEngineID is that of the > sender, again itself. So if all you do is receive Informs, you need not have an > EngineID (although there is probably a clause buried > in STD62 somewhere that > says you must) ... See RFC 3412 clause 7.1 on "Prepare an Outgoing SNMP Message" There, in point 9, it says: 9) If the PDU is from the Confirmed Class or the Notification Class, then: a) If the PDU is from the Unconfirmed Class, then securityEngineID is set to the value of this entity's snmpEngineID. Otherwise, the snmpEngineID of the target entity is determined, in an implementation-dependent manner, possibly using transportDomain and transportAddress. The value of the securityEngineID is set to the value of the target entity's snmpEngineID. There really is a need to determine the remote engine id. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 06 01:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhD3-0001n5-NV; Fri, 06 Apr 2007 01:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhD2-0001n0-At for isms@ietf.org; Fri, 06 Apr 2007 01:42:04 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZhD0-0003N3-09 for isms@ietf.org; Fri, 06 Apr 2007 01:42:04 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9963B6DA47; Fri, 6 Apr 2007 07:41:54 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22501-04; Fri, 6 Apr 2007 07:41:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 34D3769913; Fri, 6 Apr 2007 07:41:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CF16210B82; Fri, 6 Apr 2007 07:41:49 +0200 (CEST) Date: Fri, 6 Apr 2007 07:41:49 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Message-ID: <20070406054149.GA1450@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <001901c777bf$07f4efa0$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c777bf$07f4efa0$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: isms-bounces@lists.ietf.org On Thu, Apr 05, 2007 at 01:14:34PM -0700, Randy Presuhn wrote: > See RFC 3412 clause 7.1 on "Prepare an Outgoing SNMP Message" > There, in point 9, it says: > > 9) If the PDU is from the Confirmed Class or the Notification Class, > then: > > a) If the PDU is from the Unconfirmed Class, then securityEngineID > is set to the value of this entity's snmpEngineID. > > Otherwise, the snmpEngineID of the target entity is determined, > in an implementation-dependent manner, possibly using > transportDomain and transportAddress. The value of the > securityEngineID is set to the value of the target entity's > snmpEngineID. > > There really is a need to determine the remote engine id. In an implementation specific manner. My understanding is that the determined securityEngineID is passed via the generateRequestMsg() ASI into the security subsystem. And since the transport security model does not seem to need a concept of authoritative engines, I think as an implementor I can come up with an easy implementation-dependent way of determining the remote engine id, no? /js -- Juergen Schoenwaelder Jacobs 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 Apr 06 02:01:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhVa-0003Uj-OF; Fri, 06 Apr 2007 02:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhVZ-0003Ub-PO for isms@ietf.org; Fri, 06 Apr 2007 02:01:13 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZhVY-0003ze-Ft for isms@ietf.org; Fri, 06 Apr 2007 02:01:13 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Sv9t1OjddYGZ2x+SZhNW/QJpBgiid78IYffqeB/O0EhYaYzHT75kq53oNfQ9uLhl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.37] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HZhVX-0006oM-UI for isms@ietf.org; Fri, 06 Apr 2007 02:01:12 -0400 Message-ID: <001801c77811$2e9bfb60$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <001901c777bf$07f4efa0$6601a8c0@oemcomputer> <20070406054149.GA1450@elstar.local> Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Thu, 5 Apr 2007 23:02:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7984250a72153e50f4f5dbe0979c902f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.37 X-Spam-Score: 0.0 (/) 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: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, April 05, 2007 10:41 PM > Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process ... > In an implementation specific manner. My understanding is that the > determined securityEngineID is passed via the generateRequestMsg() ASI > into the security subsystem. And since the transport security model > does not seem to need a concept of authoritative engines, I think as > an implementor I can come up with an easy implementation-dependent way > of determining the remote engine id, no? Of course. I think it's quite clear that the RFC doesn't prescribe the use of a specific mechanism here, explicitly leaving it as a matter of implementation choice. However, I'm not sure it would make sense to limit an implimentation to support only the transport security model. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 06 05:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkpz-0005Da-7m; Fri, 06 Apr 2007 05:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkpy-0005Cf-FN for isms@ietf.org; Fri, 06 Apr 2007 05:34:30 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZkpx-0002eJ-4A for isms@ietf.org; Fri, 06 Apr 2007 05:34:30 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 72B406DA7A; Fri, 6 Apr 2007 11:34:28 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02474-09; Fri, 6 Apr 2007 11:34:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id F3CFA699F2; Fri, 6 Apr 2007 11:34:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 02B4A210C32; Fri, 6 Apr 2007 11:34:22 +0200 (CEST) Date: Fri, 6 Apr 2007 11:34:22 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Message-ID: <20070406093422.GA1521@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <001901c777bf$07f4efa0$6601a8c0@oemcomputer> <20070406054149.GA1450@elstar.local> <001801c77811$2e9bfb60$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c77811$2e9bfb60$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: isms-bounces@lists.ietf.org On Thu, Apr 05, 2007 at 11:02:38PM -0700, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Thursday, April 05, 2007 10:41 PM > > Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process > ... > > In an implementation specific manner. My understanding is that the > > determined securityEngineID is passed via the generateRequestMsg() ASI > > into the security subsystem. And since the transport security model > > does not seem to need a concept of authoritative engines, I think as > > an implementor I can come up with an easy implementation-dependent way > > of determining the remote engine id, no? > > Of course. I think it's quite clear that the RFC doesn't prescribe > the use of a specific mechanism here, explicitly leaving it as a > matter of implementation choice. > > However, I'm not sure it would make sense to limit an > implimentation to support only the transport security model. Sure, but since this determination is implementation specific, I do not really see a problem. And in the code bases I am familiar with, the issue really is a non-issue. /js -- Juergen Schoenwaelder Jacobs 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 Apr 06 13:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZseU-0004dV-67; Fri, 06 Apr 2007 13:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZseT-0004dP-88 for isms@ietf.org; Fri, 06 Apr 2007 13:55:09 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZseR-0004Pb-3b for isms@ietf.org; Fri, 06 Apr 2007 13:55:09 -0400 Received: (qmail 12400 invoked from network); 6 Apr 2007 10:55:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Apr 2007 10:55:02 -0700 Date: Fri, 6 Apr 2007 10:55:02 -0700 (PDT) From: "David T. Perkins" X-X-Sender: dperkins@shell4.bayarea.net To: Chris Elliott Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process In-Reply-To: Message-ID: References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Tammy Alper , 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: , Errors-To: isms-bounces@lists.ietf.org HI, This issue and associated misunderstandings have been around since the development of SNMPv3/USM. There are many "urban legends" that go with SNMPv3 engineIDs used to identify management info and used in the contextEngineID field in ALL SNMPv3 messages, and the SNMPv3 engineID used in the msgAuthoritativeEngineID used presently in ONLY SNMPv3/USM messages. Both uses of engineIDs are associated with a transport address, and for the Internetprotocol, this means an IP address and port. By the way, it is certainly the case that USM is defined as the following: GET/SET/GETNEXT/GETBULK/INFORM - msgAuthoritativeEngineID contains the value of the receiver RESPONSE/v2TRAP - msgAuthoritativeEngineID contains the value of the sender However, these choices are "arbitrary" and could have been switched. The reason they are what they are are so that the shared clock can be synchronized through "normal" message exchange without "extra" messages. Unfortunately, this approach has proven to be costly for INFORMs. Many people who have experience with SNMPv3/USM wish that INFORMs used the senders engineID. But, SNMPv3 is defined as it is, and there is too much resistance to change anything about SNMPv3/USM. Note that SNMP3v/USM requires engineIDs to perform SNMPv3 operations, and an engineID discovery technique is described in the USM RFC (RFC 3414). This technique is not without problems, and does not work for proxies. Other SNMPv3 security models, such as ISMS do use the the msgAuthoritativeEngineID field, since security is done differently. Hope this helps. Regards, /david t. perkins On Thu, 5 Apr 2007, Chris Elliott wrote: > Tom, > > In all SNMPv3 USM communications where a response is expected the > authoritativeEngineID is the SNMP entity receiving the operation to which a > response is expected. Therefore, the authoritativeEngineID for an Inform > operation is that of the recipient. > > As traps don't require a response, the authoritativeEngineID is that of the > sender. > > A trap receiver could get away without an engineID, but not an inform > receiver. > > Chris. > > P.S. Tammy--I agree with Burt--cache the port. If you look at the > SNMP-TARGET-MIB, you'll see that the typical transport domain for SNMP > (snmpUDPDomain) requires a transport address that includes the IPv4 address > and the UDP port number. > > On Thu, 5 Apr 2007, tom.petch wrote: > >> > -----Original Message----- >> > From: Tammy Alper [mailto:tammyi@marvell.com] >> > Sent: maandag 19 maart 2007 9:41 >> > To: isms@ietf.org >> > Subject: [Isms] Question regarding SNMPv3 engine-id discovery process >> > >> > Hello, >> > >> > I have a question regarding the SNMPv3 engine-id discovery process: >> > Suppose an SNMP engine wants to discover a remote engine-id value, >> > for the purpose of sending an Inform message to the remote engine. >> > >> >> I am missing something here (apart from time to read messages promptly:-( >> >> Why do you need the remote engine-id? An Inform sends information about >> itself >> so the contextEngineID is itself and the authoritativeEngineID is that of >> the >> sender, again itself. So if all you do is receive Informs, you need not >> have an >> EngineID (although there is probably a clause buried in STD62 somewhere >> that >> says you must) >> >> Tom Petch >> >> > After sending the discovery packet to the requested target and upon >> > receiving an incoming packet: >> > >> > Should the (UDP) port also be used (in addition to IP address) for >> > matching response to the request in this case? >> > >> > In other words - when a cache is used to store remote >> > engine-ids information, >> > >> > should the mapping be of the form: engine-id -> ip-address >> > or engine-id -> ip-address, UDP port >> > >> > In case the SNMP engine supports second option, if the remote >> > engine-id sends a response to the discovery packet from a port >> > different from the port on which it got the request, the SNMP >> > engine will ignore the response and the discovery process will >> > fail. Hence the importance of interoperability in this case. >> > >> > >> > >> > Thank you >> > >> > Tammy Alper >> > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 06 14:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZspx-0004xf-Uv; Fri, 06 Apr 2007 14:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZspx-0004xa-K3 for isms@ietf.org; Fri, 06 Apr 2007 14:07:01 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZspw-0008AU-55 for isms@ietf.org; Fri, 06 Apr 2007 14:07:01 -0400 Received: (qmail 18064 invoked from network); 6 Apr 2007 11:06:59 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Apr 2007 11:06:59 -0700 Date: Fri, 6 Apr 2007 11:06:59 -0700 (PDT) From: "David T. Perkins" X-X-Sender: dperkins@shell4.bayarea.net To: Juergen Schoenwaelder Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process In-Reply-To: <20070406093422.GA1521@elstar.local> Message-ID: References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <001901c777bf$07f4efa0$6601a8c0@oemcomputer> <20070406054149.GA1450@elstar.local> <001801c77811$2e9bfb60$6601a8c0@oemcomputer> <20070406093422.GA1521@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: isms-bounces@lists.ietf.org HI, Commenting on Juergen's last point.... For INFORMs, it's "just a special case" piece of code that needs to be written. It is not obvious, but once you get the concept, a coder of an INFORM generator realizes that a cache must be implemented that maps transport address to engineIDs. It's really sort of nasty. In processing sending notifications that are INFORMs, if there is no transport to security engineID mapping, the notification sending code must first do a EngineID discovery. After the code has that mapping, it can complete the procedure for notification delivery. On Fri, 6 Apr 2007, Juergen Schoenwaelder wrote: > On Thu, Apr 05, 2007 at 11:02:38PM -0700, Randy Presuhn wrote: >> Hi - >> >>> From: "Juergen Schoenwaelder" >>> To: "Randy Presuhn" >>> Cc: >>> Sent: Thursday, April 05, 2007 10:41 PM >>> Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process >> ... >>> In an implementation specific manner. My understanding is that the >>> determined securityEngineID is passed via the generateRequestMsg() ASI >>> into the security subsystem. And since the transport security model >>> does not seem to need a concept of authoritative engines, I think as >>> an implementor I can come up with an easy implementation-dependent way >>> of determining the remote engine id, no? >> >> Of course. I think it's quite clear that the RFC doesn't prescribe >> the use of a specific mechanism here, explicitly leaving it as a >> matter of implementation choice. >> >> However, I'm not sure it would make sense to limit an >> implimentation to support only the transport security model. > > Sure, but since this determination is implementation specific, I do > not really see a problem. And in the code bases I am familiar with, > the issue really is a non-issue. > > /js 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 Apr 06 15:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtp7-0001v8-51; Fri, 06 Apr 2007 15:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtp6-0001v3-HW for isms@ietf.org; Fri, 06 Apr 2007 15:10:12 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtp4-0004S3-8w for isms@ietf.org; Fri, 06 Apr 2007 15:10:12 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070406191008m130036l28e>; Fri, 6 Apr 2007 19:10:09 +0000 From: "David Harrington" To: "'David T. Perkins'" , "'Chris Elliott'" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> Subject: RE: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Fri, 6 Apr 2007 15:09:42 -0400 Message-ID: <09d401c7787f$227c9c40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd4dLpFSnKXCwNfSI+1QKRq4Wt7pgABTyAQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'Tammy Alper' , 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: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Other SNMPv3 security models, such as ISMS do use the > the msgAuthoritativeEngineID field, since security is > done differently. > I believe Dave meant to say "do not use". A few minor corrections: 1) ISMS is not a security model 2) It is not a requirement that other security models do not use msgAuthoritativeEngineID, so "do not use" should probably be "may choose not to use" So I think this would be more accurate: Other security models, such as the Transport Security Model being developed in the ISMS WG, may choose to not use a msgAuthoritativeEngineID field, since security is done differently. (For SNMPv3 processing, however, other security models will still need to set the value of securityEngineID for the processIncomingMessage ASI, because RFC3412 section 7.2 13a checks the value of securityEngineID. The Transport Security Model sets it to the local snmpEngineID, so the 7.2 13a condition does not trigger.) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Apr 10 04:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBVd-0004gx-Q2; Tue, 10 Apr 2007 04:15:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBVb-0004gg-W4 for isms@ietf.org; Tue, 10 Apr 2007 04:15:23 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbBVZ-0004Xq-LF for isms@ietf.org; Tue, 10 Apr 2007 04:15:23 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D8B9C6DA0E; Tue, 10 Apr 2007 10:15:09 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11571-08; Tue, 10 Apr 2007 10:15:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6D3536DA40; Tue, 10 Apr 2007 10:15:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B40A212006; Tue, 10 Apr 2007 10:15:04 +0200 (CEST) Date: Tue, 10 Apr 2007 10:15:04 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process Message-ID: <20070410081504.GB3235@elstar.local> Mail-Followup-To: David Harrington , "'David T. Perkins'" , 'Chris Elliott' , 'Tammy Alper' , isms@ietf.org References: <09d401c7787f$227c9c40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09d401c7787f$227c9c40$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Tammy Alper' , 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: , Errors-To: isms-bounces@lists.ietf.org On Fri, Apr 06, 2007 at 03:09:42PM -0400, David Harrington wrote: > So I think this would be more accurate: > Other security models, such as the Transport Security Model being > developed in the ISMS WG, may choose to not use a > msgAuthoritativeEngineID field, since security is done differently. Since msgAuthoritativeEngineID is a USM specific header field, the above text does seem relatively pointless do me. /js -- Juergen Schoenwaelder Jacobs 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 Wed Apr 11 14:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhtR-00040W-LM; Wed, 11 Apr 2007 14:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhtQ-00040R-Bc for isms@ietf.org; Wed, 11 Apr 2007 14:50:08 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbhtO-0000kY-TP for isms@ietf.org; Wed, 11 Apr 2007 14:50:08 -0400 Received: from pc6 (1Cust250.tnt1.lnd4.gbr.da.uu.net [62.188.130.250]) by galaxy.systems.pipex.net (Postfix) with SMTP id D25EEE000AFB for ; Wed, 11 Apr 2007 19:49:16 +0100 (BST) Message-ID: <00b701c77c61$51dda2a0$0601a8c0@pc6> From: "tom.petch" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> Subject: TMSM and Port was Re: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Wed, 11 Apr 2007 19:03:52 +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.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Errors-To: isms-bounces@lists.ietf.org Thanks to you all for putting me straight. As you may gather, I have been contemplating Informs again, wondering about the various posts that have considered their compatability with TMSM. >From that, another query. What happens to port numbers with TMSM? At present, SNMP applications use 161 and 162 (mostly) which then becomes part of the key for selecting engineID. Will applications still use this at the ASI to the Dispatcher? If and when does this change to a secure transport port? Tom Petch ----- Original Message ----- From: "David T. Perkins" To: "Chris Elliott" Cc: "tom.petch" ; "Tammy Alper" ; Sent: Friday, April 06, 2007 7:55 PM Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process > HI, > > This issue and associated misunderstandings have been around > since the development of SNMPv3/USM. There are many "urban legends" > that go with SNMPv3 engineIDs used to identify management info > and used in the contextEngineID field in ALL SNMPv3 messages, > and the SNMPv3 engineID used in the msgAuthoritativeEngineID > used presently in ONLY SNMPv3/USM messages. > > Both uses of engineIDs are associated with a transport address, > and for the Internetprotocol, this means an IP address and port. > > By the way, it is certainly the case that USM is defined as the > following: > GET/SET/GETNEXT/GETBULK/INFORM - msgAuthoritativeEngineID contains > the value of the receiver > RESPONSE/v2TRAP - msgAuthoritativeEngineID contains the value > of the sender > However, these choices are "arbitrary" and could have been switched. > The reason they are what they are are so that the shared clock > can be synchronized through "normal" message exchange without > "extra" messages. Unfortunately, this approach has proven to > be costly for INFORMs. Many people who have experience with > SNMPv3/USM wish that INFORMs used the senders engineID. > But, SNMPv3 is defined as it is, and there is too much > resistance to change anything about SNMPv3/USM. > > Note that SNMP3v/USM requires engineIDs to perform SNMPv3 > operations, and an engineID discovery technique is described > in the USM RFC (RFC 3414). This technique is not without > problems, and does not work for proxies. > > Other SNMPv3 security models, such as ISMS do use the > the msgAuthoritativeEngineID field, since security is > done differently. > > Hope this helps. > > Regards, > /david t. perkins > > On Thu, 5 Apr 2007, Chris Elliott wrote: > > Tom, > > > > In all SNMPv3 USM communications where a response is expected the > > authoritativeEngineID is the SNMP entity receiving the operation to which a > > response is expected. Therefore, the authoritativeEngineID for an Inform > > operation is that of the recipient. > > > > As traps don't require a response, the authoritativeEngineID is that of the > > sender. > > > > A trap receiver could get away without an engineID, but not an inform > > receiver. > > > > Chris. > > > > P.S. Tammy--I agree with Burt--cache the port. If you look at the > > SNMP-TARGET-MIB, you'll see that the typical transport domain for SNMP > > (snmpUDPDomain) requires a transport address that includes the IPv4 address > > and the UDP port number. > > > > On Thu, 5 Apr 2007, tom.petch wrote: > > > >> > -----Original Message----- > >> > From: Tammy Alper [mailto:tammyi@marvell.com] > >> > Sent: maandag 19 maart 2007 9:41 > >> > To: isms@ietf.org > >> > Subject: [Isms] Question regarding SNMPv3 engine-id discovery process > >> > > >> > Hello, > >> > > >> > I have a question regarding the SNMPv3 engine-id discovery process: > >> > Suppose an SNMP engine wants to discover a remote engine-id value, > >> > for the purpose of sending an Inform message to the remote engine. > >> > > >> > >> I am missing something here (apart from time to read messages promptly:-( > >> > >> Why do you need the remote engine-id? An Inform sends information about > >> itself > >> so the contextEngineID is itself and the authoritativeEngineID is that of > >> the > >> sender, again itself. So if all you do is receive Informs, you need not > >> have an > >> EngineID (although there is probably a clause buried in STD62 somewhere > >> that > >> says you must) > >> > >> Tom Petch > >> > >> > After sending the discovery packet to the requested target and upon > >> > receiving an incoming packet: > >> > > >> > Should the (UDP) port also be used (in addition to IP address) for > >> > matching response to the request in this case? > >> > > >> > In other words - when a cache is used to store remote > >> > engine-ids information, > >> > > >> > should the mapping be of the form: engine-id -> ip-address > >> > or engine-id -> ip-address, UDP port > >> > > >> > In case the SNMP engine supports second option, if the remote > >> > engine-id sends a response to the discovery packet from a port > >> > different from the port on which it got the request, the SNMP > >> > engine will ignore the response and the discovery process will > >> > fail. Hence the importance of interoperability in this case. > >> > > >> > > >> > > >> > Thank you > >> > > >> > Tammy Alper > >> > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Apr 12 02:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbt8I-0002hS-Ry; Thu, 12 Apr 2007 02:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbt8G-0002hJ-Ko for isms@ietf.org; Thu, 12 Apr 2007 02:50:12 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbt8F-0007AE-Ah for isms@ietf.org; Thu, 12 Apr 2007 02:50:12 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2F3D36DADB; Thu, 12 Apr 2007 08:50:10 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01706-01; Thu, 12 Apr 2007 08:49:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id DEA315617A; Thu, 12 Apr 2007 08:49:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 657E8214E44; Thu, 12 Apr 2007 08:49:49 +0200 (CEST) Date: Thu, 12 Apr 2007 08:49:49 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3 engine-id discovery process Message-ID: <20070412064949.GB7796@elstar.local> Mail-Followup-To: "tom.petch" , isms@ietf.org References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b701c77c61$51dda2a0$0601a8c0@pc6> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: isms-bounces@lists.ietf.org On Wed, Apr 11, 2007 at 07:03:52PM +0200, tom.petch wrote: > From that, another query. What happens to port numbers with TMSM? At present, > SNMP applications use 161 and 162 (mostly) which then becomes part of the key > for selecting engineID. Will applications still use this at the ASI to the > Dispatcher? If and when does this change to a secure transport port? We currently use a user supplied port number and we expect that a default port number for a secure transport model will be allocated by the secure transport model specification. In other words, this is part of the SSH transport model specification to spell out (together with the proper TDomain definitions). Since we use TDomain/TAddress in the ASIs, nothing is going to change about the ASIs and the internals of the Dispatcher as far as I can tell. /js -- Juergen Schoenwaelder Jacobs 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 Apr 17 02:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgsA-0004uA-QC; Tue, 17 Apr 2007 02:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgs9-0004u5-Ne for isms@ietf.org; Tue, 17 Apr 2007 02:09:01 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdgs8-0006QB-6a for isms@ietf.org; Tue, 17 Apr 2007 02:09:01 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 194D76DA1E for ; Tue, 17 Apr 2007 08:08:59 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12536-01 for ; Tue, 17 Apr 2007 08:08:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id D520F6D9C0 for ; Tue, 17 Apr 2007 08:08:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A1363227DD5; Tue, 17 Apr 2007 08:08:53 +0200 (CEST) Resent-From: j.schoenwaelder@iu-bremen.de Resent-Date: Tue, 17 Apr 2007 08:08:53 +0200 Resent-Message-ID: <20070417060853.GB22660@elstar.local> Resent-To: isms@ietf.org Received: from merkur.iu-bremen.de ([unix socket]) by merkur (Cyrus v2.2.12) with LMTPA; Mon, 16 Apr 2007 22:47:25 +0200 X-Sieve: CMU Sieve 2.2 Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by merkur.iu-bremen.de (Postfix) with ESMTP id 3ADB179EB2BA2 for ; Mon, 16 Apr 2007 21:57:21 +0200 (CEST) Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B70A27680B for ; Mon, 16 Apr 2007 21:57:21 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10232-10 for ; Mon, 16 Apr 2007 21:57:18 +0200 (CEST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 447A076598 for ; Mon, 16 Apr 2007 21:57:12 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXDH-0007xd-P5; Mon, 16 Apr 2007 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXDA-0007sO-En for i-d-announce@ietf.org; Mon, 16 Apr 2007 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXD8-0001Ov-Hm for i-d-announce@ietf.org; Mon, 16 Apr 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8133D328F6 for ; Mon, 16 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HdXD8-0000Kl-D8 for i-d-announce@ietf.org; Mon, 16 Apr 2007 15:50:02 -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: Mon, 16 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Status: No, score=-1.932 tagged_above=-30 required=5 tests=[AWL=0.005, BAYES_00=-2.312, MIME_BOUND_NEXTPART=0.375] X-Spam-Score: -1.932 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Isms] I-D ACTION:draft-schoenw-snmp-discover-02.txt X-BeenThere: isms@lists.ietf.org Reply-To: internet-drafts@ietf.org 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 Resent-Date: Tue, 17 Apr 2007 02:09:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Network Management Protocol (SNMP) EngineID Discovery Author(s) : J. Schoenwaelder Filename : draft-schoenw-snmp-discover-02.txt Pages : 9 Date : 2007-4-16 The third version of the Simple Network Management Protocol (SNMP) assumes that a manager knows the identifier of a remote SNMP protocol engine (the so called snmpEngineID) in order to retrieve or manipulate objects maintained locally on the remote engine. This document introduces a well-known localEngineID and a discovery mechanism which can be used to learn the engine identifier of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-snmp-discover-02.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-schoenw-snmp-discover-02.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-schoenw-snmp-discover-02.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: <2007-4-16144616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schoenw-snmp-discover-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-schoenw-snmp-discover-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-16144616.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Apr 20 06:12:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heq6D-0001oN-7S; Fri, 20 Apr 2007 06:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heq6C-0001oI-ID for isms@ietf.org; Fri, 20 Apr 2007 06:12:16 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heq6B-0000oa-7M for isms@ietf.org; Fri, 20 Apr 2007 06:12:16 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3867A6DD9B for ; Fri, 20 Apr 2007 12:12:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11797-04; Fri, 20 Apr 2007 12:12:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0F11E78D23; Fri, 20 Apr 2007 12:12:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5153822CF55; Fri, 20 Apr 2007 12:12:06 +0200 (CEST) Date: Fri, 20 Apr 2007 12:12:06 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070420101206.GA11595@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Isms] prague meeting minutes 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: , Errors-To: isms-bounces@lists.ietf.org Hi, the ISMS meeting minutes can be found at: http://www3.ietf.org/proceedings/07mar/minutes/isms.txt Please take a look and let me know if something needs to be changed. /js -- Juergen Schoenwaelder Jacobs 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 Apr 20 06:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqJK-0002jd-8P; Fri, 20 Apr 2007 06:25:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqJJ-0002fZ-6y for isms@ietf.org; Fri, 20 Apr 2007 06:25:49 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeqJG-0007pX-QK for isms@ietf.org; Fri, 20 Apr 2007 06:25:49 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id AE1B26DD9B; Fri, 20 Apr 2007 12:25:45 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12977-07; Fri, 20 Apr 2007 12:25:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6916A78D22; Fri, 20 Apr 2007 12:25:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA76122CFE8; Fri, 20 Apr 2007 12:25:23 +0200 (CEST) Date: Fri, 20 Apr 2007 12:25:23 +0200 From: Juergen Schoenwaelder To: kaushik_narayan@yahoo.com, d.b.nelson@comcast.net Message-ID: <20070420102523.GB11656@elstar.local> Mail-Followup-To: kaushik_narayan@yahoo.com, d.b.nelson@comcast.net, isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org Subject: [Isms] radius integration document update 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: , Errors-To: isms-bounces@lists.ietf.org Hi, following the discussion in Prague, we need to update the RADIUS document to a) bring it into sync with the introduction of a transport subsystem and transport security models, and to b) remove any discussion about authorization that goes beyond the authorization to use a secure transport model (e.g. an ssh subsystem). I suggest that our document editors post a revised version of their individual submission taking a) and b) into account. Once we have that revision in place, we can decided to accept it as a WG document. It would be nice if this can be done until the end of April. /js -- Juergen Schoenwaelder Jacobs 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 Apr 23 10:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzXA-0008KG-TI; Mon, 23 Apr 2007 10:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzX9-0008K3-D6 for isms@ietf.org; Mon, 23 Apr 2007 10:28:51 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzX7-0007hY-QL for isms@ietf.org; Mon, 23 Apr 2007 10:28:51 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3NESIn5002758; Mon, 23 Apr 2007 09:28:49 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 09:28:35 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 16:28:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 Date: Mon, 23 Apr 2007 16:28:28 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJA References: From: "Wijnen, Bert \(Bert\)" To: "Juergen Quittek" , X-OriginalArrivalTime: 23 Apr 2007 14:28:33.0475 (UTC) FILETIME=[AC013930:01C785B3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 1.1 (+) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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: , Errors-To: isms-bounces@lists.ietf.org Sorry for being late. Here are my comments: - may want to state in the abstract that there is a MIB module in this document. - I am not sure I understand points 1 and 2 of section 1.5. =20 - Section 2, the last sentence leaves me wondering how it is specified=20 for SNMPv1 and v2c. I would think that many people may want to=20 deploy SNMPv2c with SSH based Transport Security? Now I do see that in sect 2.3 you explain/state that the Transport Security Model cannot be used with SNMPv1 and SNMPv2c.=20 I wonder if this is what the operator/user community wants/accepts?? The only reason I can see is, that SNMPv1/v2c do not pass a securityModel during message processing. Is that a good enough reason why they could not be securely transported? They certainly can be transported. The only thing is that once it gets top SNMPv1/v2c Message Processing,=20 there is nothing that will detect that the msg was secured and so it assumes unsecured transport (which may have impact in Access Control=20 of course). But would we there fore state that such messages cannot be transported over TSM ? =20 - My arithmetic is not so great, but sect 2.3, 2nd para: In the RFC3411 architecture, a Message Processing Model determines which Security Model should be called. As of this writing, there are three Message Processing Models and three other Security Models: SNMPv1, SNMPv2c, and the User-based Security Model. For me the three and three do not seem to be in sync with the items listed after the colon. Possibly the 3 listed models are just the 3 (other) security models. I think that is what it is, but I got confused. Maybe you can make it less confusing. Maybe I am the only one who got confused. - I see: 3.1.2. msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is always determined by the Transport Model from the lower layer authentication method, the SNMP message does not need to carry message security parameters within the msgSecurityParameters field. The field msgSecurityParameters MUST be set to a zero-length OCTET STRING. I guess what we want to say is: - on incoming messages, the msgSecurityParameters field MUST be ignored - on outgoing messages, the msgSecurityParameters field MUST be set to a zero-length OCTET STRING. In other words: be liberal in what you accept and conservative in what you send But I see that in sect 5.2 step 2) you seem not to want to be so liberal. Do we really want to generate an error if someone has put some data into the msgSecurityParameters? - In sect 3.2.1, I am not sure that the 2nd para belongs here? Such connection related info would not be saved in the securityStateReference, but rather in the tmStateReference, no? - In sect 4.1 we are adding IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application as new parameters in the generateRequestMsg ASI. Should we not do so in the draft-ietf-isms-tmsm-07.txt document as well? - In sect 4.1 we're also adding=20 IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application to the generateResponseMsg ASI. Why do we do that? Why would that not have been cached in one way or another? So as to be sure that response returns to where the request came from? In fact, sect 4.2, step one states that the transportDomain/Address are to be extracted from the securityStateReference. So it seem we indeed do not need these 2 new parameters for prepareResponseMsg. - In sect 4.2, step 1 1) If the messageProcessingModel is SNMPv3, then the securityEngineID is set to the local snmpEngineID, to satisfy the SNMPv3 message processing defined in RFC 3412 section 7.2 13a). Why do we have to become SNMP version dependent here? It would be fine to give all SNMP versions we know up till now the same treatment, no? RFC3584 (top of page 28) does the same thing, so we can do so too if it is SNMPv1 or v2c. - It also seems to me that step 2 and 1 (in sect 4.1) are in conflict, in that step 2 (on a generateOutgoingRequestMsg) saves transportAddress/Domain (and other info) in tmStateReference but step 1 (on a generateResponseMsg) seems to want to extract it from a different cache, namely securityStateReference? - At the top of page 21, I wonder if * snmpTargetParamsSecurityName "sampleUser" Should be marked with an asterisk. The securityName is securityModel INDEPENDENT (I believe). It may be the case that the TransportSecurityModel uses identity function (as does USM) for translating it to a securityModel dependent userName, but that does not make this value=20 TransportSecurityModel specific/dependent, does it? MIB review: - for the Counter32s, do we not need to state if (and if so which) discontinuities can occur? It seems this was modeled after the USM-MIB and yep we forgot that in that MIB module too. That does not mean we need to make the same mistake now. - tsmInvalidCache OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because the tmStateReference referred to an invalid cache. This sounds as a "debugging internals of an implementation" object to me. Do we need this? =20 - I wonder if we need something like unknown userNames ?? What if a notification originator as a SecurityName configured (through SNMP maybe) that cannot be mapped to a proper identity inside the transport model? Do we not want to be able to see that in some statistic? Here are nits and typos: - section 1.3 the SNMP architecture, as defined in [RFC3411],and the architecture s/,and/, and/ - page 4: 2. How Transport Security Model Fits in the Architecture s/How/How the/ ?? I did spend several hours on this. But I think I need a second pass of a few dedicated hours (at least) in order to make sure I have checked and understood everything. Modularity is nice.... but it means you need to check several documents at the same time in order to get the complete picture. Bert Wijnen =20 > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 > Sent: Saturday, March 10, 2007 12:14 AM > To: isms@ietf.org > Subject: [Isms] working group last call=20 > ondraft-ietf-isms-transport-security-model-03 >=20 > Dear all, >=20 > This is the working group last call on the > "Transport Security Model for SNMP" > to be found at > -security-model-03.txt>. >=20 > The authors and the chairs think that this document is mature=20 > enough for last call. >=20 > Please do review the document and post your comments on this=20 > list until March 25, 2007. Of course it would be great to=20 > get your comments already before our next meeting on March 22. >=20 > Please also post to the list if you have read the document=20 > and are fine with it as it is. It is very useful to know how=20 > many people have read the document. >=20 > Thanks, >=20 > Juergen Q. > --=20 > Juergen Quittek quittek@netlab.nec.de Tel: +49=20 > 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49=20 > 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany =20 > http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL,=20 > UK Registered in England 2832014 >=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 Apr 24 21:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWd7-00008O-Nv; Tue, 24 Apr 2007 21:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWd6-00007F-4v for isms@ietf.org; Tue, 24 Apr 2007 21:49:12 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWd4-0003zX-2B for isms@ietf.org; Tue, 24 Apr 2007 21:49:12 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <200704250149090120035tk4e>; Wed, 25 Apr 2007 01:49:09 +0000 From: "David Harrington" To: "'tom.petch'" , "'Juergen Quittek'" , References: <012701c76b1c$c5139640$0601a8c0@pc6> Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Tue, 24 Apr 2007 21:49:05 -0400 Message-ID: <01dd01c786db$e89c5db0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012701c76b1c$c5139640$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrJZkbc072XOz2SP+0S9aZfz36jAbtYTuA X-Spam-Score: 1.1 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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: , Errors-To: isms-bounces@lists.ietf.org Hi, I made the requested changes. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, March 20, 2007 2:19 PM > To: Juergen Quittek; isms@ietf.org > Subject: Re: [Isms] working group last > callondraft-ietf-isms-transport-security-model-03 > > I commented before that I do not find s.2 clear. I also > think that this is a > crucial section for the document as a whole, especially for > those who have not > lived with these ideas for the past two years, as it provides > the framework into > which the details will fit. I believe it should be explicit, > as in the > following, > with ** marking changes, of sentences or word > > > " The Transport Security Model is designed to fit into the RFC3411 > architecture as a Security Model in the Security Subsystem, and to > utilize the services of a secure Transport Model. > > **The secure Transport Model maintains a cache, referenced by > tmStateReference, > which is used to pass information between the Transport > Security Model and the > secure Transport Model, and vice versa. > > **If the Transport Security Model is used with an insecure > Transport Model, then > the cache is unlikely to be populated with security > parameters, which will cause > the Transport Security Model to return an error (see section 5.2) > > **If another Security Model (eg Community-based Security > Model) is used with a > secure Transport Model, then the cache will be populated but > the other Security > Model may be unaware of the cache and ignore its contents (eg > deriving the > securityName from the Community name in the message instead > of deriving it from > the cache). > > **When the Transport Security Model is used with a secure > Transport Model, as > is intended to be the case, then the information in the cache > is used by > the Transport Security Model to translate between the > security model-independent > securityName and any identity used by the secure transport; > and to record the > tmSecurityLevel provided for the message by the transport (a > level of security > which may exceed the securityLevel requested for the message by the > application). > > To > maintain the RFC3411 modularity, the Transport Model does not know > which securityModel will be used for an incoming message; > the Message > Processing Model will determine the securityModel to be used, in a > Message Processing Model dependent manner. In an SNMPv3 message > [RFC3412], the Transport Security Model **s/should/can/ be > specified in the > message header using the object securityModel. > **The use of the Transport Security Model with other message > types is outside > the scope of this document." > > > This is intended to be a rewording of what has been agreed > and not to introduce > changes. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: > Sent: Saturday, March 10, 2007 12:13 AM > Subject: [Isms] working group last call > ondraft-ietf-isms-transport-security-model-03 > > > > Dear all, > > > > This is the working group last call on the > > "Transport Security Model for SNMP" > > to be found at > > > -security-model-03 > .txt>. > > > > The authors and the chairs think that this document is mature enough > > for last call. > > > > Please do review the document and post your comments on > this list until > > March 25, 2007. Of course it would be great to get your > comments already > > before our next meeting on March 22. > > > > Please also post to the list if you have read the document > and are fine > > with it as it is. It is very useful to know how many > people have read > > the document. > > > > Thanks, > > > > Juergen Q. > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 4342-115 > > NEC Europe Limited, Network Laboratories Fax: +49 > 6221 4342-155 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > Registered in England 2832014 > > > > _______________________________________________ > > 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 Apr 25 02:33:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgb4J-0008Jf-31; Wed, 25 Apr 2007 02:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgb4I-0008JR-99 for isms@ietf.org; Wed, 25 Apr 2007 02:33:34 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgb4G-0002y5-MU for isms@ietf.org; Wed, 25 Apr 2007 02:33:34 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200704250633320140023hg3e>; Wed, 25 Apr 2007 06:33:32 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Juergen Quittek'" , References: Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Wed, 25 Apr 2007 02:33:27 -0400 Message-ID: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUA= X-Spam-Score: 1.1 (+) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e 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: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Monday, April 23, 2007 10:28 AM > To: Juergen Quittek; isms@ietf.org > Subject: RE: [Isms] working group last > callondraft-ietf-isms-transport-security-model-03 > > Sorry for being late. > > Here are my comments: > > - may want to state in the abstract that there is a MIB module > in this document. done. > > - I am not sure I understand points 1 and 2 of section 1.5. I don't remember where I copied the first bullet from. I removed it. The second says the TSM should not depend on third party functionality such as AAA, since it may not be available during times of network stress, and it doesn't. > > - Section 2, the last sentence leaves me wondering how it is > specified > for SNMPv1 and v2c. I would think that many people may want to > deploy SNMPv2c with SSH based Transport Security? > > Now I do see that in sect 2.3 you explain/state that the Transport > Security Model cannot be used with SNMPv1 and SNMPv2c. > I wonder if this is what the operator/user community wants/accepts?? > > The only reason I can see is, that SNMPv1/v2c do not pass a > securityModel > during message processing. Is that a good enough reason why > they could > not be securely transported? They certainly can be transported. The > only thing is that once it gets top SNMPv1/v2c Message Processing, > there is nothing that will detect that the msg was secured and so > it assumes unsecured transport (which may have impact in Access > Control > of course). But would we there fore state that such > messages cannot be > transported over TSM ? TSM is a security model. You don't transport anything over TSM. If somebody wants to use SSH-TM to transport SNMPv1/v2c messages, they can but they will not get TSM as the security model because SNMPv1/2c messages use the Community-based security model(s), per RFC3584. > > > - My arithmetic is not so great, but sect 2.3, 2nd para: > In the RFC3411 architecture, a Message Processing Model determines > which Security Model should be called. As of this writing, there > are > three Message Processing Models and three other Security Models: > SNMPv1, SNMPv2c, and the User-based Security Model. > > For me the three and three do not seem to be in sync with the items > listed after the colon. Possibly the 3 listed models are just the > 3 (other) security models. I think that is what it is, but I got > confused. Maybe you can make it less confusing. Maybe I am the only > one who got confused. Changed it: In the RFC3411 architecture, a Message Processing Model determines which Security Model should be called. As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model). > > - I see: 3.1.2. msgSecurityParameters > > Since message security is provided by a "lower layer", and the > securityName parameter is always determined by the Transport Model > from the lower layer authentication method, the SNMP message does > not > need to carry message security parameters within the > msgSecurityParameters field. The field msgSecurityParameters MUST > be > set to a zero-length OCTET STRING. > > I guess what we want to say is: > > - on incoming messages, the msgSecurityParameters field MUST be > ignored > - on outgoing messages, the msgSecurityParameters field > MUST be set > to a zero-length OCTET STRING. > > In other words: be liberal in what you accept and > conservative in what > you send > > But I see that in sect 5.2 step 2) you seem not to want to be so > liberal. > Do we really want to generate an error if someone has put some data > into > the msgSecurityParameters? As protection against viruses, yes. > > > - In sect 3.2.1, I am not sure that the 2nd para belongs here? > Such connection related info would not be saved in the > securityStateReference, > but rather in the tmStateReference, no? The Command Responder provides the (opaque) securityStateReference when it requests the response message be generated. The security model extracts the security info from the securityStateReference and sets the transport "session" to be used for a Response message. However, the security model does not know whether the transport connection has been closed (only the transport model knows this), and if the connection no longer exists when the message reaches the transport model, then the Response message MAY be discarded. > > > - In sect 4.1 we are adding > IN transportDomain -- (NEW) specified by > application > IN transportAddress -- (NEW) specified by > application > as new parameters in the generateRequestMsg ASI. > Should we not do so in the draft-ietf-isms-tmsm-07.txt document as > well? I added text to that effect in TMSM. > > - In sect 4.1 we're also adding > IN transportDomain -- (NEW) specified by > application > IN transportAddress -- (NEW) specified by > application > to the generateResponseMsg ASI. > Why do we do that? Why would that not have been cached in one way or > another? > So as to be sure that response returns to where the request > came from? > > In fact, sect 4.2, step one states that the transportDomain/Address > are > to be extracted from the securityStateReference. So it seem > we indeed > do > not need these 2 new parameters for prepareResponseMsg. The SNMPv3 WG made a deliberate decision to not require that the response always be based on securityStateReference; an example of when this might be useful is when the request can be made without encryption, but the response should be encrypted. The decision of whether the response must be sent using the same transport parameters is made by a combination of the application, the message processing model and the security model. In general, the security model has the last say. SNMPv3 and USM require the values in securityStateReference to be used for the response. The SNMPv3 WG designed the RFC3411 architecure to be modular and extensible. Unless we believe we have perfect knowledge of what future applications and MPMs and security models will be, we should not change the **architecture** to require that response messages can only be sent to the same transport session that sent the request. The MPMs and SMs can handle this just fine. The SNMPv3 WG made a decision that architecturally, the MPM and Security Subsystem should not get the transport information. The changes we are making to integrate SNMP with existing secure transports, we need to pass the transport information to the MP subsystem and Security subsystem. The generateRequest and generateResponse ASIs are at the same "level" of interface, and I think if we change one to make transport info available, then we should probably change both, so we do not have to have this discussion for every MPM and SM designed in the future. > > - In sect 4.2, step 1 > 1) If the messageProcessingModel is SNMPv3, then the > securityEngineID > is set to the local snmpEngineID, to satisfy the SNMPv3 message > processing defined in RFC 3412 section 7.2 13a). > > Why do we have to become SNMP version dependent here? > It would be fine to give all SNMP versions we know up till now the > same treatment, no? RFC3584 (top of page 28) does the same thing, > so we can do so too if it is SNMPv1 or v2c. And we can do it for SNMPv4 and SNMPv5 and SNMPv6 and SNMPv7 and ... WHY? Because SNMPv3 and ONLY SNMPv3 has a dependency on USM processing that it should NOT have if we had really made MPM and SM processing modular. But for expediency, we allowed dependencies between USM and SNMPv3, which are reflected in the ASIs. securityEngineID should have been something totally hidden inside the USM security model, but we blew it by not having perfect understanding of how future models would differ from USM. The ONLY reason we need to set securityEngineID is because SNMPv3 EOP was written with USM requirements embedded in its processing, so the SNMPv3 EOP requires it be passed in an ASI. No other MPM requires this parameter; no security model other than USM actually requires securityEngineID. This memo describes the Transport Security Model, and we will NEVER be able to process SNMPv1 or SNMPv2c messages as far as I can tell. You would need a new message format, or at least a new message processing model to pass SNMPv1/v2c-style messages into the Transport Security Model, which would NOT be the Community-based security models described in rfc 3584. So what rfc 3584 does is immaterial to this security model. Personally I hope we eliminate USM once and for all, so we can move away from the USM dependencies in the architecture and can move on to a cleaner architecture. I personally have no desire to keep requiring securityEngineID be used for no good reason in every future version of security models and SNMP message processing models. And, if it escaped your notice, I am passionate about this ;-) > > - It also seems to me that step 2 and 1 (in sect 4.1) are in conflict, > in > that step 2 (on a generateOutgoingRequestMsg) saves > transportAddress/Domain > (and other info) in tmStateReference but step 1 (on a > generateResponseMsg) > seems to want to extract it from a different cache, namely > securityStateReference? > Section 4.1 refers to outgoing messages. For an outgoing response (step 1), there should be a existing securityStateReference. For an outgoing message other than a response (step 2), we want to put the information provided by the application about where to send the message into the tmStateReference cache so the transport model knows where to send it. securityStateReference is not created when a request goes out, it is created when a request comes in (section 5.2, step 9). > > > > - At the top of page 21, I wonder if > * snmpTargetParamsSecurityName "sampleUser" > Should be marked with an asterisk. > The securityName is securityModel INDEPENDENT (I believe). > It may be the case that the TransportSecurityModel uses identity > function (as does USM) for translating it to a securityModel > dependent userName, but that does not make this value > TransportSecurityModel specific/dependent, does it? > Hmmm. I'm not sure either. I removed the asterisk. > > MIB review: > > - for the Counter32s, do we not need to state if (and if so which) > discontinuities can occur? It seems this was modeled after > the USM-MIB > and yep we forgot that in that MIB module too. That does not mean > we need to make the same mistake now. I added text that says the value is not persistent across reboots. Does that address your concern adequately? I am not sure there is value of having this be persistent. > > - tsmInvalidCache OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of messages dropped because the > tmStateReference referred to an invalid cache. > > This sounds as a "debugging internals of an implementation" > object to > me. > Do we need this? InvalidCache is incremented on an incoming message when security information has not been provided by the transport model, indicating that the transport is not a secure transport (or possibly an implementation error, but that is incidental). > > - I wonder if we need something like unknown userNames ?? InvalidCache provides this for incoming messages (The transport model has not told us what securityName to use.) > What if a notification originator as a SecurityName configured > (through > SNMP maybe) that cannot be mapped to a proper identity inside the > transport model? Do we not want to be able to see that in some > statistic? That would need to be a counter for the specific transport model. For SSH-TM, for example, the identity transform is used to do the mapping, so the mappng should always be successful (the authentication may not be though). Other security models might use different mapping techniques. > > > Here are nits and typos: > > - section 1.3 > > the SNMP architecture, as defined in [RFC3411],and the > architecture > > s/,and/, and/ > > - page 4: > 2. How Transport Security Model Fits in the Architecture > > s/How/How the/ ?? > > > I did spend several hours on this. > But I think I need a second pass of a few dedicated hours (at least) > in order to make sure I have checked and understood everything. > Modularity is nice.... but it means you need to check several > documents > at the same time in order to get the complete picture. Also when editing. sigh. > > Bert Wijnen > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > Sent: Saturday, March 10, 2007 12:14 AM > > To: isms@ietf.org > > Subject: [Isms] working group last call > > ondraft-ietf-isms-transport-security-model-03 > > > > Dear all, > > > > This is the working group last call on the > > "Transport Security Model for SNMP" > > to be found at > > > -security-model-03.txt>. > > > > The authors and the chairs think that this document is mature > > enough for last call. > > > > Please do review the document and post your comments on this > > list until March 25, 2007. Of course it would be great to > > get your comments already before our next meeting on March 22. > > > > Please also post to the list if you have read the document > > and are fine with it as it is. It is very useful to know how > > many people have read the document. > > > > Thanks, > > > > Juergen Q. > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > > 6221 4342-115 > > NEC Europe Limited, Network Laboratories Fax: +49 > > 6221 4342-155 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, > > UK Registered in England 2832014 > > > > _______________________________________________ > > 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 Apr 25 10:14:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGe-0005Wi-FB; Wed, 25 Apr 2007 10:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGc-0005Vv-IY for isms@ietf.org; Wed, 25 Apr 2007 10:14:46 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiGc-0002Sl-0b for isms@ietf.org; Wed, 25 Apr 2007 10:14:46 -0400 Received: from pc6 (1Cust57.tnt30.lnd3.gbr.da.uu.net [62.188.122.57]) by ranger.systems.pipex.net (Postfix) with SMTP id 68DADE0001DA; Wed, 25 Apr 2007 15:14:40 +0100 (BST) Message-ID: <013701c7873b$3e26d120$0601a8c0@pc6> From: "tom.petch" To: "Wijnen, Bert (Bert)" , "Juergen Quittek" , References: Subject: Re: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Wed, 25 Apr 2007 15:07:03 +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.1 (+) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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: , Errors-To: isms-bounces@lists.ietf.org some comments inline on Bert's comments on the text; getting a bit lengthy so probably worth splitting if the discussion gets extended Tom Petch ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Juergen Quittek" ; Sent: Monday, April 23, 2007 4:28 PM Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Sorry for being late. Here are my comments: - may want to state in the abstract that there is a MIB module in this document. - I am not sure I understand points 1 and 2 of section 1.5. No but they have come from RFC3414 so ... - Section 2, the last sentence leaves me wondering how it is specified for SNMPv1 and v2c. I would think that many people may want to deploy SNMPv2c with SSH based Transport Security? Now I do see that in sect 2.3 you explain/state that the Transport Security Model cannot be used with SNMPv1 and SNMPv2c. I wonder if this is what the operator/user community wants/accepts?? The only reason I can see is, that SNMPv1/v2c do not pass a securityModel during message processing. Is that a good enough reason why they could not be securely transported? They certainly can be transported. The only thing is that once it gets top SNMPv1/v2c Message Processing, there is nothing that will detect that the msg was secured and so it assumes unsecured transport (which may have impact in Access Control of course). But would we there fore state that such messages cannot be transported over TSM ? I too found this confusing and did suggest some alternative working to cover all bases - My arithmetic is not so great, but sect 2.3, 2nd para: In the RFC3411 architecture, a Message Processing Model determines which Security Model should be called. As of this writing, there are three Message Processing Models and three other Security Models: SNMPv1, SNMPv2c, and the User-based Security Model. For me the three and three do not seem to be in sync with the items listed after the colon. Possibly the 3 listed models are just the 3 (other) security models. I think that is what it is, but I got confused. Maybe you can make it less confusing. Maybe I am the only one who got confused. I agree, confusing; I read the 'other' as meaning 'in addition' - I see: 3.1.2. msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is always determined by the Transport Model from the lower layer authentication method, the SNMP message does not need to carry message security parameters within the msgSecurityParameters field. The field msgSecurityParameters MUST be set to a zero-length OCTET STRING. I guess what we want to say is: - on incoming messages, the msgSecurityParameters field MUST be ignored - on outgoing messages, the msgSecurityParameters field MUST be set to a zero-length OCTET STRING. In other words: be liberal in what you accept and conservative in what you send But I see that in sect 5.2 step 2) you seem not to want to be so liberal. Do we really want to generate an error if someone has put some data into the msgSecurityParameters? I would generate an error since it suggests a pronounced mismatch in understanding between sender and receiver - In sect 3.2.1, I am not sure that the 2nd para belongs here? Such connection related info would not be saved in the securityStateReference, but rather in the tmStateReference, no? - In sect 4.1 we are adding IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application as new parameters in the generateRequestMsg ASI. Should we not do so in the draft-ietf-isms-tmsm-07.txt document as well? I think not since this is MPM to SM ASI, RFC 3412/4 as opposed to RFC3411. - In sect 4.1 we're also adding IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application to the generateResponseMsg ASI. Why do we do that? Why would that not have been cached in one way or another? So as to be sure that response returns to where the request came from? In fact, sect 4.2, step one states that the transportDomain/Address are to be extracted from the securityStateReference. So it seem we indeed do not need these 2 new parameters for prepareResponseMsg. I think that this has got tangled up with sending the Response back over the session that the Request came over; if that is a MUST, then the ASI does not need the parameters; but if it is a SHOULD, I am less clear. - In sect 4.2, step 1 Section 5.2 I think 1) If the messageProcessingModel is SNMPv3, then the securityEngineID is set to the local snmpEngineID, to satisfy the SNMPv3 message processing defined in RFC 3412 section 7.2 13a). Why do we have to become SNMP version dependent here? It would be fine to give all SNMP versions we know up till now the same treatment, no? RFC3584 (top of page 28) does the same thing, so we can do so too if it is SNMPv1 or v2c. - It also seems to me that step 2 and 1 (in sect 4.1) are in conflict, in that step 2 (on a generateOutgoingRequestMsg) saves transportAddress/Domain (and other info) in tmStateReference but step 1 (on a generateResponseMsg) seems to want to extract it from a different cache, namely securityStateReference? The way I see it both caches are needed. tmStateReference passes (a pointer to) transport details between the (newly defined) transport model and the security model while securityStateReference (which is already defined) does the same between SM and MPM for Confirmed class messages - At the top of page 21, I wonder if * snmpTargetParamsSecurityName "sampleUser" Should be marked with an asterisk. The securityName is securityModel INDEPENDENT (I believe). It may be the case that the TransportSecurityModel uses identity function (as does USM) for translating it to a securityModel dependent userName, but that does not make this value TransportSecurityModel specific/dependent, does it? I agree _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Apr 25 10:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGf-0005Y8-Km; Wed, 25 Apr 2007 10:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGe-0005Wq-F9 for isms@ietf.org; Wed, 25 Apr 2007 10:14:48 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiGd-0002Sp-4w for isms@ietf.org; Wed, 25 Apr 2007 10:14:48 -0400 Received: from pc6 (1Cust57.tnt30.lnd3.gbr.da.uu.net [62.188.122.57]) by ranger.systems.pipex.net (Postfix) with SMTP id 0589AE0001D3; Wed, 25 Apr 2007 15:14:45 +0100 (BST) Message-ID: <013801c7873b$3f874b80$0601a8c0@pc6> From: "tom.petch" To: , References: <20070420101206.GA11595@elstar.local> Subject: Re: [Isms] prague meeting minutes Date: Wed, 25 Apr 2007 15:08:02 +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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: isms-bounces@lists.ietf.org Good to see compact minutes. I don't know what was said at the meeting about issues #1 to #6 so this may be matters arising but the minutes seem somewhat at variance with the discussions on the list beforehand. Issue #1 I thought agreed that responses MUST rather than SHOULD go back on the same channel else there was a security exposure but that that linked into Issue #3 which on the list was about session reuse rather than 'transport does not know the difference between requests and notifications' and seemed to peter out without reaching a consensus. (In passing, this referenced the use of ports 161 and 162 which leaves me confused in a ssh tranport context so I am posting that separately). Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Friday, April 20, 2007 12:12 PM Subject: [Isms] prague meeting minutes > Hi, > > the ISMS meeting minutes can be found at: > > http://www3.ietf.org/proceedings/07mar/minutes/isms.txt > > Please take a look and let me know if something needs to be changed. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > 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 Apr 25 10:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGf-0005Yn-Pc; Wed, 25 Apr 2007 10:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiGe-0005Xd-OV for isms@ietf.org; Wed, 25 Apr 2007 10:14:48 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiGe-0002Ss-C8 for isms@ietf.org; Wed, 25 Apr 2007 10:14:48 -0400 Received: from pc6 (1Cust57.tnt30.lnd3.gbr.da.uu.net [62.188.122.57]) by ranger.systems.pipex.net (Postfix) with SMTP id 30385E0000AF for ; Wed, 25 Apr 2007 15:14:47 +0100 (BST) Message-ID: <013901c7873b$4025fc80$0601a8c0@pc6> From: "tom.petch" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6> <20070412064949.GB7796@elstar.local> Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-id discovery process Date: Wed, 25 Apr 2007 15:08:46 +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.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: isms-bounces@lists.ietf.org The impression I have is that for SNMP over SSH (and most likely for other such session transports) there will be but one port, for both Notifications and Requests. In which case, I think that TMSM s3.1.1 should mention this, that the application can no longer use port 161 and 162 to differentiate the traffic; they will, perforce, share the session (assuming the other session selection parameters are the same). Unless the intention is for the application to still use 161 and 162 but for these to be translated somewhere in the ASIs to the SSH port; seema unlikely. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: Sent: Thursday, April 12, 2007 8:49 AM Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-id discovery process > On Wed, Apr 11, 2007 at 07:03:52PM +0200, tom.petch wrote: > > > From that, another query. What happens to port numbers with TMSM? At present, > > SNMP applications use 161 and 162 (mostly) which then becomes part of the key > > for selecting engineID. Will applications still use this at the ASI to the > > Dispatcher? If and when does this change to a secure transport port? > > We currently use a user supplied port number and we expect that a > default port number for a secure transport model will be allocated by > the secure transport model specification. In other words, this is part > of the SSH transport model specification to spell out (together with > the proper TDomain definitions). > > Since we use TDomain/TAddress in the ASIs, nothing is going to change > about the ASIs and the internals of the Dispatcher as far as I can > tell. > > /js > > -- > Juergen Schoenwaelder Jacobs 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 Wed Apr 25 11:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjM7-0007uS-0V; Wed, 25 Apr 2007 11:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjM5-0007my-Gk for isms@ietf.org; Wed, 25 Apr 2007 11:24:29 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgjM4-0003nX-67 for isms@ietf.org; Wed, 25 Apr 2007 11:24:29 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <20070425152427012003714je>; Wed, 25 Apr 2007 15:24:27 +0000 From: "David Harrington" To: "'tom.petch'" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6><00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Wed, 25 Apr 2007 11:24:22 -0400 Message-ID: <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013901c7873b$4025fc80$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceHRBYA2dK9kdciS6CHriZ+s+3A8AABrxIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Errors-To: isms-bounces@lists.ietf.org The SNMP applications (Commnd Requetser, Command Responder, et al) specify the transport addresses, possibly based on pre-configured MIBs or other administrative configuration. An NMS may allow an administrator to decide which ports, and some NMSs may allow the ports for both types of traffic to be the same, others may require separate ports. I expect that on the NMS side, a software application may force the decision about whether RR runs on a separate transport from notifications, because the software code that supports handling asynchronous messages might be very different than the software code for handling response/requests. I consider this fairly likely because a) the processing required for event-driven management can be quite different for polling-driven management, and b) SNMP has traditionally used two ports to differentiate the different types of traffic, so existing SNMP applications might find it easier to migrate to SSH-TM using separate ports. The question we need to be conerned with is should we have IANA assign one or more default ports for SSH-TM. It is my intention to ask for one default port. The mention of 161 and 162 was only an example of how traffic can be separated by port number; I was not recommending the use of 161 and 162. I will try to make that clear in the SSH transport model. I will check the TMSM to see if I need to clarify anything there. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, April 25, 2007 9:09 AM > Cc: isms@ietf.org > Subject: Re: TMSM and Port was Re: [Isms] Question regarding > SNMPv3engine-iddiscovery process > > The impression I have is that for SNMP over SSH (and most > likely for other such > session transports) there will be but one port, for both > Notifications and > Requests. > > In which case, I think that TMSM s3.1.1 should mention this, that the > application can no longer use port 161 and 162 to > differentiate the traffic; > they will, perforce, share the session (assuming the other > session selection > parameters are the same). Unless the intention is for the > application to still > use 161 and 162 but for these to be translated somewhere in > the ASIs to the SSH > port; seema unlikely. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "tom.petch" > Cc: > Sent: Thursday, April 12, 2007 8:49 AM > Subject: Re: TMSM and Port was Re: [Isms] Question regarding > SNMPv3engine-id > discovery process > > > > On Wed, Apr 11, 2007 at 07:03:52PM +0200, tom.petch wrote: > > > > > From that, another query. What happens to port numbers > with TMSM? At > present, > > > SNMP applications use 161 and 162 (mostly) which then > becomes part of the > key > > > for selecting engineID. Will applications still use this > at the ASI to the > > > Dispatcher? If and when does this change to a secure > transport port? > > > > We currently use a user supplied port number and we expect that a > > default port number for a secure transport model will be > allocated by > > the secure transport model specification. In other words, > this is part > > of the SSH transport model specification to spell out (together with > > the proper TDomain definitions). > > > > Since we use TDomain/TAddress in the ASIs, nothing is going > to change > > about the ASIs and the internals of the Dispatcher as far as I can > > tell. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen > > P.O. Box 750 561, 28725 > Bremen, Germany > > > _______________________________________________ > 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 Apr 25 12:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgkin-000896-V6; Wed, 25 Apr 2007 12:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgkim-00088z-Ro for isms@ietf.org; Wed, 25 Apr 2007 12:52:00 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgkik-0007Pn-JP for isms@ietf.org; Wed, 25 Apr 2007 12:52:00 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200704251651580140024eage>; Wed, 25 Apr 2007 16:51:58 +0000 From: "David Harrington" To: "'tom.petch'" , , References: <20070420101206.GA11595@elstar.local> <013801c7873b$3f874b80$0601a8c0@pc6> Subject: RE: [Isms] prague meeting minutes Date: Wed, 25 Apr 2007 12:51:52 -0400 Message-ID: <020a01c7875a$06daafb0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013801c7873b$3f874b80$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceHRBVn82GaoN0lTdyaodJHojnPVQAC9K9w X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: isms-bounces@lists.ietf.org Hi, The minutes loook good. There are a couple corrections, and some additonal explanation that might help others understand them better. In the minutes, it says "Dave went through the resolution of the transport mapping model last call comments:" There is no "transport mapping model" document; There is a Transport Subsystem, a Transport Security Model, and an SSH Transport Model. The discussion at that point in the presentation was about the Transport Subsystem document last call. Issue#1: The Transport Subsystem architecture document will reflect the SNMPv3 WG's decision that **architecturally** this is a SHOULD. The decision is security-model-dependent, and the Transport Security Model will make it a MUST. The Transport Subsystem architecture document will avoid adding CLRs, and continue to reflect the SNMPv3 WG's decision that **architecturally** it is a SHOULD, because there may be future extensions (e.g. new security models) where, for some acceptable reason, it is not a security exposure and therefore not a MUST. We should assume that designers of future security models will be just as smart as we are, and given the technologies and best current practices at that time, will make the right decisions for their security models. The WG reached consensus that this is a security issue; the security models are the right place to address this issue. For USM and TSM, this mismatch could be a security exposure, so they make #1 a MUST. In TSM, the use of the same transport parameters is addressed in section 4.2, bullet 1), where the transport parameters are extracted from the securityStateReference. To resolve the interrelationship of #1 with #3, the unpublished updated draft adds another parameter to the tmStateReference to tell the transport model that this must be the same session that the request came in on, not a new session identified by the same parameters (transportdomain/address,securityname/level). Issue #3: Only the transport model knows about transport sessions, and the transport model does not know the content of the pdu, so it cannot tell the difference between a request/response and a notification. What the transport model can tell is what transport address and what securityName it is told to send to (by the SNMP application). If the **application** wants to use different sessions for different types of pdus, then it can do so by using different transport addresses or different securityNames. Part 3. There is a fourth option that isn't mentioned in the minutes - d) the development of a new access control model. But development of a new access control model is out of scope of the current charter. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Apr 26 10:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5Nc-0006bt-Nv; Thu, 26 Apr 2007 10:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5Nc-0006bo-CB for isms@ietf.org; Thu, 26 Apr 2007 10:55:32 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5Na-0003os-Kj for isms@ietf.org; Thu, 26 Apr 2007 10:55:32 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3QEtJYF022544; Thu, 26 Apr 2007 09:55:29 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:55:16 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 16:55:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Thu, 26 Apr 2007 16:55:03 +0200 Message-ID: In-Reply-To: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUAATL4U4A== References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Juergen Quittek" , X-OriginalArrivalTime: 26 Apr 2007 14:55:12.0167 (UTC) FILETIME=[E4238370:01C78812] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 1.1 (+) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 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: , Errors-To: isms-bounces@lists.ietf.org Inline Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, April 25, 2007 8:33 AM > To: Wijnen, Bert (Bert); 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] working group last=20 > callondraft-ietf-isms-transport-security-model-03 >=20 > Hi,=20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Monday, April 23, 2007 10:28 AM > > To: Juergen Quittek; isms@ietf.org > > Subject: RE: [Isms] working group last > > callondraft-ietf-isms-transport-security-model-03 > >=20 > > Sorry for being late. > >=20 > > Here are my comments: > >=20 > > - may want to state in the abstract that there is a MIB module > > in this document. >=20 > done. > >=20 > > - I am not sure I understand points 1 and 2 of section 1.5. >=20 > I don't remember where I copied the first bullet from. I removed it. >=20 OK > The second says the TSM should not depend on third party=20 > functionality such as AAA, since it may not be available=20 > during times of network stress, and it doesn't. >=20 So, my understanding is that TSM is not dependent on AAA, but somewhere in the whole ISMS solution we will be dependent on AAA for authorization, no? > > =20 > > - Section 2, the last sentence leaves me wondering how it is specified > > for SNMPv1 and v2c. I would think that many people may want to=20 > > deploy SNMPv2c with SSH based Transport Security? > >=20 > > Now I do see that in sect 2.3 you explain/state that the Transport > > Security Model cannot be used with SNMPv1 and SNMPv2c.=20 > > I wonder if this is what the operator/user community wants/accepts?? > >=20 > > The only reason I can see is, that SNMPv1/v2c do not pass a securityModel > > during message processing. Is that a good enough reason why they could > > not be securely transported? They certainly can be transported. The > > only thing is that once it gets top SNMPv1/v2c Message Processing, >=20 > > there is nothing that will detect that the msg was secured and so > > it assumes unsecured transport (which may have impact in Access Control > > of course). But would we there fore state that such messages cannot be > > transported over TSM ? >=20 > TSM is a security model. You don't transport anything over TSM. >=20 OK, sorry I got mixed up here. > If somebody wants to use SSH-TM to transport SNMPv1/v2c=20 > messages, they can but they will not get TSM as the security=20 > model because SNMPv1/2c messages use the Community-based=20 > security model(s), per RFC3584. So that could be an easy update to RFC3584, I guess, and then=20 we could let those messages be handled by the TSM, no? In any event, such could be done, And so I think it would be better to not speak about a specific SNMP version in the TSM. > > =20 > >=20 > > - My arithmetic is not so great, but sect 2.3, 2nd para: > > In the RFC3411 architecture, a Message Processing Model determines > > which Security Model should be called. As of this writing, there are > > three Message Processing Models and three other Security Models: > > SNMPv1, SNMPv2c, and the User-based Security Model. > >=20 > > For me the three and three do not seem to be in sync with the items > > listed after the colon. Possibly the 3 listed models are just the > > 3 (other) security models. I think that is what it is, but I got > > confused. Maybe you can make it less confusing. Maybe I am the only > > one who got confused. >=20 > Changed it: >=20 > In the RFC3411 architecture, a Message Processing Model=20 > determines which Security Model should be called. As of this=20 > writing, IANA has registered four Message Processing Models=20 > (SNMPv1, SNMPv2c, SNMPv2u/SNMPv2*, and SNMPv3) and three=20 > other Security Models (SNMPv1, SNMPv2c, and the User-based=20 > Security Model). >=20 Thanks. > >=20 > > - I see: 3.1.2. msgSecurityParameters > >=20 > > Since message security is provided by a "lower layer", and the > > securityName parameter is always determined by the Transport Model > > from the lower layer authentication method, the SNMP message does not > > need to carry message security parameters within the > > msgSecurityParameters field. The field msgSecurityParameters MUST be > > set to a zero-length OCTET STRING. > >=20 > > I guess what we want to say is: > >=20 > > - on incoming messages, the msgSecurityParameters field MUST be ignored > > - on outgoing messages, the msgSecurityParameters field MUST be set > > to a zero-length OCTET STRING. > >=20 > > In other words: be liberal in what you accept and conservative in=20 > > what you send > >=20 > > But I see that in sect 5.2 step 2) you seem not to want to be so liberal. > > Do we really want to generate an error if someone has put some data into > > the msgSecurityParameters? >=20 > As protection against viruses, yes. >=20 Mmmm.. not sure I agree.=20 If I am the only one... pls ignore me (on this point). > >=20 > >=20 > > - In sect 3.2.1, I am not sure that the 2nd para belongs here? > > Such connection related info would not be saved in the securityStateReference, > > but rather in the tmStateReference, no? >=20 > The Command Responder provides the (opaque)=20 > securityStateReference when it requests the response message=20 > be generated. The security model extracts the security info=20 > from the securityStateReference and sets the transport=20 > "session" to be used for a Response message.=20 >=20 > However, the security model does not know whether the=20 > transport connection has been closed (only the transport=20 > model knows this), and if the connection no longer exists=20 > when the message reaches the transport model, then the=20 > Response message MAY be discarded. >=20 Yeah... but why do we need to say that in TSM ?? > >=20 > >=20 > > - In sect 4.1 we are adding > > IN transportDomain -- (NEW) specified by=20 > > application > > IN transportAddress -- (NEW) specified by=20 > > application > > as new parameters in the generateRequestMsg ASI. > > Should we not do so in the draft-ietf-isms-tmsm-07.txt document as > > well? >=20 > I added text to that effect in TMSM. >=20 thanks > >=20 > > - In sect 4.1 we're also adding=20 > > IN transportDomain -- (NEW) specified by=20 > > application > > IN transportAddress -- (NEW) specified by=20 > > application > > to the generateResponseMsg ASI. > > Why do we do that? Why would that not have been cached in one way > or > > another? > > So as to be sure that response returns to where the request came=20 > > from? > >=20 > > In fact, sect 4.2, step one states that the > transportDomain/Address > > are > > to be extracted from the securityStateReference. So it seem we=20 > > indeed do > > not need these 2 new parameters for prepareResponseMsg. >=20 > The SNMPv3 WG made a deliberate decision to not require that=20 > the response always be based on securityStateReference; an=20 > example of when this might be useful is when the request can=20 > be made without encryption, but the response should be encrypted.=20 >=20 > The decision of whether the response must be sent using the=20 > same transport parameters is made by a combination of the=20 > application, the message processing model and the security=20 > model. In general, the security model has the last say. =20 > SNMPv3 and USM require the values in securityStateReference=20 > to be used for the response.=20 >=20 > The SNMPv3 WG designed the RFC3411 architecure to be modular=20 > and extensible. Unless we believe we have perfect knowledge=20 > of what future applications and MPMs and security models will=20 > be, we should not change the **architecture** to require that=20 > response messages can only be sent to the same transport=20 > session that sent the request. The MPMs and SMs can handle=20 > this just fine. >=20 > The SNMPv3 WG made a decision that architecturally, the MPM=20 > and Security Subsystem should not get the transport=20 > information. The changes we are making to integrate SNMP with=20 > existing secure transports, we need to pass the transport=20 > information to the MP subsystem and Security subsystem. The=20 > generateRequest and generateResponse ASIs are at the same=20 > "level" of interface, and I think if we change one to make=20 > transport info available, then we should probably change=20 > both, so we do not have to have this discussion for every MPM=20 > and SM designed in the future. >=20 You clearly are convinced that what you have is correct. I am not so convinced, but don't have the arguments ready right now to gointo a discussion. So unless someone else picks up on this I may accept your reasoning (or choice). > >=20 > > - In sect 4.2, step 1 > > 1) If the messageProcessingModel is SNMPv3, then the=20 > > securityEngineID > > is set to the local snmpEngineID, to satisfy the SNMPv3 message > > processing defined in RFC 3412 section 7.2 13a). > >=20 > > Why do we have to become SNMP version dependent here? > > It would be fine to give all SNMP versions we know up till now the > > same treatment, no? RFC3584 (top of page 28) does the same thing, > > so we can do so too if it is SNMPv1 or v2c. >=20 > And we can do it for SNMPv4 and SNMPv5 and SNMPv6 and SNMPv7 and ... >=20 > WHY? Because SNMPv3 and ONLY SNMPv3 has a dependency on USM=20 > processing that it should NOT have if we had really made MPM=20 > and SM processing modular. But for expediency, we allowed=20 > dependencies between USM and SNMPv3, which are reflected in=20 > the ASIs. securityEngineID should have been something totally=20 > hidden inside the USM security model, but we blew it by not=20 > having perfect understanding of how future models would=20 > differ from USM. >=20 iirc, we blew it for other reasons. But that is OK, we don't need to re-open that debate, that is water under the bridge. > The ONLY reason we need to set securityEngineID is because=20 > SNMPv3 EOP was written with USM requirements embedded in its=20 > processing, so the > SNMPv3 EOP requires it be passed in an ASI. No other MPM=20 > requires this parameter; no security model other than USM=20 > actually requires securityEngineID. > So is it not such then that the securityEngineID is irrelevant in this case and so that it does not matter what we set it to? The only place (I think) were we erred in SNMPv3 MP is in RFC3412 page 36/37, step 13: 13) If the pduType is from the Confirmed Class, then: a) If the value of securityEngineID is not equal to the value of snmpEngineID, then the security state information is discarded, any cached information about this message is discarded, the incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete.=20 We can fix it in 2 ways: - Update rfc3412 to say that we only check this for USM security model I know we'd rather not touch 3412 - In non-USM securityModels, no matter what, just always set=20 securityEngineID to the local snmpEngineID. It won't hurt (I think). > This memo describes the Transport Security Model, and we will=20 > NEVER be able to process SNMPv1 or SNMPv2c messages as far as=20 > I can tell.=20 We have not really explored that very much have we? > You would need a new message format, or at least=20 > a new message processing model to pass SNMPv1/v2c-style=20 > messages into the Transport Security Model, which would NOT=20 > be the Community-based security models described in rfc 3584.=20 > So what rfc 3584 does is immaterial to this security model. >=20 Could it not be as simple as seeing that we get a tmStateReference on incoming messages and then we know we need to send them to TSM? It would mean eitehr an update to 3584, or a new document that=20 describes SNMPv1/v2c over secure transport, we could called it=20 SSNMPv1 secure MP and SNMPv2c secure MP (SNMPv1SMP and SNMPv2cSMP) which would call TSM. Not sure I would really want to stimulate continued use of SNMPv1, but v2c might make sense. ANd if opertros tells us they won't migrate away from v1, then we might as well try to make it secure if it is reasonably odable over a secure transport. > Personally I hope we eliminate USM once and for all, so we=20 > can move away from the USM dependencies in the architecture=20 > and can move on to a cleaner architecture. I personally have=20 > no desire to keep requiring securityEngineID be used for no=20 > good reason in every future version of security models and=20 > SNMP message processing models. >=20 If it is as simple as "set it to loacalEngineID", then what is the problem? OK not 100% clean, but what in our whole Internet is 100% clean anymore? > And, if it escaped your notice, I am passionate about this ;-) >=20 yeah I did. It brings up memories of our fruitfull discussion in newHampshire in 1996 (I believe it was 96). ;-) when we worried so much about not disturbing your neigbours at 2 or 3 am. > >=20 > > - It also seems to me that step 2 and 1 (in sect 4.1) are in > conflict, > > in > > that step 2 (on a generateOutgoingRequestMsg) saves=20 > > transportAddress/Domain > > (and other info) in tmStateReference but step 1 (on a > > generateResponseMsg) > > seems to want to extract it from a different cache, namely=20 > > securityStateReference? > >=20 > Section 4.1 refers to outgoing messages. For an outgoing=20 > response (step 1), there should be a existing securityStateReference.=20 >=20 > For an outgoing message other than a response (step 2), we=20 > want to put the information provided by the application about=20 > where to send the message into the tmStateReference cache so=20 > the transport model knows where to send it. >=20 > securityStateReference is not created when a request goes=20 > out, it is created when a request comes in (section 5.2, step 9). >=20 OK, I will reread a few times. > >=20 > >=20 > >=20 > > - At the top of page 21, I wonder if > > * snmpTargetParamsSecurityName "sampleUser" > > Should be marked with an asterisk. > > The securityName is securityModel INDEPENDENT (I believe). > > It may be the case that the TransportSecurityModel uses identity > > function (as does USM) for translating it to a securityModel > > dependent userName, but that does not make this value=20 > > TransportSecurityModel specific/dependent, does it? > >=20 > Hmmm. I'm not sure either. I removed the asterisk. >=20 good. > >=20 > > MIB review: > >=20 > > - for the Counter32s, do we not need to state if (and if so which) > > discontinuities can occur? It seems this was modeled after the=20 > > USM-MIB > > and yep we forgot that in that MIB module too. That does not mean > > we need to make the same mistake now. >=20 > I added text that says the value is not persistent across reboots. > Does that address your concern adequately? I am not sure=20 > there is value of having this be persistent. >=20 Nop, if you reboot, that is always a possible discontinuity . If that is the only possibility for discontinuity (I think it is), then we just need to say that. > >=20 > > - tsmInvalidCache OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "The number of messages dropped because the > > tmStateReference referred to an invalid cache. > >=20 > > This sounds as a "debugging internals of an implementation"=20 > > object to me. Do we need this? >=20 > InvalidCache is incremented on an incoming message when=20 > security information has not been provided by the transport=20 > model, indicating that the transport is not a secure=20 > transport (or possibly an implementation error, but that is=20 > incidental). >=20 I am still somehwat confused. But if this is all that is left, we're good shape. > > =20 > > - I wonder if we need something like unknown userNames ?? >=20 > InvalidCache provides this for incoming messages (The=20 > transport model has not told us what securityName to use.) >=20 So invalidCache is overloaded with multiple meanings? Does not sound good to me. > > What if a notification originator as a SecurityName configured=20 > > (through > > SNMP maybe) that cannot be mapped to a proper identity inside the > > transport model? Do we not want to be able to see that in some=20 > > statistic? >=20 > That would need to be a counter for the specific transport model.=20 > For SSH-TM, for example, the identity transform is used to do=20 > the mapping, so the mappng should always be successful (the=20 > authentication may not be though). > Other security models might use different mapping techniques. OK > >=20 > >=20 > > Here are nits and typos: > >=20 > > - section 1.3 > >=20 > > the SNMP architecture, as defined in [RFC3411],and the=20 > > architecture > >=20 > > s/,and/, and/ > >=20 > > - page 4: > > 2. How Transport Security Model Fits in the Architecture > >=20 > > s/How/How the/ ?? > >=20 > >=20 > > I did spend several hours on this. > > But I think I need a second pass of a few dedicated hours=20 > (at least)=20 > > in order to make sure I have checked and understood everything. > > Modularity is nice.... but it means you need to check several=20 > > documents at the same time in order to get the complete picture. >=20 > Also when editing. sigh. >=20 yep, that must be worse. Cause you have to dream up (or design/compose) the text. I only have to check if I think it is correct or not. Bert > >=20 > > Bert Wijnen > >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Apr 26 12:27:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6p0-0001E7-CE; Thu, 26 Apr 2007 12:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6oz-0001Dz-Bf for isms@ietf.org; Thu, 26 Apr 2007 12:27:53 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6ow-0001Oo-1j for isms@ietf.org; Thu, 26 Apr 2007 12:27:53 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3A1287689C; Thu, 26 Apr 2007 18:27:49 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22742-08; Thu, 26 Apr 2007 18:27:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9B45755E44; Thu, 26 Apr 2007 18:27:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A65423B71D; Thu, 26 Apr 2007 18:27:44 +0200 (CEST) Date: Thu, 26 Apr 2007 18:27:44 +0200 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Message-ID: <20070426162744.GB7092@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , isms@ietf.org References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.2 (+) 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: , Errors-To: isms-bounces@lists.ietf.org On Thu, Apr 26, 2007 at 04:55:03PM +0200, Wijnen, Bert (Bert) wrote: > So, my understanding is that TSM is not dependent on AAA, but > somewhere in the whole ISMS solution we will be dependent on AAA for > authorization, no? My understanding is that a secure transport model _may_ call a AAA service for authentication (e.g. verification of a password) and a secure transport model _may_ (at the same time) call a AAA service for service authorization. The details may be transport model specific. In essence, AAA says "go ahead" or "go way" when the secure session is being established. As discussed in Prague, we believe that any further authorization via a AAA service (e.g. policy mapping in the form of securityName to groupName mapping) or even the provisioning of access control rules by a AAA server are outside of the current ISMS charter, but may be considered as future work items once we have successfully completed the work we are chartered to do. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 27 03:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhL3F-0006J9-Ia; Fri, 27 Apr 2007 03:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhL3E-0006Ht-L2 for isms@ietf.org; Fri, 27 Apr 2007 03:39:32 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhL3A-0005zn-13 for isms@ietf.org; Fri, 27 Apr 2007 03:39:32 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3R7dJNo027970; Fri, 27 Apr 2007 02:39:22 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 02:39:21 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:39:18 +0200 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 Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Date: Fri, 27 Apr 2007 09:39:17 +0200 Message-ID: In-Reply-To: <20070426162744.GB7092@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Thread-Index: AceIH9qwKIiC5uajTce09der+ozCpwAffnbg References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <20070426162744.GB7092@elstar.local> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 27 Apr 2007 07:39:18.0853 (UTC) FILETIME=[29F63F50:01C7889F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: isms-bounces@lists.ietf.org I agree with that. But that means that such a security model IS (will be) dependent on a 3rd party service. And the comment I had is that the document seems to state that we SHOULD NOT depend on other networkk services (point 2 in sect 1.5). SO I can live if we remove that requirement, but we shouldbe honest in advertising. Bert Wijnen =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Thursday, April 26, 2007 6:28 PM > To: Wijnen, Bert (Bert) > Cc: isms@ietf.org > Subject: Re: [Isms] working group=20 > lastcallondraft-ietf-isms-transport-security-model-03 >=20 > On Thu, Apr 26, 2007 at 04:55:03PM +0200, Wijnen, Bert (Bert) wrote: > =20 > > So, my understanding is that TSM is not dependent on AAA, but=20 > > somewhere in the whole ISMS solution we will be dependent=20 > on AAA for=20 > > authorization, no? >=20 > My understanding is that a secure transport model _may_ call=20 > a AAA service for authentication (e.g. verification of a=20 > password) and a secure transport model _may_ (at the same=20 > time) call a AAA service for service authorization. The=20 > details may be transport model specific. > In essence, AAA says "go ahead" or "go way" when the secure=20 > session is being established. >=20 > As discussed in Prague, we believe that any further=20 > authorization via a AAA service (e.g. policy mapping in the=20 > form of securityName to groupName mapping) or even the=20 > provisioning of access control rules by a AAA server are=20 > outside of the current ISMS charter, but may be considered as=20 > future work items once we have successfully completed the=20 > work we are chartered to do. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 27 11:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhS7i-0000FJ-FL; Fri, 27 Apr 2007 11:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhS7g-0000FA-N1 for isms@ietf.org; Fri, 27 Apr 2007 11:12:36 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhS7e-0000GU-CA for isms@ietf.org; Fri, 27 Apr 2007 11:12:36 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007042715123301100fdm1te>; Fri, 27 Apr 2007 15:12:33 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><20070426162744.GB7092@elstar.local> Subject: RE: [Isms] working grouplastcallondraft-ietf-isms-transport-security-model-03 Date: Fri, 27 Apr 2007 11:12:27 -0400 Message-ID: <03ad01c788de$77c51370$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIH9qwKIiC5uajTce09der+ozCpwAffnbgAA+S7TA= X-Spam-Score: 1.1 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Errors-To: isms-bounces@lists.ietf.org Hi, Please note the conditional that starts that constraint: 2. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols). If we write a model that depends on third party services, either that model should have an explicit built-in failover strategy, or it should warn that the system MAY fail during times of network stress, preventing management access to the managed node. I will make a note to add such a warning to the secshell draft. I would like to have an explicit fallover to local passwords in the secshell draft, so I'll make a note to myself. When we start to discuss sechell issues, we should make sure that gets raised. If we want to try to standardize a local passwords authn model and then have various transport models that use third party authn servers failover consistently to that (or another model that can be specified specified by the failing authn model), we can do that too. It will add complexity, but also robustness. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Friday, April 27, 2007 3:39 AM > To: j.schoenwaelder@iu-bremen.de > Cc: isms@ietf.org > Subject: RE: [Isms] working > grouplastcallondraft-ietf-isms-transport-security-model-03 > > I agree with that. > But that means that such a security model IS (will be) dependent on a > 3rd party service. > And the comment I had is that the document seems to state > that we SHOULD > NOT depend > on other networkk services (point 2 in sect 1.5). > SO I can live if we remove that requirement, but we shouldbe honest in > advertising. > > Bert Wijnen > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Thursday, April 26, 2007 6:28 PM > > To: Wijnen, Bert (Bert) > > Cc: isms@ietf.org > > Subject: Re: [Isms] working group > > lastcallondraft-ietf-isms-transport-security-model-03 > > > > On Thu, Apr 26, 2007 at 04:55:03PM +0200, Wijnen, Bert (Bert) wrote: > > > > > So, my understanding is that TSM is not dependent on AAA, but > > > somewhere in the whole ISMS solution we will be dependent > > on AAA for > > > authorization, no? > > > > My understanding is that a secure transport model _may_ call > > a AAA service for authentication (e.g. verification of a > > password) and a secure transport model _may_ (at the same > > time) call a AAA service for service authorization. The > > details may be transport model specific. > > In essence, AAA says "go ahead" or "go way" when the secure > > session is being established. > > > > As discussed in Prague, we believe that any further > > authorization via a AAA service (e.g. policy mapping in the > > form of securityName to groupName mapping) or even the > > provisioning of access control rules by a AAA server are > > outside of the current ISMS charter, but may be considered as > > future work items once we have successfully completed the > > work we are chartered to do. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > Isms mailing list > Isms@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 Apr 27 13:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUAo-0000Wb-OA; Fri, 27 Apr 2007 13:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUAn-0000WV-Sd for isms@ietf.org; Fri, 27 Apr 2007 13:23:57 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUAl-0007Bc-UA for isms@ietf.org; Fri, 27 Apr 2007 13:23:57 -0400 Received: from pc6 (1Cust231.tnt13.lnd4.gbr.da.uu.net [62.188.142.231]) by ranger.systems.pipex.net (Postfix) with SMTP id 6C178E00028A; Fri, 27 Apr 2007 18:23:53 +0100 (BST) Message-ID: <05bc01c788e7$fe5a4460$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , , References: <20070420101206.GA11595@elstar.local> <013801c7873b$3f874b80$0601a8c0@pc6> <020a01c7875a$06daafb0$0600a8c0@china.huawei.com> Subject: Re: [Isms] prague meeting minutes Date: Fri, 27 Apr 2007 18:17:32 +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.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Errors-To: isms-bounces@lists.ietf.org Yes that is much clearer on SHOULD and MUST. From the minutes, or from the list discussion of the issue tmsm#1, I would not have known that this is what we agreed but I do concur with the agreement. (I hope that Wes does too, since it was he who made me aware of the significance of MUST). I agree too that when the application is able to choose the session. then it does so by transportAddress and securityName to which I would add, at least at the architectural level if not for all models, securityModel and securityLevel. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; ; Sent: Wednesday, April 25, 2007 6:51 PM Subject: RE: [Isms] prague meeting minutes > Hi, > > The minutes loook good. There are a couple corrections, and some > additonal explanation that might help others understand them better. > > In the minutes, it says "Dave went through the resolution of the > transport mapping model last call comments:" There is no "transport > mapping model" document; There is a Transport Subsystem, a Transport > Security Model, and an SSH Transport Model. The discussion at that > point in the presentation was about the Transport Subsystem document > last call. > > Issue#1: > > The Transport Subsystem architecture document will reflect the SNMPv3 > WG's decision that **architecturally** this is a SHOULD. > The decision is security-model-dependent, and the Transport Security > Model will make it a MUST. > > > The Transport Subsystem architecture document will avoid adding CLRs, > and continue to reflect the SNMPv3 WG's decision that > **architecturally** it is a SHOULD, because there may be future > extensions (e.g. new security models) where, for some acceptable > reason, it is not a security exposure and therefore not a MUST. We > should assume that designers of future security models will be just as > smart as we are, and given the technologies and best current practices > at that time, will make the right decisions for their security models. > > The WG reached consensus that this is a security issue; the security > models are the right place to address this issue. For USM and TSM, > this mismatch could be a security exposure, so they make #1 a MUST. In > TSM, the use of the same transport parameters is addressed in section > 4.2, bullet 1), where the transport parameters are extracted from the > securityStateReference. > > To resolve the interrelationship of #1 with #3, the unpublished > updated draft adds another parameter to the tmStateReference to tell > the transport model that this must be the same session that the > request came in on, not a new session identified by the same > parameters (transportdomain/address,securityname/level). > > > Issue #3: > > Only the transport model knows about transport sessions, and the > transport model does not know the content of the pdu, so it cannot > tell the difference between a request/response and a notification. > What the transport model can tell is what transport address and what > securityName it is told to send to (by the SNMP application). If the > **application** wants to use different sessions for different types of > pdus, then it can do so by using different transport addresses or > different securityNames. > > Part 3. > > There is a fourth option that isn't mentioned in the minutes - d) the > development of a new access control model. But development of a new > access control model is out of scope of the current charter. > > dbh > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 27 13:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUAq-0000XS-ED; Fri, 27 Apr 2007 13:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUAp-0000XK-0p for isms@ietf.org; Fri, 27 Apr 2007 13:23:59 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUAn-0007Cx-Fa for isms@ietf.org; Fri, 27 Apr 2007 13:23:59 -0400 Received: from pc6 (1Cust231.tnt13.lnd4.gbr.da.uu.net [62.188.142.231]) by ranger.systems.pipex.net (Postfix) with SMTP id 9841DE0003E9; Fri, 27 Apr 2007 18:23:55 +0100 (BST) Message-ID: <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6><00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Fri, 27 Apr 2007 18:19:29 +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.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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: , Errors-To: isms-bounces@lists.ietf.org Understand that an implementation can use any port it is configured with as long as its peer agrees. But I think that the text in tmsm 3.1.1 needs amplfying, ie where it says " To differentiate a session established for different purposes, such as a notification session versus a request-response session, an application can use different securityNames or transport addresses (e.g., port 161 vs. port 162)." add something like "Note that some transport models may be allocated a single well-known port for all sessions." (assuming we do not ask for two ports for SSH). I appreciate that the consensus on the list was reuse or not reuse was not an issue but I worry that we have this one wrong so want the documents to make this clear for any other reviewers. And, while suggesting revisions to tmsm, I wonder if the reference to RFC4366 should be to RFC4346 throughout. As far as I know, we are not using any TLS extensions. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" Cc: Sent: Wednesday, April 25, 2007 5:24 PM Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process > The SNMP applications (Commnd Requetser, Command Responder, et al) > specify the transport addresses, possibly based on pre-configured MIBs > or other administrative configuration. > > An NMS may allow an administrator to decide which ports, and some NMSs > may allow the ports for both types of traffic to be the same, others > may require separate ports. > > I expect that on the NMS side, a software application may force the > decision about whether RR runs on a separate transport from > notifications, because the software code that supports handling > asynchronous messages might be very different than the software code > for handling response/requests. I consider this fairly likely because > a) the processing required for event-driven management can be quite > different for polling-driven management, and b) SNMP has traditionally > used two ports to differentiate the different types of traffic, so > existing SNMP applications might find it easier to migrate to SSH-TM > using separate ports. > > The question we need to be conerned with is should we have IANA assign > one or more default ports for SSH-TM. It is my intention to ask for > one default port. > > The mention of 161 and 162 was only an example of how traffic can be > separated by port number; I was not recommending the use of 161 and > 162. > > I will try to make that clear in the SSH transport model. I will check > the TMSM to see if I need to clarify anything there. > > dbh > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, April 25, 2007 9:09 AM > > Cc: isms@ietf.org > > Subject: Re: TMSM and Port was Re: [Isms] Question regarding > > SNMPv3engine-iddiscovery process > > > > The impression I have is that for SNMP over SSH (and most > > likely for other such > > session transports) there will be but one port, for both > > Notifications and > > Requests. > > > > In which case, I think that TMSM s3.1.1 should mention this, that > the > > application can no longer use port 161 and 162 to > > differentiate the traffic; > > they will, perforce, share the session (assuming the other > > session selection > > parameters are the same). Unless the intention is for the > > application to still > > use 161 and 162 but for these to be translated somewhere in > > the ASIs to the SSH > > port; seema unlikely. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "tom.petch" > > Cc: > > Sent: Thursday, April 12, 2007 8:49 AM > > Subject: Re: TMSM and Port was Re: [Isms] Question regarding > > SNMPv3engine-id > > discovery process > > > > > > > On Wed, Apr 11, 2007 at 07:03:52PM +0200, tom.petch wrote: > > > > > > > From that, another query. What happens to port numbers > > with TMSM? At > > present, > > > > SNMP applications use 161 and 162 (mostly) which then > > becomes part of the > > key > > > > for selecting engineID. Will applications still use this > > at the ASI to the > > > > Dispatcher? If and when does this change to a secure > > transport port? > > > > > > We currently use a user supplied port number and we expect that a > > > default port number for a secure transport model will be > > allocated by > > > the secure transport model specification. In other words, > > this is part > > > of the SSH transport model specification to spell out (together > with > > > the proper TDomain definitions). > > > > > > Since we use TDomain/TAddress in the ASIs, nothing is going > > to change > > > about the ASIs and the internals of the Dispatcher as far as I can > > > tell. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen > > > P.O. Box 750 561, 28725 > > Bremen, Germany > > > > > > _______________________________________________ > > 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 Apr 27 14:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVLL-00055R-N6; Fri, 27 Apr 2007 14:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVLK-000530-7J for isms@ietf.org; Fri, 27 Apr 2007 14:38:54 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVLJ-0000Rq-U7 for isms@ietf.org; Fri, 27 Apr 2007 14:38:54 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <200704271838530120032q7me>; Fri, 27 Apr 2007 18:38:53 +0000 From: "David Harrington" To: "'tom.petch'" , , References: <20070420101206.GA11595@elstar.local> <013801c7873b$3f874b80$0601a8c0@pc6> <020a01c7875a$06daafb0$0600a8c0@china.huawei.com> <05bc01c788e7$fe5a4460$0601a8c0@pc6> Subject: RE: [Isms] prague meeting minutes Date: Fri, 27 Apr 2007 14:38:46 -0400 Message-ID: <03dd01c788fb$4a8e0a20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <05bc01c788e7$fe5a4460$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceI8NT5AmeM6KKbRVO66hnoXUhW1gACOgBA X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Errors-To: isms-bounces@lists.ietf.org Hi, The transport session is NOT specified by securityModel; the transport model does not know about securityModel. The securityModel value is meaningful in the messaging subsystem, the security subsystem, the AC subsystem, the application subsystem, and the dispatcher, but not in the transport subsystem. On an incoming message, the securityModel is not known until the MPM extracts it from the message; the tmStateReference cache prepared by the transport model does not contain the securityModel. On outgoing, the securityModel may be involved in choosing the transport model and transport address and the security model can set these variables from the securityStateReference, for use by the transport model, but the value of the securityModel variable is not used by the transport model. I used to think this was meaningful in transport as well, but realized it could not be, and removed references to it. If you spot a place in the drafts where securityModel is used in the transport model, please point that out to me so I can fix it. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, April 27, 2007 12:18 PM > To: David Harrington; j.schoenwaelder@iu-bremen.de; isms@ietf.org > Subject: Re: [Isms] prague meeting minutes > > Yes that is much clearer on SHOULD and MUST. From the > minutes, or from the list > discussion of the issue tmsm#1, I would not have known that > this is what we > agreed but I do concur with the agreement. (I hope that Wes > does too, since it > was he who made me aware of the significance of MUST). > > I agree too that when the application is able to choose the > session. then it > does so by transportAddress and securityName to which I would > add, at least at > the > architectural level if not for all models, securityModel and > securityLevel. > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: "'tom.petch'" ; > ; > > Sent: Wednesday, April 25, 2007 6:51 PM > Subject: RE: [Isms] prague meeting minutes > > > > Hi, > > > > The minutes loook good. There are a couple corrections, and some > > additonal explanation that might help others understand them better. > > > > In the minutes, it says "Dave went through the resolution of the > > transport mapping model last call comments:" There is no "transport > > mapping model" document; There is a Transport Subsystem, a Transport > > Security Model, and an SSH Transport Model. The discussion at that > > point in the presentation was about the Transport Subsystem document > > last call. > > > > Issue#1: > > > > The Transport Subsystem architecture document will reflect > the SNMPv3 > > WG's decision that **architecturally** this is a SHOULD. > > The decision is security-model-dependent, and the Transport Security > > Model will make it a MUST. > > > > > > The Transport Subsystem architecture document will avoid > adding CLRs, > > and continue to reflect the SNMPv3 WG's decision that > > **architecturally** it is a SHOULD, because there may be future > > extensions (e.g. new security models) where, for some acceptable > > reason, it is not a security exposure and therefore not a MUST. We > > should assume that designers of future security models will > be just as > > smart as we are, and given the technologies and best > current practices > > at that time, will make the right decisions for their > security models. > > > > The WG reached consensus that this is a security issue; the security > > models are the right place to address this issue. For USM and TSM, > > this mismatch could be a security exposure, so they make #1 > a MUST. In > > TSM, the use of the same transport parameters is addressed > in section > > 4.2, bullet 1), where the transport parameters are > extracted from the > > securityStateReference. > > > > To resolve the interrelationship of #1 with #3, the unpublished > > updated draft adds another parameter to the tmStateReference to tell > > the transport model that this must be the same session that the > > request came in on, not a new session identified by the same > > parameters (transportdomain/address,securityname/level). > > > > > > Issue #3: > > > > Only the transport model knows about transport sessions, and the > > transport model does not know the content of the pdu, so it cannot > > tell the difference between a request/response and a notification. > > What the transport model can tell is what transport address and what > > securityName it is told to send to (by the SNMP application). If the > > **application** wants to use different sessions for > different types of > > pdus, then it can do so by using different transport addresses or > > different securityNames. > > > > Part 3. > > > > There is a fourth option that isn't mentioned in the > minutes - d) the > > development of a new access control model. But development of a new > > access control model is out of scope of the current charter. > > > > dbh > > > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Apr 27 22:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcFI-00087o-Ry; Fri, 27 Apr 2007 22:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcFH-00087e-8H for isms@ietf.org; Fri, 27 Apr 2007 22:01:07 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhcFG-0006zf-01 for isms@ietf.org; Fri, 27 Apr 2007 22:01:07 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007042802010501400249pee>; Sat, 28 Apr 2007 02:01:05 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Juergen Quittek'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Fri, 27 Apr 2007 22:00:57 -0400 Message-ID: <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUAATL4U4ABBYdSA X-Spam-Score: 1.1 (+) 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: , Errors-To: isms-bounces@lists.ietf.org Hi, > > > If somebody wants to use SSH-TM to transport SNMPv1/v2c > > messages, they can but they will not get TSM as the security > > model because SNMPv1/2c messages use the Community-based > > security model(s), per RFC3584. > > So that could be an easy update to RFC3584, I guess, and then > we could let those messages be handled by the TSM, no? > > In any event, such could be done, And so I think it would be better > to not speak about a specific SNMP version in the TSM. Proposed text in section 2.3: "Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or SNMPv2 Message Processing Models **as defined in RFC3584** cannot use the Transport Security Model. (This does not mean an SNMPv1 or SNMPv2 message cannot use a secure transport model, only that the RFC3584 MPM will not invoke this security model.)" This leaves the path open to a 3584bis, but makes it clear that the current rfc3584 will not use this security model. I removed all reference to message-version-specific processing. Now the only place message versions are mentioned is in co-existence and the security considerations. > > > > > > But I see that in sect 5.2 step 2) you seem not to want to be so > liberal. > > > Do we really want to generate an error if someone has put some > data into > > > the msgSecurityParameters? > > > > As protection against viruses, yes. > > > > Mmmm.. not sure I agree. > If I am the only one... pls ignore me (on this point). I'll let the chairs determine consensus on this. > > > > > > > > > > - In sect 3.2.1, I am not sure that the 2nd para belongs here? [...] > > However, the security model does not know whether the > > transport connection has been closed (only the transport > > model knows this), and if the connection no longer exists > > when the message reaches the transport model, then the > > Response message MAY be discarded. > > > Yeah... but why do we need to say that in TSM ?? I removed the warning. > - In non-USM securityModels, no matter what, just always set > securityEngineID to the local snmpEngineID. It won't hurt (I think). I modified the EOP for THIS security model to always set it to the local engineID. > > > > > > - I wonder if we need something like unknown userNames ?? > > > > InvalidCache provides this for incoming messages (The > > transport model has not told us what securityName to use.) > > > > So invalidCache is overloaded with multiple meanings? > Does not sound good to me. It is not really overloading the meaning; how you interpret things is different for this security model than for USM. To know when a username is unknown, you need a list of the known usernames. USM is preconfigured with a list of known usernames; TSM does not have preconfigured usernames, so all usernames are unknown. For outgoing messages, the application provides a securityName (via the ASI or securityStateReference), and TSM puts it into the tmStateReference cache. I will note that we do not verify it is not empty. For incoming messages, if the transport model provided a securityName in the cache, then the securityName is known; if not, then the securityName is unknown. The security subsystem is responsible for providing the securityName for the rest of the system, and this security model sets securityName based on the securityName value in the cache (5.2 step 4), so a missing cache or a cache with no securityName value is invalid as far as this security model is concerned, so it reports this problem in InvalidCache. Note that we do not check that the value of securityName is valid, only that the cache exists and has a securityName field. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Apr 28 06:19:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhk1Q-0007lT-UE; Sat, 28 Apr 2007 06:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhk1P-0007lN-LX for isms@ietf.org; Sat, 28 Apr 2007 06:19:19 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhk1O-0008U3-91 for isms@ietf.org; Sat, 28 Apr 2007 06:19:19 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l3SAIw1L009658; Sat, 28 Apr 2007 05:18:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 05:18:58 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 12:18:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Sat, 28 Apr 2007 12:17:30 +0200 Message-ID: In-Reply-To: <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUAATL4U4ABBYdSAABqemMA= References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Juergen Quittek" , X-OriginalArrivalTime: 28 Apr 2007 10:18:55.0820 (UTC) FILETIME=[A0B130C0:01C7897E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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: , Errors-To: isms-bounces@lists.ietf.org Inline Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Saturday, April 28, 2007 4:01 AM > To: Wijnen, Bert (Bert); 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] working group last=20 > callondraft-ietf-isms-transport-security-model-03 >=20 > Hi, >=20 > >=20 > > > If somebody wants to use SSH-TM to transport SNMPv1/v2c messages,=20 > > > they can but they will not get TSM as the security model because=20 > > > SNMPv1/2c messages use the Community-based security model(s), per=20 > > > RFC3584. > >=20 > > So that could be an easy update to RFC3584, I guess, and=20 > then we could=20 > > let those messages be handled by the TSM, no? > >=20 > > In any event, such could be done, And so I think it would=20 > be better to=20 > > not speak about a specific SNMP version in the TSM. >=20 > Proposed text in section 2.3: > "Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or > SNMPv2 Message Processing Models **as defined in RFC3584**=20 > cannot use the Transport Security Model. (This does not mean=20 > an SNMPv1 or SNMPv2 message cannot use a secure transport=20 > model, only that the RFC3584 MPM will not invoke this=20 > security model.)" >=20 > This leaves the path open to a 3584bis, but makes it clear=20 > that the current rfc3584 will not use this security model. >=20 I guess I can live with it. But I would remove it completely. We do not have to specify what sorts of other (external) things can or cannot work with us. We have defined our ASI, and that=20 should make it clear. > I removed all reference to message-version-specific=20 > processing. Now the only place message versions are mentioned=20 > is in co-existence and the security considerations.=20 >=20 ?? not needed in co-existence in my view. But I will turn quiet if everyone else is OK with above text. No firther response to thr eest below. Bert > > > >=20 > > > > But I see that in sect 5.2 step 2) you seem not to want to be > so > > liberal. > > > > Do we really want to generate an error if someone has put some > > data into > > > > the msgSecurityParameters? > > >=20 > > > As protection against viruses, yes. > > >=20 > >=20 > > Mmmm.. not sure I agree.=20 > > If I am the only one... pls ignore me (on this point). >=20 > I'll let the chairs determine consensus on this. >=20 > >=20 > > > >=20 > > > >=20 > > > > - In sect 3.2.1, I am not sure that the 2nd para belongs here? > [...]=20 > > > However, the security model does not know whether the transport=20 > > > connection has been closed (only the transport model knows this),=20 > > > and if the connection no longer exists when the message=20 > reaches the=20 > > > transport model, then the Response message MAY be discarded. > > >=20 > > Yeah... but why do we need to say that in TSM ?? >=20 > I removed the warning. >=20 > > - In non-USM securityModels, no matter what, just always set=20 > > securityEngineID to the local snmpEngineID. It won't hurt (I > think). >=20 > I modified the EOP for THIS security model to always set it=20 > to the local engineID.=20 >=20 > > > > =20 > > > > - I wonder if we need something like unknown userNames ?? > > >=20 > > > InvalidCache provides this for incoming messages (The transport=20 > > > model has not told us what securityName to use.) > > >=20 > >=20 > > So invalidCache is overloaded with multiple meanings? > > Does not sound good to me. >=20 > It is not really overloading the meaning; how you interpret=20 > things is different for this security model than for USM. >=20 > To know when a username is unknown, you need a list of the=20 > known usernames. USM is preconfigured with a list of known=20 > usernames; TSM does not have preconfigured usernames, so all=20 > usernames are unknown.=20 >=20 > For outgoing messages, the application provides a=20 > securityName (via the ASI or securityStateReference), and TSM=20 > puts it into the tmStateReference cache. I will note that we=20 > do not verify it is not empty. >=20 > For incoming messages, if the transport model provided a=20 > securityName in the cache, then the securityName is known; if=20 > not, then the securityName is unknown. >=20 > The security subsystem is responsible for providing the=20 > securityName for the rest of the system, and this security=20 > model sets securityName based on the securityName value in=20 > the cache (5.2 step 4), so a missing cache or a cache with no=20 > securityName value is invalid as far as this security model=20 > is concerned, so it reports this problem in InvalidCache.=20 > Note that we do not check that the value of securityName is=20 > valid, only that the cache exists and has a securityName field. >=20 > dbh >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Apr 28 09:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhmoT-0001Fu-7z; Sat, 28 Apr 2007 09:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhmoR-0001Fn-Ps for isms@ietf.org; Sat, 28 Apr 2007 09:18:07 -0400 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhmoR-0006p4-G8 for isms@ietf.org; Sat, 28 Apr 2007 09:18:07 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <20070428131807015008kihbe>; Sat, 28 Apr 2007 13:18:07 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Juergen Quittek'" , References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Sat, 28 Apr 2007 09:17:55 -0400 Message-ID: <048001c78997$a4c995d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdioPSTqZ700mf4QjiyaEeiXkzUIQi6/pJAAFOPxUAATL4U4ABBYdSAABqemMAABcBAoA== X-Spam-Score: 1.1 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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: , Errors-To: isms-bounces@lists.ietf.org Hi, My own experience, and previous discussions on this mailing list, make it quite obvious that 1) people would **like** to see TSM work with SNMPv1 and SNMPv2c, and 2) people **expect** that TSM will just work with SNMPv1 and SNMPv2c, and 3) people are **surprised** to learn that, because of RFC3584, it does not. I think I have a pretty good understanding of the RFC3411 architecture and the way RFC3412 dispatching works, but I was surprised TSM would not work with SNMPv1 and SNMPv2c. Even if the ISMS WG takes on the task of rewriting RFC3584, 3) would not go away if the implementation used is not upgraded to RFC3584bis. I think it reasonable to keep the explanation in the Co-existence section of TSM, so people understand why 2) doesn't just happen. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Saturday, April 28, 2007 6:18 AM > To: David Harrington; Juergen Quittek; isms@ietf.org > Subject: RE: [Isms] working group last > callondraft-ietf-isms-transport-security-model-03 > > Inline > > Bert Wijnen > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Saturday, April 28, 2007 4:01 AM > > To: Wijnen, Bert (Bert); 'Juergen Quittek'; isms@ietf.org > > Subject: RE: [Isms] working group last > > callondraft-ietf-isms-transport-security-model-03 > > > > Hi, > > > > > > > > > If somebody wants to use SSH-TM to transport SNMPv1/v2c > messages, > > > > they can but they will not get TSM as the security > model because > > > > SNMPv1/2c messages use the Community-based security > model(s), per > > > > RFC3584. > > > > > > So that could be an easy update to RFC3584, I guess, and > > then we could > > > let those messages be handled by the TSM, no? > > > > > > In any event, such could be done, And so I think it would > > be better to > > > not speak about a specific SNMP version in the TSM. > > > > Proposed text in section 2.3: > > "Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or > > SNMPv2 Message Processing Models **as defined in RFC3584** > > cannot use the Transport Security Model. (This does not mean > > an SNMPv1 or SNMPv2 message cannot use a secure transport > > model, only that the RFC3584 MPM will not invoke this > > security model.)" > > > > This leaves the path open to a 3584bis, but makes it clear > > that the current rfc3584 will not use this security model. > > > I guess I can live with it. > But I would remove it completely. > We do not have to specify what sorts of other (external) things > can or cannot work with us. We have defined our ASI, and that > should make it clear. > > > I removed all reference to message-version-specific > > processing. Now the only place message versions are mentioned > > is in co-existence and the security considerations. > > > ?? not needed in co-existence in my view. > But I will turn quiet if everyone else is OK with above text. > > No firther response to thr eest below. > Bert > > > > > > > > > > But I see that in sect 5.2 step 2) you seem not to > want to be > > so > > > liberal. > > > > > Do we really want to generate an error if someone > has put some > > > data into > > > > > the msgSecurityParameters? > > > > > > > > As protection against viruses, yes. > > > > > > > > > > Mmmm.. not sure I agree. > > > If I am the only one... pls ignore me (on this point). > > > > I'll let the chairs determine consensus on this. > > > > > > > > > > > > > > > > > > > > - In sect 3.2.1, I am not sure that the 2nd para belongs here? > > [...] > > > > However, the security model does not know whether the transport > > > > connection has been closed (only the transport model > knows this), > > > > and if the connection no longer exists when the message > > reaches the > > > > transport model, then the Response message MAY be discarded. > > > > > > > Yeah... but why do we need to say that in TSM ?? > > > > I removed the warning. > > > > > - In non-USM securityModels, no matter what, just always set > > > securityEngineID to the local snmpEngineID. It won't hurt (I > > think). > > > > I modified the EOP for THIS security model to always set it > > to the local engineID. > > > > > > > > > > > > - I wonder if we need something like unknown userNames ?? > > > > > > > > InvalidCache provides this for incoming messages (The transport > > > > model has not told us what securityName to use.) > > > > > > > > > > So invalidCache is overloaded with multiple meanings? > > > Does not sound good to me. > > > > It is not really overloading the meaning; how you interpret > > things is different for this security model than for USM. > > > > To know when a username is unknown, you need a list of the > > known usernames. USM is preconfigured with a list of known > > usernames; TSM does not have preconfigured usernames, so all > > usernames are unknown. > > > > For outgoing messages, the application provides a > > securityName (via the ASI or securityStateReference), and TSM > > puts it into the tmStateReference cache. I will note that we > > do not verify it is not empty. > > > > For incoming messages, if the transport model provided a > > securityName in the cache, then the securityName is known; if > > not, then the securityName is unknown. > > > > The security subsystem is responsible for providing the > > securityName for the rest of the system, and this security > > model sets securityName based on the securityName value in > > the cache (5.2 step 4), so a missing cache or a cache with no > > securityName value is invalid as far as this security model > > is concerned, so it reports this problem in InvalidCache. > > Note that we do not check that the value of securityName is > > valid, only that the cache exists and has a securityName field. > > > > dbh > > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Apr 30 06:26:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiT5e-0000yD-7E; Mon, 30 Apr 2007 06:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiT5d-0000y8-9q for isms@ietf.org; Mon, 30 Apr 2007 06:26:41 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiT5a-0001n5-W2 for isms@ietf.org; Mon, 30 Apr 2007 06:26:41 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EA05B76751; Mon, 30 Apr 2007 12:26:37 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24438-07; Mon, 30 Apr 2007 12:26:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 772B176555; Mon, 30 Apr 2007 12:26:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 18EC023E6DF; Mon, 30 Apr 2007 12:26:33 +0200 (CEST) Date: Mon, 30 Apr 2007 12:26:33 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] working grouplastcallondraft-ietf-isms-transport-security-model-03 Message-ID: <20070430102633.GA2272@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , isms@ietf.org References: <03ad01c788de$77c51370$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03ad01c788de$77c51370$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.2 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: isms-bounces@lists.ietf.org On Fri, Apr 27, 2007 at 11:12:27AM -0400, David Harrington wrote: > I would like to have an explicit fallover to local passwords in the > secshell draft, so I'll make a note to myself. When we start to > discuss sechell issues, we should make sure that gets raised. In practical PAM implementation terms, the failover strategy is determined by the PAM configuration. Requiring a failover to local passwords simply means that some legal PAM configurations may break RFC compliance. So I would prefer that the applicability section discusses this point and suggests failover to local passwords rather than requiring it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Apr 30 06:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTME-0000w0-BX; Mon, 30 Apr 2007 06:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTMD-0000vv-1p for isms@ietf.org; Mon, 30 Apr 2007 06:43:49 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiTMB-0005fM-KL for isms@ietf.org; Mon, 30 Apr 2007 06:43:49 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 257CB71BAD; Mon, 30 Apr 2007 12:43:47 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25742-09; Mon, 30 Apr 2007 12:43:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9F9AC6DD9B; Mon, 30 Apr 2007 12:43:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D03D23E782; Mon, 30 Apr 2007 12:43:42 +0200 (CEST) Date: Mon, 30 Apr 2007 12:43:42 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Message-ID: <20070430104342.GB2272@elstar.local> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , 'Juergen Quittek' , isms@ietf.org References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com> <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.2 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: isms-bounces@lists.ietf.org On Fri, Apr 27, 2007 at 10:00:57PM -0400, David Harrington wrote: BW> Do we really want to generate an error if someone has put some BW> data into the msgSecurityParameters? DH> As protection against viruses, yes. BW> Mmmm.. not sure I agree. BW> If I am the only one... pls ignore me (on this point). DH> I'll let the chairs determine consensus on this. Since it is difficult to determine concensus with just two opinions, I like to ask people to comment on this. The question is: Shall a parser simply ignore the content of msgSecurityParameters or shall it raise an error? The be liberal in what you accept rule would call for simply ignoring the value (Bert Wijnen's position) while Dave Harrington is concerned that implementations may do arbitrary non-sense with the data. Please let me know your opinion. /js As a technical contributor, I would prefer to simply ignore msgSecurityParameters (like I ignore other fields in SNMP messages that are of no use, e.g., values in get class operations). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Apr 30 14:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaBd-0007rk-EQ; Mon, 30 Apr 2007 14:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaBc-0007rX-JY for isms@ietf.org; Mon, 30 Apr 2007 14:01:20 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiaBZ-0000Y2-6k for isms@ietf.org; Mon, 30 Apr 2007 14:01:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 8A0DD1E135B; Mon, 30 Apr 2007 11:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at sharplabs.com Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCmcuRosUoHs; Mon, 30 Apr 2007 11:01:11 -0700 (PDT) Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8]) by mail2.sharplabs.com (Postfix) with ESMTP id 3EA011E1322; Mon, 30 Apr 2007 11:01:11 -0700 (PDT) Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:01:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 Date: Mon, 30 Apr 2007 11:01:10 -0700 Message-ID: In-Reply-To: <20070430102633.GA2272@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 Thread-Index: AceLEhV//jQgHCjgTWCmcNZKUzFzqAAR1rxw From: "McDonald, Ira" To: , "David Harrington" X-OriginalArrivalTime: 30 Apr 2007 18:01:10.0808 (UTC) FILETIME=[88DC0180:01C78B51] X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: isms-bounces@lists.ietf.org Hi, To allow failover to something other than local passwords based on configured policy to be RFC-conformant, but still maximize interoperability, how about adding a SHOULD (rather than a MUST) for failover to local passwords (that explains how it might be at variance with a legitimate local policy)? Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG 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: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, April 30, 2007 5:27 AM To: David Harrington Cc: isms@ietf.org Subject: Re: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 On Fri, Apr 27, 2007 at 11:12:27AM -0400, David Harrington wrote: > I would like to have an explicit fallover to local passwords in the > secshell draft, so I'll make a note to myself. When we start to > discuss sechell issues, we should make sure that gets raised.=20 In practical PAM implementation terms, the failover strategy is determined by the PAM configuration. Requiring a failover to local passwords simply means that some legal PAM configurations may break RFC compliance. So I would prefer that the applicability section discusses this point and suggests failover to local passwords rather than requiring it. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 = 9:14 AM =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Apr 30 14:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaUb-00034g-B9; Mon, 30 Apr 2007 14:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaUZ-00034a-6x for isms@ietf.org; Mon, 30 Apr 2007 14:20:55 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiaUX-0004Fj-QO for isms@ietf.org; Mon, 30 Apr 2007 14:20:55 -0400 Received: from pc6 (1Cust133.tnt29.lnd3.gbr.da.uu.net [62.188.120.133]) by galaxy.systems.pipex.net (Postfix) with SMTP id 1427CE00040A; Mon, 30 Apr 2007 19:20:47 +0100 (BST) Message-ID: <01b501c78b4b$70a02520$0601a8c0@pc6> From: "tom.petch" To: , "David Harrington" References: <01e101c78703$a24326f0$0600a8c0@china.huawei.com><046d01c78939$0fdcd3a0$0600a8c0@china.huawei.com> <20070430104342.GB2272@elstar.local> Subject: Re: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 Date: Mon, 30 Apr 2007 17:53:18 +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.1 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: isms-bounces@lists.ietf.org ---- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: Sent: Monday, April 30, 2007 12:43 PM Subject: Re: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03 > On Fri, Apr 27, 2007 at 10:00:57PM -0400, David Harrington wrote: > > BW> Do we really want to generate an error if someone has put some > BW> data into the msgSecurityParameters? > > DH> As protection against viruses, yes. > > BW> Mmmm.. not sure I agree. > BW> If I am the only one... pls ignore me (on this point). > > DH> I'll let the chairs determine consensus on this. > > Since it is difficult to determine concensus with just two opinions, I > like to ask people to comment on this. The question is: > > Shall a parser simply ignore the content of msgSecurityParameters > or shall it raise an error? > Raise an error. As I said before, I think it shows significant mismatch between sender and receiver and so should have attention drawn to it. This is security we are talking about. Tom Petch > The be liberal in what you accept rule would call for simply ignoring > the value (Bert Wijnen's position) while Dave Harrington is concerned > that implementations may do arbitrary non-sense with the data. Please > let me know your opinion. > > /js > > As a technical contributor, I would prefer to simply ignore > msgSecurityParameters (like I ignore other fields in SNMP messages > that are of no use, e.g., values in get class operations). > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@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 Apr 30 15:36:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibfU-0004kV-Na; Mon, 30 Apr 2007 15:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibfU-0004kL-3U for isms@ietf.org; Mon, 30 Apr 2007 15:36:16 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HibfS-0001M7-Pm for isms@ietf.org; Mon, 30 Apr 2007 15:36:16 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E54956DD4C; Mon, 30 Apr 2007 21:36:13 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12349-10; Mon, 30 Apr 2007 21:36:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 376B26DA24; Mon, 30 Apr 2007 21:36:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44D0E23F06F; Mon, 30 Apr 2007 21:36:06 +0200 (CEST) Date: Mon, 30 Apr 2007 21:36:06 +0200 From: Juergen Schoenwaelder To: "McDonald, Ira" Subject: Re: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03 Message-ID: <20070430193606.GB3148@elstar.local> Mail-Followup-To: "McDonald, Ira" , David Harrington , isms@ietf.org References: <20070430102633.GA2272@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.2 (+) 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: , Errors-To: isms-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 11:01:10AM -0700, McDonald, Ira wrote: > To allow failover to something other than local passwords > based on configured policy to be RFC-conformant, but still > maximize interoperability, how about adding a SHOULD (rather > than a MUST) for failover to local passwords (that explains > how it might be at variance with a legitimate local policy)? Why should we standardize local policy? A fallback mechanism to local passwords might even be a security nightmare if those local passwords never get changed. I am find to discuss fallback mechanisms and the pros and cons of them but I somehow feel SHOULD or MUST language may go a bit to far. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms