From isms-bounces@lists.ietf.org Thu Feb 01 16:08:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjAK-0000RD-8f; Thu, 01 Feb 2007 16:08:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjAJ-0000R8-8m for isms@ietf.org; Thu, 01 Feb 2007 16:08:19 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCjA6-0003nL-JD for isms@ietf.org; Thu, 01 Feb 2007 16:08:19 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020121080501300fr9bse>; Thu, 1 Feb 2007 21:08:05 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Juergen Quittek'" , References: Subject: RE: [Isms] working group last call on draft-ietf-isms-tmsm-05 Date: Thu, 1 Feb 2007 16:04:20 -0500 Message-ID: <0a1501c74644$8b81f9a0$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: Thread-index: AccgWnxKNhOsbavlRqaphYEEPQRAKASy9XgwBL9yX2A= X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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, Working on the next revision. Comments inline. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, January 08, 2007 8:18 AM > To: Juergen Quittek; isms@ietf.org > Subject: RE: [Isms] working group last call on draft-ietf-isms-tmsm-05 > > I read the document and I am fine with it. Detail level > comments follow > below. > > It is not clear to me how the document will progress relative to 3411 > and the full STD0062 package. I am not sure that the > resolution to this > question needs to be found in the text of the document though. Expect > questions and discussions in IETF LC and IESG review though. To be discussed. > > Detail level comments: > > 1. The readability of the document could be much improved if the > references to 3411 will be more exact, quoting the section where a > referred diagram, paragraph or statement quoted or reproduced here is > taken from. Fixed (although I am not convinced extended citations improve readability). > 2. I found many instances of inconsistent use of 2119 > conventions - some > examples may be found in 3.1.1, 3.2.2.2, 3.3.1 Addressed. The WG can decide if I distinguished usages accurately. > 3. I believe that Appendix B or some derivative of it includes useful > information about the rationale of some of the major design decisions > and I would suggest to keep it. > 4. If Appendix C remains with void content I would suggest to take it > out. Added an RFC editor note to remove it. > > Regards, > > Dan > > > > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > Sent: Friday, December 15, 2006 5:03 PM > > To: isms@ietf.org > > Subject: [Isms] working group last call on draft-ietf-isms-tmsm-05 > > > > Dear all, > > > > This is the working group last call on the "Transport > > Subsystem for the Simple Network Management Protocol (SNMP)" > > to be found at > > . > > > > The authors and the chairs think that this document is mature > > enough for last call. Since the holidays are coming, the > > last call period is not two weeks as usual, but three weeks. > > > > Please do review the document and post your comments on this > > list until January 8, 2007. Please also post to the list if > > you have read the document and are fine with it. It is very > > useful to know how many people have read the document. > > > > Thanks, > > > > Juergen Q. > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > > 6221 4342-115 > > NEC Europe Ltd., Network Laboratories Fax: +49 > > 6221 4342-155 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 01 16:44:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjj4-0004JR-T6; Thu, 01 Feb 2007 16:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjj3-0004Iw-67 for isms@ietf.org; Thu, 01 Feb 2007 16:44:13 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCjj0-000664-W8 for isms@ietf.org; Thu, 01 Feb 2007 16:44:13 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020121441001500745hle>; Thu, 1 Feb 2007 21:44:10 +0000 From: "David Harrington" To: "'Li Yan'" References: <001c01c733f0$81147e40$3b0c6f0a@china.huawei.com> Date: Thu, 1 Feb 2007 16:40:18 -0500 Message-ID: <0a1601c74649$93789a60$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: <001c01c733f0$81147e40$3b0c6f0a@china.huawei.com> Thread-index: Accz8IDIQ3QYq2HbQ3i8xJA5DppI5ASWFClA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org Subject: [Isms] RE: a small question 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 comments inline ________________________________ From: Li Yan [mailto:liyan_77@huawei.com] Sent: Tuesday, January 09, 2007 8:17 AM To: 'David Harrington' Subject: a small question Hi, Are David Harrington and Dave Harrington the same person? I speculate they are the same person, because I have never seen that Dave Harrington had sent comments to the mailing list. But in your draft-ietf-isms-tmsm, Dave Harrington appears in the Acknowledgments section. So I'm confused. fixed. BTW, I found two typo errors in the draft-ietf-isms-tmsm-05 3.2.1 motivstion 5.1 imatch fixed. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 01 17:35:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkWu-0004Fj-GR; Thu, 01 Feb 2007 17:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkWt-0004Fd-Dq for isms@ietf.org; Thu, 01 Feb 2007 17:35:43 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkWs-00009y-61 for isms@ietf.org; Thu, 01 Feb 2007 17:35:43 -0500 Received: from harrington73653 (failure[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007020122354101100ecd8ke>; Thu, 1 Feb 2007 22:35:41 +0000 From: "David Harrington" To: "'Nelson, David'" , References: <20070104074347.GB6362@noname> <3CFB564E055A594B82C4FE89D21565605A4A31@MABOSEVS2.ets.enterasys.com> Subject: RE: [Isms] working group last call on draft-ietf-isms-tmsm-05 Date: Thu, 1 Feb 2007 17:31:47 -0500 Message-ID: <0a1701c74650$c858a890$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: <3CFB564E055A594B82C4FE89D21565605A4A31@MABOSEVS2.ets.enterasys.com> Thread-index: Accv1By9+Yf+b5gSSBibVcj01ck1vADZpvMgBMJ/J+A= X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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, Working on the next revision. Comments inline. dbh > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, January 08, 2007 10:50 AM > To: isms@ietf.org > Subject: RE: [Isms] working group last call on draft-ietf-isms-tmsm-05 > > I have read this document and think that it's in pretty good shape. > Some specific comments follow: > > Document Header: > > Will this document update existing RFCs, e.g. 3411 or 3417? > There is no > "Updates:" field in the header. Added an "updates 3411,3412,3414,3417" This document changes ASIs used in 11,12,14; it changes the whole concept of transport mappings in 3417. > > Section 2. > > I would drop the metaphor of the "gun". The metaphor of the > "guard" is > fine without the resort to firearms. Just a "political correctness" > nit. Liberals! Fixed. > > I think it would help to further elaborate the relationship of this > document to RFC 3411 (Architecture) and 3417 (Transport Mappings). Can you provide text? > > Section 3.1.1 > > In the last sentence, since there are three alternatives > listed, I don't > think the correct wording is "either". Removed the whole clause. > > Section 3.2.1 > > Could paragraphs 3 - 6 be eliminated? This seems to be > reviewing design > issues/choices for SNMPv3 that one would assume to be documented > elsewhere. Done. > > In paragraph 8, motivation is spelled wrong. Fixed. > > Section 3.2.1.2 > > Typo in bullet item 2). Superfluous asterisk. Fixed. > > Section 3.2.3 > > In paragraph 6, "to have an security" should be "to have a security". Fixed. > > Section 4 > > This section indicates that the diagrams are incomplete. That would > seem to be a "comment magnet" in the absence of an explanation of why > the incompleteness of the diagrams does not impact the completeness of > the document. Added "This document defines the sendMessage() and recvMessage() ASIs for this purpose." > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 01 19:50:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmcq-0001nF-4p; Thu, 01 Feb 2007 19:50:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmcp-0001n5-1f for isms@ietf.org; Thu, 01 Feb 2007 19:49:59 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCmco-0005D4-D5 for isms@ietf.org; Thu, 01 Feb 2007 19:49:59 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007020200495701400q4alle>; Fri, 2 Feb 2007 00:49:57 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Subject: RE: [Isms] tmsm comments Date: Thu, 1 Feb 2007 19:46:11 -0500 Message-ID: <0a3301c74663$89508290$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: Thread-index: AccztfxmPZdWu4fASrS4Fnk53XwMHwSmrmIA X-Spam-Score: 0.0 (/) X-Scan-Signature: 182294e3fdac3aef093c0503b87ed133 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, Working on the next revision. Comments inline. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Tuesday, January 09, 2007 1:18 AM > To: isms@ietf.org > Subject: [Isms] tmsm comments > > > There was no timezone specified in the call for comments, so I'm going > to assume that midnight my time is appropriate. Thus, these are 1 > hour and 45 minutes early! > > > > > In general, I think the document is fine. I do have various comments > and one major objection and one major concern. > > The one marked with ***s I think is a show stopper. > > The one marked with ###s is a "bad thing" but I won't be obnoxious > about it. > > > > > Architecture of newly created "layer" not clearly spelled out > up front? > I guess I'd like to see the diagram in 3.2.1 higher in the doc. > > > > ----- > It is possible but > difficult to define external mechanisms that handle the > distribution > of keys for use by the USM approach. > > It's been done a number of times (the DH MIB proves it's possible and > has been used), but is still not the point... Bootstrapping USM was > not the issue operators wanted solved. They didn't want a coupled > or bootstrapable user base, they wanted a single one that wasn't > specific to SNMP. Does this cover it adequately? "USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate principal and key management infrastructure. Operators have reported that deploying another principal and key management infrastructure in order to use SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use external mechanisms to handle the distribution of keys for use by USM. The more important issue is that operators wanted to leverage a single user base that wasn't specific to SNMP." > > > > > ----- > From an operational perspective, it is highly desirable to use > security mechanisms that can unify the administrative security > management for SNMPv3, command line interfaces (CLIs) and other > management interfaces. The use of security services provided by > lower layers is the approach commonly used for the CLI, and is also > the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. > > This document describes a Transport Subsystem extension to the > RFC3411 architecture. > > > A transition sentence between those 2 paragraphs would be nice. Maybe > end the second one with: > > This document describes a Transport Subsystem extension to the RFC3411 > architecture. This extension specifies how other lower layer > protocols with common security infrastructures can be used underneath > the SNMP protocol and the desired goal of unified administrative > security can be met. > > [I just like saying "unified administrative security".] Done. > > > > ----- > > > +-------------------------------------------------------------------+ > | SNMP entity > | > | > | > | +-------------------------------------------------------------+ > | > ... > > That diagram needs an introduction to it. Like: > > The "Transport Subsystem" is defined in RFC3411 as a component of > the SNMP Engine. The following diagram depicts its place in the > SNMP architecture framework: done > > > > > > ----- > According to [RFC3411], it is not required to protect > against denial > of service or traffic analysis. > > Can we change it to: "it is not required to protect against denial of > service or traffic analysis, but it should not make those threats > significantly worse". > Done. > > > > > ----- > It has been a long-standing requirement that SNMP be able to work > when the network is unstable, to enable network troubleshooting and > repair. The UDP approach has been considered to meet that > need well, > with an assumption that getting small messages through, even if out > of order, is better than getting no messages through. > There has been > a long debate about whether UDP actually offers better support than > TCP when the underlying IP or lower layers are unstable. There has > been recent discussion of whether operators actually use SNMP to > troubleshoot and repair unstable networks. > > There has been discussion of ways SNMP could be extended to better > support management/monitoring needs when a network is running just > fine. Use of a TCP transport, for example, could enable larger > message sizes and more efficient table retrievals. > > These two paragraphs seem out of place? The text, though interesting > and potentially informative, don't connect with anything else nearby. > I suspect a point needs to be made after them along the lines of: > > "This document does not try to argue one way or another about which > protocols are better for use in which situations as there is very > little technical data upon which to draw conclusions from." I think removing the two paragraphs would be the best approach. > > > > > > ----- > Transport models MUST be able to coexist with other > transport models, > and may be designed to utilize either TCP or UDP or SCTP. > > Or any other future protocol layer? I removed the second part of the sentence, since it doesn't seem relevant after removing the two preceding paragraphs. > > > > ----- > IETF standards typically require one mandatory to > implement solution, > with the capability of adding new mechanisms in the > future. Part of > the motivstion of developing transport models is to develop support > for secure transport protocols, such as a transport model that > utilizes the Secure Shell protocol. Any transport model should > define one minimum-compliance security mechanism, preferably one > which is already widely used to secure the transport layer > protocol. > > > That last sentence is a bit odd. EG, if the UDP transport document > was written today would it state that USM is the mandatory to > implement security model for use if SNMP/UDP was implemented? It's > hard to tell what you're getting at here. Or would the SSH transport, > which you talk about below, specify that SSH is mandatory to > implement? Or would the SSH transport indicate that a particular > set of auth/priv algs be mandatory? Not sure which level of > requirement you're talking about ("security mechanism" is vague). This is about having a mandatory-to-implement security mechanism for the transport model, e.g. certificates, to ensure a basic level of interoperability. If SNMP/UDP I streated as a transport model, then USM would be the mandatory-to-implement security mechanism. Suggested text welcome. I think the text should talk about algorithm agility and a mandatory-to-implement for interoperability. I modified the text somewhat, but would welcome other suggested text. Here's my attempt: "IETF standards typically require one mandatory to implement solution, with the capability of adding new mechanisms in the future. Part of the motivation of developing transport models is to develop support for secure transport protocols, such as a transport model that utilizes the Secure Shell protocol. Any transport model SHOULD define one minimum-compliance security mechanism, such as certificates, to ensure a basic level of interoperability, but should also be able to support additional existing and new mechanisms." > > > > > ----- > The RFC3411 architecture,and the USM assume that a > security model is > ^ > needs space > > > > > ----- > To accommodate this, the ASIs > for the transport subsystem, the messaging subsystem, and the > security subsystem will be extended to pass security-model- > independent values, and a cache of transport-specific information. > > Based on the above text, the following diagram seems out of place. > Add another paragraph stating: > > The following diagram depicts the complete SNMPv3 architecture > including the Transport Subsystem defined in this document: > > > Then the diagram also has "*"s under the MP and Security subsystems. > Not sure why? They're not talked about. Artifacts from RFC3411. Removed. > > > > > > ----- > 3.2.1.1. USM and the RFC3411 Architecture > > The following diagrams illustrate the difference in the security > ^^^^^^^^ > processing done by the USM model and the security processing > potentially done by a transport model. > > there isn't any "following diagrams". Maybe you mean "lists" > Actually, that paragraph may be long in the 3.2.1 section > heading instead? Changed and moved > > > > > ----- > 3.2.1.1 - 3.2.1.3: new lines are needed before the first numbered > bullet in each of these sections. > I will investigate whether xml2rfc allows me to do this. > > > > ----- > A secure transport model will establish an encrypted tunnel between > the transport models of two SNMP engines. One transport model > instance encrypts all messages, and the other transport model > instance decrypts the messages. > > -> "...will establish an authenticated and/or encrypted > tunnel between..." > (encryption isn't required) Done. > > And the last sentence should be deleted. It implies unidirectional > and it's not really needed so I'd delete instead of fixing it. Done. > > > I'd be tempted to use "session" instead of tunnel. Only because many > people read "tunnel" and think "encryption" (though tunnels can be > authenticating only) I tend to envision this as a type of "pipe"; I think tunnel is consistent with a pipe; session is not. I'll leave this as is until we have consensus to change the wording. Suggested text welcome. > > > > > > > ----- > 3.2.2.1. securityName Binding > > For SNMP access control to function properly, security processing > must establish a securityModel identifier, a securityLevel, and a > securityName, which is the security model independent > identifier for > a principal. The message processing subsystem relies on a security > model, such as USM, to play a role in security that goes beyond > protecting the message - it provides a mapping between the USM- > specific principal to a security-model independent > securityName which > can be used for subsequent processing, such as for access control. > > Can we remove USM from that paragraph? The first is probably fine as > an example, but the second should be replaced with "Security Model". > Done. > > > > > ----- > For outgoing messages, even when a secure transport model will > provide the security services, it is necessary to have an security > model because it is the security model that actually creates the > message from its component parts. Whether there are any security > services provided by the security model for an outgoing message is > model-dependent. > > Shouldn't it be mentioned that care MUST be taken to ensure that a > SNMP engine is sending packets out over a transport using credentials > that are legal for that engine to use on behalf of that user? I worry > about the case where an engine has multiple transports open and is > "tricked" into sending a message through the wrong transport. > > > > > ----- > > ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### > ### ### ### > It is important to note that the architecture described in > [RFC3411] > does not include a session selector in the Abstract Service > Interfaces, and neither is that done for the transport > subsystem, so > an SNMP application cannot select the session except by passing a > unique combination of transport type, transport address, > securityName, securityModel, and securityLevel. > > PLEASE don't talk about how restricted the architecture is due to the > parameters the ASI have available to them. The SNMPv3 working group > fought this battle over whether or not to include them and decided > that parameters should be include but are not binding and shouldn't be > treated as an API or a fixed list of things to pass around. Your > statement above only solidifies the "bad" aspects of the ASIs. > You can continue to provide the list of what an application must > provide to the lower layer systems, but please don't say "so an SNMP > application cannot..." because it can if it treats the ASIs as they > were intended. > ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### > ### ### ### I understand and agree with your concern. I am not sure how to modify the wording to meet your request. This is after all an architecture extension document, so we cannot just say ignore the ASIs. Would the following suffice? "The architecture described in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for the transport subsystem, so an SNMP application has no mechanism to select a session using the ASIs except by passing a unique combination of transport type, transport address, securityName, securityModel, and securityLevel. Implementers, of course, might provide non-standard mechanisms to select sessions." > > > > > > ----- > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > *** *** *** > Responses are expected to > be returned using the same session that carried the corresponding > request message. Reuse of sessions is not required for > conformance. > > Um... IMHO, this should be a MUST. There are security implications > if you send a response over a different session than the request came > in over. Different sessions may use different cryptographic > properties > (algorithms, etc). Plus, once you start doing that you can actually > play with the timing of messages as they arrive at the other end by > slowing one session down and not the other, etc. > > This, IMHO, is critical that responses go back on the same session. > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > *** *** *** > I have had feedback from others that they do not want this restriction at the subsystem level, but at the model level. I think it makes sense to use the same session for both security and complexity reasons. I think we need to establish WG consensus on this point. > > > > > ----- > If each session uses new session keys, then messages > cannot be replayed from one session to another. > > Can you be more specific about what you're trying to say > there? Does > that mean that if I have a GET operation that tries one session and > fails to get a response I have to do what exactly before I'm allowed > to resend it on another session? is changing the message ID > sufficient? > > This is actually a good thing, don't get me wrong, I'm just trying to > understand it. Cryptographically resending the exact same message in > another session under a different key does provide some extra > comparison information to an attacker. But the text doesn't really > state the real goals and requirements here. [though SNMP messages > already suffer from fairly regular bytes that fall into the block size > of the algorithms being used so I'm not sure you're actually > protecting against that much analysis by blocking a resend] Copied text from Jeff's response to your question. > > > > ----- > SNMPv3 was designed to support multiple levels of security, > selectable on a per-message basis by an SNMP application, because > there is not much value in using encryption for a > Commander Generator > to poll for non-sensitive performance data on thousands of > interfaces > ^ > ^ > add "potentially" Done. > > > > > > ----- > 4.2. Command Responder > > This diagram shows how a Command Responder or Notification Receiver > application registers for handling a pduType, how a PDU is > dispatched > to the application after an SNMP message is received, and how the > Response is (asynchronously) send back to the network. > > Is this the diagram that was changed (4.1 says it was taken from the > other, so I'm assuming it was this one)? If so then you should state > how it was changed. These two diagrams are unchanged from RFC3411. I do not have new scenario diagrams. I am not certain new scenario diagrams would be useful here because the path back from Security Model through Messgaing Model through the dispatcher to the transport subsystem's sendMessage() ASI adds a lot of empty lines that don't show much of anything, but complicate the diagram. > > > > > > > > ----- > 5.2. tmStateReference > > For each message or transport session, information about > the message > security is stored in a cache, which may inlcude model- and > ^^^^^^^ > [I didn't do a spell check and generally don't consider myself worthy > to point out grammar issues, but this jumped out at me :-] Fixed. > > > > > ----- > and if state > information is available when a session is closed, the > session state > information should also be released. > > Unless the management system indicates that the state should remain > around for a longer period of time to allow for data collection about > the session to occur. See David Perkins for details. I can understand the desire to have session info last longer than the session, but the state info (in the LCD) is used to determine if a session exists, so keeping it around in the LCD might be problematic, unless it is somehow marked as expired. Since we are not writing a MIB to represent this, I am not sure how we want to address the implications of this issue here. Text welcome. > > > > > > > > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > 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 Feb 02 20:18:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD9YA-00045U-9C; Fri, 02 Feb 2007 20:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD9Y9-00044u-CY for isms@ietf.org; Fri, 02 Feb 2007 20:18:41 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD9Y6-0003xe-8P for isms@ietf.org; Fri, 02 Feb 2007 20:18: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 <2007020301183601100f2b3qe>; Sat, 3 Feb 2007 01:18:36 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: Subject: RE: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 Date: Fri, 2 Feb 2007 20:14:48 -0500 Message-ID: <0b3901c74730$b2b86620$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: Thread-index: Acc2aKjqD7lBolk9SnKcZYgyHC7TnwP/CHBw X-Spam-Score: 0.0 (/) X-Scan-Signature: b93a18b5a0786c0dec11cfcc0bd974cf 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 Comments inline. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Friday, January 12, 2007 11:43 AM > To: isms@ietf.org > Subject: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 > > I have read and reviewd this document. Here are my comments. > > First Kudo's to the authors/editors. Pretty good work. > Although have quite a set of comments/questions, I think > the document is in pretty good shape. > > But probably based on my (and other) comments (I have seen) > one more rev may make sense. > > - I am completely confused by 3rd para of sect 3.2.1 > > In SNMPv2, there were many problems of side effects between > subsystems caused by the manipulation of MIB objects, especially > those related to authentication and authorization, because many of > the parameters were stored in shared MIB objects, and different > models and protocols could assign different values to the objects. > Contributors assumed slightly different shades of meaning depending > on the models and protocols being used. As the shared MIB module > design was modified to accommodate a specific model, other models > which used the same MIB objects would be broken. > > I wonder: > - which SNMPv2 do you mean? SNMPv2c ?? Something else? > maybe you can use a citation/reference > - I have no idea which MIB objects you are talking about, > so I cannot > judege if anything was broken andd if so why/how. > - What are you rtying to convey or justifty in this para? > - is it needed at all? Removed. > > - I am also somehwta confusd by the next para (4th para in > sect 3.2.1): > > Abstract Service Interfaces (ASIs) were developed to pass model- > independent parameters. The models were required to translate from > their model-dependent formats into a model-independent format, > defined using model-independent semantics, which would not impact > other models. > > It probably has to do with the English here that seems pretty weird > to me (but then, my native tongue is not English). Removed. > > - IN sect 3.2.1 on page 8: > > Parameters have been provided in the ASIs to pass model-independent > information about the authentication that has been provided. These > parameters include a model-independent identifier of the security > "principal", the security model used to perform the authentication, > and which SNMP-specific security features were applied to > the message > (authentication and/or privacy). > > Do we leave it up to the reader to connect/link the various phrases > into securityName, securityModel and securityLevel? Why are we not > very clear and name the things as we have named them in 3411? Removed the paragraph. > > - Further in section 3.2.1, page 8: > > Parameters have been provided in the ASIs to pass model-independent > transport address information. These parameters utilize the > transportDomain and transportAddress > > Is that last sentence not finished? > And is it causing confusion? I wonder if this has any relation to > the TransPortDomain/TransportAddress TCs in RFC3419. I think not. > I think you are just saying that the model-independent parameters > transportDomain and transportAddress (as used in RFc3411) are used. Removed the sentence. > > - The figure on page 9, when I compare it with the figure on page 24 > of RFc3411, makes me wonder: > > Are we completely doing away with RFC3417 ?? > > I guess we're not completely doing away with it are we? > Maybe I'll find it further down in the document, but I fnot, we may > need some words about that. I don't know what WG consensus is on this issue. It has not been discussed. I assume the transport mappings in RFC3417 can be treated as transport models, but we might want to do an actual update at some point. > > - 2nd para in sect 3.2.2.1 , my comments inline > > The securityName MUST be bound to the mechanism-specific > > s/bound to/mapped from/ ?? is it really binding it or is it mapping? Done. > > authenticated identity, and this mapping MUST be done for incoming > messages before the security model passes securityName to the > message > processing model via the processIncoming() ASI. This translation > from a mechanism-specific authenticated identity to a securityName > MAY be done by the transport model, and the securityname is then > > s/securityname/securityName/ Fixed. > > provided to the security model to be passed to the message > processing > model. > > So I think it is passed via the tmStateReference, no? > If so would it be usefull to say so? Or do we prefer to leave it > vague? Done. > > - last para of sect 3.2.2.1 > > If the type of authentication provided by the transport > layer (e.g. > TLS) is considered adequate to secure and/or encrypt the message, > but > inadequate to provide the desired granularity of access control > (e.g. > user-based), then a second authentication (e.g., one > provided via a > RADIUS server) MAY be used to provide the authentication identity > which is bound to the securityName. This approach would require a > good analysis of the potential for man-in-the-middle attacks or > masquerade possibilities. > > It does not say anything about at what point in the process > steps this > mapping from RADIUS authenticated identity to a securityName needs > to take place. Maybe we want to leave that open. But it seems to me > that the least we can say is that: it MUST bde done for incoming > messages before the security model passes securityName to > the message > processing model via the processIncoming() ASI. I'm not sure that's true. If the goal is to get the identity for access control, it really only needs to get the securityname before it provides access control. If, for example, it uses RADIUS and does an authentication of the user and gets the authorization data, it could do this as part of the access control model. it doesn't need to be bound to the securityModel of the message, does it? I haven't spent time to consider the security implications of this, but I don't think we need to force this to be done a particular way. Of course, we do want to make sure the sender of the message is authorized to use the credentials that will authenticate the RADIUS request. > > - sect 3.2.2.2. starts with: > > A transport model that provides security services should take care > to > not violate the separation of authentication and authorization in > the > RFC3411 architecture. The isAccessAllowed() primitive is used for > passing security-model independent parameters between the > subsystems > of the architecture. > > That last sentence seems to put a big claim there. It is only ONE of > the primitives (ASIs) for passing (xxx-model) independent > parameters. > I might word it as: > > RFC3411 architecture. The isAccessAllowed() primitive is used for > passing security-model independent parameters to an Access Control > Model (like VACM) and passes Security Model independent parameters > for the Access Control Model to use. done > > - Next para in sect 3.2.2.2 states: > > Mapping of (securityModel, securityName) to an access > control policy > > I think I would add securityLevel in there as well. It is clearly > included > in the decision process (as per figure in sect 3.1 of RFC3415) and > is also security model related (some may not be able to do > a specific > level, like SNMPv1 over UDP cannot do authNoPriv or authPriv). > I see that you later state that some Access Control Models > (well your > wording uses inconsistent terms from RFC3411, but anyway) MAY need > a securityLevel. So maybe that is why you left it out here, but > certainly, it is a required parameter on the isAccessAllowed(). Added securitylevel. > > - To come back to terminology in sect 3.2.2.2. It states: > > An authorization model (in the access control subsystem) > MAY require > authentication by certain securityModels and a minimum > securityLevel > to allow access to the data. > > Mmm.. so now we also have an "authorization model" ?? > I guess you do mean the Access Control Model (in the Access Control > Subsystem) ?? Fixed. > > - sect 3.2.2.2 > > Transport models that provide secure transport are an enhancement > for > the SNMPv3 privacy and authentication, but they are not a > significant > improvement for the authorization (access control) needs > of SNMPv3. > > Are they an "enhancement"? Or are they an "addition" ?? > I would say the latter. >From Mirriam-Webster: "to increase or improve in value, quality, desirability, or attractiveness" Operators have complained that USM requires them to use yet another user and key infrastructure and they want a solution that leverages existing user and key infrastructures. The goal of ISMS is to provide a solution that is more attractive to operators. So I think this is an enhancement. I wouldn't like to think I have spent all this time editing these documents to provide just an additional solution that was not an enhancement over what is already available. ;-) > > Also, the are an addition for "SNMP message privacy...". > You can also > enhance SNMPv1 and SNMPv2c privacy with it. > Further, I believe that USM can also be used for as possible SNMPv4, > and so again I do not see why you think it is SNMPv3 > privacy specific. > or SNMPv3 specific w.r.t. aithorization. You are making the assumption SNMPv3 refers to a message format here. I was making the assumption SNMPv3 referred to the standard. This is one of the disadvantages of using "SNMPv3" in multiple ways. I'll try to make this less ambiguous by making it explicitly refer to messaging. > > - sect 3.2.2.2 > > A transport model must not specify how the securityModel and > securityName could be dynamically mapped to an access control > mechanism, such as a VACM-style groupName. The mapping of > (securityModel, securityName) to a groupName is a VACM-specific > mechanism for naming an access control policy, and for tying the > named policy to the addressing capabilities of the data modeling > language (e.g. SMIv2 [RFC2578]), the operations supported, and > other > factors. Providing a binding outside the Access Control subsystem > > I learn new things everyday. Hopefully I can leanr something new > again. > What is/are: > > the addressing capabilities of the data modeling language (e.g. > SMIv2 > > Am I the only one who is confused by that? I changed it since you found it confusing. > > And a few lines further: > > or Windows domains. The preferred approach is to pass the model- > independent security parameters via the isAccessAllowed() ASI, and > perform the mapping from the model-independent security parameters > to > an authorization-model-dependent access policy within the access > control model. > > Why is this not the RECOMMENDED approach? > We did the architectural modularization with a purpose did we not. > SO I would be strong and say RECOMMENDED instead of "preferred" Fixed. > > Pls also change "authorization-model-dependent" into "Access Control > Model dependent" Done. > > - sect 3.2.3, 5th para on page 13 states: > > When using a secure transport model, security parameters MAY be > provided through means other than carrying them in the > SNMP message. > The parameters MAY be provided by SNMP applications for outgoing > messages, and the parameters for incoming messages MAY be > extracted > from the transport layer by the transport model before the message > is > passed to the message processing subsystem. > > I am somehwat confused by the 2nd sentence. > I thought that for an outgoing message the SNMP appas MUST provide > the required security parameters. Possibly you mean that in > cases like > a response they get picked up from the cached parameters of the > incoming request (to which is being responded), but I find the > capitalzied > MAY confusing. It seems to say that for example a Comamnd Generator > can choose to NOT pass any security parameters and would still be > compliant? I am confused. I removed the first part of the second sentence. > > - section 3.3 and onwards talks about a "transport type" and > "transport > address". Is that intentionally deviating from transportDomain and > transportAddress as used earlier in the document? I.e. the > paramaters > being passed in the ASIs? Changed to match the parameters > > - last para of sect 3.3.1 (page 15/16) states: > > If a session can be reused for a different type of message, but a > receiver is not prepared to accept different message > types over the > same session, then the message MAY be dropped by the > receiver. This > may strongly affect the usefulness of session reuse, and transport > models should define a standard behavior for this circumstance. > > Mmm... "type of message" ? I only see this term occur once > in RFC3411. > It basically is the PDU type. But OK, I can live with it. > I am worried about the fact that "a transport model needs to define > standard behaviour for this". How/where does a transport model > know about the message type (or PDU type) ?? The pduType is passed > between Dispatcher and MP model (in the ASIs), but I do not see it > passed from the dispatcher to transport subsystem. Is the TM > suppsoed to go dig into the PDU itself? I hope not. Hmmm. I'm not sure how a transport model knows this. I am not a fan of session reuse, so my heart won't be broken if we simply drop this whole thing, and the transport model finds the right session by its transport address (e.g., port 161 or 162). I'll add this to the open issues section. > > - In your sect 4.2, I would add that the diagram is from RFC3411. > Oteghrwise people might think there was/is a change. Done. > > - In sect 4. You state that some info is missing in 4.6.1. > and 4.6.2 in > 3411. > You then show (repeat) the diagrams from 4.6.1. and 4.6.2 in your > sections 4.1. and 4.2. > But no further diagram extension to "complete" them? > I am missing the purpose of this? Is that just me? > I had expected the completed diagram, no? > For example I had expected to see the sendMessage and recvMessage > in a renewed diagram. > > (By the way, why no use "receiveMessage" instead of "recvMessage"? > we have many long ASI names already, and I hate all these > abbreviation for no reason). I am OK with that change. Done. > > > - I am not 100% sure, but is it correct that section 5.1. about the > securityStateReference is not adding any new (or changing any > existing) information compared to RFC3411? > If so, I would prefer we state that explicitly. > If it does add something, pls make it clear what is being > added/changed. This is not defined, but it may include additional security parameters related to the transport model. > > - Section 5.2 > I think (but it is not clear) that the transport model should save > a mapping from transport security/authentication ID to seucirtyName > so the the Security Model can pick it up and pass it back as an > OUT parameter on the processIncomingMessage ASI,. no? Yes, this information should be saved in one of the caches. The format and contents of the caches are implementation-specific however, so I don't know what information we can discuss. The transport model might also need to know the authentication algorithm, the integity-checking and encryption parameters, and so on. These are very much transport-model specific. The way we deal with it is to provide two caches - one for the request/response pair, and another for the session-like mechanism. It is up to the implementer to decide what goes where. Added to Open Issues for discussion. > > - 6.2. Processing for an Outgoing Message > > The sendMessage ASI is used to pass a message from the > Dispatcher to > the appropriate transport model for sending. > > statusInformation = > sendMessage( > IN destTransportDomain -- transport domain to be used > IN destTransportAddress -- transport address to be used > IN outgoingMessage -- the message to send > IN outgoingMessageLength -- its length > IN tmStateReference -- reference to transport state > ) > > Would it be usefull to add a not that the tmStateReference is not > always filled out? Let us say that I have just started my SNMP > manager, > now I am going to send my first SNMP GET Request. I would use above > ASI (I think). But what is the content of tmStateRefrence here? > Will it be filled upon return? I added some text about this. Good catch. > > I can see that when I want to call sendMEssage to send a > response that > the tmStateRefrence contains the info that came in on the request. Yup. > > - 6.3.1. Processing an Incoming Message > > Is there any difference for an incoming response compared to a > incoming request? Not clear to me. Not until you hit the message processing model, I think. The MPM keeps track of outstanding requests to match up to the response. > > - 7. Security Considerations > > This document describes an architectural approach that would permit > > I would: s/would permit/permits/ > > - I am not sure I understand why RFC2578 needs to be a normative > reference There used to be a mib here. Now we don't cite 2578 at all. Removed. > > - I have not checked appendix A > > - Appendix B says: > This appendix considers why a cache-based approach was > selected for > passing parameters. This section may be removed from subsequent > revisions of the document. > > I recommend to keep this appendix. It will/may help us > remember (in 5 > or 10 years from now) why we did this. So remove the 2nd sentence. Done. > > - I guess Appendix C will get removed ;-) Once we resolve all open issues. > > > NITS: > > - page 4: > > the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. > > change citation to [RFC4741] > I know you could not know the RFCnumber when rev 5 was done. > But if you do an update, then pls include this. Done. > > - Sect 3.1 > Is there a good reason to list the threaths in a different order > as is done in RFC3414 page 5? > Mmm... I see they are in the same order as in RFC3411 pages 6/7. > So ignore my rambling. > > - Section 3.2.1 > Mmm.. the terminology used looks similar, but not the same as > in RFC3411. And I wonder if it would not be better to use the > same terms. I would also use same capitlized words. In fact > you do use the RFC3411 terms in the figure on page 5. > > TMSM RFC3411 > messaging subsystem Message Processing Subsystem > application subsystem Application(s) > access control subsystem Access Control Subsystem > > I would also change "transport subsystem" to Transport Subsystem" > just for consistency in capitalization. In fact in the > figure, and in > some other places you already do so. > > - In section 3.2.1.1 I see a few cases of tautologie > - USM model (USM = User-based Security Model) > - USM security model Fixed. > > - Further in sect 3.1.1, my comments inlined in a copy of the text: > > 3.2.1.1. USM and the RFC3411 Architecture > > The following diagrams illustrate the difference in the security > > mmm.. where are thos diagrams? Is a diagram not a drawing/figure or > some such? > or ist it just text? Fixed. > > processing done by the USM model and the security processing > potentially done by a transport model. > > The USM security model is encapsulated by the messaging model, > because the messaging model needs to perform the following steps > (for > > I wonder if the "because" is correct. In any event, the > list below has > many things in it that have nothing to do with the fact that the > USM is encapsulated in the Message Processing Model (not that I use > the RFC3411 term) > Modified the text. Let me point out that the encapsulation has a significant impact. With USM, you cannot provide the security functionality until after the MPM has decoded some of the ASN.1 to determine the values in the message header; the transport model approach doesn't require ASN.1 decoding before it can provide most of the security functionality. The purpose is to show that the order of the processing is different, and different subsystems have responsibilities for certain functions of the flow through an SNMP engine when using USM vs using a transport security model. > incoming messages) > 1) decode the ASN.1 (messaging model) > > I would change that in "determine the Message Processing Model" > now it sounds as if it is completely doing the ASN.1 decoding before > it calls USM. It only partially does that. Agreed. I was going for a simple bullet rather than complete accuracy here. This is meant to be a simple bullet list that shows the abstract processing steps, and with a 69-column limit, it is hard to keep things readable if I have to spell out every little detail and every little conditional related to every abstract bullet. The detailed specification of processing steps, with all the details and conditionals, is documented elsewhere. > > 2) determine the SNMP security model and parameters (messaging > model) > 3) decrypt the encrypted portions of the message (security model) > 4) translate parameters to model-independent parameters (security > model) > > this step is completely inside Security Model, no? > in fact step 3,4,5 are all just one call from the Message Processing > Model to the Security Model, namely the processIncomingMsg ASI (Sect > 4.4.2 in 3411) They are not all completely inside the security model when using a secure transport. Some of these specific steps happen in a different order and in different subsystems, depending on whether you are using USM or a secure transport. > > 5) determine which application should get the decrypted portions > (messaging model), and > > This is done outside of the Message Processing Model (even in the > figure on page 9 of tmsm document) namely it is "PDU Dispatch" > in the "Dispatcher" The registration uses message-model-specific pduTypes. For incoming messages, the MPM determines what pduType is contained in the message, then the dispatcher matches it up to the registrations. Modified this step to read "determine the pduType in the decrypted portions (message processing model)". > > 6) pass on the decrypted portions with model-independent > parameters. > > The USM approach uses SNMP-specific message security and > parameters. > > Not 100% sure what that last sentence means. Probably you mean to > tell us that an SNMPv3 message does have a USM specific set of > security parameters. Yes; I am trying to describe the differences between USM and secure transport. I rewrote the section to try to clarify this. > The SNMPv3 message format is > specified in RFC3412 and indeed for has reserved/allocated a space > for ALL Security Model to pass Security Model specific parameters. > From RFC3412: > > -- security model-specific parameters > -- format defined by Security Model > msgSecurityParameters OCTET STRING, > > If some Security Model does not need it, then it can be the > zero-length OCTET STRING. This is immaterial to the point. > > - In sect 3.2.1.2, snippets of the text with my comments inline: > > 2*) translate parameters to model-independent parameters > (transport > model) > > Does that asterisk have special meaning? Or is it just a typo. > I guess the latter. Carryover from RFC3411; removed. > > > 3) determine the SNMP security model and parameters (transport > model) > > Mmm... is that determined by the TM at the receiving end? > Is it then filled in in the SNMPv3 message? Or is it > checked against > what is in there already? Originally, the TM was going to determine the SM, but we changed our minds on that point. Now it is taken from the message. I modified the text. > > If a message is secured using non-SNMP-specific message > security and > parameters, then the transport model should provide the > translation > from the authenticated identity (e.g., an SSH user name) to the > securityName in step 3. > > Mmm... I think I would reword into: > > If a message is secured using secure transport layer, then the > related > transport model should provide the translation from the > authenticated > identity (e.g., an SSH user name) to the securityName in step 3. > > after all, "non-SNMP-specific message security" could also be > something > that has nothing to do with the transport layer (I have no idea what > yet) > and so it would be strange to mandate that e TM would have > to fill our > parameters, no? Fixed. > > But aside from that, I wonder if/how this works. > once we move from the Transport Model to the Dispatcher, then the > Dispatcher calls the Message Processinge Model via > prepareDataElements > ASI. That ASI has an OUT parameter for securityName. So what will > happen if we have filled out the securityName in step 3? The TM determines the securityName and securityLevel, and puts them into the cache. The dispatcher calls the MPM, which calls the appropriate security model. The security model extracts securityName and securityLevel from the message securityParameter block (USM), or the message header/MIB module (Community), or from the tmStateReference cache (TSM), and passes them to the MPM to report in the OUT parameter. > > I guess, we want the Transport Model to map these > transport-layer-security > parameters into model-independent security parameters, save them in > the > tmStateReference and then later, when the Message Processing Model > calls > the Transport Security Model, they get filled in into the > securityName > (and other parameters). Assuming that I correctly > understand how these > transport layer security parameters get mapped, saved and > then passed > around, I think the steps in sect 3.2.1.2 may rather confuse people. > If I completely mis-understand it, then I there are > inconsistencies in > your document, because in sect 6.1 on page 23, you state > > The OUT parameters of the prepareOutgoingMessage() ASI are used to > pass information from the message processing model to the > dispatcher > and on to the transport model: > > And in the ASI on page 22, the securityName is still listed (as I > expected by the way) as an OUT parameter. Hopefully the new text will be clearer. > > - In sections 3.2.1, 3.2.1.1 and 3.2.1.2 you explain the > agent-side and > the process steps (and the order of those steps) for an incoming > message. I can easily see how to map the manager side for > the picture. > I wonder if it makes sense to check if we need to say anything about > sending a (i.e. an outgoing) message? The sequence of steps there > is also different. Can people easily determine that based on these > 3 sections? This is just an overview of which subsystems have which responsibilities, and the general flow of processing; it is not the detailed elements of procedure. An outgoing message would probably just reverse the order, unless you get into all the detailed elements of procedure, where there are lots of conditional flows depending on the PDUtype (trap vs inform vs request vs response). If we try to document all the various possibilities here, you won't be able to see the forest because the trees will be in the way. > > - Maybe it is my skill in English, but in sect 3.2.1.3, > I would change > > After a transport layer tunnel is established, then SNMP messages > can > conceptually be sent through the tunnel from one SNMP engine to > another SNMP engine. Once the tunnel is established, > multiple SNMP > > into: > > After a transport layer tunnel is established, then SNMP messages > can > be sent through the tunnel from one SNMP engine to the other SNMP > engine. Once the tunnel is established, multiple SNMP > > I am not sure if the word "conceptually" is needed/useful. > What do you > try to convey? For me, they can just be sent, no? This would have been better as "After a conceptual transport layer tunnel is established," since not all transport supports "tunnels" as such. But I can live without the "conceptual" being there at all. > Also, toy cannot send the messages to just "another", but just to > one, namely the one you are conne3cted to, other engine. > > Further, I would change: > > another SNMP engine. Once the tunnel is established, > multiple SNMP > messages may be able to be passed through the same tunnel. > > into > > another SNMP engine. Once the tunnel is established, > multiple SNMP > messages can be passed through the same tunnel. > > it is shorter, but also, the meaning is somewhat different > and clearer > I think (at least in my ear). This might be transport-specific (think UDP as a transport model). "Transport models MAY support sending multiple SNMP messages through the same tunnel." > > - sect 3.2.2.2 > > RFC3411 architecture. The isAccessAllowed() primitive is used for > > Why is this now a "primitive" and while it is an ASI in the 4th para > on page 12: > > independent security parameters via the isAccessAllowed() ASI, and > > Pls try to be consistent. I see however that we did this also > on RFC341x document. SO feel free to ignore this one if you like. > I changed them to ASI for consistency. > - I think the first MAY on page 14 could be lower case, or maybe > even better could be replcaed by "can". > The capitalized MAY/MUST/SHOULD and such are for compliance > information. I don't think that is the situation here, is it? Fixed. > > - I also see no reason for a capitalized MAY in the last para on page > 15. This one does affect on-the-wire interoperability, so I think a MAY is justified. An implementation would not be non-compliant because it does this (i.e., it is "legal" for an implementation to do this.) > > - Last para in sect 3.3.3 > > I think the first capitalized MAY would better be a lower case may. Changed to "might" > > TYPOs: > > - page 6, sect 3.1 > Using a protocol in a manner for which it was not designed has > numerous problems. The advertised security characteristics of a > protocol may depend on its being used as designed; when > used in other > > in last line: s/its/it/ ?? Fixed. > > - 3rd para page 8: > The design of a transport subsystem must abide the goals of the > RFC3411 architecture defined in [RFC3411]. To that end, this > transport subsystem proposal uses a modular design that will permit > > s/abide/abide by/ ?? Either is valid. According to Merriam-Webster: 3 : to accept without objection - abide by 1 : to conform to 2 : to acquiesce in Changed to "accepts the goals". > > s/RFC3411 architecture/SNMP architecture/ ?? > I can live with RFC3411 architecture though. I see it comes back > several > times. I find it strange though to name an architecure > after an RFC > number. Remember that RFC3411 is "An Architecture", not "The Architecture". I try to not to refer to this as the "SNMP architecture", unless I qualify it as the "SNMP Architecture described in RFC3411", even though it is unwieldy. I usually just say the RFC3411 architecture. > > s/proposal// -- by the time this is an RFC it is no longer a > proposal is it? Fixed. > > - 4 para on page 8 > the motivstion of developing transport models is to develop support > > s/motivstion/motivation/ Fixed. > > - last para page 8 > The RFC3411 architecture,and the USM assume that a security model is > called by a message-processing model and will perform multiple > > s/,and/, and/ > s/message-processing model/Message Processing Model/ > I hope you get the gist here on consistency of > terms/terminology. I get the gist; I hate all the capitals in the middle of the sentences. I changed them to meet your request, but I think the document looks awful as a result. "This document describes a cache, into which the Transport Model puts information about the security applied to an incoming message, and a Security Model can extract that information from the cache. Given that there might be multiple TM-security caches, a tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem and the Security Subsystem, so the Security Model knows which cache of information to consult." Is the following any less clear? I think it is better English. This document describes a cache, into which the transport model puts information about the security applied to an incoming message, and a security model can extract that information from the cache. Given that there might be multiple TM-security caches, a tmStateReference is passed as an extra parameter in the ASIs between the transport subsystem and the security subsystem, so the security model knows which cache of information to consult." I think "messaging model" is just as clear as "Message Processing Model". One way just makes it more verbose, and harder to fit things into 69-column lines. But I did it your way. > > I think I would also do s/USM/Security Subsystem/ Fixed. > > - section 4.4. > Some secure transports may have a notion of sessions, while other > secure transports might provide channels or other session-like > thing. > > s/thing/things/ ?? Changed to mechanisms. > > - last para page 20 > The information saved should include the model-independent > parameters > (transportDomain, transportAddress, securityName, > securityModel, and > securityLevel), related security parameters, and other information > needed to imatch the response with the request. The Message > > s/imatch/match/ Fixed. > > Bert > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 05 06:15:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1oW-0002PK-4g; Mon, 05 Feb 2007 06:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1oU-0002P7-IM for isms@ietf.org; Mon, 05 Feb 2007 06:15:10 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1oR-00055j-3T for isms@ietf.org; Mon, 05 Feb 2007 06:15:10 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l15BF4Bf008051; Mon, 5 Feb 2007 05:15:04 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 05:15:03 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:15:01 +0100 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] RE: working group last call on draft-ietf-isms-tmsm-05 Date: Mon, 5 Feb 2007 12:14:51 +0100 Message-ID: In-Reply-To: <0b3901c74730$b2b86620$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 Thread-Index: Acc2aKjqD7lBolk9SnKcZYgyHC7TnwP/CHBwAKqcNlA= References: <0b3901c74730$b2b86620$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , X-OriginalArrivalTime: 05 Feb 2007 11:15:01.0504 (UTC) FILETIME=[E0EC5000:01C74916] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5e78c12c28106eac1036838913e6d66b 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 Thanks for the follow up. My comments/reactions inline=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: zaterdag 3 februari 2007 2:15 > To: Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: [Isms] RE: working group last call on=20 > draft-ietf-isms-tmsm-05 >=20 > Comments inline. >=20 > dbh >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Friday, January 12, 2007 11:43 AM > > To: isms@ietf.org > > Subject: [Isms] RE: working group last call on > draft-ietf-isms-tmsm-05 > >=20 > > I have read and reviewd this document. Here are my comments. > >=20 > > First Kudo's to the authors/editors. Pretty good work. > > Although have quite a set of comments/questions, I think=20 > > the document is in pretty good shape. > >=20 > > But probably based on my (and other) comments (I have seen)=20 > > one more rev may make sense. > >=20 > > - I am completely confused by 3rd para of sect 3.2.1 > >=20 > > In SNMPv2, there were many problems of side effects between > > subsystems caused by the manipulation of MIB objects, especially > > those related to authentication and authorization, because many of > > the parameters were stored in shared MIB objects, and different > > models and protocols could assign different values to the objects. > > Contributors assumed slightly different shades of meaning depending > > on the models and protocols being used. As the shared MIB module > > design was modified to accommodate a specific model, other models > > which used the same MIB objects would be broken. > >=20 > > I wonder: > > - which SNMPv2 do you mean? SNMPv2c ?? Something else?=20 > > maybe you can use a citation/reference > > - I have no idea which MIB objects you are talking about, so I=20 > > cannot judege if anything was broken andd if so why/how. > > - What are you rtying to convey or justifty in this para? > > - is it needed at all? >=20 > Removed. > >=20 > > - I am also somehwta confusd by the next para (4th para in sect=20 > > 3.2.1): > >=20 > > Abstract Service Interfaces (ASIs) were developed to pass model- > > independent parameters. The models were required to translate from > > their model-dependent formats into a model-independent format, > > defined using model-independent semantics, which would not impact > > other models. > >=20 > > It probably has to do with the English here that seems prettyweird > > to me (but then, my native tongue is not English). >=20 > Removed. > >=20 > > - IN sect 3.2.1 on page 8: > >=20 > > Parameters have been provided in the ASIs to pass model-independent > > information about the authentication that has been provided. These > > parameters include a model-independent identifier of the security > > "principal", the security model used to perform the authentication, > > and which SNMP-specific security features were appied to the message > > (authentication and/or privacy). > >=20 > > Do we leave it up to the reader to connect/link the various phrases > > into securityName, securityModel and securityLevel? Why are we not > > very clear and name the things as we have named them in 3411? >=20 > Removed the paragraph. >=20 > >=20 > > - Further in section 3.2.1, page 8: > >=20 > > Parameters have been provided in the ASIs to pass model-independent > > transport address information. These parameters utilize the > > transportDomain and transportAddress > >=20 > > Is that last sentence not finished? > > And is it causing confusion? I wonder if this has any relation to > > the TransPortDomain/TransportAddress TCs in RFC3419. I think not. > > I think you are just saying that the model-independent parameters > > transportDomain and transportAddress (as used in RFc3411) are used. >=20 > Removed the sentence. > >=20 > > - The figure on page 9, when I compare it with the figure on page 24 > > of RFc3411, makes me wonder:=20 > >=20 > > Are we completely doing away with RFC3417 ?? > >=20 > > I guess we're not completely doing away with it are we? > > Maybe I'll find it further down in the document, but I fnot, we may > > need some words about that. >=20 > I don't know what WG consensus is on this issue. It has not been discussed. > I assume the transport mappings in RFC3417 can be treated as=20 > transport models, but we might want to do an actual update at=20 > some point. >=20 Whatever we do, we need to say something about it. Because right now it is unclear how we want to see the earlier TM from 3417. I do not yet have a suggestion for text. > >=20 > > - 2nd para in sect 3.2.2.1 , my comments inline > >=20 > > The securityName MUST be bound to the mechanism-specific > >=20 > > s/bound to/mapped from/ ?? is it really binding it or is it mapping? >=20 > Done. > >=20 > > authenticated identity, and this mapping MUST be done for incoming > > messages before the security model passes securityName to the message > > processing model via the processIncoming() ASI. This translation > > from a mechanism-specific authenticated identity to a securityName > > MAY be done by the transport model, and the securityname is then > >=20 > > s/securityname/securityName/ > Fixed. > >=20 > > provided to the security model to be passed to the message processing > > model. > >=20 > > So I think it is passed via the tmStateReference, no?=20 > > If so would it be usefull to say so? Or do we prefer to leave it vague? >=20 > Done. > >=20 > > - last para of sect 3.2.2.1 > >=20 > > If the type of authentication provided by the transport layer (e.g. > > TLS) is considered adequate to secure and/or encrypt the message, > > but inadequate to provide the desired granularity of access control=20 > > (e.g. user-based), then a second authentication (e.g., one provided via=20 > > a RADIUS server) MAY be used to provide the authentication identity > > which is bound to the securityName. This approach would require a > > good analysis of the potential for man-in-the-middle attacks or > > masquerade possibilities. > >=20 > > It does not say anything about at what point in the process steps this > > mapping from RADIUS authenticated identity to a securityName needs > > to take place. Maybe we want to leave that open. But it seems to me > > that the least we can say is that: it MUST bde done for incoming > > messages before the security model passes securityName to the message > > processing model via the processIncoming() ASI.=20 >=20 > I'm not sure that's true. If the goal is to get the identity=20 > for access control, it really only needs to get the=20 > securityname before it provides access control. If, for=20 > example, it uses RADIUS and does an authentication of the=20 > user and gets the authorization data, it could do this as=20 > part of the access control model. it doesn't need to be bound=20 > to the securityModel of the message, does it? I haven't spent=20 > time to consider the security implications of this, but I=20 > don't think we need to force this to be done a particular=20 > way. Of course, we do want to make sure the sender of the=20 > message is authorized to use the credentials that will=20 > authenticate the RADIUS request. > =20 First, none of the ASIs doe prescribe a particular way of=20 implementation. The ASIs are to pass stuff between=20 modularized documents. Second, although in theory it maybe OK to do it rigth before access control, I personally think it is cleaner (from a documentation modularity point of view) that it is done as I suggested. All the other ASIs have the securityName as a=20 paramter, and so I think it is more consistent if that paramter is filled out before such a field is being passed around. > >=20 > > - sect 3.2.2.2. starts with: > >=20 > > A transport model that provides security services should take > > care to > > not violate the separation of authentication and authorization > > in the > > RFC3411 architecture. The isAccessAllowed() primitive is used > > for > > passing security-model independent parameters between the=20 > > subsystems > > of the architecture. > >=20 > > That last sentence seems to put a big claim there. It is only ONE of > > the primitives (ASIs) for passing (xxx-model) independent parameters. > > I might word it as: > >=20 > > RFC3411 architecture. The isAccessAllowed() primitive is used for > > passing security-model independent parameters to an Access Control > > Model (like VACM) and passes Security Model independent parameters > > for the Access Control Model to use. >=20 > done > >=20 > > - Next para in sect 3.2.2.2 states: > >=20 > > Mapping of (securityModel, securityName) to an access control policy > >=20 > > I think I would add securityLevel in there as well. It is clearly included > > in the decision process (as per figure in sect 3.1 of RFC3415) and > > is also security model related (some may not be able to do a specific > > level, like SNMPv1 over UDP cannot do authNoPriv or authPriv). > > I see that you later state that some Access Control Models (well your > > wording uses inconsistent terms from RFC3411, but anyway) MAY need > > a securityLevel. So maybe that is why you left it out here, but > > certainly, it is a required parameter on the isAccessAllowed(). > Added securitylevel. >=20 > >=20 > > - To come back to terminology in sect 3.2.2.2. It states: > >=20 > > An authorization model (in the access control subsystem) MAY require > > authentication by certain securityModels and a minimum securityLevel > > to allow access to the data. > >=20 > > Mmm.. so now we also have an "authorization model" ?? > > I guess you do mean the Access Control Model (in the Access Control > > Subsystem) ?? >=20 > Fixed.=20 >=20 > >=20 > > - sect 3.2.2.2 > >=20 > > Transport models that provide secure transport are an enhancement for > > the SNMPv3 privacy and authentication, but they are not a significant > > improvement for the authorization (access control) needs of SNMPv3. > >=20 > > Are they an "enhancement"? Or are they an "addition" ?? > > I would say the latter. >=20 > From Mirriam-Webster: "to increase or improve in value,=20 > quality, desirability, or attractiveness" >=20 > Operators have complained that USM requires them to use yet=20 > another user and key infrastructure and they want a solution=20 > that leverages existing user and key infrastructures. The=20 > goal of ISMS is to provide a solution that is more attractive=20 > to operators. So I think this is an enhancement. >=20 > I wouldn't like to think I have spent all this time editing=20 > these documents to provide just an additional solution that=20 > was not an enhancement over what is already available. ;-) >=20 Peace... I still have my view, but it is not a real concern. > > =20 > > Also, the are an addition for "SNMP message privacy...".=20 > > You can also=20 > > enhance SNMPv1 and SNMPv2c privacy with it. > > Further, I believe that USM can also be used for as possible > > SNMPv4, > > and so again I do not see why you think it is SNMPv3 privacy=20 > > specific. > > or SNMPv3 specific w.r.t. aithorization. >=20 > You are making the assumption SNMPv3 refers to a message format here. > I was making the assumption SNMPv3 referred to the standard.=20 >=20 > This is one of the disadvantages of using "SNMPv3" in multiple ways.=20 > I'll try to make this less ambiguous by making it explicitly=20 > refer to messaging.=20 >=20 So why not just use "SNMP" instead of "SNMPv3" ? > >=20 > > - sect 3.2.2.2 > >=20 > > A transport model must not specify how the securityModel and > > securityName could be dynamically mapped to an access control > > mechanism, such as a VACM-style groupName. The mapping of > > (securityModel, securityName) to a groupName is a VACM-specific > > mechanism for naming an access control policy, and for tying the > > named policy to the addressing capabilities of the data modeling > > language (e.g. SMIv2 [RFC2578]), the operations supported, and=20 > > other > > factors. Providing a binding outside the Access Control subsystem > >=20 > > I learn new things everyday. Hopefully I can leanr something new again. > > What is/are: > >=20 > > the addressing capabilities of the data modeling language (e.g. > > SMIv2 > >=20 > > Am I the only one who is confused by that? >=20 > I changed it since you found it confusing.=20 > >=20 > > And a few lines further: > >=20 > > or Windows domains. The preferred approach is to pass the model- > > independent security parameters via the isAccessAllowed() ASI, and > > perform the mapping from the model-independent security parameters > > to > > an authorization-model-dependent access policy within the access > > control model. > >=20 > > Why is this not the RECOMMENDED approach? > > We did the architectural modularization with a purpose did we not. > > SO I would be strong and say RECOMMENDED instead of "preferred" >=20 > Fixed.=20 > >=20 > > Pls also change "authorization-model-dependent" into "Access Control > > Model dependent" >=20 > Done. > >=20 > > - sect 3.2.3, 5th para on page 13 states: > >=20 > > When using a secure transport model, security parameters MAY be > > provided through means other than carrying them in the SNMP message. > > The parameters MAY be provided by SNMP applications for outgoing > > messages, and the parameters for incoming messages MAY be extracted > > from the transport layer by the transport model before the message is > > passed to the message processing subsystem. > >=20 > > I am somehwat confused by the 2nd sentence.=20 > > I thought that for an outgoing message the SNMP appas MUST provide > > the required security parameters. Possibly you mean that in cases like > > a response they get picked up from the cached parameters of the > > incoming request (to which is being responded), but I find the capitalzied > > MAY confusing. It seems to say that for example a Comamnd Generator > > can choose to NOT pass any security parameters and would still be=20 > > compliant? I am confused. >=20 > I removed the first part of the second sentence. >=20 But you have kept MAY 2 times? I still find that confusing. lowercase would be fine, but now it seems to tell me something about compliance. > >=20 > > - section 3.3 and onwards talks about a "transport type" and=20 > > "transport > > address". Is that intentionally deviating from transportDomain and > > transportAddress as used earlier in the document? I.e. the=20 > > paramaters > > being passed in the ASIs? >=20 > Changed to match the parameters > >=20 > > - last para of sect 3.3.1 (page 15/16) states: > >=20 > > If a session can be reused for a different type of message, but a > > receiver is not prepared to accept different message types over the > > same session, then the message MAY be dropped by the receiver. This > > may strongly affect the usefulness of session reuse, and transport > > models should define a standard behavior for this circumstance. > >=20 > > Mmm... "type of message" ? I only see this term occur once in RFC3411. > > It basically is the PDU type. But OK, I can live with it. > > I am worried about the fact that "a transport model needs to define > > standard behaviour for this". How/where does a transport model > > know about the message type (or PDU type) ?? The pduType is passed > > between Dispatcher and MP model (in the ASIs), but I do not see it > > passed from the dispatcher to transport subsystem. Is the TM=20 > > suppsoed to go dig into the PDU itself? I hope not. >=20 > Hmmm. I'm not sure how a transport model knows this.=20 > I am not a fan of session reuse, so my heart won't be broken=20 > if we simply drop this whole thing, and the transport model=20 > finds the right session by its transport address (e.g., port=20 > 161 or 162). > I'll add this to the open issues section. >=20 So how did it get included in the first place? I guess there were some people who see a need for it? If so, then we need to figure out how the transport would know about it, or how this is/can be done otehrwise. > >=20 > > - In your sect 4.2, I would add that the diagram is from RFC3411. > > Oteghrwise people might think there was/is a change. >=20 > Done. > >=20 > > - In sect 4. You state that some info is missing in 4.6.1.=20 > > and 4.6.2 in > > 3411. > > You then show (repeat) the diagrams from 4.6.1. and 4.6.2 in your > > sections 4.1. and 4.2. > > But no further diagram extension to "complete" them? > > I am missing the purpose of this? Is that just me? > > I had expected the completed diagram, no? > > For example I had expected to see the sendMessage and recvMessage > > in a renewed diagram. > >=20 > > (By the way, why no use "receiveMessage" instead of "recvMessage"? > > we have many long ASI names already, and I hate all these > > abbreviation for no reason). >=20 > I am OK with that change. Done. >=20 > >=20 > >=20 > > - I am not 100% sure, but is it correct that section 5.1. about the > > securityStateReference is not adding any new (or changing any > > existing) information compared to RFC3411? > > If so, I would prefer we state that explicitly. > > If it does add something, pls make it clear what is being=20 > > added/changed. >=20 > This is not defined, but it may include additional security=20 > parameters related to the transport model. Then I would say something about that. Aka: the securityStateReference may include security paramters related to the transport model. or some such. And I guess that a transport model would then have to (MUST langauge) define any such parameters, no? > >=20 > > - Section 5.2 > > I think (but it is not clear) that the transport model should save > > a mapping from transport security/authentication ID to seucirtyName > > so the the Security Model can pick it up and pass it back as an > > OUT parameter on the processIncomingMessage ASI,. no? >=20 > Yes, this information should be saved in one of the caches.=20 > The format and contents of the caches are=20 > implementation-specific however, so I don't know what=20 > information we can discuss. The transport model might also=20 > need to know the authentication algorithm, the=20 > integity-checking and encryption parameters, and so on. These=20 > are very much transport-model specific. The way we deal with=20 > it is to provide two caches - one for the request/response=20 > pair, and another for the session-like mechanism. It is up to=20 > the implementer to decide what goes where. Added to Open=20 > Issues for discussion. >=20 I'd say we need to just state that thuis is what we expect, and that each specific transport model needs to be specific as to what kind of data needs to be saved in order tolet aSecurity Model be able to pick up the proper data that it needs. > >=20 > > - 6.2. Processing for an Outgoing Message > >=20 > > The sendMessage ASI is used to pass a message from the Dispatcher > > to the appropriate transport model for sending. > >=20 > > statusInformation =3D > > sendMessage( > > IN destTransportDomain -- transport domain to be used > > IN destTransportAddress -- transport address to be used > > IN outgoingMessage -- the message to send > > IN outgoingMessageLength -- its length > > IN tmStateReference -- reference to transport state > > ) > >=20 > > Would it be usefull to add a not that the tmStateReference is not > > always filled out? Let us say that I have just started my SNMP manager, > > now I am going to send my first SNMP GET Request. I would use above > > ASI (I think). But what is the content of tmStateRefrence here? > > Will it be filled upon return? >=20 > I added some text about this. Good catch. > >=20 > > I can see that when I want to call sendMEssage to send a response that > > the tmStateRefrence contains the info that came in on the request. >=20 > Yup. > >=20 > > - 6.3.1. Processing an Incoming Message > >=20 > > Is there any difference for an incoming response compared to a > > incoming request? Not clear to me. >=20 > Not until you hit the message processing model, I think. The=20 > MPM keeps track of outstanding requests to match up to the response. >=20 So maybe say something about that? Or was it just me who wondered? If it is/was clear to everyone else, then no need to add anything. But if several other people wonder(ed) as well, then it would be good to be 100% clear about it. > >=20 > > - 7. Security Considerations > >=20 > > This document describes an architectural approach that would permit > >=20 > > I would: s/would permit/permits/ > >=20 > > - I am not sure I understand why RFC2578 needs to be a normative=20 > > reference >=20 > There used to be a mib here. Now we don't cite 2578 at all. Removed. >=20 > >=20 > > - I have not checked appendix A > >=20 > > - Appendix B says: > > This appendix considers why a cache-based approach was selected for > > passing parameters. This section may be removed from subsequent > > revisions of the document. > >=20 > > I recommend to keep this appendix. It will/may help us remember (in 5 > > or 10 years from now) why we did this. So remove the 2nd sentence. >=20 > Done. > >=20 > > - I guess Appendix C will get removed ;-) >=20 > Once we resolve all open issues. sure. > >=20 > >=20 > > NITS: > >=20 > > - page 4: > >=20 > > the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. > >=20 > > change citation to [RFC4741] > > I know you could not know the RFCnumber when rev 5 was done. > > But if you do an update, then pls include this. >=20 > Done. > >=20 > > - Sect 3.1 > > Is there a good reason to list the threaths in a different order=20 > > as is done in RFC3414 page 5? > > Mmm... I see they are in the same order as in RFC3411 pages 6/7. > > So ignore my rambling. > >=20 > > - Section 3.2.1 > > Mmm.. the terminology used looks similar, but not the same as > > in RFC3411. And I wonder if it would not be better to use the > > same terms. I would also use same capitlized words. In fact > > you do use the RFC3411 terms in the figure on page 5. > >=20 > > TMSM RFC3411 > > messaging subsystem Message Processing Subsystem > > application subsystem Application(s) > > access control subsystem Access Control Subsystem > >=20 > > I would also change "transport subsystem" to Transport Subsystem"=20 > > just for consistency in capitalization. In fact in the figure, and > > in some other places you already do so. > >=20 > > - In section 3.2.1.1 I see a few cases of tautologie=20 > > - USM model (USM =3D User-based Security Model) > > - USM security model >=20 > Fixed. >=20 > >=20 > > - Further in sect 3.1.1, my comments inlined in a copy of the text: > >=20 > > 3.2.1.1. USM and the RFC3411 Architecture > >=20 > > The following diagrams illustrate the difference in the security > >=20 > > mmm.. where are thos diagrams? Is a diagram not a drawing/figure or > > some such? or ist it just text? >=20 > Fixed. >=20 > >=20 > > processing done by the USM model and the security processing > > potentially done by a transport model. > >=20 > > The USM security model is encapsulated by the messaging model, > > because the messaging model needs to perform the following steps > > (for > >=20 > > I wonder if the "because" is correct. In any event, the list below > > has > > many things in it that have nothing to do with the fact that the > > USM is encapsulated in the Message Processing Model (not that I use > > the RFC3411 term) > >=20 > Modified the text. >=20 > Let me point out that the encapsulation has a significant=20 > impact. With USM, you cannot provide the security=20 > functionality until after the MPM has decoded some of the=20 > ASN.1 to determine the values in the message header; the=20 > transport model approach doesn't require ASN.1 decoding=20 > before it can provide most of the security functionality. The=20 > purpose is to show that the order of the processing is=20 > different, and different subsystems have responsibilities for=20 > certain functions of the flow through an SNMP engine when=20 > using USM vs using a transport security model. >=20 > > incoming messages) > > 1) decode the ASN.1 (messaging model) > >=20 > > I would change that in "determine the Message Processing Model" > > now it sounds as if it is completely doing the ASN.1 decoding before > > it calls USM. It only partially does that. >=20 > Agreed. I was going for a simple bullet rather than complete=20 > accuracy here. > This is meant to be a simple bullet list that shows the=20 > abstract processing steps, and with a 69-column limit, it is=20 > hard to keep things readable if I have to spell out every=20 > little detail and every little conditional related to every=20 > abstract bullet. The detailed specification of processing=20 > steps, with all the details and conditionals, is documented elsewhere. >=20 Well, then at least add a note that states that this is not a detailed list but is only intended to .....your text ... > >=20 > > 2) determine the SNMP security model and parameters (messaging model) > > 3) decrypt the encrypted portions of the message (security model) > > 4) translate parameters to model-independent parameters (security > > model) > >=20 > > this step is completely inside Security Model, no? > > in fact step 3,4,5 are all just one call from the Message Processing > > Model to the Security Model, namely the processIncomingMsg ASI (Sect > > 4.4.2 in 3411) >=20 > They are not all completely inside the security model when=20 > using a secure transport. Some of these specific steps happen=20 > in a different order and in different subsystems, depending=20 > on whether you are using USM or a secure transport. >=20 I understand that. But I think we're keeping our ASI, and so,=20 in my view, the SecurityModel still determines it, albeit based=20 on some cache in the case of a secure ransport, while it picks=20 it up from the SNMP message in the case of USM. > >=20 > > 5) determine which application should get the decrypted portions > > (messaging model), and > >=20 > > This is done outside of the Message Processing Model (even in the > > figure on page 9 of tmsm document) namely it is "PDU Dispatch" > > in the "Dispatcher" >=20 > The registration uses message-model-specific pduTypes. For=20 > incoming messages, the MPM determines what pduType is=20 > contained in the message, then the dispatcher matches it up=20 > to the registrations. > Modified this step to read "determine the pduType in the=20 > decrypted portions (message processing model)". >=20 We both know/agree how it works (or so it seems from your response) Sounds that your fix addresses my concern. > >=20 > > 6) pass on the decrypted portions with model-independent parameters. > >=20 > > The USM approach uses SNMP-specific message security and parameters. > >=20 > > Not 100% sure what that last sentence means. Probably you mean to=20 > > tell us that an SNMPv3 message does have a USM specific set of > > security parameters.=20 >=20 > Yes; I am trying to describe the differences between USM and=20 > secure transport. I rewrote the section to try to clarify this. >=20 Need to see it before I can determine if it is better. > > The SNMPv3 message format is > > specified in RFC3412 and indeed for has reserved/allocated a space > > for ALL Security Model to pass Security Model specific parameters. > > From RFC3412: > >=20 > > -- security model-specific parameters > > -- format defined by Security Model > > msgSecurityParameters OCTET STRING, > > =20 > > If some Security Model does not need it, then it can be the > > zero-length OCTET STRING. >=20 > This is immaterial to the point. >=20 maybe so. I was not asking to add that text, I was trying to give background as to why I got confused by the last sentence, right under bullet 6). > >=20 > > - In sect 3.2.1.2, snippets of the text with my comments inline: > >=20 > > 2*) translate parameters to model-independent parameters (transport > > model) > >=20 > > Does that asterisk have special meaning? Or is it just a typo. > > I guess the latter. >=20 > Carryover from RFC3411; removed. >=20 > >=20 > >=20 > > 3) determine the SNMP security model and parameters (transport model) > >=20 > > Mmm... is that determined by the TM at the receiving end? > > Is it then filled in in the SNMPv3 message? Or is it checked against > > what is in there already? >=20 > Originally, the TM was going to determine the SM, but we=20 > changed our minds on that point. Now it is taken from the=20 > message. I modified the text. >=20 > >=20 > > If a message is secured using non-SNMP-specific message security and > > parameters, then the transport model should provide the translation > > from the authenticated identity (e.g., an SSH user name) to the > > securityName in step 3. > >=20 > > Mmm... I think I would reword into: > >=20 > > If a message is secured using secure transport layer, then the related > > transport model should provide the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. >=20 > >=20 > > after all, "non-SNMP-specific message security" could also be something > > that has nothing to do with the transport layer (I have no idea what yet) > > and so it would be strange to mandate that e TM would have to fill our > > parameters, no? >=20 > Fixed. >=20 > >=20 > > But aside from that, I wonder if/how this works. > > once we move from the Transport Model to the Dispatcher, then the > > Dispatcher calls the Message Processinge Model via prepareDataElements > > ASI. That ASI has an OUT parameter for securityName. So what will=20 > > happen if we have filled out the securityName in step 3? >=20 > The TM determines the securityName and securityLevel, and=20 > puts them into the cache. The dispatcher calls the MPM, which=20 > calls the appropriate security model. The security model=20 > extracts securityName and securityLevel from the message=20 > securityParameter block (USM), or the message header/MIB=20 > module (Community), or from the tmStateReference cache (TSM),=20 > and passes them to the MPM to report in the OUT parameter. =20 >=20 That is what I would expect. But that was not clear from the text. > > =20 > > I guess, we want the Transport Model to map these transport-layer-security > > parameters into model-independent security parameters, save them in > > the tmStateReference and then later, when the Message Processing Model=20 > > calls > > the Transport Security Model, they get filled in into the securityName > > (and other parameters). Assuming that I correctly understand how these > > transport layer security parameters get mapped, saved and then passed > > around, I think the steps in sect 3.2.1.2 may rather confuse people. > > If I completely mis-understand it, then I there are inconsistencies in > > your document, because in sect 6.1 on page 23, you state > >=20 > > The OUT parameters of the prepareOutgoingMessage() ASI are used to > > pass information from the message processing model to the dispatcher > > and on to the transport model: > >=20 > > And in the ASI on page 22, the securityName is still listed (as I > > expected by the way) as an OUT parameter. >=20 > Hopefully the new text will be clearer. >=20 Will check when I see it. > > =20 > > - In sections 3.2.1, 3.2.1.1 and 3.2.1.2 you explain the agent-side and > > the process steps (and the order of those steps) for an incoming > > message. I can easily see how to map the manager side for the picture. > > I wonder if it makes sense to check if we need to say anything about > > sending a (i.e. an outgoing) message? The sequence of steps there > > is also different. Can people easily determine that based on these > > 3 sections? >=20 > This is just an overview of which subsystems have which=20 > responsibilities, and the general flow of processing; it is=20 > not the detailed elements of procedure. > An outgoing message would probably just reverse the order,=20 > unless you get into all the detailed elements of procedure,=20 > where there are lots of conditional flows depending on the=20 > PDUtype (trap vs inform vs request vs response). If we try to=20 > document all the various possibilities here, you won't be=20 > able to see the forest because the trees will be in the way. >=20 Let us add a statement/note then that explains the purpose of what we are doing here and states that it is just rough and not a detailed eop. Maybe even add that a specific transport model MUST provide the detailed steps or elements of procedure (eop). > >=20 > > - Maybe it is my skill in English, but in sect 3.2.1.3,=20 > > I would change > >=20 > > After a transport layer tunnel is established, then SNMP messages can > > conceptually be sent through the tunnel from one SNMP engine to > > another SNMP engine. Once the tunnel is established, multiple SNMP > >=20 > > into: > >=20 > > After a transport layer tunnel is established, then SNMP messages can > > be sent through the tunnel from one SNMP engine to the other SNMP > > engine. Once the tunnel is established, multiple SNMP > >=20 > > I am not sure if the word "conceptually" is needed/useful. What do you > > try to convey? For me, they can just be sent, no? >=20 > This would have been better as "After a conceptual transport=20 > layer tunnel is established," since not all transport=20 > supports "tunnels" as such. But I can live without the=20 > "conceptual" being there at all. >=20 > > Also, toy cannot send the messages to just "another", but just to > > one, namely the one you are conne3cted to, other engine.=20 > >=20 > > Further, I would change: > >=20 > > another SNMP engine. Once the tunnel is established, multiple SNMP > > messages may be able to be passed through the same tunnel. > >=20 > > into > >=20 > > another SNMP engine. Once the tunnel is established, multiple SNMP > > messages can be passed through the same tunnel. > >=20 > > it is shorter, but also, the meaning is somewhat different and clearer > > I think (at least in my ear). >=20 > This might be transport-specific (think UDP as a transport model). >=20 > "Transport models MAY support sending multiple SNMP messages=20 > through the same tunnel." >=20 lowercase "may" if you ask me. > >=20 > > - sect 3.2.2.2 > >=20 > > RFC3411 architecture. The isAccessAllowed() primitive is used for > >=20 > > Why is this now a "primitive" and while it is an ASI in the 4th para > > on page 12: > >=20 > > independent security parameters via the isAccessAllowed() ASI, and > >=20 > > Pls try to be consistent. I see however that we did this also > > on RFC341x document. SO feel free to ignore this one if you like. > >=20 > I changed them to ASI for consistency. >=20 > > - I think the first MAY on page 14 could be lower case, or maybe > > even better could be replcaed by "can". > > The capitalized MAY/MUST/SHOULD and such are for compliance=20 > > information. I don't think that is the situation here, is it? >=20 > Fixed. >=20 > >=20 > > - I also see no reason for a capitalized MAY in the last para on page > > 15. >=20 > This one does affect on-the-wire interoperability, so I think=20 > a MAY is justified. An implementation would not be=20 > non-compliant because it does this (i.e., it is "legal" for=20 > an implementation to do this.)=20 >=20 ??? > >=20 > > - Last para in sect 3.3.3 > >=20 > > I think the first capitalized MAY would better be a lower case may. >=20 > Changed to "might" >=20 > > =20 > > TYPOs: > >=20 > > - page 6, sect 3.1 > > Using a protocol in a manner for which it was not designed has > > numerous problems. The advertised security characteristics of a > > protocol may depend on its being used as designed; when used in other > >=20 > > in last line: s/its/it/ ?? >=20 > Fixed. >=20 > >=20 > > - 3rd para page 8: > > The design of a transport subsystem must abide the goals of the > > RFC3411 architecture defined in [RFC3411]. To that end, this > > transport subsystem proposal uses a modular design that will permit > >=20 > > s/abide/abide by/ ?? >=20 > Either is valid. According to Merriam-Webster: > 3 : to accept without objection > - abide by > 1 : to conform to > 2 : to acquiesce in Changed to=20 > "accepts the goals". >=20 > >=20 > > s/RFC3411 architecture/SNMP architecture/ ??=20 > > I can live with RFC3411 architecture though. I see it comes back > > several times. I find it strange though to name an architecure=20 > > after an RFC number. >=20 > Remember that RFC3411 is "An Architecture", not "The=20 > Architecture". I try to not to refer to this as the "SNMP=20 > architecture", unless I qualify it as the "SNMP Architecture=20 > described in RFC3411", even though it is unwieldy. I usually=20 > just say the RFC3411 architecture. >=20 Aha... so I see why you do it. It still sounds/feels weird to me. > > =20 > > s/proposal// -- by the time this is an RFC it is no longer a=20 > > proposal is it? >=20 > Fixed. > >=20 > > - 4 para on page 8 > > the motivstion of developing transport models is to develop support > >=20 > > s/motivstion/motivation/ >=20 > Fixed. > >=20 > > - last para page 8 > > The RFC3411 architecture,and the USM assume that a security model is > > called by a message-processing model and will perform multiple > >=20 > > s/,and/, and/ > > s/message-processing model/Message Processing Model/ > > I hope you get the gist here on consistency of=20 > > terms/terminology. >=20 > I get the gist; I hate all the capitals in the middle of the=20 > sentences. I changed them to meet your request, but I think=20 > the document looks awful as a result. >=20 > "This document describes a cache, into which the Transport Model > puts information about the security applied to an=20 > incoming message, > and a Security Model can extract that information=20 > from the cache. > Given that there might be multiple TM-security caches, a > tmStateReference is passed as an extra parameter in=20 > the ASIs between > the Transport Subsystem and the Security Subsystem,=20 > so the Security > Model knows which cache of information to consult." > Is the following any less clear? I think it is better English. > This document describes a cache, into which the transport model > puts information about the security applied to an=20 > incoming message, > and a security model can extract that information=20 > from the cache. > Given that there might be multiple TM-security caches, a > tmStateReference is passed as an extra parameter in=20 > the ASIs between > the transport subsystem and the security subsystem,=20 > so the security > model knows which cache of information to consult." >=20 > I think "messaging model" is just as clear as "Message=20 > Processing Model". One way just makes it more verbose, and=20 > harder to fit things into 69-column lines. But I did it your way. >=20 Dave, for me it is just to get consistency between 3411 and this document. Otehrwise I couldn't care less if it is capitalized or not. > >=20 > > I think I would also do s/USM/Security Subsystem/ >=20 > Fixed. > >=20 > > - section 4.4. > > Some secure transports may have a notion of sessions, while other > > secure transports might provide channels or other session-like thing. > >=20 > > s/thing/things/ ?? >=20 > Changed to mechanisms. >=20 > > =20 > > - last para page 20 > > The information saved should include the model-independent parameters > > (transportDomain, transportAddress, securityName, securityModel, and > > securityLevel), related security parameters, and other information > > needed to imatch the response with the request. The Message > >=20 > > s/imatch/match/ >=20 > Fixed. > >=20 > > Bert > >=20 Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 05 23:53:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIKR-000424-G8; Mon, 05 Feb 2007 23:53:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIKQ-00041y-Lg for isms@lists.ietf.org; Mon, 05 Feb 2007 23:53:14 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEIKP-0007Mo-Tb for isms@lists.ietf.org; Mon, 05 Feb 2007 23:53:14 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020604531201300s86c1e>; Tue, 6 Feb 2007 04:53:12 +0000 From: "David Harrington" To: "'Andy Bierman'" , References: <45BE880C.6020806@andybierman.com> Subject: RE: [Isms] review of draft-ietf-isms-tmsm-05 Date: Mon, 5 Feb 2007 23:49:14 -0500 Message-ID: <0c6f01c749aa$2704ea50$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: <45BE880C.6020806@andybierman.com> Thread-index: AcdEABstZFTsy8M3RbW6VZVzFOaS1QFXNlzw X-Spam-Score: 0.0 (/) X-Scan-Signature: 76fee95f697ac1bd4d0bfe58b40699d9 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, Working on the -06- revision. Comments inline. dbh > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, January 29, 2007 6:50 PM > To: isms@lists.ietf.org > Subject: [Isms] review of draft-ietf-isms-tmsm-05 > > Hi, > > I was asked to review the transport subsystem draft. > I hope these comments help. > > Andy > > > Review of draft-ietf-isms-tmsm-05 > > Abstract > > This section is a bit redundant and vague. > It is not very clear why a transport sub-system is needed, > and is being added now, so many years after SNMP Arch was done. >From the abstract: "This document describes a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models." >From section 3.2.1: "The RFC3411 architecture includes a Security Subsystem for enabling different methods of providing security services, a Message Processing Subsystem permitting different message versions to be handled by a single engine, Applications(s) to support different types of application processors, and an Access Control Subsystem for allowing multiple approaches to access control. The RFC3411 architecture does not include a subsystem for Transport Models, despite the fact there are multiple transport mappings already defined for SNMP. This document addresses the need for a Transport Subsystem compatible with the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models." > > I know SNMP doesn't like to confine any system components, > so there is "an" architecture instead of "the" architecture, > but IMO, this document needs to be more normative, and more clear > about what is being defined (normative) vs. discussed (informational). I went through and looked at each "defines" and "describes", and tried to make sure I was consistent. The architecture extension is defined. The ASIs and changes to existing ASIs are defined. The cache, which is implementation-specific, is described. There is an open question of whether we need to "define" the cache (or at least the parts of the cache that contain the model-independent parameters). The LCD is described, since that is implementation-specific. I looked at the "discuss" terminology in the document, and I changed soe to describe, but most instances really are about having transport models discuss certain aspects that will have system-wide impact, but the details of which are model-specific. > > 2. Motivation > > The home security analogy is not very clear. > Consider introducing this section with a sentence that securing a > network protocol is like securing a home or business, and > make it clear > that this intro relates to the following paragraphs in this section. > > This document describes a Transport Subsystem extension to the > RFC3411 architecture. > > Which approach (of the 3 choices) does this document take? Fixed. > > The diagram on pg. 5 should be introduced and quickly explained where > this document fits into the diagram. Moved this to the introduction. > > pg. 6: > > SNMP continues to work without any surprises. > > Expand or add an example of the kind of surprise that this > document addresses. I assume you mean non-transparent > inter-operability with an SNMP peer by "no surprises". > That should be explained here. Modified the text. Suggested text welcome. > > pg 7: > > Transport models MUST be able to coexist with other > transport models, > and may be designed to utilize either TCP or UDP or SCTP. > > The section leading up to this last sentence is really good, > but SCTP is not mentioned at all, and then this summary sentence > suggests supporting it. In the first sentence, suggest changing > "other transport models" to "each other". Done. > > pg. 8: missing space > > The RFC3411 architecture,and the USM assume that a > security model is > ^ Done > pg. 9 diagram: > > Can you highlight what is new vs. already in place for SNMP? > There is a caption that says (traditional SNMP agent) but > this is not clear, since it shows new transports TCP, SSH, and TLS. > It is an excellent diagram, but could be explained a bit more. Modified the preamble to describe what is new. > > > Sec 3.2.1 General: It is not clear what is existing and what > is new in these procedures. > > > 3.2.1.1. USM and the RFC3411 Architecture > > The following diagrams illustrate the difference in the security > > Do you mean previous diagram, since this is on pg. 10? No. meant the lists. > > 3.2.2. Access Control Requirements > > General: Would help to have an executive summary at the > start of this section (like a table) that lists what new > things the 3.2.2.* sections are going to explain. done > > 3.2.2.1. securityName Binding > processing model via the processIncoming() ASI. This translation > should remove parens ^^ Done. > > > If the type of authentication provided by the transport layer (e.g. > (several places) missing > comma ^ > Done. > > pg 12: > > A transport model must not specify how the securityModel and > securityName could be dynamically mapped to an access control > mechanism, such as a VACM-style groupName. The mapping of > (securityModel, securityName) to a groupName is a VACM-specific > mechanism for naming an access control policy, and for tying the > named policy to the addressing capabilities of the data modeling > language (e.g. SMIv2 [RFC2578]), the operations > supported, and other > factors. Providing a binding outside the Access Control subsystem > might create dependencies that could make it harder to develop > alternate models of access control, such as one built on > UNIX groups > or Windows domains. The preferred approach is to pass the model- > independent security parameters via the isAccessAllowed() ASI, and > perform the mapping from the model-independent security > parameters to > an authorization-model-dependent access policy within the access > control model. > > To provide support for protocols which simultaneously send > information for authentication and authorization, such as RADIUS > [RFC2865], model-specific authorization information MAY be > cached or > otherwise made available to the access control subsystem, > e.g., via a > MIB table similar to the vacmSecurityToGroupTable, so the access > control subsystem can create an appropriate binding between the > model-independent securityModel and securityName and a > model-specific > access control policy. This may be highly undesirable, however, if > it creates a dependency between a transport model or a > security model > and an access control model, just as it is undesirable for a > transport model to create a dependency between an SNMP message > version and the security provided by a transport model. > > > A summary table gathering all the requirements from large paragraphs > (like the 2 above) would be helpful. Each of these sections has only one requirement - 1) there must be a mapping to model-independent securityname, securitylevel, and securityModel, 2) authentication and uathorization must remain separated, and 3) the model-independent parameters must be passed through the ASIs. I don't think there is anything to gather into a table. > > > 3.2.3. Security Parameter Passing Requirements > > A table summarizing the security parameters would be helpful. > It would be useful to refer back to the diagram as to > the specific information flow or ASI in question. There are only three security parameters, and they affect all ASIs. > > > This document describes a cache mechanism, into which the transport > model puts information about the transport and security parameters > > Describes or defines? Describes. The definition of the cache is implementation-specific. > A section number reference would be good here. Done. > > 3.3. Session Requirements > > Some secure transports may have a notion of sessions, while other > secure transports might provide channels or other > session-like thing. > > s/thing/mechanism/ > > Throughout this document, the term session is used in a broad sense > to cover sessions, channels, and session-like things. > Session refers > > s/things/mechanisms/ Done. > > > It is important to note that the architecture described in > [RFC3411] > does not include a session selector in the Abstract Service > Interfaces, and neither is that done for the transport > subsystem, so > an SNMP application cannot select the session except by passing a > unique combination of transport type, transport address, > securityName, securityModel, and securityLevel. > > This seems like a very important paragraph (and requirement). > It would be nice to explain why all these parameters are needed > to identify a session. Done. > > All transport models should discuss the impact of sessions on SNMP > usage, including how to establish/open a transport session > (i.e., how > it maps to the concepts of session-like things of the underlying > protocol), how to behave when a session cannot be > established, how to > close a session properly, how to behave when a session is closed > improperly, the session security properties, session establishment > overhead, and session maintenance overhead. > > To reduce redundancy, this document will discuss aspects that are > expected to be common to all transport model sessions. > > IMO, 'define' (not 'discuss') should be used when referring > to standards > track documents. These aspects depend on the specific transports, and cannot be defined here. They can be discussed here to ensure they are defined in the specific models. > > A summary (somewhere in the doc) of all the requirements > this spec defines + another summary of the requirements > that are expected to be defined externally. I think you are looking for a neat little bulleted list, but most of the requirments need to be described in context. I don't know that I could extract unambiguous bullet items into a neat little list. If you want to provided sugggested text, I would welcome that. > > > 3.3.1. Session Establishment Requirements > > SNMP Applications typically have no knowledge of whether > the session > that will be used to carry commands was initially established as a > notification session, or a request-response session, and SHOULD NOT > make any assumptions based on knowing the direction of the session. > > Is this true? Why doesn't the session initiator know what type > of session is being requested? There was WG consensus to permit transport-session reuse, including for different types of messages (request/response vs notification), and the reuse decision is made by the transport-specific model. Because of this, an application does not know whether it is the first to request a session with these security parameters (including direction), and if it is not the first, whether the session was initially opened as a request/response session or as a notification session. > > If an administrator or transport model designer wants to > differentiate a session established for different > purposes, such as a > notification session versus a request-response session, the > application can use different securityNames or transport addresses > (e.g., port 161 vs. port 162) for different purposes. > > Is this a normative definition? > Maybe a use case and example diagram would be helpful. > > An SNMP engine containing an application that initiates > communication, e.g., a Command Generator or Notification > Originator, > MUST be able to attempt to establish a session for delivery if a > session does not yet exist. If a session cannot be > established then > the message is discarded. > > Does the application know it is establishing a session? > Are the sessions just a transport layer mechanism? > Some explanation of the document I should have read before > starting this document should be in the Introduction section. No, the application does not necessarily know if it is establishing a session; the session is a transport-specific mechanism. The session might already exist, started by a different application, and might be reused for this message. The application might specify a session it has used before (using domain/address/name/model/level), but the session might have been closed for various reasons, so this message might cause the establishment of a new session. > > If a session can be reused for a different type of message, but a > receiver is not prepared to accept different message types over the > same session, then the message MAY be dropped by the > receiver. This > may strongly affect the usefulness of session reuse, and transport > models should define a standard behavior for this circumstance. > > IMO, this document should define the behavior, and not pass it > to the transport implementation. Silently dropping messages > in a purposely undefined way is not good standards practice. The whole idea of session reuse has never been used with SNMP before, or any other widely-deployed IETF NM protocol (if there were any), and I don't know that we understand how session reuse will be impacted by different security protocols, or how session reuse will impact certain security protocols, or what the impact to SNMP interoperability will be. I don't think we have enough understanding of the impacts of discarding a message sent through a reused session to define what the normative behavior should be for all transport models at this point. > > > 3.3.2. Session Maintenance Requirements > > A transport model can tear down sessions as needed. It may be > necessary for some implementations to tear down sessions as the > result of resource constraints, for example. > > I am unclear on the session model here wrt/ which components > are aware of sessions. Does the application initiate session > control or not? I usually think of sessions as user-controlled > and user-configured inactivity timeout. Is that what is > meant by resource constraints? Sessions are a transport-specific mechanism, controlled at the transport-model-specific level. > > The decision to tear down a session is implementation-dependent. > > Why? > Why isn't session control requirements part of the standard? Because this is an architecture document, and transport session mechanisms (and controls) are transport-protocol specific. > > 3.3.3. Message security versus session security > > ... > SNMPv3 was designed to support multiple levels of security, > selectable on a per-message basis by an SNMP application, because > there is not much value in using encryption for a > Commander Generator > to poll for non-sensitive performance data on thousands of > interfaces > every ten minutes; the encryption may add significant overhead to > processing of the messages. > > Should note that this non-sensitive polling is an example, > not imply this is the only reason for per-message security. Done. > > > 4.1. Command Generator or Notification Originator > > This diagram from RFC3411 4.6.1 shows how a Command Generator or > Notification Originator application [RFC3413] requests > that a PDU be > sent, and how the response is returned (asynchronously) to that > application. > > I don't see how the diagrams in sec 4. relate to sessions > and to the transport sub-system. It doesn't much; the diagram is from RFC34111. The Transport Subsystem defines ASIs to replace "Send SNMP xxx Message to the network" and "Receive SNMP xxxx Message from the Network". I included text to make this point clearer. It would be difficult to make this point clear by extending this diagram to include a transport subsystem and to show the flows, and especially any session. There just isn't enough room in 69 columns of ASCII art. > > 5. Cached Information and References > > This document differentiates the tmStateReference from the > securityStateReference. > > Suggest providing some context as to what these variables are, > and how they are different. This whole section is about providing that context. > > 5.1. securityStateReference > > A Message Processing Model has the responsibility for explicitly > releasing the cached data if such data is no longer needed. To > enable this, an abstract securityStateReference data element is > passed from the Security Model to the Message Processing > Model. The > cached security data may be implicitly released via the > generation of > a response, or explicitly released by using the stateRelease > primitive, as described in RFC3411 section 4.5.1." > > Is securityStateReference a new construct or something from RFC 3411? It's from RFC3411. > > The information saved should include the model-independent > parameters > (transportDomain, transportAddress, securityName, > securityModel, and > securityLevel), related security parameters, and other information > > needed to imatch the response with the request. The Message > sp. ^^^^^^ > > If the transport model connection is closed between the time a > Request is received and a Response message is being prepared, then > the Response message MAY be discarded. > > What other options would be appropriate? It may be appropriate to not discard such messages; a security protocol may provide a resumme capability that maintains adaequate assurances that the session security properties are identiical and that it is safe to "reopen" a session on demand and use that to send the Response message. That would be transport-model specific. For protocols that cannot provide such assurances, discarding the Response message may be the most appropriate solution. > > 5.2. tmStateReference > > For each message or transport session, information about > the message > security is stored in a cache, which may inlcude model- and > sp. Fixed. ^^^^^^^ > > 6. Abstract Service Interfaces > > An error indication may return an OID and value for an incremented > counter and a value for securityLevel, and values for > contextEngineID > and contextName for the counter, and the securityStateReference if > the information is available at the point where the error is > detected. > > Which error indication? Response to what operation? This text was taken directly from RFC3411; since this is an extension to RFC3411, there is an assumption the reader has read RFC3411. I added an explcit statement that the reader is expected to havee read RFC3411 first. I modified this text to make it clearer that this was text taken from RFC3411. > > 6.2. Processing for an Outgoing Message > > The sendMessage ASI is used to pass a message from the > Dispatcher to > the appropriate transport model for sending. > > statusInformation = > sendMessage( > IN destTransportDomain -- transport domain to be used > IN destTransportAddress -- transport address to be used > IN outgoingMessage -- the message to send > IN outgoingMessageLength -- its length > IN tmStateReference -- reference to transport state > ) > > Are there any changes to this ASI? > What is the purpose of this section? This ASI did not exist in RFC3411. It is defined here. > > 6.3. Processing an Incoming SNMP Message > > 6.3.1. Processing an Incoming Message > > If one does not exist, the Transport Model will need to create an > entry in a Local Configuration Datastore referenced by > tmStateReference. This information will include transportDomain, > transportAddress, the securityModel, the securityLevel, and the > securityName, plus any model or mechanism-specific > details. How this > information is determined is model-specific. > > Model-specific? > This is kind of a new term. > Implementation-specific has been raised so far, but not this. Model-specific is used in RFC3411. It is used throughout this document to describe a parameter, like securityName, that is independent of any model, whether transport, message-processing, security or access control models. > > 6.3.2. Prepare Data Elements from Incoming Messages > > The abstract service primitive from the Dispatcher to a Message > Processing Model for a received message is: > > .... > Note that tmStateReference has been added to this ASI. > > Should explain how the ASI semantics change due to the new parameter. The following paragraphs described the semantics, but I realize they went beyond the transport subsystem a bit too far, so I rewrote these sections. > > 6.3.3. Processing an Incoming Message > > Should explain how the ASI semantics change due to the new parameter. Ditto. > > 7. Security Considerations > > secret keys does not result in disclosure of past session > keys. The > editors recommend that each proposed transport model include a > discussion in its security considerations of whether > perfect forward > security is appropriate for the transport model. > > The editors recommend does not sound very official. Fixed. > > Since the cache and LCD will contain security-related parameters, > they should be kept in protected storage. > > What exactly is meant by protected? > > [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the > NETCONF Configuration Protocol over Secure > Shell (SSH)", > draft-ietf-netconf-ssh-06 (work > in progress), March 2006. > > > Update reference to RFC 4742. > > Appendix A. Parameter Table > > Following is a CSV formatted matrix useful for tracking data flows > into and out of the dispatcher, transport, message, and security > subsystems. Import this into your favorite spreadsheet or > other CSV > compatible application. You will need to remove lines > feeds from the > second, third, and fourth lines, which needed to be wrapped to fit > into RFC limits. > > A.1. ParameterList.csv > > Not clear what this section is for. > The syntax is very cryptic. Improved description of this appendix and its purpose. > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 06 01:18:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJf3-0001R2-Ol; Tue, 06 Feb 2007 01:18:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJey-0001PH-VS for isms@ietf.org; Tue, 06 Feb 2007 01:18:32 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJdu-0000yZ-2D for isms@ietf.org; Tue, 06 Feb 2007 01:17:26 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007020606172501400hpu4ue>; Tue, 6 Feb 2007 06:17:25 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <0b3901c74730$b2b86620$0600a8c0@china.huawei.com> Subject: RE: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05 Date: Tue, 6 Feb 2007 01:13:28 -0500 Message-ID: <0c7001c749b5$eb5f5470$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: Thread-index: Acc2aKjqD7lBolk9SnKcZYgyHC7TnwP/CHBwAKqcNlAAJpkCQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 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 Rev -06- is getting closer. Comments inline. > > > > > > - The figure on page 9, when I compare it with the figure > on page 24 > > > of RFc3411, makes me wonder: > > > > > > Are we completely doing away with RFC3417 ?? > > > > > > I guess we're not completely doing away with it are we? > > > Maybe I'll find it further down in the document, but I fnot, we > may > > > need some words about that. > > > > I don't know what WG consensus is on this issue. It has not been > discussed. > > I assume the transport mappings in RFC3417 can be treated as > > transport models, but we might want to do an actual update at > > some point. > > > > Whatever we do, we need to say something about it. Because right now > it is unclear how we want to see the earlier TM from 3417. I do not > yet have a suggestion for text. Added text saying this was a supplement that updated 3411 and 3417. > > > > > > - last para of sect 3.2.2.1 > > > > > > If the type of authentication provided by the transport layer > (e.g. > > > TLS) is considered adequate to secure and/or encrypt the > message, > > > but inadequate to provide the desired granularity of access > control > > > (e.g. user-based), then a second authentication (e.g., one > provided via > > > a RADIUS server) MAY be used to provide the authentication > identity > > > which is bound to the securityName. This approach > would require > a > > > good analysis of the potential for man-in-the-middle > attacks or > > > masquerade possibilities. > > > > > > It does not say anything about at what point in the > process steps > this > > > mapping from RADIUS authenticated identity to a > securityName needs > > > to take place. Maybe we want to leave that open. But it seems to > me > > > that the least we can say is that: it MUST bde done for incoming > > > messages before the security model passes securityName to the > message > > > processing model via the processIncoming() ASI. > > > > I'm not sure that's true. If the goal is to get the identity > > for access control, it really only needs to get the > > securityname before it provides access control. If, for > > example, it uses RADIUS and does an authentication of the > > user and gets the authorization data, it could do this as > > part of the access control model. it doesn't need to be bound > > to the securityModel of the message, does it? I haven't spent > > time to consider the security implications of this, but I > > don't think we need to force this to be done a particular > > way. Of course, we do want to make sure the sender of the > > message is authorized to use the credentials that will > > authenticate the RADIUS request. > > > > First, none of the ASIs doe prescribe a particular way of > implementation. The ASIs are to pass stuff between > modularized documents. > > Second, although in theory it maybe OK to do it rigth before > access control, I personally think it is cleaner (from a > documentation modularity point of view) that it is done > as I suggested. All the other ASIs have the securityName as a > paramter, and so I think it is more consistent if that paramter > is filled out before such a field is being passed around. > > > > > > > > Also, the are an addition for "SNMP message privacy...". > > > You can also > > > enhance SNMPv1 and SNMPv2c privacy with it. > > > Further, I believe that USM can also be used for as possible > > > SNMPv4, > > > and so again I do not see why you think it is SNMPv3 privacy > > > specific. > > > or SNMPv3 specific w.r.t. aithorization. > > > > You are making the assumption SNMPv3 refers to a message > format here. > > I was making the assumption SNMPv3 referred to the standard. > > > > This is one of the disadvantages of using "SNMPv3" in > multiple ways. > > I'll try to make this less ambiguous by making it explicitly > > refer to messaging. > > > So why not just use "SNMP" instead of "SNMPv3" ? See the new text and see if that is satsifactory. > > > But you have kept MAY 2 times? > I still find that confusing. lowercase would be fine, but now it > seems to tell me something about compliance. > > > If a session can be reused for a different type of message, but a > > receiver is not prepared to accept different message types over the > > same session, then the message MAY be dropped by the receiver. This > > may strongly affect the usefulness of session reuse, and transport > > models should define a standard behavior for this circumstance. > > > > Mmm... "type of message" ? I only see this term occur once in RFC3411. > > It basically is the PDU type. But OK, I can live with it. > > I am worried about the fact that "a transport model needs to define > > standard behaviour for this". How/where does a transport model > > know about the message type (or PDU type) ?? The pduType is passed > > between Dispatcher and MP model (in the ASIs), but I do not see it > > passed from the dispatcher to transport subsystem. Is the TM > > suppsoed to go dig into the PDU itself? I hope not. > > Hmmm. I'm not sure how a transport model knows this. > I am not a fan of session reuse, so my heart won't be broken > if we simply drop this whole thing, and the transport model > finds the right session by its transport address (e.g., port > 161 or 162). > I'll add this to the open issues section. > > > So how did it get included in the first place? > I guess there were some people who see a need for it? > If so, then we need to figure out how the transport would know > about it, or how this is/can be done otehrwise. Sessions are a transport-specific issue, and are controlled by a transport model. A transport model has no idea which application has requested that a message be sent; it typically only knows transportDomain/Address and securityName/Model/Level. If a session already exists that matches those parameters, it reuses it. The transport model does not necessarily know whether the session was first established to send a request or a notification. I'm not sure if the transport model actually needs to deal with this. The message MAY be dropped on the floor when a notification is sent to a port that is enabled only for request/response traffic, or a request was sent to a port configured only for notification traffic, or an agent sends a GET-request to an NMS. It seems unlikely a response would be sent to a port unwilling to accept responses, since we usually send the response back to the port the request came from. The message-processing model keeps track of outstanding expectResponses, so it should probably be aware that no response message was returned, when the remote node dropped a request message (including inform) on the floor. If it was a trap, it would not be expecting a response anyway. If it is an unexpected GET, there will be no registered application for that pduType, so it would be dropped anyway. So it should probably be the message processing model or the application that needs to know how to deal with dropped messages. I removed the text that says a transport model needs to define a stndard behavior. > > > > > > > > > > > - I am not 100% sure, but is it correct that section 5.1. > about the > > > securityStateReference is not adding any new (or changing any > > > existing) information compared to RFC3411? > > > If so, I would prefer we state that explicitly. > > > If it does add something, pls make it clear what is being > > > added/changed. > > > > This is not defined, but it may include additional security > > parameters related to the transport model. > > Then I would say something about that. Aka: > the securityStateReference may include security paramters > related to the transport model. > or some such. And I guess that a transport model would then have to > (MUST langauge) define any such parameters, no? "The related security parameters may include transport-specific security information." I am not sure that the security experts would like to see MUST language about what needs to be included. This would potentially limit algorithm agility. It also might depend on the libraries they are using to implement; different libraries may require different parameters. So the cached information is transport-model and implementation dependent: "A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific." > > > > > > > - Section 5.2 > > > I think (but it is not clear) that the transport model > should save > > > a mapping from transport security/authentication ID to > seucirtyName > > > so the the Security Model can pick it up and pass it back as an > > > OUT parameter on the processIncomingMessage ASI,. no? > > > > Yes, this information should be saved in one of the caches. > > The format and contents of the caches are > > implementation-specific however, so I don't know what > > information we can discuss. The transport model might also > > need to know the authentication algorithm, the > > integity-checking and encryption parameters, and so on. These > > are very much transport-model specific. The way we deal with > > it is to provide two caches - one for the request/response > > pair, and another for the session-like mechanism. It is up to > > the implementer to decide what goes where. Added to Open > > Issues for discussion. > > > > I'd say we need to just state that thuis is what we expect, and that > each specific transport model needs to be specific as to what kind > of data needs to be saved in order tolet aSecurity Model be able to > pick up the proper data that it needs. "For each message or transport session, information about the message security is stored in a cache, which may include model- and mechanism-specific parameters. The tmStateReference is passed between subsystems to provide a handle for the cache. A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific." > > > > > > > - 6.3.1. Processing an Incoming Message > > > > > > Is there any difference for an incoming response compared to a > > > incoming request? Not clear to me. > > > > Not until you hit the message processing model, I think. The > > MPM keeps track of outstanding requests to match up to the response. > > > > So maybe say something about that? > Or was it just me who wondered? > If it is/was clear to everyone else, then no need to add anything. > But if several other people wonder(ed) as well, then it would > be good to be 100% clear about it. > > > > > > incoming messages) > > > 1) decode the ASN.1 (messaging model) > > > > > > I would change that in "determine the Message Processing Model" > > > now it sounds as if it is completely doing the ASN.1 decoding > before > > > it calls USM. It only partially does that. > > > > Agreed. I was going for a simple bullet rather than complete > > accuracy here. > > This is meant to be a simple bullet list that shows the > > abstract processing steps, and with a 69-column limit, it is > > hard to keep things readable if I have to spell out every > > little detail and every little conditional related to every > > abstract bullet. The detailed specification of processing > > steps, with all the details and conditionals, is documented > elsewhere. > > > > Well, then at least add a note that states that this is not a detailed > list > but is only intended to .....your text ... Done. > > > > > > > 2) determine the SNMP security model and parameters > (messaging > model) > > > 3) decrypt the encrypted portions of the message (security > model) > > > 4) translate parameters to model-independent parameters > (security > > > model) > > > > > > this step is completely inside Security Model, no? > > > in fact step 3,4,5 are all just one call from the Message > Processing > > > Model to the Security Model, namely the processIncomingMsg ASI > (Sect > > > 4.4.2 in 3411) > > > > They are not all completely inside the security model when > > using a secure transport. Some of these specific steps happen > > in a different order and in different subsystems, depending > > on whether you are using USM or a secure transport. > > > > I understand that. But I think we're keeping our ASI, and so, > in my view, the SecurityModel still determines it, albeit based > on some cache in the case of a secure ransport, while it picks > it up from the SNMP message in the case of USM. I'm not sure what "determines it" refers to. The securityModel is determined by the message processing model. Certainly the decryption is handled by the transport, not the security model. So I assume you mean the securityName and securityLevel. To keep things modular, a secure transport model translates from transport-specific security principal to securityName, and passes the securityName in the cache. The transport model determines what security services were provided by the transport, and puts securityLevel into the cache. A security model does not need to know anything about the transport specific principal or services. The security model just takes securityName and securityLevel from the cache, already translated. Otherwise we would have a problem of requiring a specific security model for each specific transport model, something we definitely want to avoid. What happens with the cache depends on the security model called by the message processing model. Some might take the values from the cache to return to the MPM; some might just use parameters provided in a message security block and totally ignore the cache; some might use a mapping from a MIB module and totally ignore the cache. > > > > > Also, toy cannot send the messages to just "another", > but just to > > > one, namely the one you are conne3cted to, other engine. > > > > > > Further, I would change: > > > > > > another SNMP engine. Once the tunnel is established, multiple > SNMP > > > messages may be able to be passed through the same tunnel. > > > > > > into > > > > > > another SNMP engine. Once the tunnel is established, multiple > SNMP > > > messages can be passed through the same tunnel. > > > > > > it is shorter, but also, the meaning is somewhat different and > clearer > > > I think (at least in my ear). > > > > This might be transport-specific (think UDP as a transport model). > > > > "Transport models MAY support sending multiple SNMP messages > > through the same tunnel." > > > lowercase "may" if you ask me. This would have an on-the-wire interoperability impact, so I think MAY is appropriate. A reciever should be prepared to deal with a sender that puts multiple messages in the same tunnel, without core dumping, for instance. The MAY says it is permissible for a compliant implementation to send multiple messages in a tunnel. > > > > > > > > - I also see no reason for a capitalized MAY in the last para on > page > > > 15. > > > > This one does affect on-the-wire interoperability, so I think > > a MAY is justified. An implementation would not be > > non-compliant because it does this (i.e., it is "legal" for > > an implementation to do this.) > > > > ??? > Let's wait for -06- to hit before discussing these points further. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 06 01:27:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJo4-00061J-QX; Tue, 06 Feb 2007 01:27:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJo3-000612-JS for isms@ietf.org; Tue, 06 Feb 2007 01:27:55 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJo1-0005HQ-Bu for isms@ietf.org; Tue, 06 Feb 2007 01:27: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 <2007020606275101200i259ne>; Tue, 6 Feb 2007 06:27:51 +0000 From: "David Harrington" To: Date: Tue, 6 Feb 2007 01:23:51 -0500 Message-ID: <0c7101c749b7$5e85fa70$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0C72_01C7498D.75AFF270" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdJtvs3Vvth6Me/TSys3JcvHv5pmA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a6da63c04df138d130940e6d54738db Cc: Subject: [Isms] Draft-ietf-isms-tmsm-06 prerelease 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 a multi-part message in MIME format. ------=_NextPart_000_0C72_01C7498D.75AFF270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have submitted this draft for publication. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_0C72_01C7498D.75AFF270 Content-Type: text/plain; name="draft-ietf-isms-tmsm-06-prerelease.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-06-prerelease.txt" Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Updates: 3411,3412,3414,3417 J. Schoenwaelder (if approved) International University Bremen Intended status: Standards Track February 5, 2007 Expires: August 9, 2007 Transport Subsystem for the Simple Network Management Protocol (SNMP) draft-ietf-isms-tmsm-06 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design Harrington & Schoenwaelder Expires August 9, 2007 [Page 1] =0C Internet-Draft SNMP Transport Subsystem February 2007 and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. Harrington & Schoenwaelder Expires August 9, 2007 [Page 2] =0C Internet-Draft SNMP Transport Subsystem February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 4 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 3.1. Message Security Requirements . . . . . . . . . . . . . . 8 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Architectural Modularity Requirements . . . . . . . . 9 3.2.2. Access Control Requirements . . . . . . . . . . . . . 13 3.2.3. Security Parameter Passing Requirements . . . . . . . 14 3.2.4. Separation of Authentication and Authorization . . . . 15 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 16 3.3.1. Session Establishment Requirements . . . . . . . . . . 17 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 18 3.3.3. Message security versus session security . . . . . . . 18 4. Scenario Diagrams for the Transport Subsystem . . . . . . . . 19 4.1. Command Generator or Notification Originator . . . . . . . 19 4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 21 5. Cached Information and References . . . . . . . . . . . . . . 22 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 23 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 24 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 24 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 24 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 25 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 26 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 31 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 31 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 33 B.1. Define an Abstract Service Interface . . . . . . . . . . . 33 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 33 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 34 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 34 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Harrington & Schoenwaelder Expires August 9, 2007 [Page 3] =0C Internet-Draft SNMP Transport Subsystem February 2007 1. Introduction This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in [RFC3411]. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. 1.2. Where this Extension Fits It is expected that readers of this document will have read RFC3410 and RFC3411, and have a general understanding of the functionality defined in RFCs 3412-3418. The "Transport Subsystem" is an additional component for the SNMP Engine depicted in RFC3411, section 3.1. Harrington & Schoenwaelder Expires August 9, 2007 [Page 4] =0C Internet-Draft SNMP Transport Subsystem February 2007 The following diagram depicts its place in the RFC3411 architecture.: +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and ASIs that transport mappings (models) can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters translated into the transport-independent securityName and securityLevel. Harrington & Schoenwaelder Expires August 9, 2007 [Page 5] =0C Internet-Draft SNMP Transport Subsystem February 2007 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are not to be interpreted as described in RFC2119. They will usually, but not always, be used in a context relating to compatibility with the RFC3411 architecture or the subsystem defined here, but which might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC3411 subsystems and Abstract Service Interfaces (see section 3.2). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. 2. Motivation Just as there are multiple ways to secure one's home or business, in a continuum of alternatives, there are multiple ways to secure a network management protocol. Let's consider three general approaches. In the first approach, an individual could sit on his front porch waiting for intruders. In the second approach, he could hire an employee , schedule the employee, position the employee to guard what he wants protected, hire a second guard to cover if the first gets sick, and so on. In the third approach, he could hire a security company, tell them what he wants protected, and they could hire employees, train them, position the guards, schedule the guards, send a replacement when a guard cannot make it, etc., thus providing the desired security, with no significant effort on his part other than identifying requirements and verifying the quality of the service being provided. The User-based Security Model (USM) as defined in [RFC3414] largely uses the first approach - it provides its own security. It utilizes existing mechanisms (e.g., SHA), but provides all the coordination. USM provides for the authentication of a principal, message encryption, data integrity checking, timeliness checking, etc. USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate principal and key management infrastructure. Operators have reported that deploying another principal and key management infrastructure in order to use SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use Harrington & Schoenwaelder Expires August 9, 2007 [Page 6] =0C Internet-Draft SNMP Transport Subsystem February 2007 external mechanisms to handle the distribution of keys for use by USM. The more important issue is that operators wanted to leverage a single user base that wasn't specific to SNMP. A solution based on the second approach might use a USM-compliant architecture, but combine the authentication mechanism with an external mechanism, such as RADIUS [RFC2865], to provide the authentication service. It might be possible to utilize an external protocol to encrypt a message, to check timeliness, to check data integrity, etc. It is difficult to cobble together a number of subcontracted services and coordinate them however, because it is difficult to build solid security bindings between the various services, and potential for gaps in the security is significant. A solution based on the third approach might utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. There are a number of IETF standards available or in development to address these problems through security layers at the transport layer or application layer, among them TLS [RFC4366], SASL [RFC4422], and SSH [RFC4251]. From an operational perspective, it is highly desirable to use security mechanisms that can unify the administrative security management for SNMPv3, command line interfaces (CLIs) and other management interfaces. The use of security services provided by lower layers is the approach commonly used for the CLI, and is also the approach being proposed for NETCONF [RFC4741]. This document defines a Transport Subsystem extension to the RFC3411 architecture based on the third approach. This extension specifies how other lower layer protocols with common security infrastructures can be used underneath the SNMP protocol and the desired goal of unified administrative security can be met. This extension allows security to be provided by an external protocol connected to the SNMP engine through an SNMP Transport Model [RFC3417]. Such a Transport Model would then enable the use of existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251] within the RFC3411 architecture. There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try to provide a generic infrastructure to be used by many different application layer protocols. The motivation behind the Transport Subsystem is to leverage these protocols where it seems useful. Harrington & Schoenwaelder Expires August 9, 2007 [Page 7] =0C Internet-Draft SNMP Transport Subsystem February 2007 There are a number of challenges to be addressed to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to provide interoperability with existing implementations. These challenges are described in detail in this document. For some key issues, design choices are described that might be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411]. 3. Requirements of a Transport Model 3.1. Message Security Requirements Transport security protocols SHOULD provide protection against the following message-oriented threats [RFC3411]: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure These threats are described in section 1.4 of [RFC3411]. It is not required to protect against denial of service or traffic analysis, but it should not make those threats significantly worse. 3.1.1. Security Protocol Requirements There are a number of standard protocols that could be proposed as possible solutions within the Transport Subsystem. Some factors SHOULD be considered when selecting a protocol. Using a protocol in a manner for which it was not designed has numerous problems. The advertised security characteristics of a protocol might depend on it being used as designed; when used in other ways, it might not deliver the expected security characteristics. It is recommended that any proposed model include a description of the applicability of the Transport Model. A Transport Model SHOULD require no modifications to the underlying protocol. Modifying the protocol might change its security characteristics in ways that would impact other existing usages. If a change is necessary, the change SHOULD be an extension that has no impact on the existing usages. Any Transport Model SHOULD include a description of potential impact on other usages of the protocol. Transport Models MUST be able to coexist with each other. Harrington & Schoenwaelder Expires August 9, 2007 [Page 8] =0C Internet-Draft SNMP Transport Subsystem February 2007 3.2. SNMP Requirements 3.2.1. Architectural Modularity Requirements SNMP version 3 (SNMPv3) is based on a modular architecture (defined in [RFC3411] section 3) to allow the evolution of the SNMP protocol standards over time, and to minimize side effects between subsystems when changes are made. The RFC3411 architecture includes a Security Subsystem for enabling different methods of providing security services, a Message Processing Subsystem permitting different message versions to be handled by a single engine, Applications(s) to support different types of application processors, and an Access Control Subsystem for allowing multiple approaches to access control. The RFC3411 architecture does not include a subsystem for Transport Models, despite the fact there are multiple transport mappings already defined for SNMP. This document addresses the need for a Transport Subsystem compatible with the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. The design of this Transport Subsystem accepts the goals of the RFC3411 architecture defined in section 1.5 of [RFC3411]. This Transport Subsystem uses a modular design that will permit Transport Models to be advanced through the standards process independently of other Transport Models, and independent of other modular SNMP components as much as possible. Parameters have been added to the ASIs to pass model-independent transport address information. IETF standards typically require one mandatory to implement solution, with the capability of adding new mechanisms in the future. Part of the motivation of developing Transport Models is to develop support for secure transport protocols, such as a Transport Model that utilizes the Secure Shell protocol. Any Transport Model SHOULD define one minimum-compliance security mechanism, such as certificates, to ensure a basic level of interoperability, but should also be able to support additional existing and new mechanisms. The Transport Subsystem permits multiple transport protocols to be "plugged into" the RFC3411 architecture, supported by corresponding Transport Models, including models that are security-aware. The RFC3411 architecture and the Security Subsystem assume that a Security Model is called by a Message Processing Model and will Harrington & Schoenwaelder Expires August 9, 2007 [Page 9] =0C Internet-Draft SNMP Transport Subsystem February 2007 perform multiple security functions within the Security Subsystem. A Transport Model that supports a secure transport protocol might perform similar security functions within the Transport Subsystem. A Transport Model might perform the translation of transport security parameters to/from security-model-independent parameters. To accommodate this, an implementation-specific cache of transport- specific information will be described (not shown), and the data flows between the Transport Subsystem and the Transport Dispatch, between the Message Dispatch and the Message Processing Subsystem, and between the Message Processing Subsystem and the Security Subsystem will be extended to pass security-model-independent values. New Security Models may also be defined that understand how to work with the modified ASIs and the cache. One such Security Mode, the Transport Security Model, is defined in The following diagram depicts the SNMPv3 architecture including the new Transport Subsystem defined in this document, and a new Transport Security Model defined in [I-D.ietf-isms-transport-security-model]. Harrington & Schoenwaelder Expires August 9, 2007 [Page 10] =0C Internet-Draft SNMP Transport Subsystem February 2007 +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-------------------------------------------------------------------+ | +--------------------------------------------------+ | | | Transport Subsystem | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | +--------------------------------------------------+ | | ^ | | | | | Dispatcher v | | +-------------------+ +---------------------+ +----------------+ | | | Transport | | Message Processing | | Security | | | | Dispatch | | Subsystem | | Subsystem | | | | | | +------------+ | | +------------+ | | | | | | +->| v1MP |<--->| | USM | | | | | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | | | | | | +->| v2cMP |<--->| | Transport | | | | | Message | | | +------------+ | | | Security | | | | | Dispatch <--------->| +------------+ | | | Model | | | | | | | +->| v3MP |<--->| +------------+ | | | | | | | +------------+ | | +------------+ | | | | PDU Dispatch | | | +------------+ | | | Other | | | | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | | ^ | +------------+ | | +------------+ | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ Harrington & Schoenwaelder Expires August 9, 2007 [Page 11] =0C Internet-Draft SNMP Transport Subsystem February 2007 3.2.1.1. Processing Differences between USM and Secure Transport USM and secure transports differ is the processing order and responsibilities within the RFC3411 architecture. While the steps are the same, they occur in a different order, and may be done by different subsystems. The following lists illustrate the difference in the flow and the responsibility for different processing steps for incoming messages when using USM and when using a secure transport. (Note that these lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models must provide the detailed elements of procedure.) With USM and other Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to extract an opaque block of security parameters and header parameters that identify which Security Model should process the message to perform authentication, decryption, timeliness checking, integrity checking, and translation of parameters to model-independent parameters. A secure transport performs those security functions on the message, before the ASN.1 is decoded. Step 6 cannot occur until after decryption occurs. Step 6 and beyond are the same for USM and a secure transport. 3.2.1.1.1. USM and the RFC3411 Architecture 1) decode the ASN.1 header (Message Processing Model) 2) determine the SNMP Security Model and parameters (Message Processing Model) 3) verify securityLevel. [Security Model] 4) translate parameters to model-independent parameters (Security Model) 5) authenticate and decrypt message. [Security Model] 6) determine the pduType in the decrypted portions (Message Processing Model), and 7) pass on the decrypted portions with model-independent parameters. 3.2.1.2. Transport Subsystem and the RFC3411 Architecture 1) authenticate and decrypt message. [Transport Model] 2) translate parameters to model-independent parameters (Transport Model) 3) decode the ASN.1 header (Message Processing Model) 4) determine the SNMP Security Model and parameters (Message Processing Model) Harrington & Schoenwaelder Expires August 9, 2007 [Page 12] =0C Internet-Draft SNMP Transport Subsystem February 2007 5) verify securityLevel [Security Model] 6) determine the pduType in the decrypted portions (Message Processing Model), and 7) pass on the decrypted portions with model-independent security parameters If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. 3.2.1.3. Passing Information between Engines A secure Transport Model will establish an authenticated and/or encrypted tunnel between the Transport Models of two SNMP engines. After a transport layer tunnel is established, then SNMP messages can be sent through the tunnel from one SNMP engine to the other SNMP engine. Transport Models MAY support sending multiple SNMP messages through the same tunnel. 3.2.2. Access Control Requirements RFC3411 made some design decisions related to the support of an Access Control Subsystem. These include a securityName and securityLevel mapping, the separation of Authentication and Authorization, and the passing of model-independent security parameters. 3.2.2.1. securityName and securityLevel Mapping For SNMP access control to function properly, Security Models MUST establish a securityLevel and a securityName, which is the security- model-independent identifier for a principal. The Message Processing Subsystem relies on a Security Model, such as USM, to play a role in security that goes beyond protecting the message - it provides a mapping between the security-model-specific principal to a security- model independent securityName which can be used for subsequent processing, such as for access control. The securityName MUST be mapped from the mechanism-specific authenticated identity, and this mapping must be done for incoming messages before the Security Model passes securityName to the Message Processing Model via the processIncoming ASI. This translation from a mechanism-specific authenticated identity to a securityName might be done by the Transport Model, and the securityName is then provided to the Security Model via the tmStateReference to be passed to the Message Processing Model. If the type of authentication provided by the transport layer (e.g., Harrington & Schoenwaelder Expires August 9, 2007 [Page 13] =0C Internet-Draft SNMP Transport Subsystem February 2007 TLS) is considered adequate to secure and/or encrypt the message, but inadequate to provide the desired granularity of access control (e.g., user-based), then a second authentication (e.g., one provided via a RADIUS server) MAY be used to provide the authentication identity which is mapped to the securityName. This approach would require a good analysis of the potential for man-in-the-middle attacks or masquerade possibilities. 3.2.3. Security Parameter Passing Requirements RFC3411 section 4 describes abstract data flows between the subsystems, models and applications within the architecture. Abstract Service Interfaces describe the flow of data, passing model- independent information between subsystems within an engine. The RFC3411 architecture has no ASI parameters for passing security information between the Transport Subsystem and the dispatcher, or between the dispatcher and the Message Processing Model. This document defines or modifies ASIs for this purpose. The security parameters include a model-independent identifier of the security "principal" (the securityName), the Security Model used to perform the authentication, and which authentication and privacy services were (should be) applied to the message (securityLevel). A Message Processing Model might unpack SNMP-specific security parameters from an incoming message before calling a specific Security Model to authenticate and decrypt an incoming message, perform integrity checking, and translate security-model-specific parameters into model-independent parameters. When using a secure Transport Model, security parameters might be provided through means other than carrying them in the SNMP message; the parameters for incoming messages might be extracted from the transport layer by the Transport Model before the message is passed to the Message Processing Subsystem. This document describes a cache mechanism (see Section 5), into which the Transport Model puts information about the transport and security parameters applied to a transport connection or an incoming message, and a Security Model may extract that information from the cache. A tmStateReference is passed as an extra parameter in the ASIs of the Transport Subsystem and the Message Processing and Security Subsystems, to identify the relevant cache. This approach of passing a model-independent reference is consistent with the securityStateReference cache already being passed around in the RFC3411 ASIs. For outgoing messages, even when a secure Transport Model will provide the security services, a Message Processing Model might have Harrington & Schoenwaelder Expires August 9, 2007 [Page 14] =0C Internet-Draft SNMP Transport Subsystem February 2007 a Security Model actually create the message from its component parts. Whether there are any security services provided by the Security Model for an outgoing message is security-model-dependent. For incoming messages, even when a secure Transport Model provides security services, a Security Model might provide some security functionality that can only be provided after the message version or other parameters are extracted from the message. 3.2.4. Separation of Authentication and Authorization The RFC3411 architecture defines a separation of authentication and authorization (access control), and a Transport Model that provides security services should take care to not violate this separation. A Transport Model must not specify how the securityModel and securityName could be dynamically mapped to an access control mechanism, such as a VACM-style groupName. The RECOMMENDED approach is to pass the model-independent security parameters via the isAccessAllowed ASI, and perform the mapping from the model-independent security parameters to an access-control-model- dependent policy within the Access Control Model. The isAccessAllowed ASI is used for passing the securityModel, securityName, and securityLevel parameters that are independent of any specific security model and any specific access control model to the Access Control Subsystem. The mapping of (securityModel, securityName, securityLevel) to an access-control-model-specific policy should be handled within a specific access control model. This mapping should not be done in the Transport or Security Subsystems, to be consistent with the modularity of the RFC3411 architecture. This separation was a deliberate decision of the SNMPv3 WG, to allow support for authentication protocols which did not provide authorization (access control) capabilities, and to support authorization schemes, such as VACM, that do not perform their own authentication. The View-based Access Control Model uses the securityModel and the securityName as inputs to check for access rights. It determines the groupName as a function of securityModel and securityName. Providing a binding outside the Access Control Subsystem might create dependencies that could make it harder to develop alternate models of access control, such as one built on UNIX groups or Windows domains. To provide support for protocols which simultaneously send information for authentication and authorization (access control), such as RADIUS [RFC2865], access-control-model-specific information might be cached or otherwise made available to the Access Control Subsystem, e.g., via a MIB table similar to the Harrington & Schoenwaelder Expires August 9, 2007 [Page 15] =0C Internet-Draft SNMP Transport Subsystem February 2007 vacmSecurityToGroupTable, so the Access Control Subsystem can create an appropriate binding between the access-control-model-independent securityModel and securityName and an access-control-model-specific policy. This would be highly undesirable, however, if it creates a dependency between a Transport Model or a Security Model and an Access Control Model. 3.3. Session Requirements Some secure transports might have a notion of sessions, while other secure transports might provide channels or other session-like mechanism. Throughout this document, the term session is used in a broad sense to cover sessions, channels, and session-like mechanisms. Session refers to an association between two SNMP engines that permits the transmission of one or more SNMP messages within the lifetime of the session. How the session is actually established, opened, closed, or maintained is specific to a particular Transport Model. Sessions are not part of the SNMP architecture defined in [RFC3411], but are considered desirable because the cost of authentication can be amortized over potentially many transactions. The architecture defined in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for the Transport Subsystem, so an SNMP application has no mechanism to select a session using the ASIs except by passing a unique combination of transportDomain, transportAddress, securityName, securityModel, and securityLevel. Implementers, of course, might provide non-standard mechanisms to select sessions. The transportDomain and transportAddress identify the transport connection to a remote network node; the securityName identifies which security principal to communicate with at that address (e.g., different NMS applications), and the securityModel and securityLevel might permit selection of different sets of security properties for different purposes (e.g., encrypted SETs vs. non-encrypted GETs). All Transport Models should discuss the impact of sessions on SNMP usage, including how to establish/open a transport session (i.e., how it maps to the concepts of session-like mechanisms of the underlying protocol), how to behave when a session cannot be established, how to close a session properly, how to behave when a session is closed improperly, the session security properties, session establishment overhead, and session maintenance overhead. To reduce redundancy, this document describes aspects that are expected to be common to all Transport Model sessions. Harrington & Schoenwaelder Expires August 9, 2007 [Page 16] =0C Internet-Draft SNMP Transport Subsystem February 2007 3.3.1. Session Establishment Requirements SNMP applications must provide the transportDomain, transportAddress, securityName, securityModel, and securityLevel to be used for a session. SNMP Applications might have no knowledge of whether the session that will be used to carry commands was initially established as a notification session, or a request-response session, and SHOULD NOT make any assumptions based on knowing the direction of the session. If an administrator or Transport Model designer wants to differentiate a session established for different purposes, such as a notification session versus a request-response session, the application can use different securityNames or transport addresses (e.g., port 161 vs. port 162) for different purposes. An SNMP engine containing an application that initiates communication, e.g., a Command Generator or Notification Originator, must be able to attempt to establish a session for delivery if a session does not yet exist. If a session cannot be established then the message is discarded. Sessions are usually established by the Transport Model when no appropriate session is found for an outgoing message, but sessions might be established in advance to support features such as notifications. How sessions are established in advance is beyond the scope of this document. Sessions are initiated by notification originators when there is no currently established connection that can be used to send the notification. For a client-server security protocol, this might require provisioning authentication credentials on the agent, either statically or dynamically, so the client/agent can successfully authenticate to a notification receiver. A Transport Model must be able to determine whether a session does or does not exist, and must be able to determine which session has the appropriate security characteristics (transportDomain, transportAddress, securityName, securityModel, and securityLevel) for an outgoing message. A Transport Model implementation MAY reuse an already established session with the appropriate transportDomain, transportAddress, securityName, securityModel, and securityLevel characteristics for delivery of a message containing a different pduType than originally caused the session to be created. For example, an implementation that has an existing session originally established to receive a request MAY use that session to send an outgoing notification, and Harrington & Schoenwaelder Expires August 9, 2007 [Page 17] =0C Internet-Draft SNMP Transport Subsystem February 2007 MAY use a session that was originally established to send a notification to send a request. Responses SHOULD be returned using the same session that carried the corresponding request message. Reuse of sessions is not required for conformance. If a session can be reused for a different pduType, but a receiver is not prepared to accept different pduTypes over the same session, then the message MAY be dropped by the receiver. 3.3.2. Session Maintenance Requirements A Transport Model can tear down sessions as needed. It might be necessary for some implementations to tear down sessions as the result of resource constraints, for example. The decision to tear down a session is implementation-dependent. While it is possible for an implementation to automatically tear down each session once an operation has completed, this is not recommended for anticipated performance reasons. How an implementation determines that an operation has completed, including all potential error paths, is implementation-dependent. The elements of procedure describe when cached information can be discarded, in some circumstances, and the timing of cache cleanup might have security implications, but cache memory management is an implementation issue. If a Transport Model defines MIB module objects to maintain session state information, then the Transport Model MUST define what SHOULD happen to the objects when a related session is torn down, since this will impact interoperability of the MIB module. 3.3.3. Message security versus session security A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to multiple messages. Cryptographic keys established at the beginning of the session SHOULD be used to provide authentication, integrity checking, and encryption services for data that is communicated during the session. The cryptographic protocols used to establish keys for a Transport Model session SHOULD ensure that fresh new session keys are generated for each session. In addition sequence information might be maintained in the session which can be used to prevent the replay and reordering of messages within a session. If each session uses new keys, then a cross-session replay attack will be unsuccessful; that is, an attacker cannot successfully replay on one session a message he observed from another session. A good security protocol will also Harrington & Schoenwaelder Expires August 9, 2007 [Page 18] =0C Internet-Draft SNMP Transport Subsystem February 2007 protect against replay attacks _within_ a session; that is, an attacker cannot successfully replay a message observed earlier in the same session. A Transport Model session will have a single transportDomain, transportAddress, securityModel, securityName and securityLevel associated with it. If an exchange between communicating engines requires a different securityLevel or is on behalf of a different securityName, or uses a different securityModel, then another session would be needed. An immediate consequence of this is that implementations SHOULD be able to maintain some reasonable number of concurrent sessions. For Transport Models, securityName should be specified during session setup, and associated with the session identifier. SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because, for example, there is not much value in using encryption for a Commander Generator to poll for potentially non-sensitive performance data on thousands of interfaces every ten minutes; the encryption might add significant overhead to processing of the messages. Some Transport Models might support only specific authentication and encryption services, such as requiring all messages to be carried using both authentication and encryption, regardless of the security level requested by an SNMP application. A Transport Model may upgrade the requested security level, i.e. noAuthNoPriv and authNoPriv MAY be sent over an authenticated and encrypted session. 4. Scenario Diagrams for the Transport Subsystem RFC3411 section 4.6 provides scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. Both diagrams are incomplete, however. In section 4.6.1, the diagram doesn't show an ASI for sending an SNMP request to the network or for receiving an SNMP response message from the network. In section 4.6.2, the diagram doesn't show the ASIs to receive an SNMP message from the network, or to send an SNMP message to the network. 4.1. Command Generator or Notification Originator This diagram from RFC3411 4.6.1 shows how a Command Generator or Notification Originator application [RFC3413] requests that a PDU be sent, and how the response is returned (asynchronously) to that application. Harrington & Schoenwaelder Expires August 9, 2007 [Page 19] =0C Internet-Draft SNMP Transport Subsystem February 2007 This document defines a sendMessage ASI to send SNMP messages to the network, and a receiveMessage ASI to receive SNMP messages from the network. Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | | Harrington & Schoenwaelder Expires August 9, 2007 [Page 20] =0C Internet-Draft SNMP Transport Subsystem February 2007 4.2. Command Responder This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Response is (asynchronously) sent back to the network. This document defines the sendMessage and receiveMessage ASIs for this purpose. Harrington & Schoenwaelder Expires August 9, 2007 [Page 21] =0C Internet-Draft SNMP Transport Subsystem February 2007 Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | | 5. Cached Information and References The RFC3411 architecture uses caches to store dynamic model-specific information, and uses references in the ASIs to indicate in a model- independent manner which cached information flows between subsystems. Harrington & Schoenwaelder Expires August 9, 2007 [Page 22] =0C Internet-Draft SNMP Transport Subsystem February 2007 There are two levels of state that might need to be maintained: the security state in a request-response pair, and potentially long-term state relating to transport and security. This state is maintained in caches. To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message should also be discarded, and if state information is available when a relationship between engines is severed, such as the closing of a transport session, the state information for that relationship might also be discarded. This document differentiates the tmStateReference from the securityStateReference. This document does not specify an implementation strategy, only an abstract description of the data that flows between subsystems. An implementation might use one cache and one reference to serve both functions, but an implementer must be aware of the cache-release issues to prevent the cache from being released before a security or Transport Model has had an opportunity to extract the information it needs. 5.1. securityStateReference From RFC3411: "For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response." To enable this, an abstract securityStateReference data element, defined in RFC3411 section A.1.5, is passed from the Security Model to the Message Processing Model. The information saved should include the model-independent parameters (transportDomain, transportAddress, securityName, securityModel, and securityLevel), related security parameters, and other information needed to match the response with the request. The related security parameters may include transport-specific security information. The Message Processing Model has the responsibility for explicitly releasing the securityStateReference when such data is no longer needed. The securityStateReference cached data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease ASI, as defined in RFC 3411 section 4.5.1." If the Transport Model connection is closed between the time a Request is received and a Response message is being prepared, then the Response message MAY be discarded. Harrington & Schoenwaelder Expires August 9, 2007 [Page 23] =0C Internet-Draft SNMP Transport Subsystem February 2007 5.2. tmStateReference For each message or transport session, information about the message security is stored in a cache, which may include model- and mechanism-specific parameters. The tmStateReference is passed between subsystems to provide a handle for the cache. A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific. The state referenced by tmStateReference might be saved in a Local Configuration Datastore (LCD) to make it available across multiple messages, as compared to securityStateReference which is designed to be saved only for the life of a request-response pair of messages. It is expected that an LCD will allow lookup based on the combination of transportDomain, transportAddress, securityName, securityModel, and securityLevel, and that the cache contain these values to reference entries in the LCD. 6. Abstract Service Interfaces Abstract service interfaces have been defined by RFC 3411 to describe the conceptual data flows between the various subsystems within an SNMP entity, and to help keep the subsystems independent of each other except for the common parameters. This document follows the example of RFC3411 regarding the release of state information, and regarding error indications. 1) The release of state information is not always explicitly specified in a transport model. As a general rule, if state information is available when a message gets discarded, the message- state information should also be released, and if state information is available when a session is closed, the session state information should also be released. 2) An error indication in statusInformation may include an OID and value for an incremented counter and a value for securityLevel, and values for contextEngineID and contextName for the counter, and the securityStateReference if the information is available at the point where the error is detected. 6.1. sendMessage ASI The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate Transport Model for sending. Harrington & Schoenwaelder Expires August 9, 2007 [Page 24] =0C Internet-Draft SNMP Transport Subsystem February 2007 If present and valid, the tmStateReference refers to a cache containing transport-model-specific parameters for the transport and transport security. How the information in the cache is used is transport-model-dependent and implementation-dependent. How a tmStateReference is determined to be present and valid is implementation-dependent. This may sound underspecified, but keep in mind that a transport model might be something like SNMP over UDP over IPv6, where no security is provided, so it might have no mechanisms for utilizing a securityName and securityLevel. statusInformation =3D sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- reference to transport state ) 6.2. Other Outgoing ASIs A tmStateReference parameter has been added to the prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg ASIs as an OUT parameter. statusInformation =3D -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length OUT tmStateReference -- (NEW) reference to transport state ) Harrington & Schoenwaelder Expires August 9, 2007 [Page 25] =0C Internet-Draft SNMP Transport Subsystem February 2007 The tmStateReference parameter of generateRequestMsg or generateResponseMsg is passed in the return parameters of the Security Subsystem to the Message Processing Subsystem. If a cache exists for a session identifiable from transportDomain, transportAddress, securityModel, securityName, and securityLevel, then an appropriate Security Model might create a tmStateReference to the cache and pass that as an OUT parameter. If one does not exist, the Security Model might create a cache referenced by tmStateReference. This information might include transportDomain, transportAddress, the securityModel, the securityLevel, and the securityName, plus any model or mechanism- specific details. The contents of the cache may be incomplete until the Transport Model has established a session. What information is passed, and how this information is determined, is implementation and security-model-specific. The prepareOutgoingMessage ASI passes tmStateReference from the Message Processing Subsystem to the dispatcher. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. This may sound underspecified, but keep in mind that a message processing model might have access to all the information from the cache and from the message, and have no need to call a Security Model to do any processing; an application might choose a Security Model such as USM to authenticate and secure the SNMP message, but also utilize a secure transport such as that provided by the SSH Transport Model to send the message to its destination. 6.3. The receiveMessage ASI If one does not exist, the Transport Model might create a cache referenced by tmStateReference. If present, this information might include transportDomain, transportAddress, securityLevel, and securityName, plus model or mechanism-specific details. How this information is determined is implementation and transport-model- specific. This may sound underspecified, but keep in mind that a transport model might be something like SNMP over UDP over IPv6, where no security is provided, so it might have no mechanisms for determining a securityName and securityLevel. The Transport Model does not know the securityModel for an incoming message; this will be determined by the Message Processing Model in a message-processing-model-dependent manner. Harrington & Schoenwaelder Expires August 9, 2007 [Page 26] =0C Internet-Draft SNMP Transport Subsystem February 2007 The receiveMessage ASI is used to pass a message from the Transport Subsystem to the Dispatcher. statusInformation =3D receiveMessage( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN incomingMessage -- the message received IN incomingMessageLength -- its length IN tmStateReference -- reference to transport state ) 6.4. Other Incoming ASIs To support the Transport Subsystem, the tmStateReference is added to the prepareDataElements ASI (from the Dispatcher to the Message Processing Subsystem), and to the processIncomingMsg ASI (from the Message Processing Subsystem to the Security Model Subsystem). How or if a Message Processing Model or Security Model uses tmStateReference is message-processing-model-dependent and security- model-dependent. result =3D -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network IN tmStateReference -- (NEW) from the Transport Model OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response ) Harrington & Schoenwaelder Expires August 9, 2007 [Page 27] =0C Internet-Draft SNMP Transport Subsystem February 2007 statusInformation =3D -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response The tmStateReference parameter of prepareDataElements is passed from the dispatcher to the Message Processing Subsystem. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. The processIncomingMessage ASI passes tmStateReference from the Message Processing Subsystem to the Security Subsystem. If tmStateReference is present and valid, an appropriate Security Model might utilize the information in the cache. How or if the Security Subsystem utilizes the information in the cache is security- model-specific. This may sound underspecified, but keep in mind that a message processing model might have access to all the information from the cache and from the message, and have no need to call a Security Model to do any processing. The Message Processing Model might determine that the USM Security Model is specified in an SNMPv3 message header; the USM Security Model has no need of values in the tmStateReference cache to authenticate and secure the SNMP message, but an application might have chosen to use a secure transport such as that provided by the SSH Transport Model to send the message to its destination. 7. Security Considerations This document defines an architectural approach that permits SNMP to utilize transport layer security services. Each proposed Transport Model should discuss the security considerations of the Transport Model. Harrington & Schoenwaelder Expires August 9, 2007 [Page 28] =0C Internet-Draft SNMP Transport Subsystem February 2007 It is considered desirable by some industry segments that SNMP Transport Models should utilize transport layer security that addresses perfect forward secrecy at least for encryption keys. Perfect forward secrecy guarantees that compromise of long term secret keys does not result in disclosure of past session keys. Each proposed Transport Model should include a discussion in its security considerations of whether perfect forward security is appropriate for the Transport Model. Since the cache and LCD will contain security-related parameters, implementers should store this information (in memory or in persistent storage) in a manner to protect it from unauthorized disclosure and/or modification. Care must be taken to ensure that a SNMP engine is sending packets out over a transport using credentials that are legal for that engine to use on behalf of that user. Otherwise an engine that has multiple transports open might be "tricked" into sending a message through the wrong transport. 8. IANA Considerations This document requires no action by IANA. 9. Acknowledgments The Integrated Security for SNMP WG would like to thank the following people for their contributions to the process: The authors of submitted Security Model proposals: Chris Elliot, Wes Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Perkins, Joseph Salowey, and Juergen Schoenwaelder. The members of the Protocol Evaluation Team: Uri Blumenthal, Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. WG members who committed to and performed detailed reviews: Jeffrey Hutzelman 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Harrington & Schoenwaelder Expires August 9, 2007 [Page 29] =0C Internet-Draft SNMP Transport Subsystem February 2007 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 10.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Harrington & Schoenwaelder Expires August 9, 2007 [Page 30] =0C Internet-Draft SNMP Transport Subsystem February 2007 Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport Security Model for SNMP", d raft-ietf-isms-transport- security-model-02 (work in progress), January 2007. Appendix A. Parameter Table Following is a Comma-separated-values (CSV) formatted matrix useful for tracking data flows into and out of the dispatcher, Transport, Message Processing, and Security Subsystems. This will be of most use to designers of models, to understand what information is available at which points in the processing, following the RFC3411 architecture (and this subsystem). Import this into your favorite spreadsheet or other CSV compatible application. You will need to remove lines feeds from the second, third, and fourth lines, which needed to be wrapped to fit into RFC line lengths. A.1. ParameterList.csv ,Dispatcher,,,,Messaging,,,Security,,,Transport, Harrington & Schoenwaelder Expires August 9, 2007 [Page 31] =0C Internet-Draft SNMP Transport Subsystem February 2007 ,sendPDU,returnResponse,processPDU,processResponse, prepareOutgoingMessage,prepareResponseMessage,prepareDataElements, generateRequest,processIncoming,generateResponse, sendMessage,receiveMessage transportDomain,In,,,,In,,In,,,,,In transportAddress,In,,,,In,,In,,,,,In destTransportDomain,,,,,Out,Out,,,,,In, destTransportAddress,,,,,Out,Out,,,,,In, messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,, securityModel,In,In,In,In,In,In,Out,In,In,In,, securityName,In,In,In,In,In,In,Out,In,Out,In,, securityLevel,In,In,In,In,In,In,Out,In,In,In,, contextEngineID,In,In,In,In,In,In,Out,,,,, contextName,In,In,In,In,In,In,Out,,,,, expectResponse,In,,,,In,,,,,,, PDU,In,In,In,In,In,In,Out,,,,, pduVersion,In,In,In,In,In,In,Out,,,,, statusInfo,Out,In,,In,,In,Out,Out,Out,Out,, errorIndication,Out,Out,,,,,Out,,,,, sendPduHandle,Out,,,In,In,,Out,,,,, maxSizeResponsePDU,,In,In,,,In,Out,,Out,,, stateReference,,In,In,,,In,Out,,,,, wholeMessage,,,,,Out,Out,In,Out,In,Out,In,In messageLength,,,,,Out,Out,In,Out,In,Out,In,In Harrington & Schoenwaelder Expires August 9, 2007 [Page 32] =0C Internet-Draft SNMP Transport Subsystem February 2007 maxMessageSize,,,,,,,,In,In,In,, globalData,,,,,,,,In,,In,, securityEngineID,,,,,,,,In,Out,In,, scopedPDU,,,,,,,,In,Out,In,, securityParameters,,,,,,,,Out,In,Out,, securityStateReference,,,,,,,,,Out,In,, pduType,,,,,,,Out,,,,, tmStateReference,,,,,Out,Out,In,,In,,In,In Appendix B. Why tmStateReference? This appendix considers why a cache-based approach was selected for passing parameters. There are four approaches that could be used for passing information between the Transport Model and a Security Model. 1. one could define an ASI to supplement the existing ASIs, or 2. one could add a header to encapsulate the SNMP message, 3. one could utilize fields already defined in the existing SNMPv3 message, or 4. one could pass the information in an implementation-specific cache or via a MIB module. B.1. Define an Abstract Service Interface Abstract Service Interfaces (ASIs) are defined by a set of primitives that specify the services provided and the abstract data elements that are to be passed when the services are invoked. Defining additional ASIs to pass the security and transport information from the Transport Subsystem to Security Subsystem has the advantage of being consistent with existing RFC3411/3412 practice, and helps to ensure that any Transport Model proposals pass the necessary data, and do not cause side effects by creating model-specific dependencies between itself and other models or other subsystems other than those that are clearly defined by an ASI. B.2. Using an Encapsulating Header A header could encapsulate the SNMP message to pass necessary information from the Transport Model to the dispatcher and then to a Harrington & Schoenwaelder Expires August 9, 2007 [Page 33] =0C Internet-Draft SNMP Transport Subsystem February 2007 Message Processing Model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding Message Processing Model. This would imply the (one and only) messaging dispatcher would need to be modified to determine which SNMP message version was involved, and a new Message Processing Model would need to be developed that knew how to extract the header from the message and pass it to the Security Model. B.3. Modifying Existing Fields in an SNMP Message [RFC3412] defines the SNMPv3 message, which contains fields to pass security related parameters. The Transport Subsystem could use these fields in an SNMPv3 message, or comparable fields in other message formats to pass information between Transport Models in different SNMP engines, and to pass information between a Transport Model and a corresponding Message Processing Model. If the fields in an incoming SNMPv3 message are changed by the Transport Model before passing it to the Security Model, then the Transport Model will need to decode the ASN.1 message, modify the fields, and re-encode the message in ASN.1 before passing the message on to the message dispatcher or to the transport layer. This would require an intimate knowledge of the message format and message versions so the Transport Model knew which fields could be modified. This would seriously violate the modularity of the architecture. B.4. Using a Cache This document describes a cache, into which the Transport Model puts information about the security applied to an incoming message, and a Security Model can extract that information from the cache. Given that there might be multiple TM-security caches, a tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem and the Security Subsystem, so the Security Model knows which cache of information to consult. This approach does create dependencies between a specific Transport Model and a corresponding specific Security Model. However, the approach of passing a model-independent reference to a model- dependent cache is consistent with the securityStateReference already being passed around in the RFC3411 ASIs. Appendix C. Open Issues NOTE to RFC editor: If this section is empty, then please remove this open issues section before publishing this document as an RFC. (If it is not empty, please send it back to the editor to resolve. Harrington & Schoenwaelder Expires August 9, 2007 [Page 34] =0C Internet-Draft SNMP Transport Subsystem February 2007 o MUST responses go back on the same session? o How should we describe the case where a management system wants to keep session info available for inspection after a session has closed? see "Abstract Service Interfaces" o Do Informs work correctly? o How does a Transport Model know whether a message is a notification or a request/response? o cache contents - do we define this? Appendix D. Change Log NOTE to RFC editor: Please remove this change log before publishing this document as an RFC. Changes from revision -05- to -06- mostly editorial changes removed some paragraphs considered unnecessary added Updates to header modified some text to get the security details right modified text re: ASIs so they are not API-like cleaned up some diagrams cleaned up RFC2119 language added section numbers to citations to RFC3411 removed gun for political correctness Changes from revision -04- to -05- removed all objects from the MIB module. changed document status to "Standard" rather than the xml2rfc default of informational. changed mention of MD5 to SHA moved addressing style to TDomain and TAddress modified the diagrams as requested removed the "layered stack" diagrams that compared USM and a Transport Model processing removed discussion of speculative features that might exist in future Transport Models removed openSession and closeSession ASIs, since those are model- dependent removed the MIB module removed the MIB boilerplate intro (this memo defines a SMIv2 MIB ...) removed IANA considerations related to the now-gone MIB module removed security considerations related to the MIB module Harrington & Schoenwaelder Expires August 9, 2007 [Page 35] =0C Internet-Draft SNMP Transport Subsystem February 2007 removed references needed for the MIB module changed receiveMessage ASI to use origin transport domain/address updated Parameter CSV appendix Changes from revision -03- to -04- changed title from Transport Mapping Security Model Architectural Extension to Transport Subsystem modified the abstract and introduction changed TMSM to TMS changed MPSP to simply Security Model changed SMSP to simply Security Model changed TMSP to Transport Model removed MPSP and TMSP and SMSP from Acronyms section modified diagrams removed most references to dispatcher functionality worked to remove dependencies between transport and security models. defined snmpTransportModel enumeration similar to snmpSecurityModel, etc. eliminated all reference to SNMPv3 msgXXXX fields changed tmSessionReference back to tmStateReference Changes from revision -02- to -03- o removed session table from MIB module o removed sessionID from ASIs o reorganized to put ASI discussions in EOP section, as was done in SSHSM o changed user auth to client auth o changed tmStateReference to tmSessionReference o modified document to meet consensus positions published by JS o * authoritative is model-specific * msgSecurityParameters usage is model-specific * msgFlags vs. securityLevel is model/implementation-specific * notifications must be able to cause creation of a session * security considerations must be model-specific * TDomain and TAddress are model-specific * MPSP changed to SMSP (Security Model security processing) Changes from revision -01- to -02- o wrote text for session establishment requirements section. o wrote text for session maintenance requirements section. o removed section on relation to SNMPv2-MIB o updated MIB module to pass smilint Harrington & Schoenwaelder Expires August 9, 2007 [Page 36] =0C Internet-Draft SNMP Transport Subsystem February 2007 o Added Structure of the MIB module, and other expected MIB-related sections. o updated author address o corrected spelling o removed msgFlags appendix o Removed section on implementation considerations. o started modifying the security boilerplate to address TMS and MIB security issues o reorganized slightly to better separate requirements from proposed solution. This probably needs additional work. o removed section with sample protocols and sample tmSessionReference. o Added section for acronyms o moved section comparing parameter passing techniques to appendix. o Removed section on notification requirements. Changes from revision -00- o changed SSH references from I-Ds to RFCs o removed parameters from tmSessionReference for DTLS that revealed lower layer info. o Added TMS-MIB module o Added Internet-Standard Management Framework boilerplate o Added Structure of the MIB Module o Added MIB security considerations boilerplate (to be completed) o Added IANA Considerations o Added ASI Parameter table o Added discussion of Sessions o Added Open issues and Change Log o Rearranged sections Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Harrington & Schoenwaelder Expires August 9, 2007 [Page 37] =0C Internet-Draft SNMP Transport Subsystem February 2007 Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Harrington & Schoenwaelder Expires August 9, 2007 [Page 38] =0C Internet-Draft SNMP Transport Subsystem February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harrington & Schoenwaelder Expires August 9, 2007 [Page 39] =0C ------=_NextPart_000_0C72_01C7498D.75AFF270 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0C72_01C7498D.75AFF270-- From isms-bounces@lists.ietf.org Wed Feb 07 06:08:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkfB-0002bR-Fv; Wed, 07 Feb 2007 06:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkf9-0002YP-R5 for isms@ietf.org; Wed, 07 Feb 2007 06:08:31 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEkf7-0000OZ-Ba for isms@ietf.org; Wed, 07 Feb 2007 06:08:31 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8A34B5ADE6 for ; Wed, 7 Feb 2007 12:08:24 +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 00944-01 for ; Wed, 7 Feb 2007 12:08:21 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 07A5A5ADEA for ; Wed, 7 Feb 2007 12:07:49 +0100 (CET) Received: by gagas-computer.local (Postfix, from userid 501) id DBC80C71F6; Fri, 2 Feb 2007 12:47:41 +0100 (CET) Date: Fri, 2 Feb 2007 12:47:41 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070202114741.GA889@gagas-computer.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.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Isms] [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic] 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, please note the deadlines - especially the editors of the Radius document. /js ----- Forwarded message from ietf-secretariat@ietf.org ----- To: ietf-announce@ietf.org Cc: From: ietf-secretariat@ietf.org Date: Fri, 02 Feb 2007 00:00:01 -0500 Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic Precedence: list Errors-To: ietf-announce-bounces@ietf.org There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 07 09:39:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnxW-0008Ac-Up; Wed, 07 Feb 2007 09:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBg3f-0000M4-7L for isms@lists.ietf.org; Mon, 29 Jan 2007 18:37:07 -0500 Received: from omr8.networksolutionsemail.com ([205.178.146.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBg3e-00061x-HR for isms@lists.ietf.org; Mon, 29 Jan 2007 18:37:07 -0500 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0TNb6Tc008536 for ; Mon, 29 Jan 2007 18:37:06 -0500 Received: (qmail 19088 invoked by uid 78); 29 Jan 2007 23:37:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 29 Jan 2007 23:37:05 -0000 Message-ID: <45BE8535.1040003@andybierman.com> Date: Mon, 29 Jan 2007 15:37:25 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: isms@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 X-Mailman-Approved-At: Wed, 07 Feb 2007 09:39:42 -0500 Cc: Subject: [Isms] review of draft-ietf-isms-tmsm-05 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 was asked to review the transport subsystem draft. I hope these comments help. Andy Review of draft-ietf-isms-tmsm-05 Abstract This section is a bit redundant and vague. It is not very clear why a transport sub-system is needed, and is being added now, so many years after SNMP Arch was done. I know SNMP doesn't like to confine any system components, so there is "an" architecture instead of "the" architecture, but IMO, this document needs to be more normative, and more clear about what is being defined (normative) vs. discussed (informational). 2. Motivation The home security analogy is not very clear. Consider introducing this section with a sentence that securing a network protocol is like securing a home or business, and make it clear that this intro relates to the following paragraphs in this section. This document describes a Transport Subsystem extension to the RFC3411 architecture. Which approach (of the 3 choices) does this document take? The diagram on pg. 5 should be introduced and quickly explained where this document fits into the diagram. pg. 6: SNMP continues to work without any surprises. Expand or add an example of the kind of surprise that this document addresses. I assume you mean non-transparent inter-operability with an SNMP peer by "no surprises". That should be explained here. pg 7: Transport models MUST be able to coexist with other transport models, and may be designed to utilize either TCP or UDP or SCTP. The section leading up to this last sentence is really good, but SCTP is not mentioned at all, and then this summary sentence suggests supporting it. In the first sentence, suggest changing "other transport models" to "each other". pg. 8: missing space The RFC3411 architecture,and the USM assume that a security model is ^ pg. 9 diagram: Can you highlight what is new vs. already in place for SNMP? There is a caption that says (traditional SNMP agent) but this is not clear, since it shows new transports TCP, SSH, and TLS. It is an excellent diagram, but could be explained a bit more. Sec 3.2.1 General: It is not clear what is existing and what is new in these procedures. 3.2.1.1. USM and the RFC3411 Architecture The following diagrams illustrate the difference in the security Do you mean previous diagram, since this is on pg. 10? 3.2.2. Access Control Requirements General: Would help to have an executive summary at the start of this section (like a table) that lists what new things the 3.2.2.* sections are going to explain. 3.2.2.1. securityName Binding processing model via the processIncoming() ASI. This translation should remove parens ^^ If the type of authentication provided by the transport layer (e.g. (several places) missing comma ^ pg 12: A transport model must not specify how the securityModel and securityName could be dynamically mapped to an access control mechanism, such as a VACM-style groupName. The mapping of (securityModel, securityName) to a groupName is a VACM-specific mechanism for naming an access control policy, and for tying the named policy to the addressing capabilities of the data modeling language (e.g. SMIv2 [RFC2578]), the operations supported, and other factors. Providing a binding outside the Access Control subsystem might create dependencies that could make it harder to develop alternate models of access control, such as one built on UNIX groups or Windows domains. The preferred approach is to pass the model- independent security parameters via the isAccessAllowed() ASI, and perform the mapping from the model-independent security parameters to an authorization-model-dependent access policy within the access control model. To provide support for protocols which simultaneously send information for authentication and authorization, such as RADIUS [RFC2865], model-specific authorization information MAY be cached or otherwise made available to the access control subsystem, e.g., via a MIB table similar to the vacmSecurityToGroupTable, so the access control subsystem can create an appropriate binding between the model-independent securityModel and securityName and a model-specific access control policy. This may be highly undesirable, however, if it creates a dependency between a transport model or a security model and an access control model, just as it is undesirable for a transport model to create a dependency between an SNMP message version and the security provided by a transport model. A summary table gathering all the requirements from large paragraphs (like the 2 above) would be helpful. 3.2.3. Security Parameter Passing Requirements A table summarizing the security parameters would be helpful. It would be useful to refer back to the diagram as to the specific information flow or ASI in question. This document describes a cache mechanism, into which the transport model puts information about the transport and security parameters Describes or defines? A section number reference would be good here. 3.3. Session Requirements Some secure transports may have a notion of sessions, while other secure transports might provide channels or other session-like thing. s/thing/mechanism/ Throughout this document, the term session is used in a broad sense to cover sessions, channels, and session-like things. Session refers s/things/mechanisms/ It is important to note that the architecture described in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for the transport subsystem, so an SNMP application cannot select the session except by passing a unique combination of transport type, transport address, securityName, securityModel, and securityLevel. This seems like a very important paragraph (and requirement). It would be nice to explain why all these parameters are needed to identify a session. All transport models should discuss the impact of sessions on SNMP usage, including how to establish/open a transport session (i.e., how it maps to the concepts of session-like things of the underlying protocol), how to behave when a session cannot be established, how to close a session properly, how to behave when a session is closed improperly, the session security properties, session establishment overhead, and session maintenance overhead. To reduce redundancy, this document will discuss aspects that are expected to be common to all transport model sessions. IMO, 'define' (not 'discuss') should be used when referring to standards track documents. A summary (somewhere in the doc) of all the requirements this spec defines + another summary of the requirements that are expected to be defined externally. 3.3.1. Session Establishment Requirements SNMP Applications typically have no knowledge of whether the session that will be used to carry commands was initially established as a notification session, or a request-response session, and SHOULD NOT make any assumptions based on knowing the direction of the session. Is this true? Why doesn't the session initiator know what type of session is being requested? If an administrator or transport model designer wants to differentiate a session established for different purposes, such as a notification session versus a request-response session, the application can use different securityNames or transport addresses (e.g., port 161 vs. port 162) for different purposes. Is this a normative definition? Maybe a use case and example diagram would be helpful. An SNMP engine containing an application that initiates communication, e.g., a Command Generator or Notification Originator, MUST be able to attempt to establish a session for delivery if a session does not yet exist. If a session cannot be established then the message is discarded. Does the application know it is establishing a session? Are the sessions just a transport layer mechanism? Some explanation of the document I should have read before starting this document should be in the Introduction section. If a session can be reused for a different type of message, but a receiver is not prepared to accept different message types over the same session, then the message MAY be dropped by the receiver. This may strongly affect the usefulness of session reuse, and transport models should define a standard behavior for this circumstance. IMO, this document should define the behavior, and not pass it to the transport implementation. Silently dropping messages in a purposely undefined way is not good standards practice. 3.3.2. Session Maintenance Requirements A transport model can tear down sessions as needed. It may be necessary for some implementations to tear down sessions as the result of resource constraints, for example. I am unclear on the session model here wrt/ which components are aware of sessions. Does the application initiate session control or not? I usually think of sessions as user-controlled and user-configured inactivity timeout. Is that what is meant by resource constraints? The decision to tear down a session is implementation-dependent. Why? Why isn't session control requirements part of the standard? 3.3.3. Message security versus session security ... SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because there is not much value in using encryption for a Commander Generator to poll for non-sensitive performance data on thousands of interfaces every ten minutes; the encryption may add significant overhead to processing of the messages. Should note that this non-sensitive polling is an example, not imply this is the only reason for per-message security. 4.1. Command Generator or Notification Originator This diagram from RFC3411 4.6.1 shows how a Command Generator or Notification Originator application [RFC3413] requests that a PDU be sent, and how the response is returned (asynchronously) to that application. I don't see how the diagrams in sec 4. relate to sessions and to the transport sub-system. 5. Cached Information and References This document differentiates the tmStateReference from the securityStateReference. Suggest providing some context as to what these variables are, and how they are different. 5.1. securityStateReference A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC3411 section 4.5.1." Is securityStateReference a new construct or something from RFC 3411? The information saved should include the model-independent parameters (transportDomain, transportAddress, securityName, securityModel, and securityLevel), related security parameters, and other information needed to imatch the response with the request. The Message sp. ^^^^^^ If the transport model connection is closed between the time a Request is received and a Response message is being prepared, then the Response message MAY be discarded. What other options would be appropriate? 5.2. tmStateReference For each message or transport session, information about the message security is stored in a cache, which may inlcude model- and sp. ^^^^^^^ 6. Abstract Service Interfaces An error indication may return an OID and value for an incremented counter and a value for securityLevel, and values for contextEngineID and contextName for the counter, and the securityStateReference if the information is available at the point where the error is detected. Which error indication? Response to what operation? 6.2. Processing for an Outgoing Message The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate transport model for sending. statusInformation = sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- reference to transport state ) Are there any changes to this ASI? What is the purpose of this section? 6.3. Processing an Incoming SNMP Message 6.3.1. Processing an Incoming Message If one does not exist, the Transport Model will need to create an entry in a Local Configuration Datastore referenced by tmStateReference. This information will include transportDomain, transportAddress, the securityModel, the securityLevel, and the securityName, plus any model or mechanism-specific details. How this information is determined is model-specific. Model-specific? This is kind of a new term. Implementation-specific has been raised so far, but not this. 6.3.2. Prepare Data Elements from Incoming Messages The abstract service primitive from the Dispatcher to a Message Processing Model for a received message is: .... Note that tmStateReference has been added to this ASI. Should explain how the ASI semantics change due to the new parameter. 6.3.3. Processing an Incoming Message Should explain how the ASI semantics change due to the new parameter. 7. Security Considerations secret keys does not result in disclosure of past session keys. The editors recommend that each proposed transport model include a discussion in its security considerations of whether perfect forward security is appropriate for the transport model. The editors recommend does not sound very official. Since the cache and LCD will contain security-related parameters, they should be kept in protected storage. What exactly is meant by protected? [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-06 (work in progress), March 2006. Update reference to RFC 4742. Appendix A. Parameter Table Following is a CSV formatted matrix useful for tracking data flows into and out of the dispatcher, transport, message, and security subsystems. Import this into your favorite spreadsheet or other CSV compatible application. You will need to remove lines feeds from the second, third, and fourth lines, which needed to be wrapped to fit into RFC limits. A.1. ParameterList.csv Not clear what this section is for. The syntax is very cryptic. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 07 15:51:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtlX-0006Fj-QL; Wed, 07 Feb 2007 15:51:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkx-00056P-HT; Wed, 07 Feb 2007 15:51:07 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtku-0002cy-Rc; Wed, 07 Feb 2007 15:51:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E31452ACA9; Wed, 7 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001b1-Ln; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-05.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-05.txt Pages : 39 Date : 2006-12-14 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7111045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7111045.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Mon Feb 12 15:15:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGha1-0004Rh-PU; Mon, 12 Feb 2007 15:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGha0-0004Rb-FO for isms@ietf.org; Mon, 12 Feb 2007 15:15:16 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGhZz-0001W4-2a for isms@ietf.org; Mon, 12 Feb 2007 15:15:16 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5311855D11 for ; Mon, 12 Feb 2007 21:15:07 +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 08435-06; Mon, 12 Feb 2007 21:15:04 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3C6825ACFA; Mon, 12 Feb 2007 21:15:04 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id C3AC5199F49; Mon, 12 Feb 2007 21:15:01 +0100 (CET) Date: Mon, 12 Feb 2007 21:15:01 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070212201501.GB944@elstar.iuhb02.iu-bremen.de> 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.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Isms] wg meeting at the 68th ietf in prague 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, we asked for a one hour meeting slot in Prague and it got scheduled for Thursday 1510-1610. Note that this is a DRAFT schedule and may still change. For more details, see https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=68 /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 13 08:59:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyBU-0005lc-8J; Tue, 13 Feb 2007 08:59:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyBT-0005jP-Ac for isms@ietf.org; Tue, 13 Feb 2007 08:59:03 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGyBN-0005pa-RW for isms@ietf.org; Tue, 13 Feb 2007 08:59:03 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0AD905AD31; Tue, 13 Feb 2007 14:58:55 +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 19544-01; Tue, 13 Feb 2007 14:58:51 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 734AF5AD2D; Tue, 13 Feb 2007 14:58:49 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 0E00C19D3C3; Tue, 13 Feb 2007 14:58:46 +0100 (CET) Date: Tue, 13 Feb 2007 14:58:46 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20070213135846.GA18604@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <04db01c740e2$1184f060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04db01c740e2$1184f060$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: isms@ietf.org Subject: [Isms] review of draft-ietf-isms-transport-security-model-02 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, I have gone through this document and I have a few comments; most of them I think are rather easy to resolve. a) spell out AAA the first time this acronym is used b) p6: s/authenticatio and/authentication and/ c) The document in several places talks about transportType but this really is transportDomain called in the architecture and the ASIs. d) p7: s/modles/models/ In the paragraph, change "security" to "security model". e) There are places with quite some repetitions - cutting the repetions might shorten the ID quite a bit. For example, section 3 repeats many details from RFC 3412 - this could be much shorter by just stating which things actually change. It is also stated multiple times how the securityLevel and the level of s ecurity provided by the transport relate. f) I am confused about msgSecurityParameters. Does it simply encode to '0400'h or does it contain a ber serialization of a zero length octet string, that is '04020400'? I was hoping the first option, but the ASN.1 definition (which should be (SIZE (0))) makes me believe the second option is meant. g) The first step in the EoP (section 4.2) seems interesting since you try to verify that the message processing model did its work correctly. We do not have such a check in the USM as far as I can tell and I am not sure we should go down that path of verifying everywhere that the other parts of the system work correctly. h) Step 4 in the EoP again seems to step on what RFC 3412 is doing (see step 7e) in section 7.1 or RFC 3412). i) Step 5 in the EoP also seem to be covered by RFC 3412 7e). j) In step 9, I suggest to drop "and securityParameters (a zero-length octet string)" since you can't return a wholeMsg without it. k) Like before, I question the need for step 1) in section 5.2. l) You want to capitalize the beginning of all steps in section 5. m) Section 6.2. can probably be removed because the MIB does not use any TCs. n) In section 8, I am not sure the phrase ", for access control purposes" is particularly clear. I would suggest to drop it. If you keep it, you probably have to spend some more text to explain what goes into an access control decision (but since we do not change anything, I think such an explanation is not needed). o) p21: s/Secuirty/Security/ p) Are RFCs 3413, 3414, 3416, 3584 really all normative references? Dave, perhaps you can take a look at my list above and post a new ID. Since I believe the text is fairly complete, we can consider to move this document into last call mode so that we get more people to look at this in more detail before the meeting in Prague. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Feb 16 08:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3DH-00026x-KQ; Fri, 16 Feb 2007 08:33:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3DF-00026L-Nn for isms@ietf.org; Fri, 16 Feb 2007 08:33:21 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3AU-0002vL-Gm for isms@ietf.org; Fri, 16 Feb 2007 08:30:31 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007021613303001200pom4te>; Fri, 16 Feb 2007 13:30:30 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 08:26:26 -0500 Message-ID: <166801c751ce$0f3c2060$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 Thread-index: AcdRzaAvRMwhMONdRvamIiUqWaLe5A== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Isms] Issue#5: Do Informs work correctly? 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 >From Jeff Case: (from message forwarded to WG by JS on 1/10) "i mention this because the experience with the project causes me to question one of the draft's fundamental tenets -- that you can do what you want to do without being forced to compromise anything in arch, v3mp, and/or usm in particular, while your design probably works flawlessly for gets and sets, and might work for traps as well, it would be helpful if you could explain to me how informs work in a way that is consistent with the above specs (yes, i read and reread page 15 several times including the waffle words found therein but maybe i am just dense and/or missed something somewhere else)" We never got Jeff to elaborate further. So the WG should look at Informs in STD62, and determine how they differ from all other operations. We know USM differs in its handling of Informs; are there non-USM differences? Then look at the EOP in tmsm, and verify that informs work appropriately. 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 Fri Feb 16 08:35:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3Fe-00034B-FS; Fri, 16 Feb 2007 08:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3Fd-00033q-Gg for isms@ietf.org; Fri, 16 Feb 2007 08:35:49 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3Fc-0005NT-BD for isms@ietf.org; Fri, 16 Feb 2007 08:35:49 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <20070216133547011005i4epe>; Fri, 16 Feb 2007 13:35:47 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 08:31:44 -0500 Message-ID: <166901c751ce$cd267170$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 Thread-index: AcdRzhifMwc+NCmUSJCOEN1c2zqK9Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Isms] Tmsm-06 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 submitted tmsm-06- last week, but somehow -05- simply got re-announced and republished. I submitted -06- again. Hopefully it will show up today. It addresses almost all comments received during WGLC. There are some open issues that I will post to the list. 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 Fri Feb 16 08:41:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3Kn-00006e-2S; Fri, 16 Feb 2007 08:41:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3Km-00006X-B9 for isms@ietf.org; Fri, 16 Feb 2007 08:41:08 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3Kl-0006iD-5S for isms@ietf.org; Fri, 16 Feb 2007 08:41:08 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007021613410601400s3usle>; Fri, 16 Feb 2007 13:41:06 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 08:37:04 -0500 Message-ID: <166a01c751cf$8bb084f0$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 Thread-index: AcdRzyi1L4F5Qe9lQLSaQLKr2+POlg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Isms] Tmsm non-issues? 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 posted responses to each review of -05-. I identified 5 issues I feel are open. But the WG needs to review my responses to the reviews to make sure you agree with my treatment of the issues raised. All my response emails are dated from 2/1 to 2/6. 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 Fri Feb 16 08:51:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3Ua-0000JL-Ky; Fri, 16 Feb 2007 08:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3UZ-0000JG-V4 for isms@ietf.org; Fri, 16 Feb 2007 08:51:15 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3UY-0001bb-OP for isms@ietf.org; Fri, 16 Feb 2007 08:51:15 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <20070216135114011005fkkre>; Fri, 16 Feb 2007 13:51:14 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 08:47:12 -0500 Message-ID: <166b01c751d0$f5d31f90$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 Thread-index: AcdR0F+9rLH8LFsNRhmA0zWbsx6raQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Isms] Tmsm#1: MUST Responses go back on the same channel? 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 >From Wes Hardaker (1/9/07): > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > *** *** *** > Responses are expected to > be returned using the same session that carried the corresponding > request message. Reuse of sessions is not required for > conformance. > > Um... IMHO, this should be a MUST. There are security implications > if you send a response over a different session than the request came > in over. Different sessions may use different cryptographic > properties > (algorithms, etc). Plus, once you start doing that you can actually > play with the timing of messages as they arrive at the other end by > slowing one session down and not the other, etc. > > This, IMHO, is critical that responses go back on the same session. > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > *** *** *** There have been comments, prior to WGLC, saying this should not be architecturally-mandatory, but should depend on the transport model and/or security model. 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 Fri Feb 16 09:02:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3es-0005Rc-Hq; Fri, 16 Feb 2007 09:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3eq-0005RD-RD for isms@ietf.org; Fri, 16 Feb 2007 09:01:52 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3ep-0004a2-Ku for isms@ietf.org; Fri, 16 Feb 2007 09:01:52 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007021614015101400s419te>; Fri, 16 Feb 2007 14:01:51 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 08:57:49 -0500 Message-ID: <166c01c751d2$71865700$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 Thread-index: AcdR0bRAGF+5Kcf1QzymeESEQ8iXHA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Isms] Tmsm#4: persistent session info 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 >From Wes (1/9/07): > ----- > and if state > information is available when a session is closed, the > session state > information should also be released. > > Unless the management system indicates that the state should remain > around for a longer period of time to allow for data collection about > the session to occur. See David Perkins for details. Dbh response: I can understand the desire to have session info last longer than the session, but the state info (in the LCD) is used to determine if a session exists, so keeping it around in the LCD might be problematic, unless it is somehow marked as expired. Since we are not writing a MIB to represent this, I am not sure how we want to address the implications of this issue here. I have not heard from Dave Perkins on this issue at all. The LCD is implementation-specific; as compared to the rfc341x docs, we are not defining the LCD in MIB modules, but leaving it entirely up to implementers to decide whether to use an LCD, the format of the LCD, and so on. We have explicitly stated that release of memory/resources for the cache and LCD are implementation-specific. Therefore, I think we probably do not need to say anything about this issue. 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 Fri Feb 16 09:47:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4NQ-0005gm-Pv; Fri, 16 Feb 2007 09:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4NP-0005d7-Cp for isms@ietf.org; Fri, 16 Feb 2007 09:47:55 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4NO-0000VO-2m for isms@ietf.org; Fri, 16 Feb 2007 09:47:55 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <20070216144753013007saqne>; Fri, 16 Feb 2007 14:47:53 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 09:43:50 -0500 Message-ID: <166d01c751d8$dfc23120$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 Thread-index: AcdR2F62NG6Z5+q8RIy4TBoFtdNPWQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [Isms] Tmsm#3: session reuse issues 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 >From Bert (1/12): "> - last para of sect 3.3.1 (page 15/16) states: > > If a session can be reused for a different type of message, but a > receiver is not prepared to accept different message > types over the > same session, then the message MAY be dropped by the > receiver. This > may strongly affect the usefulness of session reuse, and transport > models should define a standard behavior for this circumstance. > > Mmm... "type of message" ? I only see this term occur once > in RFC3411. > It basically is the PDU type. But OK, I can live with it. > I am worried about the fact that "a transport model needs to define > standard behaviour for this". How/where does a transport model > know about the message type (or PDU type) ?? The pduType is passed > between Dispatcher and MP model (in the ASIs), but I do not see it > passed from the dispatcher to transport subsystem. Is the TM > suppsoed to go dig into the PDU itself? I hope not. DBH: "Hmmm. I'm not sure how a transport model knows this. I am not a fan of session reuse, so my heart won't be broken if we simply drop this whole thing, and the transport model finds the right session by its transport address (e.g., port 161 or 162). I'll add this to the open issues section." Bert: "So how did it get included in the first place? I guess there were some people who see a need for it? If so, then we need to figure out how the transport would know about it, or how this is/can be done otehrwise." Separtely from Andy Bierman (1/29): "> SNMP Applications typically have no knowledge of whether > the session > that will be used to carry commands was initially established as a > notification session, or a request-response session, and SHOULD NOT > make any assumptions based on knowing the direction of the session. > > Is this true? Why doesn't the session initiator know what type > of session is being requested?" DBH response: There was WG consensus to permit transport-session reuse, including for different types of messages (request/response vs notification), and the reuse decision is made by the transport-specific model. Because of this, an application does not know whether it is the first to request a session with these security parameters (including direction), and if it is not the first, whether the session was initially opened as a request/response session or as a notification session. Andy: "> An SNMP engine containing an application that initiates > communication, e.g., a Command Generator or Notification > Originator, > MUST be able to attempt to establish a session for delivery if a > session does not yet exist. If a session cannot be > established then > the message is discarded. > > Does the application know it is establishing a session? > Are the sessions just a transport layer mechanism? > Some explanation of the document I should have read before > starting this document should be in the Introduction section." DBH response: No, the application does not necessarily know if it is establishing a session; the session is a transport-specific mechanism. The session might already exist, started by a different application, and might be reused for this message. The application might specify a session it has used before (using domain/address/name/model/level), but the session might have been closed for various reasons, so this message might cause the establishment of a new session. Andy: "> If a session can be reused for a different type of message, but a > receiver is not prepared to accept different message types over the > same session, then the message MAY be dropped by the > receiver. This > may strongly affect the usefulness of session reuse, and transport > models should define a standard behavior for this circumstance. > > IMO, this document should define the behavior, and not pass it > to the transport implementation. Silently dropping messages > in a purposely undefined way is not good standards practice." DBH response: The whole idea of session reuse has never been used with SNMP before, or any other widely-deployed IETF NM protocol (if there were any), and I don't know that we understand how session reuse will be impacted by different security protocols, or how session reuse will impact certain security protocols, or what the impact to SNMP interoperability will be. I don't think we have enough understanding of the impacts of discarding a message sent through a reused session to define what the normative behavior should be for all transport models at this point. 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 Fri Feb 16 09:53:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4SR-0000lu-O6; Fri, 16 Feb 2007 09:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4SR-0000lp-5z for isms@ietf.org; Fri, 16 Feb 2007 09:53:07 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4SP-0001os-Vd for isms@ietf.org; Fri, 16 Feb 2007 09:53:07 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <20070216145305013007vsate>; Fri, 16 Feb 2007 14:53:05 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 09:49:02 -0500 Message-ID: <166e01c751d9$9944e250$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 Thread-index: AcdR2RW/9gOIXIR0Tme8jSmlHAkMTw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Isms] Tmsm#3: session reuse - continued 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 was a response to Bert that I left out of the earlier posting: "Sessions are a transport-specific issue, and are controlled by a transport model. A transport model has no idea which application has requested that a message be sent; it typically only knows transportDomain/Address and securityName/Model/Level. If a session already exists that matches those parameters, it reuses it. The transport model does not necessarily know whether the session was first established to send a request or a notification. I'm not sure if the transport model actually needs to deal with this. The message MAY be dropped on the floor when a notification is sent to a port that is enabled only for request/response traffic, or a request was sent to a port configured only for notification traffic, or an agent sends a GET-request to an NMS. It seems unlikely a response would be sent to a port unwilling to accept responses, since we usually send the response back to the port the request came from. The message-processing model keeps track of outstanding expectResponses, so it should probably be aware that no response message was returned, when the remote node dropped a request message (including inform) on the floor. If it was a trap, it would not be expecting a response anyway. If it is an unexpected GET, there will be no registered application for that pduType, so it would be dropped anyway. So it should probably be the message processing model or the application that needs to know how to deal with dropped messages. I removed the text that says a transport model needs to define a stndard behavior." 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 Fri Feb 16 10:03:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4cj-0001Xl-LW; Fri, 16 Feb 2007 10:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4ci-0001Xe-AQ for isms@ietf.org; Fri, 16 Feb 2007 10:03:44 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4cg-00046h-0T for isms@ietf.org; Fri, 16 Feb 2007 10:03:44 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <20070216150341011005f6g2e>; Fri, 16 Feb 2007 15:03:41 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 09:59:38 -0500 Message-ID: <166f01c751db$14408990$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 Thread-index: AcdR2mM3og+oS7usR2qQjGGhA/0P8w== X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Isms] Tmsm#2: cache contents 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 >From Bert Wijnen (1/12): "> - I am not 100% sure, but is it correct that section 5.1. about the > securityStateReference is not adding any new (or changing any > existing) information compared to RFC3411? > If so, I would prefer we state that explicitly. > If it does add something, pls make it clear what is being > added/changed. > > - Section 5.2 > I think (but it is not clear) that the transport model should save > a mapping from transport security/authentication ID to seucirtyName > so the the Security Model can pick it up and pass it back as an > OUT parameter on the processIncomingMessage ASI,. no?" Dbh response: Yes, this information should be saved in one of the caches. The format and contents of the caches are implementation-specific however, so I don't know what information we can discuss. The transport model might also need to know the authentication algorithm, the integity-checking and encryption parameters, and so on. These are very much transport-model specific. The way we deal with it is to provide two caches - one for the request/response pair, and another for the session-like mechanism. It is up to the implementer to decide what goes where. Added to Open Issues for discussion." Bert: " I'd say we need to just state that thuis is what we expect, and that each specific transport model needs to be specific as to what kind of data needs to be saved in order tolet aSecurity Model be able to pick up the proper data that it needs." DBH: "The related security parameters may include transport-specific security information." I am not sure that the security experts would like to see MUST language about what needs to be included. This would potentially limit algorithm agility. It also might depend on the libraries they are using to implement; different libraries may require different parameters. So the cached information is transport-model and implementation dependent: "A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific." "For each message or transport session, information about the message security is stored in a cache, which may include model- and mechanism-specific parameters. The tmStateReference is passed between subsystems to provide a handle for the cache. A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific." To keep things modular, a secure transport model translates from transport-specific security principal to securityName, and passes the securityName in the cache. The transport model determines what security services were provided by the transport, and puts securityLevel into the cache. A security model does not need to know anything about the transport specific principal or services. The security model just takes securityName and securityLevel from the cache, already translated. Otherwise we would have a problem of requiring a specific security model for each specific transport model, something we definitely want to avoid. What happens with the cache depends on the security model called by the message processing model. Some might take the values from the cache to return to the MPM; some might just use parameters provided in a message security block and totally ignore the cache; some might use a mapping from a MIB module and totally ignore the cache. 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 Fri Feb 16 11:06:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5as-0003Pn-IL; Fri, 16 Feb 2007 11:05:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5ar-0003PY-7v for isms@ietf.org; Fri, 16 Feb 2007 11:05:53 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI5ap-0008Qy-VM for isms@ietf.org; Fri, 16 Feb 2007 11:05:53 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007021616055101400s75m1e>; Fri, 16 Feb 2007 16:05:51 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 11:01:48 -0500 Message-ID: <167c01c751e3$c3ba9700$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 Thread-index: AcdR4wperTn4Tmk0Q/K6Ny228/r4Ng== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Isms] Tmsm#6: double-authentication 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 did not originally consider this an open issue, but I suppose I should. - last para of sect 3.2.2.1 If the type of authentication provided by the transport layer (e.g. TLS) is considered adequate to secure and/or encrypt the message, but inadequate to provide the desired granularity of access control (e.g. user-based), then a second authentication (e.g., one provided via a RADIUS server) MAY be used to provide the authentication identity which is bound to the securityName. This approach would require a good analysis of the potential for man-in-the-middle attacks or masquerade possibilities. Bert (1/9): It does not say anything about at what point in the process steps this mapping from RADIUS authenticated identity to a securityName needs to take place. Maybe we want to leave that open. But it seems to me that the least we can say is that: it MUST bde done for incoming messages before the security model passes securityName to the message processing model via the processIncoming() ASI. DBH: I'm not sure that's true. If the goal is to get the identity for access control, it really only needs to get the securityname before it provides access control. If, for example, it uses RADIUS and does an authentication of the user and gets the authorization data, it could do this as part of the access control model. it doesn't need to be bound to the securityModel of the message, does it? I haven't spent time to consider the security implications of this, but I don't think we need to force this to be done a particular way. Of course, we do want to make sure the sender of the message is authorized to use the credentials that will authenticate the RADIUS request. Bert: First, none of the ASIs doe prescribe a particular way of implementation. The ASIs are to pass stuff between modularized documents. Second, although in theory it maybe OK to do it rigth before access control, I personally think it is cleaner (from a documentation modularity point of view) that it is done as I suggested. All the other ASIs have the securityName as a paramter, and so I think it is more consistent if that paramter is filled out before such a field is being passed around. DBH (new): I agree that the security model has the responsibility for determining for incoming messages which securityname/level parameters will passed to MPM, to be passed deeper into the system. [Just to be clear on this somewhat related point, the security model might determine securityname/level from the message itself (e.g. USM), or from a cache (e.g. TSM), or from a MIB (e.g. RFC3584 Community-SM); it is security-model-dependent how these are determined. They are passed to the MPM and then to the rest of the system.] The securityname/level/model parameters provided by MPM COULD be used by an access control model, but there is nothing that says the access control model MUST use them. Applications are the typical clients of the service(s) of the Access Control Subsystem. The MPM passes securityname/level/model to the disptacher, which passes them to the application. Assuming an application wanted to do so, the application could take the MPM-provided securityname/level/model (e.g. dbh/authpriv/tsm) and look up some RADIUS credentials (e.g. dharrington and some keys), talk to a RADIUS server to authenticate the principal (e.g. dharrington), and then use the RADIUS-supplied principal in the securityname/level/model parameters for the call to isAccessAllowed. An alternative (that is more consistent with RFC4311 modularity): An access control model could accept the securityName (e.g. dbh) provided by the securityModel-MPM-application in the isAccessAllowed ASI, and THEN could translate that into RADIUS parameters (dharrington), talk to RADIUS, and then use the RADIUS-principal (dharrington) as the mapping to securityName used in the VACM MIB. Again, I agree that the security model has the responsibility for determining for incoming messages which securityname/level parameters will passed to MPM, to be passed deeper into the system. But I think we want to be careful mandating that any "mapping from RADIUS authenticated identity to a securityName MUST be done for incoming messages before the security model passes securityName to the message processing model". 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 Fri Feb 16 15:50:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA2F-0001hR-Cd; Fri, 16 Feb 2007 15:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA1r-0001Q3-Kq; Fri, 16 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIA1q-0006vP-AY; Fri, 16 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 47862328F0; Fri, 16 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HIA1q-0000cD-5l; Fri, 16 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-06.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-06.txt Pages : 39 Date : 2007-2-16 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-16111122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-16111122.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Fri Feb 16 17:39:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBj8-0001Xx-Co; Fri, 16 Feb 2007 17:38:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBj7-0001Xr-QF for isms@ietf.org; Fri, 16 Feb 2007 17:38:49 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIBj3-0003xs-D8 for isms@ietf.org; Fri, 16 Feb 2007 17:38:49 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 562AE5AD1D; Fri, 16 Feb 2007 23:38:38 +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 21237-02; Fri, 16 Feb 2007 23:38:34 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id EA2985AD26; Fri, 16 Feb 2007 23:38:34 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CD22B19F849; Fri, 16 Feb 2007 23:38:32 +0100 (CET) Date: Fri, 16 Feb 2007 23:38:32 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm-06 Message-ID: <20070216223832.GA22448@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166901c751ce$cd267170$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166901c751ce$cd267170$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Feb 16, 2007 at 08:31:44AM -0500, David Harrington wrote: > I submitted tmsm-06- last week, but somehow -05- simply got > re-announced and republished. > I submitted -06- again. Hopefully it will show up today. > It addresses almost all comments received during WGLC. > There are some open issues that I will post to the list. Thanks Dave for going through the comments and posting a revised draft. Please check whether your comments have been addressed. You do not have to wait for the next last call; the earlier we receive feedback, the faster we can move. Dave also started threads for the open issues he has identified. Please comment on them - it would be nice if we can get them resolved on the list before the meeting in Prague. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Feb 16 18:36:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICcW-0008S1-0P; Fri, 16 Feb 2007 18:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICcT-0008Qu-Te for isms@ietf.org; Fri, 16 Feb 2007 18:36:01 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HICcS-0004KO-Jr for isms@ietf.org; Fri, 16 Feb 2007 18:36:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 069F055CCC; Sat, 17 Feb 2007 00:36:00 +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 24168-09; Sat, 17 Feb 2007 00:35:56 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id EA7E159526; Sat, 17 Feb 2007 00:35:56 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CC9461A3542; Sat, 17 Feb 2007 00:35:54 +0100 (CET) Date: Sat, 17 Feb 2007 00:35:54 +0100 From: Juergen Schoenwaelder To: David Harrington , isms@ietf.org Subject: Re: [Isms] Tmsm-06 Message-ID: <20070216233554.GB14203@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166901c751ce$cd267170$0600a8c0@china.huawei.com> <20070216223832.GA22448@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070216223832.GA22448@elstar.iuhb02.iu-bremen.de> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 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, Feb 16, 2007 at 11:38:32PM +0100, Juergen Schoenwaelder wrote: > Thanks Dave for going through the comments and posting a revised > draft. Please check whether your comments have been addressed. You > do not have to wait for the next last call; the earlier we receive > feedback, the faster we can move. Clarification: The intention is that those who submitted comments check whether they have been addresses (I should not have put two independent statements into one paragraph.) /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Feb 16 18:40:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICgo-0004Ry-Sp; Fri, 16 Feb 2007 18:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICgn-0004Oj-IH for isms@ietf.org; Fri, 16 Feb 2007 18:40:29 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HICgm-0004nQ-9r for isms@ietf.org; Fri, 16 Feb 2007 18:40:29 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <200702162340280150097ni7e>; Fri, 16 Feb 2007 23:40:28 +0000 From: "David Harrington" To: Date: Fri, 16 Feb 2007 18:36:24 -0500 Message-ID: <17b201c75223$456d1c20$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 Thread-index: AcdSEm1Mzo0ZrzMbQFKiQGnjufXf5wAD+4pg X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [Isms] Tmsm#6: double-authentication X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, This was posted to the ietf list today, and might have an impact on the double-authentication issue. The terminology of course differs from isms/snmp terminology, and I haven't gone through this thoroughly yet. (Wes or Jeff or Joe might be able to do analysis of relevance faster than I can.) dbh -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Friday, February 16, 2007 4:35 PM To: ietf@ietf.org Subject: New text in draft-housley-aaa-key-mgmt-08.txt I'd like to draw your attention to changes made to resolve my discuss comments on Russ's key management draft. The authenticate all parties section has been changed to the following new text. Please let us know if you have concerns about the text; the draft is scheduled for approval in somewhat over a week. Each party in the AAA key management protocol MUST be authenticated to the other parties with whom they communicate. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process. When a secure association protocol is used to establish session keys, the parties involved in the secure association protocol MUST identify themselves using identities that are meaningful in the lower layer protocol environment that will employ the session keys. In this situation, the authenticator and peer may be known by different identifiers in the AAA protocol environment and the lower layer protocol environment, making authorization decisions difficult without a clear key scope. If the lower layer identifier of the peer will be used to make authorization decisions, then the pair of identifiers associated with the peer MUST be authorized by the authenticator and/or the AAA server. AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co- resident, this mechanism is applicable to the identification of EAP authenticators. When multiple base stations and a "controller" (such as a WLAN switch) comprise a single EAP authenticator, the "base station identity" is not relevant; the EAP method conversation takes place between the EAP peer and the EAP server. Also, many base stations can share the same authenticator identity. The authenticator identity is important in the AAA protocol exchange and the secure association protocol conversation. Authentication mechanisms MUST NOT employ plaintext passwords. Passwords may be used provided that they are not sent to another party without confidentiality protection. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Feb 17 16:25:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIX3c-0005mO-7u; Sat, 17 Feb 2007 16:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIX3a-0005mJ-95 for isms@ietf.org; Sat, 17 Feb 2007 16:25:22 -0500 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIX3Z-0000QC-1K for isms@ietf.org; Sat, 17 Feb 2007 16:25:22 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l1HLPGJs001026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Feb 2007 16:25:17 -0500 (EST) Date: Sat, 17 Feb 2007 16:25:04 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: Re: [Isms] Tmsm#6: double-authentication Message-ID: <458AB3E48CEFB0F68961A2A6@sirius.fac.cs.cmu.edu> In-Reply-To: <17b201c75223$456d1c20$0600a8c0@china.huawei.com> References: <17b201c75223$456d1c20$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01cHvdCtrjUn68xlWLo/kNeQftFDX3r1bd8Atvpvs=; 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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Friday, February 16, 2007 06:36:24 PM -0500 David Harrington wrote: > Hi, > > This was posted to the ietf list today, and might have an impact on > the double-authentication issue. > The terminology of course differs from isms/snmp terminology, and I > haven't gone through this thoroughly yet. > (Wes or Jeff or Joe might be able to do analysis of relevance faster > than I can.) I haven't looked in detail, but it doesn't look like this is relevant. The issue with the AAA key management draft is that there are three parties involved, and they may not all know each other by the same names (for example, the authentication exchanges may not all be using the same mechanism). In ISMS we don't have that problem - any given exchange involves only two parties, and only one authentication exchange that matters in determining the identity of each peer. In particular, in the double-authentication case, you're doing the second authentication because the first one was something you got "for free" but is not useful. Since the information from that authentication is thrown away in favor of the second one, it doesn't matter what it was, or whether its name was meaningful or consistent with the second authentication. In fact, if it _were_, and you could tell that, then the second authentication wouldn't have been needed in the first place. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 19 09:41:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9hP-00075E-2F; Mon, 19 Feb 2007 09:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9hO-000759-1R for isms@ietf.org; Mon, 19 Feb 2007 09:41:02 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ9hM-0005Bh-Fk for isms@ietf.org; Mon, 19 Feb 2007 09:41:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1JEexQr014309; Mon, 19 Feb 2007 08:40:59 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 08:40:59 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 15:40:58 +0100 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] Tmsm#6: double-authentication Date: Mon, 19 Feb 2007 15:40:42 +0100 Message-ID: In-Reply-To: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#6: double-authentication Thread-Index: AcdR4wperTn4Tmk0Q/K6Ny228/r4NgCT8lng References: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , X-OriginalArrivalTime: 19 Feb 2007 14:40:58.0407 (UTC) FILETIME=[F7FE9370:01C75433] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline at the bottom (so people can follow the discussion by just reading this email):=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: vrijdag 16 februari 2007 17:02 > To: isms@ietf.org > Subject: [Isms] Tmsm#6: double-authentication >=20 > Hi, >=20 > I did not originally consider this an open issue, but I=20 > suppose I should. >=20 > - last para of sect 3.2.2.1 >=20 > If the type of authentication provided by the transport layer (e.g. > TLS) is considered adequate to secure and/or encrypt the message, but > inadequate to provide the desired granularity of access control (e.g. > user-based), then a second authentication (e.g., one provided via a > RADIUS server) MAY be used to provide the authentication identity > which is bound to the securityName. This approach would require a > good analysis of the potential for man-in-the-middle attacks or > masquerade possibilities. >=20 > Bert (1/9): > It does not say anything about at what point in the process steps this > mapping from RADIUS authenticated identity to a securityName needs > to take place. Maybe we want to leave that open. But it seems to me > that the least we can say is that: it MUST bde done for incoming > messages before the security model passes securityName to the message > processing model via the processIncoming() ASI.=20 >=20 > DBH: I'm not sure that's true. If the goal is to get the=20 > identity for access control, it really only needs to get the=20 > securityname before it provides access control. If, for=20 > example, it uses RADIUS and does an authentication of the=20 > user and gets the authorization data, it could do this as=20 > part of the access control model. it doesn't need to be bound=20 > to the securityModel of the message, does it? I haven't spent=20 > time to consider the security implications of this, but I=20 > don't think we need to force this to be done a particular=20 > way. Of course, we do want to make sure the sender of the=20 > message is authorized to use the credentials that will=20 > authenticate the RADIUS request. >=20 > Bert: > First, none of the ASIs doe prescribe a particular way of=20 > implementation. The ASIs are to pass stuff between=20 > modularized documents. >=20 > Second, although in theory it maybe OK to do it rigth before=20 > access control, I personally think it is cleaner (from a=20 > documentation modularity point of view) that it is done as I=20 > suggested. All the other ASIs have the securityName as a=20 > paramter, and so I think it is more consistent if that=20 > paramter is filled out before such a field is being passed around. >=20 > DBH (new): > I agree that the security model has the responsibility for=20 > determining for incoming messages which securityname/level=20 > parameters will passed to MPM, to be passed deeper into the system.=20 >=20 > [Just to be clear on this somewhat related point, the=20 > security model might determine securityname/level from the=20 > message itself (e.g. USM), or from a cache (e.g. TSM), or=20 > from a MIB (e.g. RFC3584 Community-SM); it is=20 > security-model-dependent how these are determined. They are=20 > passed to the MPM and then to the rest of the system.] >=20 > The securityname/level/model parameters provided by MPM COULD=20 > be used by an access control model, but there is nothing that=20 > says the access control model MUST use them. >=20 > Applications are the typical clients of the service(s) of the=20 > Access Control Subsystem. The MPM passes=20 > securityname/level/model to the disptacher, which passes them=20 > to the application. Assuming an application wanted to do so,=20 > the application could take the MPM-provided=20 > securityname/level/model (e.g. dbh/authpriv/tsm) and look up=20 > some RADIUS credentials (e.g. dharrington and some keys),=20 > talk to a RADIUS server to authenticate the principal (e.g.=20 > dharrington), and then use the RADIUS-supplied principal in=20 > the securityname/level/model parameters for the call to=20 > isAccessAllowed.=20 >=20 > An alternative (that is more consistent with RFC4311 modularity): > An access control model could accept the securityName (e.g.=20 > dbh) provided by the securityModel-MPM-application in the=20 > isAccessAllowed ASI, and THEN could translate that into=20 > RADIUS parameters (dharrington), talk to RADIUS, and then use=20 > the RADIUS-principal > (dharrington) as the mapping to securityName used in the VACM MIB. >=20 > Again, I agree that the security model has the responsibility=20 > for determining for incoming messages which=20 > securityname/level parameters will passed to MPM, to be=20 > passed deeper into the system.=20 >=20 > But I think we want to be careful mandating that any "mapping=20 > from RADIUS authenticated identity to a securityName MUST be=20 > done for incoming messages before the security model passes=20 > securityName to the message processing model". >=20 I agree we need to be carefull. But all the ways you describe above in how things COULD be done is exactly the reason why I prefer we describe how we EXPECT it to be done, so that we easily get compliant and interoperable implementations (I agree that this is not on-the-wire-interoperability, but I think it is also important to ensure that if you have agents=20 from 3 different vendors, that they more or less apply access control consistently. In RFC3411, we have described in Sect 4.3 the ASI for the Access Control Subsystem. Not for VACM, but for the Subsystem. SO to me that means that we intended that all Access Control Models=20 would (preferably) use that ASI and the paramters that come with it. Further, I would hope that the ISMS implementation will be able to use VACM as an Access Control Model, and so it would be BEST (in my view) if the parameters are properly populated at one place so that they get passed as specified in the ASI. Further, I am not sure that it is wise (I understand it is possible) to have a dbh securityName from some transport model, and then later get a dharrington as the identity for access control. I would MUCH MUCH=20 more prefer that this also is the securityName. Bert=20 > 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 Feb 19 10:14:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJADW-000586-Qz; Mon, 19 Feb 2007 10:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJADV-000581-4e for isms@ietf.org; Mon, 19 Feb 2007 10:14:13 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJADT-00039f-P4 for isms@ietf.org; Mon, 19 Feb 2007 10:14:13 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l1JFE2CQ029084; Mon, 19 Feb 2007 09:14:02 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 09:14:02 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 16:13:33 +0100 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] Tmsm#1: MUST Responses go back on the same channel? Date: Mon, 19 Feb 2007 16:13:33 +0100 Message-ID: In-Reply-To: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#1: MUST Responses go back on the same channel? Thread-Index: AcdR0F+9rLH8LFsNRhmA0zWbsx6raQCY8oOg References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , X-OriginalArrivalTime: 19 Feb 2007 15:13:33.0504 (UTC) FILETIME=[8552B400:01C75438] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 I am not a security expert. But I tend to agree with Wes. Remember that in USM we also have the rule that a response needs to come back with the SAME securityLevel. This to me is somwhwat analogous as to why Wes wants a stronger statement that a response must come back on same connection. my 2 cents Bert=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: vrijdag 16 februari 2007 14:47 > To: isms@ietf.org > Subject: [Isms] Tmsm#1: MUST Responses go back on the same channel? >=20 > >From Wes Hardaker (1/9/07): >=20 > > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > > *** *** ***=20 > > Responses are expected > to > > be returned using the same session that carried the corresponding > > request message. Reuse of sessions is not required for=20 > > conformance. > >=20 > > Um... IMHO, this should be a MUST. There are security=20 > implications=20 > > if you send a response over a different session than the request > came > > in over. Different sessions may use different cryptographic=20 > > properties (algorithms, etc). Plus, once you start doing=20 > that you can=20 > > actually play with the timing of messages as they arrive at=20 > the other=20 > > end by slowing one session down and not the other, etc. > >=20 > > This, IMHO, is critical that responses go back on the same session. > > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > > *** *** *** >=20 > There have been comments, prior to WGLC, saying this should=20 > not be architecturally-mandatory, but should depend on the=20 > transport model and/or security model. =20 >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 19 11:02:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAxd-0004eU-Em; Mon, 19 Feb 2007 11:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAxc-0004eB-Ii for isms@ietf.org; Mon, 19 Feb 2007 11:01:52 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJAxa-0003s9-9D for isms@ietf.org; Mon, 19 Feb 2007 11:01:52 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007021916014901400s3e9te>; Mon, 19 Feb 2007 16:01:49 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> Subject: RE: [Isms] Tmsm#1: MUST Responses go back on the same channel? Date: Mon, 19 Feb 2007 10:57:50 -0500 Message-ID: <185801c7543e$b55c5060$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: Thread-index: AcdR0F+9rLH8LFsNRhmA0zWbsx6raQCY8oOgAAFlGlA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I understand that USM (and the SNMPv3 Message Processing Model) requires this. But I believe the RFC3411 'descriptive' architecture deliberately did not mandate this. There was discussion during SNMPv2/v3 development that there might be circumstances where the request could be sent unencrypted, and the response could be sent encrypted. TMSM is an architecture extension. Do we want to modify the architecuture to require that all transport models and any security models and message processing models that work with them MUST always use the same session (or session-like mechanism) for the request and the response? The RFC3411 architecture makes this decision model-dependent. If we make this a MUST, we change the RFC3411 architecture. I certainly agree that we could say SHOULD, and suggest that any model that does not use the same session should explain the security threats introduced by such a design. I hesitate to add such a contraint to an architectural subsystem, since I cannot tell how such a constraint might impact future models. It sounds like one more CLR. Dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Monday, February 19, 2007 10:14 AM > To: David Harrington; isms@ietf.org > Subject: RE: [Isms] Tmsm#1: MUST Responses go back on the > same channel? > > I am not a security expert. But I tend to agree with Wes. > Remember that in USM we also have the rule that a response > needs to come back with the SAME securityLevel. This to > me is somwhwat analogous as to why Wes wants a stronger > statement that a response must come back on same connection. > > my 2 cents > Bert > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: vrijdag 16 februari 2007 14:47 > > To: isms@ietf.org > > Subject: [Isms] Tmsm#1: MUST Responses go back on the same channel? > > > > >From Wes Hardaker (1/9/07): > > > > > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > > > *** *** *** > > > Responses > are expected > > to > > > be returned using the same session that carried the > corresponding > > > request message. Reuse of sessions is not required for > > > conformance. > > > > > > Um... IMHO, this should be a MUST. There are security > > implications > > > if you send a response over a different session than the request > > came > > > in over. Different sessions may use different cryptographic > > > properties (algorithms, etc). Plus, once you start doing > > that you can > > > actually play with the timing of messages as they arrive at > > the other > > > end by slowing one session down and not the other, etc. > > > > > > This, IMHO, is critical that responses go back on the > same session. > > > *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > > > *** *** *** > > > > There have been comments, prior to WGLC, saying this should > > not be architecturally-mandatory, but should depend on the > > transport model and/or security model. > > > > 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 > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Feb 22 21:20:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKQ36-0008TV-Cp; Thu, 22 Feb 2007 21:20:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKQ34-0008N7-Qa for isms@ietf.org; Thu, 22 Feb 2007 21:20:38 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKQ32-0004Oq-Gz for isms@ietf.org; Thu, 22 Feb 2007 21:20:38 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007022302203601200clpf8e>; Fri, 23 Feb 2007 02:20:36 +0000 From: "David Harrington" To: References: <04db01c740e2$1184f060$0600a8c0@china.huawei.com> <20070213135846.GA18604@elstar.iuhb02.iu-bremen.de> Date: Thu, 22 Feb 2007 21:16:32 -0500 Message-ID: <1b9401c756f0$a2f62a90$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: <20070213135846.GA18604@elstar.iuhb02.iu-bremen.de> Thread-index: AcdPdxoLHeVwOJalSeuFW3IX0RuJogHVXl4Q X-Spam-Score: 1.1 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: isms@ietf.org Subject: [Isms] RE: review of draft-ietf-isms-transport-security-model-02 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: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, February 13, 2007 8:59 AM > To: David Harrington > Cc: isms@ietf.org > Subject: review of draft-ietf-isms-transport-security-model-02 > > Hi, > > I have gone through this document and I have a few comments; most of > them I think are rather easy to resolve. > > a) spell out AAA the first time this acronym is used Done. > > b) p6: > > s/authenticatio and/authentication and/ Done. > > c) The document in several places talks about transportType but this > really is transportDomain called in the architecture and the ASIs. Done. > > d) p7: > > s/modles/models/ done > > In the paragraph, change "security" to "security model". Done. > > e) There are places with quite some repetitions - cutting the > repetions might shorten the ID quite a bit. For example, section 3 > repeats many details from RFC 3412 - this could be much shorter by > just stating which things actually change. It is also stated > multiple times how the securityLevel and the level of s ecurity > provided by the transport relate. Done. > > f) I am confused about msgSecurityParameters. Does it simply encode to > '0400'h or does it contain a ber serialization of a zero length > octet string, that is '04020400'? I was hoping the first option, > but the ASN.1 definition (which should be (SIZE (0))) makes me > believe the second option is meant. Changed to an OCTET STRING SIZE(0) - '0400' > > g) The first step in the EoP (section 4.2) seems interesting since you > try to verify that the message processing model did its work > correctly. We do not have such a check in the USM as far as I can > tell and I am not sure we should go down that path of verifying > everywhere that the other parts of the system work correctly. Removed. > > h) Step 4 in the EoP again seems to step on what RFC 3412 is doing > (see step 7e) in section 7.1 or RFC 3412). Removed. > > i) Step 5 in the EoP also seem to be covered by RFC 3412 7e). Removed. > > j) In step 9, I suggest to drop "and securityParameters (a zero-length > octet string)" since you can't return a wholeMsg without it. securityParameters is an OUT parameter. I don't know why, since rfc3412 doesn't describe any subsequent processing for that parameter, but it is in the ASIs between ther MPM and the SM. > > k) Like before, I question the need for step 1) in section 5.2. Done. > > l) You want to capitalize the beginning of all steps in section 5. Done (also for section 4). > > m) Section 6.2. can probably be removed because the MIB does not use > any TCs. Done. > > n) In section 8, I am not sure the phrase ", for access control > purposes" is particularly clear. I would suggest to drop it. If you > keep it, you probably have to spend some more text to explain what > goes into an access control decision (but since we do not change > anything, I think such an explanation is not needed). Removed. > > o) p21: > > s/Secuirty/Security/ Done. > > p) Are RFCs 3413, 3414, 3416, 3584 really all normative references? 3413 defines application types that are referenced; a reader will need to undersand those types. That makes it normative. 3414 changed 3414 and 3584 to informative Eliminated all reference to rfc3416. > > Dave, perhaps you can take a look at my list above and post a new > ID. Since I believe the text is fairly complete, we can consider to > move this document into last call mode so that we get more people to > look at this in more detail before the meeting in Prague. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Feb 23 18:50:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkBb-0005i4-Q7; Fri, 23 Feb 2007 18:50:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkBO-0005Hj-0c; Fri, 23 Feb 2007 18:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKkBM-0006r7-LW; Fri, 23 Feb 2007 18:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 940E617659; Fri, 23 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKkAs-00024M-AS; Fri, 23 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-transport-security-model-03.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington Filename : draft-ietf-isms-transport-security-model-03.txt Pages : 25 Date : 2007-2-23 This memo describes a Transport Security Model for the Simple Network Management Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-transport-security-model-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-transport-security-model-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-23162941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23162941.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Mon Feb 26 17:11:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLo4J-00082X-BY; Mon, 26 Feb 2007 17:11:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLo4I-00080v-2k for isms@ietf.org; Mon, 26 Feb 2007 17:11:38 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLo40-0007rp-3x for isms@ietf.org; Mon, 26 Feb 2007 17:11:38 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 4CD4D11D8DE; Mon, 26 Feb 2007 14:11:08 -0800 (PST) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Organization: Sparta References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> <185801c7543e$b55c5060$0600a8c0@china.huawei.com> Date: Mon, 26 Feb 2007 14:11:08 -0800 In-Reply-To: <185801c7543e$b55c5060$0600a8c0@china.huawei.com> (David Harrington's message of "Mon\, 19 Feb 2007 10\:57\:50 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org [sorry for the delay] >>>>> "DH" == David Harrington writes: DH> I understand that USM (and the SNMPv3 Message Processing Model) DH> requires this. ... DH> TMSM is an architecture extension. Extensions that have security ramifications on the original architecture may need to impose additional constraints. I think the issue is that you're trying to avoid it for the case where it doesn't matter (EG, USM over UDP) which makes perfect sense. But, in the case where the security is entirely implemented by the transport itself (as will be the case with ssh) then suddenly it becomes necessary that the transport itself refuses to send responses to queries that didn't come through it in the first place. What worries me is this: lets say manager M wants to send a request to agent A. It believes the response will contain highly-sensitive data that it wants to ensure is protected by at least AES security. Under USM/UDP you can be assured that when the manager sends the request, that agent A will double check (in the USM module) to make sure that the response is at the same security level as the original request. Under TMSM, though, suddenly you're in a situation where as agent A is processing the request and the original session between M and A gets dropped and a new one is created using DES gets established (regardless of which side establishes it; both are potentially possible but it doesn't matter). Now, since the transport is the one that is picking where to send it if you don't require it to go back over the same transport then suddenly you're sending the response back with a potentially completely different set of security properties than the request came through under (in this case, the response would be sent back over DES instead of AES). The agent has no ability to make an intelligent decision. It doesn't know what the security requirements of the response should be protected by. Only the person or application that sent the request would know this. Further, it's unlikely that the management stack would even warn the user that the transport used was potentially the incorrect one. If it simply receives a message from the lower transport and wasn't handed the security parameters under which the message was protected, it likely wouldn't even know that the policy it sent the request with wasn't followed by the responder. With USM, this example wouldn't pose an issue. The user's key, protocols, and user name are all cached in the security state, so the response will always be protected in the same way. The encryption algorithm couldn't have changed from AES to DES because it's disallowed. Even if the user's algorithm was reduced to NULL the security cache still contains the proper information to send the response back using the same mechanisms it was sent over. In the end, maybe what you really want is to qualify the statement such that it MUST NOT be sent over a different transport if the transport itself is responsible for handling any of the message security details. (word smithing needed). But fundamentally, you could allow a USM/UDP request's response to go back over USM/TCP and not care but it would be illegal to allow a TMSM/ISMS response to go back over anything that wasn't the original transport. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 26 17:29:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoLl-0001KS-5A; Mon, 26 Feb 2007 17:29:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoLJ-0000yq-Ml for isms@ietf.org; Mon, 26 Feb 2007 17:29:13 -0500 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLoLH-0002MX-IQ for isms@ietf.org; Mon, 26 Feb 2007 17:29:13 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l1QMT5cQ013376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 17:29:06 -0500 (EST) Date: Mon, 26 Feb 2007 17:29:04 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Message-ID: <1D78DD5484E543EB0B2383B7@sirius.fac.cs.cmu.edu> In-Reply-To: References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> <185801c7543e$b55c5060$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01W0Nob8Wr3eOnjuDwjsGY3vK1n5rid+HIuJbUkcM=; 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: 97adf591118a232206bdb5a27b217034 Cc: isms@ietf.org, 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 Monday, February 26, 2007 02:11:08 PM -0800 Wes Hardaker wrote: > Under TMSM, though, suddenly you're in a situation where as agent A is > processing the request and the original session between M and A gets > dropped and a new one is created using DES gets established The manager avoids this by not accepting such a connection. Of course, he doesn't necessarily know what response is going to come over that connection, so he probably needs a uniform policy about what he is going to accept. In an ideal world, the way to solve this is to provide a much richer concept of "security level" than SNMP currently has. However, previous attempts have shown that both in design and operationally, this is very hard to get right. IMHO, if someone thinks they can get this right, they should go off and do it, but not in ISMS. In practice, the solution is to do exactly what Wes described - open a connection with the desired security properties, and assume the application will require the response to be sent back via the same transport. For most applications, this assumption pretty much has to be true, because there's no other way to associate requests and responses. For others, it has to be explicit. I don't see a problem with requiring that responses be sent using the same security model (already true, AFAIK), and for TMSM, that the same transport session be used. The main issue here is that I'd rather not see the session concept appear above the transport model, especially when it comes to deciding how to manage cached sessions and when to destroy them. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Feb 26 18:29:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpHM-0000Yd-AA; Mon, 26 Feb 2007 18:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpGd-0000Jq-Cc for isms@ietf.org; Mon, 26 Feb 2007 18:28:27 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLpGa-00047b-Aw for isms@ietf.org; Mon, 26 Feb 2007 18:28:27 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id CABB811D8DE; Mon, 26 Feb 2007 15:28:14 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Organization: Sparta References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> <185801c7543e$b55c5060$0600a8c0@china.huawei.com> <1D78DD5484E543EB0B2383B7@sirius.fac.cs.cmu.edu> Date: Mon, 26 Feb 2007 15:28:14 -0800 In-Reply-To: <1D78DD5484E543EB0B2383B7@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon\, 26 Feb 2007 17\:29\:04 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >>>>> "JH" == Jeffrey Hutzelman writes: JH> The manager avoids this by not accepting such a connection. Of JH> course, he doesn't necessarily know what response is going to come JH> over that connection, so he probably needs a uniform policy about what JH> he is going to accept. It's frequently been presumed in the past that managers may use multiple protection mechanisms based on the requests they're sending... IE, authNoPriv for no-need-for-encryption data like interface counters but authPriv for, say, policy data or something worth protecting with encryption. Now, having said that, I don't know how many managers actually exist that make use of that concept but it was in the usability design of SNMPv3 originally. On the other hand in the ISMS world then if a manager opens two connections with different security properties and the agent is allowed to choose which it responds over then this is moot. JH> In an ideal world, the way to solve this is to provide a much richer JH> concept of "security level" than SNMP currently has. However, JH> previous attempts have shown that both in design and operationally, JH> this is very hard to get right. IMHO, if someone thinks they can get JH> this right, they should go off and do it, but not in ISMS. It's sort of there now, that's my point. The combination of USM/VACM/etc actually does provide some things that aren't really well discussed in the RFCs themselves but I've heard being talked about by vendors. One of which is the ability to trust that the response will be protected similarly as it was sent. The "security level" isn't the only mechanism that is assured today... the level, the keys, the integrity mechanism and the encryption mechanism are all assured by the USM spec to be the same in the response. JH> I don't see a problem with requiring that responses be sent using the JH> same security model (already true, AFAIK), and for TMSM, that the same JH> transport session be used. The main issue here is that I'd rather not JH> see the session concept appear above the transport model, especially JH> when it comes to deciding how to manage cached sessions and when to JH> destroy them. I should have mentioned, that if the decision not to send it happens at the SM level rather than the transport level, that doesn't bother me. IE, if the SM says "use transport X with ID #2 or nothing" that's fine. What I don't think is wise is the SSH SM saying "let it go forward" and then the transport model later arbitrarily picking which session to send it over. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 04:42:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyqK-0004xK-7B; Tue, 27 Feb 2007 04:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyqJ-0004xF-Kk for isms@ietf.org; Tue, 27 Feb 2007 04:41:55 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLyqH-0000qc-6K for isms@ietf.org; Tue, 27 Feb 2007 04:41:55 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 49A3A60BFC for ; Tue, 27 Feb 2007 10:41:50 +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 21389-05; Tue, 27 Feb 2007 10:41:47 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 217DA5BC34; Tue, 27 Feb 2007 10:41:47 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id B84041B12E8; Tue, 27 Feb 2007 10:41:45 +0100 (CET) Date: Tue, 27 Feb 2007 10:41:45 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Message-ID: <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: isms@ietf.org References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> <185801c7543e$b55c5060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <185801c7543e$b55c5060$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Feb 19, 2007 at 10:57:50AM -0500, David Harrington wrote: > TMSM is an architecture extension. Do we want to modify the > architecuture to require that all transport models and any security > models and message processing models that work with them MUST always > use the same session (or session-like mechanism) for the request and > the response? > > The RFC3411 architecture makes this decision model-dependent. If we > make this a MUST, we change the RFC3411 architecture. The text in question is: A Transport Model implementation MAY reuse an already established session with the appropriate transportDomain, transportAddress, securityName, securityModel, and securityLevel characteristics for delivery of a message containing a different pduType than originally caused the session to be created. For example, an implementation that has an existing session originally established to receive a request MAY use that session to send an outgoing notification, and MAY use a session that was originally established to send a notification to send a request. Responses SHOULD be returned using the same session that carried the corresponding request message. Reuse of sessions is not required for conformance. Speaking as a technical contributor, I am fine with making the SHOULD a MUST since there might indeed security holes that we are opening, although I do understand Dave's argument that we should not architecturally require this. Speaking as a co-chair, it seems that so far most people supported a MUST. If someone (except Dave) thinks we should be using a SHOULD, please speak up now. Otherwise, I assume that the concensus is to go with a MUST. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 04:48:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLywK-0005pQ-9w; Tue, 27 Feb 2007 04:48:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLywJ-0005pK-Cm for isms@ietf.org; Tue, 27 Feb 2007 04:48:07 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLywH-0001e3-Uu for isms@ietf.org; Tue, 27 Feb 2007 04:48:07 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 85AD36DA2A; Tue, 27 Feb 2007 10:48:05 +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 21782-07; Tue, 27 Feb 2007 10:48:01 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 42D136DA29; Tue, 27 Feb 2007 10:48:01 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CFB231B1371; Tue, 27 Feb 2007 10:47:59 +0100 (CET) Date: Tue, 27 Feb 2007 10:47:59 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] Issue#5: Do Informs work correctly? Message-ID: <20070227094759.GA8673@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: isms@ietf.org, Dave Harrington References: <166801c751ce$0f3c2060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166801c751ce$0f3c2060$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Dave Harrington 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, Feb 16, 2007 at 08:26:26AM -0500, David Harrington wrote: > >From Jeff Case: > (from message forwarded to WG by JS on 1/10) > > "i mention this because the experience with the project > causes me to question one of the draft's fundamental > tenets -- that you can do what you want to do without being > forced to compromise anything in arch, v3mp, and/or usm > > in particular, while your design probably works flawlessly for > gets and sets, and might work for traps as well, it would > be helpful if you could explain to me how informs work in > a way that is consistent with the above specs > (yes, i read and reread page 15 several times including the > waffle words found therein but maybe i am just dense and/or > missed something somewhere else)" > > We never got Jeff to elaborate further. > So the WG should look at Informs in STD62, and determine how they > differ from all other operations. > We know USM differs in its handling of Informs; are there non-USM > differences? > Then look at the EOP in tmsm, and verify that informs work > appropriately. Can someone please volunteer to check the TMSM EoP against the relevant sections in the STD62 documents that deal with notifications and in particular with informs? Perhaps one of the authors of the STD62 document is hanging around and can help us out here? /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 04:53:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLz17-000889-G5; Tue, 27 Feb 2007 04:53:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLz16-00083Z-0a for isms@ietf.org; Tue, 27 Feb 2007 04:53:04 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLz13-00026b-ID for isms@ietf.org; Tue, 27 Feb 2007 04:53:03 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 28DA86DA29; Tue, 27 Feb 2007 10:53:01 +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 22486-07; Tue, 27 Feb 2007 10:52:58 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 039556DA01; Tue, 27 Feb 2007 10:52:58 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 8F8B51B13D3; Tue, 27 Feb 2007 10:52:56 +0100 (CET) Date: Tue, 27 Feb 2007 10:52:56 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#4: persistent session info Message-ID: <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166c01c751d2$71865700$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166c01c751d2$71865700$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Feb 16, 2007 at 08:57:49AM -0500, David Harrington wrote: > >From Wes (1/9/07): > > > ----- > > and if state > > information is available when a session is closed, the > > session state > > information should also be released. > > > > Unless the management system indicates that the state should remain > > around for a longer period of time to allow for data collection > about > > the session to occur. See David Perkins for details. > > Dbh response: > I can understand the desire to have session info last longer than the > session, but the state info (in the LCD) is used to determine if a > session exists, so keeping it around in the LCD might be problematic, > unless it is somehow marked as expired. Since we are not writing a MIB > to represent this, I am not sure how we want to address the > implications of this issue here. > > I have not heard from Dave Perkins on this issue at all. > > The LCD is implementation-specific; as compared to the rfc341x docs, > we are not defining the LCD in MIB modules, but leaving it entirely up > to implementers to decide whether to use an LCD, the format of the > LCD, and so on. We have explicitly stated that release of > memory/resources for the cache and LCD are implementation-specific. > Therefore, I think we probably do not need to say anything about this > issue. I have not seen any further comments on this. Hence, I assume that we like to define that "session state is released if a session is closed". If you believe this is wrong, please speak up now. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 05:00:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLz84-0005em-9b; Tue, 27 Feb 2007 05:00:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLz83-0005eh-JM for isms@ietf.org; Tue, 27 Feb 2007 05:00:15 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLz82-0002u9-1g for isms@ietf.org; Tue, 27 Feb 2007 05:00:15 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A00F56DA29; Tue, 27 Feb 2007 11:00:13 +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 23171-02; Tue, 27 Feb 2007 11:00:10 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6E2A56DA2A; Tue, 27 Feb 2007 10:59:32 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 068EE1B1427; Tue, 27 Feb 2007 10:59:30 +0100 (CET) Date: Tue, 27 Feb 2007 10:59:30 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#2: cache contents Message-ID: <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166f01c751db$14408990$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166f01c751db$14408990$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Feb 16, 2007 at 09:59:38AM -0500, David Harrington wrote: > >From Bert Wijnen (1/12): > > "> - I am not 100% sure, but is it correct that section 5.1. about the > > securityStateReference is not adding any new (or changing any > > existing) information compared to RFC3411? > > If so, I would prefer we state that explicitly. > > If it does add something, pls make it clear what is being > > added/changed. > > > > - Section 5.2 > > I think (but it is not clear) that the transport model should save > > a mapping from transport security/authentication ID to > seucirtyName > > so the the Security Model can pick it up and pass it back as an > > OUT parameter on the processIncomingMessage ASI,. no?" > > Dbh response: > > Yes, this information should be saved in one of the caches. The format > and contents of the caches are implementation-specific however, so I > don't know what information we can discuss. The transport model might > also need to know the authentication algorithm, the integity-checking > and encryption parameters, and so on. These are very much > transport-model specific. The way we deal with it is to provide two > caches - one for the request/response pair, and another for the > session-like mechanism. It is up to the implementer to decide what > goes where. Added to Open Issues for discussion." > > Bert: " > I'd say we need to just state that thuis is what we expect, and that > each specific transport model needs to be specific as to what kind > of data needs to be saved in order tolet aSecurity Model be able to > pick up the proper data that it needs." > > DBH: > "The related security parameters may include transport-specific > security information." > I am not sure that the security experts would like to see MUST > language about what needs to be included. This would potentially limit > algorithm agility. It also might depend on the libraries they are > using to implement; different libraries may require different > parameters. So the cached information is transport-model and > implementation dependent: > > "A Transport Model may store transport-specific parameters in the > cache for subsequent usage. Since the contents of a cache are > meaningful only within an implementation, and not on-the-wire, the > format of the cache is implementation-specific." > > "For each message or transport session, information about the message > security is stored in a cache, which may include model- and > mechanism-specific parameters. The tmStateReference is passed between > subsystems to provide a handle for the cache. A Transport Model may > store transport-specific parameters in the cache for subsequent usage. > Since the contents of a cache are meaningful only within an > implementation, and not on-the-wire, the format of the cache is > implementation-specific." > > To keep things modular, a secure transport model translates from > transport-specific security principal to securityName, and passes the > securityName in the cache. The transport model determines what > security services were provided by the transport, and puts > securityLevel into the cache. A security model does not need to know > anything about the transport specific principal or services. The > security model just takes securityName and securityLevel from the > cache, already translated. Otherwise we would have a problem of > requiring a specific security model for each specific transport model, > something we definitely want to avoid. > > What happens with the cache depends on the security model called by > the message processing model. Some might take the values from the > cache to return to the MPM; some might just use parameters provided in > a message security block and totally ignore the cache; some might use > a mapping from a MIB module and totally ignore the cache. Can we resolve this issue by spelling out (a) which SNMP parameters need to be maintained in the cache and at the same time we spell out (b) that there might be additional parameters used by the secure transport, which are specific to the secure transport itself (and need not be spelled out since this is the job of the secure transport technology to spell out if desirable)? /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 05:14:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzLF-0001OL-L6; Tue, 27 Feb 2007 05:13:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzLE-0001OE-8C for isms@ietf.org; Tue, 27 Feb 2007 05:13:52 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzLB-0004ZA-P0 for isms@ietf.org; Tue, 27 Feb 2007 05:13:52 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l1RACL5n003537; Tue, 27 Feb 2007 04:13:43 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 04:13:31 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 11:13:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Isms] Tmsm#2: cache contents Date: Tue, 27 Feb 2007 11:10:56 +0100 Message-ID: In-reply-to: <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#2: cache contents Thread-Index: AcdaVie7vI/UH+/RTVusK+b+CUvTbAAAWJnw References: <166f01c751db$14408990$0600a8c0@china.huawei.com> <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> From: "Wijnen, Bert \(Bert\)" To: , "David Harrington" X-OriginalArrivalTime: 27 Feb 2007 10:13:28.0197 (UTC) FILETIME=[ECA0E350:01C75A57] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Yep, that probably works. Need to see the text of course. Bert=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: dinsdag 27 februari 2007 11:00 > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Tmsm#2: cache contents >=20 > On Fri, Feb 16, 2007 at 09:59:38AM -0500, David Harrington wrote: > > >From Bert Wijnen (1/12): > >=20 > > "> - I am not 100% sure, but is it correct that section=20 > 5.1. about the > > > securityStateReference is not adding any new (or changing any > > > existing) information compared to RFC3411? > > > If so, I would prefer we state that explicitly. > > > If it does add something, pls make it clear what is being=20 > > > added/changed. > > >=20 > > > - Section 5.2 > > > I think (but it is not clear) that the transport model=20 > should save > > > a mapping from transport security/authentication ID to > > seucirtyName > > > so the the Security Model can pick it up and pass it back as an > > > OUT parameter on the processIncomingMessage ASI,. no?" > >=20 > > Dbh response: > >=20 > > Yes, this information should be saved in one of the caches.=20 > The format=20 > > and contents of the caches are implementation-specific=20 > however, so I=20 > > don't know what information we can discuss. The transport=20 > model might=20 > > also need to know the authentication algorithm, the=20 > integity-checking=20 > > and encryption parameters, and so on. These are very much=20 > > transport-model specific. The way we deal with it is to provide two=20 > > caches - one for the request/response pair, and another for the=20 > > session-like mechanism. It is up to the implementer to decide what=20 > > goes where. Added to Open Issues for discussion." > >=20 > > Bert: " > > I'd say we need to just state that thuis is what we expect,=20 > and that=20 > > each specific transport model needs to be specific as to=20 > what kind of=20 > > data needs to be saved in order tolet aSecurity Model be=20 > able to pick=20 > > up the proper data that it needs." > >=20 > > DBH: > > "The related security parameters may include transport-specific=20 > > security information." > > I am not sure that the security experts would like to see MUST=20 > > language about what needs to be included. This would=20 > potentially limit=20 > > algorithm agility. It also might depend on the libraries they are=20 > > using to implement; different libraries may require different=20 > > parameters. So the cached information is transport-model and=20 > > implementation dependent: > >=20 > > "A Transport Model may store transport-specific parameters in the=20 > > cache for subsequent usage. Since the contents of a cache are=20 > > meaningful only within an implementation, and not on-the-wire, the=20 > > format of the cache is implementation-specific." > >=20 > > "For each message or transport session, information about=20 > the message=20 > > security is stored in a cache, which may include model- and=20 > > mechanism-specific parameters. The tmStateReference is=20 > passed between=20 > > subsystems to provide a handle for the cache. A Transport Model may=20 > > store transport-specific parameters in the cache for=20 > subsequent usage. > > Since the contents of a cache are meaningful only within an=20 > > implementation, and not on-the-wire, the format of the cache is=20 > > implementation-specific." > >=20 > > To keep things modular, a secure transport model translates from=20 > > transport-specific security principal to securityName, and=20 > passes the=20 > > securityName in the cache. The transport model determines what=20 > > security services were provided by the transport, and puts=20 > > securityLevel into the cache. A security model does not=20 > need to know=20 > > anything about the transport specific principal or services. The=20 > > security model just takes securityName and securityLevel from the=20 > > cache, already translated. Otherwise we would have a problem of=20 > > requiring a specific security model for each specific=20 > transport model,=20 > > something we definitely want to avoid. > >=20 > > What happens with the cache depends on the security model called by=20 > > the message processing model. Some might take the values from the=20 > > cache to return to the MPM; some might just use parameters=20 > provided in=20 > > a message security block and totally ignore the cache; some=20 > might use=20 > > a mapping from a MIB module and totally ignore the cache. >=20 > Can we resolve this issue by spelling out (a) which SNMP=20 > parameters need to be maintained in the cache and at the same=20 > time we spell out > (b) that there might be additional parameters used by the=20 > secure transport, which are specific to the secure transport=20 > itself (and need not be spelled out since this is the job of=20 > the secure transport technology to spell out if desirable)? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 08:18:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM2DX-00055a-F9; Tue, 27 Feb 2007 08:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM2DV-00055V-RL for isms@ietf.org; Tue, 27 Feb 2007 08:18:05 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM2DU-0004zs-Gs for isms@ietf.org; Tue, 27 Feb 2007 08:18:05 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E1FEA6DA47; Tue, 27 Feb 2007 14:18:03 +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 10734-01; Tue, 27 Feb 2007 14:17:59 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3DE036DA0E; Tue, 27 Feb 2007 14:17:59 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CE4FC1B1684; Tue, 27 Feb 2007 14:17:57 +0100 (CET) Date: Tue, 27 Feb 2007 14:17:57 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#3: session reuse - continued Message-ID: <20070227131757.GA8875@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166e01c751d9$9944e250$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166e01c751d9$9944e250$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Feb 16, 2007 at 09:49:02AM -0500, David Harrington wrote: [...] > So it should probably be the message processing model or the > application that needs to know how to deal with dropped messages. > > I removed the text that says a transport model needs to define a > stndard behavior." I am not sure where we stand with this issue. I believe the original motivaion for this "feature" were attempts to work towards call-home support. For example, one could a "manager" establish a CG/CR session and configure the target MIBs to direct notifications towards the same session. >From the viewpoint of a transport model, you do not really know / care what PDU type is contained in a message and if there is a matching session, you could just send the message over it. Is the issue whether we do or do not want this behaviour? Or is the issue that we want to classify sessions into CG/CR sessions and NO/NR sessions? This would be difficult wrt. the existing ASIs. Or is the issue simply that the ID said messages can be dropped? I would say that this is not really a new feature. Even today, if you send CG PDUs to a NR, the messages will be dropped and if you send NO PDUs to a CG, messages will be dropped as well. In other words, we may choose to actually say nothing about it in the TSMS document. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 09:41:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3W5-0002Nw-Fj; Tue, 27 Feb 2007 09:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3W3-0002Nq-Uu for isms@ietf.org; Tue, 27 Feb 2007 09:41:19 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3W1-0006od-GC for isms@ietf.org; Tue, 27 Feb 2007 09:41:19 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C295B6DB58; Tue, 27 Feb 2007 15:41:16 +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 19420-09; Tue, 27 Feb 2007 15:41:13 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4BDA76DB68; Tue, 27 Feb 2007 15:41:10 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id C8A051B1A52; Tue, 27 Feb 2007 15:41:08 +0100 (CET) Date: Tue, 27 Feb 2007 15:41:08 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] Tmsm#6: double-authentication Message-ID: <20070227144108.GA9212@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , isms@ietf.org References: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Feb 19, 2007 at 03:40:42PM +0100, Wijnen, Bert (Bert) wrote: > > If the type of authentication provided by the transport layer (e.g. > > TLS) is considered adequate to secure and/or encrypt the message, but > > inadequate to provide the desired granularity of access control (e.g. > > user-based), then a second authentication (e.g., one provided via a > > RADIUS server) MAY be used to provide the authentication identity > > which is bound to the securityName. This approach would require a > > good analysis of the potential for man-in-the-middle attacks or > > masquerade possibilities. > > > > Bert (1/9): > > It does not say anything about at what point in the process steps this > > mapping from RADIUS authenticated identity to a securityName needs > > to take place. Maybe we want to leave that open. But it seems to me > > that the least we can say is that: it MUST bde done for incoming > > messages before the security model passes securityName to the message > > processing model via the processIncoming() ASI. Why do we have to talk about this in this document at all? Is it not the job of the RADIUS integration document to spell out when and where in the processing RADIUS can be called, which attributes are relevant and how the RADIUS interaction may change values of things such as the securityName? Such a document should then be precise where things happen. I would like to treat a secure transport model as a block box which provides me with an authenticated securityName etc. and I would leave it to the specifications of such a secure transport model to tell me how things work (and this includes AAA services such as RADIUS). /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 11:00:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4l5-0000WK-FA; Tue, 27 Feb 2007 11:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4l4-0000UZ-5m for isms@ietf.org; Tue, 27 Feb 2007 11:00:54 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4l2-00071K-Mx for isms@ietf.org; Tue, 27 Feb 2007 11:00:54 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007022716005101400p7c4ae>; Tue, 27 Feb 2007 16:00:51 +0000 From: "David Harrington" To: , References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com><185801c7543e$b55c5060$0600a8c0@china.huawei.com> <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms] Tmsm#1: MUST Responses go back on the same channel? Date: Tue, 27 Feb 2007 10:56:42 -0500 Message-ID: <20b701c75a87$e04fa7f0$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: <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> Thread-index: AcdaU40i9V6weaWiS3W/zP2bM9XmsAAIIVNA X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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, Sorry, this is a long one. I have not been a strong proponent of one way or the other; I raised this as an issue because somebody else raised the issue that security properties were not required to be the same between request and response; this was a deliberate decision of the snmpv3 WG to not make this mandatory. The SNMPv3 WG made the decisioon model-specific. Then they made it mandatory for the snmpv3-MPM and USM models. Obviously, they had mixed feelings on the issue, but felt it best to allow for the possibility of future models to support this rather than outlaw it architecturally. As I study this problem, however, I think there are real problems associated with trying to require the Transport Subsystem to enforce a decision that the same session must be used for request and corresponding response. 1) Who knows what? Before deciding on an answer for this issue, the WG should seriously consider issue#3 - does a transport model know what operation is contained within a message? i.e. does it know a message is a Response? The ASIs have been designed such that the transport model does NOT have that information. The transport model/subsystem does not know whether a message contains a response or a request or a notification. The transport model only sees an opaque outgoingMessage that needs to be sent, or an opaque incomingMessage that needs to be passed to the dispatcher. The determination of what operation is/should be in a message is made, for incoming and outgoing messages, by the message processing model. The mapping of an incoming response to an outstanding request is handled within the Message Processing Subsystem. Part of the reason for this is to permit the extensibility of message formats, including the operations contained in a message, without impacting the security subsystem or the transport subsystem or the disptacher (an application would need to know how to process the operation). This allows co-existence of an SNMPv1 message processing model and an SNMPv3 messafe processing model, since there are operations specific to each protocol version (Trap, Trap-v2, GetBulk, Inform, etc.). Having the transport subsystem know about specific operations violates the modularity of the architecture, and makes it harder to support new operations in the system. 2) in a related question, who knows about transport session? Remember that the "sessions" being discussed in TMSM and TSM are purely **transport** sessions. They are NOT security sessions; they are not messaging sessions. Since transport sessions are transport-specific, the only portion of the system that knows about transport sessions should be the transport-specific models. An SSH session is not the same as a TLS session is not the same as a BEEP session and so on. The notion of session is specific to the transport being used. The message processing model has no knowledge of transport sessions. Nor does the Transport Security Model. The Message Processing Subsystem, which knows when an outgoing message is a response, does have the securityStateReference cached information, and can request the use of the same securityName, securitylevel, transportDomain, and transportAddress as the request. 3) who knows about the encryption algorithms used? Wes argues that a request could be sent over an AES-encrypted session, and the response could be sent over a less-secure DES encrypted session if we do not require the same session be used. Jeff responded with "In an ideal world, the way to solve this is to provide a much richer concept of "security level" than SNMP currently has. However, previous attempts have shown that both in design and operationally, this is very hard to get right. IMHO, if someone thinks they can get this right, they should go off and do it, but not in ISMS." The SNMPv3 WG struggled with this issue, especially given that both the Community-based security and USM provide "authentication" but at widely different levels of effectiveness. After studying the problem, including much input from security experts, it was decided that this was a slippery slope. It was decided that SNMP could only specify whether authentication was provided, and whether encryption was provided, without trying to standardize different security levels of the mechanisms used, and without standardizing an ASI to request specific mechanisms or security options. It was decided by the SNMPv3 WG that SNMP should have no inherent knowledge of the security mechanisms used. That was up to an operator to configure. USM provided a vendor-neutral, mechanism-neutral, and extensible MIB module that an operator could use to configure which mechanisms could be used by each USM user. This WG has already decided similarly. It was decided that implementations should support any mechanism allowed for the secure transport protocol, and then it is the responsibility of operators to ensure that reasonable options were configured. As editor, I fought long battles that the WG should standardize which transport-specific parameters should be saved in the cache and the LCD (issue#2) and I lost, because doing this would hamper algorithm agility. Therefore, the idea that the SNMP engine knows which transports are encrypted with AES and which with DES seems out of scope for this WG. That determination should be made by the operator who configures the options for the underlying secure transports (and possibly by a AAA "policy" support of the secure transport). 4) who should provide the mapping from model-independent parameters to transport-specific security parameters? It would be inappropriate for the MPM to know anything about transport-specific sessions, and it would be especially inappropriate to force the Message Porcessing Subsystem to know which encryption algorithms were used for which transport-specific sessions, so the MPM cannot choose which transport-specific session should be used for a Response. The Security Model has limited insight into both sets of information. When the Message Processing Subsystem calls the Security Subsystem, it passes the securityName/Level and transportDomain/Address information. For SNMPv3, if it is a Response, then this will be the values extracted from the securityStateReference cache to match the Request. The Security Model can then look up any associated LCD info and pass that to the transport model. The tmStateReference cache contains transport-specific information, possibly including the mechanisms used and other security options. But those are outside the scope of the Security Model so we can avoid having to have an SSH-specific security model to use with the SSH-specific transport model, and a TLS-security model to use with the TLS transport model, and so on. We do not define the cache or LCD format because this would force us to **standardize** an SSH-specific LCD, and possibly an SSH-over-AES specific cache and LCD, and an SSH-over-DES specific cache and LCD, and so on. In the Transport-Security-Model, for an incoming message, an implementation MAY save the transport-specific information in a Local Configuration Datastore; for an outgoing message, if the transport-specific properties have been saved in an LCD, then they should be forwarded to the transport model for (possible) use. Should we REQUIRE saving the transport-specific info in an LCD? Should we specify what information must be saved? Should we write a MIB module to hold transport-model-security-specific info? Thus far, the WG consensus seems to be "no, we should not. We want to keep knowledge of mechanism-specific information and options out of view of SNMP, and keep it in the secure transport layer." Given that, we need to be careful about trying to impose need-to-know intelligence onto SNMP subsystems that thus far have no need-to-know. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, February 27, 2007 4:42 AM > To: isms@ietf.org > Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the > same channel? > > On Mon, Feb 19, 2007 at 10:57:50AM -0500, David Harrington wrote: > > > TMSM is an architecture extension. Do we want to modify the > > architecuture to require that all transport models and any security > > models and message processing models that work with them MUST always > > use the same session (or session-like mechanism) for the request and > > the response? > > > > The RFC3411 architecture makes this decision model-dependent. If we > > make this a MUST, we change the RFC3411 architecture. > > The text in question is: > > A Transport Model implementation MAY reuse an already established > session with the appropriate transportDomain, transportAddress, > securityName, securityModel, and securityLevel characteristics for > delivery of a message containing a different pduType than > originally > caused the session to be created. For example, an implementation > that has an existing session originally established to receive a > request MAY use that session to send an outgoing notification, and > MAY use a session that was originally established to send a > notification to send a request. Responses SHOULD be returned using > the same session that carried the corresponding request message. > Reuse of sessions is not required for conformance. > > Speaking as a technical contributor, I am fine with making the SHOULD > a MUST since there might indeed security holes that we are opening, > although I do understand Dave's argument that we should not > architecturally require this. > > Speaking as a co-chair, it seems that so far most people supported a > MUST. If someone (except Dave) thinks we should be using a SHOULD, > please speak up now. Otherwise, I assume that the concensus is to go > with a MUST. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 11:11:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4vG-00038n-VP; Tue, 27 Feb 2007 11:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4vF-00038V-T8 for isms@ietf.org; Tue, 27 Feb 2007 11:11:25 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4v8-0000As-BW for isms@ietf.org; Tue, 27 Feb 2007 11:11:25 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007022716111401100ilr02e>; Tue, 27 Feb 2007 16:11:14 +0000 From: "David Harrington" To: References: <166c01c751d2$71865700$0600a8c0@china.huawei.com> <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms] Tmsm#4: persistent session info Date: Tue, 27 Feb 2007 11:07:06 -0500 Message-ID: <20b801c75a89$5415e950$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: <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> Thread-index: AcdaVRHCz7Nn7KepTD+hvVloT9kJNwAMyRRA X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, > I have not seen any further comments on this. Hence, I assume that we > like to define that "session state is released if a session is > closed". If you believe this is wrong, please speak up now. I believe the complaint is that we specified the state was released when the session is closed; this should be an implementation decision, since all release handling is implementation-specific. The important point is we should not rely on any specific implementation choice, so checking to see if the session is still in the LCD to determine that the session has not been closed is inappropriate in our document. I changed the documents to reflect this implementation-specific view. If we want more control over this, we should probably standardize the LCD as a MIB module, with a RowStatus object per session. But that opens a whole new can of worms. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, February 27, 2007 4:53 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Tmsm#4: persistent session info > > On Fri, Feb 16, 2007 at 08:57:49AM -0500, David Harrington wrote: > > >From Wes (1/9/07): > > > > > ----- > > > > and if state > > > information is available when a session is closed, the > > > session state > > > information should also be released. > > > > > > Unless the management system indicates that the state > should remain > > > around for a longer period of time to allow for data collection > > about > > > the session to occur. See David Perkins for details. > > > > Dbh response: > > I can understand the desire to have session info last > longer than the > > session, but the state info (in the LCD) is used to determine if a > > session exists, so keeping it around in the LCD might be > problematic, > > unless it is somehow marked as expired. Since we are not > writing a MIB > > to represent this, I am not sure how we want to address the > > implications of this issue here. > > > > I have not heard from Dave Perkins on this issue at all. > > > > The LCD is implementation-specific; as compared to the rfc341x docs, > > we are not defining the LCD in MIB modules, but leaving it > entirely up > > to implementers to decide whether to use an LCD, the format of the > > LCD, and so on. We have explicitly stated that release of > > memory/resources for the cache and LCD are implementation-specific. > > Therefore, I think we probably do not need to say anything > about this > > issue. > > I have not seen any further comments on this. Hence, I assume that we > like to define that "session state is released if a session is > closed". If you believe this is wrong, please speak up now. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 11:21:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM556-0005YY-5q; Tue, 27 Feb 2007 11:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM554-0005YK-9V for isms@ietf.org; Tue, 27 Feb 2007 11:21:34 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM552-0001f0-Tk for isms@ietf.org; Tue, 27 Feb 2007 11:21:34 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007022716213201100ij9mie>; Tue, 27 Feb 2007 16:21:32 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , References: <166f01c751db$14408990$0600a8c0@china.huawei.com> <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms] Tmsm#2: cache contents Date: Tue, 27 Feb 2007 11:17:24 -0500 Message-ID: <20bc01c75a8a$c44177c0$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: Thread-index: AcdaVie7vI/UH+/RTVusK+b+CUvTbAAAWJnwAAy/hXA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Please see revision -06-. Is that text OK? dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Tuesday, February 27, 2007 5:11 AM > To: j.schoenwaelder@iu-bremen.de; David Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Tmsm#2: cache contents > > Yep, that probably works. Need to see the text of course. > > Bert > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: dinsdag 27 februari 2007 11:00 > > To: David Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] Tmsm#2: cache contents > > > > On Fri, Feb 16, 2007 at 09:59:38AM -0500, David Harrington wrote: > > > >From Bert Wijnen (1/12): > > > > > > "> - I am not 100% sure, but is it correct that section > > 5.1. about the > > > > securityStateReference is not adding any new (or changing any > > > > existing) information compared to RFC3411? > > > > If so, I would prefer we state that explicitly. > > > > If it does add something, pls make it clear what is being > > > > added/changed. > > > > > > > > - Section 5.2 > > > > I think (but it is not clear) that the transport model > > should save > > > > a mapping from transport security/authentication ID to > > > seucirtyName > > > > so the the Security Model can pick it up and pass it > back as an > > > > OUT parameter on the processIncomingMessage ASI,. no?" > > > > > > Dbh response: > > > > > > Yes, this information should be saved in one of the caches. > > The format > > > and contents of the caches are implementation-specific > > however, so I > > > don't know what information we can discuss. The transport > > model might > > > also need to know the authentication algorithm, the > > integity-checking > > > and encryption parameters, and so on. These are very much > > > transport-model specific. The way we deal with it is to > provide two > > > caches - one for the request/response pair, and another for the > > > session-like mechanism. It is up to the implementer to > decide what > > > goes where. Added to Open Issues for discussion." > > > > > > Bert: " > > > I'd say we need to just state that thuis is what we expect, > > and that > > > each specific transport model needs to be specific as to > > what kind of > > > data needs to be saved in order tolet aSecurity Model be > > able to pick > > > up the proper data that it needs." > > > > > > DBH: > > > "The related security parameters may include transport-specific > > > security information." > > > I am not sure that the security experts would like to see MUST > > > language about what needs to be included. This would > > potentially limit > > > algorithm agility. It also might depend on the libraries they are > > > using to implement; different libraries may require different > > > parameters. So the cached information is transport-model and > > > implementation dependent: > > > > > > "A Transport Model may store transport-specific parameters in the > > > cache for subsequent usage. Since the contents of a cache are > > > meaningful only within an implementation, and not > on-the-wire, the > > > format of the cache is implementation-specific." > > > > > > "For each message or transport session, information about > > the message > > > security is stored in a cache, which may include model- and > > > mechanism-specific parameters. The tmStateReference is > > passed between > > > subsystems to provide a handle for the cache. A Transport > Model may > > > store transport-specific parameters in the cache for > > subsequent usage. > > > Since the contents of a cache are meaningful only within an > > > implementation, and not on-the-wire, the format of the cache is > > > implementation-specific." > > > > > > To keep things modular, a secure transport model translates from > > > transport-specific security principal to securityName, and > > passes the > > > securityName in the cache. The transport model determines what > > > security services were provided by the transport, and puts > > > securityLevel into the cache. A security model does not > > need to know > > > anything about the transport specific principal or services. The > > > security model just takes securityName and securityLevel from the > > > cache, already translated. Otherwise we would have a problem of > > > requiring a specific security model for each specific > > transport model, > > > something we definitely want to avoid. > > > > > > What happens with the cache depends on the security model > called by > > > the message processing model. Some might take the values from the > > > cache to return to the MPM; some might just use parameters > > provided in > > > a message security block and totally ignore the cache; some > > might use > > > a mapping from a MIB module and totally ignore the cache. > > > > Can we resolve this issue by spelling out (a) which SNMP > > parameters need to be maintained in the cache and at the same > > time we spell out > > (b) that there might be additional parameters used by the > > secure transport, which are specific to the secure transport > > itself (and need not be spelled out since this is the job of > > the secure transport technology to spell out if desirable)? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 11:32:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5FR-0002gT-LC; Tue, 27 Feb 2007 11:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5FQ-0002eX-Vs for isms@ietf.org; Tue, 27 Feb 2007 11:32:16 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM5FP-00032d-Jm for isms@ietf.org; Tue, 27 Feb 2007 11:32:16 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9B88F58EE5; Tue, 27 Feb 2007 17:32:12 +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 31503-02; Tue, 27 Feb 2007 17:32:09 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2548D5ACC4; Tue, 27 Feb 2007 17:32:01 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id A53E41B1E99; Tue, 27 Feb 2007 17:31:59 +0100 (CET) Date: Tue, 27 Feb 2007 17:31:59 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#4: persistent session info Message-ID: <20070227163159.GA9720@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <166c01c751d2$71865700$0600a8c0@china.huawei.com> <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> <20b801c75a89$5415e950$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20b801c75a89$5415e950$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 11:07:06AM -0500, David Harrington wrote: > Hi, > > > I have not seen any further comments on this. Hence, I assume that > we > > like to define that "session state is released if a session is > > closed". If you believe this is wrong, please speak up now. > > I believe the complaint is that we specified the state was released > when the session is closed; this should be an implementation decision, > since all release handling is implementation-specific. > > The important point is we should not rely on any specific > implementation choice, so checking to see if the session is still in > the LCD to determine that the session has not been closed is > inappropriate in our document. > > I changed the documents to reflect this implementation-specific view. Dave, can you please post the new wording so that we can check whether we agree with it? /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:20:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6w8-0001OI-Dl; Tue, 27 Feb 2007 13:20:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6w7-0001Mf-4e for isms@ietf.org; Tue, 27 Feb 2007 13:20:27 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6w4-00006H-Ql for isms@ietf.org; Tue, 27 Feb 2007 13:20:27 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007022718202401200cg9ble>; Tue, 27 Feb 2007 18:20:24 +0000 From: "David Harrington" To: References: <166c01c751d2$71865700$0600a8c0@china.huawei.com> <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> <20b801c75a89$5415e950$0600a8c0@china.huawei.com> <20070227163159.GA9720@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms] Tmsm#4: persistent session info Date: Tue, 27 Feb 2007 13:16:16 -0500 Message-ID: <20c701c75a9b$5f2f3af0$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: <20070227163159.GA9720@elstar.iuhb02.iu-bremen.de> Thread-index: AcdajNWqagfo+ofgR9WBT5rqIIFrzwABzYmg X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, The LCD an implementation-decision, including the contents, whether there is one at all, and when it should be released if there is one: >From tmsm-06: 5.2. tmStateReference For each message or transport session, information about the message security is stored in a cache, which may include model- and mechanism-specific parameters. The tmStateReference is passed between subsystems to provide a handle for the cache. A Transport Model may store transport-specific parameters in the cache for subsequent usage. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific. The state referenced by tmStateReference might be saved in a Local Configuration Datastore (LCD) to make it available across multiple messages, as compared to securityStateReference which is designed to be saved only for the life of a request-response pair of messages. It is expected that an LCD will allow lookup based on the combination of transportDomain, transportAddress, securityName, securityModel, and securityLevel, and that the cache contain these values to reference entries in the LCD. >From TSM-03: 3.2.2. tmStateReference For each transport session, information about the message security is stored in a cache to pass model- and mechanism-specific parameters. The state referenced by tmStateReference may be saved across multiple messages, in a Local Configuration Datastore (LCD), as compared to securityStateReference which is usually only saved for the life of a request-response pair of messages. The format of the cache and the LCD are implementation-specific. 5.2. Elements of Procedure for Incoming Messages 8) The information in the tmStateReference may be saved, in an implementation-dependent manner, in a Local Configuration Datastore (LCD) for subsequent usage. [Note that the LCD is not mentioned for outgoing messages.] -- The SSH Transport Model is not as up-to-date as the other documents. As previously discussed, I have been waiting for the architectural issues and the transport-model-independent security model to gel before getting into the details of the SSH model. Currently, the SSH transport model does use an LCD - one that is SSHTM-specific, and documented as SSHTM-MIB. It is actually not viable at this point; much of it is just cut-and-pasted from USM with a global replace operation to remove USM-specific details. It does not and should not reflect SSH-specific information, such as the encryption mechanism used by a session; that information should should be made available through an SSH-MIB, designed by SSH experts to document their protocol. Then the SSHTM-MIB can reference the SSH-MIB as needed. I have to assume that the lack of an SSH-MIB is an IESG-approved decision for the SecSH WG for security reasons, and we should not presume to overturn such a decision by exposing SSH-specific info in the SSHTM-MIB. If we allow for transport model specific LCDs (which makes sense architecturally), then sechell-xx might continue to define such an LCD, even if the Transport Subsystem and the Transport Security Model have no access to the model-specific LCD. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, February 27, 2007 11:32 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Tmsm#4: persistent session info > > On Tue, Feb 27, 2007 at 11:07:06AM -0500, David Harrington wrote: > > Hi, > > > > > I have not seen any further comments on this. Hence, I assume that > > we > > > like to define that "session state is released if a session is > > > closed". If you believe this is wrong, please speak up now. > > > > I believe the complaint is that we specified the state was released > > when the session is closed; this should be an > implementation decision, > > since all release handling is implementation-specific. > > > > The important point is we should not rely on any specific > > implementation choice, so checking to see if the session is still in > > the LCD to determine that the session has not been closed is > > inappropriate in our document. > > > > I changed the documents to reflect this > implementation-specific view. > > Dave, can you please post the new wording so that we can check whether > we agree with it? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:20:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6wW-0001sy-M5; Tue, 27 Feb 2007 13:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6wW-0001st-0D for isms@ietf.org; Tue, 27 Feb 2007 13:20:52 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6wU-00009P-NB for isms@ietf.org; Tue, 27 Feb 2007 13:20:51 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 583BF11D8DE; Tue, 27 Feb 2007 10:20:37 -0800 (PST) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] Tmsm#4: persistent session info Organization: Sparta References: <166c01c751d2$71865700$0600a8c0@china.huawei.com> <20070227095256.GA8692@elstar.iuhb02.iu-bremen.de> <20b801c75a89$5415e950$0600a8c0@china.huawei.com> Date: Tue, 27 Feb 2007 10:20:37 -0800 In-Reply-To: <20b801c75a89$5415e950$0600a8c0@china.huawei.com> (David Harrington's message of "Tue\, 27 Feb 2007 11\:07\:06 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >>>>> "DH" == David Harrington writes: DH> I believe the complaint is that we specified the state was released DH> when the session is closed; this should be an implementation decision, DH> since all release handling is implementation-specific. I'd suggest you word in a way it such that the following happens: 1) some state MUST be zeroized and freed immediately for security reasons (keys). 2) other state MAY be kept around by the implementation or released immediately. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:22:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6xi-0002DQ-HG; Tue, 27 Feb 2007 13:22:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6xh-0002DI-LD for isms@ietf.org; Tue, 27 Feb 2007 13:22:05 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6xg-0000FE-Ag for isms@ietf.org; Tue, 27 Feb 2007 13:22:05 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8E8575EA41; Tue, 27 Feb 2007 19:22:03 +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 08868-02; Tue, 27 Feb 2007 19:22:00 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 569216D9FF; Tue, 27 Feb 2007 19:22:00 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D37031B206C; Tue, 27 Feb 2007 19:21:58 +0100 (CET) Date: Tue, 27 Feb 2007 19:21:58 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#2: cache contents Message-ID: <20070227182158.GA9989@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , "'Wijnen, Bert (Bert)'" , isms@ietf.org References: <166f01c751db$14408990$0600a8c0@china.huawei.com> <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> <20bc01c75a8a$c44177c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20bc01c75a8a$c44177c0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 11:17:24AM -0500, David Harrington wrote: > Please see revision -06-. > Is that text OK? I assume you are referring to section 5, right? If my guess is correct, I believe this text is just fine for me. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:30:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM768-0002LC-6F; Tue, 27 Feb 2007 13:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM766-0002L6-WC for isms@ietf.org; Tue, 27 Feb 2007 13:30:47 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM765-0001NO-Q3 for isms@ietf.org; Tue, 27 Feb 2007 13:30:46 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007022718304501200che00e>; Tue, 27 Feb 2007 18:30:45 +0000 From: "David Harrington" To: Date: Tue, 27 Feb 2007 13:26:37 -0500 Message-ID: <20c801c75a9c$d16c4440$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 Thread-index: AcdanCaDGWJhj77NSS+pLLE7uB5Ndg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Isms] Request-response pairs 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 realize that I may have made comments that are incorrect. I had been assuming that the pairing of requesta and responses was handled in the message processing subsystem. That would be incorrect. That pairing is done at the application level. So to handle a session-close and session-open between the time of request and the time of response means sharing information between the transport subsystem and the application subsystem - two opposite ends of the SNMP architecture. So much for modularity. If this is a requirement, then I think we can sucessfully say that SNMP should not use lower layer security services, but should do everything internally like USM does. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:38:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7Do-0003uO-DF; Tue, 27 Feb 2007 13:38:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7Dm-0003uC-GA for isms@ietf.org; Tue, 27 Feb 2007 13:38:42 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7Dl-0002Lq-55 for isms@ietf.org; Tue, 27 Feb 2007 13:38:42 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 936D76DABC; Tue, 27 Feb 2007 19:38:40 +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 10039-09; Tue, 27 Feb 2007 19:38:37 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 570BF6DA47; Tue, 27 Feb 2007 19:38:37 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D558C1B213A; Tue, 27 Feb 2007 19:38:35 +0100 (CET) Date: Tue, 27 Feb 2007 19:38:35 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Message-ID: <20070227183835.GA10028@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 10:56:42AM -0500, David Harrington wrote: > As I study this problem, however, I think there are real problems > associated with trying to require the Transport Subsystem to enforce a > decision that the same session must be used for request and > corresponding response. [...] I am not sure I see the problem. Perhaps I am missing the conclusions from your essay. ;-) The dispatcher knows the transport domain and transport address of a receiver. In addition, if we have a response, we have a saved security state reference. Is this not enough information to locate the correct session for a session based transport? Perhaps we need to put the tmStateReference into the security state reference. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 13:41:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7G7-0005D9-Bt; Tue, 27 Feb 2007 13:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7G6-0005CO-4t for isms@ietf.org; Tue, 27 Feb 2007 13:41:06 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7G4-0002e3-UL for isms@ietf.org; Tue, 27 Feb 2007 13:41:06 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007022718410401300n5jmve>; Tue, 27 Feb 2007 18:41:04 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <166c01c751d2$71865700$0600a8c0@china.huawei.com><20070227095256.GA8692@elstar.iuhb02.iu-bremen.de><20b801c75a89$5415e950$0600a8c0@china.huawei.com> Subject: RE: [Isms] Tmsm#4: persistent session info Date: Tue, 27 Feb 2007 13:36:56 -0500 Message-ID: <20c901c75a9e$427f2570$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: Thread-index: AcdanAWt7lOjbR5nRcu6IXC/Yc38LgAAG3Dw X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi wes, I understand your concerns, but please understand we are at an abstract level in these documents, and to the degree that we can, we are outsourcing ALL knowledge of the transport security. I can certainly word the tmsm document to say "some state MUST be zeroized and freed immediately for security reasons (keys), but which state that is is model- and implementation-specific." I don't think does what you want, does it? We could state in the specific transport-models that certain known details about that transport be cleared, but WG consensus seems to be we don't HAVE that information in the transport model; that is kept in the secure transport layer, and we trust the transport layer to tell us whether it has applied/will apply auth and priv services for us. We do not store the keys or the parameters or any other secure-transport information except possibly in an implementation-specific cache. To the greatest degree possible, the transport models do not KNOW any transport-layer sensitive information. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Tuesday, February 27, 2007 1:21 PM > To: David Harrington > Cc: j.schoenwaelder@iu-bremen.de; isms@ietf.org > Subject: Re: [Isms] Tmsm#4: persistent session info > > >>>>> "DH" == David Harrington writes: > > DH> I believe the complaint is that we specified the state > was released > DH> when the session is closed; this should be an > implementation decision, > DH> since all release handling is implementation-specific. > > I'd suggest you word in a way it such that the following happens: > > 1) some state MUST be zeroized and freed immediately for security > reasons (keys). > 2) other state MAY be kept around by the implementation or > released immediately. > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 14:06:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7eg-0007Sv-3O; Tue, 27 Feb 2007 14:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7ee-0007Pe-MY for isms@ietf.org; Tue, 27 Feb 2007 14:06:28 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7ed-0007R6-23 for isms@ietf.org; Tue, 27 Feb 2007 14:06:28 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id B87BE11D8DE; Tue, 27 Feb 2007 11:06:15 -0800 (PST) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Organization: Sparta References: <166b01c751d0$f5d31f90$0600a8c0@china.huawei.com> <185801c7543e$b55c5060$0600a8c0@china.huawei.com> <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> Date: Tue, 27 Feb 2007 11:06:15 -0800 In-Reply-To: <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> (David Harrington's message of "Tue\, 27 Feb 2007 10\:56\:42 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org DH> Sorry, this is a long one. No problem. I'm going to shorten it to specific points. I do believe that you're thinking I'm saying something much different than what I was trying to say. EG: I never at all tried to say what's associated with: DH> Therefore, the idea that the SNMP engine knows which transports DH> are encrypted with AES and which with DES seems out of scope for DH> this WG. Specifically, I agree completely. The SNMP stack shouldn't have to know, understand, etc the nitty gritty details of an already opened transport (it may have to in order to open one, but that's a different case). But that wasn't my point. As worded, the document allows responses (specifically) to go back over any session it so chooses. This is all I take issue with. *If* you simply change that to a MUST this all goes away and there is no need for snmp stack to understand the nitty gritty. All it needs to do is ensure that the response goes back over the same session, which is significantly easier than trying to ensure that transport Y is sufficient when it came in over transport X. If you unsure that if incoming is X then outgoing is X, then no magic knowledge has to go anywhere *except* to ensure that the right transport session is used. Because doing anything else, as you say, is way out of scope! Doing anything less, though, is insecure. You already need to have a binding between the future transport specific security models and the underlying transport. Information is already being bound between them that has never existed before because the transport will be taking care of the security issues and information will have to pass between them for the security model to make heads or tails of the decisions it has to make about the message. DH> Before deciding on an answer for this issue, the WG should seriously DH> consider issue#3 - does a transport model know what operation is DH> contained within a message? i.e. does it know a message is a DH> Response? IMHO, it doesn't need to and I wasn't trying to imply that. What I think MUST be able to happen is that the security model must be able to say "use session X and nothing else". I'm not trying to state that the transport itself needs to know the internals of the packet. I'm trying to state that if the system as a whole can't promise that, the system is broken. I honestly don't care whether the decision happens at the transport level or in the security model level. But the wording today implies the transport layer gets to make a security decision (which secure transport to use) without guidance from anywhere else. It shouldn't be in charge of securing data. It should be a minion that is being directed by the security model because doing anything else means the transport can trump the security model. I fail to see how that's ever a good thing. Now stepping off the high soap box that seemed to grow while I was standing on it... The solution, in my mind, is that for security transports they must be directed by the security model. If the security model is willing to say "I don't care and please use any available session" then that's a different story, but I at least have the trust that it is making an informed decision. I don't think the transport model itself can. I think I had more to say, but I think you're probably happy that I forgot it. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 14:07:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7fF-0007wj-Uu; Tue, 27 Feb 2007 14:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7fE-0007wK-Qb for isms@ietf.org; Tue, 27 Feb 2007 14:07:04 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7fD-0007Xu-Jb for isms@ietf.org; Tue, 27 Feb 2007 14:07:04 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007022719070301300n48rpe>; Tue, 27 Feb 2007 19:07:03 +0000 From: "David Harrington" To: References: <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> <20070227183835.GA10028@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms] Tmsm#1: MUST Responses go back on the same channel? Date: Tue, 27 Feb 2007 14:02:55 -0500 Message-ID: <20ca01c75aa1$e39a4040$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: <20070227183835.GA10028@elstar.iuhb02.iu-bremen.de> Thread-index: AcdanoGoAZvDI4ibToaUx/z6HTuInAAAK3nA X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, OK. Maybe I'm seeing problems that don't exist. Please tell me which text in which document needs to be changed to meet the MUST requirement. Please be sure the ASIs and cache definitions deliver the necessary information to where it is needed. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, February 27, 2007 1:39 PM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the > same channel? > > On Tue, Feb 27, 2007 at 10:56:42AM -0500, David Harrington wrote: > > > As I study this problem, however, I think there are real problems > > associated with trying to require the Transport Subsystem > to enforce a > > decision that the same session must be used for request and > > corresponding response. > > [...] > > I am not sure I see the problem. Perhaps I am missing the conclusions > from your essay. ;-) The dispatcher knows the transport domain and > transport address of a receiver. In addition, if we have a response, > we have a saved security state reference. Is this not enough > information > to locate the correct session for a session based transport? > Perhaps we > need to put the tmStateReference into the security state reference. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 14:13:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7lT-0004k0-99; Tue, 27 Feb 2007 14:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7lR-0004ht-8F for isms@ietf.org; Tue, 27 Feb 2007 14:13:29 -0500 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7lP-0000Qf-Ve for isms@ietf.org; Tue, 27 Feb 2007 14:13:29 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 9A47611D8DE; Tue, 27 Feb 2007 11:13:16 -0800 (PST) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] Issue#5: Do Informs work correctly? Organization: Sparta References: <166801c751ce$0f3c2060$0600a8c0@china.huawei.com> Date: Tue, 27 Feb 2007 11:13:16 -0800 In-Reply-To: <166801c751ce$0f3c2060$0600a8c0@china.huawei.com> (David Harrington's message of "Fri\, 16 Feb 2007 08\:26\:26 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >>>>> "DH" == David Harrington writes: DH> We know USM differs in its handling of Informs; are there non-USM DH> differences? The contexntEngineID? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 17:29:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAp3-0000sz-9w; Tue, 27 Feb 2007 17:29:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMADq-0003Bn-IJ for isms@ietf.org; Tue, 27 Feb 2007 16:50:58 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9kt-0004Gn-CM for isms@ietf.org; Tue, 27 Feb 2007 16:21:23 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1RLKxA8009756; Tue, 27 Feb 2007 15:21:00 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 15:20:59 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 22:20:57 +0100 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] Tmsm#2: cache contents Date: Tue, 27 Feb 2007 22:20:57 +0100 Message-ID: In-reply-to: <20070227182158.GA9989@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#2: cache contents Thread-Index: AcdanDM4X1uemCaRQcePGQXafrNwpgAF+eMQ References: <166f01c751db$14408990$0600a8c0@china.huawei.com> <20070227095930.GB8692@elstar.iuhb02.iu-bremen.de> <20bc01c75a8a$c44177c0$0600a8c0@china.huawei.com> <20070227182158.GA9989@elstar.iuhb02.iu-bremen.de> From: "Wijnen, Bert \(Bert\)" To: , "David Harrington" X-OriginalArrivalTime: 27 Feb 2007 21:20:57.0995 (UTC) FILETIME=[2C2B15B0:01C75AB5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org A quick read seems to make me happy. I may come back to this when I reread the whole doc.=20 But at first sight iy looks fine. Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: dinsdag 27 februari 2007 19:22 > To: David Harrington > Cc: Wijnen, Bert (Bert); isms@ietf.org > Subject: Re: [Isms] Tmsm#2: cache contents >=20 > On Tue, Feb 27, 2007 at 11:17:24AM -0500, David Harrington wrote: >=20 > > Please see revision -06-. > > Is that text OK? >=20 > I assume you are referring to section 5, right? If my guess=20 > is correct, I believe this text is just fine for me. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Feb 27 17:31:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMArJ-0002EX-HD; Tue, 27 Feb 2007 17:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMADq-0003C9-IG for isms@ietf.org; Tue, 27 Feb 2007 16:50:58 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9kt-0004Gh-CN for isms@ietf.org; Tue, 27 Feb 2007 16:21:23 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1RLKxA6009756; Tue, 27 Feb 2007 15:20:59 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 15:20:59 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 22:20:57 +0100 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] Tmsm#6: double-authentication Date: Tue, 27 Feb 2007 22:20:52 +0100 Message-ID: In-reply-to: <20070227144108.GA9212@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#6: double-authentication Thread-Index: AcdafV72Ftde8AnlT0Ck9btzy0kOQwAN4Qrg References: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> <20070227144108.GA9212@elstar.iuhb02.iu-bremen.de> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 27 Feb 2007 21:20:57.0524 (UTC) FILETIME=[2BE33740:01C75AB5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: dinsdag 27 februari 2007 15:41 > To: Wijnen, Bert (Bert) > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] Tmsm#6: double-authentication >=20 > On Mon, Feb 19, 2007 at 03:40:42PM +0100, Wijnen, Bert (Bert) wrote: >=20 > > > If the type of authentication provided by the=20 > transport layer (e.g. > > > TLS) is considered adequate to secure and/or encrypt=20 > the message, but > > > inadequate to provide the desired granularity of=20 > access control (e.g. > > > user-based), then a second authentication (e.g., one=20 > provided via a > > > RADIUS server) MAY be used to provide the=20 > authentication identity > > > which is bound to the securityName. This approach=20 > would require a > > > good analysis of the potential for man-in-the-middle=20 > attacks or > > > masquerade possibilities. > > >=20 > > > Bert (1/9): > > > It does not say anything about at what point in the=20 > process steps this > > > mapping from RADIUS authenticated identity to a=20 > securityName needs > > > to take place. Maybe we want to leave that open. But it=20 > seems to me > > > that the least we can say is that: it MUST bde done for incoming > > > messages before the security model passes securityName=20 > to the message > > > processing model via the processIncoming() ASI.=20 >=20 > Why do we have to talk about this in this document at all? Is=20 > it not the job of the RADIUS integration document to spell=20 > out when and where in the processing RADIUS can be called,=20 > which attributes are relevant and how the RADIUS interaction=20 > may change values of things such as the securityName? Such a=20 > document should then be precise where things happen. >=20 CHANGING the securityName at some point during the process????? I am not so sure this is wise. This is in fact exactly why I wanted to make sure that we prescribe where the securityName is determined. > I would like to treat a secure transport model as a block box=20 > which provides me with an authenticated securityName etc. and=20 > I would leave it to the specifications of such a secure=20 > transport model to tell me how things work (and this includes=20 > AAA services such as RADIUS). >=20 Yep.... but once we start processing the message, I think that is where we want to be sure we have securtyName, securityLevel and that such do not change anymore. Bert > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 28 03:50:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKVT-0006de-Mf; Wed, 28 Feb 2007 03:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKVR-0006dT-SC for isms@ietf.org; Wed, 28 Feb 2007 03:49:49 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMKVQ-0000g4-DP for isms@ietf.org; Wed, 28 Feb 2007 03:49:49 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B25EC5ACE6; Wed, 28 Feb 2007 09:49:47 +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 29296-02; Wed, 28 Feb 2007 09:49:44 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id C9A926DAA9; Wed, 28 Feb 2007 09:49:40 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 428451B2AE5; Wed, 28 Feb 2007 09:49:39 +0100 (CET) Date: Wed, 28 Feb 2007 09:49:39 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] Tmsm#6: double-authentication Message-ID: <20070228084939.GA10733@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Wijnen, Bert (Bert)" , David Harrington , isms@ietf.org References: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> <20070227144108.GA9212@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 10:20:52PM +0100, Wijnen, Bert (Bert) wrote: > > Why do we have to talk about this in this document at all? Is > > it not the job of the RADIUS integration document to spell > > out when and where in the processing RADIUS can be called, > > which attributes are relevant and how the RADIUS interaction > > may change values of things such as the securityName? Such a > > document should then be precise where things happen. > > > > CHANGING the securityName at some point during the process????? > I am not so sure this is wise. This is in fact exactly why I > wanted to make sure that we prescribe where the securityName > is determined. My understanding of RFC 3411 is that the security model determines the securityName. We do not change that by introducing a transport subsystem. The transport security model says that the securityName is provided by the secure transport and accessed via the tmStateReference. I believe this is what the documents should say. We should refrain from discussing RADIUS or any other fancy AAA service that can/might/... be called in the transport subsystem and the transport security model documents. [Note that I did not suggest to change securityName - but I do believe that RADIUS might be called during the processing, e.g. to obtain a securityName to groupName mapping. So I believe my quoted comment above stands.] > > I would like to treat a secure transport model as a block box > > which provides me with an authenticated securityName etc. and > > I would leave it to the specifications of such a secure > > transport model to tell me how things work (and this includes > > AAA services such as RADIUS). > > > > Yep.... but once we start processing the message, I think that is where > we want to be sure we have securtyName, securityLevel and that such do > not change anymore. I agree. I would expect that a document which proposed to call RADIUS in the middle of the processing to change parameters will have to come up with a very convincing story. My point at this time is to get the open issues on the transport subsystem document closed and I believe we do not need to discuss RADIUS aspects in the transport subsystem document. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 28 10:49:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMR3z-0008S3-IJ; Wed, 28 Feb 2007 10:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMR3y-0008Rs-4L for isms@ietf.org; Wed, 28 Feb 2007 10:49:54 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMR3w-0006R6-JW for isms@ietf.org; Wed, 28 Feb 2007 10:49:54 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 19C4F6DBAB; Wed, 28 Feb 2007 16:49: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 16108-03; Wed, 28 Feb 2007 16:49:48 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 925736D253; Wed, 28 Feb 2007 16:49:48 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 020F61B3497; Wed, 28 Feb 2007 16:49:46 +0100 (CET) Date: Wed, 28 Feb 2007 16:49:46 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#4: persistent session info Message-ID: <20070228154946.GA11556@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , 'Wes Hardaker' , isms@ietf.org References: <20c901c75a9e$427f2570$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20c901c75a9e$427f2570$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 01:36:56PM -0500, David Harrington wrote: > Hi wes, > > I understand your concerns, but please understand we are at an > abstract level in these documents, and to the degree that we can, we > are outsourcing ALL knowledge of the transport security. > > I can certainly word the tmsm document to say "some state MUST be > zeroized and freed immediately for security reasons (keys), but which > state that is is model- and implementation-specific." > > I don't think does what you want, does it? > > We could state in the specific transport-models that certain known > details about that transport be cleared, but WG consensus seems to be > we don't HAVE that information in the transport model; that is kept in > the secure transport layer, and we trust the transport layer to tell > us whether it has applied/will apply auth and priv services for us. We > do not store the keys or the parameters or any other secure-transport > information except possibly in an implementation-specific cache. > > To the greatest degree possible, the transport models do not KNOW any > transport-layer sensitive information. Can we please try to avoid over specifying every little detail? In our prototype implementation, we simply tell the ssh library or the tls library to close the session by calling the appropriate API function and we trust that the libraries do a reasonable job. Also note that TLS, for example, allows session resumption and if an implementation chooses to take advantage of this, you only clear some of the state associated with a session. The architectural documents should allow for such things to happen in a given transport model and not mandate that I can't support such nice features and that I have to zero out something for which I have a valid reason to not zero it out. We posted a -00 draft for a TLS transport and it describes how we support TLS session resumption and IMHO the TLS transport model is the right place to deal with this feature. But even then, we prefer to not spell out what exactly needs to be zeroed since in implementation terms, I trust openssl or gnutls to just do the right thing. (I was speaking as a technical contributor - just in case. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 28 11:55:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMS5F-0002Cb-Aa; Wed, 28 Feb 2007 11:55:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMS5E-0002CS-0Q for isms@ietf.org; Wed, 28 Feb 2007 11:55:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMS5C-0005aD-Cq for isms@ietf.org; Wed, 28 Feb 2007 11:55:15 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1SGt1XF017601; Wed, 28 Feb 2007 10:55:12 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 10:55:04 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:54:58 +0100 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] Tmsm#6: double-authentication Date: Wed, 28 Feb 2007 17:54:52 +0100 Message-ID: In-reply-to: <20070228084939.GA10733@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Tmsm#6: double-authentication Thread-Index: AcdbFXycvoJcCeQgRfOXSyMlD2+qFwAQ0UJA References: <167c01c751e3$c3ba9700$0600a8c0@china.huawei.com> <20070227144108.GA9212@elstar.iuhb02.iu-bremen.de> <20070228084939.GA10733@elstar.iuhb02.iu-bremen.de> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 28 Feb 2007 16:54:58.0424 (UTC) FILETIME=[2DEF8F80:01C75B59] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: woensdag 28 februari 2007 9:50 > To: Wijnen, Bert (Bert) > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] Tmsm#6: double-authentication >=20 > On Tue, Feb 27, 2007 at 10:20:52PM +0100, Wijnen, Bert (Bert) wrote: >=20 > > > Why do we have to talk about this in this document at=20 > all? Is it not=20 > > > the job of the RADIUS integration document to spell out when and=20 > > > where in the processing RADIUS can be called, which=20 > attributes are=20 > > > relevant and how the RADIUS interaction may change values=20 > of things=20 > > > such as the securityName? Such a document should then be precise=20 > > > where things happen. > > >=20 > >=20 > > CHANGING the securityName at some point during the process????? > > I am not so sure this is wise. This is in fact exactly why I wanted to=20 > > make sure that we prescribe where the securityName is determined. >=20 > My understanding of RFC 3411 is that the security model=20 > determines the securityName. We do not change that by=20 > introducing a transport subsystem. The transport security=20 > model says that the securityName is provided by the secure=20 > transport and accessed via the tmStateReference. I believe=20 > this is what the documents should say. Rigght, and when we come back from the security-model, then we DO have the securityName as a paramter that passes along the subsequent ASIs. And so, I would get worried if some access model (or whatever) can later call RADIUS and change the securityName. And so that is what I thought we ought to specify. Bert > We should refrain from discussing RADIUS or any other fancy=20 > AAA service that can/might/... be called in the transport=20 > subsystem and the transport security model documents. >=20 If it gets called at those places, I am fine. I believe DBH suggested it could be called later in the process, and that would make me worried. > [Note that I did not suggest to change securityName - but I=20 > do believe that RADIUS might be called during the processing, e.g. > to obtain a securityName to groupName mapping. So I believe=20 > my quoted comment above stands.] > =20 > > > I would like to treat a secure transport model as a block=20 > box which=20 > > > provides me with an authenticated securityName etc. and I would=20 > > > leave it to the specifications of such a secure transport=20 > model to=20 > > > tell me how things work (and this includes AAA services such as=20 > > > RADIUS). > > >=20 > >=20 > > Yep.... but once we start processing the message, I think that is=20 > > where we want to be sure we have securtyName, securityLevel=20 > and that=20 > > such do not change anymore. >=20 > I agree. I would expect that a document which proposed to=20 > call RADIUS in the middle of the processing to change=20 > parameters will have to come up with a very convincing story.=20 > My point at this time is to get the open issues on the=20 > transport subsystem document closed and I believe we do not=20 > need to discuss RADIUS aspects in the transport subsystem document. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 28 12:03:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSD0-000714-Tr; Wed, 28 Feb 2007 12:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSCz-00070v-GA for isms@ietf.org; Wed, 28 Feb 2007 12:03:17 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMSCs-00075X-Pn for isms@ietf.org; Wed, 28 Feb 2007 12:03:17 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 07C636D9FF; Wed, 28 Feb 2007 18:03:10 +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 24022-04; Wed, 28 Feb 2007 18:03:06 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7F6B26DB86; Wed, 28 Feb 2007 18:03:06 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id EA4D81B3682; Wed, 28 Feb 2007 18:03:04 +0100 (CET) Date: Wed, 28 Feb 2007 18:03:04 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the same channel? Message-ID: <20070228170304.GA11668@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , isms@ietf.org References: <20070227094145.GA8600@elstar.iuhb02.iu-bremen.de> <20b701c75a87$e04fa7f0$0600a8c0@china.huawei.com> <20070227183835.GA10028@elstar.iuhb02.iu-bremen.de> <20ca01c75aa1$e39a4040$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20ca01c75aa1$e39a4040$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tue, Feb 27, 2007 at 02:02:55PM -0500, David Harrington wrote: > OK. Maybe I'm seeing problems that don't exist. > > Please tell me which text in which document needs to be changed to > meet the MUST requirement. I think we are talking about the following text: A Transport Model implementation MAY reuse an already established session with the appropriate transportDomain, transportAddress, securityName, securityModel, and securityLevel characteristics for delivery of a message containing a different pduType than originally caused the session to be created. For example, an implementation that has an existing session originally established to receive a request MAY use that session to send an outgoing notification, and MAY use a session that was originally established to send a notification to send a request. Responses SHOULD be returned using the same session that carried the corresponding request message. Reuse of sessions is not required for conformance. I think Wes' proposal was to change the SHOULD into a MUST. I can live with this (as long as we consider a resumed TLS session the same session - so we might end up discussing what a session is ;-). I am also fine with a SHOULD in the RFC 2119 sense: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Since we are on an architectural level, using SHOULD and thereby putting the burdon on security model designers to provide an explanation if they choose to not do the SHOULD is just fine. > Please be sure the ASIs and cache definitions deliver the necessary > information to where it is needed. If the ASIs support a SHOULD, they should also support a MUST. (The SHOULD is pointless if the ASIs do not provide the information to make it happen.) So to summarize, I finally concluded for myself that the SHOULD wording is just fine as it implies that transport models that do not return responses over the same session need to explain why. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Feb 28 18:49:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYYS-00012P-6V; Wed, 28 Feb 2007 18:49:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYYR-00012K-1I for isms@ietf.org; Wed, 28 Feb 2007 18:49:51 -0500 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMYYP-0002gd-NN for isms@ietf.org; Wed, 28 Feb 2007 18:49:51 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l1SNnhej016314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 18:49:43 -0500 (EST) Date: Wed, 28 Feb 2007 18:49:43 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: Re: [Isms] Request-response pairs Message-ID: <59C85CC4D01D2312469A0EC8@sirius.fac.cs.cmu.edu> In-Reply-To: <20c801c75a9c$d16c4440$0600a8c0@china.huawei.com> References: <20c801c75a9c$d16c4440$0600a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01jjpr8Pii4GTaheNxwbibXyWsohsVbuT7r5lVxLo=; 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: 21c69d3cfc2dd19218717dbe1d974352 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 Tuesday, February 27, 2007 01:26:37 PM -0500 David Harrington wrote: > Hi, > > I realize that I may have made comments that are incorrect. > I had been assuming that the pairing of requesta and responses was > handled in the message processing subsystem. That would be incorrect. > That pairing is done at the application level. I was wondering about that. > So to handle a session-close and session-open between the time of > request and the time of response means sharing information between the > transport subsystem and the application subsystem - two opposite ends > of the SNMP architecture. So much for modularity. Hm? If the session is closed between when the request is received and when the response is ready, you lose. The session over which you must send the response no longer exists. > If this is a requirement, then I think we can sucessfully say that > SNMP should not use lower layer security services, but should do > everything internally like USM does. I think that's being a little extreme. We can solve the problem without throwing everything away and starting over, and I think we should. All that is required si for the SM to send some opaque thing up the stack to the application, which is sent back down with the response. This thing contains whatever the SM needs to insure the response goes back over the same session, if that is required (and the SM gets to decide this, or perhaps the SM specification gets to specify this). For messages that are not responses, the "thing" is omitted, which tells the SM it can use any session it likes. BTW, this is still a security issue - it is the SM that gets to decide whether the same session is needed, not the transport mapping, and thus it is the SM that needs to toss an opaque object "over the fence" so to speak. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms