From ietfdbh@comcast.net Fri May 1 05:43:06 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE7D28C15A for ; Fri, 1 May 2009 05:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bTumBvZjMdE for ; Fri, 1 May 2009 05:43:05 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 9878E3A7203 for ; Fri, 1 May 2009 05:32:14 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA04.westchester.pa.mail.comcast.net with comcast id mAMx1b0050Fqzac54CZfUj; Fri, 01 May 2009 12:33:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id mCZs1b00C0UQ6dC3UCZs3G; Fri, 01 May 2009 12:33:52 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Date: Fri, 1 May 2009 08:33:37 -0400 Message-ID: <045f01c9ca59$0d2b4750$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 Thread-Index: AcnJ0vnqL1gjK/5HTrSnOzCej1tyQwAe5OAg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: opsawg@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:43:06 -0000 Hi, (I have copied this to OPSAWG since that WG is discussed later in this email.) I am not sure how much difference will be encountered between TLS and DTLS support. Trying to do both in one document could be confusing unless there is clear separation. The elements of procedure are especially tricky to get right in ISMS documents. This might be simpler now that we did the SSH TM, whose client/server issues will be similar. I would be interested in understanding which sections in the current document would be impacted by adding TLS to the document. Will it be possible to write most sections in a manner that is independent of the TLS vs DTLS choice, and then capture the differences in separate appendices, or will all the sections, especially EOP, end up with lots of conditional clauses? We need to develop standards that are clear and unambiguous. If putting the two into the same document seriously hurts the clarity, then it should be done as two documents. I think the single most important work to be done following a recharter is AAA-aware access control. Chartering for only that work will probably get it done faster, and that will complete the initial vision of ISMS. The TLS/DTLS work could be done as individual submissions (or is that independent submissions? or AD-sponsored?) I hope Wes's documents are very close to complete, since he has done them in parallel with the SSH work. I would hate to see the WG get bogged down with the TLS/DTLS TMs and not get AAA-aware AC done quickly. I support having TLS and DTLS TMs, because I see growinfg demand for TLS and DTLS transport, but I am not sure there is compelling demand for them at this time. My suggestion would to be recharter for AAA-aware AC, with tight milestones - on the order of six to nine months. When that work is complete, then take on the TLS/DTLS work. -- consistency -- I will note that there is a Proposed Standard for syslog/TLS, and netconf/TLS is in the RFC Editor's queue. There are two proposals for syslog over DTLS. The authors of the two proposals are discussing merging the two documents. Syslog WG is also debating whether to recharter. The syslog chairs and OPS/SEC ADs are discussing whether to do DTLS support in the syslog WG or in OPSAWG or a new syslog-ops WG. The syslog/TLS standard already discusses at length how TLS should be used, including cyphers, certificates, fingerprinting, what to do when a CA is unavailable, and so on, and the newer DTLS draft simply points to the syslog over TLS standard for the TLS processing. The newer syslog over DTLS draft just describes the differences between DTLS and TLS processing, and specific changes to syslog transport. And that can be seen as syslog OPS work, not syslog SEC work. If both syslog over DTLS(TLS) and SNMP over DTLS(TLS) were done in OPSAWG, there might be a greater chance of consistent DTLS(TLS) security, and Wes's draft might be able to simply point to the TLS security processing in the syslog over TLS Proposed Standard as well. If Wes and the syslog authors separated the DTLS-specific differences into a separate document, possibly published in the sylog-sec WG, then both syslog and SNMP transport models could point to that draft. Of course, the syslog drafts are way simpler because they don't need RFC3411 compatibility. The newer of the sylog/DTLS drafts was deliberately made consistent with the syslog/TLS Proposed Standard, and was made consistent with Wes's DTLS-specific support. The Netconf/TLS draft was also made consistent with the syslog/TLS draft. I think Wes tried to keep his draft consistent with other NM/DTLS work going on. So draft consistency work has already been done; it has just already been done by individual editors rather than as a deliberate SEC-area and OPS-area approach. ISMS was originally started because operators want to be able to utilize their existing security systems rather than having SNMP-specific and syslog-specific security infrastructures. By making the TLS and DTLS layers consistent for NM interfaces, we help accomplish that goal. And if we separate the TLS/DTLS support from the NM transport models, we can have the SEC area maintain the security protocol applicability, while OPS maintains the NM bindings. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Thursday, April 30, 2009 4:34 PM > To: isms@ietf.org > Subject: [Isms] Latest Proposed Charter Text > > > Enclosed is the last charter text (which received no comments > after the > last submission). > > The only outstanding question I can think of is whether there was > agreement to include TLS into the DTLS draft or not. Everyone in the > discussion seemed to be "on the fence" so I didn't include it in the > text below, taking that as "not consensus at this time". If > people wish > TLS to be taken into account, now is the time to speak up. > > > > Integrated Security Model for SNMP (isms) > > Last Modified: XXXX > > Additional information is available at tools.ietf.org/wg/isms > > Chair(s): > * Juergen Schoenwaelder > > Security Area Director(s): > * Tim Polk > * Pasi Eronen > > Security Area Advisor: > * Pasi Eronen > > Mailing Lists: > > General Discussion: isms@ietf.org > To Subscribe: isms-request@ietf.org > In Body: in body: (un)subscribe > Archive: > http://www.ietf.org/mail-archive/working-groups/isms/current/m > aillist.html > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be > tackled by the working group involved only these pieces. Additional > work on other transport models and other security extensions were to > wait until the initial transport architecture and defining documents > were completed. > > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. > However, > it still remains impossible to centrally authorize a given SNMP > transaction as on-device pre-existing authorization configuration is > still required. In order to leverage a centralized RADIUS service to > its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to the View-based > Access Control Model (VACM), to obtain authorization > information for an > authenticated principal from RADIUS. The authorization > information will > be limited to mapping the authenticated principal to existing access > control polices, defining session timeouts, and similar session > parameters. This mechanism will not provision the detailed access > control rules. > > Additionally, new work will be undertaken to define a DTLS-based > transport that can offer support for environments that prefer > certificate authentication and/or datagram-based transmissions. > Certificate based authentication is desirable for many > environments with > a centralized authentication service. Datagram based > transports may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A > DTLS-based transport > would offer a solution that addresses both of these situations. > > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop a > DTLS-based Transport Model. > > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). > > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide > a binding > between a user and preconfigured VACM policies via > dynamic additions > to the securityToGroupname table. Additionally, specify a > time limit > for access decisions, and such a time limit should be used to > garbage collect expired dynamic securityToGroup mappings. > > - Specify the DTLS transport for SNMP. > > Goals and Milestones: > Jul 2009 Publish initial documentation on the DTLS > transport for SNMP > Jul 2009 Publish initial documentation for the > centralized access control > Jan 2010 Submit documentation on the DTLS transport > for SNMP to IESG > Jan 2010 Submit documentation for the centralized > access control to IESG > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Fri May 1 06:19:26 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B8228C18B for ; Fri, 1 May 2009 06:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7N5BnPXP8Y3 for ; Fri, 1 May 2009 06:19:25 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id BCE8128C190 for ; Fri, 1 May 2009 06:16:21 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA09.westchester.pa.mail.comcast.net with comcast id mBYv1b0070QuhwU59DHm0a; Fri, 01 May 2009 13:17:46 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id mDHl1b00H4H2mdz3NDHlnS; Fri, 01 May 2009 13:17:46 +0000 From: "Dave Nelson" To: References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> Date: Fri, 1 May 2009 09:17:51 -0400 Message-ID: <51C8991BA900436F99C3C9559C235900@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnJ0vnqL1gjK/5HTrSnOzCej1tyQwAe5OAgAAPkslA= In-Reply-To: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: opsawg@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 13:19:26 -0000 David Harrington writes... > I think the single most important work to be done following a > recharter is AAA-aware access control. I concur. > Chartering for only that work will probably get it done faster, and > that will complete the initial vision of ISMS. This seems like a non sequitur. I don't see any serialization of work that would occur because of scarce resources. > If both syslog over DTLS(TLS) and SNMP over DTLS(TLS) were done in > OPSAWG, there might be a greater chance of consistent DTLS(TLS) > security, and Wes's draft might be able to simply point to the TLS > security processing in the syslog over TLS Proposed Standard as well. That might be true. OTOH, is there any benefit in doing that work in a Security Area WG rather than an Operations & Management Area WG? > So draft consistency work has already been done; it has just already > been done by individual editors rather than as a deliberate SEC-area > and OPS-area approach. ISMS was originally started because operators > want to be able to utilize their existing security systems rather than > having SNMP-specific and syslog-specific security infrastructures. By > making the TLS and DTLS layers consistent for NM interfaces, we help > accomplish that goal. And if we separate the TLS/DTLS support from the > NM transport models, we can have the SEC area maintain the security > protocol applicability, while OPS maintains the NM bindings. Certainly there is some benefit to operators in cross-protocol operational consistency. Of course I've found that obtaining that kind of consistency usually slows things down. Not that speed of completion is the only driving factor, of course. From ietfdbh@comcast.net Fri May 1 07:29:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104F028C1DE for ; Fri, 1 May 2009 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I+lLvzqMqFk for ; Fri, 1 May 2009 07:29:17 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id ABC8328C1F1 for ; Fri, 1 May 2009 07:27:40 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id mB8m1b0020vyq2s53EUxLd; Fri, 01 May 2009 14:28:57 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id mEV41b00e0UQ6dC3REV4fm; Fri, 01 May 2009 14:29:05 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> <51C8991BA900436F99C3C9559C235900@NEWTON603> Date: Fri, 1 May 2009 10:29:03 -0400 Message-ID: <046e01c9ca69$2d7be180$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 Thread-Index: AcnJ0vnqL1gjK/5HTrSnOzCej1tyQwAe5OAgAAPkslAAAiUGYA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <51C8991BA900436F99C3C9559C235900@NEWTON603> Cc: opsawg@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:29:18 -0000 Hi, > > Chartering for only that work will probably get it done faster, and > > that will complete the initial vision of ISMS. > > This seems like a non sequitur. I don't see any > serialization of work that > would occur because of scarce resources. We only have about six active people in this WG, and they will be involved in both activities. If the AAA-AC becomes in any way dependent on the TLS/DTLS work, I would hate to see the AAA delayed. Maybe you are right. AAA-AC is in the AC subsystem, while TLS/DTLS is in the transport subsystem. Maybe the work will be orthogonal. > > > If both syslog over DTLS(TLS) and SNMP over DTLS(TLS) were done in > > OPSAWG, there might be a greater chance of consistent DTLS(TLS) > > security, and Wes's draft might be able to simply point to the TLS > > security processing in the syslog over TLS Proposed > Standard as well. > > That might be true. OTOH, is there any benefit in doing that > work in a > Security Area WG rather than an Operations & Management Area WG? As Pasi pointed out in the syslog/DTLS discussions, the DTLS processing should be basically the same as the TLS processing. The dufferences are generally minor at the secureity level. But the OPS-level applicability and bindings can be substantially different. If you consider these as two different related pieces, much as SSHTM and the SSH processing are distinct, then it would seem to make sense to me to have the DTLS processing be done in the SEC area. Some of the work is really about understanding the applicability for different tasks. That was a major issue for SSTM, as we had to figure out whether notification originators should be clients or servers. That could get built into the SEC area standards and/or applicability statements for how to use TLS/DTLS for NM. Then the OPS area can deal with writing bindings between specific NM protocols and the underlying, standardized DTLS and TLS layer services. > > > So draft consistency work has already been done; it has just already > > been done by individual editors rather than as a deliberate SEC-area > > and OPS-area approach. ISMS was originally started because operators > > want to be able to utilize their existing security systems > rather than > > having SNMP-specific and syslog-specific security > infrastructures. By > > making the TLS and DTLS layers consistent for NM interfaces, we help > > accomplish that goal. And if we separate the TLS/DTLS > support from the > > NM transport models, we can have the SEC area maintain the security > > protocol applicability, while OPS maintains the NM bindings. > > Certainly there is some benefit to operators in > cross-protocol operational > consistency. Of course I've found that obtaining that kind > of consistency > usually slows things down. Not that speed of completion is > the only driving > factor, of course. It could slow things down, BUT ... much of that work has already been done because the authors of the related documents (Wes, Linda, Rainer, Tom, Badra), have worked to be fairly consistent already. Each NM protocol community that needs secure transport has already completed its work. The remaining TLS and DTLS work is optional to handle less immediate use cases. A little delay for the sake of consistency can probably be accommodated without problems. dbh > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Fri May 1 11:53:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FC43A6D36; Fri, 1 May 2009 11:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWYZ5YtXB0n8; Fri, 1 May 2009 11:53:23 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 06A8F3A67FF; Fri, 1 May 2009 11:53:22 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3D7E039A0F4; Fri, 1 May 2009 11:54:43 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> Date: Fri, 01 May 2009 11:54:43 -0700 In-Reply-To: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> (David Harrington's message of "Fri, 1 May 2009 08:33:37 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org, isms@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:53:24 -0000 DH> I am not sure how much difference will be encountered between TLS and DH> DTLS support. Trying to do both in one document could be confusing DH> unless there is clear separation. Most of TLS and DTLS are identical in functionality. The certificate handling, etc would be identical and wouldn't change. What would change: 1) The elements of procedure. You're right that it's tricky to get right. The good news is that I think the current draft already reflects a lot of what would be needed. I don't think you've read the current EOPs yet, but if you go look at it you'll notice that right now it already separates out DTLS over UDP from DTLS over SCTP where it makes sense to do so. And that's really only for identifying incoming packets, because TLS and DTLS don't have an internal session identifier. Everything else is identical. Really, TLS would be a similar case to SCTP as both TCP and SCTP are stream based protocols that have internal kernel identification procedures. 2) We'd need another domain/address format. This is trivial. 3) Various wording would need to be cleaned up to include TLS everywhere as appropriate. I don't think this would be difficult, but it would require a complete draft review. Something is likely to be needed anyway. DH> Will it be possible to write most sections in a manner that is DH> independent of the TLS vs DTLS choice, and then capture the DH> differences in separate appendices, or will all the sections, DH> especially EOP, end up with lots of conditional clauses? I think most of the draft would be very similar to what it is now, with slightly more generic wording. The only spot I can think of that needs extra care is the EOP. But I think the existing EOP is close to what we want anyway for how TLS would need to be added. DH> I think the single most important work to be done following a recharter DH> is AAA-aware access control. You may certainly think that. DH> Chartering for only that work will probably get it done faster, and that DH> will complete the initial vision of ISMS. But I'm not sure that the community thinks your prioritization there is right. From the meeting minutes: | | DTLS | Radius | | Authors | 1 [1] | 0 [2] | | Reviewers | 6 | 5 | | Supporters | 9 | 6 | [1] it wasn't asked if anyone else wanted to help edit [2] Editors have since agreed to work on it Now, not everyone was there and certainly the authors of the radius draft alone pick the numbers up a bit in the right most column. But I don't think, based on the numbers, that your weighing of importance is anything other than your own personal preference. I also don't think that one document would hamper the other. I'm not sure they would. In fact, I'm fairly positive they wouldn't. They're even on different time schedules according to the draft charter and I don't think that if you wished to drop the DTLS work that anyone would be willing to move the other schedule dates for AAA mappings up. They're very independent drafts. DH> I support having TLS and DTLS TMs, because I see growing demand for DH> TLS and DTLS transport, but I am not sure there is compelling demand DH> for them at this time. You see demand but no demand??? Huh? As an implementer, I've seen demand for DTLS. I've never seen demand for AAA support. DH> I think Wes tried to keep his draft consistent with other NM/DTLS work DH> going on. I spent most of my time keeping the SNMP/DTLS work consistent with the other ISMS work (TSM and SSH). -- from your other message -- DH> If the AAA-AC becomes in any way dependent on the TLS/DTLS work, I DH> would hate to see the AAA delayed. I don't see how that would ever happen. DH> If you consider these as two different related pieces, much as SSHTM DH> and the SSH processing are distinct, then it would seem to make DH> sense to me to have the DTLS processing be done in the SEC area. I don't see the purpose of considering moving it. The expertise for TLS is here in the security area. The current ADs already have knowledge of the whole ISMS related solution and architecture. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Mon May 4 12:25:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAB83A693E for ; Mon, 4 May 2009 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA8+nxWUexca for ; Mon, 4 May 2009 12:25:06 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id E098528C167 for ; Mon, 4 May 2009 12:25:05 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with comcast id nSBy1b0050cZkys52XSQHC; Mon, 04 May 2009 19:26:24 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id nXSX1b00H0UQ6dC3WXSXMd; Mon, 04 May 2009 19:26:32 +0000 From: "David Harrington" To: "'Wes Hardaker'" Date: Mon, 4 May 2009 15:26:30 -0400 Message-ID: <059401c9ccee$3a763d40$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 Thread-Index: AcnM7joW+QmMxmw+TP2Dd+wTl1OLNw== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: [Isms] review of dtls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:25:15 -0000 Hi Wes, I started reviewing your dtls-03 draft. I got ten pages in before being distracted by other priorities. But I might as well comment on that much ;-) 1) RFC3411 is NOT The SNMPv3 architecture. It is "An" architecture. If we want to be able to ever get rid of this architecture and its ASI shackles, please do not refer to it as THE SNMPv3 architecture. It is the RFC3411 architecture. 2) page 5 Introduction. I recommend moving the 4th paragraph "this document also specifies" before the third paragraph "Managed objects are accessed". 3) you have quite a lot of duplicate cxut-and-paste "boilerplate" discussion. section 1.1 is duplicated in section 1.2 paragraph 6 and paragraph 10. Many of the paragraphs on page 7 are also on page 8. 4) The discussion of client/server terminology refers to SSH. 5) section 2.1 discusses threats. I think the bullets go into way too much detail about how DTLS mitigates the threats. All we need here is a list of the threats DTLS mitigates; readers can go read the DTLS spec to see details of the encryption protocols supported and the integrity checking protocols supported. 6) section 2.2 also goes into details about the cryptographic protocols supported by DTLS. We don't need that detail here. 7) section 2.2 discusses that autheintication can be made optional. I recommend moving this discussion to Security Considerations. 8) section 2.3 talks about securityName and the fact it is used for access control. I don't think this is needed. This is covered in the RFC3411 architecture extensively. If you want to make sure people understand how it is used, cite RFC3411 or the Transport Subsystem architectural extension document. 9) section 2.3 says mutual authentication SHOULD always be used with DTLS. Is this actually a requirement of SNMP, or of this model? SNMP permits noAuthNoPriv as a securitylevel, so authentication of any type appears to not be an SNMP requirement. I don't recall whether mutual auth is required for sshtm. 10) section 3 uses a capitaized Dispatcher and a lower case dispatcher. be consistent. I prefer lower case. 11) For the threat analysis in 3.1.1, I recommend you use pointers to the TSMS or SSHTM documents, and just supplement the pointers as needed for DTLS security features. 12) Pasi had the syslog/DTLS draft use pointers to the syslog/TLS RFC to discuss certificate handling, etc. Unless your handling needs to be significantly different for SNMP, I expect Pasi will want you use pointers to the syslog/TLS RFC as well, for consistency of TLS/DTLS configuration requirements and processing behaviors. I'll try to get more to you later. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From wjhns1@hardakers.net Mon May 4 13:37:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51273A7135 for ; Mon, 4 May 2009 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31A2UYSL1dGJ for ; Mon, 4 May 2009 13:37:36 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C13643A713C for ; Mon, 4 May 2009 13:37:36 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8782E399A8E; Mon, 4 May 2009 13:39:02 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <059401c9ccee$3a763d40$0600a8c0@china.huawei.com> Date: Mon, 04 May 2009 13:39:01 -0700 In-Reply-To: <059401c9ccee$3a763d40$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 4 May 2009 15:26:30 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] review of dtls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:37:37 -0000 >>>>> On Mon, 4 May 2009 15:26:30 -0400, "David Harrington" said: DH> I started reviewing your dtls-03 draft. I got ten pages in before DH> being distracted by other priorities. But I might as well comment DH> on that much ;-) I appreciate all comments, even if they're only on part of the document. I'll incorporate them into a future version of the draft. DH> 1) RFC3411 is NOT The SNMPv3 architecture. It is "An" architecture. DH> If we want to be able to ever get rid of this architecture and its ASI DH> shackles, please do not refer to it as THE SNMPv3 architecture. It is DH> the RFC3411 architecture. Good catch. I can't believe I didn't notice that myself ;-) DH> 3) you have quite a lot of duplicate cxut-and-paste "boilerplate" DH> discussion. A bunch of the boilerplates were copied from one of the recent SSH documents, and since that time a bunch of the text was removed from the SSH document but not from the last published DTLS document (though it's changed on my disk). I'll make sure I check the text you're referring to. I'm sure there is more that could be removed. DH> 4) The discussion of client/server terminology refers to SSH. That's already been fixed, but thanks. DH> 5) section 2.1 discusses threats. I think the bullets go into way too DH> much detail about how DTLS mitigates the threats. All we need here is DH> a list of the threats DTLS mitigates; readers can go read the DTLS DH> spec to see details of the encryption protocols supported and the DH> integrity checking protocols supported. I'm not sure if you're referring to the right section here. 3.1.1 discusses threats (though some of it is also discussed in 2.1). The SSH document has a fairly lengthy threats section too... See [*] below for further discussion on text removal. DH> 6) section 2.2 also goes into details about the cryptographic DH> protocols supported by DTLS. We don't need that detail here. [*] Some of the document was written by others and they had included a lot of background reading material. More so than in most IETF documents. I left most of it in deliberately in order to see where people think the line should be drawn. You're actually the first to comment on the quantity and relevance of it, but then again it's only fairly recently in the headlights of the WG. Feel free to continue commenting on which sections you think should be shortened and I'll take your opinion and others into consideration as I consider slimming it down. DH> 7) section 2.2 discusses that autheintication can be made optional. I DH> recommend moving this discussion to Security Considerations. If the section stays, I think it's important to note that it can be optional in order to understand the protocol itself. I don't think moving that one sentence to later in the document helps the reader understand the aspects of the protocol. DH> 9) section 2.3 says mutual authentication SHOULD always be used with DH> DTLS. Is this actually a requirement of SNMP, or of this model? DH> SNMP permits noAuthNoPriv as a securitylevel, so authentication of DH> any type appears to not be an SNMP requirement. I don't recall DH> whether mutual auth is required for sshtm. The wording in sshtm is a bit more fuzzy. IMHO, we're defining a secure transport so specifying that you MUST authenticate the client and you SHOULD authenticate the agent are requirements that stem from how you'd use the transport. But I actually think you're right. Because that is already covered later in the document when discussing security levels, so I don't necessarily think it needs to go here too. And the text later properly handles noAuthNoPriv I think as well. DH> 11) For the threat analysis in 3.1.1, I recommend you use pointers to DH> the TSMS or SSHTM documents, and just supplement the pointers as DH> needed for DTLS security features. I think if you compare 3.1.1 from the SSHTM document and this one you'll find they're pretty similar in structure and content. The SSHTM one is shorter though and the wording is a bit more concise. DH> 12) Pasi had the syslog/DTLS draft use pointers to the syslog/TLS RFC DH> to discuss certificate handling, etc. Unless your handling needs to be DH> significantly different for SNMP, I expect Pasi will want you use DH> pointers to the syslog/TLS RFC as well, for consistency of TLS/DTLS DH> configuration requirements and processing behaviors. I'll take a look at the other document to see what they did. I'm sure Pasi will comment on the document on multiple viewpoints. Again, I'll refer to [*] above. DH> I'll try to get more to you later. Thanks, I look forward to them! -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon May 4 15:24:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAA43A6C87 for ; Mon, 4 May 2009 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq8F3RgpN82Z for ; Mon, 4 May 2009 15:24:54 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BD0D83A6B7A for ; Mon, 4 May 2009 15:24:53 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 08EB1399A8E for ; Mon, 4 May 2009 15:26:19 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 04 May 2009 15:26:19 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] proposed charter text with change to add TLS X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:24:55 -0000 Here's the charter text again with changes to simply add TLS in addition to the DTLS work. Looking back over the comments received, there does seem to be (IMHO) enough interest to warrant it I think. There have been a few people state they'd prefer it done within the single document *IF* it could be done clearly. I think it can, so I'm adding it to the text below. I'll leave it up to Juergen and/or Pasi to make the final call as to whether they think there is general agreement to include or exclude TLS from the scope of work. Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * Juergen Schoenwaelder Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transports for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue May 5 00:27:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181633A6B62 for ; Tue, 5 May 2009 00:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9vne0GVT4zc for ; Tue, 5 May 2009 00:27:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AF6FD3A6A67 for ; Tue, 5 May 2009 00:27:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8550DC00EC for ; Tue, 5 May 2009 09:28:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VxPzj5PUvi7e for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F8D8C00D9 for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B20CBADA2B7; Tue, 5 May 2009 09:28:21 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:21 +0200 Resent-Message-ID: <20090505072821.GC18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.122) with Microsoft SMTP Server id 8.1.358.0; Sat, 2 May 2009 15:13:44 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2F7FC0055 for ; Sat, 2 May 2009 15:13:43 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id BC14A5EC for ; Sat, 2 May 2009 15:13:43 +0200 (CEST) Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id 3JXwTcZmQYGx for ; Sat, 2 May 2009 15:13:41 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas1a.jacobs-university.de (Postfix) with ESMTP for ; Sat, 2 May 2009 15:13:40 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:1112:1::20]:55870) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M0F2B-0006V4-CP; Sat, 02 May 2009 15:13:40 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id 256133A6C75; Sat, 2 May 2009 06:10:54 -0700 (PDT) From: Alexey Melnikov To: "iesg@ietf.org" Date: Sat, 2 May 2009 15:10:54 +0200 Thread-Topic: DISCUSS and COMMENT: draft-ietf-isms-tmsm Thread-Index: AcnLJ9G3Lz+hJt4rSvO9FuO1N8ZgGw== Message-ID: <20090502131054.256133A6C75@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: wwwrun@core3.amsl.com x-sa-exim-connect-ip: 2001:1890:1112:1::20 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-isms-tmsm@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:27:17 -0000 RGlzY3VzczoNCkluIGdlbmVyYWwgdGhpcyBpcyBhIHdlbGwgd3JpdHRlbiBkb2N1bWVudCBhbmQg SSBob3BlIHRvIGNsZWFyIHRoaXMgRElTQ1VTUyB2ZXJ5IHNvb24uDQoNCjMuMi4xLiAgQXJjaGl0 ZWN0dXJhbCBNb2R1bGFyaXR5IFJlcXVpcmVtZW50cw0KDQogWy4uLl0NCg0KICAgVG8gZW5jb3Vy YWdlIGEgYmFzaWMgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0eSwgYW55IFRyYW5zcG9ydCBNb2Rl bA0KICAgU0hPVUxEIGRlZmluZSBvbmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBzZWN1cml0eSBt ZWNoYW5pc20sIGJ1dA0KICAgc2hvdWxkIGFsc28gYmUgYWJsZSB0byBzdXBwb3J0IGFkZGl0aW9u YWwgZXhpc3RpbmcgYW5kIG5ldw0KICAgbWVjaGFuaXNtcy4NCg0KV2h5IHRoaXMgU0hPVUxEIGlz IG5vdCBhIE1VU1Q/IEkgYW0gZXhwZWN0aW5nIGEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCB0byBi ZSBhIE1VU1QuDQoNCg0KMy4yLjIuMS4gIHNlY3VyaXR5TmFtZSBhbmQgc2VjdXJpdHlMZXZlbCBN YXBwaW5nDQoNCiBbLi4uXQ0KDQogICBEb2N1bWVudHMgZGVmaW5pbmcgYSBuZXcgdHJhbnNwb3J0 IGRvbWFpbiBNVVNUIGRlZmluZSBhIHByZWZpeCB0aGF0DQogICBNQVkgYmUgcHJlcGVuZGVkIGJ5 IHRoZSBTZWN1cml0eSBNb2RlbCB0byBhbGwgcGFzc2VkIHNlY3VyaXR5TmFtZXMuDQoNCkkgbWln aHQgYmUgc2xpZ2h0bHkgY29uZnVzZWQgaGVyZTogcGFzc2VkIGJ5IHdob20/DQoNCiAgIFRoZSBw cmVmaXggTVVTVCBpbmNsdWRlIGZyb20gb25lIHRvIGZvdXIgQVNDSUkgY2hhcmFjdGVycywgbm90 DQoNCllvdSBwcm9iYWJseSBkaWRuJ3QgbWVhbiBhbnkgVVMtQVNDSUkgY2hhcmFjdGVyIGhlcmUs IGUuZy4gSSBkb24ndCB0aGluaw0KeW91IHdhbnRlZCB0byBhbGxvdyBjb250cm9sIGNoYXJhY3Rl cnMsIHNwYWNlcywgZXRjLg0KV291bGRuJ3QgaXQgYmUgYmV0dGVyIGlmIHRoaXMgaXMgZGVmaW5l ZCBhcyBVUy1BU0NJSSBhbHBoYS1udW1lcmljPw0KDQogICBpbmNsdWRpbmcgYSAiOiIgKEFTQ0lJ IDB4M2EpIGNoYXJhY3Rlci4gIElmIGEgcHJlZml4IGlzIHVzZWQsIGENCiAgIHNlY3VyaXR5TmFt ZSBpcyBjb25zdHJ1Y3RlZCBieSBjb25jYXRlbmF0aW5nIHRoZSBwcmVmaXggYW5kIGEgIjoiDQog ICAoQVNDSUkgMHgzYSkgY2hhcmFjdGVyIGZvbGxvd2VkIGJ5IGEgbm9uLWVtcHR5IGlkZW50aXR5 IGluIGFuDQogICBzbm1wQWRtaW5TdHJpbmcgY29tcGF0aWJsZSBmb3JtYXQuICBUcmFuc3BvcnQg ZG9tYWlucyBhbmQgdGhlaXINCiAgIGNvcnJlc3BvbmRpbmcgcHJlZml4ZXMgYXJlIGNvb3JkaW5h dGVkIHZpYSB0aGUgSUFOQSByZWdpc3RyeSAiU05NUA0KICAgVHJhbnNwb3J0IERvbWFpbnMiLg0K DQozLjMuNC4gIE1lc3NhZ2Ugc2VjdXJpdHkgdmVyc3VzIHNlc3Npb24gc2VjdXJpdHkNCg0KICAg U29tZSBUcmFuc3BvcnQgTW9kZWxzIG1pZ2h0IHN1cHBvcnQgb25seSBzcGVjaWZpYyBhdXRoZW50 aWNhdGlvbiBhbmQNCiAgIGVuY3J5cHRpb24gc2VydmljZXMsIHN1Y2ggYXMgcmVxdWlyaW5nIGFs bCBtZXNzYWdlcyB0byBiZSBjYXJyaWVkDQogICB1c2luZyBib3RoIGF1dGhlbnRpY2F0aW9uIGFu ZCBlbmNyeXB0aW9uLCByZWdhcmRsZXNzIG9mIHRoZSBzZWN1cml0eQ0KICAgbGV2ZWwgcmVxdWVz dGVkIGJ5IGFuIFNOTVAgYXBwbGljYXRpb24uICBBIFRyYW5zcG9ydCBNb2RlbCBNQVkNCiAgIHVw Z3JhZGUgdGhlIHNlY3VyaXR5IGxldmVsIHJlcXVlc3RlZCBieSBhIHRyYW5zcG9ydC1hd2FyZSBz ZWN1cml0eQ0KICAgbW9kZWwsIGkuZS4gbm9BdXRoTm9Qcml2IGFuZCBhdXRoTm9Qcml2IG1pZ2h0 IGJlIHNlbnQgb3ZlciBhbg0KICAgYXV0aGVudGljYXRlZCBhbmQgZW5jcnlwdGVkIHNlc3Npb24u ICBBIFRyYW5zcG9ydCBNb2RlbCBNVVNUIE5PVA0KICAgZG93bmdyYWRlIHRoZSBzZWN1cml0eSBs ZXZlbCByZXF1ZXN0ZWQgYnkgYSB0cmFuc3BvcnQtYXdhcmUgc2VjdXJpdHkNCiAgIG1vZGVsLCBh bmQgU0hPVUxEIGRpc2NhcmQgYW55IG1lc3NhZ2Ugd2hlcmUgdGhpcyB3b3VsZCBvY2N1ci4NCg0K V2hhdCBpcyBhbiBhbHRlcm5hdGl2ZSB0byBkaXNjYXJkaW5nPw0KKEkuZS4gd2h5IHRoZSBsYXN0 IFNIT1VMRCBpcyBub3QgYSBNVVNUKQ0KDQpDb21tZW50Og0KSSB0aGluayB0aGUgZG9jdW1lbnQg aXMgYSBiaXQgbGF4IHdpdGggU0hPVUxEcywgc29tZSBvZiB3aGljaCBtaWdodCBiZSBiZXR0ZXIg c3BlY2lmaWVkIGFzIE1VU1RzIG9yIGp1c3QgcmVtb3ZlZC4gRm9yIGV4YW1wbGU6DQoNCjMuMy4z LiAgU2Vzc2lvbiBNYWludGVuYW5jZSBSZXF1aXJlbWVudHMNCg0KIFsuLi5dDQoNCiAgIElmIGEg VHJhbnNwb3J0IE1vZGVsIGRlZmluZXMgTUlCIG1vZHVsZSBvYmplY3RzIHRvIG1haW50YWluIHNl c3Npb24NCiAgIHN0YXRlIGluZm9ybWF0aW9uLCB0aGVuIHRoZSBUcmFuc3BvcnQgTW9kZWwgTVVT VCBkZWZpbmUgd2hhdCBTSE9VTEQNCiAgIGhhcHBlbiB0byB0aGUgb2JqZWN0cyB3aGVuIGEgcmVs YXRlZCBzZXNzaW9uIGlzIHRvcm4gZG93biwgc2luY2UgdGhpcw0KICAgd2lsbCBpbXBhY3QgaW50 ZXJvcGVyYWJpbGl0eSBvZiB0aGUgTUlCIG1vZHVsZS4NCg0KTWF5YmUganVzdCBzYXkgIk1VU1Qg ZGVmaW5lIHdoYXQgaGVwcGVucyB0byB0aGUgb2JqZWN0cyAuLi4iPw0KDQoNCjMuMy40LiAgTWVz c2FnZSBzZWN1cml0eSB2ZXJzdXMgc2Vzc2lvbiBzZWN1cml0eQ0KDQogWy4uLl0NCg0KICAgSWYg YSBzZWN1cmUgdHJhbnNwb3J0IHNlc3Npb24gaXMgY2xvc2VkIGJldHdlZW4gdGhlIHRpbWUgYSBy ZXF1ZXN0DQogICBtZXNzYWdlIGlzIHJlY2VpdmVkLCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcmVz cG9uc2UgbWVzc2FnZSBpcyBzZW50LA0KICAgdGhlbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBTSE9V TEQgYmUgZGlzY2FyZGVkLCBldmVuIGlmIGEgbmV3IHNlc3Npb24NCiAgIGhhcyBiZWVuIGVzdGFi bGlzaGVkLiAgVGhlIFNOTVB2MyBXRyBkZWNpZGVkIHRoYXQgdGhpcyBzaG91bGQgYmUgYQ0KICAg U0hPVUxEIGFyY2hpdGVjdHVyYWxseSwgYW5kIGl0IGlzIGEgc2VjdXJpdHktbW9kZWwtc3BlY2lm aWMgZGVjaXNpb24NCiAgIHdoZXRoZXIgdG8gUkVRVUlSRSB0aGlzLiAgVGhlIGFyY2hpdGVjdHVy ZSBkb2VzIG5vdCBtYW5kYXRlIHRoaXMNCiAgIHJlcXVpcmVtZW50IHRvIGFsbG93IGZvciBmdXR1 cmUgc2VjdXJpdHkgbW9kZWxzIHdoZXJlIHRoaXMgbWlnaHQgbWFrZQ0KICAgc2Vuc2UsIGJ1dCBu b3QgcmVxdWlyaW5nIHRoaXMgY291bGQgbGVhZCB0byBhZGRlZCBjb21wbGV4aXR5IGFuZA0KICAg c2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVzLCBzbyBtb3N0IHNlY3VyaXR5IG1vZGVscyBTSE9VTEQg cmVxdWlyZQ0KICAgdGhpcy4NCg0KRW5jbG9zZSBzb21lIFNIT1VMRHMgaW4gIiIgdG8gZW1waGFz aXplIHRoYXQgdGhleSBhcmUgbm90IGRlY2xhcmluZyByZXF1aXJlbWVudHM/DQoNCg== From j.schoenwaelder@jacobs-university.de Tue May 5 00:27:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565F83A67F5 for ; Tue, 5 May 2009 00:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEGr-mO-tRPA for ; Tue, 5 May 2009 00:27:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EE8053A6AE2 for ; Tue, 5 May 2009 00:27:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12F4CC00D9 for ; Tue, 5 May 2009 09:28:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hV5yY6Q-jviQ for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8099FC00E7 for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 07896ADA2DB; Tue, 5 May 2009 09:28:21 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:21 +0200 Resent-Message-ID: <20090505072821.GD18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.122) with Microsoft SMTP Server id 8.1.358.0; Sat, 2 May 2009 15:16:16 +0200 Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD3E9C0055 for ; Sat, 2 May 2009 15:16:15 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0O-a6NKZ4v3K for ; Sat, 2 May 2009 15:16:14 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id BE924C0002 for ; Sat, 2 May 2009 15:16:14 +0200 (CEST) Received: from rufus.isode.com ([62.3.217.251]:50962) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M0F4a-0006zH-JD; Sat, 02 May 2009 15:16:09 +0200 Received: from [92.40.78.203] (92.40.78.203.sub.mbb.three.co.uk [92.40.78.203]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 2 May 2009 14:16:06 +0100 From: Alexey Melnikov To: "draft-ietf-isms-tmsm@tools.ietf.org" Date: Sat, 2 May 2009 15:15:37 +0200 Thread-Topic: DISCUSS and COMMENT: draft-ietf-isms-tmsm Thread-Index: AcnLKCxeAbVulsi8Ttyaq6HSAMeyLg== Message-ID: <49FC4779.6030906@isode.com> References: <20090502131054.256133A6C75@core3.amsl.com> In-Reply-To: <20090502131054.256133A6C75@core3.amsl.com> Accept-Language: en-us, en Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-us, en user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: alexey.melnikov@isode.com x-sa-exim-connect-ip: 62.3.217.251 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , "isms-chairs@tools.ietf.org" Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:27:18 -0000 Alexey Melnikov wrote: >3.2.2.1. securityName and securityLevel Mapping > > [...] > > Documents defining a new transport domain MUST define a prefix that > MAY be prepended by the Security Model to all passed securityNames. > >I might be slightly confused here: passed by whom? > > The prefix MUST include from one to four ASCII characters, not > >You probably didn't mean any US-ASCII character here, e.g. I don't think >you wanted to allow control characters, spaces, etc. >Wouldn't it be better if this is defined as US-ASCII alpha-numeric? > > including a ":" (ASCII 0x3a) character. If a prefix is used, a > securityName is constructed by concatenating the prefix and a ":" > (ASCII 0x3a) character followed by a non-empty identity in an > snmpAdminString compatible format. Transport domains and their > corresponding prefixes are coordinated via the IANA registry "SNMP > Transport Domains". > =20 > Also, I think the document is a bit unclear on how these prefixes are=20 used. Can you provide an example? Thank you, Alexey --=20 IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From j.schoenwaelder@jacobs-university.de Tue May 5 00:28:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41C63A6B9B for ; Tue, 5 May 2009 00:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISMmKCnfUAsG for ; Tue, 5 May 2009 00:28:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C03993A6A67 for ; Tue, 5 May 2009 00:28:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADA26C00E5 for ; Tue, 5 May 2009 09:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OELb4Xo9Oe1N for ; Tue, 5 May 2009 09:29:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCDC6C00D9 for ; Tue, 5 May 2009 09:29:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E22DADA325; Tue, 5 May 2009 09:28:22 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:22 +0200 Resent-Message-ID: <20090505072822.GG18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Sun, 3 May 2009 14:45:37 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BC73C0207 for ; Sun, 3 May 2009 14:45:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id C3582608 for ; Sun, 3 May 2009 14:45:36 +0200 (CEST) Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id 6Wxo9zOB-qxm for ; Sun, 3 May 2009 14:45:36 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas1b.jacobs-university.de (Postfix) with ESMTP for ; Sun, 3 May 2009 14:45:35 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:1112:1::20]:57355) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M0b4V-0000Wk-UO; Sun, 03 May 2009 14:45:32 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id 54EBD3A6BE3; Sun, 3 May 2009 05:43:59 -0700 (PDT) From: Alexey Melnikov To: "iesg@ietf.org" Date: Sun, 3 May 2009 14:44:00 +0200 Thread-Topic: COMMENT: draft-ietf-isms-radius-usage Thread-Index: AcnL7Q9xalkCzySnQIukKJJMoSkUbg== Message-ID: <20090503124400.54EBD3A6BE3@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: wwwrun@core3.amsl.com x-sa-exim-connect-ip: 2001:1890:1112:1::20 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-radius-usage@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-isms-radius-usage@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] COMMENT: draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:28:17 -0000 Q29tbWVudDoNCjIuMy4gIFNOTVAgU2VydmljZSBBdXRob3JpemF0aW9uDQoNCiBbLi4uXQ0KDQog ICBUaGVyZSBhcmUgbm8gY29tYmluYXRpb25zIG9mIFJBRElVUyBhdHRyaWJ1dGVzIHRoYXQgZGVu b3RlIHRoZQ0KICAgZXF1aXZhbGVudCBvZiBTTk1QIG5vQXV0aE5vUHJpdiBhY2Nlc3MsIGFzIFJB RElVUyBhbHdheXMgaW52b2x2ZXMgdGhlDQogICBhdXRoZW50aWNhdGlvbiBvZiBhIHVzZXIgKGku ZS4gYSBwcmluY2lwYWwpIGFzIGEgcHJlcmVxdWlzaXRlIGZvcg0KICAgYXV0aG9yaXphdGlvbi4g IFJBRElVUyBjYW4gYmUgdXNlZCB0byB0byBwcm92aWRlIGFuICJBdXRob3JpemUtT25seSINCg0K RXh0cmEgInRvIi4NCg0KICAgc2VydmljZSwgYnV0IG9ubHkgd2hlbiB0aGUgcmVxdWVzdCBjb250 YWlucyBhICJjb29raWUiIGZyb20gYQ0KICAgcHJldmlvdXMgc3VjY2Vzc2Z1bCBhdXRoZW50aWNh dGlvbiB3aXRoIHRoZSBzYW1lIFJBRElVUyBzZXJ2ZXIgKGkuZS4NCiAgIHRoZSBSQURJVVMgU3Rh dGUgQXR0cmlidXRlKS4NCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KIFsuLi5d DQoNCiAgIFRoZSBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgKDgwKSBhdHRyaWJ1dGUgW1JGQzM1Nzld IFNIT1VMRCBiZSB1c2VkDQogICB3aXRoIFJBRElVUyBtZXNzYWdlcyB0aGF0IGFyZSBkZXNjcmli ZWQgaW4gdGhpcyBtZW1vLg0KDQpTb21lIGV4cGxhbmF0aW9uIG9mIHdoeSB3b3VsZCBiZSBoZWxw ZnVsIGhlcmUuDQoNCg== From j.schoenwaelder@jacobs-university.de Tue May 5 00:28:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E18B3A6C12 for ; Tue, 5 May 2009 00:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0JcMkIwOnsg for ; Tue, 5 May 2009 00:28:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECD373A6AE2 for ; Tue, 5 May 2009 00:28:35 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03685C00E6 for ; Tue, 5 May 2009 09:28:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RZ27hqTSNsmJ for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 866CFC00EB for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0A9F7ADA2DC; Tue, 5 May 2009 09:28:21 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:21 +0200 Resent-Message-ID: <20090505072821.GE18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.122) with Microsoft SMTP Server id 8.1.358.0; Sat, 2 May 2009 22:33:48 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A9BCC002A for ; Sat, 2 May 2009 22:33:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 70E155EC for ; Sat, 2 May 2009 22:33:48 +0200 (CEST) Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id fF7x8FJalUZE for ; Sat, 2 May 2009 22:33:46 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by atlas1a.jacobs-university.de (Postfix) with ESMTP for ; Sat, 2 May 2009 22:33:46 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463503A6C13; Sat, 2 May 2009 13:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB753A6BAD; Sat, 2 May 2009 13:32:18 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bap-gkfA8pKq; Sat, 2 May 2009 13:32:17 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 86B603A695D; Sat, 2 May 2009 13:32:16 -0700 (PDT) Received: by fxm2 with SMTP id 2so2881642fxm.37 for ; Sat, 02 May 2009 13:33:40 -0700 (PDT) Received: by 10.223.108.211 with SMTP id g19mr1508050fap.39.1241296418792; Sat, 02 May 2009 13:33:38 -0700 (PDT) From: Barry Leiba To: "secdir@ietf.org" , "iesg@ietf.org" Sender: "secdir-bounces@ietf.org" Date: Sat, 2 May 2009 22:33:38 +0200 Thread-Topic: [secdir] secdir review of draft-ietf-isms-transport-security-model-12 Thread-Index: AcnLZUwu2W1Vd7VvT4OWm2HjF/zAmA== Message-ID: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-beenthere: secdir@ietf.org x-original-to: secdir@core3.amsl.com x-mailman-version: 2.1.9 Errors-To: secdir-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com delivered-to: secdir@core3.amsl.com x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fy2uYmSw5rN/Pkf8xt7e0mSigt4cAQWXutHm2qCKnpg=; b=JtsOIL/Vu3SllFQvuERsB4hMdgtE2xwH3vSN2+JDDIQ3QgZkX/5JBkBk5VqcugSMZ/ ye3gp/fLPg1TlQFB9c0sV0R1sXHDrTYRb2RkvXPQWnxR4kLpmLkgTQHeA6qhOkSSJAta zEpNLZ7aDQ2rC+Kh5r3lG1yjBkjUA9tIX/AHc= domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=WfVkeWoNpOxGGx/5RDCnLeYIkgt3GHhDqtMAf9iaIcd/4t1TLq5RjYjy8XthXuaTW2 siP9Clb+KFNDrjMFaWMU+zpzTYqwigei5swnFVwbHOT0CSNlcw4O52RudN09feRZ5IIO vQBpqk0yHp2FwsQoQoRj7V6T+I3P/neui+idI= x-google-sender-auth: 583d759322804ec8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-isms-transport-security-model@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:28:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a type of Security Model, as defined in RFC 3411, designed to go with a Transport Model, as defined in draft-ietf-isms-tmsm. I have no expertise in MIBs, and must presume that people who do have reviewed this. For that matter, I don't have expertise in SNMP, so please take these comments with that in mind. I've briefly gone through the associated documents, and I think I understand how the pieces fit into the architecture, but my understanding isn't thorough. My comments: Section 1.5: bullets 1 & 2 use normative RFC 2119 language. Should bullets 4 & 5 do so also? E.g., "A Security Model SHOULD NOT require changes to the SNMP architecture." Section 2.1.1: I'm confused by this. RFC 3411 section 3.1.1.4.1 says that a Security Model specifies "the security protocols used to provide security services such as authentication and privacy." Yet this section says that the Transport Security Model does NOT provide these things. And if it doesn't provide them, how can the admonition to use it "with a Transport Model that provides appropriate security" be a SHOULD, and not a MUST (noting that "appropriate" security could include no authentication, if that's appropriate to the system in question)? Some component has to take responsibility for the security, even if it's to determine that no authentication or no privacy controls are needed. The same goes for the discussion of this in section 8, Security Considerations. "The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports." It looks like this needs to be stronger than plain-English "should", or RFC 2119 "SHOULD", no? I think this is a key point to make clear, so it's well understood where the responsibility lies for the assurance of "appropriate" security in the Transport Model, and what happens when a system uses multiple Security Models, one of which is this one. Again, my confusion here might simply be due to my understanding of the architecture being only superficial. Barry --=20 Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From j.schoenwaelder@jacobs-university.de Tue May 5 00:30:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E473A6C12 for ; Tue, 5 May 2009 00:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlE1GdWeEJEo for ; Tue, 5 May 2009 00:30:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 222403A67F5 for ; Tue, 5 May 2009 00:29:56 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEA3BC00ED for ; Tue, 5 May 2009 09:28:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id X4W+9D3hxTa1 for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79A4DC00E6 for ; Tue, 5 May 2009 09:28:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 05B4CADA2D6; Tue, 5 May 2009 09:28:22 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:21 +0200 Resent-Message-ID: <20090505072821.GF18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Sun, 3 May 2009 13:34:48 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA2EAC01FB for ; Sun, 3 May 2009 13:34:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id B450A608 for ; Sun, 3 May 2009 13:34:48 +0200 (CEST) Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id BS-yuBMONSzk for ; Sun, 3 May 2009 13:34:46 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas1a.jacobs-university.de (Postfix) with ESMTP for ; Sun, 3 May 2009 13:34:46 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:1112:1::20]:48378) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M0Zxs-000880-Vh; Sun, 03 May 2009 13:34:37 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id C3E693A6A35; Sun, 3 May 2009 04:33:02 -0700 (PDT) From: Alexey Melnikov To: "iesg@ietf.org" Date: Sun, 3 May 2009 13:33:02 +0200 Thread-Topic: DISCUSS and COMMENT: draft-ietf-isms-secshell Thread-Index: AcnL4yqGQTUJx6sWRYueePaBZr+e/w== Message-ID: <20090503113302.C3E693A6A35@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: wwwrun@core3.amsl.com x-sa-exim-connect-ip: 2001:1890:1112:1::20 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-secshell@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-isms-secshell@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:30:02 -0000 RGlzY3VzczoNCkkgaGF2ZSBhIGNvdXBsZSBtaW5vciByZWxhdGVkIHBvaW50cyBoZXJlOg0KDQo1 LjMuICBFc3RhYmxpc2hpbmcgYSBTZXNzaW9uDQoNCiBbLi4uXQ0KDQogICAzLiAgVGhlIGNsaWVu dCB3aWxsIHRoZW4gaW52b2tlIGFuIFNTSCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIHRvDQogICAg ICAgYXV0aGVudGljYXRlIHRoZSBwcmluY2lwYWwsIHN1Y2ggYXMgdGhhdCBkZXNjcmliZWQgaW4g dGhlIFNTSA0KICAgICAgIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIFtSRkM0MjUyXS4NCg0KICAg ICAgIDEuICBJZiB0aGUgdG1UcmFuc3BvcnRBZGRyZXNzIGZpZWxkIGNvbnRhaW5zIGEgdXNlci1u YW1lIGZvbGxvd2VkDQogICAgICAgICAgIGJ5IGFuICdAJyBjaGFyYWN0ZXIgKEFTQ0lJIDB4NDAp LCB0aGF0IHVzZXItbmFtZSBzdHJpbmcgdGhhdA0KICAgICAgICAgICBzaG91bGQgYmUgcHJlc2Vu dGVkIHRvIHRoZSBzc2ggc2VydmVyIGFzIHRoZSAidXNlciBuYW1lIiBmb3INCiAgICAgICAgICAg dXNlciBhdXRoZW50aWNhdGlvbiBwdXJwb3Nlcy4gIElmIHRoZXJlIGlzIG5vIHVzZXItbmFtZSBp bg0KICAgICAgICAgICB0aGUgdG1UcmFuc3BvcnRBZGRyZXNzIHRoZW4gdGhlIHRtU2VjdXJpdHlO YW1lIHNob3VsZCBiZSB1c2VkDQogICAgICAgICAgIGFzIHRoZSB1c2VyLW5hbWUuDQoNCkkgdGhp bmsgdGhpcyB0ZXh0IG5lZWRzIHRvIHNheSB3aGljaCBjaGFyYWN0ZXIgc2V0IGlzIHVzZWQgZm9y IHJlcHJlc2VudGluZyB1c2VyLW5hbWUsIGFuZCBpZGVhbGx5IGl0IG5lZWRzIHRvIGRlc2NyaWJl IG9yIHBvaW50DQp0byBzeW50YXggb2YgYWxsb3dlZCB1c2VybmFtZXMuDQoNCg0KNy4gIE1JQiBN b2R1bGUgRGVmaW5pdGlvbg0KDQogWy4uLl0NCg0KU25tcFNTSEFkZHJlc3MgOjo9IFRFWFRVQUwt Q09OVkVOVElPTg0KICAgIERJU1BMQVktSElOVCAiMWEiDQogICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICJSZXByZXNlbnRzIGVpdGhlciBhIGhvc3RuYW1l IG9yIElQIGFkZHJlc3MsIGFsb25nIHdpdGggYSBwb3J0DQogICAgICAgICBudW1iZXIgYW5kIGFu IG9wdGlvbmFsIHVzZXJuYW1lLg0KDQogICAgICAgICBUaGUgYmVnaW5uaW5nIG9mIHRoZSBhZGRy ZXNzIHNwZWNpZmljYXRpb24gbWF5IGNvbnRhaW4gYQ0KICAgICAgICAgdXNlcm5hbWUgZm9sbG93 ZWQgYnkgYW4gJ0AnIChBU0NJSSBjaGFyYWN0ZXIgMHg0MCkuIFRoaXMNCiAgICAgICAgIHBvcnRp b24gb2YgdGhlIGFkZHJlc3Mgd2lsbCBpbmRpY2F0ZSB0aGUgdXNlciBuYW1lIHRoYXQgc2hvdWxk DQogICAgICAgICBiZSB1c2VkIHdoZW4gYXV0aGVudGljYXRpbmcgdG8gYW4gU1NIIHNlcnZlci4g SWYgbWlzc2luZywgdGhlDQogICAgICAgICBTTk1QIHNlY3VyaXR5TmFtZSBzaG91bGQgYmUgdXNl ZC4gQWZ0ZXIgdGhlIG9wdGlvbmFsIHVzZXIgbmFtZQ0KICAgICAgICAgZmllbGQgYW5kICdAJyBj aGFyYWN0ZXIgY29tZXMgdGhlIGhvc3RuYW1lIG9yIElQIGFkZHJlc3MuDQoNClNhbWUgY29tbWVu dCBhcyBhYm92ZTogY2FuIHlvdSBhZGQgYSByZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IGRlZmlu aW5nIHN5bnRheCBvZiB0aGUgdXNlcm5hbWU/DQoNCiAgICAgICAgIFRoZSBob3N0bmFtZSBtdXN0 IGJlIGVuY29kZWQgaW4gQVNDSUksIGFzIHNwZWNpZmllZCBpbg0KICAgICAgICAgUkZDMzQ5MCAo SW50ZXJuYXRpb25hbGl6aW5nIERvbWFpbiBOYW1lcyBpbiBBcHBsaWNhdGlvbnMpDQoNClNhbWUg Y29tbWVudCBhYm91dCBzeW50YXg6IEkgdGhpbmsgYSByZWZlcmVuY2UgdG8gdGhlIDxob3N0PiBB Qk5GIHByb2R1Y3Rpb24gZnJvbSBSRkMgMzk4NiB3b3VsZCBiZSBhcHByb3ByaWF0ZSBoZXJlLg0K DQpOaXQ6IEkgYWxzbyB0aGluayB0aGUgdGV4dCBhcyB3cml0dGVuIGlzIG5vdCBxdWl0ZSByaWdo dC4NCkludGVybmF0aW9uYWxpemVkIGhvc3RuYW1lcyBtdXN0IGJlIGVuY29kZWQgdXNpbmcgdGhl IGFsZ29yaXRobQ0Kc3BlY2lmaWVkIGluIFJGQyAzNDkwLCBidXQgZm9yIGFsbCBBU0NJSSBob3N0 bmFtZXMgdGhlcmUgaXMgbm8gbmVlZA0KdG8gc2VuZCBwZW9wbGUgdG8gcmV2aWV3IFJGQyAzNDkw LiBTbyBJIHdvdWxkIHN1Z2dlc3Q6DQoNCiAgICBUaGUgaG9zdG5hbWUgaXMgYWx3YXlzIGluIEFT Q0lJLiBJbnRlcm5hdGlvbmFsaXplZCBEb21haW4gTmFtZXMNCiAgICBNVVNUIGJlIGVuY29kZWQg aW4gQVNDSUksIGFzIHNwZWNpZmllZCBpbg0KICAgIFJGQzM0OTAgKEludGVybmF0aW9uYWxpemlu ZyBEb21haW4gTmFtZXMgaW4gQXBwbGljYXRpb25zKS4NCg0KICAgICAgICAgZm9sbG93ZWQgYnkg YSBjb2xvbiAnOicgKEFTQ0lJIGNoYXJhY3RlciAweDNBKSBhbmQgYQ0KICAgICAgICAgZGVjaW1h bCBwb3J0IG51bWJlciBpbiBBU0NJSS4gVGhlIG5hbWUgU0hPVUxEIGJlIGZ1bGx5DQogICAgICAg ICBxdWFsaWZpZWQgd2hlbmV2ZXIgcG9zc2libGUuDQoNCkNvbW1lbnQ6DQoxLjIuICBDb252ZW50 aW9ucw0KDQogWy4uLl0NCg0KICAgU2VjdGlvbnMgcmVxdWlyaW5nIGZ1cnRoZXIgZWRpdGluZyBh cmUgaWRlbnRpZmllZCBieSBbdG9kb10gbWFya2Vycw0KICAgaW4gdGhlIHRleHQuICBQb2ludHMg cmVxdWlyaW5nIGZ1cnRoZXIgV0cgcmVzZWFyY2ggYW5kIGRpc2N1c3Npb24gYXJlDQogICBpZGVu dGlmaWVkIGJ5IFtkaXNjdXNzXSBtYXJrZXJzIGluIHRoZSB0ZXh0Lg0KDQpQbGVhc2UgZGVsZXRl IHRoaXMgcGFyYWdyYXBoLg0KSSBjYW4ndCBmaW5kIGFueSBbdG9kb10gb3IgW2Rpc2N1c3NdIG1h cmtlcnMgaW4gdGhlIGRvY3VtZW50Lg0KDQogICBOb3RlIHRvIFJGQyBFZGl0b3IgLSBpZiB0aGUg cHJldmlvdXMgcGFyYWdyYXBoIGFuZCB0aGlzIG5vdGUgaGF2ZSBub3QNCiAgIGJlZW4gcmVtb3Zl ZCwgcGxlYXNlIHNlbmQgdGhlIGRvY3VtZW50IGJhY2sgdG8gdGhlIGVkaXRvciB0byByZW1vdmUN CiAgIHRoaXMuDQoNCjotKQ0KDQoNCjIuICBUaGUgU2VjdXJlIFNoZWxsIFByb3RvY29sDQoNCiBb Li4uXQ0KDQogICBUaGUgY2xpZW50IHNlbmRzIGEgc2VydmljZSByZXF1ZXN0IG9uY2UgYSBzZWN1 cmUgdHJhbnNwb3J0IGxheWVyDQogICBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLiAg QSBzZWNvbmQgc2VydmljZSByZXF1ZXN0IGlzIHNlbnQNCiAgIGFmdGVyIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBpcyBjb21wbGV0ZS4NCg0KRm9yIG15IGVkdWNhdGlvbiwgY2FuIHlvdSBwb2ludCBv dXQgd2hlcmUgdGhpcyBpcyBkZXNjcmliZWQgaW4gbW9yZSBkZXRhaWxzPw0KDQogICBUaGlzIGFs bG93cyBuZXcgcHJvdG9jb2xzDQogICB0byBiZSBkZWZpbmVkIGFuZCBjb2V4aXN0IHdpdGggdGhl IHByb3RvY29scyBsaXN0ZWQgYWJvdmUuDQoNCg0KMy4xLjIuICBNZXNzYWdlIEF1dGhlbnRpY2F0 aW9uDQoNCiBbLi4uXQ0KDQogICBUaGUgU1NIIFRyYW5zcG9ydCBNb2RlbCBkZXRlcm1pbmVzIGZy b20gU1NIIHRoZSBpZGVudGl0eSBvZiB0aGUNCiAgIGF1dGhlbnRpY2F0ZWQgcHJpbmNpcGFsLCBh bmQgdGhlIHR5cGUgYW5kIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIGFuDQogICBpbmNvbWluZyBt ZXNzYWdlLCBhbmQgcHJvdmlkZXMgdGhpcyBpbmZvcm1hdGlvbiB0byBTU0ggZm9yIGFuDQogICBv dXRnb2luZyBtZXNzYWdlLiAgVGhlIHRyYW5zcG9ydCBsYXllciBhbGdvcml0aG1zIHVzZWQgdG8g cHJvdmlkZQ0KDQoiU1NIIHRyYW5zcG9ydCBsYXllciBhbGdvcml0aG1zIC4uLiI/DQoNCiAgIGF1 dGhlbnRpY2F0aW9uLCBkYXRhIGludGVncml0eSBhbmQgZW5jcnlwdGlvbiBTSE9VTEQgTk9UIGJl IGV4cG9zZWQNCiAgIHRvIHRoZSBTU0ggVHJhbnNwb3J0IE1vZGVsIGxheWVyLiAgVGhlIFNOTVB2 MyBXRyBkZWxpYmVyYXRlbHkgYXZvaWRlZA0KICAgdGhpcyBhbmQgc2V0dGxlZCBmb3IgYW4gYXNz ZXJ0aW9uIGJ5IHRoZSBzZWN1cml0eSBtb2RlbCB0aGF0IHRoZQ0KICAgcmVxdWlyZW1lbnRzIG9m IHNlY3VyaXR5TGV2ZWwgd2VyZSBtZXQgVGhlIFNTSCBUcmFuc3BvcnQgTW9kZWwgaGFzIG5vDQoN CkkgdGhpbmsgdGhlcmUgaXMgYSBtaXNzaW5nIGRvdCBiZWZvcmUgIlRoZSIuDQoNCiAgIG1lY2hh bmlzbXMgYnkgd2hpY2ggaXQgY2FuIHRlc3Qgd2hldGhlciBhbiB1bmRlcmx5aW5nIFNTSCBjb25u ZWN0aW9uDQogICBwcm92aWRlcyBhdXRoIG9yIHByaXYsIHNvIHRoZSBTU0ggVHJhbnNwb3J0IE1v ZGVsIHRydXN0cyB0aGF0IHRoZQ0KICAgdW5kZXJseWluZyBTU0ggY29ubmVjdGlvbiBoYXMgYmVl biBwcm9wZXJseSBjb25maWd1cmVkIHRvIHN1cHBvcnQNCiAgIGF1dGhQcml2IHNlY3VyaXR5IGNo YXJhY3RlcmlzdGljcy4NCg0KDQo1LiAgRWxlbWVudHMgb2YgUHJvY2VkdXJlDQoNCiBbLi4uXQ0K DQogICBUbyBzaW1wbGlmeSB0aGUgZWxlbWVudHMgb2YgcHJvY2VkdXJlLCB0aGUgcmVsZWFzZSBv ZiBzdGF0ZQ0KICAgaW5mb3JtYXRpb24gaXMgbm90IGFsd2F5cyBleHBsaWNpdGx5IHNwZWNpZmll ZC4gIEFzIGEgZ2VuZXJhbCBydWxlLA0KICAgaWYgc3RhdGUgaW5mb3JtYXRpb24gaXMgYXZhaWxh YmxlIHdoZW4gYSBtZXNzYWdlIGdldHMgZGlzY2FyZGVkLCB0aGUNCiAgIG1lc3NhZ2Utc3RhdGUg aW5mb3JtYXRpb24gc2hvdWxkIGFsc28gYmUgcmVsZWFzZWQsIGFuZCBpZiBzdGF0ZQ0KICAgaW5m b3JtYXRpb24gaXMgYXZhaWxhYmxlIHdoZW4gYSBzZXNzaW9uIGlzIGNsb3NlZCwgdGhlIHNlc3Np b24gc3RhdGUNCiAgIGluZm9ybWF0aW9uIHNob3VsZCBhbHNvIGJlIHJlbGVhc2VkLg0KDQpJIGFt IHdvbmRlcmluZyB3aHkgMiAic2hvdWxkInMgYXJlIG5vdCBTSE9VTERzIG9yIGV2ZW4gTVVTVHMu DQoNCg0KNS4xLiAgUHJvY2VkdXJlcyBmb3IgYW4gSW5jb21pbmcgTWVzc2FnZQ0KDQogWy4uLl0N Cg0KICAgNC4gIENyZWF0ZSBhIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUgZm9yIHN1YnNlcXVlbnQg cmVmZXJlbmNlIHRvIHRoZQ0KICAgICAgIGluZm9ybWF0aW9uLg0KDQogICAgICAgICAgdG1UcmFu c3BvcnREb21haW4gPSBzbm1wU1NIRG9tYWluDQoNCiAgICAgICAgICB0bVRyYW5zcG9ydEFkZHJl c3MgPSB0aGUgZGVyaXZlZCB0bVRyYW5zcG9ydEFkZHJlc3MgZnJvbSBzdGVwDQogICAgICAgICAg My4NCg0KSSB0aGluayB0aGlzIGlzIHN0ZXAgMi4NCg0KICAgICAgICAgIHRtU2VjdXJpdHlOYW1l ID0gVGhlIGRlcml2ZWQgdG1TZWN1cml0eU5hbWUgZnJvbSBzdGVwIDIuDQoNCkFuZCB0aGlzIGlz IHN0ZXAgMy4NCg0KDQo1LjMuICBFc3RhYmxpc2hpbmcgYSBTZXNzaW9uDQoNCiBbLi4uXQ0KDQog ICAzLiAgVGhlIGNsaWVudCB3aWxsIHRoZW4gaW52b2tlIGFuIFNTSCBhdXRoZW50aWNhdGlvbiBz ZXJ2aWNlIHRvDQogICAgICAgYXV0aGVudGljYXRlIHRoZSBwcmluY2lwYWwsIHN1Y2ggYXMgdGhh dCBkZXNjcmliZWQgaW4gdGhlIFNTSA0KICAgICAgIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIFtS RkM0MjUyXS4NCg0KICAgICAgIDEuICBJZiB0aGUgdG1UcmFuc3BvcnRBZGRyZXNzIGZpZWxkIGNv bnRhaW5zIGEgdXNlci1uYW1lIGZvbGxvd2VkDQogICAgICAgICAgIGJ5IGFuICdAJyBjaGFyYWN0 ZXIgKEFTQ0lJIDB4NDApLCB0aGF0IHVzZXItbmFtZSBzdHJpbmcgdGhhdA0KDQpSZW1vdmUgdGhl IGxhc3QgInRoYXQiPw0KDQogICAgICAgICAgIHNob3VsZCBiZSBwcmVzZW50ZWQgdG8gdGhlIHNz aCBzZXJ2ZXIgYXMgdGhlICJ1c2VyIG5hbWUiIGZvcg0KICAgICAgICAgICB1c2VyIGF1dGhlbnRp Y2F0aW9uIHB1cnBvc2VzLiAgSWYgdGhlcmUgaXMgbm8gdXNlci1uYW1lIGluDQogICAgICAgICAg IHRoZSB0bVRyYW5zcG9ydEFkZHJlc3MgdGhlbiB0aGUgdG1TZWN1cml0eU5hbWUgc2hvdWxkIGJl IHVzZWQNCiAgICAgICAgICAgYXMgdGhlIHVzZXItbmFtZS4NCg0KDQoNCg0KNy4gIE1JQiBNb2R1 bGUgRGVmaW5pdGlvbg0KDQogWy4uLl0NCg0Kc25tcFNTSERvbWFpbiBPQkpFQ1QtSURFTlRJVFkN CiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgIlRoZSBT Tk1QIG92ZXIgU1NIIHRyYW5zcG9ydCBkb21haW4uIFRoZSBjb3JyZXNwb25kaW5nDQogICAgICAg ICB0cmFuc3BvcnQgYWRkcmVzcyBpcyBvZiB0eXBlIFNubXBTU0hBZGRyZXNzLg0KDQogICAgICAg ICBXaGVuIGFuIFNOTVAgZW50aXR5IHVzZXMgdGhlIHNubXBTU0hEb21haW4gdHJhbnNwb3J0DQog ICAgICAgICBtb2RlbCwgaXQgbXVzdCBiZSBjYXBhYmxlIG9mIGFjY2VwdGluZyBtZXNzYWdlcyB1 cCB0bw0KICAgICAgICAgYW5kIGluY2x1ZGluZyA4MTkyIG9jdGV0cyBpbiBzaXplLiBJbXBsZW1l bnRhdGlvbiBvZg0KICAgICAgICAgbGFyZ2VyIHZhbHVlcyBpcyBlbmNvdXJhZ2VkIHdoZW5ldmVy IHBvc3NpYmxlLg0KDQogICAgICAgICBUaGUgc2VjdXJpdHlOYW1lIHByZWZpeCB0byBiZSBhc3Nv Y2lhdGVkIHdpdGggdGhlDQogICAgICAgICBzbm1wU1NIRG9tYWluIGlzICdzc2gnLiBUaGlzIHBy ZWZpeCBtYXkgYmUgdXNlZCBieSBzZWN1cml0eQ0KICAgICAgICAgbW9kZWxzIG9yIG90aGVyIGNv bXBvbmVudHMgdG8gaWRlbnRpZnkgd2hhdCBzZWN1cmUgdHJhbnNwb3J0DQoNCnMvd2hhdC90aGF0 ID8NCg0KICAgICAgICAgaW5mcmFzdHJ1Y3R1cmUgYXV0aGVudGljYXRlZCBhIHNlY3VyaXR5TmFt ZS4iDQoNCg0KOC4gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBTU0ggVHJh bnNwb3J0IE1vZGVsIHdpbGwgbGlrZWx5IG5vdCB3b3JrIGluIGNvbmRpdGlvbnMgd2hlcmUNCiAg IGFjY2VzcyB0byB0aGUgQ0xJIGhhcyBzdG9wcGVkIHdvcmtpbmcuDQoNCkNhbiB5b3UgZWxhYm9y YXRlIG9uIHRoaXMgYSBiaXQgbW9yZT8NCg0KICAgSW4gc2l0dWF0aW9ucyB3aGVyZSBTTk1QDQog ICBhY2Nlc3MgaGFzIHRvIHdvcmsgd2hlbiB0aGUgQ0xJIGhhcyBzdG9wcGVkIHdvcmtpbmcsIGEg VURQIHRyYW5zcG9ydA0KICAgbW9kZWwgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW5zdGVhZCBvZiB0 aGUgU1NIIFRyYW5zcG9ydCBNb2RlbC4NCg0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHJlZmVyZW5j ZSB0byBbUkZDMjg2NV0gKFJBRElVUykgaXMgbm9ybWF0aXZlLg0KDQo= From j.schoenwaelder@jacobs-university.de Tue May 5 00:30:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096873A6A67 for ; Tue, 5 May 2009 00:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gwPPk1gHUDQ for ; Tue, 5 May 2009 00:30:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECBE33A67F5 for ; Tue, 5 May 2009 00:30:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8269BC00EB for ; Tue, 5 May 2009 09:29:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5Znc4a-hrb4d for ; Tue, 5 May 2009 09:29:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4D84C00D9 for ; Tue, 5 May 2009 09:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6493AADA326; Tue, 5 May 2009 09:28:22 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:22 +0200 Resent-Message-ID: <20090505072822.GH18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Mon, 4 May 2009 15:45:29 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 747D7C0076 for ; Mon, 4 May 2009 15:45:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 6EFA15EC for ; Mon, 4 May 2009 15:45:29 +0200 (CEST) Received: from atlas2b.jacobs-university.de ([212.201.44.15]) by localhost (demetrius4.jacobs-university.de [212.201.44.49]) (amavisd-new, port 10030) with ESMTP id rzvCEmE4pj8F for ; Mon, 4 May 2009 15:45:28 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas2b.jacobs-university.de (Postfix) with ESMTP for ; Mon, 4 May 2009 15:45:28 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:1112:1::20]:52904) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M0yTx-0000s2-Va; Mon, 04 May 2009 15:45:22 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id 89A3F3A6FEB; Mon, 4 May 2009 06:43:49 -0700 (PDT) From: Adrian Farrel To: "iesg@ietf.org" Date: Mon, 4 May 2009 15:43:49 +0200 Thread-Topic: DISCUSS and COMMENT: draft-ietf-isms-transport-security-model Thread-Index: AcnMvpZQ2PiCeSSrSguCe1wRLfqb4w== Message-ID: <20090504134349.89A3F3A6FEB@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: wwwrun@core3.amsl.com x-sa-exim-connect-ip: 2001:1890:1112:1::20 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-transport-security-model@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-isms-transport-security-model@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:30:17 -0000 RGlzY3VzczoNCkkgYW0gbm90IGEgTUlCIGV4cGVydCwgYnV0IHdoZW4gSSBzZWUgY291bnRlcnMg SSB3b25kZXIgYWJvdXQgd3JhcHMNCmFuZCBkaXNjb250aW51aXRpZXMuIFRoZXNlIHNlZW0gbm90 IHRvIGJlIGNvdmVyZWQgaW4gdGhpcyBkb2N1bWVudA0KYW5kIEkgd291bGQgbGlrZSB0byBoZWFy IGZyb20gYSBNSUIgZXhwZXJ0IHRoYXQgdGhpcyBpcyBPSy4NCg0KQ29tbWVudDoNClNlY3Rpb24g MS4yDQpIZWxwZnVsIGlmIHMvU1RENjIvU1RENjIgW1JGQzM0MTFdLw0KDQpTZWN0aW9uIDEuNQ0K WW91IHNlZW0gdG8gZmx1Y3R1YXRlIGluIHlvdXIgdXNhZ2Ugb2YgUkZDIDIxMTkgbGFuZ3VhZ2Uu DQpJbiBidWxsZXQgMywgSSBzdWdnZXN0IHMvbWF5IG5vdC9taWdodCBub3QvDQoNClNlY3Rpb24g Mi4zLjENCk5vdHdpdGhzdGFuZGluZyB0aGUgcmVxdWlyZW1lbnQgdG8gcmVhZCB0aGUgcmVmZXJl bmNlIG1hdGVyaWFsLCBwbGVhc2UNCmV4cGFuZCBBU0kgb24gZmlyc3QgdXNlLg0KDQpTZWN0aW9u IDMuMS4yDQoiUkVRVUlSRVMiIGlzIG5vdCBpbiB0aGUgUkZDIDIxMTkgbGV4aWNvbi4NCg0KU2Vj dGlvbiAzLjEuMw0KImFuZCBvdGhlciBNSUIgbW9kdWxlcyIgaXMgYSBiaXQgdmFndWUuDQoNClNl Y3Rpb24gMy4xLjMNCiAgIElBTkEgbWFpbnRhaW5zIGEgcmVnaXN0cnkgZm9yIHRyYW5zcG9ydCBk b21haW5zIGFuZCB0aGUgY29ycmVzcG9uZGluZw0KICAgcHJlZml4Lg0KV291bGQgYmUgaGVscGZ1 bCB0byBpbmNsdWRlIGEgcG9pbnRlciAocGVyaGFwcyBieSByZWdpc3RyeSBuYW1lLCBvciBieQ0K ZGVmaW5pbmcgUkZDKSB0byB0aGlzIHJlZ2lzdHJ5LiANCg0KU2VjdGlvbiA3DQpVc2VmdWwgaWYg RlJPTSBjbGF1c2VzIGNhbiBnaXZlIGEgY29tbWVudCB0aGF0IHNob3dzIHRoZSBSRkMgdGhhdCAN CmRlZmluZXMgdGhlIG1vZHVsZSBmcm9tIHdoaWNoIHRoZSBpbXBvcnQgaXMgdGFrZW4uDQpGb3Ig ZXhhbXBsZQ0KRlJPTSBTTk1QdjItU01JICAtLSBSRkMgMjU3OA0KDQo= From j.schoenwaelder@jacobs-university.de Tue May 5 00:32:57 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469693A6BE9 for ; Tue, 5 May 2009 00:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQqGr5lgY5Qf for ; Tue, 5 May 2009 00:32:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 50A653A67F5 for ; Tue, 5 May 2009 00:32:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE822C00D9 for ; Tue, 5 May 2009 09:29:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pVcw2ebP-AEk for ; Tue, 5 May 2009 09:29:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAAE5C00E7 for ; Tue, 5 May 2009 09:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 65B78ADA327; Tue, 5 May 2009 09:28:22 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 5 May 2009 09:28:22 +0200 Resent-Message-ID: <20090505072822.GI18821@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Mon, 4 May 2009 18:58:24 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D158C0008 for ; Mon, 4 May 2009 18:58:24 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 46C595EC for ; Mon, 4 May 2009 18:58:24 +0200 (CEST) Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id spY3nCnZ2iHL for ; Mon, 4 May 2009 18:58:23 +0200 (CEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Mon, 4 May 2009 18:58:23 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:1112:1::20]:50891) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M11Ui-0002Dz-7W; Mon, 04 May 2009 18:58:20 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id 1550B3A6972; Mon, 4 May 2009 09:56:47 -0700 (PDT) From: Adrian Farrel To: "iesg@ietf.org" Date: Mon, 4 May 2009 18:56:48 +0200 Thread-Topic: COMMENT: draft-ietf-isms-radius-usage Thread-Index: AcnM2Yl0ozhhF84UTOO2yBg4GOZYBQ== Message-ID: <20090504165648.1550B3A6972@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 x-sa-exim-scanned: Yes (on merlot.tools.ietf.org) x-sa-exim-mail-from: wwwrun@core3.amsl.com x-sa-exim-connect-ip: 2001:1890:1112:1::20 x-sa-exim-version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) x-sa-exim-rcpt-to: draft-ietf-isms-radius-usage@tools.ietf.org, isms-chairs@tools.ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-isms-radius-usage@tools.ietf.org" , "isms-chairs@tools.ietf.org" Subject: [Isms] COMMENT: draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 07:32:57 -0000 Q29tbWVudDoNClRhYmxlIDIgc2F5cw0KICAgMCAgICBUaGlzIGF0dHJpYnV0ZSBNVVNUIE5PVCBi ZSBwcmVzZW50IGluIGEgcGFja2V0Lg0KICAgMCsgICBaZXJvIG9yIG1vcmUgaW5zdGFuY2VzIG9m IHRoaXMgYXR0cmlidXRlIE1BWSBiZSBwcmVzZW50IGluDQogICAgICAgIGEgcGFja2V0Lg0KICAg MC0xICBaZXJvIG9yIG9uZSBpbnN0YW5jZSBvZiB0aGlzIGF0dHJpYnV0ZSBNQVkgYmUgcHJlc2Vu dCBpbg0KICAgICAgICBhIHBhY2tldC4NCiAgIDEgICAgRXhhY3RseSBvbmUgaW5zdGFuY2Ugb2Yg dGhpcyBhdHRyaWJ1dGUgTVVTVCBiZSBwcmVzZW50IGluDQogICAgICAgIGEgcGFja2V0Lg0KICAg KiAgICBPbmx5IG9uZSBvZiB0aGVzZSBhdHJpYnV0ZSBvcHRpb25zIFNIT1VMRCBiZSBpbmNsdWRl ZC4NCg0KQnV0Og0KLSB0YWJsZSAxIGhhcyBubyBpbnN0YW5jZSBvZiAwKw0KLSB0YWJsZSAxIGhh cyBubyBpbnN0YW5jZSBvZiAxDQotICogc2VlbXMgdG8gY29udHJhZGljdCAwLTENCg0K From cfinss@dial.pipex.com Tue May 5 07:05:11 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF883A6D11 for ; Tue, 5 May 2009 07:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxtCh8io97zf for ; Tue, 5 May 2009 07:05:09 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 823083A6AA8 for ; Tue, 5 May 2009 07:05:09 -0700 (PDT) X-Trace: 210097071/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.197/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.197 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAB/l/0k+vBPF/2dsb2JhbACDKDmKbbIYCY9gAQaCSIEyBQ X-IronPort-AV: E=Sophos;i="4.40,297,1238972400"; d="scan'208";a="210097071" X-IP-Direction: IN Received: from 1cust197.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.197]) by smtp.pipex.tiscali.co.uk with SMTP; 05 May 2009 15:06:33 +0100 Message-ID: <000401c9cd82$41f9c3e0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090427194829.GC10764@elstar.local> Date: Tue, 5 May 2009 14:38:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Pasi Eronen Subject: Re: [Isms] revised core isms documents posted - please check X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:05:11 -0000 I have read all three apart from the MIB modules and yes, the latest comments have been addressed. >From (mostly0) some comments of mine last March: in tsm-13 s.2.3.1, I see "Such messages can still be conveyed over a secure transport protocol, but the Transport Security Model will not be invoked." as overly optimistic. sshtm 5.2 2) will discard an outbound message if no cache exists, so 'can' seems too strong. I suggest 'may' allowing that a future secure transport model may allow it even if none do at present. while the MIB module contains an extra period " or models defined in other document.." in sshtm it might be time to remove the note about [todo] and [discuss] markers. 3.1.2 lacks a period in " requirements of securityLevel were met The SSH Transport Model has no" 5.1 2C and 3C suggest "i.e." rather than "e.g." is more accurate as I do not see an alternative 5.3 3) by an '@' character (ASCII 0x40), that user-name string that suggest removing second 'that' Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: ; "Allison Mankin" ; "Ben Campbell" ; "Vijay K. Gurbani" Cc: "Pasi Eronen" Sent: Monday, April 27, 2009 9:48 PM Subject: [Isms] revised core isms documents posted - please check > Hi, > > a new set of the core ISMS documents has been posted: > > http://tools.ietf.org/html/draft-ietf-isms-tmsm-17 > http://tools.ietf.org/html/draft-ietf-isms-transport-security-model-13 > http://tools.ietf.org/html/draft-ietf-isms-secshell-16 > > These documents incorporate comments we received as part of the IETF > last call process. Please check the changes and let us know as soon as > possible if you think a comment has not been sufficiently addressed or > errors have been introduced. > > These documents are currently scheduled for the IESG meeting on May 7th. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Tue May 5 10:23:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E533A6DD2 for ; Tue, 5 May 2009 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdcRdaHHliT9 for ; Tue, 5 May 2009 10:23:37 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 9B3D53A6DA8 for ; Tue, 5 May 2009 10:23:37 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA10.westchester.pa.mail.comcast.net with comcast id nmhx1b0030QuhwU5AtR4Py; Tue, 05 May 2009 17:25:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id ntR31b00G0UQ6dC3NtR3sM; Tue, 05 May 2009 17:25:04 +0000 From: "David Harrington" To: "'Adrian Farrel'" , References: <20090504134349.89A3F3A6FEB@core3.amsl.com> Date: Tue, 5 May 2009 13:25:02 -0400 Message-ID: <068e01c9cda6$6d261f90$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 Thread-Index: AcnMvpYMlCu4kkFrQ3iqMPVJoy330QA1/b0w X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20090504134349.89A3F3A6FEB@core3.amsl.com> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:23:38 -0000 Hi, I am changing the sources with the requested changes. comments inline David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Adrian Farrel [mailto:adrian.farrel@huawei.com] > Sent: Monday, May 04, 2009 9:44 AM > To: iesg@ietf.org > Cc: isms-chairs@tools.ietf.org; > draft-ietf-isms-transport-security-model@tools.ietf.org > Subject: DISCUSS and COMMENT: > draft-ietf-isms-transport-security-model > > Discuss: > I am not a MIB expert, but when I see counters I wonder about wraps > and discontinuities. These seem not to be covered in this document > and I would like to hear from a MIB expert that this is OK. I discussed this with some of the MIB Doctors. These counters should behave in the normal manner, as defined in rfc2578: 7.1.6. Counter32 The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. There are no anticipated discontinuities other than re-initialization of the management system. This behavior is consistent with other SNMP-system counters, such as those in the User-based Security Model. > > Comment: > Section 1.2 > Helpful if s/STD62/STD62 [RFC3411]/ I deliberately did not provide a reference to a specific RFC. STD62 refers to 8 RFCs. The terminology under discussion in section 1.2 is not limited to RFC3411. I think it is correct to just reference STD62 in this case without a citation. > > Section 1.5 > You seem to fluctuate in your usage of RFC 2119 language. > In bullet 3, I suggest s/may not/might not/ I will search out instances of lowercase may/should/must and either make them RFC2119 compliant or change the word. > > Section 2.3.1 > Notwithstanding the requirement to read the reference material, please > expand ASI on first use. done. > > Section 3.1.2 > "REQUIRES" is not in the RFC 2119 lexicon. fixed. > > Section 3.1.3 > "and other MIB modules" is a bit vague. Yes, but a complete list would be distracting, and a moving target. > > Section 3.1.3 > IANA maintains a registry for transport domains and the > corresponding > prefix. > Would be helpful to include a pointer (perhaps by registry name, or by > defining RFC) to this registry. done. > > Section 7 > Useful if FROM clauses can give a comment that shows the RFC that > defines the module from which the import is taken. > For example > FROM SNMPv2-SMI -- RFC 2578 done > > From dbharrington@comcast.net Tue May 5 10:49:22 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC1C28C144 for ; Tue, 5 May 2009 10:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qinKivR+wPH9 for ; Tue, 5 May 2009 10:49:21 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id EA0CC3A71C0 for ; Tue, 5 May 2009 10:49:20 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id nosY1b03j1HzFnQ5Btqn5k; Tue, 05 May 2009 17:50:47 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id ntqm1b00n0UQ6dC3atqnEa; Tue, 05 May 2009 17:50:47 +0000 From: "David B Harrington" To: "'Barry Leiba'" , , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> Date: Tue, 5 May 2009 13:50:46 -0400 Message-ID: <069801c9cdaa$050fb660$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 Thread-Index: AcnLZUwu2W1Vd7VvT4OWm2HjF/zAmACQXncg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:49:22 -0000 Hi, Thanks fo rthe review. I am updating the sources. comments inline David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Saturday, May 02, 2009 4:34 PM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; > isms-chairs@tools.ietf.org > Subject: [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines a type of Security Model, as defined in RFC > 3411, designed to go with a Transport Model, as defined in > draft-ietf-isms-tmsm. I have no expertise in MIBs, and must presume > that people who do have reviewed this. > > For that matter, I don't have expertise in SNMP, so please take these > comments with that in mind. I've briefly gone through the associated > documents, and I think I understand how the pieces fit into the > architecture, but my understanding isn't thorough. > > My comments: > > Section 1.5: bullets 1 & 2 use normative RFC 2119 language. Should > bullets 4 & 5 do so also? E.g., "A Security Model SHOULD NOT require > changes to the SNMP architecture." fixed. > > Section 2.1.1: I'm confused by this. RFC 3411 section 3.1.1.4.1 says > that a Security Model specifies "the security protocols used to > provide security services such as authentication and privacy." Yet > this section says that the Transport Security Model does NOT provide > these things. Hmmm. two parts to this answer: 1) RFC3411 says the security model **specifies**; it does not say it must provide the security services itself. This section says this security model "does not provide security mechanisms such as authentication and encryption itself." So they are consistent. 2) They are slightly inconsistent, because the WG realized that the interface to different security protocols would require much the same thing, so we made the Transport Security Model capable of working with multiple underlying security-providing security protocols, and rather than **specifying** each possible protocol, we specify how an administrator can specify the protocol as a parameter used by the Security Model. > > And if it doesn't provide them, how can the admonition to use it "with > a Transport Model that provides appropriate security" be a SHOULD, and > not a MUST (noting that "appropriate" security could include no > authentication, if that's appropriate to the system in question)? > Some component has to take responsibility for the security, even if > it's to determine that no authentication or no privacy controls are > needed. That is a deployment decision made by an administrator who has an understanding of what is appropriate to the system in question. MUST is for implementers and SHOULD is for deployers. > > The same goes for the discussion of this in section 8, Security > Considerations. "The security threats and how these threats are > mitigated should be covered in detail in the specifications of the > Transport Models and the underlying secure transports." It looks like > this needs to be stronger than plain-English "should", or RFC 2119 > "SHOULD", no? fixed. > > I think this is a key point to make clear, so it's well understood > where the responsibility lies for the assurance of "appropriate" > security in the Transport Model, and what happens when a system uses > multiple Security Models, one of which is this one. > > Again, my confusion here might simply be due to my understanding of > the architecture being only superficial. > > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From jhutz@cmu.edu Tue May 5 12:09:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468693A6E38; Tue, 5 May 2009 12:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYkvilSA9R2D; Tue, 5 May 2009 12:09:18 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6A4FE3A6CFA; Tue, 5 May 2009 12:09:18 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n45JAH51026910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:10:17 -0400 (EDT) Date: Tue, 05 May 2009 15:10:17 -0400 From: Jeffrey Hutzelman To: David B Harrington , "'Barry Leiba'" , secdir@ietf.org, iesg@ietf.org Message-ID: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> In-Reply-To: <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org, jhutz@cmu.edu Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:09:19 -0000 --On Tuesday, May 05, 2009 01:50:46 PM -0400 David B Harrington wrote: > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. MUST > is for implementers and SHOULD is for deployers. Nononono. When we say "MUST is for implementors", we mean that our specifications give requirements for implementations which claim to comply; RFC2119 requirements language is generally inappropriate for deployment advice. It is appropriate to say TSM MUST be use with a TM that provides appropriate security; that is equivalent to saying that implementations MUST NOT use TSM together with an inappropriate TM, such as UDP. That said, selection of transport and security models generally is an operational decision. TSM itself is really architectural glue to allow us to push some of the security infrastructure down into a transport below SNMP, such as SSH or TLS. You'd never say "I want to use TSM, now which transport should I use"; you'd say "I want to use SSH -- oh, for that to work, I have to use it with TSM". -- Jeff From dbharrington@comcast.net Tue May 5 12:27:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470DA3A6DAC for ; Tue, 5 May 2009 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mlplsue1Vqn for ; Tue, 5 May 2009 12:27:14 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id A7BE33A6E13 for ; Tue, 5 May 2009 12:27:09 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id npTJ1b00B16LCl054vUcTA; Tue, 05 May 2009 19:28:36 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id nvUb1b00a0UQ6dC3SvUbcE; Tue, 05 May 2009 19:28:36 +0000 From: "David B Harrington" To: "'Jeffrey Hutzelman'" , "'Barry Leiba'" , , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> Date: Tue, 5 May 2009 15:28:34 -0400 Message-ID: <06a701c9cdb7$aed00f30$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 Thread-Index: AcnNtSYsrMOk66M4RPGOpg+msofHJgAAhTKA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:27:15 -0000 OK, I'll change my answer. That is a deployment decision made by an administrator who has an understanding of what is appropriate to the system in question. What is the correct non-RFC2119 phrase in which to couch our deployment advice? dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Tuesday, May 05, 2009 3:10 PM > To: David B Harrington; 'Barry Leiba'; secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; > isms@ietf.org; isms-chairs@tools.ietf.org; jhutz@cmu.edu > Subject: Re: [Isms] [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > --On Tuesday, May 05, 2009 01:50:46 PM -0400 David B Harrington > wrote: > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. MUST > > is for implementers and SHOULD is for deployers. > > Nononono. When we say "MUST is for implementors", we mean that our > specifications give requirements for implementations which > claim to comply; > RFC2119 requirements language is generally inappropriate for > deployment > advice. > > It is appropriate to say TSM MUST be use with a TM that provides > appropriate security; that is equivalent to saying that > implementations > MUST NOT use TSM together with an inappropriate TM, such as UDP. > > > That said, selection of transport and security models generally is an > operational decision. TSM itself is really architectural > glue to allow us > to push some of the security infrastructure down into a > transport below > SNMP, such as SSH or TLS. You'd never say "I want to use > TSM, now which > transport should I use"; you'd say "I want to use SSH -- oh, > for that to > work, I have to use it with TSM". > > > -- Jeff > From jhutz@cmu.edu Tue May 5 12:41:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70563A71A3; Tue, 5 May 2009 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYlM6RORR87p; Tue, 5 May 2009 12:41:42 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 1FC073A6CBF; Tue, 5 May 2009 12:41:10 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n45Jg5Ov028113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:42:05 -0400 (EDT) Date: Tue, 05 May 2009 15:42:05 -0400 From: Jeffrey Hutzelman To: David B Harrington , "'Barry Leiba'" , secdir@ietf.org, iesg@ietf.org Message-ID: In-Reply-To: <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org, jhutz@cmu.edu Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:41:42 -0000 --On Tuesday, May 05, 2009 03:28:34 PM -0400 David B Harrington wrote: > OK, I'll change my answer. > > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. > > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? I don't know, but as I said, I don't think it would be inappropriate to simply say TSM MUST be used with a secure transport, placing the onus on implementors to prevent inappropriate combinations from being used. From dbharrington@comcast.net Tue May 5 13:42:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8441A3A6AFE for ; Tue, 5 May 2009 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ9n4i8Oidf3 for ; Tue, 5 May 2009 13:42:33 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 7B7933A6C13 for ; Tue, 5 May 2009 13:42:33 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id nmc51b00617dt5G57wjpL0; Tue, 05 May 2009 20:43:49 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id nwk01b0090UQ6dC3Zwk0w8; Tue, 05 May 2009 20:44:00 +0000 From: "David B Harrington" To: "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Date: Tue, 5 May 2009 16:43:59 -0400 Message-ID: <06ae01c9cdc2$37bbe4e0$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 Thread-Index: AcnNvYH7CDZJrmj2Tqm7iS1rwxNuTAAAYdyQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:42:34 -0000 Hi Barry, your formulation is "MUST ... use", where "use" is a deployment decision, and MUST is inappropriate for deployment advice. We currently use "SHOULD ... use", but Jeff thinks that in inappropriate as well. How about: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so operators are advised to always use this with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. dbh > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On > Behalf Of Barry Leiba > Sent: Tuesday, May 05, 2009 4:04 PM > To: David B Harrington > Cc: secdir@ietf.org; iesg@ietf.org; isms@ietf.org; > isms-chairs@tools.ietf.org > Subject: Re: [Isms] [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > Well, this would make me happy; would it work for you (and others)?: > > OLD: > by the RFC 3411 architecture. However, the Transport > Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it SHOULD always be used with a > Transport Model > that provides appropriate security. Which threats are > addressed and > how they are mitigated depends on the Transport Model. > > NEW: > by the RFC 3411 architecture. However, the Transport > Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it MUST always be used with a Transport Model > that provides appropriate security. What is "appropriate" > for a particular > deployment is an administrative decision. Which threats > are addressed > and how they are mitigated depends on the Transport Model. > > Barry > From ietfdbh@comcast.net Tue May 5 15:03:23 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D053928C161 for ; Tue, 5 May 2009 15:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 302srTjpSMoJ for ; Tue, 5 May 2009 15:03:22 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 5A42928C184 for ; Tue, 5 May 2009 15:03:21 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id nlnT1b0020cZkys55y4prH; Tue, 05 May 2009 22:04:49 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id ny4o1b00B0UQ6dC3Wy4oJS; Tue, 05 May 2009 22:04:49 +0000 From: "David Harrington" To: "'Alexey Melnikov'" , References: <20090502131054.256133A6C75@core3.amsl.com> Date: Tue, 5 May 2009 18:04:47 -0400 Message-ID: <06bc01c9cdcd$8195aeb0$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 Thread-Index: AcnLJ9G3Lz+hJt4rSvO9FuO1N8ZgGwChMPfw X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20090502131054.256133A6C75@core3.amsl.com> Cc: draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 22:03:23 -0000 Hi Alexey, Thanks for the review. I am updating my sources as needed. comments inline. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Alexey Melnikov > Sent: Saturday, May 02, 2009 9:11 AM > To: iesg@ietf.org > Cc: draft-ietf-isms-tmsm@tools.ietf.org; isms-chairs@tools.ietf.org > Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm > > Discuss: > In general this is a well written document and I hope to > clear this DISCUSS very soon. > > 3.2.1. Architectural Modularity Requirements > > [...] > > To encourage a basic level of interoperability, any Transport Model > SHOULD define one mandatory-to-implement security mechanism, but > should also be able to support additional existing and new > mechanisms. > > Why this SHOULD is not a MUST? I am expecting a > mandatory-to-implement to be a MUST. remember these are transport models, not security models. Some transport models can be non-secure. What if we defined a new transport model using SCTP or 10GE, for example? We can use that with User-based Security Model, which does its own security work. Why would it be required that the SCTP or 10GE Transport Models define a mandatory-to-implement security mechanism? (and with RFC3411, it would be wrong to specify that USM is the mandatory-to-implement security mechanism for a specific transport model). We also allow non-standard proprietary transport models and on the architectural level having a non-standard transport model without a mandatory-to-implement security mechanism is just fine. We use SHOULD to provide guidance to model developers, without assuming we can predict what is approrpiate for all future transport models. > > > 3.2.2.1. securityName and securityLevel Mapping > > [...] > > Documents defining a new transport domain MUST define a prefix that > MAY be prepended by the Security Model to all passed securityNames. > > I might be slightly confused here: passed by whom? Is this wording clearer? prepended to all securityNames passed by the Security Model. > > The prefix MUST include from one to four ASCII characters, not > > You probably didn't mean any US-ASCII character here, e.g. I > don't think > you wanted to allow control characters, spaces, etc. > Wouldn't it be better if this is defined as US-ASCII alpha-numeric? We can change this to US-ASCII alpha-numeric. > 3.3.4. Message security versus session security > > 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 security level requested by a transport-aware security > model, i.e. noAuthNoPriv and authNoPriv might be sent over an > authenticated and encrypted session. A Transport Model MUST NOT > downgrade the security level requested by a > transport-aware security > model, and SHOULD discard any message where this would occur. > > What is an alternative to discarding? > (I.e. why the last SHOULD is not a MUST) RFC3411 has a modular architecture, and we try not to constrain the specific behavior of yet-to-be-defined models and implementations with MUSTs. We use SHOULD to provide guidance rather than a hard rule. It is expensive to generate messages only to discard them during the final steps of processing (sending them). In the Transport Subsystem, the SNMP message is fully formed before handing it to the Transport Model, and if transport-security is used, then the message contents should be independent of the transport used. A new Transport Model could, for example, be defined that returns the fully-formed message to the requesting application, which might then choose to send it using a different security model or different security association or a different address (in a multi-homed receiver) that can meet the securityLevel requirement. If we mandate in the architecture that it MUST be discarded, then we do not permit such solutions. > > Comment: > I think the document is a bit lax with SHOULDs, some of which > might be better specified as MUSTs or just removed. For example: > > 3.3.3. Session Maintenance Requirements > > [...] > > 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. > > Maybe just say "MUST define what heppens to the objects ..."? done. > > > 3.3.4. Message security versus session security > > [...] > > If a secure transport session is closed between the time a request > message is received, and the corresponding response > message is sent, > then the response message SHOULD be discarded, even if a > new session > has been established. The SNMPv3 WG decided that this should be a > SHOULD architecturally, and it is a > security-model-specific decision > whether to REQUIRE this. The architecture does not mandate this > requirement to allow for future security models where this > might make > sense, but not requiring this could lead to added complexity and > security vulnerabilities, so most security models SHOULD require > this. > > Enclose some SHOULDs in "" to emphasize that they are not > declaring requirements? We use a different convention: >From section 1.2: Non uppercased versions of the keywords should be read as in normal English. 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 (ASIs) (see section 3.2). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. I'll certainly double-check al usages, but generally we used uppercased keywords when we thought it would impact interoperability, and lowercase where we thought it would impact modularity or inter-model expectations within an SNMP entity. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From ietfdbh@comcast.net Tue May 5 17:16:14 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E183A6E2B for ; Tue, 5 May 2009 17:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cD-Jvr3usQn for ; Tue, 5 May 2009 17:16:13 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 5752F3A6DFC for ; Tue, 5 May 2009 17:15:47 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id o0ED1b00517dt5G530Gz5g; Wed, 06 May 2009 00:16:59 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id o0HE1b00E0UQ6dC3Z0HEWY; Wed, 06 May 2009 00:17:15 +0000 From: "David Harrington" To: "'Alexey Melnikov'" , References: <20090503113302.C3E693A6A35@core3.amsl.com> Date: Tue, 5 May 2009 20:17:13 -0400 Message-ID: <06c401c9cde0$01a02290$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 Thread-Index: AcnL4yqGQTUJx6sWRYueePaBZr+e/wB8Ur+Q X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20090503113302.C3E693A6A35@core3.amsl.com> Cc: draft-ietf-isms-secshell@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 00:16:14 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Alexey Melnikov > Sent: Sunday, May 03, 2009 7:33 AM > To: iesg@ietf.org > Cc: draft-ietf-isms-secshell@tools.ietf.org; > isms-chairs@tools.ietf.org > Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell > > Discuss: > I have a couple minor related points here: > > 5.3. Establishing a Session > > [...] > > 3. The client will then invoke an SSH authentication service to > authenticate the principal, such as that described in the SSH > authentication protocol [RFC4252]. > > 1. If the tmTransportAddress field contains a > user-name followed > by an '@' character (ASCII 0x40), that user-name > string that > should be presented to the ssh server as the "user > name" for > user authentication purposes. If there is no user-name in > the tmTransportAddress then the tmSecurityName > should be used > as the user-name. > > I think this text needs to say which character set is used > for representing user-name, and ideally it needs to describe or point > to syntax of allowed usernames. Is this OK? "The user name must be encoded in UTF-8 (per RFC4252)." with a citation to [RFC4252] in the text, with a REFERENCE clause to "RFC4252, The Secure Shell (SSH) Authentication Protocol" in the SnmpSSHAddress definition > > [...] > SnmpSSHAddress ::= TEXTUAL-CONVENTION [...] > > Same comment as above: can you add a reference to the > document defining syntax of the username? yup. > > The hostname must be encoded in ASCII, as specified in > RFC3490 (Internationalizing Domain Names in Applications) > > Same comment about syntax: I think a reference to the > ABNF production from RFC 3986 would be appropriate here. We have a REFERENCE to RFC3986 already. If you want something more specific, can you provided suggested text? I am a bit concerned about affecting readability with too many references inside the DESCRIPTION clause. We have a REFERENCE clause. Is this OK? SnmpSSHAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents either a hostname or IP address, along with a port number and an optional user name. The beginning of the address specification may contain a user name followed by an '@' (US-ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. The user name must be encoded in UTF-8 (per RFC4252). If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname or IP address. The hostname is always in US-ASCII (as per RFC3490), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be in colon separated format, surrounded by square brackets ('[' US-ASCII character 0x5B and ']' US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. Values of this textual convention might not be directly useable as transport-layer addressing information, and may require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpSSHAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation. " REFERENCE "RFC3490, Internationalizing Domain Names in Applications, RFC4252, The Secure Shell (SSH) Authentication Protocol, RFC3986, Uniform Resource Identifier (URI): Generic Syntax" SYNTAX OCTET STRING (SIZE (1..255)) > > Nit: I also think the text as written is not quite right. > Internationalized hostnames must be encoded using the algorithm > specified in RFC 3490, but for all ASCII hostnames there is no need > to send people to review RFC 3490. So I would suggest: > > The hostname is always in ASCII. Internationalized Domain Names > MUST be encoded in ASCII, as specified in > RFC3490 (Internationalizing Domain Names in Applications). > > followed by a colon ':' (ASCII character 0x3A) and a > decimal port number in ASCII. The name SHOULD be fully > qualified whenever possible. > > Comment: > 1.2. Conventions > > [...] > > Sections requiring further editing are identified by [todo] markers > in the text. Points requiring further WG research and > discussion are > identified by [discuss] markers in the text. > > Please delete this paragraph. > I can't find any [todo] or [discuss] markers in the document. > > Note to RFC Editor - if the previous paragraph and this > note have not > been removed, please send the document back to the editor to remove > this. > > :-) done. > > > 2. The Secure Shell Protocol > > [...] > > The client sends a service request once a secure transport layer > connection has been established. A second service request is sent > after client authentication is complete. > > For my education, can you point out where this is described > in more details? I think this refers to RFC4252 section 5. > > This allows new protocols > to be defined and coexist with the protocols listed above. > > > 3.1.2. Message Authentication > > [...] > > The SSH Transport Model determines from SSH the identity of the > authenticated principal, and the type and address > associated with an > incoming message, and provides this information to SSH for an > outgoing message. The transport layer algorithms used to provide > > "SSH transport layer algorithms ..."? OK. > > authentication, data integrity and encryption SHOULD NOT be exposed > to the SSH Transport Model layer. The SNMPv3 WG > deliberately avoided > this and settled for an assertion by the security model that the > requirements of securityLevel were met The SSH Transport > Model has no > > I think there is a missing dot before "The". fixed. > > mechanisms by which it can test whether an underlying SSH > connection > provides auth or priv, so the SSH Transport Model trusts that the > underlying SSH connection has been properly configured to support > authPriv security characteristics. > > > 5. Elements of Procedure > > [...] > > 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 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. > > I am wondering why 2 "should"s are not SHOULDs or even MUSTs. two reasons. 1) cut and paste from SNMPv3 standard documents. 2) the shoulds refer to implementation-specific processing that happens strictly inside the SNMP entity, not on the wire. > > > 5.1. Procedures for an Incoming Message > > [...] > > 4. Create a tmStateReference cache for subsequent reference to the > information. > > tmTransportDomain = snmpSSHDomain > > tmTransportAddress = the derived tmTransportAddress > from step > 3. > > I think this is step 2. > > tmSecurityName = The derived tmSecurityName from step 2. > > And this is step 3. fixed. > > > 5.3. Establishing a Session > > [...] > > 3. The client will then invoke an SSH authentication service to > authenticate the principal, such as that described in the SSH > authentication protocol [RFC4252]. > > 1. If the tmTransportAddress field contains a > user-name followed > by an '@' character (ASCII 0x40), that user-name > string that > > Remove the last "that"? fixed. > > should be presented to the ssh server as the "user > name" for > user authentication purposes. If there is no user-name in > the tmTransportAddress then the tmSecurityName > should be used > as the user-name. > > > > > 7. MIB Module Definition > > [...] > > snmpSSHDomain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over SSH transport domain. The corresponding > transport address is of type SnmpSSHAddress. > > When an SNMP entity uses the snmpSSHDomain transport > model, it must be capable of accepting messages up to > and including 8192 octets in size. Implementation of > larger values is encouraged whenever possible. > > The securityName prefix to be associated with the > snmpSSHDomain is 'ssh'. This prefix may be used by security > models or other components to identify what secure transport > > s/what/that ? "which" has the right meaning. > > infrastructure authenticated a securityName." > > > 8. Operational Considerations > > The SSH Transport Model will likely not work in conditions where > access to the CLI has stopped working. > > Can you elaborate on this a bit more? How's this? The SSH Transport Model will likely not work in conditions where access to the CLI has stopped working. Remote access to a CLI is often over TCP, which is also used by SSH. > > In situations where SNMP > access has to work when the CLI has stopped working, a UDP > transport > model should be considered instead of the SSH Transport Model. > > > > I don't think the reference to [RFC2865] (RADIUS) is normative. OK. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Tue May 5 17:37:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92BF3A6892; Tue, 5 May 2009 17:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaYApnRznAoZ; Tue, 5 May 2009 17:37:29 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6E9533A6B09; Tue, 5 May 2009 17:37:28 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n460cmDH009978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 20:38:49 -0400 (EDT) Date: Tue, 05 May 2009 20:38:49 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Alexey Melnikov'" , iesg@ietf.org Message-ID: In-Reply-To: <200905052204.n45M4sve002429@mx02.srv.cs.cmu.edu> References: <20090502131054.256133A6C75@core3.amsl.com> <200905052204.n45M4sve002429@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu, draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 00:37:29 -0000 --On Tuesday, May 05, 2009 06:04:47 PM -0400 David Harrington wrote: >> 3.2.1. Architectural Modularity Requirements >> >> [...] >> >> To encourage a basic level of interoperability, any Transport > Model >> SHOULD define one mandatory-to-implement security mechanism, but >> should also be able to support additional existing and new >> mechanisms. >> >> Why this SHOULD is not a MUST? I am expecting a >> mandatory-to-implement to be a MUST. > > remember these are transport models, not security models. Some > transport models can be non-secure. > > What if we defined a new transport model using SCTP or 10GE, for > example? We can use that with User-based Security Model, which does > its own security work. Why would it be required that the SCTP or 10GE > Transport Models define a mandatory-to-implement security mechanism? > (and with RFC3411, it would be wrong to specify that USM is the > mandatory-to-implement security mechanism for a specific transport > model). > > We also allow non-standard proprietary transport models and on the > architectural level having a non-standard transport model without a > mandatory-to-implement security mechanism is just fine. > > We use SHOULD to provide guidance to model developers, without > assuming we can predict what is approrpiate for all future transport > models. In this case I think maybe we should eliminate the text Alexey quoted entirely. As you point out, the architecture is modular; IMHO this means that under normal circumstances a transport model should _not_ be specifying a mandatory-to-implement or even a RECOMMENDED security model; that is up to SNMPv3 or some application, not each transport model. The interesting exception is secure transport models designed to be used with TSM. These models should RECOMMEND if not REQUIRE support for TSM, since they are fairly useless without it (you can use SSH with USM, but you don't really get more or different security than you would using TCP with USM). -- Jeff From ietfdbh@comcast.net Tue May 5 19:39:12 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1D53A69A6 for ; Tue, 5 May 2009 19:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxdFRmf0Raqa for ; Tue, 5 May 2009 19:39:11 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 242763A68B2 for ; Tue, 5 May 2009 19:39:11 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA09.westchester.pa.mail.comcast.net with comcast id nw251b02c0xGWP8592ged3; Wed, 06 May 2009 02:40:38 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id o2gd1b00W0UQ6dC3Y2gd8A; Wed, 06 May 2009 02:40:38 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Alexey Melnikov'" , References: <20090502131054.256133A6C75@core3.amsl.com> <200905052204.n45M4sve002429@mx02.srv.cs.cmu.edu> Date: Tue, 5 May 2009 22:40:36 -0400 Message-ID: <06d401c9cdf4$09c79980$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 Thread-Index: AcnN4wh2bG/GsTZ+TGGBXCpr+wES8QAEMzZQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 02:39:12 -0000 A Transport Model cannot require a specific security model. That would violate the RFC3411 modularity. The WG discussed this at length. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Tuesday, May 05, 2009 8:39 PM > To: David Harrington; 'Alexey Melnikov'; iesg@ietf.org > Cc: draft-ietf-isms-tmsm@tools.ietf.org; > isms-chairs@tools.ietf.org; isms@ietf.org; jhutz@cmu.edu > Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm > > --On Tuesday, May 05, 2009 06:04:47 PM -0400 David Harrington > wrote: > > >> 3.2.1. Architectural Modularity Requirements > >> > >> [...] > >> > >> To encourage a basic level of interoperability, any Transport > > Model > >> SHOULD define one mandatory-to-implement security mechanism, but > >> should also be able to support additional existing and new > >> mechanisms. > >> > >> Why this SHOULD is not a MUST? I am expecting a > >> mandatory-to-implement to be a MUST. > > > > remember these are transport models, not security models. Some > > transport models can be non-secure. > > > > What if we defined a new transport model using SCTP or 10GE, for > > example? We can use that with User-based Security Model, which does > > its own security work. Why would it be required that the > SCTP or 10GE > > Transport Models define a mandatory-to-implement security mechanism? > > (and with RFC3411, it would be wrong to specify that USM is the > > mandatory-to-implement security mechanism for a specific transport > > model). > > > > We also allow non-standard proprietary transport models and on the > > architectural level having a non-standard transport model without a > > mandatory-to-implement security mechanism is just fine. > > > > We use SHOULD to provide guidance to model developers, without > > assuming we can predict what is approrpiate for all future transport > > models. > > In this case I think maybe we should eliminate the text Alexey quoted > entirely. As you point out, the architecture is modular; > IMHO this means > that under normal circumstances a transport model should _not_ be > specifying a mandatory-to-implement or even a RECOMMENDED > security model; > that is up to SNMPv3 or some application, not each transport model. > > The interesting exception is secure transport models designed > to be used > with TSM. These models should RECOMMEND if not REQUIRE > support for TSM, > since they are fairly useless without it (you can use SSH > with USM, but you > don't really get more or different security than you would > using TCP with > USM). > > -- Jeff > From jhutz@cmu.edu Tue May 5 19:53:14 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FC73A6978; Tue, 5 May 2009 19:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xIgyT6tg2gd; Tue, 5 May 2009 19:53:14 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0D1B13A6965; Tue, 5 May 2009 19:53:13 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n462sbT6012309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 22:54:38 -0400 (EDT) Date: Tue, 05 May 2009 22:54:37 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Alexey Melnikov'" , iesg@ietf.org Message-ID: <84C2332FBAA30A61DB3C4EB3@atlantis.pc.cs.cmu.edu> In-Reply-To: <06d401c9cdf4$09c79980$0600a8c0@china.huawei.com> References: <20090502131054.256133A6C75@core3.amsl.com> <200905052204.n45M4sve002429@mx02.srv.cs.cmu.edu> <06d401c9cdf4$09c79980$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu, draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 02:53:14 -0000 --On Tuesday, May 05, 2009 10:40:36 PM -0400 David Harrington wrote: > A Transport Model cannot require a specific security model. That would > violate the RFC3411 modularity. The WG discussed this at length. No. A transport model cannot work with only one security model; _that_ would violate modularity. A transport model specification certainly can require that implementations also implement a particular security model, particularly when not doing so would both be silly and result in poor interoperability. I see no modularity problem in saying "if you implement SSHTM, you must also implement TSM". -- Jeff From d.b.nelson@comcast.net Tue May 5 20:13:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78C23A6D9E for ; Tue, 5 May 2009 20:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LLlGFlL10DR for ; Tue, 5 May 2009 20:13:24 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 2397E3A6872 for ; Tue, 5 May 2009 20:13:24 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id o32s1b0020mlR8UAE3Es3X; Wed, 06 May 2009 03:14:52 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id o3En1b0084H2mdz8X3EpBy; Wed, 06 May 2009 03:14:51 +0000 From: "Dave Nelson" To: "'David Harrington'" , "'Jeffrey Hutzelman'" , "'Alexey Melnikov'" , References: <20090502131054.256133A6C75@core3.amsl.com><200905052204.n45M4sve002429@mx02.srv.cs.cmu.edu> <06d401c9cdf4$09c79980$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 23:15:02 -0400 Message-ID: <80644307791C44F6AE9CD6A8DAFCBD94@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <06d401c9cdf4$09c79980$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnN4wh2bG/GsTZ+TGGBXCpr+wES8QAEMzZQAADjKQA= Cc: draft-ietf-isms-tmsm@tools.ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 03:13:25 -0000 David Harrington writes... > A Transport Model cannot require a specific security model. That > would violate the RFC3411 modularity. Well, yes it would. OTOH, the RFC3411 architecture never envisioned that the actual security function of any security model would be "outsourced" to a transport model. In order to work correctly, the SSHTM and the TSM are wedded. You could devise another secure transport model that would work with TSM, but you cannot effectively (securely) use TSM with a non-secure transport model, nor use SSHTM with secure-transport-unaware security model, such as USM. That was the architectural tradeoff the WG was forced to accept in order to be able to support security at the transport layer rather than security integral to the SMNP protocol as the RFC3411 architecture assumes. There is some mix-and-match obtainable, but there is not complete independence. From d.b.nelson@comcast.net Tue May 5 21:46:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0E13A6A5D for ; Tue, 5 May 2009 21:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEEmBTaM9Yan for ; Tue, 5 May 2009 21:46:38 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id E5A9C3A69CF for ; Tue, 5 May 2009 21:45:39 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id o0l31b00816AWCUA44n76R; Wed, 06 May 2009 04:47:07 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id o4n61b0034H2mdz8S4n6GU; Wed, 06 May 2009 04:47:07 +0000 From: "Dave Nelson" To: Date: Wed, 6 May 2009 00:47:20 -0400 Message-ID: <9588C3EE3AA64B8BB42B3046253E198C@NEWTON603> 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.5579 Thread-Index: AcnNpFiBbOOEmKygTYW03uT3GEz8wAAYUzVg Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 04:46:40 -0000 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Tuesday, May 05, 2009 1:13 PM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms- > chairs@tools.ietf.org > Subject: Review of draft-ietf-isms-radius-usage-05 > > $Id: draft-ietf-isms-radius-usage-05-rev.txt,v 1.1 2009/05/05 16:12:55 ekr > Exp $ > > This document is about the use of RADIUS servers with SNMP "transport > models" (security protocols such as SSH used with SNMP). As far as I > can tell, the idea is to explain how to outsource some of the > authorization decisions to RADIUS. > > I found this document extremely difficult to read. I realize that > the intended audience is for people with a lot of RADIUS and > SNMP experience, but despite some familiarity with them, I had > to work fairly hard to figure out what it was trying to say > and I'm still not sure. This document would benefit very greatly > from a diagram explaining how the authors think things are supposed > to work. > > My big question is how the user authentication decisions are > expected to be split between (e.g., SSH), and RADIUS. For > example: > > - If the user has a password, who checks it the RADIUS server > or the NAS? RADIUS certainly can do this. > - If the user is authenticating with SSH pubkey auth, who > checks that? > > These seem like important architectural issues but I'm not getting > them out of the document, and they should in particular > be in the security considerations. > > IMO, this document would benefit from a rewrite that makes it a > lot clearer to someone not enmeshed in the WG. > > S 2. > I don't understand what the difference is between service authorization > and access control in this context. > > S 2.3. > I don't get the SHOULDs here. If you're defining how code points are > set, why are these optional? From d.b.nelson@comcast.net Tue May 5 21:46:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5FA3A69CF for ; Tue, 5 May 2009 21:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAq3R6d7rXOv for ; Tue, 5 May 2009 21:46:40 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id F323328C180 for ; Tue, 5 May 2009 21:46:06 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id o0aY1b00T16AWCUAB4na3S; Wed, 06 May 2009 04:47:34 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id o4nZ1b0034H2mdz8S4naMc; Wed, 06 May 2009 04:47:34 +0000 From: "Dave Nelson" To: Date: Wed, 6 May 2009 00:47:48 -0400 Message-ID: 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.5579 Thread-Index: AcnNpFiBbOOEmKygTYW03uT3GEz8wAAVLHbgAAMuoZA= Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 04:46:41 -0000 > -----Original Message----- > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > Sent: Tuesday, May 05, 2009 11:45 PM > To: 'Eric Rescorla'; secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms- > chairs@tools.ietf.org > Subject: RE: Review of draft-ietf-isms-radius-usage-05 > > Eric Rescorla writes... > > > Subject: Review of draft-ietf-isms-radius-usage-05 > > Thanks for your review and comments. > > > IMO, this document would benefit from a rewrite that makes it a > > lot clearer to someone not enmeshed in the WG. > > Umm. OK. That's a bit disheartening to hear, but useful feedback. > > > As far as I can tell, the idea is to explain how to outsource > > some of the authorization decisions to RADIUS. > > Correct. > > > I found this document extremely difficult to read. I realize that > > the intended audience is for people with a lot of RADIUS and > > SNMP experience... > > That's true. Those are the intended audiences. Additional explanatory > material was added to give each group some background information. > > > ...but despite some familiarity with them, I had > > to work fairly hard to figure out what it was trying to say > > and I'm still not sure. This document would benefit very greatly > > from a diagram explaining how the authors think things are > > supposed to work. > > Diagrams can be useful. We can certainly think about what might be > helpful > in that regard. > > > My big question is how the user authentication decisions are > > expected to be split between (e.g., SSH), and RADIUS. For > > example: > > > > - If the user has a password, who checks it the RADIUS server > > or the NAS? RADIUS certainly can do this. > > The RADIUS server makes the authentication decision. If the credential is > a > password, as is the typical use case, the password is sent (hidden) in a > RADIUS Access-Request message. > > > - If the user is authenticating with SSH pubkey auth, who > > checks that? > > The SSH server, i.e. the NAS. SSH is used to create a protected transport > session (a tunnel, if you will) and the RADIUS credentials are obtained > from > the SSH server implementation in the NAS and used by the RADIUS client in > the NAS to authenticate the user with the RADIUS server. Of course, it > has > to be an authentication method that RADIUS supports, and SSH public key is > not one of those. > > > These seem like important architectural issues but I'm not getting > > them out of the document, and they should in particular > > be in the security considerations. > > I'll re-read the document with your questions in mind. Of course, as a > draft author and a RADIUS expert, I may have overlooked some unstated > assumptions. > > > S 2. > > I don't understand what the difference is between service authorization > > and access control in this context. > > Service Authorization means that the user is authorized to (a) manage the > NAS and (b) use SNMP in particular as the management mechanism. Access > Control Authorization relates to the SNMP Access Control Subsystem and > could > be thought of as analogous to access control lists or packet filters or > any > similar fine-granularity access control mechanism. > > > S 2.3. > > I don't get the SHOULDs here. If you're defining how code points are > > set, why are these optional? > > OK, let's look at each one of these: > > RADIUS servers compliant to this specification SHOULD use RADIUS > service provisioning attributes, as described herein, to specify > SNMP access over a secure transport. > > This one could arguably be a MUST. In fact, I tend to think it ought to > be > a MUST. > > The following RADIUS attributes SHOULD be used, as hint attributes > included in the Access-Request message to signal use of SNMP over > a secure transport (i.e. authPriv) to the RADIUS server: > > RADIUS documents have traditionally held that appropriate "hint" > attributes > are desirable in an Access-Request message, but that they are optional. > This preserves that tradition. I suppose this could be changed to MUST > without impacting interoperability with RADIUS servers, which are always > free to ignore such hints. From d.b.nelson@comcast.net Tue May 5 21:48:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564C93A6D71 for ; Tue, 5 May 2009 21:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SVDApGvJI0G for ; Tue, 5 May 2009 21:48:24 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 4C98C3A6D43 for ; Tue, 5 May 2009 21:48:24 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id o0ad1b00J17UAYkA44psTE; Wed, 06 May 2009 04:49:52 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id o4pq1b00K4H2mdz8Z4przS; Wed, 06 May 2009 04:49:52 +0000 From: "Dave Nelson" To: Date: Wed, 6 May 2009 00:50:05 -0400 Message-ID: <98810517A9AD42BA977476B179469260@NEWTON603> 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.5579 Thread-Index: AcnL7Q9xalkCzySnQIukKJJMoSkUbgCGQhgg Subject: [Isms] FW: COMMENT: draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 04:48:25 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > Alexey Melnikov > Sent: Sunday, May 03, 2009 8:44 AM > To: iesg@ietf.org > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms- > chairs@tools.ietf.org > Subject: [Isms] COMMENT: draft-ietf-isms-radius-usage > > Comment: > 2.3. SNMP Service Authorization > > [...] > > There are no combinations of RADIUS attributes that denote the > equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the > authentication of a user (i.e. a principal) as a prerequisite for > authorization. RADIUS can be used to to provide an "Authorize-Only" > > Extra "to". > > service, but only when the request contains a "cookie" from a > previous successful authentication with the same RADIUS server (i.e. > the RADIUS State Attribute). > > > 5. Security Considerations > > [...] > > The Message-Authenticator (80) attribute [RFC3579] SHOULD be used > with RADIUS messages that are described in this memo. > > Some explanation of why would be helpful here. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From d.b.nelson@comcast.net Tue May 5 21:52:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADCA3A6935 for ; Tue, 5 May 2009 21:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCtKruDsoKSz for ; Tue, 5 May 2009 21:52:16 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 5D4B13A67DF for ; Tue, 5 May 2009 21:52:16 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id o3gE1b0040lTkoCAF4tkkv; Wed, 06 May 2009 04:53:44 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id o4ti1b0094H2mdz8Q4tjCb; Wed, 06 May 2009 04:53:44 +0000 From: "Dave Nelson" To: Date: Wed, 6 May 2009 00:53:57 -0400 Message-ID: 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.5579 Thread-Index: AcnM2YlIMiaso27fQ4OwJJZr77/QXAApZhogACHgOwA= Subject: [Isms] FW: COMMENT: draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 04:52:17 -0000 > -----Original Message----- > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > Sent: Tuesday, May 05, 2009 8:54 AM > To: 'Adrian Farrel'; iesg@ietf.org > Cc: isms-chairs@tools.ietf.org; draft-ietf-isms-radius- > usage@tools.ietf.org > Subject: RE: COMMENT: draft-ietf-isms-radius-usage > > Adrian Farrel writes... > > > Subject: COMMENT: draft-ietf-isms-radius-usage > > > > Comment: > > Table 2 says > > 0 This attribute MUST NOT be present in a packet. > > 0+ Zero or more instances of this attribute MAY be present in > > a packet. > > 0-1 Zero or one instance of this attribute MAY be present in > > a packet. > > 1 Exactly one instance of this attribute MUST be present in > > a packet. > > * Only one of these atribute options SHOULD be included. > > > > But: > > - table 1 has no instance of 0+ > > - table 1 has no instance of 1 > > This table footnote is "standard boilerplate" for RADIUS documents. It is > traditionally included in its entirety even when not all of the elements > are > actually used in a particular document. It's like including RFC 2119 in > the > references even though not all of the keywords are actually used in the > document. I don't think this will confuse anyone familiar with RADIUS > RFCs. > On the other hand, customizing the footnote for brevity would not cause > any > problems. > > > - * seems to contradict 0-1 > > Once again, it is fairly common to indicate that one of a set of > alternative > attributes may be included in a RADIUS packet. It's also common to use a > footnote in the Table of Attribute to convey this information. There is > no > actual contradiction here. This could be expanded into a sentence (or > two) > for added clarity, but this usage is common to RADIUS documentation. From d.b.nelson@comcast.net Tue May 5 21:52:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81BD3A6935 for ; Tue, 5 May 2009 21:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f8Fg7j2CgEn for ; Tue, 5 May 2009 21:52:37 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id D9E553A68F2 for ; Tue, 5 May 2009 21:52:36 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id o0aZ1b0081HpZEsA64u4Bt; Wed, 06 May 2009 04:54:04 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id o4u31b0074H2mdz8a4u4tr; Wed, 06 May 2009 04:54:04 +0000 From: "Dave Nelson" To: Date: Wed, 6 May 2009 00:54:18 -0400 Message-ID: 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.5579 Thread-Index: AcnL7Q9xalkCzySnQIukKJJMoSkUbgBlBClwACFkEDA= Subject: [Isms] FW: COMMENT: draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 04:52:38 -0000 > -----Original Message----- > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > Sent: Tuesday, May 05, 2009 9:06 AM > To: 'Alexey Melnikov'; iesg@ietf.org > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms- > chairs@tools.ietf.org > Subject: RE: [Isms] COMMENT: draft-ietf-isms-radius-usage > > Alexey Melnikov writes... > > > Subject: [Isms] COMMENT: draft-ietf-isms-radius-usage > > > > Comment: > > 2.3. SNMP Service Authorization > > > > [...] > > > > There are no combinations of RADIUS attributes that denote the > > equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the > > authentication of a user (i.e. a principal) as a prerequisite for > > authorization. RADIUS can be used to to provide an "Authorize-Only" > > > > Extra "to". > > > > service, but only when the request contains a "cookie" from a > > previous successful authentication with the same RADIUS server (i.e. > > the RADIUS State Attribute). > > Right. > > > > > 5. Security Considerations > > > > [...] > > > > The Message-Authenticator (80) attribute [RFC3579] SHOULD be used > > with RADIUS messages that are described in this memo. > > > > Some explanation of why would be helpful here. > > It is useful because the Message-Authenticator Attribute is the best > available mechanism in RADIUS as it stands today to provide tamper-evident > integrity protection of the service provisioning attributes in an > Access-Accept packet. It is slightly less important for Access-Request > packets, although it may be desirable to protect any "hint" attributes > contained in those messages. This protection mitigates the fact that > RADIUS > messages are not encrypted and attributes could be added, deleted or > modified by an adversary in a position to intercept the packet. > > This is all pretty standard RADIUS Security Considerations material, and > could be shortened to a brief explanation for inclusion in this draft. From randy_presuhn@mindspring.com Tue May 5 23:34:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26DD3A6D99; Tue, 5 May 2009 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APd+vbDPfEl3; Tue, 5 May 2009 23:34:08 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A26FA28C2A2; Tue, 5 May 2009 23:33:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZCfDUSPI4y2lymIkeFzD/aKt/DGZr6iF2Y71N5UHfaCCQ/DoJ5hjJdEfFnj7Hdo4; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.233] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M1ai3-0007Hq-47; Wed, 06 May 2009 02:34:27 -0400 Message-ID: <005901c9ce15$1f2f5300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 23:37:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696816e54f1a9a3995a2d36e37862333af29350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.233 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] [secdir] secdirreview ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:34:08 -0000 Hi - > From: "David B Harrington" > To: "'Jeffrey Hutzelman'" ; "'Barry Leiba'" ; ; > Cc: ; ; > Sent: Tuesday, May 05, 2009 12:28 PM > Subject: Re: [Isms] [secdir] secdirreview ofdraft-ietf-isms-transport-security-model-12 ... > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? ... Sounds like what RFC 2026 calls an "Applicability Statement". Randy From j.schoenwaelder@jacobs-university.de Wed May 6 02:29:33 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D253A68E5; Wed, 6 May 2009 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGclpckzahzX; Wed, 6 May 2009 02:29:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7E0853A6BAD; Wed, 6 May 2009 02:29:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53C0AC0171; Wed, 6 May 2009 11:30:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cDvakrjxEPcC; Wed, 6 May 2009 11:30:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69EC4C0022; Wed, 6 May 2009 11:30:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 97034ADBF3D; Wed, 6 May 2009 11:30:21 +0200 (CEST) Date: Wed, 6 May 2009 11:30:21 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090506093021.GB21714@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David B Harrington , 'Barry Leiba' , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-isms-transport-security-model@tools.ietf.org" , "isms@ietf.org" , "isms-chairs@tools.ietf.org" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: David B Harrington , "isms@ietf.org" , "secdir@ietf.org" , "isms-chairs@tools.ietf.org" , "iesg@ietf.org" , 'Barry Leiba' , "draft-ietf-isms-transport-security-model@tools.ietf.org" Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:29:33 -0000 On Tue, May 05, 2009 at 09:42:05PM +0200, Jeffrey Hutzelman wrote: > --On Tuesday, May 05, 2009 03:28:34 PM -0400 David B Harrington > wrote: > > > OK, I'll change my answer. > > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > I don't know, but as I said, I don't think it would be inappropriate to > simply say TSM MUST be used with a secure transport, placing the onus on > implementors to prevent inappropriate combinations from being used. I think the only interesting case here is the sending of messages where a combination of TSM with say UDP/TCP leads to maybe surprising results. (Note that the existing EoPs take care of dropping incoming messages received by a non-secure transport model that does not provide an appropriate cache entry.) I believe changing to MUST is actually fine and it will be very implementation specific how one prevents a combination such as TSM with UDP - so having this not spelled out in the EoP seems to be fine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed May 6 04:55:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB4D3A6C84; Wed, 6 May 2009 04:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrgkQeuQQ8dU; Wed, 6 May 2009 04:54:55 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B477E3A6A29; Wed, 6 May 2009 04:54:52 -0700 (PDT) X-Trace: 210443367/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.215/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.215 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEACgYAUo+vBHX/2dsb2JhbACDKIsowVgHgjSBRgU X-IronPort-AV: E=Sophos;i="4.40,302,1238972400"; d="scan'208";a="210443367" X-IP-Direction: IN Received: from 1cust215.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.215]) by smtp.pipex.tiscali.co.uk with SMTP; 06 May 2009 12:56:15 +0100 Message-ID: <023e01c9ce39$383f4ca0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com><51C8991BA900436F99C3C9559C235900@NEWTON603> <046e01c9ca69$2d7be180$0600a8c0@china.huawei.com> Date: Wed, 6 May 2009 12:36:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: opsawg@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:55:02 -0000 From: "David Harrington" To: "'Dave Nelson'" ; Cc: Sent: Friday, May 01, 2009 4:29 PM > > > > Chartering for only that work will probably get it done faster, and > > > that will complete the initial vision of ISMS. > > > > This seems like a non sequitur. I don't see any serialization of work that > > would occur because of scarce resources. > > We only have about six active people in this WG, and they will be > involved in both activities. > If the AAA-AC becomes in any way dependent on the TLS/DTLS work, I > would hate to see the AAA delayed. > Maybe you are right. AAA-AC is in the AC subsystem, while TLS/DTLS is > in the transport subsystem. > Maybe the work will be orthogonal. > > > > > If both syslog over DTLS(TLS) and SNMP over DTLS(TLS) were done in > > > OPSAWG, there might be a greater chance of consistent DTLS(TLS) > > > security, and Wes's draft might be able to simply point to the TLS > > > security processing in the syslog over TLS Proposed > > Standard as well. > > > > That might be true. OTOH, is there any benefit in doing that > > work in a > > Security Area WG rather than an Operations & Management Area WG? > > As Pasi pointed out in the syslog/DTLS discussions, the DTLS processing > should be basically the same as the TLS processing. The dufferences are > generally minor at the secureity level. But the OPS-level applicability > and bindings can be substantially different. > > If you consider these as two different related pieces, much as SSHTM > and > the SSH processing are distinct, then it would seem to make sense to > me > to have the DTLS processing be done in the SEC area. Some of the work > is > really about understanding the applicability for different tasks. That > > was a major issue for SSTM, as we had to figure out whether > notification > originators should be clients or servers. That could get built into > the > SEC area standards and/or applicability statements for how to use > TLS/DTLS > for NM. > > Then the OPS area can deal with writing bindings between specific NM > protocols and the underlying, standardized DTLS and TLS layer > services. I agree that the priority should be with AAA-AC work (even though that holds little interest for me; Windows Active Directory anyone?) so that should be the focus of any rechartering. Including DTLS at this stage would be to take resources from AAA-AC and so delay it. (Resources is not something that isms WG is rich in:-) As and when DTLS is part of a charter, I think that it would be very wrong to include TLS. SSHTM has been the most troublesome part of the three I-Ds so far, and all the factors that make it so are present in full measure in DTLSTM. Recall that when Pasi pointed out that securityName alice with transportAddress bob@example.com:request produced a Response with securityName bob, it took five months and endless e-mails to resolve. And that is only the most recent of issues where what is in the documents is not what people assume the documents mean, each of which takes ages to resolve. We might finish DTLSTM in less than the four years it has taken us to progress sshtm but I cannot see it being straightforward. TLSTM is different, in many ways, not so much with the security aspects but in having sessions and in the SNMP considerations. Right now, I expect that it would be easier to do than DTLSTM just because of those sessions but putting the two together in one docuemnt would be ... madness (IMHO). Tom Petch > > > > > So draft consistency work has already been done; it has just > already > > > been done by individual editors rather than as a deliberate > SEC-area > > > and OPS-area approach. ISMS was originally started because > operators > > > want to be able to utilize their existing security systems > > rather than > > > having SNMP-specific and syslog-specific security > > infrastructures. By > > > making the TLS and DTLS layers consistent for NM interfaces, we > help > > > accomplish that goal. And if we separate the TLS/DTLS > > support from the > > > NM transport models, we can have the SEC area maintain the > security > > > protocol applicability, while OPS maintains the NM bindings. > > > > Certainly there is some benefit to operators in > > cross-protocol operational > > consistency. Of course I've found that obtaining that kind > > of consistency > > usually slows things down. Not that speed of completion is > > the only driving > > factor, of course. > > It could slow things down, BUT ... much of that work has already been > done > because the authors of the related documents (Wes, Linda, Rainer, Tom, > Badra), > have worked to be fairly consistent already. > > Each NM protocol community that needs secure transport has already > completed its work. > The remaining TLS and DTLS work is optional to handle less immediate > use cases. A > little delay for the sake of consistency can probably be accommodated > without problems. > > dbh > > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Wed May 6 05:23:23 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F183F3A70EA for ; Wed, 6 May 2009 05:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK8iuIyaEixt for ; Wed, 6 May 2009 05:23:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3DA493A71C9 for ; Wed, 6 May 2009 05:19:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ACCEC0007; Wed, 6 May 2009 14:21:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5V75SSsE7HKw; Wed, 6 May 2009 14:21:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FADDC0019; Wed, 6 May 2009 14:21:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A3A4BADC54C; Wed, 6 May 2009 14:20:45 +0200 (CEST) Date: Wed, 6 May 2009 14:20:45 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090506122045.GE21810@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] proposed charter text with change to add TLS X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:23:24 -0000 On Tue, May 05, 2009 at 12:26:19AM +0200, Wes Hardaker wrote: > Here's the charter text again with changes to simply add TLS in addition > to the DTLS work. [...] > Chair(s): > * Juergen Schoenwaelder This needs to be marked as TBD since I won't be able to continue charing ISMS as the only chair of this WG. (I might help as co-chair if there is a need but it is already pretty clear that I won't be able to attend the Hiroshima nor the Anaheim IETF and a chair not attending his WG meetings does not sound right.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed May 6 05:43:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DE93A6F1B; Wed, 6 May 2009 05:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGEXXvAjDDqd; Wed, 6 May 2009 05:43:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 98BF83A71EB; Wed, 6 May 2009 05:39:40 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7056C0003; Wed, 6 May 2009 14:41:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CzO9Xg7a3n6s; Wed, 6 May 2009 14:41:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3AE3C000C; Wed, 6 May 2009 14:41:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43BB4ADC5C7; Wed, 6 May 2009 14:40:41 +0200 (CEST) Date: Wed, 6 May 2009 14:40:41 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090506124041.GF21810@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , "isms@ietf.org" , "opsawg@ietf.org" References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> <51C8991BA900436F99C3C9559C235900@NEWTON603> <046e01c9ca69$2d7be180$0600a8c0@china.huawei.com> <023e01c9ce39$383f4ca0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023e01c9ce39$383f4ca0$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:43:58 -0000 On Wed, May 06, 2009 at 12:36:18PM +0200, tom.petch wrote: > I agree that the priority should be with AAA-AC work (even though > that holds little interest for me; Windows Active Directory anyone?) > so that should be the focus of any rechartering. Including DTLS at > this stage would be to take resources from AAA-AC and so delay > it. (Resources is not something that isms WG is rich in:-) Yes, I am concerned about the lack of resources. On the other hand, the RADIUS AAA work is very different from the [D]TLS transport work and we have a non-overlapping set of document editors. How much work is needed on the AAA document would for me be easier to judge if there would actually be a draft I could look at. > As and when DTLS is part of a charter, I think that it would be very > wrong to include TLS. SSHTM has been the most troublesome part of > the three I-Ds so far, and all the factors that make it so are > present in full measure in DTLSTM. Recall that when Pasi pointed > out that securityName alice with transportAddress > bob@example.com:request produced a Response with securityName bob, > it took five months and endless e-mails to resolve. And that is > only the most recent of issues where what is in the documents is not > what people assume the documents mean, each of which takes ages to > resolve. We might finish DTLSTM in less than the four years it has > taken us to progress sshtm but I cannot see it being > straightforward. > > TLSTM is different, in many ways, not so much with the security > aspects but in having sessions and in the SNMP considerations. Right > now, I expect that it would be easier to do than DTLSTM just because > of those sessions but putting the two together in one docuemnt would > be ... madness (IMHO). As far as I understand TLS and DTLS, both protocols are pretty similar in the way they authenticate principals, so I am not sure I share your concerns (speaking as a technical contributor). How we deal with [D]TLS certificates and map them to securityNames will be rather common between TLS and DTLS based transports. The proposed charter text posted by Wes does not state whether this is going to be one or two documents; perhaps the best thing is to wait until there is a concrete proposal on the table and then take an informed decision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed May 6 05:46:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5658A28C2E9 for ; Wed, 6 May 2009 05:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgI+orX7Ie75 for ; Wed, 6 May 2009 05:46:30 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 2D7F228C211 for ; Wed, 6 May 2009 05:42:42 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA09.westchester.pa.mail.comcast.net with comcast id oAqG1b0040mv7h059CkALA; Wed, 06 May 2009 12:44:10 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id oCk91b00W0UQ6dC3XCk9dF; Wed, 06 May 2009 12:44:10 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: Date: Wed, 6 May 2009 08:44:08 -0400 Message-ID: <070c01c9ce48$59920a00$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 Thread-Index: AcnNpFiBbOOEmKygTYW03uT3GEz8wAAVLHbgAAMuoZAAEJAVkA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] FW: Review of draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:46:37 -0000 Hi, The term access control as used in AAA and as used in SNMP has always been a problem. The MIB boilerplate always discusses that the MIB is a virtual database. To help clarify the distinctiojnj when doiscussing SNMP and AAA together, I recommend referring to SNMP access control as "database access control" or "MIB database access control". dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, May 06, 2009 12:48 AM > To: isms@ietf.org > Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05 > > > -----Original Message----- > > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > > Sent: Tuesday, May 05, 2009 11:45 PM > > To: 'Eric Rescorla'; secdir@ietf.org; iesg@ietf.org > > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms- > > chairs@tools.ietf.org > > Subject: RE: Review of draft-ietf-isms-radius-usage-05 > > > > Eric Rescorla writes... > > > > > Subject: Review of draft-ietf-isms-radius-usage-05 > > > > Thanks for your review and comments. > > > > > IMO, this document would benefit from a rewrite that makes it a > > > lot clearer to someone not enmeshed in the WG. > > > > Umm. OK. That's a bit disheartening to hear, but useful feedback. > > > > > As far as I can tell, the idea is to explain how to outsource > > > some of the authorization decisions to RADIUS. > > > > Correct. > > > > > I found this document extremely difficult to read. I realize that > > > the intended audience is for people with a lot of RADIUS and > > > SNMP experience... > > > > That's true. Those are the intended audiences. Additional > explanatory > > material was added to give each group some background information. > > > > > ...but despite some familiarity with them, I had > > > to work fairly hard to figure out what it was trying to say > > > and I'm still not sure. This document would benefit very greatly > > > from a diagram explaining how the authors think things are > > > supposed to work. > > > > Diagrams can be useful. We can certainly think about what might be > > helpful > > in that regard. > > > > > My big question is how the user authentication decisions are > > > expected to be split between (e.g., SSH), and RADIUS. For > > > example: > > > > > > - If the user has a password, who checks it the RADIUS server > > > or the NAS? RADIUS certainly can do this. > > > > The RADIUS server makes the authentication decision. If > the credential is > > a > > password, as is the typical use case, the password is sent > (hidden) in a > > RADIUS Access-Request message. > > > > > - If the user is authenticating with SSH pubkey auth, who > > > checks that? > > > > The SSH server, i.e. the NAS. SSH is used to create a > protected transport > > session (a tunnel, if you will) and the RADIUS credentials > are obtained > > from > > the SSH server implementation in the NAS and used by the > RADIUS client in > > the NAS to authenticate the user with the RADIUS server. > Of course, it > > has > > to be an authentication method that RADIUS supports, and > SSH public key is > > not one of those. > > > > > These seem like important architectural issues but I'm not getting > > > them out of the document, and they should in particular > > > be in the security considerations. > > > > I'll re-read the document with your questions in mind. Of > course, as a > > draft author and a RADIUS expert, I may have overlooked > some unstated > > assumptions. > > > > > S 2. > > > I don't understand what the difference is between service > authorization > > > and access control in this context. > > > > Service Authorization means that the user is authorized to > (a) manage the > > NAS and (b) use SNMP in particular as the management > mechanism. Access > > Control Authorization relates to the SNMP Access Control > Subsystem and > > could > > be thought of as analogous to access control lists or > packet filters or > > any > > similar fine-granularity access control mechanism. > > > > > S 2.3. > > > I don't get the SHOULDs here. If you're defining how code > points are > > > set, why are these optional? > > > > OK, let's look at each one of these: > > > > RADIUS servers compliant to this specification SHOULD use RADIUS > > service provisioning attributes, as described herein, to specify > > SNMP access over a secure transport. > > > > This one could arguably be a MUST. In fact, I tend to > think it ought to > > be > > a MUST. > > > > The following RADIUS attributes SHOULD be used, as hint > attributes > > included in the Access-Request message to signal use of SNMP over > > a secure transport (i.e. authPriv) to the RADIUS server: > > > > RADIUS documents have traditionally held that appropriate "hint" > > attributes > > are desirable in an Access-Request message, but that they > are optional. > > This preserves that tradition. I suppose this could be > changed to MUST > > without impacting interoperability with RADIUS servers, > which are always > > free to ignore such hints. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Wed May 6 06:37:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CCD3A685C; Wed, 6 May 2009 06:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7T3Q4HGjIdm; Wed, 6 May 2009 06:37:04 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D21B63A6EED; Wed, 6 May 2009 06:34:56 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 323E439A0EA; Wed, 6 May 2009 06:36:24 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <045f01c9ca59$0d2b4750$0600a8c0@china.huawei.com> <51C8991BA900436F99C3C9559C235900@NEWTON603> <046e01c9ca69$2d7be180$0600a8c0@china.huawei.com> <023e01c9ce39$383f4ca0$0601a8c0@allison> <20090506124041.GF21810@elstar.local> Date: Wed, 06 May 2009 06:36:24 -0700 In-Reply-To: <20090506124041.GF21810@elstar.local> (Juergen Schoenwaelder's message of "Wed, 6 May 2009 14:40:41 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "opsawg@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] [OPSAWG] IsmsLatest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:37:05 -0000 >>>>> On Wed, 6 May 2009 14:40:41 +0200, Juergen Schoenwaelder said: JS> The proposed charter text posted by Wes does not state whether this is JS> going to be one or two documents; perhaps the best thing is to wait JS> until there is a concrete proposal on the table and then take an JS> informed decision. I did envision one, since that's what most people wanted *if* it could be done cleanly, which I think it can (though since I haven't done it yet, I reserve the right to change my mind later). I'll start immediately working on it after the decision by the WG is made that I should be working on it in the first place. FYI, the current DTLS draft already has two sub-transports: UDP and SCTP. It was not that difficult to add SCTP to the wording. In fact SCTP is closer to real TLS from a usage point of view since it's stream based [it also happens to be message based too]. The biggest difference between the wording between the UDP and SCTP components was how streaming affects things [in quick summary: without streaming you have to manually figure out the session id for the incoming packet]. Thus, in summary, I don't expect the TLS work to be hard at all. The bigger issue will be the careful search and replace and making sure the wording works everywhere. I don't think technical aspects will be difficult at all. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed May 6 06:38:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673453A6AE3 for ; Wed, 6 May 2009 06:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3vSI1z6sm9G for ; Wed, 6 May 2009 06:38:20 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id EA8193A6D46 for ; Wed, 6 May 2009 06:36:34 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6DDB539A0EA; Wed, 6 May 2009 06:38:02 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090506122045.GE21810@elstar.local> Date: Wed, 06 May 2009 06:38:02 -0700 In-Reply-To: <20090506122045.GE21810@elstar.local> (Juergen Schoenwaelder's message of "Wed, 6 May 2009 14:20:45 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] proposed charter text with change to add TLS X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:38:21 -0000 >>>>> On Wed, 6 May 2009 14:20:45 +0200, Juergen Schoenwaelder said: JS> This needs to be marked as TBD since I won't be able to continue JS> charing ISMS as the only chair of this WG. (I might help as co-chair JS> if there is a need but it is already pretty clear that I won't be JS> able to attend the Hiroshima nor the Anaheim IETF and a chair not JS> attending his WG meetings does not sound right.) The chairs listed in the charter are not really subject to WG charter text discussions; it's there more to show how it would look. But I understand your point and appreciate the work you've done to date. I'm confident we can find at least a co-chair fortunately. -- Wes Hardaker Cobham Analytic Solutions From d.b.nelson@comcast.net Wed May 6 06:54:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD873A6CF1 for ; Wed, 6 May 2009 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5vqDCtFnxre for ; Wed, 6 May 2009 06:54:20 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 7A1A83A6AE3 for ; Wed, 6 May 2009 06:53:49 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id oC5q1b0070cQ2SLA1DvHgT; Wed, 06 May 2009 13:55:17 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id oDvF1b00A4H2mdz8WDvGKY; Wed, 06 May 2009 13:55:17 +0000 From: "Dave Nelson" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'TSV Dir'" , References: <3D3C75174CB95F42AD6BCC56E5555B450152E317@FIESEXC015.nsn-intra.net> Date: Wed, 6 May 2009 09:55:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450152E317@FIESEXC015.nsn-intra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnOP1GZ58ZKQ0gJR9qUpHPBb5fcjAADduXA Cc: ietf@ietf.org, isms@ietf.org Subject: Re: [Isms] Transport directorate review of draft-ietf-isms-radius-usage-06 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:54:27 -0000 Hannes Tschofenig writes... > Subject: Transport directorate review of draft-ietf-isms-radius-usage-06 > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. Thanks for your review and your comments. > Since I am familiar with the work on RADIUS I had already a clue about > the direction the document when I read the title. Still, a diagram would > help with the basic idea. In some sense your document is based on a > fairly obvious idea, namely to use the RADIUS backend infrastructure to > relay authentication and authorization for SSH. So, a figure like this > one could help: > > +--------+ > |RADIUS | > |Server | > +--------+ > ^ > RADIUS + | Back-End > Management-Transport-Protection | Protocol > Framed-Management-Protocol | Support > | > v > +---------+ +---------------+ > | Admin's | SNMP |RADIUS Client /| > | Device |<-------------------->|Network Device | > +---------+ SSH +---------------+ Another reviewer indicated that a diagram would have been helpful to him, so we should probably consider adding one. > Regarding the following statement: > > The RADIUS protocol [RFC2865] provides authentication and > authorization services for network access devices, usually referred > to as a Network Access Server (NAS). > > This is not the only usage of RADIUS. See, for example, > http://www.ietf.org/rfc/rfc5090.txt > > The interesting thing is that you are defining a RADIUS usage that is > conceptually extremely close to RFC 5090. My reading of RFC 5090 was that is adds another authentication method to RADIUS. I guess I'm missing the part where it changes the basic RADIUS model. :-) > Section 1.2 provides an overview of RADIUS. However, I don't think it is > appropriate to use RFC 2119 language in that section. Hmmm. I fear getting the reverse comment if we de-capitalize the keywords. > You write: > > RADIUS almost always involves user authentication as > prerequisite to authorization, and there is a user authentication > phase for each of these two use cases. > > Since you mention authorize only later you could refer to this aspect as > well. > The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt allows > you todo authorization without running the authentication exchange even > though you bind the authorization step to a previously done > authentication exchange. We may end up using a two-step process involving "Authorize Only" when we take up the VACM-related work. There is no reason to mention such a mechanism in the scope of this document, however. > The following RADIUS attributes SHOULD be used, as hint attributes > included in the Access-Request message to signal use of SNMP over a > secure transport (i.e. authPriv) to the RADIUS server: > > Why don't you use a MUST here? The reason is that "hint" attributes are traditionally optional. > In the previous section you describe how > important it is for the AAA server to figure this information out and > here you have a SHOULD and do not explain what happens otherwise if > this information is not sent. Another reviewer mentioned this same point. We could consider making this a MUST, without unduly impacting interoperability with existing RADIUS servers as servers are always free to ignore such hints. > The following RADIUS attributes are used in an Access-Accept message > to provision SNMP over a secure transport which provides both > integrity and confidentiality (i.e. authPriv): > > I suspect that this should read as > " > The following RADIUS attributes MUST be used in an Access-Accept > message to provision SNMP over a secure transport which provides > both integrity and confidentiality (i.e. SNMP authPriv): > " I'm not sure that a keyword is required here, but if one were to be required is would be MUST. > In Table 2 I was only expecting to see the newly introduced RADIUS > attributes rather than the attributes that come via the base RADIUS > RFC. I wouldn't do that. I'm following the precedent of RFC 3580 which defines RADIUS usage for Layer 2 access control (IEEE 801.1X). > You excluded accounting from the document and I was wondering whether > logging isn't a useful feature (or event required) to ensure > accountability when it comes to the management of network equipment. Well, there was no discussion in the ISMS WG that accounting was an operator requirement. I agree there is a case to be made for it, but in some sense the work of ISMS is in response to operator's perceptions of deployment impediments with SNMPv3. We are out to alleviate those impediments. > If you look at > http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori > zation-06.txt then you will notice that they allow accounting messages > to carry these new attributes. Btw, the authors of > http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori > zation-06.txt also allow CoA to be used even though I cannot really say > whether this is useful in the context of a SNMP. The ISMS WG saw no use case for SNMP. > Withdrawing access > right for a person that is logged into an administrative interface, as > it can be done with CoA, does not sound too far fetched to me. Another > example is the need for re-authentication after a certain time period. Session timeouts are supported in the document. > http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori > zation-06.txt defines 4 new RADIUS attributes, namely > - Framed-Management-Protocol > - Management-Transport-Protection > - Management-Policy-Id > - Management-Privilege-Level > > You don't make use of the last two. Is there a specific reason? Yes, because they are not needed to solve the problem this draft addresses. If the currently proposed re-chartering is approved in the ISMS WG, then one of these, the Management-Policy-Id, will likely be used to provision an extension to VACM. The last one is defined to apply to CLI only, so would never be of interest in SNMP work. > In your document you only focus on RADIUS whereas the document that > defines the attributes, namely > http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori > zation-06.txt, also defines them for Diameter. Any reason why you did > not extend your description also to Diameter? Maybe because Diameter is > not used in your envisioned usage domain or so? Right. The ISMS WG was formed to address impediments operators perceived in the "ease of deployment" of SNMPv3. The goals were to apply mechanisms and infrastructure that the operators were already using. This drove choices such as SSH and RADIUS. > Regarding the security considerations: The interworking between RADIUS > and SSH for authentication and authorization does not really allow > "high-quality" authentication mechanisms to be used. In the document > itself you state that mostly username/password is going to be utilized > and hence I believe that the solution is not secure outside a single > adminstrative domain. Hence, I would spell this out in the security > consideration section instead of referring to AAA roaming, particularly > RFC 2607. Could you elaborate? We all know that RADIUS has outdated security mechanisms, but what specifically about usage with SSH causes additional concerns? > Regarding the usage of the Message authentication in RADIUS. I suggest > to copy-and-paste the following paragraph from > http://tools.ietf.org/html/draft-ietf-radext-design-07 > and modify it slightly: > > " > Message authentication in RADIUS is provided largely via the Message- > Authenticator attribute. See [RFC3579] Section 3.2, and also > [RFC5080] 2.2.2. Unfortunately, the Message-Authenticator attribute > does not provide confidentiality protection. We had something longer, but it was shortened to the current form to resolve WGLC comments. :-) Another commented asked for an explanation of why this recommendation was being made, and the following answer was given. It is useful because the Message-Authenticator Attribute is the best available mechanism in RADIUS as it stands today to provide tamper-evident integrity protection of the service provisioning attributes in an Access-Accept packet. It is slightly less important for Access-Request packets, although it may be desirable to protect any "hint" attributes contained in those messages. This protection mitigates the fact that RADIUS messages are not encrypted and attributes could be added, deleted or modified by an adversary in a position to intercept the packet. This is all pretty standard RADIUS Security Considerations material, and could be shortened to a brief explanation for inclusion in this draft. > To avoid eavesdropping of RADIUS message exchanges a secure > communications protocol, such as > IPsec or TLS (with RadSec > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-04.txt) > MUST be used. See [RFC3579] Section 4, and [RFC3580] Section 5 for a > more in-depth explanation of these issues. > " Well, yes. I'm not sure how far to go here. The idea was to use the operators' existing RADIUS infrastructure. Yes, new firmware will be required in the NASes, but the attributes used in this document can be added to the data dictionary of a data dictionary driven RADIUS sever without any change to the server software. > If you add RadSec as a normative references your document will > unfortunately be blocked a little bit (until RadSec is completed) and > you will have to repeat the IETF Last Call since RadSec will have to be > indicated as a DownRef in the LC. I don't think that would serve the goals of the ISMS WG. > IPsec on the other hand can be used without any problems (and is used > today a lot for protection of RADIUS). Yes, but is it used in the deployment scenarios this work is targeting? From j.schoenwaelder@jacobs-university.de Wed May 6 07:06:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0583A6A9E; Wed, 6 May 2009 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugmaNib+x2LF; Wed, 6 May 2009 07:06:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3B1EB3A6EF9; Wed, 6 May 2009 07:06:00 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FF85C0178; Wed, 6 May 2009 16:07:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9eLd6KXOz-Mj; Wed, 6 May 2009 16:07:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37005C0019; Wed, 6 May 2009 16:07:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7BD41ADC9A4; Wed, 6 May 2009 16:07:01 +0200 (CEST) Date: Wed, 6 May 2009 16:07:01 +0200 From: Juergen Schoenwaelder To: Alexey Melnikov Message-ID: <20090506140701.GD22610@elstar.local> Mail-Followup-To: Alexey Melnikov , David Harrington , "iesg@ietf.org" , "draft-ietf-isms-secshell@tools.ietf.org" , "isms-chairs@tools.ietf.org" , "isms@ietf.org" References: <20090503113302.C3E693A6A35@core3.amsl.com> <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> <4A015F19.4040106@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A015F19.4040106@isode.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "draft-ietf-isms-secshell@tools.ietf.org" , "iesg@ietf.org" , "isms-chairs@tools.ietf.org" , "isms@ietf.org" Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:06:55 -0000 On Wed, May 06, 2009 at 11:57:45AM +0200, Alexey Melnikov wrote: > >> 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 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. > >> > >>I am wondering why 2 "should"s are not SHOULDs or even MUSTs. > >> > >> > >two reasons. > >1) cut and paste from SNMPv3 standard documents. > >2) the shoulds refer to implementation-specific processing that > >happens strictly inside the SNMP entity, not on the wire. > > > > > I think this has implications on interoperability, so I am not entirely > convinced by your point # 2. > Maybe you can give me an example of when it would be Ok not to discard > such state? I do not see any interoperability issues; this text is really just a hint that it is a good idea to release message specific state when the message gets discarded. But protocol wise, an implementation would not break anything if it would never release any message specific state information (but such an implementation might run out of memory of course and be an easy target for a DoS attack). Since this same wording has worked in other SNMPv3 specifications (i.e., RFC3412 and RFC3414, both part of STD62), I am not sure this needs any changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Hannes.Tschofenig@gmx.net Wed May 6 08:36:22 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8FB3A6F4B for ; Wed, 6 May 2009 08:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1cjTIyx+nuq for ; Wed, 6 May 2009 08:36:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7073D28C191 for ; Wed, 6 May 2009 08:33:52 -0700 (PDT) Received: (qmail invoked by alias); 06 May 2009 15:28:39 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 06 May 2009 17:28:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IWrBX8t2IAlviHIr1PJa1+F6mWayn167QiPR955 4q5PC85teaHu++ From: "Hannes Tschofenig" To: "'Dave Nelson'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'TSV Dir'" , References: <3D3C75174CB95F42AD6BCC56E5555B450152E317@FIESEXC015.nsn-intra.net> Date: Wed, 6 May 2009 18:30:17 +0300 Message-ID: <018501c9ce5f$8fd8e0e0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnOP1GZ58ZKQ0gJR9qUpHPBb5fcjAADduXAAAHX15A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: ietf@ietf.org, isms@ietf.org Subject: Re: [Isms] [tsv-dir] Transport directorate review ofdraft-ietf-isms-radius-usage-06 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 15:36:22 -0000 Hi Dave, Thanks for your extremly quick response. See my response below. >-----Original Message----- >From: tsv-dir-bounces@ietf.org >[mailto:tsv-dir-bounces@ietf.org] On Behalf Of Dave Nelson >Sent: 06 May, 2009 16:56 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'TSV Dir'; >kaushik_narayan@yahoo.com >Cc: ietf@ietf.org; isms@ietf.org >Subject: Re: [tsv-dir] Transport directorate review >ofdraft-ietf-isms-radius-usage-06 > >Hannes Tschofenig writes... > >> Subject: Transport directorate review of >> draft-ietf-isms-radius-usage-06 >> >> I've reviewed this document as part of the transport area >> directorate's ongoing effort to review key IETF documents. > >Thanks for your review and your comments. > >> Since I am familiar with the work on RADIUS I had already a >clue about >> the direction the document when I read the title. Still, a diagram >> would help with the basic idea. In some sense your document is based >> on a fairly obvious idea, namely to use the RADIUS backend >> infrastructure to relay authentication and authorization for >SSH. So, >> a figure like this one could help: >> >> +--------+ >> |RADIUS | >> |Server | >> +--------+ >> ^ >> RADIUS + | Back-End >> Management-Transport-Protection | Protocol >> Framed-Management-Protocol | Support >> | >> v >> +---------+ +---------------+ >> | Admin's | SNMP |RADIUS Client /| >> | Device |<-------------------->|Network Device | >> +---------+ SSH +---------------+ > >Another reviewer indicated that a diagram would have been >helpful to him, so we should probably consider adding one. OK. > >> Regarding the following statement: >> >> The RADIUS protocol [RFC2865] provides authentication and >> authorization services for network access devices, >usually referred >> to as a Network Access Server (NAS). >> >> This is not the only usage of RADIUS. See, for example, >> http://www.ietf.org/rfc/rfc5090.txt >> >> The interesting thing is that you are defining a RADIUS >usage that is >> conceptually extremely close to RFC 5090. > >My reading of RFC 5090 was that is adds another authentication >method to RADIUS. I guess I'm missing the part where it >changes the basic RADIUS model. :-) It adds an authentication mechanism as well. The important part, however, is that it uses RADIUS for an application layer protocol (HTTP and SIP) rather than for network access. You are essentially doing the same (just for a different protocol). > >> Section 1.2 provides an overview of RADIUS. However, I don't >think it >> is appropriate to use RFC 2119 language in that section. > >Hmmm. I fear getting the reverse comment if we de-capitalize >the keywords. Might be. > >> You write: >> >> RADIUS almost always involves user authentication as >> prerequisite to authorization, and there is a user authentication >> phase for each of these two use cases. >> >> Since you mention authorize only later you could refer to >this aspect >> as well. >> The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt >> allows you todo authorization without running the authentication >> exchange even though you bind the authorization step to a previously >> done authentication exchange. > >We may end up using a two-step process involving "Authorize >Only" when we take up the VACM-related work. There is no >reason to mention such a mechanism in the scope of this >document, however. OK. I don't know the background of your work. > >> The following RADIUS attributes SHOULD be used, as hint attributes >> included in the Access-Request message to signal use of >SNMP over a >> secure transport (i.e. authPriv) to the RADIUS server: >> >> Why don't you use a MUST here? > >The reason is that "hint" attributes are traditionally optional. > >> In the previous section you describe how important it is for the AAA >> server to figure this information out and here you have a >SHOULD and >> do not explain what happens otherwise if this information is >not sent. > >Another reviewer mentioned this same point. We could consider >making this a MUST, without unduly impacting interoperability >with existing RADIUS servers as servers are always free to >ignore such hints. I don't think this will impact interoperability in any way. If you don't want to use a MUST then you might want to say what happens if these attributes are not provided and how the AAA server should react. > >> The following RADIUS attributes are used in an >Access-Accept message >> to provision SNMP over a secure transport which provides both >> integrity and confidentiality (i.e. authPriv): >> >> I suspect that this should read as >> " >> The following RADIUS attributes MUST be used in an Access-Accept >> message to provision SNMP over a secure transport which provides >> both integrity and confidentiality (i.e. SNMP authPriv): >> " > >I'm not sure that a keyword is required here, but if one were >to be required is would be MUST. When the AAA server made the decision that the authentication and authorization step was success then wouldn't you send these attributes. > >> In Table 2 I was only expecting to see the newly introduced RADIUS >> attributes rather than the attributes that come via the base RADIUS >> RFC. I wouldn't do that. > >I'm following the precedent of RFC 3580 which defines RADIUS >usage for Layer >2 access control (IEEE 801.1X). We should put these things in the RADIUS design guidelines on what one would write into these tables. The current table is incomplete as the RADIUS RFC puts more attributes in there. > >> You excluded accounting from the document and I was >wondering whether >> logging isn't a useful feature (or event required) to ensure >> accountability when it comes to the management of network equipment. > >Well, there was no discussion in the ISMS WG that accounting >was an operator requirement. I agree there is a case to be >made for it, but in some sense the work of ISMS is in response >to operator's perceptions of deployment impediments with >SNMPv3. We are out to alleviate those impediments. OK. > >> If you look at >> >http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho >> ri zation-06.txt then you will notice that they allow accounting >> messages to carry these new attributes. Btw, the authors of >> >http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho >> ri zation-06.txt also allow CoA to be used even though I >cannot really >> say whether this is useful in the context of a SNMP. > >The ISMS WG saw no use case for SNMP. OK. > >> Withdrawing access >> right for a person that is logged into an administrative >interface, as >> it can be done with CoA, does not sound too far fetched to >me. Another >> example is the need for re-authentication after a certain >time period. > >Session timeouts are supported in the document. > >> >http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho >> ri zation-06.txt defines 4 new RADIUS attributes, namely >> - Framed-Management-Protocol >> - Management-Transport-Protection >> - Management-Policy-Id >> - Management-Privilege-Level >> >> You don't make use of the last two. Is there a specific reason? > >Yes, because they are not needed to solve the problem this >draft addresses. >If the currently proposed re-chartering is approved in the >ISMS WG, then one of these, the Management-Policy-Id, will >likely be used to provision an extension to VACM. The last >one is defined to apply to CLI only, so would never be of >interest in SNMP work. > OK. >> In your document you only focus on RADIUS whereas the document that >> defines the attributes, namely >> >http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho >> ri zation-06.txt, also defines them for Diameter. Any reason why you >> did not extend your description also to Diameter? Maybe because >> Diameter is not used in your envisioned usage domain or so? > >Right. The ISMS WG was formed to address impediments >operators perceived in the "ease of deployment" of SNMPv3. >The goals were to apply mechanisms and infrastructure that the >operators were already using. This drove choices such as SSH >and RADIUS. OK. > >> Regarding the security considerations: The interworking >between RADIUS >> and SSH for authentication and authorization does not really allow >> "high-quality" authentication mechanisms to be used. In the document >> itself you state that mostly username/password is going to >be utilized >> and hence I believe that the solution is not secure outside a single >> adminstrative domain. Hence, I would spell this out in the security >> consideration section instead of referring to AAA roaming, >> particularly RFC 2607. > >Could you elaborate? We all know that RADIUS has outdated >security mechanisms, but what specifically about usage with >SSH causes additional concerns? I could imagin that administrators might not want their username / password to travel over the the AAA broker infrastructure when they are also allowed to configure network equipment. So, the security risk of exposure of credentials is more than just fraud. No problem with SSH as such. Maybe I see it more dramatic as it is. > >> Regarding the usage of the Message authentication in RADIUS. >I suggest >> to copy-and-paste the following paragraph from >> http://tools.ietf.org/html/draft-ietf-radext-design-07 >> and modify it slightly: >> >> " >> Message authentication in RADIUS is provided largely via >the Message- >> Authenticator attribute. See [RFC3579] Section 3.2, and also >> [RFC5080] 2.2.2. Unfortunately, the Message-Authenticator >attribute >> does not provide confidentiality protection. > >We had something longer, but it was shortened to the current >form to resolve WGLC comments. :-) Sorry. I know what you mean; I had many comments from Glen already :-) Another commented asked >for an explanation of why this recommendation was being made, >and the following answer was given. > >It is useful because the Message-Authenticator Attribute is >the best available mechanism in RADIUS as it stands today to >provide tamper-evident integrity protection of the service >provisioning attributes in an Access-Accept packet. It is >slightly less important for Access-Request packets, although >it may be desirable to protect any "hint" attributes contained >in those messages. This protection mitigates the fact that >RADIUS messages are not encrypted and attributes could be >added, deleted or modified by an adversary in a position to >intercept the packet. I know the Message-Authenticator. > >This is all pretty standard RADIUS Security Considerations >material, That's true. > and could be shortened to a brief explanation for >inclusion in this draft. I just thought that the text from the RADIUS Design Guidelines draft was quite good. With the background on all the key management work I thought it would be useful to mention the confidentiality protection. (I deleted the sentence that said that RADIUS security is quite bad.) > >> To avoid eavesdropping of RADIUS message exchanges a secure >> communications protocol, such as >> IPsec or TLS (with RadSec >> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-04.txt) >> MUST be used. See [RFC3579] Section 4, and [RFC3580] >Section 5 for a >> more in-depth explanation of these issues. >> " > >Well, yes. I'm not sure how far to go here. The idea was to >use the operators' existing RADIUS infrastructure. Yes, new >firmware will be required in the NASes, but the attributes >used in this document can be added to the data dictionary of a >data dictionary driven RADIUS sever without any change to the >server software. I think IPsec usage is fine if operators care about the security of their credentials. > >> If you add RadSec as a normative references your document will >> unfortunately be blocked a little bit (until RadSec is >completed) and >> you will have to repeat the IETF Last Call since RadSec will have to >> be indicated as a DownRef in the LC. > >I don't think that would serve the goals of the ISMS WG. Most likely not. > >> IPsec on the other hand can be used without any problems >(and is used >> today a lot for protection of RADIUS). > >Yes, but is it used in the deployment scenarios this work is targeting? You tell me. Whatever you write in this document the operators will use anyway whatever they want. Ciao Hannes > > From ietfdbh@comcast.net Wed May 6 10:07:46 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52843A7017 for ; Wed, 6 May 2009 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppLjiOpbAM9l for ; Wed, 6 May 2009 10:07:46 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id E70373A7074 for ; Wed, 6 May 2009 10:02:51 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA11.westchester.pa.mail.comcast.net with comcast id oA2j1b0030xGWP85BH4LsE; Wed, 06 May 2009 17:04:20 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id oH4K1b00G0UQ6dC3YH4Koh; Wed, 06 May 2009 17:04:19 +0000 From: "David Harrington" To: "'Alexey Melnikov'" , "'Juergen Schoenwaelder'" References: <20090503113302.C3E693A6A35@core3.amsl.com> <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> <4A015F19.4040106@isode.com> <20090506140701.GD22610@elstar.local> <4A01A338.1040203@isode.com> Date: Wed, 6 May 2009 13:04:18 -0400 Message-ID: <075a01c9ce6c$b1a39f50$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 Thread-Index: AcnOWcKoTx979gbYT1WGodpXblD9YQAEiJ7w X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4A01A338.1040203@isode.com> Cc: draft-ietf-isms-secshell@tools.ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:07:46 -0000 Hi, I think this is really about memory management. In SNMPv3 WG, we did not want to talk about getting rid of the cache everytime we suggested discarding a message (and for ISMS, closing sessions), so we put the advice about "releasing" the cache in one general statement. While memory management is an implementation detail, we wanted to assert that it was OK to release the memory at specific points, so implementers would know the related state information was no longer needed. The SNMPv3 standard uses the same text, and we have never, to my knowledge, had any implementer have problmes with implementing or with interoperability as a result of this text. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Wednesday, May 06, 2009 10:48 AM > To: Juergen Schoenwaelder > Cc: David Harrington; iesg@ietf.org; > draft-ietf-isms-secshell@tools.ietf.org; > isms-chairs@tools.ietf.org; isms@ietf.org > Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell > > Juergen Schoenwaelder wrote: > > >On Wed, May 06, 2009 at 11:57:45AM +0200, Alexey Melnikov wrote: > > > > > >>>> 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 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. > >>>> > >>>>I am wondering why 2 "should"s are not SHOULDs or even MUSTs. > >>>> > >>>> > >>>two reasons. > >>>1) cut and paste from SNMPv3 standard documents. > >>>2) the shoulds refer to implementation-specific processing that > >>>happens strictly inside the SNMP entity, not on the wire. > >>> > >>> > >>I think this has implications on interoperability, so I am > not entirely > >>convinced by your point # 2. > >>Maybe you can give me an example of when it would be Ok not > to discard > >>such state? > >> > >> > >I do not see any interoperability issues; this text is really just a > >hint that it is a good idea to release message specific > state when the > >message gets discarded. But protocol wise, an implementation > would not > >break anything if it would never release any message specific state > >information (but such an implementation might run out of memory of > >course and be an easy target for a DoS attack). > > > >Since this same wording has worked in other SNMPv3 specifications > >(i.e., RFC3412 and RFC3414, both part of STD62), I am not sure this > >needs any changes. > > > > > Juergen, > Your response makes me think that I don't really understand > what is the > meaning of "release" is in this case. > I understood "release" as "don't use this information again, it is > invalid". I wasn't thinking about "release" as an advice about memory > management. > Which one is it? > > Thanks, > Alexey > > From ietfdbh@comcast.net Wed May 6 13:14:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCAA3A6A58 for ; Wed, 6 May 2009 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94o6HhwNONUQ for ; Wed, 6 May 2009 13:14:20 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id DAA943A6D1A for ; Wed, 6 May 2009 13:14:19 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with comcast id oHb91b00B1HzFnQ57LFab1; Wed, 06 May 2009 20:15:34 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id oLFm1b0060UQ6dC3aLFmQr; Wed, 06 May 2009 20:15:47 +0000 From: "David Harrington" To: "'Alexey Melnikov'" References: <20090502131054.256133A6C75@core3.amsl.com> <06bc01c9cdcd$8195aeb0$0600a8c0@china.huawei.com> <4A01AA64.3000102@isode.com> Date: Wed, 6 May 2009 16:15:45 -0400 Message-ID: <078c01c9ce87$70b1ff30$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 Thread-Index: AcnOXgrJhJrPjiHFTbuKFbXHB9goUgADtF4Q X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4A01AA64.3000102@isode.com> Cc: iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] My DISCUSSes on draft-ietf-isms-* documents X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:14:20 -0000 Hi, Done dbh > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Wednesday, May 06, 2009 11:19 AM > To: David Harrington > Cc: iesg@ietf.org; isms-chairs@tools.ietf.org > Subject: My DISCUSSes on draft-ietf-isms-* documents > > David, > I am directing this message to you, as you were the most > active person > discussing my DISCUSSes and comments. You can co-ordinate with your > co-editors. > > Considering the amount of small changes to the documents, I > would like > to suggest that you post an updated version of your drafts before > tomorrows IESG telechat, so that I can either clear or at > least shorten > my DISCUSSes. > > Thanks, > Alexey > > From root@core3.amsl.com Wed May 6 13:15:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EDCFC3A6DF2; Wed, 6 May 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090506201501.EDCFC3A6DF2@core3.amsl.com> Date: Wed, 6 May 2009 13:15:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-18.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:15:02 -0000 --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-18.txt Pages : 36 Date : 2009-05-06 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 transports to include secure transports 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-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-isms-tmsm-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-06131054.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed May 6 13:15:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 064CB3A6E1F; Wed, 6 May 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090506201502.064CB3A6E1F@core3.amsl.com> Date: Wed, 6 May 2009 13:15:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-14.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:15:02 -0000 --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, W. Hardaker Filename : draft-ietf-isms-transport-security-model-14.txt Pages : 29 Date : 2009-05-06 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-isms-transport-security-model-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-06131108.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed May 6 13:15:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D2A428C0D0; Wed, 6 May 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090506201502.0D2A428C0D0@core3.amsl.com> Date: Wed, 6 May 2009 13:15:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-17.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-17.txt Pages : 38 Date : 2009-05-06 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-isms-secshell-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-06131121.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Tue May 5 10:33:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9924E3A6DD2; Tue, 5 May 2009 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhCuxZkniZgT; Tue, 5 May 2009 10:33:15 -0700 (PDT) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id 1B4153A71C1; Tue, 5 May 2009 10:32:29 -0700 (PDT) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ600G6UM4G0W@lhrga01-in.huawei.com>; Tue, 05 May 2009 18:33:52 +0100 (BST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ600J4CM4CMZ@lhrga01-in.huawei.com>; Tue, 05 May 2009 18:33:52 +0100 (BST) Date: Tue, 05 May 2009 18:33:33 +0100 From: Adrian Farrel To: David Harrington , iesg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090504134349.89A3F3A6FEB@core3.amsl.com> <068e01c9cda6$6d261f90$0600a8c0@china.huawei.com> X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:33:16 -0000 Cleared. There, that didn't hurt, did it? Adrian ----- Original Message ----- From: "David Harrington" To: "'Adrian Farrel'" ; Cc: ; ; Sent: Tuesday, May 05, 2009 6:25 PM Subject: RE: DISCUSS and COMMENT: draft-ietf-isms-transport-security-model > Hi, > > I am changing the sources with the requested changes. > comments inline > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian.farrel@huawei.com] >> Sent: Monday, May 04, 2009 9:44 AM >> To: iesg@ietf.org >> Cc: isms-chairs@tools.ietf.org; >> draft-ietf-isms-transport-security-model@tools.ietf.org >> Subject: DISCUSS and COMMENT: >> draft-ietf-isms-transport-security-model >> >> Discuss: >> I am not a MIB expert, but when I see counters I wonder about wraps >> and discontinuities. These seem not to be covered in this document >> and I would like to hear from a MIB expert that this is OK. > > I discussed this with some of the MIB Doctors. > These counters should behave in the normal manner, as defined in > rfc2578: > 7.1.6. Counter32 > > The Counter32 type represents a non-negative integer which > monotonically increases until it reaches a maximum value of 2^32-1 > (4294967295 decimal), when it wraps around and starts increasing > again from zero. > > Counters have no defined "initial" value, and thus, a single value > of > a Counter has (in general) no information content. Discontinuities > in the monotonically increasing value normally occur at re- > initialization of the management system, and at other times as > specified in the description of an object-type using this ASN.1 > type. > > There are no anticipated discontinuities other than re-initialization > of the management system. > This behavior is consistent with other SNMP-system counters, such as > those in the User-based Security Model. > >> >> Comment: >> Section 1.2 >> Helpful if s/STD62/STD62 [RFC3411]/ > > I deliberately did not provide a reference to a specific RFC. > STD62 refers to 8 RFCs. > The terminology under discussion in section 1.2 is not limited to > RFC3411. > I think it is correct to just reference STD62 in this case without a > citation. > >> >> Section 1.5 >> You seem to fluctuate in your usage of RFC 2119 language. >> In bullet 3, I suggest s/may not/might not/ > > I will search out instances of lowercase may/should/must and either > make them RFC2119 compliant or change the word. > >> >> Section 2.3.1 >> Notwithstanding the requirement to read the reference material, > please >> expand ASI on first use. > > done. >> >> Section 3.1.2 >> "REQUIRES" is not in the RFC 2119 lexicon. > > fixed. >> >> Section 3.1.3 >> "and other MIB modules" is a bit vague. > > Yes, but a complete list would be distracting, and a moving target. > >> >> Section 3.1.3 >> IANA maintains a registry for transport domains and the >> corresponding >> prefix. >> Would be helpful to include a pointer (perhaps by registry name, or > by >> defining RFC) to this registry. > > done. >> >> Section 7 >> Useful if FROM clauses can give a comment that shows the RFC that >> defines the module from which the import is taken. >> For example >> FROM SNMPv2-SMI -- RFC 2578 > > done >> >> > > From barryleiba@gmail.com Tue May 5 13:02:30 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABC33A67EA; Tue, 5 May 2009 13:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waff0qxjJ8YL; Tue, 5 May 2009 13:02:29 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E61E728C16E; Tue, 5 May 2009 13:02:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so5347919ewy.37 for ; Tue, 05 May 2009 13:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sv8oTgEQ8oMuiDWDkPQWplPFflqJ6w8ydcDEHTONgFw=; b=J/7+wVj1L+Onocd0Zc5KbKCizEEO5DmK8Eo8iUyjEckkECv54aMSW1qU3q4rB/4RGZ DSTxNwbtf4HjWyI5Xwis7e7lNcCddR0bUuPhyGDjd+KaNabt8tJtHa8AeX2CQx/OY+WA CbE2ujOUBeMQxQtUgXvFR5xUNKUuS34ku4Lzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BWbHu/a5dBvf2VYE2eKYD1436ydCCSqJcpN8cW6aqt/7S4SC8LDwviMLJUv2aoqK3k tgd9RYoOoz05cI8fBWhy4z7dlrF8ZnDme3YdyQ7NG84Zth74ov3jV0SEuH2YBqzmlIhQ LUSNUccrsFT1U8PMKAaeCacuxtv/B6fQh7faI= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.211.137.19 with SMTP id p19mr5023185ebn.69.1241553832236; Tue, 05 May 2009 13:03:52 -0700 (PDT) In-Reply-To: <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 16:03:52 -0400 X-Google-Sender-Auth: 8ab2eb4451dce772 Message-ID: <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> From: Barry Leiba To: David B Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:02:30 -0000 > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. > > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? Well, this would make me happy; would it work for you (and others)?: OLD: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it SHOULD always be used with a Transport Model that provides appropriate security. Which threats are addressed and how they are mitigated depends on the Transport Model. NEW: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it MUST always be used with a Transport Model that provides appropriate security. What is "appropriate" for a particular deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. Barry From glenzorn@comcast.net Wed May 6 01:16:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0323A6977 for ; Wed, 6 May 2009 01:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrhyxWqgs48N for ; Wed, 6 May 2009 01:16:37 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id B81E43A6DAD for ; Wed, 6 May 2009 01:15:51 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id o8EU1b0020EZKEL538H3xZ; Wed, 06 May 2009 08:17:03 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA01.westchester.pa.mail.comcast.net with comcast id o8Gd1b0070t0P5u3M8Ghlo; Wed, 06 May 2009 08:16:58 +0000 From: "Glen Zorn" To: "'David B Harrington'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com> In-Reply-To: <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com> Date: Wed, 6 May 2009 17:16:53 +0900 Message-ID: <011601c9ce23$10883930$3198ab90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNvYH7CDZJrmj2Tqm7iS1rwxNuTAAAYdyQABj7Q4A= Content-Language: en-us X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: secdir@ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 08:16:44 -0000 How about just losing the capitalization? > -----Original Message----- > From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On > Behalf Of David B Harrington > Sent: Wednesday, May 06, 2009 5:44 AM > To: 'Barry Leiba' > Cc: isms@ietf.org; iesg@ietf.org; isms-chairs@tools.ietf.org; > secdir@ietf.org > Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport- > security-model-12 > > Hi Barry, > > your formulation is "MUST ... use", where "use" is a deployment > decision, and MUST is inappropriate for deployment advice. > We currently use "SHOULD ... use", but Jeff thinks that in > inappropriate as well. > > How about: > by the RFC 3411 architecture. However, the Transport Security > Model > does not provide security mechanisms such as authentication and > encryption itself, so operators are advised to always use this > with a Transport Model > that provides appropriate security, where "appropriate" for a > particular > deployment is an administrative decision. Which threats are > addressed > and how they are mitigated depends on the Transport Model. > > dbh > > > -----Original Message----- > > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On > > Behalf Of Barry Leiba > > Sent: Tuesday, May 05, 2009 4:04 PM > > To: David B Harrington > > Cc: secdir@ietf.org; iesg@ietf.org; isms@ietf.org; > > isms-chairs@tools.ietf.org > > Subject: Re: [Isms] [secdir] secdir review > > ofdraft-ietf-isms-transport-security-model-12 > > > > > That is a deployment decision made by an administrator who has an > > > understanding of what is appropriate to the system in question. > > > > > > What is the correct non-RFC2119 phrase in which to couch our > > > deployment advice? > > > > Well, this would make me happy; would it work for you (and others)?: > > > > OLD: > > by the RFC 3411 architecture. However, the Transport > > Security Model > > does not provide security mechanisms such as authentication and > > encryption itself, so it SHOULD always be used with a > > Transport Model > > that provides appropriate security. Which threats are > > addressed and > > how they are mitigated depends on the Transport Model. > > > > NEW: > > by the RFC 3411 architecture. However, the Transport > > Security Model > > does not provide security mechanisms such as authentication and > > encryption itself, so it MUST always be used with a Transport > Model > > that provides appropriate security. What is "appropriate" > > for a particular > > deployment is an administrative decision. Which threats > > are addressed > > and how they are mitigated depends on the Transport Model. > > > > Barry > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From alexey.melnikov@isode.com Wed May 6 02:56:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66FC3A6A51; Wed, 6 May 2009 02:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL2I-EUq9hfn; Wed, 6 May 2009 02:56:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CAA503A6784; Wed, 6 May 2009 02:56:36 -0700 (PDT) Received: from [92.40.30.113] (92.40.30.113.sub.mbb.three.co.uk [92.40.30.113]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 10:58:01 +0100 Message-ID: <4A015F19.4040106@isode.com> Date: Wed, 06 May 2009 10:57:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: David Harrington References: <20090503113302.C3E693A6A35@core3.amsl.com> <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> In-Reply-To: <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: draft-ietf-isms-secshell@tools.ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:56:45 -0000 Hi David, My comments inline: David Harrington wrote: >>-----Original Message----- >>From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On >>Behalf Of Alexey Melnikov >>Sent: Sunday, May 03, 2009 7:33 AM >>To: iesg@ietf.org >>Cc: draft-ietf-isms-secshell@tools.ietf.org; >>isms-chairs@tools.ietf.org >>Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell >> >>Discuss: >>I have a couple minor related points here: >> >>5.3. Establishing a Session >> >> [...] >> >> 3. The client will then invoke an SSH authentication service to >> authenticate the principal, such as that described in the SSH >> authentication protocol [RFC4252]. >> >> 1. If the tmTransportAddress field contains a >>user-name followed >> by an '@' character (ASCII 0x40), that user-name >>string that >> should be presented to the ssh server as the "user >>name" for >> user authentication purposes. If there is no user-name in >> >> >> the tmTransportAddress then the tmSecurityName >>should be used >> as the user-name. >> >>I think this text needs to say which character set is used >>for representing user-name, and ideally it needs to describe or point >> >> >>to syntax of allowed usernames. >> >> > >Is this OK? > >"The user name must be encoded in UTF-8 (per RFC4252)." >with a citation to [RFC4252] in the text, >with a REFERENCE clause to "RFC4252, The Secure Shell (SSH) >Authentication Protocol" in the SnmpSSHAddress definition > > Yes, this would work. >[...] > > >>SnmpSSHAddress ::= TEXTUAL-CONVENTION >> >> >[...] > > >>Same comment as above: can you add a reference to the >>document defining syntax of the username? >> >> >yup. > > >> The hostname must be encoded in ASCII, as specified in >> RFC3490 (Internationalizing Domain Names in Applications) >> >>Same comment about syntax: I think a reference to the >>ABNF production from RFC 3986 would be appropriate here. >> >> > >We have a REFERENCE to RFC3986 already. >If you want something more specific, can you provided suggested text? > > See my corrections to your text, othetwise it looks fine. >I am a bit concerned about affecting readability with too many >references inside the DESCRIPTION clause. We have a REFERENCE clause. > >Is this OK? > >SnmpSSHAddress ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1a" > STATUS current > DESCRIPTION > "Represents either a hostname or IP address, along with a port > number and an optional user name. > > The beginning of the address specification may contain a > user name followed by an '@' (US-ASCII character 0x40). This > portion of the address will indicate the user name that >should > be used when authenticating to an SSH server. The user name > must be encoded in UTF-8 (per RFC4252). If missing, the > SNMP securityName should be used. After the optional user >name > field and '@' character comes the hostname or IP address. > > The hostname is always in US-ASCII (as per RFC3490), > > I was trying to hint at that, but RFC 3490 is not a good reference in this case: it defines both Internationalized domain names (in Unicode) and their US-ASCII encoding. I think RFC 1033 (Section "Names") would be a better reference, unless you know a newer one. So I suggest something like the following: The hostname is always in US-ASCII (as per 1033), Internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname ... > followed by a colon ':' (US-ASCII character 0x3A) and a > decimal port number in US-ASCII. The name SHOULD be fully > qualified whenever possible. > > An IPv4 address must be in dotted decimal format followed > by a colon ':' (US-ASCII character 0x3A) and a decimal port > number in US-ASCII. > > An IPv6 address must be in colon separated format, surrounded > by square brackets ('[' US-ASCII character 0x5B and ']' >US-ASCII > character 0x5D), followed by a colon ':' (US-ASCII character > 0x3A) and a decimal port number in US-ASCII. > > Values of this textual convention might not be directly useable > as transport-layer addressing information, and may require > runtime resolution. As such, applications that write them > must be prepared for handling errors if such values are > not supported, or cannot be resolved (if resolution occurs > at the time of the management operation). > > The DESCRIPTION clause of TransportAddress objects that may > have snmpSSHAddress values must fully describe how (and > when) such names are to be resolved to IP addresses and vice > versa. > > This textual convention SHOULD NOT be used directly in > object definitions since it restricts addresses to a > specific format. However, if it is used, it MAY be used > either on its own or in conjunction with > TransportAddressType or TransportDomain as a pair. > > When this textual convention is used as a syntax of an > index object, there may be issues with the limit of 128 > sub-identifiers specified in SMIv2, STD 58. It is > RECOMMENDED that all MIB documents using this textual > convention make explicit any limitations on index > component lengths that management software must observe. > This may be done either by including SIZE constraints on > the index components or by specifying applicable > constraints in the conceptual row DESCRIPTION clause or > in the surrounding documentation. >" > REFERENCE > "RFC3490, Internationalizing Domain Names in Applications, > RFC4252, The Secure Shell (SSH) Authentication Protocol, > RFC3986, Uniform Resource Identifier (URI): Generic Syntax" > SYNTAX OCTET STRING (SIZE (1..255)) > > Maybe add RFC 1033 to this list. [...] >> mechanisms by which it can test whether an underlying SSH >>connection >> provides auth or priv, so the SSH Transport Model trusts that the >> underlying SSH connection has been properly configured to support >> authPriv security characteristics. >> >> >>5. Elements of Procedure >> >> [...] >> >> 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 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. >> >>I am wondering why 2 "should"s are not SHOULDs or even MUSTs. >> >> >two reasons. >1) cut and paste from SNMPv3 standard documents. >2) the shoulds refer to implementation-specific processing that >happens strictly inside the SNMP entity, not on the wire. > > I think this has implications on interoperability, so I am not entirely convinced by your point # 2. Maybe you can give me an example of when it would be Ok not to discard such state? [...] >> should be presented to the ssh server as the "user name" for >> user authentication purposes. If there is no user-name in >> >> >> the tmTransportAddress then the tmSecurityName should be used >> as the user-name. >> >> >> >>7. MIB Module Definition >> >> [...] >> >>snmpSSHDomain OBJECT-IDENTITY >> STATUS current >> DESCRIPTION >> "The SNMP over SSH transport domain. The corresponding >> transport address is of type SnmpSSHAddress. >> >> When an SNMP entity uses the snmpSSHDomain transport >> model, it must be capable of accepting messages up to >> and including 8192 octets in size. Implementation of >> larger values is encouraged whenever possible. >> >> The securityName prefix to be associated with the >> snmpSSHDomain is 'ssh'. This prefix may be used by security >> models or other components to identify what secure transport >> >> >>s/what/that ? >> >> >"which" has the right meaning. > > Ok. >> infrastructure authenticated a securityName." >> >> >>8. Operational Considerations >> >> The SSH Transport Model will likely not work in conditions where >> access to the CLI has stopped working. >> >>Can you elaborate on this a bit more? >> >> >How's this? > The SSH Transport Model will likely not work in conditions where > > I think inserting "remote" here would be even better. > access to the CLI has stopped working. Remote access to a CLI is often > over TCP, which is also used by SSH. > > Ok, I think this is clearer. >> In situations where SNMP >> access has to work when the CLI has stopped working, a UDP transport >> model should be considered instead of the SSH Transport Model. >> >> From alexey.melnikov@isode.com Wed May 6 03:08:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384713A6A73; Wed, 6 May 2009 03:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7+tgQDDACs0; Wed, 6 May 2009 03:08:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6FED33A6A51; Wed, 6 May 2009 03:08:18 -0700 (PDT) Received: from [92.40.30.113] (92.40.30.113.sub.mbb.three.co.uk [92.40.30.113]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 11:09:43 +0100 Message-ID: <4A0161D0.8060600@isode.com> Date: Wed, 06 May 2009 11:09:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: David Harrington References: <20090502131054.256133A6C75@core3.amsl.com> <06bc01c9cdcd$8195aeb0$0600a8c0@china.huawei.com> In-Reply-To: <06bc01c9cdcd$8195aeb0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, draft-ietf-isms-tmsm@tools.ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:08:20 -0000 David Harrington wrote: >Hi Alexey, > > Hi David, My replies are inline. >Thanks for the review. >I am updating my sources as needed. >comments inline. > >David Harrington >dbharrington@comcast.net >ietfdbh@comcast.net >dharrington@huawei.com > > >>-----Original Message----- >>From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On >>Behalf Of Alexey Melnikov >>Sent: Saturday, May 02, 2009 9:11 AM >>To: iesg@ietf.org >>Cc: draft-ietf-isms-tmsm@tools.ietf.org; isms-chairs@tools.ietf.org >>Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm >> >>Discuss: >>In general this is a well written document and I hope to >>clear this DISCUSS very soon. >> >>3.2.1. Architectural Modularity Requirements >> >> [...] >> >> To encourage a basic level of interoperability, any Transport Model >> >> >> SHOULD define one mandatory-to-implement security mechanism, but >> should also be able to support additional existing and new >> mechanisms. >> >>Why this SHOULD is not a MUST? I am expecting a >>mandatory-to-implement to be a MUST. >> >> >remember these are transport models, not security models. Some >transport models can be non-secure. > >What if we defined a new transport model using SCTP or 10GE, for >example? We can use that with User-based Security Model, which does >its own security work. Why would it be required that the SCTP or 10GE >Transport Models define a mandatory-to-implement security mechanism? >(and with RFC3411, it would be wrong to specify that USM is the >mandatory-to-implement security mechanism for a specific transport >model). > >We also allow non-standard proprietary transport models and on the >architectural level having a non-standard transport model without a >mandatory-to-implement security mechanism is just fine. > >We use SHOULD to provide guidance to model developers, without >assuming we can predict what is approrpiate for all future transport >models. > I think I will watch the conclusion of this discussion on the mailing list - so far I see several people disagreeing with you. >>3.2.2.1. securityName and securityLevel Mapping >> >> [...] >> >> Documents defining a new transport domain MUST define a prefix that >> >> >> MAY be prepended by the Security Model to all passed securityNames. >> >> >>I might be slightly confused here: passed by whom? >> >> > >Is this wording clearer? >prepended to all securityNames passed by the Security Model. > > I think it is. >> The prefix MUST include from one to four ASCII characters, not >> >>You probably didn't mean any US-ASCII character here, e.g. I >>don't think >>you wanted to allow control characters, spaces, etc. >>Wouldn't it be better if this is defined as US-ASCII alpha-numeric? >> >> >We can change this to US-ASCII alpha-numeric. > > Good. >>3.3.4. Message security versus session security >> >> 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 security level requested by a transport-aware security >> >> >> model, i.e. noAuthNoPriv and authNoPriv might be sent over an >> authenticated and encrypted session. A Transport Model MUST NOT >> downgrade the security level requested by a >>transport-aware security >> model, and SHOULD discard any message where this would occur. >> >>What is an alternative to discarding? >>(I.e. why the last SHOULD is not a MUST) >> >> > >RFC3411 has a modular architecture, and we try not to constrain the >specific behavior of yet-to-be-defined models and implementations with >MUSTs. We use SHOULD to provide guidance rather than a hard rule. > >It is expensive to generate messages only to discard them during the >final steps of processing (sending them). In the Transport Subsystem, >the SNMP message is fully formed before handing it to the Transport >Model, and if transport-security is used, then the message contents >should be independent of the transport used. A new Transport Model >could, for example, be defined that returns the fully-formed message >to the requesting application, which might then choose to send it >using a different security model or different security association or >a different address (in a multi-homed receiver) that can meet the >securityLevel requirement. If we mandate in the architecture that it >MUST be discarded, then we do not permit such solutions. > > I think you are talking about implementation details which might not match every implementation. Anyway, I think adding a couple of sentence saying what you said above would make the context for the SHOULD much clearer. >>Comment: >>I think the document is a bit lax with SHOULDs, some of which >>might be better specified as MUSTs or just removed. For example: >> >> [...] >>3.3.4. Message security versus session security >> >> [...] >> >> If a secure transport session is closed between the time a request >> >> >> message is received, and the corresponding response >>message is sent, >> then the response message SHOULD be discarded, even if a >>new session >> has been established. The SNMPv3 WG decided that this should be a >> >> >> SHOULD architecturally, and it is a >>security-model-specific decision >> whether to REQUIRE this. The architecture does not mandate this >> requirement to allow for future security models where this >>might make >> sense, but not requiring this could lead to added complexity and >> security vulnerabilities, so most security models SHOULD require >> this. >> >>Enclose some SHOULDs in "" to emphasize that they are not >>declaring requirements? >> >> >We use a different convention: > > I was thinking about: The SNMPv3 WG decided that this should be a "SHOULD" architecturally, ... But never mind, this is only a comment. >From section 1.2: > > Non uppercased versions of the keywords should be read as in normal > English. 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 (ASIs) (see section >3.2). > Implementers are free to implement differently. Some usages of >these > lowercase terms are simply normal English usage. > >I'll certainly double-check al usages, but generally we used >uppercased keywords when we thought it would impact interoperability, >and lowercase where we thought it would impact modularity or >inter-model expectations within an SNMP entity. > > From hannes.tschofenig@nsn.com Wed May 6 04:37:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288D128C114; Wed, 6 May 2009 04:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbyy6euKBAMr; Wed, 6 May 2009 04:36:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F10713A6EBE; Wed, 6 May 2009 04:36:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46Bbrf0005368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 13:37:53 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n46BbqVI008873; Wed, 6 May 2009 13:37:53 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 13:37:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 14:39:30 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450152E317@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transport directorate review of draft-ietf-isms-radius-usage-06 Thread-Index: AcnOP1GZ58ZKQ0gJR9qUpHPBb5fcjA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "TSV Dir" , , X-OriginalArrivalTime: 06 May 2009 11:37:52.0551 (UTC) FILETIME=[17463B70:01C9CE3F] X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: ietf@ietf.org, isms@ietf.org Subject: [Isms] Transport directorate review of draft-ietf-isms-radius-usage-06 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:37:00 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. I understand the purpose of the document and I am fine with the content. I only have some minor comments/questions.=20 Since I am familiar with the work on RADIUS I had already a clue about the direction the document when I read the title. Still, a diagram would help with the basic idea. In some sense your document is based on a fairly obvious idea, namely to use the RADIUS backend infrastructure to relay authentication and authorization for SSH. So, a figure like this one could help:=20 +--------+ |RADIUS | |Server | +--------+ ^ RADIUS + | Back-End Management-Transport-Protection | Protocol Framed-Management-Protocol | Support | v +---------+ +---------------+ | Admin's | SNMP |RADIUS Client /| | Device |<-------------------->|Network Device | +---------+ SSH +---------------+ Regarding the following statement: The RADIUS protocol [RFC2865] provides authentication and authorization services for network access devices, usually referred to as a Network Access Server (NAS). This is not the only usage of RADIUS. See, for example, http://www.ietf.org/rfc/rfc5090.txt The interesting thing is that you are defining a RADIUS usage that is conceptually extremely close to RFC 5090.=20 Section 1.2 provides an overview of RADIUS. However, I don't think it is appropriate to use RFC 2119 language in that section.=20 You write:=20 RADIUS almost always involves user authentication as prerequisite to authorization, and there is a user authentication phase for each of these two use cases. Since you mention authorize only later you could refer to this aspect as well.=20 The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt allows you todo authorization without running the authentication exchange even though you bind the authorization step to a previously done authentication exchange. =20 The following RADIUS attributes SHOULD be used, as hint attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e. authPriv) to the RADIUS server: Why don't you use a MUST here? In the previous section you describe how important it is for the AAA server to figure this information out and here you have a SHOULD and do not explain what happens otherwise if this information is not sent.=20 The following RADIUS attributes are used in an Access-Accept message to provision SNMP over a secure transport which provides both integrity and confidentiality (i.e. authPriv): I suspect that this should read as=20 " The following RADIUS attributes MUST be used in an Access-Accept message to provision SNMP over a secure transport which provides both integrity and confidentiality (i.e. SNMP authPriv): " In Table 2 I was only expecting to see the newly introduced RADIUS attributes rather than the attributes that come via the base RADIUS RFC. I wouldn't do that.=20 You excluded accounting from the document and I was wondering whether logging isn't a useful feature (or event required) to ensure accountability when it comes to the management of network equipment. If you look at http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori zation-06.txt then you will notice that they allow accounting messages to carry these new attributes. Btw, the authors of http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori zation-06.txt also allow CoA to be used even though I cannot really say whether this is useful in the context of a SNMP. Withdrawing access right for a person that is logged into an administrative interface, as it can be done with CoA, does not sound too far fetched to me. Another example is the need for re-authentication after a certain time period.=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori zation-06.txt defines 4 new RADIUS attributes, namely - Framed-Management-Protocol - Management-Transport-Protection - Management-Policy-Id - Management-Privilege-Level You don't make use of the last two. Is there a specific reason?=20 I would have just copied the Table of Attributes from http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori zation-06.txt and maybe you would have to add a little bit of text indicating whether these two additional AVPs are somehow in relationship with SNMP usage. In your document you only focus on RADIUS whereas the document that defines the attributes, namely http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori zation-06.txt, also defines them for Diameter. Any reason why you did not extend your description also to Diameter? Maybe because Diameter is not used in your envisioned usage domain or so?=20 Regarding the security considerations: The interworking between RADIUS and SSH for authentication and authorization does not really allow "high-quality" authentication mechanisms to be used. In the document itself you state that mostly username/password is going to be utilized and hence I believe that the solution is not secure outside a single adminstrative domain. Hence, I would spell this out in the security consideration section instead of referring to AAA roaming, particularly RFC 2607.=20 Regarding the usage of the Message authentication in RADIUS. I suggest to copy-and-paste the following paragraph from=20 http://tools.ietf.org/html/draft-ietf-radext-design-07 and modify it slightly:=20 " Message authentication in RADIUS is provided largely via the Message- Authenticator attribute. See [RFC3579] Section 3.2, and also [RFC5080] 2.2.2. Unfortunately, the Message-Authenticator attribute does not provide confidentiality protection.=20 To avoid eavesdropping of RADIUS message exchanges a secure communications protocol, such as IPsec or TLS (with RadSec http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-04.txt) MUST be used. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more in-depth explanation of these issues. " If you add RadSec as a normative references your document will unfortunately be blocked a little bit (until RadSec is completed) and you will have to repeat the IETF Last Call since RadSec will have to be indicated as a DownRef in the LC.=20 IPsec on the other hand can be used without any problems (and is used today a lot for protection of RADIUS).=20 Editorial: FROM: SSH server implementations often use the Pluggable Authentication Modules (PAM) [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by operating systems such as Linux and Solaris to integrate with password based network authentication mechanisms such as RADIUS, TACACS+, Kerberos, etc. TO: SSH server implementations often use the Pluggable Authentication Modules (PAM) [ref1] interface provided by operating systems, such as Linux and Solaris, to integrate with password based network authentication mechanisms, such as RADIUS, TACACS+, and Kerberos. [ref1] http://www.opengroup.org/rfc/rfc86.0.html FROM: The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a mechanism for providing transport layer security for SNMP, allowing protocols such as SSH and TLS to be used to secure SNMP communication. TO: The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a mechanism for providing transport layer security for SNMP, allowing protocols, such as SSH and TLS, to be used to secure SNMP communication. FROM: The Secure Shell protocol provides a secure transport channel with support for channel authentication via local accounts and integration with various external authentication and authorization services such as RADIUS, Kerberos, etc. TO: The Secure Shell protocol provides a secure transport channel with support for channel authentication via local accounts and integration with various external authentication and authorization systems, such as RADIUS, and Kerberos. FROM: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. TO: 1. Service-Type with a value of TBA-x for "Framed-Management. 2. Framed-Management-Protocol with a value of (1) for "SNMP". 3. Management-Transport-Protection with a value of (3) for "Integrity-Confidentiality-Protection". The Service-Type value for TBA-x is registered via draft-ietf-radext-management-authorization.=20 FROM: The following RADIUS attributes MAY be optionally used, to authorize use of SNMP without protection (i.e. authNoPriv): TO: The following RADIUS attributes MAY be optionally used, to authorize use of SNMP without integrity and confidentiality protection (i.e.,=20 equivalent to the SNMP authNoPriv access). FROM: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of No-Protection. TO: 1. Service-Type with a value of TBA-x for "Framed-Management. 2. Framed-Management-Protocol with a value of (1) for "SNMP". 3. Management-Transport-Protection with a value of (1) for "No-Protection". Ciao Hannes From alexey.melnikov@isode.com Wed May 6 07:48:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58DB13A6EB7; Wed, 6 May 2009 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-9IaflB198D; Wed, 6 May 2009 07:48:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C5C403A6F1C; Wed, 6 May 2009 07:47:13 -0700 (PDT) Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 15:48:40 +0100 Message-ID: <4A01A338.1040203@isode.com> Date: Wed, 06 May 2009 15:48:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Juergen Schoenwaelder References: <20090503113302.C3E693A6A35@core3.amsl.com> <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> <4A015F19.4040106@isode.com> <20090506140701.GD22610@elstar.local> In-Reply-To: <20090506140701.GD22610@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: "draft-ietf-isms-secshell@tools.ietf.org" , "iesg@ietf.org" , "isms-chairs@tools.ietf.org" , "isms@ietf.org" Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:48:15 -0000 Juergen Schoenwaelder wrote: >On Wed, May 06, 2009 at 11:57:45AM +0200, Alexey Melnikov wrote: > > >>>> 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 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. >>>> >>>>I am wondering why 2 "should"s are not SHOULDs or even MUSTs. >>>> >>>> >>>two reasons. >>>1) cut and paste from SNMPv3 standard documents. >>>2) the shoulds refer to implementation-specific processing that >>>happens strictly inside the SNMP entity, not on the wire. >>> >>> >>I think this has implications on interoperability, so I am not entirely >>convinced by your point # 2. >>Maybe you can give me an example of when it would be Ok not to discard >>such state? >> >> >I do not see any interoperability issues; this text is really just a >hint that it is a good idea to release message specific state when the >message gets discarded. But protocol wise, an implementation would not >break anything if it would never release any message specific state >information (but such an implementation might run out of memory of >course and be an easy target for a DoS attack). > >Since this same wording has worked in other SNMPv3 specifications >(i.e., RFC3412 and RFC3414, both part of STD62), I am not sure this >needs any changes. > > Juergen, Your response makes me think that I don't really understand what is the meaning of "release" is in this case. I understood "release" as "don't use this information again, it is invalid". I wasn't thinking about "release" as an advice about memory management. Which one is it? Thanks, Alexey From alexey.melnikov@isode.com Wed May 6 11:13:32 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5E528C264; Wed, 6 May 2009 11:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYHLykJDJBWH; Wed, 6 May 2009 11:13:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C58073A6939; Wed, 6 May 2009 11:06:12 -0700 (PDT) Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 19:07:38 +0100 Message-ID: <4A01D1D0.4060902@isode.com> Date: Wed, 06 May 2009 19:07:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: David Harrington References: <20090503113302.C3E693A6A35@core3.amsl.com> <06c401c9cde0$01a02290$0600a8c0@china.huawei.com> <4A015F19.4040106@isode.com> <20090506140701.GD22610@elstar.local> <4A01A338.1040203@isode.com> <075a01c9ce6c$b1a39f50$0600a8c0@china.huawei.com> In-Reply-To: <075a01c9ce6c$b1a39f50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: draft-ietf-isms-secshell@tools.ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 18:13:32 -0000 David Harrington wrote: >Hi, > >I think this is really about memory management. > >In SNMPv3 WG, we did not want to talk about getting rid of the cache >everytime we suggested discarding a message (and for ISMS, closing >sessions), so we put the advice about "releasing" the cache in one >general statement. While memory management is an implementation >detail, we wanted to assert that it was OK to release the memory at >specific points, so implementers would know the related state >information was no longer needed. > >The SNMPv3 standard uses the same text, and we have never, to my >knowledge, had any implementer have problmes with implementing or with >interoperability as a result of this text. > > Ok, I've updated my COMMENT in the id-tracker. I think it would have been nice if the text is more clearer that it talks about memory management and nothing else, but this is only a non-blocking comment. From alexey.melnikov@isode.com Thu May 7 03:23:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F193A69B8; Thu, 7 May 2009 03:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KreMyua3jgUd; Thu, 7 May 2009 03:23:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 78CFD3A68DA; Thu, 7 May 2009 03:23:08 -0700 (PDT) Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 May 2009 11:24:35 +0100 Message-ID: <4A02B6C7.9070407@isode.com> Date: Thu, 07 May 2009 11:24:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: David Harrington References: <20090502131054.256133A6C75@core3.amsl.com> <06bc01c9cdcd$8195aeb0$0600a8c0@china.huawei.com> <4A01AA64.3000102@isode.com> <078c01c9ce87$70b1ff30$0600a8c0@china.huawei.com> In-Reply-To: <078c01c9ce87$70b1ff30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 May 2009 17:23:18 -0700 Cc: iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] My DISCUSSes on draft-ietf-isms-* documents X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 10:23:09 -0000 Thank you for addressing my concerns. I cleared my DISCUSSes. From hartmans@mit.edu Thu May 7 18:49:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055583A7042; Thu, 7 May 2009 18:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLYc+BBZDXxZ; Thu, 7 May 2009 18:49:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 410C63A7031; Thu, 7 May 2009 18:49:18 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EFB854163; Thu, 7 May 2009 21:50:40 -0400 (EDT) To: "David B. Nelson" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> From: Sam Hartman Date: Thu, 07 May 2009 21:15:47 -0400 In-Reply-To: (David B. Nelson's message of "Tue\, 5 May 2009 16\:07\:48 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'David B Harrington' , isms@ietf.org, secdir@ietf.org, isms-chairs@tools.ietf.org, iesg@ietf.org, 8 'Barry Leiba' , draft-ietf-isms-transport-security-model@tools.ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 01:49:19 -0000 >>>>> "David" == David B Nelson writes: David> David B Harrington writes... >> What is the correct non-RFC2119 phrase in which to couch our >> deployment advice? David> One suitable strategy would be to include any "advice to David> operators" in a non-normative section or appendix, clearly David> labeled as non-normative. I don't think the "keyword David> police" will bother with non-normative text. :-) 8 David> _______________________________________________ secdir David> mailing list secdir@ietf.org David> https://www.ietf.org/mailman/listinfo/secdir Or just use lower case should. I think the advice is important enough it does not belong in an appendix. From randy_presuhn@mindspring.com Fri May 8 10:42:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E5A3A6FD7; Fri, 8 May 2009 10:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTTD83LyVFI5; Fri, 8 May 2009 10:42:18 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 2650C3A6982; Fri, 8 May 2009 10:42:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e2ruHzbTd3fXIeGUUvwivr4pbUoBVFfIV3Ci76F5AJR8gyJBdGc9TRY/SgkOlFCX; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.146.20] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2U6q-0002yd-05; Fri, 08 May 2009 13:43:44 -0400 Message-ID: <007b01c9d004$f6f57da0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <20090503113302.C3E693A6A35@core3.amsl.com><06c401c9cde0$01a02290$0600a8c0@china.huawei.com><4A015F19.4040106@isode.com> <20090506140701.GD22610@elstar.local> <4A01A338.1040203@isode.com> Date: Fri, 8 May 2009 10:46:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69686c273d9dbd07ffbdecaafb3b9e52cca5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.20 Cc: draft-ietf-isms-secshell@tools.ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, isms@ietf.org Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 17:42:19 -0000 Hi - > From: "Alexey Melnikov" > To: "Juergen Schoenwaelder" > Cc: ; ; ; > Sent: Wednesday, May 06, 2009 7:48 AM > Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell ... > Juergen, > Your response makes me think that I don't really understand what is the > meaning of "release" is in this case. > I understood "release" as "don't use this information again, it is > invalid". I wasn't thinking about "release" as an advice about memory > management. > Which one is it? When this text was written, we were thinking about memory management. It comes from a time when did not yet have agreement about whether the procedures should be described in terms of APIs. We did not want to constrain implementation technologies, but it was felt that this could be helpful to those writing new implementations. Randy From cfinss@dial.pipex.com Fri May 8 10:57:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9123A6DB9; Fri, 8 May 2009 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvk2KI+YgHvU; Fri, 8 May 2009 10:57:18 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 41AE33A6C68; Fri, 8 May 2009 10:57:18 -0700 (PDT) X-Trace: 101204951/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.61/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.61 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEAP8PBEo+vBM9/2dsb2JhbACDKEyKYsJBB4N2BQ X-IronPort-AV: E=Sophos;i="4.40,318,1238972400"; d="scan'208";a="101204951" X-IP-Direction: IN Received: from 1cust61.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.61]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2009 18:57:44 +0100 Message-ID: <007f01c9cffe$0aa68da0$0601a8c0@allison> From: "tom.petch" To: "Barry Leiba" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Date: Fri, 8 May 2009 18:56:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 17:57:19 -0000 ----- Original Message ----- From: "Barry Leiba" To: "David B Harrington" Cc: ; ; ; Sent: Tuesday, May 05, 2009 10:03 PM > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > Well, this would make me happy; would it work for you (and others)?: > > OLD: > by the RFC 3411 architecture. However, the Transport Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it SHOULD always be used with a Transport Model > that provides appropriate security. Which threats are addressed and > how they are mitigated depends on the Transport Model. > > NEW: > by the RFC 3411 architecture. However, the Transport Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it MUST always be used with a Transport Model > that provides appropriate security. What is "appropriate" for a particular > deployment is an administrative decision. Which threats are addressed > and how they are mitigated depends on the Transport Model. I have reservations about this, about the optimism that it may generate in readers. The idea of Models in SNMP is to be able to mix and match. In practice, this has not worked - USM with sshTM will not function, regardless of whether it is secure or not. Do not underestimate the labour it has taken to get TSM working with sshTM. If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an idea that is being mooted now. But it may not. In a similar vein, I am mindful that ssh just hit problems with AES-GCM, that the architecture of ssh does not allow for this new cryptography or that the discussions leading to TLS 1.2 of how to introduce (or not) algorithm agility, just as SNMP has problems (and has given up) trying to use USM with sshTM. Thus TLS has session cache and resumption. Will that work with TSM? I do not know - and as it has taken the last two years to come up with an agreed form of words that allows just TSM to work with just sshTM, so I am not going to try and work out the ramifications of TLSTM just yet:-( We may find we got TSM wrong and that it needs changing. Or we may have another secure Transport Model that turns out to be insecure with TSM and needs an xSM to make it secure. The proposed amendment seems to me rather optimistic. Tom Petch > Barry > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Fri May 8 14:33:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5F83A6FDC for ; Fri, 8 May 2009 14:33:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc6RaXSnYcWC for ; Fri, 8 May 2009 14:32:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDF863A6C85 for ; Fri, 8 May 2009 14:32:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 382FCC0218 for ; Fri, 8 May 2009 23:33:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kQXJDiBcsbj0 for ; Fri, 8 May 2009 23:33:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79F67C0212 for ; Fri, 8 May 2009 23:33:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82F5DAE3FDD; Fri, 8 May 2009 23:33:24 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Fri, 8 May 2009 23:33:24 +0200 Resent-Message-ID: <20090508213324.GA28541@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.122) with Microsoft SMTP Server id 8.1.358.0; Fri, 8 May 2009 21:48:03 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CF7DC020C for ; Fri, 8 May 2009 21:48:03 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 26E055CF for ; Fri, 8 May 2009 21:48:03 +0200 (CEST) Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id 8DzVK0lDNnvO for ; Fri, 8 May 2009 21:48:01 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Fri, 8 May 2009 21:48:01 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EE228C1B1; Fri, 8 May 2009 12:45:04 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 0473A3A7144; Fri, 8 May 2009 12:45:01 -0700 (PDT) From: "Internet-Drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Fri, 8 May 2009 21:45:02 +0200 Thread-Topic: I-D Action:draft-hardaker-isms-dtls-tm-04.txt Thread-Index: AcnQFeZa9XLITa9cQmyZM3qWcEIgyg== Message-ID: <20090508194502.0473A3A7144@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-beenthere: i-d-announce@ietf.org x-original-to: i-d-announce@ietf.org x-mailman-version: 2.1.9 Errors-To: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at jacobs-university.de delivered-to: i-d-announce@core3.amsl.com x-jacobsispwhitelisted: med ietf.org DNSWLId 1703 Content-Type: multipart/mixed; boundary="_003_200905081945020473A3A7144core3amslcom_" MIME-Version: 1.0 Subject: [Isms] I-D Action:draft-hardaker-isms-dtls-tm-04.txt X-BeenThere: isms@ietf.org Precedence: list Reply-To: "internet-drafts@ietf.org" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:33:17 -0000 --_003_200905081945020473A3A7144core3amslcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoJVGl0bGUgICAgICAgICAgIDogRGF0YWdyYW0gVHJh bnNwb3J0IExheWVyIFNlY3VyaXR5IFRyYW5zcG9ydCBNb2RlbCBmb3IgU05NUA0KCUF1dGhvcihz KSAgICAgICA6IFcuIEhhcmRha2VyDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaGFyZGFrZXIt aXNtcy1kdGxzLXRtLTA0LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDU2DQoJRGF0ZSAgICAgICAg ICAgIDogMjAwOS0wNS0wOA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIFRyYW5zcG9ydCBN b2RlbCBmb3IgdGhlIFNpbXBsZSBOZXR3b3JrDQpNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKSwg dGhhdCB1c2VzIHRoZSBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXINClNlY3VyaXR5IChEVExTKSBw cm90b2NvbC4gIFRoZSBEVExTIHByb3RvY29sIHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uDQphbmQg cHJpdmFjeSBzZXJ2aWNlcyBmb3IgU05NUCBhcHBsaWNhdGlvbnMuICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcw0KaG93IHRoZSBEVExTIFRyYW5zcG9ydCBNb2RlbCAoRFRMU1RNKSBpbXBsZW1lbnRz IHRoZSBuZWVkZWQgZmVhdHVyZXMNCm9mIGEgU05NUCBUcmFuc3BvcnQgU3Vic3lzdGVtIHRvIG1h a2UgdGhpcyBwcm90ZWN0aW9uIHBvc3NpYmxlIGluIGFuDQppbnRlcm9wZXJhYmxlIHdheS4NCg0K VGhpcyB0cmFuc3BvcnQgbW9kZWwgaXMgZGVzaWduZWQgdG8gbWVldCB0aGUgc2VjdXJpdHkgYW5k IG9wZXJhdGlvbmFsDQpuZWVkcyBvZiBuZXR3b3JrIGFkbWluaXN0cmF0b3JzLCBvcGVyYXRlIGlu IGVudmlyb25tZW50cyB3aGVyZSBhDQpjb25uZWN0aW9ubGVzcyAoZS5nLiAgVURQIG9yIFNDVFAp IHRyYW5zcG9ydCBpcyBwcmVmZXJyZWQsIGFuZA0KaW50ZWdyYXRlcyB3ZWxsIGludG8gZXhpc3Rp bmcgcHVibGljIGtleWluZyBpbmZyYXN0cnVjdHVyZXMuDQoNClRoaXMgZG9jdW1lbnQgYWxzbyBk ZWZpbmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbg0KQmFzZSAoTUlC KSBmb3IgbW9uaXRvcmluZyBhbmQgbWFuYWdpbmcgdGhlIERUTFMgVHJhbnNwb3J0IE1vZGVsIGZv cg0KU05NUC4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJkYWtlci1pc21zLWR0bHMtdG0tMDQu dHh0DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCkJlbG93IGlzIHRo ZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXINCmlt cGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24g b2YgdGhlDQpJbnRlcm5ldC1EcmFmdC4NCg== --_003_200905081945020473A3A7144core3amslcom_ Content-Type: message/external-body; name="draft-hardaker-isms-dtls-tm-04.url" Content-Description: draft-hardaker-isms-dtls-tm-04.url Content-Disposition: attachment; filename="draft-hardaker-isms-dtls-tm-04.url"; size=159; creation-date="Fri, 08 May 2009 21:48:03 GMT"; modification-date="Fri, 08 May 2009 21:48:03 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYXJkYWtlci1pc21zLWR0bHMtdG0tMDQudHh0DQo= --_003_200905081945020473A3A7144core3amslcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=322; creation-date="Fri, 08 May 2009 21:48:03 GMT"; modification-date="Fri, 08 May 2009 21:48:03 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_200905081945020473A3A7144core3amslcom_-- From cfinss@dial.pipex.com Fri May 8 14:35:43 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14A03A6B1C; Fri, 8 May 2009 14:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GD8Patyglo3; Fri, 8 May 2009 14:35:42 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 819AA3A7151; Fri, 8 May 2009 14:35:32 -0700 (PDT) X-Trace: 245559828/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.116/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.116 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEABdDBEo+vBN0/2dsb2JhbACDKEyKYsIbB4N2BQ X-IronPort-AV: E=Sophos;i="4.40,319,1238972400"; d="scan'208";a="245559828" X-IP-Direction: IN Received: from 1cust116.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.116]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2009 22:36:57 +0100 Message-ID: <002801c9d01c$ab134bc0$0601a8c0@allison> From: "tom.petch" To: "Barry Leiba" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> Date: Fri, 8 May 2009 22:35:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:35:43 -0000 ----- Original Message ----- From: "Barry Leiba" To: "tom.petch" Cc: ; Sent: Friday, May 08, 2009 8:05 PM (Top post only...) I get what you're saying, Tom, but I'm not sure where it's going. Are you saying that the text should be changed to allow *less* flexibility? That may be right, but then what text do you suggest instead? Barry I would like the idea of 'in conjunction with' to hint at the co-dependence of xSM and xTM eg "However, the Transport Security Model does not by itself provide security mechanisms such as authentication and encryption, so it MUST always be used in conjunction with a Transport Model that together with it provides appropriate security" Tom Petch Barry >> > That is a deployment decision made by an administrator who has an >> > understanding of what is appropriate to the system in question. >> > >> > What is the correct non-RFC2119 phrase in which to couch our >> > deployment advice? >> >> Well, this would make me happy; would it work for you (and others)?: >> >> OLD: >> by the RFC 3411 architecture. However, the Transport Security Model >> does not provide security mechanisms such as authentication and >> encryption itself, so it SHOULD always be used with a Transport Model >> that provides appropriate security. Which threats are addressed and >> how they are mitigated depends on the Transport Model. >> >> NEW: >> by the RFC 3411 architecture. However, the Transport Security Model >> does not provide security mechanisms such as authentication and >> encryption itself, so it MUST always be used with a Transport Model >> that provides appropriate security. What is "appropriate" for a particular >> deployment is an administrative decision. Which threats are addressed >> and how they are mitigated depends on the Transport Model. > > I have reservations about this, about the optimism that it may generate in > readers. > > The idea of Models in SNMP is to be able to mix and match. In practice, this > has not worked - USM with sshTM will not function, regardless of whether it is > secure or not. Do not underestimate the labour it has taken to get TSM working > with sshTM. > > If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an idea > that is being mooted now. But it may not. In a similar vein, I am mindful that > ssh just hit problems with AES-GCM, that the architecture of ssh does not allow > for this new cryptography or that the discussions leading to TLS 1.2 of how to > introduce (or not) algorithm agility, just as SNMP has problems (and has given > up) trying to use USM with sshTM. > > Thus TLS has session cache and resumption. Will that work with TSM? I do not > know - and as it has taken the last two years to come up with an agreed form of > words that allows just TSM to work with just sshTM, so I am not going > to try and work out the ramifications of TLSTM just yet:-( We may find we got > TSM wrong and that it needs changing. > > Or we may have another secure Transport Model that turns out to be insecure with > TSM and needs an xSM to make it secure. The proposed amendment seems to me > rather optimistic. > > Tom Petch From j.schoenwaelder@jacobs-university.de Fri May 8 14:42:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942843A67FD; Fri, 8 May 2009 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcCfKlImNOzp; Fri, 8 May 2009 14:42:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7DE063A6C4F; Fri, 8 May 2009 14:42:40 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7D49C0218; Fri, 8 May 2009 23:44:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XzlQWnAS0c2U; Fri, 8 May 2009 23:44:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FA30C0212; Fri, 8 May 2009 23:44:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F0A20AE404D; Fri, 8 May 2009 23:43:46 +0200 (CEST) Date: Fri, 8 May 2009 23:43:46 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090508214346.GB28541@elstar.local> Mail-Followup-To: "tom.petch" , Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007f01c9cffe$0aa68da0$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" Subject: Re: [Isms] [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:42:41 -0000 On Fri, May 08, 2009 at 06:56:27PM +0200, tom.petch wrote: > The idea of Models in SNMP is to be able to mix and match. In > practice, this has not worked - USM with sshTM will not function, > regardless of whether it is secure or not. Not sure I understand why. Can you explain? > Thus TLS has session cache and resumption. Will that work with TSM? Yes, this will just work fine since it is transparent. You can add session resumption to SSH and it will work just fine with sshtm. Of course, sometimes we design for extensibility and when we need it, we realize the shortcomings of the design. But there are also things that just work fine - you are painting a picture here with black colors. Even though it is difficult to get exensibility right, I think not trying to be extensible is not an alternative. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Fri May 8 15:08:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2E43A69BD for ; Fri, 8 May 2009 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ85NrQxyErQ for ; Fri, 8 May 2009 15:08:18 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 1BE7F3A6B55 for ; Fri, 8 May 2009 15:08:18 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id p18X1b0070vyq2s59A9njv; Fri, 08 May 2009 22:09:47 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id pA9n1b00H0UQ6dC3RA9nJ1; Fri, 08 May 2009 22:09:47 +0000 From: "David Harrington" To: "'tom.petch'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> <002801c9d01c$ab134bc0$0601a8c0@allison> Date: Fri, 8 May 2009 18:09:46 -0400 Message-ID: <096b01c9d029$b2b51c20$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 Thread-Index: AcnQJUeTxtK0lG2NTU6SeHB0hlUu0QAAycQA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002801c9d01c$ab134bc0$0601a8c0@allison> Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:08:19 -0000 Hi, IN sechell-17, its says: "It is expected that an entity implementing this MIB will also support the Transport Security Model [I-D.ietf-isms-transport-security-model], and therefore implement the SNMP-TSM-MIB." " To have SNMP properly utilize the security services provided by SSH, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [I-D.ietf-isms-transport-security-model]." In transport-model-14, it says: " To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]." By keeping the reference to an example using "such as", we avoid hard bindings between the models, and we avoid normative references between the documents, so as to not defeat the goal of the RFC3411 modular architecture of allowing the models to advance on the standards track independently. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, May 08, 2009 4:36 PM > To: Barry Leiba > Cc: isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir] > secdirreviewofdraft-ietf-isms-transport-security-model-12 > > ----- Original Message ----- > From: "Barry Leiba" > To: "tom.petch" > Cc: ; > Sent: Friday, May 08, 2009 8:05 PM > > (Top post only...) > I get what you're saying, Tom, but I'm not sure where it's going. Are > you saying that the text should be changed to allow *less* > flexibility? That may be right, but then what text do you suggest > instead? > > Barry > > I would like the idea of 'in conjunction with' to hint at the > co-dependence of > xSM and xTM eg > > "However, the Transport Security Model > does not by itself provide security mechanisms such as > authentication and > encryption, so it MUST always be used in conjunction with a > Transport Model that > together with it provides appropriate security" > > Tom Petch > > Barry > > >> > That is a deployment decision made by an administrator who has an > >> > understanding of what is appropriate to the system in question. > >> > > >> > What is the correct non-RFC2119 phrase in which to couch our > >> > deployment advice? > >> > >> Well, this would make me happy; would it work for you (and > others)?: > >> > >> OLD: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it SHOULD always be used with a > Transport Model > >> that provides appropriate security. Which threats are addressed and > >> how they are mitigated depends on the Transport Model. > >> > >> NEW: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it MUST always be used with a Transport Model > >> that provides appropriate security. What is "appropriate" > for a particular > >> deployment is an administrative decision. Which threats > are addressed > >> and how they are mitigated depends on the Transport Model. > > > > I have reservations about this, about the optimism that it > may generate in > > readers. > > > > The idea of Models in SNMP is to be able to mix and match. > In practice, this > > has not worked - USM with sshTM will not function, > regardless of whether it is > > secure or not. Do not underestimate the labour it has taken > to get TSM working > > with sshTM. > > > > If we have got TSM right, then it will work with eg TLSTM > or DTLSTM, an idea > > that is being mooted now. But it may not. In a similar > vein, I am mindful that > > ssh just hit problems with AES-GCM, that the architecture > of ssh does not > allow > > for this new cryptography or that the discussions leading > to TLS 1.2 of how to > > introduce (or not) algorithm agility, just as SNMP has > problems (and has given > > up) trying to use USM with sshTM. > > > > Thus TLS has session cache and resumption. Will that work > with TSM? I do not > > know - and as it has taken the last two years to come up > with an agreed form > of > > words that allows just TSM to work with just sshTM, so I am > not going > > to try and work out the ramifications of TLSTM just yet:-( > We may find we got > > TSM wrong and that it needs changing. > > > > Or we may have another secure Transport Model that turns > out to be insecure > with > > TSM and needs an xSM to make it secure. The proposed > amendment seems to me > > rather optimistic. > > > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Fri May 8 15:22:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236D13A67FD for ; Fri, 8 May 2009 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRQEBa53jFRC for ; Fri, 8 May 2009 15:22:37 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id E160E3A6830 for ; Fri, 8 May 2009 15:22:36 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id oyCx1b0040vyq2s5AAQ6Qs; Fri, 08 May 2009 22:24:06 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id pAQ61b00A0UQ6dC3RAQ6Lt; Fri, 08 May 2009 22:24:06 +0000 From: "David Harrington" To: "'tom.petch'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> <002801c9d01c$ab134bc0$0601a8c0@allison> Date: Fri, 8 May 2009 18:24:05 -0400 Message-ID: <096c01c9d02b$b29db1a0$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 Thread-Index: AcnQJUeTxtK0lG2NTU6SeHB0hlUu0QABPnpQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002801c9d01c$ab134bc0$0601a8c0@allison> Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:22:38 -0000 Hi, transport-security-model-14 says, in the discussion of threats,: " The Transport Security Model is compatible with the RFC3411 architecture, and provides protection against the threats identified by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself. Which threats are addressed and how they are mitigated depends on the Transport Model used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision." Whether SSHTM is appropriate in the network being managed is an administrative decision, so we do not cite it specifically at this point. and, under Coexistence with Transport Models, it says: " To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, May 08, 2009 4:36 PM > To: Barry Leiba > Cc: isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir] > secdirreviewofdraft-ietf-isms-transport-security-model-12 > > ----- Original Message ----- > From: "Barry Leiba" > To: "tom.petch" > Cc: ; > Sent: Friday, May 08, 2009 8:05 PM > > (Top post only...) > I get what you're saying, Tom, but I'm not sure where it's going. Are > you saying that the text should be changed to allow *less* > flexibility? That may be right, but then what text do you suggest > instead? > > Barry > > I would like the idea of 'in conjunction with' to hint at the > co-dependence of > xSM and xTM eg > > "However, the Transport Security Model > does not by itself provide security mechanisms such as > authentication and > encryption, so it MUST always be used in conjunction with a > Transport Model that > together with it provides appropriate security" > > Tom Petch > > Barry > > >> > That is a deployment decision made by an administrator who has an > >> > understanding of what is appropriate to the system in question. > >> > > >> > What is the correct non-RFC2119 phrase in which to couch our > >> > deployment advice? > >> > >> Well, this would make me happy; would it work for you (and > others)?: > >> > >> OLD: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it SHOULD always be used with a > Transport Model > >> that provides appropriate security. Which threats are addressed and > >> how they are mitigated depends on the Transport Model. > >> > >> NEW: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it MUST always be used with a Transport Model > >> that provides appropriate security. What is "appropriate" > for a particular > >> deployment is an administrative decision. Which threats > are addressed > >> and how they are mitigated depends on the Transport Model. > > > > I have reservations about this, about the optimism that it > may generate in > > readers. > > > > The idea of Models in SNMP is to be able to mix and match. > In practice, this > > has not worked - USM with sshTM will not function, > regardless of whether it is > > secure or not. Do not underestimate the labour it has taken > to get TSM working > > with sshTM. > > > > If we have got TSM right, then it will work with eg TLSTM > or DTLSTM, an idea > > that is being mooted now. But it may not. In a similar > vein, I am mindful that > > ssh just hit problems with AES-GCM, that the architecture > of ssh does not > allow > > for this new cryptography or that the discussions leading > to TLS 1.2 of how to > > introduce (or not) algorithm agility, just as SNMP has > problems (and has given > > up) trying to use USM with sshTM. > > > > Thus TLS has session cache and resumption. Will that work > with TSM? I do not > > know - and as it has taken the last two years to come up > with an agreed form > of > > words that allows just TSM to work with just sshTM, so I am > not going > > to try and work out the ramifications of TLSTM just yet:-( > We may find we got > > TSM wrong and that it needs changing. > > > > Or we may have another secure Transport Model that turns > out to be insecure > with > > TSM and needs an xSM to make it secure. The proposed > amendment seems to me > > rather optimistic. > > > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Sat May 9 06:49:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBEB3A6E40; Sat, 9 May 2009 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgbqtvb5bBNf; Sat, 9 May 2009 06:49:20 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id A210C3A6813; Sat, 9 May 2009 06:49:20 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 19B9139A104; Sat, 9 May 2009 06:50:49 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> Date: Sat, 09 May 2009 06:50:49 -0700 In-Reply-To: <20090508214346.GB28541@elstar.local> (Juergen Schoenwaelder's message of "Fri, 8 May 2009 23:43:46 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" Subject: Re: [Isms] [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 13:49:21 -0000 >>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen Schoenwaelder said: >> The idea of Models in SNMP is to be able to mix and match. In >> practice, this has not worked - USM with sshTM will not function, >> regardless of whether it is secure or not. JS> Not sure I understand why. Can you explain? The way it's worded right now in the SSH document is that there must be a tmStateReference for outgoing messages or the SSHTM will drop the message: 1. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the sshtmSessionInvalidCaches counter, discard the message and return the error indication in the statusInformation. Processing of this message stops. USM won't generate a tmStateReference so it can't be used as an upper-level security protocol. This was discussed (I'm fairly certain) on the list at some point and it was decided this was ok as doing something to try and recover at that point would really be adding words and complexity for a situation that didn't really need to be supported. [that being said, note that there isn't a MUST drop it in the text] -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Sat May 9 09:30:12 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB843A6E68 for ; Sat, 9 May 2009 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A0e7LjTuUMs for ; Sat, 9 May 2009 09:30:11 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 3B3F73A6E67 for ; Sat, 9 May 2009 09:30:10 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id pPZ51b0040cZkys56UXRFw; Sat, 09 May 2009 16:31:25 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id pUXf1b00n0UQ6dC3WUXgVo; Sat, 09 May 2009 16:31:40 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><20090508214346.GB28541@elstar.local> Date: Sat, 9 May 2009 12:31:38 -0400 Message-ID: <098001c9d0c3$a119ea00$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 Thread-Index: AcnQrS0FO4T3PJQ/S7+R9hOXeJvNcQAFTx9g X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: 'Barry Leiba' , isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir]secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 16:30:12 -0000 Hi, I agree we didn't use the word "MUST" in this text, but we do not seem to allow any alternative approach: "then [...] discard the message and return the error indication in the statusInformation." For compliance to this model, this is a required step. Where we do NOT specify a MUST is in the **architecture** document, because other models might choose to do something other than discard the message. Wes, are you suggestiong we should rwwrite all the elements of procedure to use MUST every place where there is a definite step to be followed? Would this be clearer? > 1. If tmStateReference does not refer to a cache containing values > for tmTransportDomain, tmTransportAddress, tmSecurityName, > tmRequestedSecurityLevel, and tmSameSecurity, then the implementation MUST > increment the > sshtmSessionInvalidCaches counter, MUST discard the message > and MUST return > the error indication in the statusInformation. Processing of > this message MUST stop. is that what you want to see? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Saturday, May 09, 2009 9:51 AM > To: tom.petch > Cc: Barry Leiba; isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir]secdir > reviewofdraft-ietf-isms-transport-security-model-12 > > >>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen > Schoenwaelder said: > > >> The idea of Models in SNMP is to be able to mix and match. In > >> practice, this has not worked - USM with sshTM will not function, > >> regardless of whether it is secure or not. > > JS> Not sure I understand why. Can you explain? > > The way it's worded right now in the SSH document is that > there must be > a tmStateReference for outgoing messages or the SSHTM will drop the > message: > > 1. If tmStateReference does not refer to a cache containing values > for tmTransportDomain, tmTransportAddress, tmSecurityName, > tmRequestedSecurityLevel, and tmSameSecurity, then > increment the > sshtmSessionInvalidCaches counter, discard the message > and return > the error indication in the statusInformation. Processing of > this message stops. > > USM won't generate a tmStateReference so it can't be used as an > upper-level security protocol. This was discussed (I'm > fairly certain) > on the list at some point and it was decided this was ok as doing > something to try and recover at that point would really be > adding words > and complexity for a situation that didn't really need to be > supported. > > [that being said, note that there isn't a MUST drop it in the text] > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Sat May 9 15:18:48 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A213A6887; Sat, 9 May 2009 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufMJKKgYOMoo; Sat, 9 May 2009 15:18:48 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 3DF4E3A67F7; Sat, 9 May 2009 15:18:48 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6A22539A0EB; Sat, 9 May 2009 15:20:16 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> <098001c9d0c3$a119ea00$0600a8c0@china.huawei.com> Date: Sat, 09 May 2009 15:20:16 -0700 In-Reply-To: <098001c9d0c3$a119ea00$0600a8c0@china.huawei.com> (David Harrington's message of "Sat, 9 May 2009 12:31:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Barry Leiba' , isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir]secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 22:18:49 -0000 >>>>> On Sat, 9 May 2009 12:31:38 -0400, "David Harrington" said: DH> Wes, are you suggestiong we should rwwrite all the elements of DH> procedure to use MUST every place where there is a definite step to be DH> followed? Would this be clearer? David, stop leaping. -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Mon May 11 08:45:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A27E93A6F75; Mon, 11 May 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090511154501.A27E93A6F75@core3.amsl.com> Date: Mon, 11 May 2009 08:45:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-18.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-18.txt Pages : 39 Date : 2009-05-11 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-isms-secshell-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-11083831.I-D@ietf.org> --NextPart-- From cfinss@dial.pipex.com Mon May 11 10:57:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954D53A6899; Mon, 11 May 2009 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hEVay6OuSzI; Mon, 11 May 2009 10:57:08 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7193A67E5; Mon, 11 May 2009 10:57:07 -0700 (PDT) X-Trace: 158041757/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.14/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.14 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQEAMsDCEo+vBEO/2dsb2JhbACDKEyKYbBFCY1mAQaCRoE1BQ X-IronPort-AV: E=Sophos;i="4.40,329,1238972400"; d="scan'208";a="158041757" X-IP-Direction: IN Received: from 1cust14.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.14]) by smtp.pipex.tiscali.co.uk with SMTP; 11 May 2009 18:58:35 +0100 Message-ID: <005301c9d259$a5aefa00$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> Date: Mon, 11 May 2009 18:49:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Barry Leiba , isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 17:57:09 -0000 Juergen Apologies for the delayed response. Happily, I think that Wes's post last Saturday covered it very well. The text as it stands tells me that with sshTM but without TSM, conformance to the three I-Ds will cause outbound messages to be discarded (although inbound can be received - a potential attack surface?) But again as Wes says, this topic has occurred on the list, more than once I seem to recall. I believe it was Bert who first commented - sadly - that it did not seem possible to use sshTM with eg CSM. But that is what we have come up with. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Barry Leiba" ; ; Sent: Friday, May 08, 2009 11:43 PM Subject: Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms-transport-security-model-12 > On Fri, May 08, 2009 at 06:56:27PM +0200, tom.petch wrote: > > > The idea of Models in SNMP is to be able to mix and match. In > > practice, this has not worked - USM with sshTM will not function, > > regardless of whether it is secure or not. > > Not sure I understand why. Can you explain? > > > Thus TLS has session cache and resumption. Will that work with TSM? > > Yes, this will just work fine since it is transparent. You can add > session resumption to SSH and it will work just fine with sshtm. > > Of course, sometimes we design for extensibility and when we need it, > we realize the shortcomings of the design. But there are also things > that just work fine - you are painting a picture here with black > colors. Even though it is difficult to get exensibility right, I think > not trying to be extensible is not an alternative. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From barryleiba@gmail.com Thu May 7 19:09:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9663A6FA4; Thu, 7 May 2009 19:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGiIoh-fIV9J; Thu, 7 May 2009 19:09:06 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id B5D493A67FB; Thu, 7 May 2009 19:09:05 -0700 (PDT) Received: by ewy24 with SMTP id 24so1539420ewy.37 for ; Thu, 07 May 2009 19:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eM1Y+1syv701mN0NEXSk+38dINk3YIInWKgYsYKTN44=; b=MRKj4VOlTNPdEKwk9g57Pz9Z2mgXujun7N9pPhuB7aTb2oPtrso+f4N7IgIWp4ZbYk bHr4WxmYkxXcjjZabTddTR5aHuGucn01K//0zYmhWX76xYarCNHVxPzvXDX3fn+WsaR/ YsNq4bSYahFoYxE0Ew8E7mjjqpi8NTb+tzwr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mPUyleGooZh1a2Mj2ARwlvaL1mUVDGvxqrU549mXls+f63DS1NZ+0glCsE+oSn2HcK HHSpVmKciSLZ3VAx9whcBf/sFmb67xM7cBDA3/2lIaK6Um+M9uNdBU6nYR+q6i/M0d+Z Adxlf2FsebSIYQKVV1+zfHoBhYbVQDghrPxrI= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.130.14 with SMTP id c14mr3848956ebd.17.1241748630564; Thu, 07 May 2009 19:10:30 -0700 (PDT) In-Reply-To: References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Thu, 7 May 2009 22:10:30 -0400 X-Google-Sender-Auth: df2cf3bcf03b453a Message-ID: <9abf48a60905071910rcf9e321ha0ab92e692a6aeed@mail.gmail.com> From: Barry Leiba To: David B Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 11 May 2009 15:05:52 -0700 Cc: isms@ietf.org, secdir@ietf.org, isms-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-isms-transport-security-model@tools.ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 02:09:07 -0000 Sam says... > Or just use lower case should. =A0I think the advice is important enough > it does not belong in an appendix. Indeed. I didn't mean for my comment to cause a big stir; I think it's easy to sort= out. I like my first suggestion, repeated here: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it MUST always be used with a Transport Model that provides appropriate security. What is "appropriate" for a particul= ar deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. ...but I'd also be happy with something like this, if you don't want to use 2119 language: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so deployments should [or "must"] use it with a Transport Model that provides appropriate security. Which threats are addressed and how they are mitigated depends on the Transport Model. In any case, let's not spend any more time on this one. Barry --=20 Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From barryleiba@gmail.com Fri May 8 11:03:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CDB3A6A6A; Fri, 8 May 2009 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh7Vs5CytDTP; Fri, 8 May 2009 11:03:49 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 1BACA3A68EE; Fri, 8 May 2009 11:03:48 -0700 (PDT) Received: by ewy24 with SMTP id 24so2003758ewy.37 for ; Fri, 08 May 2009 11:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Xxbp2g/pWwo7wsfjK8ouyVG14qFJJN2OPWa/Cf9cPF4=; b=NaZGuz7Lfy6PIhb6XXhqFOUxKiPSjILsG2wIPMGm3SOI3e1l479V+wP2juGsDVjjO1 uVIGYnrIAG3rN4OeOBzelTQbOZyrJm4GSndz6c0YdgJW6Yz79aaFoBWpRz2MINLLQEIC mXhc3i1D0v0U2rBotIxLv98Dylyr3jTAY3ZQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aCDzAUR8J3hlq8jZ3Ncr467cgTwOt9My7E5c9dTl12N+AJEVrvyicLHlg2mYtAnJ8V e+flK2bF2fO3F/cZ0c40YpZUwK+/FtRy3ZsWpWuVdJLxXCpcsKgH+11f7Px8KajLBiUL 2QyFHmRBdS5ucBkez5wanSNSbzz2XdCV784tg= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.17.2 with SMTP id 2mr2065031ebq.35.1241805915886; Fri, 08 May 2009 11:05:15 -0700 (PDT) In-Reply-To: <007f01c9cffe$0aa68da0$0601a8c0@allison> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> Date: Fri, 8 May 2009 14:05:15 -0400 X-Google-Sender-Auth: cb874c641c4d5cc1 Message-ID: <9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> From: Barry Leiba To: "tom.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 11 May 2009 15:05:52 -0700 Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [Isms] [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 18:03:50 -0000 (Top post only...) I get what you're saying, Tom, but I'm not sure where it's going. Are you saying that the text should be changed to allow *less* flexibility? That may be right, but then what text do you suggest instead? Barry >> > That is a deployment decision made by an administrator who has an >> > understanding of what is appropriate to the system in question. >> > >> > What is the correct non-RFC2119 phrase in which to couch our >> > deployment advice? >> >> Well, this would make me happy; would it work for you (and others)?: >> >> OLD: >> =A0 =A0by the RFC 3411 architecture. =A0However, the Transport Security = Model >> =A0 =A0does not provide security mechanisms such as authentication and >> =A0 =A0encryption itself, so it SHOULD always be used with a Transport M= odel >> =A0 =A0that provides appropriate security. =A0Which threats are addresse= d and >> =A0 =A0how they are mitigated depends on the Transport Model. >> >> NEW: >> =A0 =A0by the RFC 3411 architecture. =A0However, the Transport Security = Model >> =A0 =A0does not provide security mechanisms such as authentication and >> =A0 =A0encryption itself, so it MUST always be used with a Transport Mod= el >> =A0 =A0that provides appropriate security. =A0What is "appropriate" for = a particular >> =A0 =A0deployment is an administrative decision. =A0Which threats are ad= dressed >> =A0 =A0and how they are mitigated depends on the Transport Model. > > I have reservations about this, about the optimism that it may generate i= n > readers. > > The idea of Models in SNMP is to be able to mix and match. =A0In practice= , this > has not worked - USM with sshTM will not function, regardless of whether = it is > secure or not. =A0Do not underestimate the labour it has taken to get TSM= working > with sshTM. > > If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an i= dea > that is being mooted now. =A0But it may not. =A0In a similar vein, I am m= indful that > ssh just hit problems with AES-GCM, that the architecture of ssh does not= allow > for this new cryptography or that the discussions leading to TLS 1.2 of h= ow to > introduce (or not) algorithm agility, just as SNMP has problems (and has = given > up) trying to use USM with sshTM. > > Thus TLS has session cache and resumption. Will that work with TSM? I do = not > know - and as it has taken the last two years to come up with an agreed f= orm of > words that allows just TSM to work with just sshTM, so I am not going > to try and work out the ramifications of TLSTM just yet:-( =A0We may find= we got > TSM wrong and that it needs changing. > > Or we may have another secure Transport Model that turns out to be insecu= re with > TSM and needs an xSM to make it secure. =A0The proposed amendment seems t= o me > rather optimistic. > > Tom Petch From j.schoenwaelder@jacobs-university.de Fri May 15 04:38:13 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CCB3A6996 for ; Fri, 15 May 2009 04:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdYXDHtdb64f for ; Fri, 15 May 2009 04:38:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3BACC3A6781 for ; Fri, 15 May 2009 04:38:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2CB8C0085 for ; Fri, 15 May 2009 13:39:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aNqkrabNQ3rA; Fri, 15 May 2009 13:39:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A30EC007E; Fri, 15 May 2009 13:39:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 362B4AEFD79; Fri, 15 May 2009 13:39:43 +0200 (CEST) Date: Fri, 15 May 2009 13:39:43 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090515113943.GA2815@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 11:38:13 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the proposal for rechartering the ISMS working group. I like to determine how much support there is for this new charter text. Please read the charter and send to the list (or me directly if you prefer) a short note indicating: a) I do support the new charter and I commit myself to review the documents and contribute to the discussions around the work items b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items c) I do not support the new charter and here is why and how the charter can be fixed: d) I do not support to recharter this WG and I believe it should go dormant. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=qqqq Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * TBD Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG --Q68bSM7Ycu6FN28Q-- From ietfdbh@comcast.net Fri May 15 04:58:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D494D3A6A4C for ; Fri, 15 May 2009 04:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcbENhxheop8 for ; Fri, 15 May 2009 04:58:10 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id BC7DA3A69BB for ; Fri, 15 May 2009 04:58:09 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA09.westchester.pa.mail.comcast.net with comcast id rmeg1b0030ldTLk59nzk4M; Fri, 15 May 2009 11:59:44 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id rnzj1b00B0UQ6dC3QnzjMr; Fri, 15 May 2009 11:59:44 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20090515113943.GA2815@elstar.local> Date: Fri, 15 May 2009 07:59:42 -0400 Message-ID: <017601c9d554$a234aca0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090515113943.GA2815@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcnVUdr/cBYONur6TcK0atqCKvMguAAAqDYA Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 11:58:10 -0000 b) dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, May 15, 2009 7:40 AM > To: isms@ietf.org > Subject: [Isms] rechartering poll > > Hi, > > attached please find the proposal for rechartering the ISMS working > group. I like to determine how much support there is for this new > charter text. Please read the charter and send to the list (or me > directly if you prefer) a short note indicating: > > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items > > b) I do support the new charter but I have no resources to be actively > involved with reviewing/discussing work items > > c) I do not support the new charter and here is why and how the > charter can be fixed: > > d) I do not support to recharter this WG and I believe it should go > dormant. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From d.b.nelson@comcast.net Fri May 15 05:33:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047033A70D0 for ; Fri, 15 May 2009 05:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlxCX7n8a1kd for ; Fri, 15 May 2009 05:33:09 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id D88E628C3A8 for ; Fri, 15 May 2009 05:32:33 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id rnhs1b0050b6N64AFoa81c; Fri, 15 May 2009 12:34:08 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id roa61b00H4H2mdz8Poa7MT; Fri, 15 May 2009 12:34:08 +0000 From: "Dave Nelson" To: References: <20090515113943.GA2815@elstar.local> Date: Fri, 15 May 2009 08:34:41 -0400 Message-ID: <5286569E84684EBB9B72019ABD8B1E19@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090515113943.GA2815@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AcnVUdr/bRc3USC8SdW/0KvxtraYVgAB1yog Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 12:33:10 -0000 (a) -- utilizing non-work hours. I will co-edit the RADIUS/VACM document and contribute to discussion. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Friday, May 15, 2009 7:40 AM > To: isms@ietf.org > Subject: [Isms] rechartering poll > > Hi, > > attached please find the proposal for rechartering the ISMS working > group. I like to determine how much support there is for this new > charter text. Please read the charter and send to the list (or me > directly if you prefer) a short note indicating: > > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items > > b) I do support the new charter but I have no resources to be actively > involved with reviewing/discussing work items > > c) I do not support the new charter and here is why and how the > charter can be fixed: > > d) I do not support to recharter this WG and I believe it should go > dormant. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From wjhns1@hardakers.net Fri May 15 07:15:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA14E3A6DB7 for ; Fri, 15 May 2009 07:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpYnBrO6CrGy for ; Fri, 15 May 2009 07:15:36 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 00E063A68FA for ; Fri, 15 May 2009 07:15:35 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 888D739A10A for ; Fri, 15 May 2009 07:17:09 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090515113943.GA2815@elstar.local> Date: Fri, 15 May 2009 07:17:09 -0700 In-Reply-To: <20090515113943.GA2815@elstar.local> (Juergen Schoenwaelder's message of "Fri, 15 May 2009 13:39:43 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsrechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:15:36 -0000 >>>>> On Fri, 15 May 2009 13:39:43 +0200, Juergen Schoenwaelder said: a) JS> a) I do support the new charter and I commit myself to review the JS> documents and contribute to the discussions around the work items -- Wes Hardaker Cobham Analytic Solutions From wwwrun@core3.amsl.com Fri May 15 07:24:10 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7409C3A70D5; Fri, 15 May 2009 07:24:10 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090515142410.7409C3A70D5@core3.amsl.com> Date: Fri, 15 May 2009 07:24:10 -0700 (PDT) Cc: Internet Architecture Board , isms mailing list , isms chair , RFC Editor Subject: [Isms] Protocol Action: 'Secure Shell Transport Model for SNMP' to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:24:10 -0000 The IESG has approved the following document: - 'Secure Shell Transport Model for SNMP ' as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-18.txt Technical Summary The document defines a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell protocol (SSH). The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Secure Shell Transport Model for SNMP. Working Group Summary The document has mainly been updated recently to track clarifications and to improve the readability. There has been WG consensus on revision 15 of this document and there are no controversies on the technical solution. Document Quality There are two known implementations in progress of the Secure Shell Transport Model. There are no further vendor commitments at the moment to implement this specification. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. From wwwrun@core3.amsl.com Fri May 15 07:25:38 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2217328C3C7; Fri, 15 May 2009 07:25:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090515142527.2217328C3C7@core3.amsl.com> Date: Fri, 15 May 2009 07:25:25 -0700 (PDT) Cc: Internet Architecture Board , isms mailing list , isms chair , RFC Editor Subject: [Isms] Protocol Action: 'Transport Subsystem for the Simple Network Management Protocol (SNMP)' to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:25:38 -0000 The IESG has approved the following document: - 'Transport Subsystem for the Simple Network Management Protocol (SNMP) ' as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-18.txt Technical Summary The document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. The subsystem can contain Transport Models comparable to other subsystems in the RFC 3411 architecture. The Transport Subsystem can be used to expand the transports to include secure transports such as SSH or TLS. Working Group Summary The working group went over several revisions of this document while developing a Transport Model for SSH. The document did stabilize several revisions ago and has mainly been kept back to track clarifications and to ensure the new subsystem works with the SSH transport defined in a companion document. There has been strong WG consensus on revision 16 of this document. Document Quality There are two known implementations in progress of secure transport models. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Subsystem defined in this document is capable to supports both secure transports. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. The IANA Expert for the registries in this document is David Harrington (ietfdbh@comcast.net). From wwwrun@core3.amsl.com Fri May 15 07:26:44 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 707EC3A6BA9; Fri, 15 May 2009 07:26:44 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090515142644.707EC3A6BA9@core3.amsl.com> Date: Fri, 15 May 2009 07:26:44 -0700 (PDT) Cc: Internet Architecture Board , isms mailing list , isms chair , RFC Editor Subject: [Isms] Protocol Action: 'Transport Security Model for SNMP' to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:26:44 -0000 The IESG has approved the following document: - 'Transport Security Model for SNMP ' as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-14.txt Technical Summary The document defines a Transport Security Model for the Simple Network Management Protocol (SNMP) for use with secure Transport Models in the Transport Subsystem. The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. Working Group Summary The document did stabilize several revisions ago and has mainly been updated recently to track clarifications. There has been WG consensus on revision 12 of this document and there were no controversies on the technical solution since the IETF meeting in Dublin. Document Quality There are two known implementations in progress of the Transport Security Model. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Security Model defined in this document is capable to support both secure transports. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. From kaushik@cisco.com Fri May 15 08:08:43 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDB73A6A7F for ; Fri, 15 May 2009 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRnLF+f1ANDy for ; Fri, 15 May 2009 08:08:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2950C3A68C5 for ; Fri, 15 May 2009 08:08:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,200,1241395200"; d="scan'208";a="165949021" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 May 2009 15:10:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4FFAE2K010494; Fri, 15 May 2009 08:10:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4FFAEKb006036; Fri, 15 May 2009 15:10:14 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 08:10:14 -0700 Received: from 10.21.115.237 ([10.21.115.237]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 May 2009 15:10:13 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 15 May 2009 08:10:11 -0700 From: kaushik To: Juergen Schoenwaelder , Message-ID: Thread-Topic: [Isms] rechartering poll Thread-Index: AcnVbz2zhwcobQbi2ECxQiOke7mZew== In-Reply-To: <20090515113943.GA2815@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 May 2009 15:10:14.0015 (UTC) FILETIME=[3F7F18F0:01C9D56F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=895; t=1242400214; x=1243264214; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20rechartering=20poll |Sender:=20; bh=ahA5TvkKPI/IEqCPkot+RziWU0jz0aLAAZ5ahx8A2rE=; b=juhVo7IikR4L9imbqWQ4v5uxxWSIDp1QHpf5MCe9WQZQV82m47m34dcnFF AVon/ovlmANx+M/LmjLIJp1JCKo3BVNYZEQtooZIpKqq3a+tBopoho8Pv+8D ou7zI+++HurBU7yhAaJ8k7d9ye9XV5Kyqh0OuFinreXEQ2Vto3pho=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 15:08:43 -0000 a) - I will help co-edit the RADIUS/VACM document. On 5/15/09 4:39 AM, "Juergen Schoenwaelder" wrote: > Hi, > > attached please find the proposal for rechartering the ISMS working > group. I like to determine how much support there is for this new > charter text. Please read the charter and send to the list (or me > directly if you prefer) a short note indicating: > > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items > > b) I do support the new charter but I have no resources to be actively > involved with reviewing/discussing work items > > c) I do not support the new charter and here is why and how the > charter can be fixed: > > d) I do not support to recharter this WG and I believe it should go > dormant. > > /js From j.schoenwaelder@jacobs-university.de Sat May 16 04:22:13 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069853A6AEB for ; Sat, 16 May 2009 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmaOjJJsl85z for ; Sat, 16 May 2009 04:22:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 262AC3A67E6 for ; Sat, 16 May 2009 04:22:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECF7BC02F5 for ; Sat, 16 May 2009 13:23:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZCPo7dvj1s2A; Sat, 16 May 2009 13:23:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 544CEC02F0; Sat, 16 May 2009 13:23:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 13714B17ED2; Sat, 16 May 2009 13:23:43 +0200 (CEST) Date: Sat, 16 May 2009 13:23:43 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090516112343.GA2388@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] isms core drafts approved X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2009 11:22:13 -0000 Hi, the core IDs of this WG have been approved by the IESG and are now in the RFC editor queue. I like to thank everyone actively involved in the production process of these IDs for their contributions over the years and in particular David Harrington for serving as our lead editor for these comments and our responsible ADs (Pasi and formerly Sam) for helping us along when we needed their help. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon May 18 03:03:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3A128C29C for ; Mon, 18 May 2009 03:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV83AK3j4ETh for ; Mon, 18 May 2009 03:03:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EFF0228C28C for ; Mon, 18 May 2009 03:03:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="146073552" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 May 2009 06:05:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 May 2009 06:05:01 -0400 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 Date: Mon, 18 May 2009 12:04:56 +0200 Message-ID: In-Reply-To: <20090515113943.GA2815@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] rechartering poll Thread-Index: AcnVUdvWAH8cKBV/QlePBA4z61jdCgCThR/g References: <20090515113943.GA2815@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 10:03:29 -0000 b)=20 Dan (speaking as a contributor)=20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Friday, May 15, 2009 2:40 PM > To: isms@ietf.org > Subject: [Isms] rechartering poll >=20 > Hi, >=20 > attached please find the proposal for rechartering the ISMS=20 > working group. I like to determine how much support there is=20 > for this new charter text. Please read the charter and send=20 > to the list (or me directly if you prefer) a short note indicating: >=20 > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items >=20 > b) I do support the new charter but I have no resources to be actively > involved with reviewing/discussing work items >=20 > c) I do not support the new charter and here is why and how the > charter can be fixed: >=20 > d) I do not support to recharter this WG and I believe it should go > dormant. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From jhutz@cmu.edu Mon May 18 07:32:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF9F28C2F4 for ; Mon, 18 May 2009 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPTUB0qeg4GM for ; Mon, 18 May 2009 07:32:53 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by core3.amsl.com (Postfix) with ESMTP id 702A73A704D for ; Mon, 18 May 2009 07:32:37 -0700 (PDT) Received: from [192.168.1.101] (173-114-113-168.pools.spcsdns.net [173.114.113.168]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4IEY9pE021320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2009 10:34:11 -0400 (EDT) Date: Mon, 18 May 2009 10:34:09 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , isms@ietf.org Message-ID: In-Reply-To: <200905151139.n4FBdnse011995@mx02.srv.cs.cmu.edu> References: <200905151139.n4FBdnse011995@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.117 Cc: jhutz@cmu.edu Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 14:32:54 -0000 > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items Really, I could make a bunch of comments about the language of the WG description in the proposed charter, but I don't think it's worth the effort. The substance is right, which is what matters. -- Jeff From hmills@mitre.org Mon May 18 11:10:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E013A7062 for ; Mon, 18 May 2009 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.744 X-Spam-Level: X-Spam-Status: No, score=-4.744 tagged_above=-999 required=5 tests=[AWL=1.855, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvAXyJo+KhjO for ; Mon, 18 May 2009 11:10:01 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 983993A705C for ; Mon, 18 May 2009 11:10:00 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n4IIBZWx032170 for ; Mon, 18 May 2009 14:11:35 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n4IIBZhA032167 for ; Mon, 18 May 2009 14:11:35 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 18 May 2009 14:11:35 -0400 From: "Mills, Hyrum L" To: "isms@ietf.org" Date: Mon, 18 May 2009 14:11:32 -0400 Thread-Topic: [Isms] rechartering poll Thread-Index: AcnVUd38wQG0pxhdTrOSeuEnQLoMJwCkfxeg Message-ID: References: <20090515113943.GA2815@elstar.local> In-Reply-To: <20090515113943.GA2815@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:10:09 -0000 a) I do support the new charter and I commit myself to review the documents and contribute to the discussions around the work items Hyrum Mills -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Friday, May 15, 2009 6:40 AM To: isms@ietf.org Subject: [Isms] rechartering poll Hi, attached please find the proposal for rechartering the ISMS working group. I like to determine how much support there is for this new charter text. Please read the charter and send to the list (or me directly if you prefer) a short note indicating: a) I do support the new charter and I commit myself to review the documents and contribute to the discussions around the work items b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items c) I do not support the new charter and here is why and how the charter can be fixed: d) I do not support to recharter this WG and I believe it should go dormant. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From adonati@motorola.com Mon May 18 12:19:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A7F28C2CF for ; Mon, 18 May 2009 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erm4BWmzS82o for ; Mon, 18 May 2009 12:19:26 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 546183A6E8A for ; Mon, 18 May 2009 12:19:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1242674458!2424897!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15341 invoked from network); 18 May 2009 19:20:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 May 2009 19:20:59 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n4IJKwTb014545 for ; Mon, 18 May 2009 12:20:58 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n4IJKvHo007374 for ; Mon, 18 May 2009 14:20:57 -0500 (CDT) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n4IJKvSi007370 for ; Mon, 18 May 2009 14:20:57 -0500 (CDT) 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 Date: Mon, 18 May 2009 15:20:35 -0400 Message-ID: In-Reply-To: <20090515113943.GA2815@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] rechartering poll Thread-Index: AcnVUd6QxF9DMDIiT/6GT1mc9RmTeACmVe4A References: <20090515113943.GA2815@elstar.local> From: "Donati Andrew-MGIA0477" To: "Juergen Schoenwaelder" , X-CFilter-Loop: Reflected Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:19:27 -0000 b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items - Andy Donati -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, May 15, 2009 7:40 AM To: isms@ietf.org Subject: [Isms] rechartering poll Hi, attached please find the proposal for rechartering the ISMS working group. I like to determine how much support there is for this new charter text. Please read the charter and send to the list (or me directly if you prefer) a short note indicating: a) I do support the new charter and I commit myself to review the documents and contribute to the discussions around the work items b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items c) I do not support the new charter and here is why and how the charter can be fixed: d) I do not support to recharter this WG and I believe it should go dormant. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dave.shield@googlemail.com Tue May 19 02:47:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF04D28C2F1 for ; Tue, 19 May 2009 02:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WltAz9gRHejl for ; Tue, 19 May 2009 02:47:36 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 8113328C10A for ; Tue, 19 May 2009 02:47:35 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so1800648fkq.5 for ; Tue, 19 May 2009 02:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=RaK87IHewEWPV6aBSlOiT+GHbWUECvPxjmQV+ge4aao=; b=HCCPC06HdxfG76KcjaXMS5fbMpNoxa9YCfaaKknKe9SvxfFB5AH9vFufL2ikmNBQWc XFuI9Vxv8vLEj9L5OTTHNrqsO03PWq6WYk+2p7bwnT2B8PcDpZJLWS+yNlQ+Z1GmUPfu kcoufj9RBuwtrrH9bUfDl3j1iNTKclOyLflac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=TdnjXzQ+8gz2Q16KGRU3bZUJ+XtjzWYRlvlUve4V8REh972+bhzN6m8QiVUJ0y8s0t wVLKJ3JLC++djVyxxdZlUYtGdLWJvA5AFslG4p8bjjjqgjX1bB+19kCw5vFbh9Vy+HrO JaHWuXbJ+ovFMTzNpBq3kYn3CbOTbql7zs73E= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.223.111.71 with SMTP id r7mr4958803fap.59.1242726548704; Tue, 19 May 2009 02:49:08 -0700 (PDT) In-Reply-To: <20090515113943.GA2815@elstar.local> References: <20090515113943.GA2815@elstar.local> Date: Tue, 19 May 2009 10:49:08 +0100 X-Google-Sender-Auth: 88b70012674ae968 Message-ID: From: Dave Shield To: Juergen Schoenwaelder , isms@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:47:37 -0000 2009/5/15 Juergen Schoenwaelder : > a) I do support the new charter and I commit myself to review the > =A0 documents and contribute to the discussions around the work items Dave From cfinss@dial.pipex.com Tue May 19 10:28:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC813A6ECC for ; Tue, 19 May 2009 10:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_20=-0.74, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BtLtD1pCxkp for ; Tue, 19 May 2009 10:28:04 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id E36623A68D4 for ; Tue, 19 May 2009 10:28:03 -0700 (PDT) X-Trace: 214909187/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.58/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.58 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswFALOJEko+vBM6/2dsb2JhbABFgmNOinSxPAmPcgEGgkeBNAU X-IronPort-AV: E=Sophos;i="4.41,216,1241391600"; d="scan'208";a="214909187" X-IP-Direction: IN Received: from 1cust58.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.58]) by smtp.pipex.tiscali.co.uk with SMTP; 19 May 2009 18:29:38 +0100 Message-ID: <00e601c9d89e$e7967740$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090515113943.GA2815@elstar.local> Date: Tue, 19 May 2009 10:05:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:28:05 -0000 d) Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Friday, May 15, 2009 1:39 PM Subject: [Isms] rechartering poll > > attached please find the proposal for rechartering the ISMS working > group. I like to determine how much support there is for this new > charter text. Please read the charter and send to the list (or me > directly if you prefer) a short note indicating: > > a) I do support the new charter and I commit myself to review the > documents and contribute to the discussions around the work items > > b) I do support the new charter but I have no resources to be actively > involved with reviewing/discussing work items > > c) I do not support the new charter and here is why and how the > charter can be fixed: > > d) I do not support to recharter this WG and I believe it should go > dormant. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From blueroofmusic@gmail.com Tue May 19 13:32:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7588C3A69D6 for ; Tue, 19 May 2009 13:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoBgPZbWSmmH for ; Tue, 19 May 2009 13:32:20 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 52E9A3A6E68 for ; Tue, 19 May 2009 13:32:06 -0700 (PDT) Received: by fxm2 with SMTP id 2so36825fxm.37 for ; Tue, 19 May 2009 13:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ki5S42Zol6HoE7sY/+5t7/Yyof1ey8WgwVrwdFrm+34=; b=NnQNIPmPGRu71IyiZuItTndS6ewjlYVOfbovyvCeMVnYTxHqQphewsrGPMnwR+8HoL MPmoPeoGu35doFDLBjUBAiSXv1rdMhRUr4rp2BXjCBQErWfSM7BKmi/FBEgk/OfwVOjE 5JfcCS2yC/PhlTwn7r0G9NbBEj+CnCDehjZoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PcMDqm0WM1gVhPFihOjop5SDU4D0QSMEcNv/T0xQHyXNOzLKfag1OvKTD6rE/6T+Tm XQb1akCKe28BFwT8flOGkiaY/9SFnSVNDli3wDwzS/Mh4XkNEVzNkgi5722sJQ8Fm6Sb /vUeQ/ARRK94w6pTYe8UxOmT3KBEFWDrd/0lk= MIME-Version: 1.0 Received: by 10.204.56.4 with SMTP id w4mr443019bkg.25.1242765220607; Tue, 19 May 2009 13:33:40 -0700 (PDT) In-Reply-To: <20090515113943.GA2815@elstar.local> References: <20090515113943.GA2815@elstar.local> Date: Tue, 19 May 2009 16:33:40 -0400 Message-ID: From: Ira McDonald To: Juergen Schoenwaelder , isms@ietf.org Content-Type: multipart/alternative; boundary=00504502bad0837a15046a49d362 Subject: Re: [Isms] rechartering poll X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:32:21 -0000 --00504502bad0837a15046a49d362 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 --00504502bad0837a15046a49d362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

