From isms-bounces@lists.ietf.org Sat Nov 04 19:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVbr-0004Er-CS; Sat, 04 Nov 2006 19:11:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVbq-0004Ee-3b for isms@ietf.org; Sat, 04 Nov 2006 19:11:34 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgVbn-00030R-DC for isms@ietf.org; Sat, 04 Nov 2006 19:11:34 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DE0A05AC3C for ; Sun, 5 Nov 2006 01:11:15 +0100 (CET) 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 11466-03; Sun, 5 Nov 2006 01:11:12 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 2D10256217; Sun, 5 Nov 2006 01:11:12 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 1380D8BCC88; Sun, 5 Nov 2006 01:11:09 +0100 (CET) Date: Sun, 5 Nov 2006 01:11:09 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20061105001109.GA27351@boskop.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.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Subject: [Isms] review of draft-ietf-isms-transport-security-model-00.txt 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 I have reviewed and below are my comments (as a technical contributor). /js 01: Page 5: "self- contained" -> "self-contained" 02: Page 5: "User Security Model" -> "User-based Security Model" 03: Page 6: [todo]: I think this [todo] can simply be removed. 04: Page 7: ", s the" -> ", as the" 05: Page 8: "secruity" -> "security" 06: Page 8: I am not sure how useful it will ever be to run USM over SSH (second bullet). If we like to discuss such cases, it might be worth to note, however, that in such a configuration the securityName would be derived from the USM userName and the securityName provided by the secure Transport Model would be ignored. 07: Page 8/9: [discuss] I do not think that the secure transport model must determine the security model. I do not think we want this binding and "overwrite" the msgSecurityModel field in the SNMPv3 message. However, the transport security model must check that the transport actually did provide an appropriate tmStateReference and drop any messages where this is not the case (so that plain SNMP over TCP messages do not go pass the transport security model). 07: Page 8: The more interesting case in term of coexistance that IMHO should be mentioned in section 2.3. is the combination of a secure transport model with a community-based security model [RFC 3584]. It should be made clear that in this combination you won't get an authenticated securityName since the community-based security model derives the securityName from the community string which is not authenticated. 08: Page 9: "WholeMsg" -> "wholeMsg" 09: Page 10: It should probably be noted somewhere that the fact that there is only a single Transport Security Model for potentially many secure transports implies that you cannot have different access control rules for say SNMPv3/TMS/SSH and SNMPv3/TMS/TLS since the isAccessAllowed primitive only takes the securityModel as input but not the transport model. I am not saying this is a problem - just that we should be clear about this. 10: Page 11: "how Transport" -> "how the Transport" 11: Page 12: ". if the" -> ". If the" 12: Page 13, section 3.1.3: Why do we not simply state that the msgSecurityParameters are a zero-length OCTET STRING? Section 6.6 of RFC 3412 states that this field is opaque from the message processor's point of view and just passed to the security model. Since the Transport Security Model does not have any data to put there, we should IMHO just set this field to a zero-length OCTET STRING. Defining and ASN.1 SEQUENCE which contains a zero-length OCTET STRING and serializing this using BER and putting the result (0x10020400) there does not really add any value. 13: Page 14: "to imatch" -> "to match" 14: Page 15: I do not understand the text about the LCD, the MIB module and lookups. In fact, I do not see why there is a MIB with a user table in the first place (see below). I believe this text is not needed an can be discarded. 15: Page 16: Is the discussion of the prepareOutgoingMessage() ASI needed? This seems to be unchanged from RFC 3411. 16: Page 17: The text states that the Transport Subsystem architectural extension did add parameters to the generateRequestMsg() and generateResponseMsg() ASIs. I checked the ID and could not find this. So this needs to be added to the architectural extension document together with a discussion why the new parameters are needed. The community-based security model has the capability to filter messages based on the IP addresses. It seems this never really worked according to the architecture because the ASIs never passed the transport address to the security model. So it seems that this work actually makes the community-based security fit into the architecture. ;-) 17: Page 18: It would be nice if the elements of procedure could actually be highlighted by putting them into a subsubsection. 18: Page 18: "Subystem" -> "Subsystem" 19: Page 19: Item 4): Fill the securityParameters with a zero-length OCTET STRING (see 12 above). 20: Page 19: It seem subsection 4.3 is empty. 21: Page 19: The subsection structure is confusing. It seems that the section header "4.4. Prepare ..." should be dropped in order to be consistent. 22: Page 20: "is::" -> "is:" 23: Page 20: It would be nice if the elements of procedure could actually be highlighted by putting them into a subsubsection. 24: Page 20: Replace 1) If the received securityParameters is not the serialization of an OCTET STRING formatted according to the transportSecurityParameters, and the contained OCTET STRING is not empty, then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. with: 1) If the received securityParameters is not a zero length string, then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. (according to 12 above). 25: Page 20: I do not understand step 2). If you want to check that the security level reported via the tmStateReference is at least as good as the securityLevel indicated in the message, just do it and discard the packet otherwise. I do not understand the text about securityModel and securityName. SecurityName is an OUT parameter and the securityModel was used to call us; was your idea to check for "surprising" combinations of security models with transport models? I believe we should not do this. 26: Page 20: Before step 3) (mistakenly called 2) again), we have to make sure a valid tmStateReference has been provided. If it is missing (e.g. the packet was received via a plain TCP/UDP transport), then we should discard the packet and increment a suitable counter. 27: Page 21: The transportStats subtree is empty - drop 5.3. The transportState subtree is empty - drop 5.4. 28: Page 22: Transport-Subsystem-MIB will be renamed - updated needed here to be consistent. 29: Page 22: The name of the MIB module should be changed to SNMP-TRANSPORT-SM-MIB to be consistend with other SNMPv3 specifications and I suggest to register the module below snmpModules. 30: Page 22-27: Almost all definitions should be removed since they are not needed. What is missing are two counters: one for messages dropped due to the security level in the message being inconsistent with the security level provided by the transport (step 2) in the elements of procedure for incoming messages) and one counter for messages dropped due to a missing tmStateReference. 31: Page 28: The MIB boilerplate security text needs to be updated. 32: Page 29: IANA considerations must be updated if we register under snmpModules. 33: Page 30: I believe reference [RFC3419] is not needed. 34: Appendix A: Some of the tags need to be updated. If we drop the user table in the MIB module, we can also drop section A.1. Section A.2 depends on the SSH transport model which I think we should avoid. It might make more sense to let the SSH transport model depend on the Tranport Security Model and to move the notification example to the SSH document. (We should definately keep the example since this is useful.) -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Nov 04 19:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVd9-0004Y4-NA; Sat, 04 Nov 2006 19:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVd8-0004Xz-5e for isms@ietf.org; Sat, 04 Nov 2006 19:12:54 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgVd6-0003FA-Hl for isms@ietf.org; Sat, 04 Nov 2006 19:12:54 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 25EAC5ACCE for ; Sun, 5 Nov 2006 01:12:52 +0100 (CET) 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 11465-05; Sun, 5 Nov 2006 01:12:49 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id BCC0456217; Sun, 5 Nov 2006 01:12:48 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id F31CF8BCCAC; Sun, 5 Nov 2006 01:12:46 +0100 (CET) Date: Sun, 5 Nov 2006 01:12:46 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20061105001246.GB27351@boskop.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.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Isms] review of draft-ietf-isms-tmsm-04.txt 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 I have reviewed and here are my comments (as a technical contributor). Even though I have written down quite some comments, I believe this document is in a rather good shape and I would encourage especially SNMP people to look at it. /js 01: Should the document status not be standards track? Note that RFC 3411 is also standards track. 02: On page 5, should we mention SHA instead of MD5 or more generally talk about hash and encryption functions? 03: Page 6, last paragraph states that every proposed transport model "includes a discussion of the applicability statement of the protocols to be used". Do you really mean a discussion of the applicability statement? Or do we mean that every proposed transport model "includes an applicability statement which discusses the security protocols to be used." Note that the current ISMS charter kind of suggests a separate document for the applicability statement. I personally would prefer to inline these applicability statements into the various secure transports as page 6 seems to suggest. 04: Page 8 says that the ASIs utilize TransportType and TransportAddress. I believe we have to stick to TDomain and TAddress in the SNMP MIB space and transportDomain and transportAddress in the ASI space. (Requires edits in all three documents in various places). 05: Page 10: In the box representing the Dispatcher, I would add "Transport Dispatcher" at the top (similar to Message Dispatcher and PDU Dispatcher). 06: Page 12: Add vertical bars to the SNMP messaging box and fix the alignment of the arrow between the transport layer and the SNMP engine box. 07: Page 12: The following sentence is a bit confusing (and ends with a comma): If a message is secured using non-SNMP-specific message security and parameters, then the transport model should provide the translation from e.g., an SSH user name to the securityName in step 3, Step 3 is marked as (messaging model). Perhaps a better phrasing is: If a message is secured using non-SNMP-specific message security and parameters, then the transport model should provide the translation from e.g., an SSH user name to the securityName messaging model in step 3. 08: Page 12 and page 13: I find the two figures pretty different; on page 13 you indicate a security model while on page 12 you indicate only a box with "decryption + translation". Is it needed to have these figures at all or is it possible to explain the difference between message based security and transport model security not be refering to the boxes in the figure on page 10? 09: Page 14 has a duplicate dot in 2.2.2.1. 10: Page 17: I do not understand the [todo:] 11: Page 17: Rewording of the old text: Throughout this document, the term session is used. Some underlying secure transports will have a notion of session. Some underlying secure transports might enable the use of channels or other session- like thing. New text: Some secure transports may have a notion of sessions while other secure transports might provide channels or other session-like things. Throughout this document, the term session is used in a broad sense to cover sessions, channels, and session-like things. 12: Page 18: My answer to the [discuss] is no. The transport model should not have insight into the security model. 13: Page 19: I suggest that we leave it to the transport to define what happens if the session disappears while a response is being prepared and close the discuss. 14: Page 20: ransport -> transport 15: Page 20: End of 5th paragraph: Should we not state explicitely that the actual security level can be upgraded by a secure transport, i.e. that noAuth/noPriv and auth/noPriv can be sent over an authenticated and encrypted session? 16: Page 21: Regarding the [discuss]: I would be in favor of dropping any discussions about speculative features of transports yet to be invented. 17: Page 25: "contrain" -> "constrain" 18: Page 25: Concerning the [todo]: I think it OK to keep the ASIs since they were actually changed. 19: Page 26: Add a comment to tmStateReference in the ASI and mark it as (NEW) so that it becomes obvious what has changed. 20: Page 26: "for the application" -> "from the application" 21: Page 27: Add a comment for the tmStateReference in the ASIs. 22: Page 27: The openSession() and closeSession() ASIs are actually never invoked by the dispatcher and hence they do not need to be visible in the architecture; they could be purely local to the transport models. On the other hand, I agree that several transports will have similar internal openSession() and closeSession() interfaces. Perhaps the text should make it clear that these ASIs are really "helper" ASIs for session based transports and not needed as interfaces between subsystems (which normally ASIs are used for). Or we might want to simply remove them and introduce them in the transport models that need them. 23: Page 28: Add a comment for the tmStateReference in the ASIs. 24: Page 29: Align the tmStateReference comment and mark it as (NEW). 25: Page 29: Remove duplicate colon. 26: Page 30: Align the tmStateReference comment and mark it as (NEW). 27: Page 30: "5)The" -> "5) The" 28: Page 31: There is no use of tmsmStats so the definition should be removed and section 6.1.1 can be discarded. 29: Page 31: The name of the MIB module should be changed; all SNMP core module names start with SNMP- and so I suggest to call it SNMP-TRANSPORT-MIB. 30: Page 32: The imports need to be cleaned up and unsued stuff removed. 31: Page 33: The comment of the REVISION is wrong. I sugges to simply remove the comment. 32: Page 33: All core SNMP MIBs have traditionally been registered under snmpModules and I am not sure we want to break that tradition (if we do, we should make a deliberate choice). Note that the revised SNMP over Ethernet module went with the tradition... 33: Page 33: The SnmpTransportModel TC might become handy at some point in time but I note that so far this is not used by any definition. 34: Page 35: Do we need a counter for situations where the dispatcher has to call a transport model which does not exist? 35: Page 36: The text boilerplate text needs to be revised to match the actual MIB definitions. Should we also add text stating that the data referred to by tmStateReference must be kept in protected storage or is this obvious? 36: Page 37: Updated the MIB module name and the registration point to match points 29 and 32 above. 37: Page 38: Why are references [RFC4366] and [RFC2865] normative? 38: Page 39: Why are references [RFC3419] and [RFC4251] normative? -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Nov 04 19:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVdj-0004lk-1C; Sat, 04 Nov 2006 19:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVdi-0004le-4L for isms@ietf.org; Sat, 04 Nov 2006 19:13:30 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgVdg-0003JW-I8 for isms@ietf.org; Sat, 04 Nov 2006 19:13:30 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2A0145ACC8 for ; Sun, 5 Nov 2006 01:13:28 +0100 (CET) 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 11465-06; Sun, 5 Nov 2006 01:13:25 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E57595AC3C; Sun, 5 Nov 2006 01:13:24 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 4BCB98BCCB4; Sun, 5 Nov 2006 01:13:24 +0100 (CET) Date: Sun, 5 Nov 2006 01:13:24 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20061105001324.GC27351@boskop.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.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [Isms] review of draft-ietf-isms-secshell-05.txt 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 I have reviewed and below are my comments (as a technical contributor). /js 01: Page 1: Reference [RFC 3411] in the third paragraph in section 1. 02: Page 5: The last sentence in the 3rd paragraph of section 1.3 somehow does not read well. 03: Page 5: "User Security Model" -> "User-based Security Model" 04: Page 6: Keyboard-interactive [RFC4256] has been excluded from the discussion of authentication mechanisms and I think it should be mentioned. 05: Page 7: Is the last paragraph on this page needed? 06: Page 8: I think we should replace the term "tunnel" with "channel". 07: Page 10: "SSH.This" -> "SSH. This" 08: Page 10: I think we need to mention here keyboard-interactive again. 09: Page 11: Expland "DH" the first time it is used. 10: Page 11: The first paragraph in section 3.1.7 actually is part of an applicability statement and perhaps should be factored out into a separate section. 11: Page 12: I think engineID discovery is so widely used with USM that we can't make the discovery implementation-dependent. We need an interoperable solution. The USM discovery procedure concerns the securityEngineID (the contextEngineID is actually not passed to a security model). My understanding is that implementations usually do securityEngineID discovery and subsequently use the securityEngineID also as the contextEngineID (basically assuming that they talk to the non-proxy agent). Please correct me if my assumption is wrong. Dave Perkins wrote a private message on this subject to a few people on Thu, 8 Sep 2005 which led to the conclusion that one should get an snmpUnknownPDUHandlers report if there is not value engineID (or the PDU type is invalid) and that this can be used to pickup the "local" engineID. Dave Perkins, can you post the relevant part of your message to this list? [Note that we also discussed this durng the Boston interim.] An alternative approach could be to introduce a "fake" securityEngineID into the Transport Security Model for the only purpose to let it be discovered and to let clients to continue to assume that the securityEngineID is the contextEngineID to use. Another alternative would be to introduce a general "default" contextEngineID (while conceptually simply and appealing, this does not really work due to the fact the no existing implementation has something like that and all SNMPv3/USM implementations are not likely to change). We need to settle on one approach and document it properly. 12: Page 13: 1st paragraph in 3.3: Is it OK to be silent how credentials are provisioned? 13: Page 14: Why do you use the tms prefix here? Note that the names of the transport domain etc. may need to be updated. I am not sure why you want to have the security model in the LCD. 14: Page 16: tmsTransportModel can't be "SSH Transport Model" 15: Page 16: Add a comment after tmStateReference in the ASIs. 16: Page 17: Add a comment after tmStateReference in the ASI and fix the alignment of the comments. 17: Page 18: [todo]: This is mainly an architectural problem since we can't write the EoP; I assume that in most implementations, you still know whether you send a response or a request. I am not sure what to do about it. This needs discussion. 18: Page 18: [todo]: I think it is always the client invoking the ssh-userauth service. Shall we state as in step 1) that it is implementation dependent where the parameters are coming from? 19: Page 19: drop "(TBD by IANA)" 20: Page 19: The last paragraph in 5.3 likely needs updates depending how we want to deal with engineID discovery. And I kind of believe we should deal with this in the Transport Security Model, not in every Transport Model. 21: Page 19: The first sentence in 5.4 needs a rewrite - closeSession does not pass data between the Transport Model and the SSH Service. 22: Page 21: "SSHTM-MIB" -> "SNMP-SSH-TM-MIB" to be consistent with prior naming conventions. This module should likely be registered under snmpModules as well. 23: Page 23: I am not sure we need TransportAddressSSH; we should be able to use TransportAddressDns. 24: Page 24: I think transportDomainSSH should be snmpSshDomain and be registered below snmpDomains (now that we even have an IANA registry for this). 25: Page 24: Does sshtmSessionOpenErrors count all open errors ranging from TCP connection establishment failures to SSH user authentication failures? 26: Page 24: When will sshtmSessionSecurityLevelNotAvailableErrors be incremented? Does the document not say SSH is always providing good enough security and we trust it? 27: Page 30: I do not understand the [discuss]. 28: Page 30/31: The MIB module security section needs to be updated. 29: Page 31: IANA considerations need to be updated (mib-2 -> snmpModules, registration of snmpSshDomain, creation of the transport modules registration is done the transport model architectural extension document. -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Nov 06 04:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0QB-0002PD-Ca; Mon, 06 Nov 2006 04:05:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0QA-0002P8-GG for isms@lists.ietf.org; Mon, 06 Nov 2006 04:05:34 -0500 Received: from web58407.mail.re3.yahoo.com ([68.142.236.175]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gh0Q9-0000vj-89 for isms@lists.ietf.org; Mon, 06 Nov 2006 04:05:34 -0500 Received: (qmail 95714 invoked by uid 60001); 6 Nov 2006 09:05:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rKeVY/I0vtqp0/KYvUBPUMi5A/BlJxjkmGLOAxhEIEF7DGKgm1BgS1jZP4AIIXTHvXi1gY3/x0U3JWxarukuBx0MB4WV0sTQePfu+M1bSEjk0XVYXPGRd33B9MB3rrfLS4ts5HIqTUYSrs8Awsa6Uhabh2xa+FI8nZa0j2cx5JU= ; Message-ID: <20061106090533.95712.qmail@web58407.mail.re3.yahoo.com> Received: from [88.154.157.174] by web58407.mail.re3.yahoo.com via HTTP; Mon, 06 Nov 2006 01:05:33 PST Date: Mon, 6 Nov 2006 01:05:33 -0800 (PST) From: Ziv Artzi To: isms@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Isms] Where I find answers about USM? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925470363==" Errors-To: isms-bounces@lists.ietf.org --===============0925470363== Content-Type: multipart/alternative; boundary="0-9985731-1162803933=:91556" Content-Transfer-Encoding: 8bit --0-9985731-1162803933=:91556 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, this is my first msg here :) I have recently started investigating SNMP, and SNMP security particulary. I read the RFC 3414 (USM) and I have questions about it. The problem is that there is no longer an active working group for that. I will be glad if you will tell me who can help, or just answer the next q's: 1. What is the need for two counters of time latestReceivedEngineTime and snmpEngineTime that are saved against all source engine. The paragraph 2.3 says that it is against a threat of DoS by Replay attack but does not ellaborate. I think there is no such threat. 2. The process of Discovery (chapter 4) seems not to be supported by chapter 3. examples: how the discover gets the key that will be used by him in order to secure the 2nd message of his? where in 3.2 there is handling of incoming messages with zero values like the discovery (2nd message also) Thanks, Ziv --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. --0-9985731-1162803933=:91556 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
this is my first msg here :)
 