b) I do support the new charter but I have no resources to be ac= tively
=A0 involved with reviewing/discussing work items

Cheers,
- Ira

Ira McDonald (Musician / Software= Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music= /High North Inc
email: bluero= ofmusic@gmail.com
winter:
=A0579 Park Place =A0Saline, MI =A048176
=A0734-944-0094summer:
=A0PO Box 221 =A0Grand Marais, MI 49839
=A0906-494-2434
--00504502bad0837a15046a49d362-- From j.schoenwaelder@jacobs-university.de Mon May 25 01:06:35 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC843A6B66 for ; Mon, 25 May 2009 01:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2aB-QbjABfo for ; Mon, 25 May 2009 01:06:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0901B3A6847 for ; Mon, 25 May 2009 01:06:34 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6437FC0188; Mon, 25 May 2009 10:08:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0OZxxQM7ss0D; Mon, 25 May 2009 10:08:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D87BC00AC; Mon, 25 May 2009 10:08:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9651DB1FD0C; Mon, 25 May 2009 10:08:12 +0200 (CEST) Date: Mon, 25 May 2009 10:08:12 +0200 From: Juergen Schoenwaelder To: isms@ietf.org, Pasi Eronen Message-ID: <20090525080812.GA2548@elstar.local> Mail-Followup-To: isms@ietf.org, Pasi Eronen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] isms recharter poll results X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 08:06:35 -0000 Hi, here is the result of the rechartering poll: a) I do support the new charter and I commit myself to review the documents and contribute to the discussions around the work items - Dave Nelson - Wes Hardaker - Kaushik Narayan - Jeff Hutzelman - Hyrum Mills - Dave Shield b) I do support the new charter but I have no resources to be actively involved with reviewing/discussing work items - Dave Harrington - Dan Romascanu - Andy Donati - Ira McDonald c) I do not support the new charter and here is why and how the charter can be fixed: d) I do not support to recharter this WG and I believe it should go dormant. - Tom Petch There is obviously a majority in favour of the charter proposal. The number of contributors, taking potential document editors/authors aside, is however small and it is likely going to be tough to get substantial and timely reviews. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103