I have recently started investigating SNMP, and SNMP security particulary.
I read the RFC 3414 (USM) and I have questions about it. The problem is that there is no longer an active working group for that.
 
I will be glad if you will tell me who can help, or just answer the next q's:
 
1. What is the need for two counters of time latestReceivedEngineTime and snmpEngineTime that are saved against all source engine. The paragraph 2.3 says that it is against a threat of DoS by Replay attack but does not ellaborate. I think there is no such threat.
2. The process of Discovery (chapter 4) seems not to be supported by chapter 3. examples: how the discover gets the key that will be used by him in order to secure the 2nd message of his? where in 3.2 there is handling of incoming messages with zero values like the discovery (2nd message also)
 
Thanks,
Ziv

Want to start your own business? Learn how on Yahoo! Small Business. --0-9985731-1162803933=:91556-- --===============0925470363== 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 --===============0925470363==-- From isms-bounces@lists.ietf.org Mon Nov 06 10:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6W8-0006kr-PC; Mon, 06 Nov 2006 10:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6V4-0005fV-9H for isms@lists.ietf.org; Mon, 06 Nov 2006 10:35:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6HP-0006pr-S7 for isms@lists.ietf.org; Mon, 06 Nov 2006 10:21:02 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2006 07:20:23 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABvgTkWrR7PDh2dsb2JhbACMSgEBAQgOKg X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="350287722:sNHT47194416388" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6FKMK1009451; Mon, 6 Nov 2006 07:20:22 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6FKMAo018614; Mon, 6 Nov 2006 07:20:22 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA09078; Mon, 6 Nov 2006 07:18:56 -0800 (PST) From: Keith McCloghrie Message-Id: <200611061518.HAA09078@cisco.com> Subject: Re: [Isms] Where I find answers about USM? To: zivartzi@yahoo.com (Ziv Artzi) Date: Mon, 6 Nov 2006 07:18:56 -0800 (PST) In-Reply-To: from "Ziv Artzi" at Nov 06, 2006 01:05:33 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1854; t=1162826422; x=1163690422; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:Keith=20McCloghrie=20 |Subject:Re=3A=20[Isms]=20Where=20I=20find=20answers=20about=20USM?; X=v=3Dcisco.com=3B=20h=3DyO3nJyfNhKItqrrKg5XCN7TjYaA=3D; b=u136crKi1Z2vjIeXIg4xjt6I9gAUbRCPJxwecmITjPClzb0i0RZAdA5MSDW+fgnKvm42NK6F B0TOyiI63GGiqFwNYREXMPCrdq5ycFmwunF0RVqMfkpceVhMseLbKSoe; Authentication-Results: sj-dkim-3.cisco.com; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@lists.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 > this is my first msg here :) Welcome. > I have recently started investigating SNMP, and SNMP security particulary. > I read the RFC 3414 (USM) and I have questions about it. The problem is > that there is no longer an active working group for that. > > I will be glad if you will tell me who can help, The ISMS WG is defining a new Security Model for SNMPv3 to augment USM, and you could ask your questions in that WG. Alternatively, you could ask on one of the OPS area mailing lists (see http://www.ops.ietf.org/), e.g., ietfmibs@ietf.org. > or just answer the next q's: I'll try. > 1. What is the need for two counters of time > latestReceivedEngineTime and snmpEngineTime that are saved against all > source engine. The paragraph 2.3 says that it is against a threat of > DoS by Replay attack but does not ellaborate. I think there is no such > threat. If I recall correctly, snmpEngineTime is adjusted (based on received authentic messages) in order to prevent clock drift. Such adjustments could be used in a DOS attack to prevent the clock from moving forward. E.g., capturing authentic messages and replaying them while they are still authentic as a means of preventing the time window from moving forward. latestReceivedEngineTime prevents such an attack. > 2. The process of Discovery (chapter 4) seems not to be supported > by chapter 3. examples: how the discover gets the key that will be used > by him in order to secure the 2nd message of his? where in 3.2 there is > handling of incoming messages with zero values like the discovery (2nd > message also) Discovery is about discovering the presence of other engines, so that (unprotected) communication can can occur. It does not discover the secrets which are necessary for protected communcation. Keith. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Nov 06 14:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhA7H-0004xb-Oa; Mon, 06 Nov 2006 14:26:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhA7F-0004x5-KT for isms@lists.ietf.org; Mon, 06 Nov 2006 14:26:41 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhA7D-0004f6-B5 for isms@lists.ietf.org; Mon, 06 Nov 2006 14:26:41 -0500 Received: from dhcp69-133.ietf67.org (dhcp69-133.ietf67.org [130.129.69.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BDFB813CF82 for ; Mon, 6 Nov 2006 20:28:52 +0100 (CET) Date: Mon, 06 Nov 2006 20:26:27 +0100 From: Juergen Quittek To: isms@lists.ietf.org Message-ID: <38E6E74410F55804FC1B8D09@dhcp69-133.ietf67.org> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Isms] draft session agenda 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 Dear all, Please find the draft agenda of our meeting on Thursday at . Comments on the agenda are very welcome. Thanks, Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Nov 09 12:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDKh-00046G-O4; Thu, 09 Nov 2006 12:04:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDKg-00046A-OZ for isms@ietf.org; Thu, 09 Nov 2006 12:04:54 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDKe-000833-DJ for isms@ietf.org; Thu, 09 Nov 2006 12:04:54 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B7A075ADC5 for ; Thu, 9 Nov 2006 18:04:51 +0100 (CET) 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 14000-07; Thu, 9 Nov 2006 18:04:48 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8904A5AE21; Thu, 9 Nov 2006 18:04:48 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 22F8F8C2424; Thu, 9 Nov 2006 18:04:46 +0100 (CET) Date: Thu, 9 Nov 2006 18:04:46 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20061109170446.GA8235@boskop.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.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Isms] today's session has been moved 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, today's ISMS session has been moved to Harbor Island III: : ISMS Session 1 (1 hour) : Thursday, Afternoon Session II 1510-1610 : Room Name: Harbor Island III : ---------------------------------------------- : : Special Note: ROOM CHANGE : : : Requested Information: : : : --------------------------------------------------------- : Working Group Name: isms : Area Name: Security Area : Session Requester: Juergen Quittek : : Number of Sessions: 1 : Length of Session(s): 1 hour The reason behind the room change was the lack of audio streaming support in the previous room. Accoring to the audio web page, the audio stream should now be on: http://videolab.uoregon.edu/events/ietf/ietf676.m3u As usual, the jabber room is "isms" on jabber.ietf.org. /js -- Juergen Schoenwaelder International University Bremen (Jacobs University Bremen as of Spring 2007) 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 Nov 09 19:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiK8A-0007Te-RQ; Thu, 09 Nov 2006 19:20:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiK89-0007TA-S2 for isms@ietf.org; Thu, 09 Nov 2006 19:20:25 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiK88-0004JB-Jg for isms@ietf.org; Thu, 09 Nov 2006 19:20:25 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8H009QKNGV07@usaga01-in.huawei.com> for isms@ietf.org; Thu, 09 Nov 2006 16:17:19 -0800 (PST) Received: from Harrington73653 (dhcp71-105.ietf67.org [130.129.71.105]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8H00BX4NGR53@usaga01-in.huawei.com> for isms@ietf.org; Thu, 09 Nov 2006 16:17:19 -0800 (PST) Date: Thu, 09 Nov 2006 16:17:38 -0800 From: David Harrington In-reply-to: <304BF6AEA3DA71488B9EC776A03D6FFB045E08F2@EVS3.ams.gblxint.com> To: "'Copley, Timothy'" Message-id: <093801c7045d$a14c72c0$0600a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccEWoFxURGSwg3uTNyjtcTMLI+88gAAF1YA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: isms@ietf.org Subject: [Isms] RE: Transport MIB removal 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 think these can be provided elsewhere. > *) Failed attempts > *) # of connections, # of attempts. > *) Connections > *) Amount of data over transport, data These can be provided in MIB modules of the individual transport models, such as SSH-TM. If we keep one counter that is the aggregate failed attempts of multiple transport models, we won't know which transport is having a problem. It would be difficult to build a transport-agnostic table without knowing what parameters need to be known to understand the data. I recommend using separate MIB modules per transport model. This is also consistent with the RFC3411 approach to keep separate model-specific MIB modules. > *) Failover to different pollers We do not handle failover automatically as part of the transport model or the transport subsystem or the security model. We should report failures back to the requester via the ASIs; the SNMP Application can make the determination of whether to failover to a different transport. Only the "SNMP application" (or the application that uses it) knows the content, and it should make the decision about which transports (especially of different security levels) are acceptable for failover. dbh > -----Original Message----- > From: Copley, Timothy [mailto:Timothy.Copley@GlobalCrossing.com] > Sent: Thursday, November 09, 2006 3:55 PM > To: dharrington@huawei.com > Subject: Transport MIB removal > > I think we need it. Sorry, I'm not a security guy > by any means, however, There are a few things I think > We would need that the transport architecture should > provide. > > *) Failed attempts > *) Failover to different pollers > *) # of connections, # of attempts. > *) Connections > *) Amount of data over transport, data > > I would like to see these things in a mib. Is it > provided somewhere else? > > Thanks, > TimC > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Nov 09 21:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLlc-0001Da-Dj; Thu, 09 Nov 2006 21:05:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLlb-00019J-7V for isms@ietf.org; Thu, 09 Nov 2006 21:05:15 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLlX-0000N0-QG for isms@ietf.org; Thu, 09 Nov 2006 21:05:15 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6808E20031EF; Fri, 10 Nov 2006 03:05:41 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntV2mwVRMnPn; Fri, 10 Nov 2006 03:05:41 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5193B20031E5; Fri, 10 Nov 2006 03:05:41 +0100 (CET) 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 Date: Fri, 10 Nov 2006 03:05:10 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBA@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISMS IETF67 session summary Thread-Index: AccEbKaLCfVPBK2PSDecYmhEXKPwjQ== From: "Juergen Quittek" To: , , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Isms] ISMS IETF67 session summary 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 ISMS IETF67 session summary ISMS met on Thursday after the SAAG meeting. As agreed at the last meeting, one of the two existing WG documents was split into two. The resulting three documents describe a transport subsystem for SNMP, a transport security model for SNMP, and a SSH security model for SNMP. The new document structure is more modular and simplifies the potential future specification of other security=20 models, for example, a TLS security model in addition to the SSH model that the ISMS WG develops. The new document structure was=20 approved by the WG and by the responsible AD Sam Hartman. For the transport subsystem for SNMP and the transport security model for SNMP all open issues have been resolved and the next versions of these documents will enter WGLC. The SSH security model for SNMP will probably need two more revisions to be ready for WGLC. The=20 biggest open issue is the authentication for notifications. The charter contains two more documents that do not yet exist. One describes the usage of RADIUS for the SSH security model. We have an individual draft, but kept it on hold until the SSH security model had become sufficiently stable. This has been achieved with the current version of the SSH security model. Now, work on the RADIUS document can go on and the initial WG draft is planned for December. The last document on the charter is an applicability statement=20 for ISMS. With the new modular structure, the WG considers it preferable to have rather applicability statements per module instead of a generic one for ISMS. It was agreed to drop this document and instead add a specific applicability statement to the SSH security module. This change was approved by the=20 responsible AD. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Nov 12 07:13:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjECq-0004tB-R0; Sun, 12 Nov 2006 07:13:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjECq-0004t5-4X for isms@lists.ietf.org; Sun, 12 Nov 2006 07:13:00 -0500 Received: from web58409.mail.re3.yahoo.com ([68.142.236.177]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjECm-0001ih-Lh for isms@lists.ietf.org; Sun, 12 Nov 2006 07:13:00 -0500 Received: (qmail 27658 invoked by uid 60001); 12 Nov 2006 12:12:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CeIcDOm8BGh9z8PMWn0qaO5hjn1g+pne8OMHVxYqA4MR3uYIxukp5aqIwp4fjiESJ3Wk6R7+2oyx1xRKdfYCeh+cr4+qOGhIthC1ZbF73UCzlraUNsWceSQ8uHVqPUnyIuzBqwuT0gUnuKcaJCjSKCDKOhiDQIw7707t3I309qs= ; Message-ID: <20061112121256.27656.qmail@web58409.mail.re3.yahoo.com> Received: from [82.81.29.187] by web58409.mail.re3.yahoo.com via HTTP; Sun, 12 Nov 2006 04:12:56 PST Date: Sun, 12 Nov 2006 04:12:56 -0800 (PST) From: Ziv Artzi Subject: Re: [Isms] Where I find answers about USM? To: Keith McCloghrie In-Reply-To: <200611061518.HAA09078@cisco.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@lists.ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576816608==" Errors-To: isms-bounces@lists.ietf.org --===============1576816608== Content-Type: multipart/alternative; boundary="0-281996512-1163333576=:27261" Content-Transfer-Encoding: 8bit --0-281996512-1163333576=:27261 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Keith, Thanks for the fast reply. However, I still don't understand the threat of preventing the snmpEngineTime from advancing. I will explain it in 2 ways: 1. Replaying authentic message cannot cause the snmpEngineTime to move downward since it's defined that this value is changed only in the next cases: a. reset, initialization => keeping another variable won't help, it will suffer the same behvior b. getting a message with equal snmpEngingBoots in the SNMP header and in local notion, but with snmpEngineTime bigger in the header than the local notion => snmpEngineTime got bigger c. getting a message with snmpEngingBoots bigger in the SNMP header than local notion and then snmpEngineTime will get the value from the SNMP header => (snmpEngingBoots , snmpEngineTime ) got bigger lexicographically as an ordered couple. in all cases, i don't see how the time window isn't advancing (it can stay in place, but the attacker cannot prevent it from advancing by real authentic messages!). 2. snmpEngineTime and latestReceivedEngineTime seem to be updated together to the same value (from the SNMP header) so when are they different? can you or anyone check it up please? thanks, Ziv Keith McCloghrie wrote: > 1. What is the need for two counters of time > latestReceivedEngineTime and snmpEngineTime that are saved against all > source engine. The paragraph 2.3 says that it is against a threat of > DoS by Replay attack but does not ellaborate. I think there is no such > threat. If I recall correctly, snmpEngineTime is adjusted (based on received authentic messages) in order to prevent clock drift. Such adjustments could be used in a DOS attack to prevent the clock from moving forward. E.g., capturing authentic messages and replaying them while they are still authentic as a means of preventing the time window from moving forward. latestReceivedEngineTime prevents such an attack. --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. --0-281996512-1163333576=:27261 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Keith,
 
Thanks for the fast reply.
 
However, I still don't understand the threat of preventing the snmpEngineTime from advancing. I will explain it in 2 ways:
1. Replaying authentic message cannot cause the snmpEngineTime to move downward since it's defined that this value is changed only in the next cases:
   a. reset, initialization => keeping another variable won't help, it will suffer the same behvior
   b. getting a message with equal snmpEngingBoots in the SNMP header and in local notion, but with snmpEngineTime bigger in the header than the local notion => snmpEngineTime got bigger
  c. getting a message with snmpEngingBoots bigger in the SNMP header than local notion and then snmpEngineTime will get the value from the SNMP header => (snmpEngingBoots , snmpEngineTime ) got bigger lexicographically as an ordered couple.
 
in all cases, i don't see how the time window isn't advancing (it can stay in place, but the attacker cannot prevent it from advancing by real authentic messages!).
 
2. snmpEngineTime and latestReceivedEngineTime seem to be updated together to the same value (from the SNMP header) so when are they different?
 
can you or anyone check it up please?
 
thanks,
Ziv

Keith McCloghrie <kzm@cisco.com> wrote:

> 1. What is the need for two counters of time
> latestReceivedEngineTime and snmpEngineTime that are saved against all
> source engine. The paragraph 2.3 says that it is against a threat of
> DoS by Replay attack but does not ellaborate. I think there is no such
> threat.

If I recall correctly, snmpEngineTime is adjusted (based on received
authentic messages) in order to prevent clock drift. Such adjustments
could be used in a DOS attack to prevent the clock from moving forward.
E.g., capturing authentic messages and replaying them while they are
still authentic as a means of preventing the time window from moving
forward. latestReceivedEngineTime prevents such an attack.

Want to start your own business? Learn how on Yahoo! Small Business. --0-281996512-1163333576=:27261-- --===============1576816608== 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 --===============1576816608==-- From isms-bounces@lists.ietf.org Sun Nov 12 11:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjINf-0001kN-2Z; Sun, 12 Nov 2006 11:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjINd-0001iI-4z for isms@lists.ietf.org; Sun, 12 Nov 2006 11:40:25 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjINX-0006rn-OJ for isms@lists.ietf.org; Sun, 12 Nov 2006 11:40:25 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 12 Nov 2006 08:40:07 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 12 Nov 2006 08:40:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,415,1157353200"; d="scan'208"; a="145012491:sNHT20185221" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 08:40:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Where I find answers about USM? Date: Sun, 12 Nov 2006 11:40:06 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F326FB@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Where I find answers about USM? thread-index: AccGVDXJI25eZZQ0TwGw+YvCBVQ5UgAIpHIw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 12 Nov 2006 16:40:06.0588 (UTC) FILETIME=[35BF2FC0:01C70679] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 > However, I still don't understand the threat of preventing > the snmpEngineTime from advancing. I will explain it in 2 ways: > > 1. Replaying authentic message cannot cause the snmpEngineTime > to move downward.............. But relpaying can cause the notion of snmpEngineTime to "freeze", effectively moving it backwards against the real clock. > 2. snmpEngineTime and latestReceivedEngineTime seem to be > updated together to the same value (from the SNMP header) > so when are they different? Not together (one only if the check with the other passed OK) and not to the same value. snmpEngineTime is a computed (dynamic) value. A smart engine stores and adjusts the clock difference. Comparing only with snmpEngineTime is insufficient. We have made our decisions 10 years ago based on long and scrupulous analysis. Since this protocol is a done deal by now - perhaps it's best to leave the "whys" of it as a home exercise (a recommendation: start with an approach "if they put it in - they must have had a reason, let me figure out what it is"). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Nov 13 22:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjoZi-00028i-KU; Mon, 13 Nov 2006 22:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjoZh-00028X-Gv for isms@lists.ietf.org; Mon, 13 Nov 2006 22:03:01 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjoZg-00015f-2f for isms@lists.ietf.org; Mon, 13 Nov 2006 22:03:01 -0500 Received: from harrington73653 (c-24-128-66-115.hsd1.nh.comcast.net[24.128.66.115]) by comcast.net (sccrmhc14) with SMTP id <2006111403025901400mgvbie>; Tue, 14 Nov 2006 03:02:59 +0000 From: "David Harrington" To: "'Ziv Artzi'" , "'Keith McCloghrie'" Subject: RE: [Isms] Where I find answers about USM? Date: Mon, 13 Nov 2006 22:00:26 -0500 Message-ID: <0b6f01c70799$09481c60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: <20061112121256.27656.qmail@web58409.mail.re3.yahoo.com> Thread-Index: AccGU/xm/tR5nvF6Rd+3PMjAbvYY1wBP0sBw X-Spam-Score: 0.1 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: isms@lists.ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1895465791==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1895465791== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B70_01C7076F.20721460" This is a multi-part message in MIME format. ------=_NextPart_000_0B70_01C7076F.20721460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ziv, We did a great deal of work considering all the possible variations, felt there was a DoS attack, and detailed how to avoid the DoS attack. I do not see what the community will gain from having this threat re-examined and re-justified. Doing so will cost the community resources that could be allocated to doing other things that are more beneficial. Can you justify our spending time revisiting this design decision? If I were to check this, the way I would do it would be to go through rfc3414 elements of procedure and detail the conditional logic steps and the relevant processing steps, in a flowchart or something similar. Then I would assign some reasonable values to the relevant variables, and then vary them to see how they would impact the processing. I would make it a point to **identify the relevant clauses** that cause certain processing to occur, given the values of the variables. I think you might find the answer to your question if you do this time-consuming exercise. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair SNMPv3 WG, concluded _____ From: Ziv Artzi [mailto:zivartzi@yahoo.com] Sent: Sunday, November 12, 2006 4:13 AM To: Keith McCloghrie Cc: isms@lists.ietf.org Subject: Re: [Isms] Where I find answers about USM? Hi Keith, Thanks for the fast reply. However, I still don't understand the threat of preventing the snmpEngineTime from advancing. I will explain it in 2 ways: 1. Replaying authentic message cannot cause the snmpEngineTime to move downward since it's defined that this value is changed only in the next cases: a. reset, initialization => keeping another variable won't help, it will suffer the same behvior b. getting a message with equal snmpEngingBoots in the SNMP header and in local notion, but with snmpEngineTime bigger in the header than the local notion => snmpEngineTime got bigger c. getting a message with snmpEngingBoots bigger in the SNMP header than local notion and then snmpEngineTime will get the value from the SNMP header => (snmpEngingBoots , snmpEngineTime ) got bigger lexicographically as an ordered couple. in all cases, i don't see how the time window isn't advancing (it can stay in place, but the attacker cannot prevent it from advancing by real authentic messages!). 2. snmpEngineTime and latestReceivedEngineTime seem to be updated together to the same value (from the SNMP header) so when are they different? can you or anyone check it up please? thanks, Ziv Keith McCloghrie wrote: > 1. What is the need for two counters of time > latestReceivedEngineTime and snmpEngineTime that are saved against all > source engine. The paragraph 2.3 says that it is against a threat of > DoS by Replay attack but does not ellaborate. I think there is no such > threat. If I recall correctly, snmpEngineTime is adjusted (based on received authentic messages) in order to prevent clock drift. Such adjustments could be used in a DOS attack to prevent the clock from moving forward. E.g., capturing authentic messages and replaying them while they are still authentic as a means of preventing the time window from moving forward. latestReceivedEngineTime prevents such an attack. _____ Want to start your own business? Learn how on Yahoo! Small Business. ------=_NextPart_000_0B70_01C7076F.20721460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ziv,
 
We did a great deal of work considering all the = possible=20 variations, felt there was a DoS attack, and detailed how to avoid the = DoS=20 attack.
 
I do not see what the community will gain from = having this=20 threat re-examined and re-justified. Doing so will cost the community = resources=20 that could be allocated to doing other things that are more beneficial. = Can you justify=20 our spending time revisiting this design=20 decision?
 
If I were to check this, the way I would = do it would=20 be to go through rfc3414 elements of procedure and detail the = conditional=20 logic steps and the relevant processing steps, in a flowchart or = something=20 similar. Then I would assign some reasonable values to = the relevant=20 variables, and then vary them to see how they would impact the = processing.=20 I would make it a point to **identify the relevant clauses** = that cause=20 certain processing to occur, given the values of the variables. I think = you=20 might find the answer to your question if you do this time-consuming=20 exercise.
 
David=20 Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfd= bh@comcast.net
co-chair SNMPv3=20 WG, concluded

From: Ziv Artzi = [mailto:zivartzi@yahoo.com]=20
Sent: Sunday, November 12, 2006 4:13 AM
To: Keith = McCloghrie
Cc: isms@lists.ietf.org
Subject: Re: = [Isms]=20 Where I find answers about USM?

Hi Keith,
 
Thanks for the fast reply.
 
However, I still don't understand the threat = of preventing the=20 snmpEngineTime from advancing. I will explain it in 2 ways:
1. Replaying authentic message cannot cause the snmpEngineTime to = move=20 downward since it's defined that this value is changed only in the = next=20 cases:
   a. reset, initialization =3D> keeping another = variable=20 won't help, it will suffer the same behvior
   b. getting a message with equal snmpEngingBoots in = the SNMP=20 header and in local notion, but with snmpEngineTime bigger in the = header than=20 the local notion =3D> snmpEngineTime got bigger
  c. getting a message with snmpEngingBoots bigger in = the SNMP=20 header than local notion and then snmpEngineTime will get the = value from=20 the SNMP header =3D> (snmpEngingBoots , snmpEngineTime ) got bigger = lexicographically as an ordered couple.
 
in all cases, i don't see how the time window isn't advancing (it = can=20 stay in place, but the attacker cannot prevent it from advancing by = real=20 authentic messages!).
 
2. snmpEngineTime and latestReceivedEngineTime seem to be = updated=20 together to the same value (from the SNMP header) so when are they=20 different?
 
can you or anyone check it up please?
 
thanks,
Ziv

Keith McCloghrie <kzm@cisco.com>=20 wrote:

>=20 1. What is the need for two counters of time
>=20 latestReceivedEngineTime and snmpEngineTime that are saved against=20 all
> source engine. The paragraph 2.3 says that it is against = a=20 threat of
> DoS by Replay attack but does not ellaborate. I = think=20 there is no such
> threat.

If I recall correctly,=20 snmpEngineTime is adjusted (based on received
authentic messages) = in=20 order to prevent clock drift. Such adjustments
could be used in a = DOS=20 attack to prevent the clock from moving forward.
E.g., capturing=20 authentic messages and replaying them while they are
still = authentic as a=20 means of preventing the time window from moving
forward.=20 latestReceivedEngineTime prevents such an = attack.

Want to start your own business? Learn how on Yahoo!=20 Small Business. ------=_NextPart_000_0B70_01C7076F.20721460-- --===============1895465791== 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 --===============1895465791==-- From isms-bounces@lists.ietf.org Wed Nov 15 17:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTVg-0001B4-PC; Wed, 15 Nov 2006 17:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTVf-0001Az-83 for isms@ietf.org; Wed, 15 Nov 2006 17:45:35 -0500 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTVa-0004Xd-T9 for isms@ietf.org; Wed, 15 Nov 2006 17:45:35 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kAFMjT53001580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 17:45:29 -0500 (EST) Date: Wed, 15 Nov 2006 17:45:29 -0500 From: Jeffrey Hutzelman To: j.schoenwaelder@iu-bremen.de, isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-transport-security-model-00.txt Message-ID: <1514B5D157CDCF8E1C56AECD@sirius.fac.cs.cmu.edu> In-Reply-To: <20061105001109.GA27351@boskop.local> References: <20061105001109.GA27351@boskop.local> Originator-Info: login-token=Mulberry:01Vj3glcClVQmiiFgWibsQBO2vF8DdcVnDsg76jL0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Jeffrey Hutzelman 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 On Sunday, November 05, 2006 01:11:09 AM +0100 Juergen Schoenwaelder wrote: > 06: Page 8: I am not sure how useful it will ever be to run USM over > SSH (second bullet). If we like to discuss such cases, it might be > worth to note, however, that in such a configuration the > securityName would be derived from the USM userName and the > securityName provided by the secure Transport Model would be > ignored. Right. That is, if USM runs over any transport, then it should run over any transport, including SSH. I'm not sure this will ever have any operational value, but it's good for thinking about whether the abstraction is good enough. > > 09: Page 10: It should probably be noted somewhere that the fact that > there is only a single Transport Security Model for potentially > many secure transports implies that you cannot have different > access control rules for say SNMPv3/TMS/SSH and SNMPv3/TMS/TLS > since the isAccessAllowed primitive only takes the securityModel > as input but not the transport model. I am not saying this is a > problem - just that we should be clear about this. That's an interesting point. Of course, it's not clear to me how the securityName would be derived with a TLS transport; if the namespaces happened to be disjoint, this wouldn't be an issue. > 25: Page 20: I do not understand step 2). If you want to check that > the security level reported via the tmStateReference is at least > as good as the securityLevel indicated in the message, just do it > and discard the packet otherwise. I do not understand the text > about securityModel and securityName. SecurityName is an OUT > parameter and the securityModel was used to call us; was your idea > to check for "surprising" combinations of security models with > transport models? I believe we should not do this. > > 26: Page 20: Before step 3) (mistakenly called 2) again), we have to > make sure a valid tmStateReference has been provided. If it is > missing (e.g. the packet was received via a plain TCP/UDP > transport), then we should discard the packet and increment a > suitable counter. > > 27: Page 21: The transportStats subtree is empty - drop 5.3. The > transportState subtree is empty - drop 5.4. > > 28: Page 22: Transport-Subsystem-MIB will be renamed - updated needed > here to be consistent. > > 29: Page 22: The name of the MIB module should be changed to > SNMP-TRANSPORT-SM-MIB to be consistend with other SNMPv3 > specifications and I suggest to register the module below > snmpModules. > > 30: Page 22-27: Almost all definitions should be removed since they > are not needed. What is missing are two counters: one for messages > dropped due to the security level in the message being > inconsistent with the security level provided by the transport > (step 2) in the elements of procedure for incoming messages) and > one counter for messages dropped due to a missing tmStateReference. > > 31: Page 28: The MIB boilerplate security text needs to be updated. > > 32: Page 29: IANA considerations must be updated if we register under > snmpModules. > > 33: Page 30: I believe reference [RFC3419] is not needed. > > 34: Appendix A: Some of the tags need to be updated. If we drop the > user table in the MIB module, we can also drop section > A.1. Section A.2 depends on the SSH transport model which I think > we should avoid. It might make more sense to let the SSH transport > model depend on the Tranport Security Model and to move the > notification example to the SSH document. (We should definately > keep the example since this is useful.) > > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Nov 17 08:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl3Nr-0001d4-3b; Fri, 17 Nov 2006 08:03:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl3Nq-0001cz-1a for isms@lists.ietf.org; Fri, 17 Nov 2006 08:03:54 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl3Nj-0008D4-JP for isms@lists.ietf.org; Fri, 17 Nov 2006 08:03:54 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D59A1180 for ; Fri, 17 Nov 2006 14:03:46 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 14:03:46 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 14:03:46 +0100 Message-ID: <455DB332.2090404@ericsson.com> Date: Fri, 17 Nov 2006 14:03:46 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: isms@lists.ietf.org References: <0b6f01c70799$09481c60$0600a8c0@china.huawei.com> In-Reply-To: <0b6f01c70799$09481c60$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 13:03:46.0602 (UTC) FILETIME=[D12340A0:01C70A48] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Isms] ISMS without support for notifications, is it useful? 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 Hello All, After participating in the Isms wg meeting in San Diego I would like to make some comments as a potential user of ISMS. Sorry if I misunderstand the situation. Isms is proceeding well with their work but only officially. In reallity ISMS gave up on applying their new security solution to agent initiated traffic (notifications, traps). This means that for these to be secured you still need USM security. But the whole Isms started by hating USM, as it is too much work to configure. Alternatives: 1) Forget the whole Isms as useless 2) Use Isms for get, set type operations and use USM security for notifications/traps. In this case we have 2 security models to configure instead of one, so SNMP security configuration got even more complicated. 3) Use Isms for get,set type of operations and do not secure notifications. This assumes that notifications are inherently less sensitive then get/set commands. While this might be true in some cases it is not generally accepted. We might still try to propose this alternative to customers and have USM security as a backup. Personal opinion: push Isms to solve the problem of notifications or forget about Isms. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Nov 17 09:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4hz-00065E-FK; Fri, 17 Nov 2006 09:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4hx-000651-Rq for isms@lists.ietf.org; Fri, 17 Nov 2006 09:28:45 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4hv-0003dV-Cx for isms@lists.ietf.org; Fri, 17 Nov 2006 09:28:45 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A93135ACD6; Fri, 17 Nov 2006 15:28:42 +0100 (CET) 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 08100-10; Fri, 17 Nov 2006 15:28:39 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B433D5ACE2; Fri, 17 Nov 2006 15:28:39 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 7DABC8CAD3C; Fri, 17 Nov 2006 15:28:38 +0100 (CET) Date: Fri, 17 Nov 2006 15:28:37 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Subject: Re: [Isms] ISMS without support for notifications, is it useful? Message-ID: <20061117142837.GA6126@boskop.local> References: <0b6f01c70799$09481c60$0600a8c0@china.huawei.com> <455DB332.2090404@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455DB332.2090404@ericsson.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@lists.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, Nov 17, 2006 at 02:03:46PM +0100, Balazs Lengyel wrote: > Isms is proceeding well with their work but only officially. > > In reallity ISMS gave up on applying their new security solution to > agent initiated traffic (notifications, traps). This means that for > these to be secured you still need USM security. But the whole Isms > started by hating USM, as it is too much work to configure. I do not think this is a correct summary if you happen to read the specifications. The documents do not state that notifications are dropped somehow on the floor if you try to send them. What ISMS did not figure out (yet?) is how to send notifications over SSH without having to provision extra credentials and not reversing authenticated identities. Several options were discussed, none did really convince so far. Perhaps we simply have to accept that notifications over SSH require credentials to be provisioned. Concerning USM: What really bothers me personally is the lack of context engineID discovery. I want to do something as simple as snmpwalk ssh:myagent ifTable and we are close to that except that the context engineID is missing. >From my understanding of the problem, the easiest solution seems to follow a proposal by Dave Perkins to introduce a default context engineID, much like the default context name. Having to send USM messages or SNMPv1 messages just to get ISMS going seems like an ugly hack. Introduction of a default context engineID probably falls out of the charter of this WG; not sure whether something like this can be introduced by means of an individual submission as an enhancement of SNMPv3. Without a working context engineID discovery solution, it will be much more difficult to upgrade the many applications that are internally still SNMPv1/SNMPv2c and do not maintain engineIDs to use a secure transport. /js -- Juergen Schoenwaelder International University Bremen (Jacobs University Bremen as of Spring 2007) 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 Nov 17 10:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5xQ-00050F-7k; Fri, 17 Nov 2006 10:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5xO-000504-OT for isms@lists.ietf.org; Fri, 17 Nov 2006 10:48:46 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5x0-0004kp-6b for isms@lists.ietf.org; Fri, 17 Nov 2006 10:48:46 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ACF681186; Fri, 17 Nov 2006 16:46:38 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 16:46:38 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 16:29:06 +0100 Message-ID: <455DD542.9070800@ericsson.com> Date: Fri, 17 Nov 2006 16:29:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] ISMS without support for notifications, is it useful? References: <0b6f01c70799$09481c60$0600a8c0@china.huawei.com> <455DB332.2090404@ericsson.com> <20061117142837.GA6126@boskop.local> In-Reply-To: <20061117142837.GA6126@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 15:29:07.0023 (UTC) FILETIME=[1EE9E5F0:01C70A5D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: isms@lists.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 Hello, Thanks for the info. From the meeting I had the feeling that Isms intends to drop the issue of notifications. It seems that this was my misunderstanding. I am really happy that you are working on the solution. Balazs PS. I did read much of the drafts. Juergen Schoenwaelder wrote: > On Fri, Nov 17, 2006 at 02:03:46PM +0100, Balazs Lengyel wrote: > >> Isms is proceeding well with their work but only officially. >> >> In reallity ISMS gave up on applying their new security solution to >> agent initiated traffic (notifications, traps). This means that for >> these to be secured you still need USM security. But the whole Isms >> started by hating USM, as it is too much work to configure. > > I do not think this is a correct summary if you happen to read the > specifications. The documents do not state that notifications are > dropped somehow on the floor if you try to send them. > > What ISMS did not figure out (yet?) is how to send notifications over > SSH without having to provision extra credentials and not reversing > authenticated identities. Several options were discussed, none did > really convince so far. Perhaps we simply have to accept that > notifications over SSH require credentials to be provisioned. > > Concerning USM: What really bothers me personally is the lack of > context engineID discovery. I want to do something as simple as > > snmpwalk ssh:myagent ifTable > > and we are close to that except that the context engineID is missing. > From my understanding of the problem, the easiest solution seems to > follow a proposal by Dave Perkins to introduce a default context > engineID, much like the default context name. Having to send USM > messages or SNMPv1 messages just to get ISMS going seems like an ugly > hack. > > Introduction of a default context engineID probably falls out of the > charter of this WG; not sure whether something like this can be > introduced by means of an individual submission as an enhancement of > SNMPv3. Without a working context engineID discovery solution, it will > be much more difficult to upgrade the many applications that are > internally still SNMPv1/SNMPv2c and do not maintain engineIDs to use a > secure transport. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Nov 17 12:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7vH-0001vV-Bs; Fri, 17 Nov 2006 12:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7vF-0001ut-JV for isms@lists.ietf.org; Fri, 17 Nov 2006 12:54:42 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7v1-0002kX-Dm for isms@lists.ietf.org; Fri, 17 Nov 2006 12:54:41 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2006111717542201100rg4c6e>; Fri, 17 Nov 2006 17:54:22 +0000 From: "David Harrington" To: "'Balazs Lengyel'" , Subject: RE: [Isms] ISMS without support for notifications, is it useful? Date: Fri, 17 Nov 2006 12:51:44 -0500 Message-ID: <0f2701c70a71$0b984820$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.2962 In-reply-to: <455DB332.2090404@ericsson.com> Thread-Index: AccKSNYkeJX2ZU4aQbivUvmTwOBRhQAD8iHg X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Balazs, I think you misunderstand what was said at the ISMS meeting. Since I did the presentation, I apologize for not being clearer. Notifications are supported by ISMS. There are some wrinkles however to make the support different than the support provided by USM. 1) There may be some events that occur before the SSH session is created, especially if the creation of the session fails for some reason. Since SSH authentication may depend on a third party, such as a RADIUS server, to perform authentication, in a "broken" network it may be impossible to establish the session to send such notifications. USM has no third-party dependencies, so it does not face this problem. This is a corner case and would probably have very little impact on the day-to-day management of the network. One solution for this would be to have the snmp application choose to send the notification over USM if sending it over SSH fails. The necessary configuration of USM would involve provisioning one USM user (e.g. superuser) to send corner case notifications. 2) SNMPv3 usage (with USM) has been described with an implicit assumption that the same principals that perform request-response interactions would be the targets of notifications, and therefore one VACM entry for a principal suffices for both usages. This works because USM uses symmetric authentication - regardless of direction, the authentication is done for the same level of principal (e.g. user). SSH uses assymmetric authentication - the client side typically authenticates at a "user" level, while the server is authenticated at the host level. This is different than the implicit assumption of SNMPv3, and we need to decide if this is acceptable. 3) In reality the applications that receive notifications are frequently not the same applications that perform R/R processing. In practical terms what this means is that there are likely to be different entries in the authentication system and the access control system for the R/R applications and for the notifications application. It may be acceptable for the notification receiver to be authenticated at the host level, while the R/R application is authenticated at the "user" level, but we have not gotten any feedback from operators on this point. 4) If it is not acceptable to use asymmetric authentication, then we need to determine how to provide symmetric (or at least equivalent level) authentication. The apparently simplest way to reuse existing security mechanisms would be to have the agent open a connection as the client for notifications, and the manager open a connection as the client for R/R commands. However, since there is no operator at the agent to initiate communications and provide credentials, the agent would need to be provisioned with the credentials for the notification sender. That is considered undesirable. -- So ISMS is facing some problems regarding notifications, but ISMS has not given up applying SSH secure transport to notifications. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Friday, November 17, 2006 8:04 AM > To: isms@lists.ietf.org > Subject: [Isms] ISMS without support for notifications, is it useful? > > Hello All, > After participating in the Isms wg meeting in San Diego I > would like to make some comments > as a potential user of ISMS. Sorry if I misunderstand the situation. > > Isms is proceeding well with their work but only officially. > > In reallity ISMS gave up on applying their new security solution to > agent initiated traffic (notifications, traps). This means that for > these to be secured you still need USM security. But the whole Isms > started by hating USM, as it is too much work to configure. > > Alternatives: > 1) Forget the whole Isms as useless > 2) Use Isms for get, set type operations and use USM security for > notifications/traps. In this case we have 2 security models > to configure > instead of one, so SNMP security configuration got even more > complicated. > 3) Use Isms for get,set type of operations and do not secure > notifications. This assumes that notifications are inherently less > sensitive then get/set commands. While this might be true in > some cases > it is not generally accepted. We might still try to propose this > alternative to customers and have USM security as a backup. > > Personal opinion: push Isms to solve the problem of > notifications or forget > about Isms. > > Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Nov 17 13:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl85A-00075d-0d; Fri, 17 Nov 2006 13:04:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl859-00075Y-K0 for isms@lists.ietf.org; Fri, 17 Nov 2006 13:04:55 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl854-00049g-RL for isms@lists.ietf.org; Fri, 17 Nov 2006 13:04:55 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2006111718044601200or4oge>; Fri, 17 Nov 2006 18:04:46 +0000 From: "David Harrington" To: "'Balazs Lengyel'" , Subject: RE: [Isms] ISMS without support for notifications, is it useful? Date: Fri, 17 Nov 2006 13:02:08 -0500 Message-ID: <0f2901c70a72$7fd84d60$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.2962 In-reply-to: <455DB332.2090404@ericsson.com> Thread-Index: AccKSNYkeJX2ZU4aQbivUvmTwOBRhQAKOwEw 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 > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Friday, November 17, 2006 8:04 AM > To: isms@lists.ietf.org > Subject: [Isms] ISMS without support for notifications, is it useful? > > Personal opinion: push Isms to solve the problem of > notifications or forget > about Isms. > Hi Balzs, Just to make it very clear, if you know how to solve the problems we are facing with notifications, we welcome your input. 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 Mon Nov 20 03:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Fh-0004qz-S3; Mon, 20 Nov 2006 03:11:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Fg-0004ot-Hn for isms@lists.ietf.org; Mon, 20 Nov 2006 03:11:40 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm4FZ-0008Mw-RJ for isms@lists.ietf.org; Mon, 20 Nov 2006 03:11:40 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 206571A8; Mon, 20 Nov 2006 09:11:33 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 09:11:32 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 09:11:32 +0100 Message-ID: <456162F1.2010805@ericsson.com> Date: Mon, 20 Nov 2006 09:10:25 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: David Harrington Subject: Re: [Isms] ISMS without support for notifications, is it useful? References: <0f2701c70a71$0b984820$0600a8c0@china.huawei.com> In-Reply-To: <0f2701c70a71$0b984820$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 08:11:32.0712 (UTC) FILETIME=[7D5D3680:01C70C7B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: isms@lists.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 Thanks, for clarifying the question. Balazs David Harrington wrote: > Hi Balazs, > > I think you misunderstand what was said at the ISMS meeting. Since I > did the presentation, I apologize for not being clearer. > > Notifications are supported by ISMS. There are some wrinkles however > to make the support different than the support provided by USM. > > 1) There may be some events that occur before the SSH session is > created, especially if the creation of the session fails for some > reason. Since SSH authentication may depend on a third party, such as > a RADIUS server, to perform authentication, in a "broken" network it > may be impossible to establish the session to send such notifications. > USM has no third-party dependencies, so it does not face this problem. > This is a corner case and would probably have very little impact on > the day-to-day management of the network. > > One solution for this would be to have the snmp application choose to > send the notification over USM if sending it over SSH fails. > > The necessary configuration of USM would involve provisioning one USM > user (e.g. superuser) to send corner case notifications. > > 2) SNMPv3 usage (with USM) has been described with an implicit > assumption that the same principals that perform request-response > interactions would be the targets of notifications, and therefore one > VACM entry for a principal suffices for both usages. This works > because USM uses symmetric authentication - regardless of direction, > the authentication is done for the same level of principal (e.g. > user). > > SSH uses assymmetric authentication - the client side typically > authenticates at a "user" level, while the server is authenticated at > the host level. This is different than the implicit assumption of > SNMPv3, and we need to decide if this is acceptable. > > 3) In reality the applications that receive notifications are > frequently not the same applications that perform R/R processing. In > practical terms what this means is that there are likely to be > different entries in the authentication system and the access control > system for the R/R applications and for the notifications application. > > It may be acceptable for the notification receiver to be authenticated > at the host level, while the R/R application is authenticated at the > "user" level, but we have not gotten any feedback from operators on > this point. > > 4) If it is not acceptable to use asymmetric authentication, then we > need to determine how to provide symmetric (or at least equivalent > level) authentication. > > The apparently simplest way to reuse existing security mechanisms > would be to have the agent open a connection as the client for > notifications, and the manager open a connection as the client for R/R > commands. However, since there is no operator at the agent to initiate > communications and provide credentials, the agent would need to be > provisioned with the credentials for the notification sender. That is > considered undesirable. > > -- > So ISMS is facing some problems regarding notifications, but ISMS has > not given up applying SSH secure transport to notifications. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] >> Sent: Friday, November 17, 2006 8:04 AM >> To: isms@lists.ietf.org >> Subject: [Isms] ISMS without support for notifications, is it > useful? >> Hello All, >> After participating in the Isms wg meeting in San Diego I >> would like to make some comments >> as a potential user of ISMS. Sorry if I misunderstand the situation. >> >> Isms is proceeding well with their work but only officially. >> >> In reallity ISMS gave up on applying their new security solution to >> agent initiated traffic (notifications, traps). This means that for >> these to be secured you still need USM security. But the whole Isms >> started by hating USM, as it is too much work to configure. >> >> Alternatives: >> 1) Forget the whole Isms as useless >> 2) Use Isms for get, set type operations and use USM security for >> notifications/traps. In this case we have 2 security models >> to configure >> instead of one, so SNMP security configuration got even more >> complicated. >> 3) Use Isms for get,set type of operations and do not secure >> notifications. This assumes that notifications are inherently less >> sensitive then get/set commands. While this might be true in >> some cases >> it is not generally accepted. We might still try to propose this >> alternative to customers and have USM security as a backup. >> >> Personal opinion: push Isms to solve the problem of >> notifications or forget >> about Isms. >> >> Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> TSP System Manager >> ECN: 831 7320 Fax: +36 1 4377792 >> Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >> > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms